Как не сделать ИТ-продукт за девять месяцев: вредные советы от Product Owner

В июле 2019 года мне случилось прочитать пророческий доклад на GeekPicnic в Петербурге, который назывался «Как не сделать ИТ-продукт за девять месяцев. Вредные советы от Product Owner».

Думаю, какие-то вредные советы (а может даже все) окажутся близки для моих товарищей по digital-цеху. Впрочем, они применимы практически в любой сфере, где правят любовь к своему делу, командный дух и здравый смысл.

Статья будет в первую очередь интересна тем, кто уже прошёл через ряд подобных сложностей при создании продукта. А также тем, кто подобных сложностей стремится избежать.

Многие из вас читали в детстве Григория Остера и его «Вредные советы». О том, как классно «зажать» подарок для друга в его День рождения, отрицать свою причастность к разукрашиванию обоев в гостиной, от души посмеяться над поскользнувшимся человеком и многом-многом другом.

В детстве эти вредные советы казались мне каким-то несуразным бредом сумасшедшего. Но вот я вырос, узнал мир корпоративного ИТ и придумал пять своих собственных вредных советов. А кто скажет, что это бред, пусть первым кинет в меня задачу в Jira.

Готовы? Тогда, как сказал один известный космонавт, релиз которого таки состоялся, поехали.

Как это часто бывает. У стейкхолдеров рождается гениальная продуктовая идея. Или у Product Owner рождается не менее гениальная идея. Или, ожидая таксон на улице, вы услышали и подхватили гениальную идею. Или... Да не важно! У вас в руках гениальная идея!

Что же с этим добром делать?

В результате CustDev-изысканий, съёма требований, приоритизации, анализа рынка, обкатки MVP появляется занимательный документ. Знакомьтесь — это скоуп проекта. В нем - всё!

Это и набор функциональных требований для версии 1.0, и учтённые риски, и матрица коммуникаций, и миссия, и стройный Roadmap на 3, 6, 12 месяцев. Очаровательная де-ком-по-зи-ция!

Ура, бюджет выделен, работы стартовали, команда заряжена на небывалый успех.

Но вот проходит полтора месяца работы, и... в голове стейкхолдера или в голове Product Owner созревает губительное зерно. Требуется докинуть в будущий продукт версии 1.0 ещё одну или две функциональности.

Почему? Потому что это сделает продукт ещё круче! Потому что это киллер-фича для рынка! Потому что успех, бабки, бабы! (простите). Почему не перенести во вторую версию? Потому что нельзя ждать: конкуренты не дремлют. Надо сейчас!

И вот в скоуп проекта летит первая вонючая ракета. И треугольник проекта, основанный на трёх взаимосвязанных вещах: сроке, бюджете, результате — начинает качаться. Варианты могут быть разные:

Вариации и выводы можно продолжать.

Ещё через два месяца в скоуп проекта летит ещё одна ракета. Потом вторая, третья...

А потом ваша команда начинает разваливаться. И почему-то ни высокие зарплаты, ни речи в стиле Арагорна, ни даже пятничная пицца больше не спасают. И тогда проект вовсе оказывается на грани провала. Кого винят в итоге? Ну вы поняли.

Какие можно сделать выводы:

Good Luck!

Как показало моё общение с представителями ИТ-компаний на российском рынке, далеко не все осознают даже саму роль «аналитик». Часто я сталкивался с непониманием в духе «ну рынок проанализировали, цифры получили, выводы сделаны».

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

Например, в одной из моих прошлых компаний, мы выкатили довольно-таки стройный маркетплейс товаров и услуг без единой строчки в Confluence.

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

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

Мое мнение таково. Аналитик закроет собой множество неожиданностей и поможет сэкономить ресурсы. В особенности это касается сложных, заросших мхом и кустарником, монолитных систем, где одно неверное движение и хилая конструкция из дерьма и веток разлетается на раз-два. Поэтому хотя бы минимальная документация нужна, ну а кто будет её вести — только ваш выбор.

Выводы следующие:

«Нужно сделать релиз к декабрю», «проект сдадим к 20 мая», «все работы должны быть завершены через неделю».

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

Здесь всё как в известной ментальной обманке «он такой здоровый, потому что служил в ВДВ». Но нет же! «Его взяли в ВДВ, потому что он такой здоровый». Причина — следствие.

