Недосказанность всегда против вас
После подписания договора и назначения установочной встречи ваша основная задача – договориться, как именно исполнитель будет создавать продукт.
Самая большая ошибка, которую здесь можно совершить, – увериться в том, что вас понимают на 100%. Даже если вам так кажется, это всё равно не так. Просто при передаче информации другому человеку она проходит через несколько коммуникационных этапов – и смысл постепенно теряется.
Потери информации в процессе передачи сообщения.
Автор теории – Предраг Мицич.
В случае водопадной разработки требования к результатам каждого этапа должны быть подробно описаны. Переспросите исполнителя, как он понял требования и какие задачи собирается выполнять. Это может показаться невероятным, но после такого упражнения вы сделаете немало новых открытий. Во-первых, в сфере разработки есть понятия, которые часто все трактуют по-своему. А во-вторых, все, что очевидно для вас – не очевидно для других.
Чем тщательнее вы проговариваете требования – тем лучше. А в идеале не только проговаривать, но и показывать на примерах, рисунках, схемах, таблицах – где угодно. Главное – донести суть и проверить, насколько правильно она понята. Только после того, как вы убедились в правильном понимании исполнителем всех ваших требований – отпускайте функционал в дальнейшую проработку.
В случае гибкой разработки все иначе. Рассмотрим 3 инструмента, помогающие в планировании при гибкой разработке:
– Use Case
– Нагляднее других инструментов помогает описать функционал, но заковывает в «рамки креативности» автора.
– User Story
– Позволяет планировать релизы проще, чем в остальных методах, но увеличивается риск разрастания ошибочных гипотез.
– Job Story
– Максимально точно помогает сосредоточиться на выполнении задач пользователей, но не имеет иерархии и сложно выявить зависимости.
Выбирайте инструмент исходя из особенностей команды и проекта. Если работаете только с аккаунт-менеджером и не общаетесь с финальными исполнителями – следует выбрать диаграммы вариантов использования. Но в случае участия всей команды выбирайте более гибкую методику – получите массу продуктовых идей, и тем самым добьётесь большей объективности в гипотезах.
Во время планирования релиза с командой откройте список «болей пользователей», которые должен закрыть ваш продукт. Каждый участник встречи предлагает свой вариант решения, а вы заносите в таблицу. В процессе генерации идей важно не критиковать решения, а собрать максимальное их количество. Я люблю использовать онлайн-таблицы Google Sheets для подобных задач.
После того, как идеи сгенерированы – проставьте вместе с командой оценки важности для пользователей и бизнеса, а также оценки сложности реализации. Затем проранжируйте решения по методу скоринга, как в первой главе при составлении задания на разработку.
В результате у вас получится продуктовый бэклог в виде онлайн-таблицы, отражающий:
– Боль/проблему пользователя;
– описание функционала, который эту проблему решает (и как решает);
– Важность для пользователя;
– Важность для бизнеса;
– Сложность реализации;
– Совокупный балл приоритета;
– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).
Из верхней части списка выделите решения, которые войдут в релиз. В процессе разработки потребуется декомпозировать каждую функциональность на более мелкие части и делить по спринтам. Об этом в следующей главе.
Вовлечённость
Вторая проблема, с которой вы можете столкнуться на этапе планирования релиза, – отсутствие вовлечённости. Это может происходить из-за того, что вы не даёте разработчику возможность придумывать идеи, а поручаете только выполнять их.
У вас может быть экспертное мнение в своей профессиональной области, но во время разработки нового функционала это всего лишь гипотезы.
Точно такие же гипотезы (а может и лучше), могут возникнуть и у исполнителя. Дайте ему возможность поучаствовать в процессе формирования идей – и получите вовлечённых помощников.
Заподозрив другие причины отсутствия искорки в глазах, – такие как личные проблемы, полное непонимание происходящего или незаинтересованность в выполнении проекта, – как можно скорее выясните, в чём дело.
Отсутствие понимания и личные проблемы – скорее всего, временное влияние, которое можно исправить, а вот с категорической незаинтересованностью разобраться уже гораздо сложнее. Поговорите с руководителем исполнителя, если он есть. Если ситуация не изменится – переходите к обсуждению расторжения договора.
Исполнитель может быть вовлечённым и профессиональным, но без вас он проект не завершит. Обязательно договоритесь, насколько часто вы будете встречаться для обсуждения статуса и деталей задач.
Для средних по длительности проектов достаточно двух встреч на спринт (от недели до месяца): На первой вы обсуждаете, что уже сделано, что и почему не сделано и план на неделю, а на второй собираете список из «почему не сделано» и ищете закономерные возможности для устранения закономерных проблем. Если вы лично не можете принимать участие в подобных обсуждениях, найдите помощника, который будет защищать ваши интересы как заказчика, но никогда не пускайте всё на самотёк.
Тараканы
Помните, мы составляли список «страхов» в запросе на разработку? Откройте его во время планирования задач с исполнителем и ещё раз обсудите ваши действия в том случае, если страхи оправдаются. Пусть подрядчик помнит, чтó вас беспокоит. Но также спросите и о его страхах. Скорее всего, среди них будут:
– микроменеджмент с вашей стороны;
– отсутствие вовлечённости (противоположная проблема);
– невыполнение обещаний (обычно под этим подразумевается непредоставление материалов в срок или затягивание согласований).
Заранее предпримите все необходимые меры, чтобы страхи исполнителя не оправдались. Как сделать это с микроменеджментом, я расскажу в следующей главе, а решить проблемы отсутствия вашей вовлечённости или невыполнения обещаний вы должны самостоятельно.
Иногда во время планирования релиза обсуждение отдельных функций может затягиваться. Если вы выбиваетесь из временного графика, значит функционал слишком сложный. Его нужно декомпозировать и сформулировать отдельные решения.
Если у вас есть подозрения, что задачи определённого типа представляют серьёзную трудность, желательно подключить к их решению отдельных исполнителей. Такие подозрения могут появиться когда угодно: во время планирования, разработки или даже приёмки задач. Причём за выполнение этих задач можете отвечать как вы, так и подрядчик.
Я часто привожу в пример создание контента, поскольку тематика очень специфическая. Например, у подрядчика есть копирайтер, который устраивает 99% его заказчиков, а у вас настолько узкоспециализированная тематика, что невозможно было догадаться о требованиях к контенту, пока вы не начали обсуждать детали. В этом случае, вместо того чтобы испытывать подрядчика на прочность и добиваться от него невозможного, просто найдите исполнителя, у которого есть подтверждённая экспертиза в необходимой сфере.
Заметки и истории
Стартапер против архитектора
Все знают типологию менеджмента PAEI, которую предложил Ицхак Адизес: – Producing – Administrating – Entrepreneuring – IntegratingОлег Чулаков
На более высоком уровне, когда мы говорим о стратегии, я бы выделил два типа руководителей: 1. Стартапер
2. Архитектор
Допустим, вы планируете запустить новое бизнес-направление.
Что делает архитектор? Архитектор старается все очень основательно продумать. Взвесить все «за» и «против». Понять, где скрыта куча подводных камней, выявить и решить все потенциальные проблемы заранее. Потом, вероятно, он отложит запуск, так как еще недостаточно «вставьте любое слово».
Как поступает стартапер? Он начинает с маленького кусочка и тестирует новое направление на небольшой аудитории, возможно, в закрытом режиме. Получает обратную связь и принимает решение – развивать гипотезу или переключаться на другую.
Будьте на 80% стартапером и на 20% архитектором.
Такой разный контент
Когда я руководил веб-студией, у нас было много заказов на корпоративные сайты. Одним из проектов был сайт крупной фармацевтической компании. Со стороны заказчика с нами работал глубоко вовлечённый менеджер по маркетингу. Проект шёл по плану, пока не добрались до работ с контентом…
По договору предоставление исходного контента было на стороне заказчика, с условием, что для финальных текстов мы привлечём копирайтера с опытом в фармацевтической тематике. Такого копирайтера мы нашли. Когда пришло время, он переделал текст согласно новой информационной структуре. Затем мы наполнили сайт и ожидали принятия работ. Ожидали и ожидали… Но заказчик не принимал работу и постоянно вносил правки в текст. Правок было настолько много, что на полное исправление ушло полгода.
Как оказалось, копирайтер имел опыт в фармацевтике, но ничего не знал про фармацевтических операторов (склады, таможня, контроль качества и т.п.). Этой задержки могло бы и не быть в случае предварительного детального обсуждения задачи и чётко прописанных критериев приёмки. И хотя долгий период ожидания несколько накалил между нами отношения, проект всё равно завершился успешно.