Оптимизация совещаний по техническому проектированию с помощью структурированных шаблонов заявок

Когда я устроился на работу в Wayfair в 2020 году, я был рад присоединиться к скромным, разрозненным командам, которые поддерживали инструмент b2b, который управлял огромными объемами бизнеса. Я пришел с должности, где я работал в основном изолированно, поэтому я был особенно рад снова стать частью команды разработчиков. Однако я очень быстро обнаружил, что большая часть команды обладала таким большим опытом в инструментах, которые мы использовали, что у них было предопределенное предположение, что у других разработчиков был такой же бэкграунд, опыт и знания, как у них. Основная проблема заключалась в том, что инструменты, над которыми мы работали, были внутренними и фирменными, поэтому многие из новых разработчиков не знали их так же хорошо, как опытные разработчики. Теперь это не проблема в целом. Однако это стало очень проблематичным, когда тикеты Jira создавались, приоритизировались, оценивались и назначались с небольшим количеством деталей. Конечно, заголовок объяснял общую проблему, и опытный разработчик, который его написал, вероятно, точно знал, с чего начать, чтобы внести изменения, но у тех из нас, кто был новичком на платформах, было очень мало материала, чтобы начать. Это привело к огромным дырам в эффективности, когда мы постоянно преследовали более опытных разработчиков, требуя больше информации.

Другим побочным продуктом этой установки было то, что наши встречи по техническому проектированию, как правило, затягивались, поскольку у все большего числа из нас возникали вопросы по тикетам, которые представлялись для оценки. Детали постоянно вытягивались в разговоре, но ни одна из них не записывалась. Эти встречи затягивались, а затем те же самые вопросы возвращались, как только тикет был назначен (если только назначенный не мог волшебным образом вспомнить разговор, состоявшийся несколько недель назад, где изначально задавались вопросы).

Этот рабочий процесс был невероятно разочаровывающим и неэффективным. Но есть надежда! Вскоре после того, как мы осознали эту проблему и обсудили ее, встречи стали проходить более гладко, занимая меньше времени и оказывая большее влияние. Тикеты были полны подробностей и их было легко выполнять, тестировать и выполнять. Вот как мы это сделали.

Проблема: неподготовленные билеты и длительные встречи

Наши встречи по техническому проектированию часто срывались из-за тикетов, в которых не хватало подробностей. Разработчики, дизайнеры и другие заинтересованные стороны тратили слишком много времени на поиск дополнительной информации или разъяснение неясных аспектов задачи. Это не только удлиняло наши встречи, но и задерживало разработку, поскольку назначенные тикеты часто возвращались, требуя дополнительных разъяснений, прежде чем работа могла быть продолжена.

Отличным примером этого может служить тикет, отправленный штатным разработчиком, в котором просто говорилось: «Нам нужно исправить цены на напольные покрытия».

Очевидно, что без достаточного количества справочной информации вы ничего не сможете сделать, получив этот тикет. В чем проблема с ценообразованием на складские номера? Что ожидается? Имеет ли значение количество складских номеров в корзине? Есть много открытых вопросов, и на самом деле нет способа начать работу, не заскочив на встречу. Лучшее описание тикета может быть таким.

«Товары с минимальной ценой имеют оптовую цену, и наша система не обрабатывает расчеты цены/количества должным образом, когда количество в корзине превышает пороговые значения оптовых цен».

Конечно, здесь все еще недостаточно подробностей, но, по крайней мере, проблема объяснена правильно.

Я не собираюсь утомлять пример, но разработчику(ам) пришлось бы конкретизировать все эти детали с помощью повторяющихся вопросов, разговоров и презентаций, пока у нас не будет достаточно деталей для оценки или работы над тикетом, в зависимости от текущей задачи. Это привело к потере большого количества времени, которое мы, как разработчики, не могли вернуть.

Решение: внедрение шаблонов тикетов

Чтобы решить эту проблему, мы разработали набор структурированных шаблонов тикетов, адаптированных к типу выполняемой работы. Эти шаблоны гарантировали, что каждый тикет — будь то отчет об ошибке, изменение дизайна, запрос функции или задача оптимизации — содержал всю необходимую информацию до обсуждения или назначения. Правило было простым: если шаблон не был полностью завершен, тикет не был готов к встрече или к разработке.

Отчеты об ошибках

Описание:

Краткое, но подробное описание проблемы.

Ожидаемое поведение:

Более подробное объяснение, включая скриншоты или ссылки на Figma, того, как все должно работать.

Фактическое поведение:

Подробное описание происходящего и того, чем оно отличается от ожидаемого поведения.

Шаги по воссозданию:

Конкретные, подробные шаги по воссозданию проблемы. Это нужно сделать так, чтобы кто-то мог открыть новое окно в режиме инкогнито в инструменте и воссоздать проблему, не отклоняясь от шагов.

(необязательно) Примечания разработчика:

Это необязательный раздел, в который мы можем включить предлагаемые подходы, если у нас уже есть хорошее представление о том, куда это должно пойти или как это должно быть разработано. Мы не хотим заставлять разработчиков делать что-то определенным образом, но любые указания здесь могут помочь ускорить выполнение тикета позже.

