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

Все знают типологию менеджмента PAEI, которую предложил Ицхак Адизес: – Producing – Administrating – Entrepreneuring – Integrating

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

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

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

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

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

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

Олег Чулаков

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

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

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

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

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

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

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

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

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

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