Connect with us

Разработка

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

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

Опубликовано

/

     
     

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

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

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

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

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

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

1

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

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

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

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

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

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

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

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

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

2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3

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

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

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

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

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

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

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

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

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

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

Спасибо!

Теперь редакторы в курсе.