Это не разработчики тормозят, это процесс так устроен

[pullquote align=right]
Джасти Джексон – менеджер по продукту в Sprintly
[/pullquote]»Почему мы не запустились на прошлой неделе?»

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

У нас в Sprintly много данных о циклах разработки. Мы отслеживаем, как много времени занимают разные типы заданий (сюжеты, тесты, баги) и разные объемы (S, M, L, XL).

Какие закономерности мы обнаружили?

Первое: разработчики всегда работают примерно одно и то же время. Наши данные показывают, что продолжительность цикла почти всегда одинакова: 75% всех наших тикетов в системе делаются за порядка 175 часов.

Второе: вариативность во времени возникает до того, как тикет был начат (на схеме: Someday to Backlog).Это тот уровень, когда управляющие начинают определять задания и расставлять приоритеты. В мире Kanban это обычно называется время реакции (время между созданием тикета и определением его приоритета). Куча времени теряется на этот этапе.

Третье: оказывается, что команда теряет много времени на переход от «сделано» до «прошло тесты и готово к использованию» (на схеме: Completed to Accepted).

Вам кажется, что команда работает недостаточно быстро? Возможно, разработчики не виноваты.

Что на самом деле замедляет разработку?

Если это не разработчики, то что замедляет процесс? Подсказка: это ваш процесс.

Неясные требования

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

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

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

Мы сделали форму в стиле Mad Libs для создания пользовательских историй.

Когда вы делаете что-то в Sprintly, вам нужно ввести это в таком виде: «Поскольку ___, я хочу ___, поэтому ___». Вы не можете добавить функцию без заполнения этой формы, и это заставляет вас делать это как следует, — Даррен Роган в подкасте Hack and Heckle.

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

Изменение требований

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

Вот эта история с Hacker News приводит хорошую метафору для описания ситуации:

Мы: «Итак, мы только что положили крышу и оштукатурили стены!»
Они: «Отлично, мы хотим, чтобы стен не было».

Это симптом непродуманности функций перед помещением их в очередь на выполнение.

Первый способ избежать изменения требований в середине процесса — создавать интерактивные макеты перед началом реальной разработки:

Мы могли быть быстрее, если бы все было тщательно смоделировано. Иногда мы недостаточно хорошо изучаем процесс пользовательского взаимодействия, поэтому нам приходится переделывать его уже после реализации,» — Тобин Харрис, директор Pocketworks.

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

Другой путь избежать изменения требований — предсказывать прогресс. В Sprintly у нас есть визуализация того, как много дней еще осталось до конца разработки.

При добавлении новых задач сразу видно, насколько отдаляется срок выхода.

Переключение контекста

Последняя загвоздка — переключение контекста. Это может принимать разные формы:

1. Разработчик сделал задание A на 50%, а вы подходите к нему и просите переключиться на задание Б.
2. Разработчик наполовину завершил задание А, а вы подходите к нему и просите сделать также задание Б.

Отличный пример — наш ведущий разработчик, который делает много отчетов, планирует разработку, ходит на встречи и решает неотложные проблемы.

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

Очевидно, именно природа должности ведущего разработчика влияет на время выполнения заданий.

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

Джоель Сполски пишет именно об этом в своей посте про переключение контекста:

Штука в том, что нельзя позволять людям работать более, чем над одной задачей одновременно. Убедитесь, что они об этом знают. Хороший менеджер берет на себя ответственность за удаление препятствий к тому, чтобы люди могли сконцентрироваться на одной задаче и завершить ее. Когда возникает что-то срочное, подумайте: может быть вы сможете решить проблему самостоятельно, не отвлекая программиста, погруженного с головой в проект.

Будьте ответственны

Задача менеджера — создать среду, в которой программист сможет успешно работать. До того, как скинуть вину на разработчика, посмотрите на себя.

Вот вещи, которые помогут вам понять, не вы ли тормозите команду:

1. Помогите команде понять суть — поработайте над тем, чтобы команда сформировала понимание того, как сделать жизнь пользователей лучше. Определите четко то, в чем нуждаются пользователи. Важна вовлеченность разработчиков. Их заинтересованность может значительно повысить скорость.
2. Формулируйте пользовательские запросы верно — используйте mad-lib или шаблон для каждого задания. Разработчики должны иметь право отказаться от выполнения плохо описанного задания.
3. Снизьте издержки на смену контекстов — не беспокойте разработчиков! Перед тем, как прислать им емэйл или сделать запрос, оцените, как это скажется на их продуктивности.

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