(необязательно, но желательно) Внешние воздействия:

Здесь мы указываем любые внешние источники, которые могут повлиять на эту работу. Есть ли команды, которые уже создали обходной путь для ошибки в нашем API, и которые должны быть уведомлены, когда мы ее исправим? Опирается ли эта ошибка на другие команды/API/источники для получения информации, которая может потенциально повлиять на то, сколько времени потребуется для ее исправления?

(необязательно) Влияние:

Имеет ли это известное, измеримое влияние на команду или бизнес? Это не всегда известно или легко измерить, поэтому это необязательное поле. Но важно знать для расстановки приоритетов, если оно существует.

Изменения в дизайне

Описание:

Краткое, но подробное описание проблемы.

Ожидаемое поведение:

Скриншоты или ссылки Figma для ожидаемого, спроектированного поведения.

Фактическое поведение:

Скриншоты или видео, подробно демонстрирующие, что на самом деле происходит, а также описание происходящего и того, чем оно отличается от ожидаемого поведения.

(необязательно) Шаги по воссозданию:

Если это определенный элемент пользовательского интерфейса, который появляется только в определенных ситуациях, нам нужно точно знать, как/когда он должен присутствовать, чтобы мы знали, как тестировать наши изменения.

(необязательно) Примечания разработчика:

Это необязательный раздел, в который мы можем включить предлагаемые подходы, если у нас уже есть хорошее представление о том, куда это должно пойти или как это должно быть разработано. Мы не хотим заставлять разработчиков делать что-то определенным образом, но любые указания здесь могут помочь ускорить выполнение тикета позже.

(необязательно) Влияние:

Имеет ли это известное, измеримое влияние на команду или бизнес? Это не всегда известно или легко измерить, поэтому это необязательное поле. Но важно знать для расстановки приоритетов, если оно существует.

Запросы функций

Описание:

Полная подробная картина того, что представляет собой функция. Как она должна функционировать, каковы ожидаемые входы/выходы и т. д. Мы также должны включить любые имеющиеся у нас обоснования того, почему эта функция запрашивается здесь.

Примечания разработчика:

Разработчик должен использовать этот раздел для предоставления руководства по известным фреймворкам/шаблонам, которые следует использовать для бесшовного встраивания в остальную часть нашей кодовой базы. Мы не хотим заставлять разработчиков писать код каким-либо определенным образом, но любое руководство здесь ускорит выполнение тикета и должно привести к более упорядоченным PR-обсуждениям.

(необязательно, но желательно) Макеты:

Если у нас есть примеры полезных нагрузок, скриншоты или ссылки на Figma, которые могут помочь в разработке, все это следует включить сюда.

(необязательно, но желательно) Внешние воздействия:

Здесь мы указываем любые внешние источники, которые могут повлиять на эту работу. Есть ли команды, которые уже создали обходной путь для отсутствующей функции в нашем API, и которые должны быть уведомлены, когда мы ее добавим? Опирается ли эта функция на другие команды/API/источники для получения информации, которая может потенциально повлиять на то, сколько времени потребуется для ее создания?

(необязательно) Влияние:

Имеет ли это известное, измеримое влияние на команду или бизнес? Это не всегда известно или легко измерить, поэтому это необязательное поле. Но важно знать для расстановки приоритетов, если оно существует.

Задачи оптимизации

Описание:

Краткое, но подробное описание проблемы.

Текущее состояние:

Более подробное объяснение того, как в настоящее время работает код и почему он неэффективен.

Предпочтительное состояние:

Подробное описание того, что мы хотим исправить с помощью этой оптимизации, каких целей мы пытаемся достичь.

Примечания разработчика:

Это руководство от разработчика, который указывает на необходимость оптимизации. Оно должно указывать на конкретные файлы и тесты, которые необходимо отредактировать, а также на конкретные разделы, которые, по нашему мнению, являются узким местом в производительности или вызывают путаницу.

Тестирование:

Заметки о том, как можно проверить или верифицировать эту оптимизацию. Нам нужно не только увидеть, что мы действительно что-то получили от этого процесса (и это может быть чем-то, чем мы можем похвастаться), но нам также нужно убедиться, что изменения не повлияли ни на какие известные внешние процессы, которые полагались на измененный код.

Внешние воздействия:

Здесь мы указываем любые внешние источники, которые могут повлиять на эту работу. Полагается ли эта функция на другие команды/API/источники для информации, которая может потенциально повлиять на то, сколько времени потребуется для сборки или тестирования?

Влияние:

Имеет ли это известное, измеримое влияние на команду или бизнес? Это не всегда известно или легко измерить, но для того, чтобы обосновать рефакторинг или оптимизацию, нам нужно иметь эту информацию.

Влияние шаблонов

Результаты не заставили себя ждать.

