Политика в области качества зачастую рождается как «работа над ошибками», которую команда проводит на основе собственного опыта или же для того, чтобы не повторять чужие типичные ошибки.
Рассмотрим такие ошибки на примере внутреннего проекта, с которым наша компания работала много лет назад, еще на этапе своего раннего развития.
С чего все началось
Проект был давно запущен, фронт работы известен и распланирован на крупные и мелкие спринты. К одной из значимых для компании дат был поставлен жесткий дедлайн – необходимо было реализовать важный функционал, на котором были завязаны задачи разных подразделений.
Обычно команда работала в спокойном режиме, состав постоянно менялся – к его реализации по возможности подключались временно освободившиеся с коммерческих проектов сотрудники. Так и в тот день команда разбрелась по таск-трекеру и медленно, но верно стала закрывать текущие задачи.
Утро не предвещало никаких проблем, пока в чат не пришло сообщение: «Ребят, у нас проблемы, мы не успеем выкатить релиз вовремя». Когда поняли, что дедлайн сорван, срочно подключили специалиста, который должен был помочь разобрать ситуацию и выяснить, что пошло не так.
Что удалось выяснить
Вводные данные: Релиз предполагал двухнедельный спринт. Команда состояла из ПМа, который подключался лишь изредка, трех разработчиков и одного QA. Планируемая оценка – 150 часов с учетом отвлечения специалистов на другие проекты.
Исследование показало:
- К середине первой недели спринта — при передаче проекта от одного ПМа к другому — забыли объяснить часть логики реализации фичи. Road map давно не актуализировался, да и описание задач в имеющемся документе было недостаточным. Когда вспомнили про эту фичу, что произошло только к середине второй недели спринта, это добавило еще 60 часов разработки и ретеста.
- В конце первой недели спринта от проекта отвлекли самого осведомленного разработчика и подключили нового. Погружение для него не провели. В конце второй недели главный разработчик возвращается на проект и переписывает код новичка. Результат — еще 40 часов разработки.
- При смене QA-специалиста также выяснилось, что документацию на том внутреннем проекте не вели. В итоге новый QA затратил еще 25 часов, чтобы разобраться в логике.
Наши выводы
Вместо 150 часов разработки проект потребовал 275 часов реализации и вышел из запланированных двух недель, бюджет превышен в два раза. И это были только самые очевидные проблемы, которые обнаружились на проекте.
Как этого избежать? Рекомендациями поделились специалисты нашей службы качества. Итак, в этом случае необходимо:
- разработать и согласовать регламент передачи проекта,
- закрепить ответственных специалистов за внутренними проектами, которые будут больше всех осведомлены на проекте,
- внедрить шаблон постановки задач, который никогда не помешает, а только упростит работу,
- закрепить обязательный минимум по документированию, в том числе документ по погружению новых специалистов.
Очень часто мы можем сказать, что «проект простой, зачем там что-то усложнять, быстрее сделать, чем соблюдать правила и стандарты». В большинстве случаев такой проект вряд ли закончится успешно. Минимальные принципы и стандарты, от которых не стоит отступать, должны быть всегда, даже на внутренних проектах компании.
К каким выводам мы еще пришли:
- Даже в самом простом проекте нужно работать с ожиданиями заказчика, даже если заказчик ваша же компания и формировать на основе этого требования.
- Внедрение инженерных практик (стандарты написания кода, проведение Code Review и другие) потребует времени, но в дальнейшем сократит время на поддержку.
- Все лучшие практики scrum: проведение демо, дейли и ретроспективы важно адаптировать под задачи конкретного проекта и внутреннюю культуру разработки. О последней мы подробно рассказывали здесь.
О том, что нам помогает избегать рисков на коммерческих проектах, рассказывали в другой нашей статье.