Как организовать работу разработчиков, сохранить нервы и повысить эффективность

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

В чём проблема

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

Результат:

• • задачи не выполняются вовремя;
  • отсутствует понимание общей цели и плана её реализации;
  • в коллективе царит угнетённое настроение.

Что сделали мы?

Мы решили внедрить Scrum-методологию. Scrum — это один из гибких способов разработки ПО, относящихся к семейству Agile. В общем виде это выглядит так: у тебя и коллег есть чётко заданный список задач (бэклог), самые приоритетные из которых нужно запланировать на ближайший спринт и успеть выполнить к заданному сроку (демо). Для каждой задачи назначается ответственный исполнитель и выделяется конкретное время.

О чём это я (scrum-терминология):

Бэклог — общий список задач, ранжированных по приоритету. Их бывает три типа:

• бэклог руководителя — перечень функций, необходимых для достижения ближайших бизнес-целей;
• бэклог менеджера — проработанный и детализированный список задач с пониманием технических проблем реализации;
• бэклог команды программистов — запланированные на ближайшие 1–2 спринта реальные к исполнению задачи.

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

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

Демо — подведение итогов прошедшего спринта.

Тикеты — отдельные задачи; выписываются на отдельные листочки с количеством времени на его выполнение.

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

Плановый коэффициент — число от 0 до 1, указывающее на расчётную вероятность выполнения плана в срок.

Как это выглядит на практике

•  

На практике мы используем не «чистокровный» Scrum — мы адаптировали методологию под свои потребности. И вот как это работает в нашей команде.

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

Все задачи распределяются среди разработчиков, для каждой определяется количество часов на выполнение — всё это фиксируется в электронной таблице. Для срочных задач, которые невозможно запланировать заранее, отводятся специальные «часы на саппорт», в это время выполняются задачи из серии «я чё-то нажала и всё исчезло».

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

   

Три колонки на доске — это план, задачи в работе и готовые задачи каждого из продуктов (UMI.CMS и 1С-UMI).  Параллельно идут два спринта по обоим продуктам. Положение тикетов показывает статус спринта, и весь коллектив наглядно видит, что происходит у разработчиков.

Со следующего дня после планирования начинается спринт. Конец спринта тоже заранее известен, и на следующий день после него все тикеты должны быть закрыты. Плановый коэффициент в UMI довольно высокий — 0,8. Это значит, что наши оценки на 80% верны, а адекватно оценённые задачи чаще бывают выполнены в срок.

Запрещается добавлять новые задачи в середине спринта, кроме ЧП. Ежедневные митинги поддерживают рабочий темп. В графиках (листах А4 справа на фото) ежедневно фиксируются остатки неготовых тикетов. Все тикеты — общая цель команды, а не персональная. При этом, метод Scrum отлично выявляет, кто в команде — «слабое звено».

Что в результате

Уже больше года Scrum помогает нам плавно, без нервов и факапов, развивать  продукты и добавлять новые функции в UMI.CMS и 1С-UMI. Благодаря тому, что всё спланировано заранее, мы не гонимся за скоростью, не откладываем на последний момент и больше внимания уделяем качеству работы. Каждый участник команды знает, за что он отвечает, как движется работа у коллег и спринт в целом. Благодаря этому в коллективе спокойная атмосфера и работать намного проще.