В современных реалиях успешные компании начинают задумываться над тем, чтобы увеличить свою эффективность за счет цифровизации бизнес-процессов. Большинству компаний хватает готовых решений, но часть имеют и желание, и ресурсы для создания собственного цифрового продукта, который будет максимально отвечать их специфике. В этом случае они обращаются к ИТ-компаниям для заказной разработки.
Для кого-то этот опыт становится негативным, нередко можно услышать истории о том, что обговорили результат, требования, бюджет и подписали договор. Но прошло несколько месяцев, а заказчик не понимает, когда он наконец-то получит свой готовый продукт. Что самое страшное: исполнитель тоже не может внятно назвать конкретные сроки.
У этого кейса может быть несколько корневых причин. Здесь мы сфокусируемся на проблеме руководителя со стороны исполнителя, который не понимает, чем заняты его разработчики и что происходит на проекте. Как следствие, он не может транслировать конкретные сроки и цифры, к чему так привык заказчик, который работает в реальном секторе.
Чтобы избежать такой проблемы, мы рекомендуем следующие 4 совета руководителю со стороны исполнителя.
Декомпозиция продукта
Примитивный, однако работающий, как швейцарский нож, совет: разбиваем продукт на эпики, их в свою очередь на User Story, а каждую User Story на набор функциональностей. Такая матрешка дает прозрачность статусов готовности каждого из этапов и всего проекта в целом.
Функциональности же необходимо разбить на этапы (системный анализ, дизайн, backend-разработка, frontend-разработка, QA-тестирование).
При декомпозиции важно «не забывать» сопутствующие задачи, такие как интеграция с внешними модулями, подготовка моковых и тестовых данных, деплоймент в окружения и тому подобное.
Критерии готовности (Definition of Done)
Очень распространенная история, когда разработчик говорит, что функциональность «готова» и руководитель на радостях рапортует заказчику, что сегодня-завтра передаст продукт. Но на самом деле разработчик имел в виду, что он-то фичу сделал, но ее теперь должен проверить другой разработчик, а потом еще ее нужно прогнать через серию тестов. Да и вообще там нужна интеграция с другим модулем, которая делает другая команда, а у них до этого руки еще не дошли.
Поэтому важно зафиксировать критерии готовности и проговорить их с командой. А потом еще быть готовым много-много раз повторять до тех пор, пока вы не будете говорить на одном языке со своей командой. До автоматизма.
Это же правило верно и для коммуникации с заказчиком. Вы должны идентично понимать, что означает критерий готовности.
Ограничивать ожидаемый результат
При постановке задачи важно заранее фиксировать и четко ограничивать ожидаемый результат. Иначе есть риск столкнуться с тем, что ваша команда будет пытаться затаскивать все и сразу. В первую очередь необходимо обговорить, какие функциональности и User Story вы делаете в текущей релизной сборке, а какие — в следующих.
Важно и с заказчиком проговаривать ожидаемый результат, чтобы его ожидания максимально совпадали с реальностью.
Избегать бесконечной работы
Представим, что вы воспользовались предыдущими советами: декомпозировали продукт, определили критерии готовности, ограничили ожидаемый результат, оценили трудоемкость реализации. Разработчик взял фичу, обещал сделать за 3 дня… Прошло уже 5, а он уверяет, что теперь не знает, когда закончит работу, потому что вскрылись новые вводные.
Часто кастомный разрабатываемый ИТ-продукт является сложной системой. Как следствие в процессе разработки возникает реальная необходимость в дополнительных поисках ИТ-решений.
Важно донести до команды, что поиск новых ИТ-решений и дополнительные доработки для достижения целей проекта допустимы, однако, при этом недопустимо уходить в бесконечный цикл работ. То есть все дополнительные активности должны выполняться в рамках других отдельных задач.
Применение этих 4 советов значительно уменьшит неопределенность на проекте, что станет залогом продуктивного взаимоотношения между заказчиком и исполнителем.
Источник: РБК Компании
Автор: Александр Хван (Release Manager TAGES)