Так же и с проектами: часто дедлайны стараются подстроить под заданные сроки. Без постановки первоначальных сценариев, видения интерфейсов, должного технического ревью, оценки рисков (нужное подчеркнуть).

В лучшем случае собирается команда, оговаривается примерное видение и на основе экспертного мнения называются далёкие от истины сроки.

Итог предсказуем: из последних сил все хотят успеть к сроку, изматываются, теряют запал, выгорают. А продукт если и выходит, то весь на костылях, стоящий под вентилятором негативных отзывов клиентов.

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

Здесь важно проявлять стойкость. И помнить про эти три правила:

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

Гулять по кладбищу продуктов— особый вид больного наслаждения.

Наблюдая за всеми этими мертворождёнными социальными сетями, сервисами по доставке чёрт знает чего, православными мессенджерами и забугорными gogle-reader-wave-buzz-health, думаешь: «Ну нет, я бы на такую удочку не попался! CustDev (или то, что в русскоязычном сегменте подразумевают под интервью с клиентом) — на первом месте! Сначала нужно понять, кто твой клиент, какие у него "боли", затем этап MVP, снова CustDev, MVP 2.0, и только потом — полноценный продукт с блэкджеком и IPO».

Только на деле обычно получается так. Появляется идея и вместо того, чтобы отнестись к ней критически (проверить на прочность), мы начинаем неосознанно искать ей подтверждение.

Рассказываем коллегам, друзьям, соседям, своей кошке. Да как рассказываем! Стив Джобс в ярости бы порвал на себе водолазку, наблюдая за нами. Мы убедительны, мы продаём.

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

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

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

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

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

Разумеется, частенько мы слышим: «Мы с ребятами подумали, почувствовали, решили попробовать [функциональность], запустили, и вот через сутки у нас [количество пользователей], это успех, продукт всем зашёл».

Только важно помнить, что в медийное пространство попадают лишь крайние участки спектра — либо феерический успех, либо грандиозный провал. Всё посередине выпадает из нашего поля зрения. А ведь на один-два примера успешно взлетевших продуктов приходятся сотни (если не тысячи) проваленных затей. Затей, в которых были уверены, которыми горели. Но которые на этапе «запустили» не вызвали ни-че-го.

Потому-то очень важно тестировать такие идеи на ранних стадиях. И здесь не нужно быть чёртовым гением, чтобы ещё раз повторить: «Выйдите из комнаты и спросите у клиентов».

Не нужны прототипы, не нужны продукты. Это просто интервью для выявления реальной потребности. Это 10–20 минут, за которые вы можете узнать многое — и как скорректировать гипотезу, так и полностью от неё отказаться. Абсолютно без затрат, ну разве что с лёгким спадом настроения.

А вот если первоначальная гипотеза подтвердилась, вас ждут более увлекательные вещи: исследования, метрики, A/B-тесты, опросы, CGM и многое другое. И, конечно, софиты. Всему свое время.

Итак:

К сожалению, картина в сознании большинства людей сложилась таким образом, что понятие «критиковать» носит негативный оттенок. В противовес критике часто ставят «критикуешь — предлагай» или более резкое — «сначала добейся, а потом...» (формулировка зависит от уровня накала диалога).

Но ведь критика совсем не про это.

Есть «некритическое мышление» — это принятие на веру и как руководство к действию любой информации, поступающей извне. Без пауз на размышление. Подчинение.

А есть «критическое мышление» — способность и желание смотреть на информацию скептически. В слове «скептицизм», кстати, тоже нет ничего плохого. Это просто отказ автоматически считать за истину всё, что человек видит, слышит, получает.

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

Только существует один важный момент: в сфере ИТ не может и не должно быть отношений в духе «руководитель — персонал». Здесь есть команда.

Лично для меня отличия следующие.

В руководстве:

В команде:

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

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

А лид в свою очередь смотрит на замечания не как на выпады в сторону его лидерства, а как на возможность что-то докрутить в продукте или идее и сделать проект как можно лучше.

Вывод:

Сегодня я поделился с вами пятью вредными советами, силу которых ощутил на себе в полной мере. А теперь мои вам полезные советы:

Желаю вам удачи в разработке продуктов. Не бойтесь ошибаться и никогда не сдавайтесь.

#продукт