Дмитрий Ершов - Без ТЗ - Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов

На более высоком уровне, когда мы говорим о стратегии, я бы выделил два типа руководителей: 1. Стартапер

2. Архитектор

Допустим, вы планируете запустить новое бизнес-направление.

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

Как поступает стартапер? Он начинает с маленького кусочка и тестирует новое направление на небольшой аудитории, возможно, в закрытом режиме. Получает обратную связь и принимает решение – развивать гипотезу или переключаться на другую.

Будьте на 80% стартапером и на 20% архитектором.

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

По договору предоставление исходного контента было на стороне заказчика, с условием, что для финальных текстов мы привлечём копирайтера с опытом в фармацевтической тематике. Такого копирайтера мы нашли. Когда пришло время, он переделал текст согласно новой информационной структуре. Затем мы наполнили сайт и ожидали принятия работ. Ожидали и ожидали… Но заказчик не принимал работу и постоянно вносил правки в текст. Правок было настолько много, что на полное исправление ушло полгода.

Как оказалось, копирайтер имел опыт в фармацевтике, но ничего не знал про фармацевтических операторов (склады, таможня, контроль качества и т.п.). Этой задержки могло бы и не быть в случае предварительного детального обсуждения задачи и чётко прописанных критериев приёмки. И хотя долгий период ожидания несколько накалил между нами отношения, проект всё равно завершился успешно.

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

– Use Case: детализация вариантов использования. (Например, описание возможных вариантов использования во время заполнения заявки на получение услуги).

– User Story: разбор отдельных историй на части. (Например, описание истории перехода от заполнения заявки к получению услуги).

– Job Story: дробление крупного контекста на мелкие контексты. (Например, описание переключения от контекста заполнения заявки к контексту получения услуги)

Как видите, степень свободы в реализации решений зависит от выбора фреймворка. Методика приоритизации задач на спринт – аналогичная той, что и для приоритизации функционала в релизе.

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

Вертикальная декомпозиция. Источник – https://creativecommons.org

Я предпочитаю не углубляться в подробности реализации задач, если только разработчики сами этого не попросят.

Допустим, план на спринт готов, критерии приемки чётко сформулированы и команда приступила к разработке. Обсудим несколько базовых правил, чтобы всё шло так, как должно.

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

Если вы не можете избавиться от мысли, что ваше решение задачи самое лучшее и других вариантов быть не может, грамотный исполнитель предложит провести A/B-тест. Зафиксируйте ваше решение в отдельной таблице работы с гипотезами и двигайтесь дальше.

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