Как понять, чем заняты ваши разработчики и что происходит на проекте

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

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

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

Чтобы избежать такой проблемы, мы рекомендуем следующие 4 совета руководителю со стороны исполнителя.

Декомпозиция продукта

Примитивный, однако работающий, как швейцарский нож, совет: разбиваем продукт на эпики, их в свою очередь на User Story, а каждую User Story на набор функциональностей. Такая матрешка дает прозрачность статусов готовности каждого из этапов и всего проекта в целом. 

Функциональности же необходимо разбить на этапы (системный анализ, дизайн, backend-разработка, frontend-разработка, QA-тестирование).

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

Критерии готовности (Definition of Done)

Очень распространенная история, когда разработчик говорит, что функциональность «готова» и руководитель на радостях рапортует заказчику, что сегодня-завтра передаст продукт. Но на самом деле разработчик имел в виду, что он-то фичу сделал, но ее теперь должен проверить другой разработчик, а потом еще ее нужно прогнать через серию тестов. Да и вообще там нужна интеграция с другим модулем, которая делает другая команда, а у них до этого руки еще не дошли.

Поэтому важно зафиксировать критерии готовности и проговорить их с командой. А потом еще быть готовым много-много раз повторять до тех пор, пока вы не будете говорить на одном языке со своей командой. До автоматизма.

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

Ограничивать ожидаемый результат

При постановке задачи важно заранее фиксировать и четко ограничивать ожидаемый результат. Иначе есть риск столкнуться с тем, что ваша команда будет пытаться затаскивать все и сразу. В первую очередь необходимо обговорить, какие функциональности и User Story вы делаете в текущей релизной сборке, а какие — в следующих. 

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

Избегать бесконечной работы

Представим, что вы воспользовались предыдущими советами: декомпозировали продукт, определили критерии готовности, ограничили ожидаемый результат, оценили трудоемкость реализации. Разработчик взял фичу, обещал сделать за 3 дня… Прошло уже 5, а он уверяет, что теперь не знает, когда закончит работу, потому что вскрылись новые вводные.

Часто кастомный разрабатываемый ИТ-продукт является сложной системой. Как следствие в процессе разработки возникает реальная необходимость в дополнительных поисках ИТ-решений. 

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

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