Задача сделана и нет одновременно – или как мы устраняли квантовую неопределённость на проектах

Личный опыт наведения порядка в проектах по заказной разработке.

На заре создания нашей компании в качестве системы управления проектами мы выбрали Redmine. Сакрального смысла в таком выборе не было: один из основателей, работавший в ИТ-гиганте, притащил из своего корпоративного мира best practice в виде использования этой системы.

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

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

К слову и для понимания исходного состояния: в начале мы использовали только одну сущность – Задача (трекер task), для которой было предусмотрено всего пять статусов: новая, в работе, выполнена, отменена, приостановлена.

Сейчас даже стыдно от такой наивности. Самому удивительно, но тогда этого хватало.

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

Со временем проектов стало больше, они усложнялись и удлинялись. Вместе с этим рос коллектив, появлялись новые роли в команде. Вслед за изменениями мы настраивали и Redmine.

Хотя «настраивали» – это громко сказано. В основном это сводилось к добавлению новых статусов задач, переходов между ними и пользовательских ролей. Так, например, в статусной модели трекера task появились «на тестировании», «протестировано» и «на приёмке».

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

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

Из-за нагромождения и плохой продуманности таких изменений очень скоро узнать из Redmine о статусе проектов нельзя было ровным счётом ничего.

Например, статус “на тестировании” не давал чёткого понимания, тестируется ли задача в данный момент или только ожидает своей очереди на проверку. А то, что задача всегда была закреплена за одним человеком, вводило лишь путаницу - зачастую нельзя было однозначно сказать, кто же ей занимается именно сейчас.

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

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

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

Ситуация осложнялась ещё и тем, что у нас были и есть разные типы проектов: где-то мы реализуем проект полностью «под ключ», где-то работаем с готовыми требованиями, а где-то занимается только сопровождением. Одни и те же статусы задач на разных проектах означали разное их состояние! Были даже шутки про задачи Шрёдингера, которые одновременно сделаны и нет. Смех сквозь слёзы.

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

Осознав проблему, мы поставили себе цель изменить производственный процесс и сделать из Redmine реальный инструмент управления проектной деятельностью, а не просто todo-list. Чтобы этого добиться мы наметили следующие задачи и требования:

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

Далее о том, как мы воплощали намеченное в жизнь.

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

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

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

Нарисовав блок-схему, мы сразу почувствовали два сильных положительных эффекта:

1. Получили хорошо представленный и поэтому понятный всем участникам процесс разработки. Все ребята стали однозначно и единообразно воспринимать значения статусов и корректно пользоваться матрицей переходов между ними. Так мы добились прозрачности процесса изнутри.

2. Увидели «напряжённые узлы» – этапы, где процесс слишком сложный и неэффективный. Так, например, мы сообразили, что можно снять с и без того загруженных ведущих разработчиков функции контроля оценок задач, заменив их покером-планированием.

Развязав такие «узлы» в процессе, мы принялись за настройку Redmine: удалили устаревшие статусы, поменяли логику оставшихся и добавили новые в соответствии с изменённой схемой.

Главным нововведением были новые трекеры, логику которых мы очень глубоко проработали. Так у нас кроме task появились epic, test, bug и checklist.

Трекер epic используется для блока работ, отражающих то или иное функциональное требование. Задача с трекером epic включает в себя всё, что связано с реализацией данного функционального требования, начиная от оценки и заканчивая приёмкой. Грубо говоря, epic – это контейнер для всех задач других трекеров.

Трекеры test и checklist используются для задач тестирования. При этом последний, как можно понять из названия, содержит чек-лист того, что требуется протестировать в рамках реализации epic.

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

Кроме того, мы стали использовать такую сущность Redmine, как «Версия». С помощью версий мы объединяем эпики, соответствующие законченной части проекта или этапу работ.

Всю эту красоту мы приправили автоматизацией. Например, запретили создание задач без привязки к эпику, добавили автоматическое создание подзадачи на тестирование при создании эпика, добавили автоматическое заполнение полей дочерних задач, созданных внутри эпика, реализовали автоматическую привязку Merge Request в GitLab к задаче в Redmine.

Также мы добавили ряд обязательных полей при смене статусов задач: Срок завершения, Оценка временных затрат, Согласованные часы, Баг от заказчика и Закрыта в срок. Данные из этих полей мы используем для анализа проектной деятельности и принятия управленческих решений.

На этом этапе мы добились следующих положительных эффектов:

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

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

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

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

Еженедельно мы докручивали процесс и Redmine, выпуская обновления и проводя разъяснительные планёрки.

Спустя месяц ситуация стабилизировалась. Процесс заработал, и мы оказались в Нирване.

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

И ещё один важный вывод, который хочется оставить себе в виде татуировки: улучшать процессы и внедрять нововведения лучше постепенно, по мере необходимости и с глубокой проработкой.

Завершив описанное, мы вошли во вкус. В наших ближайших планах:

На VC ещё есть ретрограды, которые используют Redmine?