Вторая часть с моими ошибками, первая тут. 

Напомню, что я владелец продукта в команде, состоящей исключительно из разработчиков, и мы делаем IT-платформу для управления партнерскими сетями АЗС. 

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

Набрать 8 человек, которые совсем не могут заменять друг друга, без тестировщика, а сначала еще и без аналитика? Казалось бы, я сошла с ума и решила потопить продукт. 

На деле – мне нужно сделать 6 разных групп сервисов, для каждого из них уже есть «the best practice», которые легко и быстро разворачиваются, рынок опытных разработчиков велик. 

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

Что это для команды? На уровне старта — очень много разных компетенций, которыми они могут делиться друг с другом, возможность для каждой фичи использовать максимально быстрое решение, и самое главное – они учатся чему-то новому постоянно, а это, согласитесь, интересно даже для senior. (По крайней мере моя команда разработки разделяет эти принципы).

Во время проверки бизнес-гипотез команда разработки притирается друг к другу и со временем начинает проверять технические гипотезы внутри себя, таким образом, в спорах вырисовывается целевая архитектура платформы которую создала КОМАНДА, а не один человек — архитектор. «Всея архитектор» человек, на мой взгляд, бесполезный, дорогой и их не бывает:)  Когда команда имеет равную ответственность, продукт становится общим детищем, за него болеют все, перекладывать ответственность уже не хочется. Вот таким тернистым путем команда растет, принимает решения, КАК делать продукт дальше, компетенции расширяются, появляются взаимозаменяемость и самоорганизованность. Мы пока не прошли этот путь, но рано или поздно пройдем. Конечно, сейчас мы расширяем команду на выделенного тестировщика, но на старте, команда вполне способна справиться с этой функцией сама. 

Да, проще взять 6 java-разработчиков и вот они уже сразу взаимозаменяемы, но быстро с нуля они не сделают рабочий продукт, и будут очень сильно ограничены своими компетенциями.

Кстати, быть владельцем IT — продукта без опыта работы в том самом IT,  к примеру разрабом, системным аналитиком или консультантом (кем угодно, кроме руководителей проектов) крайне трудно, и даже если у вас будет гуру  архитектор — это будет его продукт, не ваш. Тут можно и поспорить, но практика и статистика таковы. 

Ошибка пять.
Мне неудобно так, значит и другим не понравится

В нашей команде часто возникали вопросы «А кому это надо?», «Клиент хочет вот так», «Это точно неудобно, потому что мне не нравится» и тд. На старте, конечно, можно подумать за клиента, предложить ему что-то и на основе обратной связи наполнять беклог. Здесь главное провести качественное исследование, и услышать боли, а не готовые решения, иначе они будут просить «более быструю лошадь», а не отлично работающую машину. 

Нужно погружать команду в боли клиента, звать на груминги клиентов и команду, дать команде контакты тех клиентов, у которых они всегда могут спросить мнение или быстро проверить функциональность. 

Я себе стала чаще говорить: «Никогда не примеряй роль клиента, если ты не была на его месте и не позволяй это делать команде». Зачем впустую спорить если можно спросить человека, для которого вы это делаете?

Ошибка шесть.
Прототипы никому не нужны

Очень большая ошибка начинающего РО — не делать прототипы и не проверять гипотезы. Хочется скорее творить прекрасное и сразу в продуктив.

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

Можно потратить три дня или неделю, от руки нарисовать, как будет выглядеть продукт, а еще обязательно показать его клиенту. Попроси его самого разобраться, как он будет этим пользоваться и не забывай делать это каждый раз, когда идеи переселяются в беклог продукта. 

Ну а когда  ты придумал гениальную фичу, запрототипировал ее, твой пользователь хлопает в ладоши и очень хочет ее — нет, все еще нельзя брать в работу:) Не забывай о метриках фич, и продуктовых и бизнесовых. Метрики вообще особая история с ошибками — о них позже и подробнее в следующей партии. Пока анонс…

Ошибка семь.
Метрика всевластия

Напомню, что наша команда — часть очень большого стартапа в крупной компании.  Договориться со стейкхлодерми о метриках продукта было сложно. Ставить бизнес-метрику на ИТ-решение, которое еще в стадии проектирования, - плохая затея. Но показывать свою работу инвесторам нужно, даже если инкрементов для пользователя пока нет.

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

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

• Сначала попробуй, если твое — иди в школу РО 
  
• Ты не бессмертен, не хватайся за все сразу, набирай команду, которой готов доверять
  
• Тебе точно нужен скрам мастер. На фултайм.
  
• Рискуй. Скрам-команда станет взаимозаменяемой рано или поздно, а бизнес гипотезы на полу не валяются, лучше быстрее занять свободное место на рынке со своим MVP, пусть и с рисками бас-фактора на старте, чем не успеть его занять. 
  
• Больше общайся с клиентом, помни про его боль, пытайся ее решить. 
  
• Подвергай сомнению все свои идеи, создавай прототипы и проверяй гипотезы, смотри на реакцию клиента,  мы тут за этим собрались:)
  
• Выбирай метрики сам, они должны помогать тебе делать качественно и итерационно хороший продукт. Помни, что продуктов, которые остались в «долине смерти» из-за отсутствия качества, предостаточно.