Все знают выражение: плохое ТЗ – плохой результат. За время работы интернет-маркетологом в сфере e-commerce, при постановке задач, я в половине случаев сталкивалась с проблемой коммуникации с разработчиками. Это приводило к частым переделкам и раздражению с обеих сторон. Зато этот опыт стал для меня бесценным уроком.
От правильно выстроенной коммуникации зависит эффективность всей команды. Так, что же мешает построить «здоровую» коммуникацию между продактом / маркетингом и разработкой? Это недопонимание!
Какие чаще всего возникают недопонимания:
- разработчики не понимают задачи бизнеса.
Перед началом выполнения задач, объясните какие проблемы они решают, какие ожидания у бизнеса от реализации.
- задачи поставлены нечётко.
Составьте Road map и обсудите его с командой. Это поможет наладить взаимодействие команды и обозначить приоритезацию задач.
- заказчик и разработчик говорят на разных языках.
Каждый участник команды силён в своей сфере, поэтому может использовать терминологию непонятную для другой стороны. В этом случае нужно обязательно уточнять детали, чтобы избежать рассинхрона.
Правильно составленное ТЗ может решить эти недопонимания.
Но сначала рассмотрим основные ошибки при составлении ТЗ
Заказчик не погружён
Нельзя поставить чёткие задачи, пока заказчик не разобрался со сценариями использования и функционалом фичи. А до тех пор это будет: сделай то, не знаю что.
Ответственные не назначены
Если не объяснили чётко каждому участнику разработки продукта в чем его роль и какую часть продукта он разрабатывает, готовьтесь играть в пинбол.
Задача не декомпозирована
Если большая задача не разбита на подзадачи и нет приоритезации, то разработчик это сделает за вас. Результат вряд ли вас обрадует.
Система контроля отсутствует
Искать баг в задеплоеной версии то ещё удовольствие.
Основные рекомендации по составлению ТЗ для разработчика:
1. Погрузитесь в проект. Вы точно должны понимать, что вы делаете, зачем и как.
2. Описывайте задачи максимально подробно с приведением ссылок на уже реализованные похожие проекты, делайте прототипы, дайте доступ к расчётам.
3. Указывайте чёткие сроки сдачи выполнения задач. Закладывайте +20% времени от первоначальной оценки. Это поможет избежать риска просрочить дедлайн.
4. Назначайте ответственных на каждую задачу и убедитесь, что все члены команды поняли свою роль в проекте.
5. Определитесь с платформой для удобного взаимодействия. Всё общение по проекту стоит вести в одном месте. Это поможет упорядочить все обсуждения, ничего не потеряется и информацию будет легко найти.
Используйте, например Youtrack или Worksection.
6. Разбивайте большие задачи на подзадачи и не забывайте о приоритезации. Используйте фреймворки типа: RICE, КАНО.
7. Обозначьте контрольные точки в проекте. Такие точки нужны для проверки, идёт ли команда по заданному курсу. Если что-то пошло не так, то эти проверки помогут оперативно исправиться.
Например, можно использовать систему контроля версий Git. При достижении контрольной точки, разработчик зальёт результат своей работы на сервер. А заказчик протестирует новую часть системы и всё, что она могла затронуть. Если всё ок, идём дальше. Если нет, отдаем на доработку.
Любой проект требует структурированной коммуникации и чёткого понимания между заказчиком и исполнителем. Нечёткие задачи и требования могут затянуть любой проект, задерживая развитие продукта и увеличивая затраты на разработку.
Ставьте чёткие и логичные задачи, и ваша команда достигнет успеха.