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

В результате у вас получится продуктовый бэклог в виде онлайн-таблицы, отражающий:

– Боль/проблему пользователя;

– описание функционала, который эту проблему решает (и как решает);

– Важность для пользователя;

– Важность для бизнеса;

– Сложность реализации;

– Совокупный балл приоритета;

– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).

Из верхней части списка выделите решения, которые войдут в релиз. В процессе разработки потребуется декомпозировать каждую функциональность на более мелкие части и делить по спринтам. Об этом в следующей главе.

Вовлечённость

Вторая проблема, с которой вы можете столкнуться на этапе планирования релиза, – отсутствие вовлечённости. Это может происходить из-за того, что вы не даёте разработчику возможность придумывать идеи, а поручаете только выполнять их.

У вас может быть экспертное мнение в своей профессиональной области, но во время разработки нового функционала это всего лишь гипотезы.

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

Заподозрив другие причины отсутствия искорки в глазах, – такие как личные проблемы, полное непонимание происходящего или незаинтересованность в выполнении проекта, – как можно скорее выясните, в чём дело.

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

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

Для средних по длительности проектов достаточно двух встреч на спринт (от недели до месяца): На первой вы обсуждаете, что уже сделано, что и почему не сделано и план на неделю, а на второй собираете список из «почему не сделано» и ищете закономерные возможности для устранения закономерных проблем. Если вы лично не можете принимать участие в подобных обсуждениях, найдите помощника, который будет защищать ваши интересы как заказчика, но никогда не пускайте всё на самотёк.

Тараканы

Помните, мы составляли список «страхов» в запросе на разработку? Откройте его во время планирования задач с исполнителем и ещё раз обсудите ваши действия в том случае, если страхи оправдаются. Пусть подрядчик помнит, чтó вас беспокоит. Но также спросите и о его страхах. Скорее всего, среди них будут:

– микроменеджмент с вашей стороны;

– отсутствие вовлечённости (противоположная проблема);

– невыполнение обещаний (обычно под этим подразумевается непредоставление материалов в срок или затягивание согласований).

Заранее предпримите все необходимые меры, чтобы страхи исполнителя не оправдались. Как сделать это с микроменеджментом, я расскажу в следующей главе, а решить проблемы отсутствия вашей вовлечённости или невыполнения обещаний вы должны самостоятельно.

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

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

Я часто привожу в пример создание контента, поскольку тематика очень специфическая. Например, у подрядчика есть копирайтер, который устраивает 99% его заказчиков, а у вас настолько узкоспециализированная тематика, что невозможно было догадаться о требованиях к контенту, пока вы не начали обсуждать детали. В этом случае, вместо того чтобы испытывать подрядчика на прочность и добиваться от него невозможного, просто найдите исполнителя, у которого есть подтверждённая экспертиза в необходимой сфере.

Заметки и истории

Стартапер против архитектора

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

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

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

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

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

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