Читать «Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов» онлайн - страница 16

Такой разный контент

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

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

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

6 – Как разрабатывать

Постоянная декомпозиция

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

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

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

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

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

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

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

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

Усмирение демонов

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

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

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