Мы быстро поняли, что можем обработать примерно в 3 раза больше тикетов за одно часовое совещание по техническому проектированию, чем раньше. Кроме того, обсуждения, которые мы вели на этих совещаниях, были более полезными и эффективными. Мы уделяли время выявлению пограничных случаев, затронутых команд и потенциальных заторов или узких мест в процессе, готовя разработчиков к работе, вместо того чтобы тратить все свое время на попытки понять больше деталей. Мы также заставили себя придерживаться шаблона, в котором мы записывали все эти отзывы в тикет либо в описание, либо в комментарии. Шаблоны были постоянным напоминанием о том, что эти детали важны и что они должны быть представлены и легкодоступны. В некотором смысле эти шаблоны переучили наши мозги на подход «сначала документация» к этим тикетам, гарантируя, что тот, кто схватил тикет, будь то младший разработчик или опытный инженер, будет иметь достаточно информации для написания высококачественного кода.

Далее мы заметили, что наши циклы разработки стали более краткими, наши оценки стали более точными, и мы достигли желанной отметки 100% завершения спринтов гораздо чаще, чем когда-либо прежде. Мы смогли очистить нашу доску почти постоянно. Это не только важно для бизнеса, потому что они получали обновления, когда мы им говорили, что они их получат, но и стало огромным стимулом для уверенности команды, поскольку вы постоянно ставите себя в положение успеха. Наши заинтересованные стороны увидели нашу улучшенную эффективность и пропускную способность и обрели большее доверие к нашей команде и нашему процессу. Они также заметили, что наш код стал более качественным, так как мы смогли больше времени сосредоточиться на реальной проблеме.

Мы с самого начала знали, что это улучшит нашу жизнь как разработчиков, но мы не осознавали, насколько положительно это скажется на наших деловых партнерах.

Ключевые выводы для других команд

Если вы чувствуете, что ваша команда постоянно обременена нехваткой информации, возможно, стоит изучить, может ли вам подойти создание структурированных шаблонов тикетов. Важно отметить, что это требует дополнительного времени разработчика, чтобы наполнить тикеты достаточным количеством деталей для действий. Я считаю, что это оправданные затраты, и в долгосрочной перспективе это приводит к огромной экономии средств, поскольку это значительно улучшает ваши рабочие процессы, но важно отметить, что эти изменения не происходят просто так. Кто-то должен выделить время на проведение исследований и написание высококачественного тикета, и этим кем-то, скорее всего, будет ваша команда разработчиков.

При этом легко увидеть, насколько это может быть огромной победой для команды. Для начала я бы рекомендовал несколько коротких шагов.

Первый, оцените, действительно ли у вас есть проблема. Иногда один или два разработчика испытывают трудности с документацией или передачей знаний, но это не указывает на полномасштабную проблему с вашими тикетами. Возможно, другие вещи, такие как улучшение посадки или документации, могут решить некоторые из этих проблем.

Во-вторых, яЕсли вы обнаружили, что это широко распространенная проблема, требующая решения, следующим шагом будет категоризация типов тикетов, которые вы обычно получаете, и того, какой тип информации требуется в каждом из них. Очевидными кандидатами являются ошибки и функции, однако в зависимости от характера бизнеса вашей компании у вас могут быть другие типы тикетов, которые постоянно проходят через вашу систему и имеют разные потребности. Возможно, ваша команда управляет конвейером ETL, и вам нужно знать, какие входы/выходы влияют на тикеты, связанные с этим. Возможно, ваша команда владеет SDK, и тикеты, связанные с ним, должны обрабатываться особым/приоритетным образом и должны включать в себя то, на какие бизнес-функции может повлиять изменение? Знайте свою команду и ее требования, чтобы вы могли точно определить, какие типы шаблонов требуются.

Следующий,Как только у вас будет вся эта информация, изложите ее в письменном виде в общедоступном месте, к которому у всех будет доступ. Возможно, это будет общий документ или вики-страница, которой управляет и к которой имеет доступ команда, или, возможно, вы даже можете создать шаблоны в самой Jira, заставляя людей их использовать. Независимо от вашего подхода, вам нужно получить поддержку от команды и разработчиков, что означает, что они должны иметь возможность видеть это. Это один из самых важных шагов, потому что этот процесс не пойдет дальше, если у вас не будет 100% поддержки от всех, кто будет писать тикеты. Представьте эти шаблоны своей команде, соберите отзывы, объясните, как, по вашему мнению, этот новый процесс повлияет на вас и ваших заинтересованных лиц. Убедитесь, что всем в команде комфортно с новым процессом.

Последний, вам нужно обеспечить соблюдение этих изменений. Билеты, представленные без достаточной информации, следует немедленно отбрасывать без обсуждения. Важно строго следовать рекомендациям по шаблону, иначе люди всегда найдут причины обойти его. «Эта проблема слишком критична, у меня нет времени ее описывать» — это распространенная жалоба, которую мы получаем. Однако, строго придерживаясь необходимости шаблона и работая с людьми, которые пытаются обойти его, вы в конечном итоге их переубедите.

В Wayfair мы увидели огромные улучшения в процессе работы нашей команды, а также в моральном духе, внеся небольшие изменения, перечисленные выше. Надеюсь, это поможет и вашей команде.