{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Как не сделать ИТ-продукт за девять месяцев: вредные советы от 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.

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

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

  • Вы сможете обнаружить дополнительные пользовательские сценарии, которые упустили на своём уровне абстракции. Такие сценарии необходимо проработать для будущего продукта.
  • Аналитик сможет предусмотреть наиболее «безболезненный» путь внедрения новых функциональностей, без глобальных изменений в бэке и последующих флэшбеков по закрытым багам. Это сэкономит ваши ресурсы и нервы.
  • Вам не придётся на словах или перебирая старые задачи объяснять работу системы новым сотрудникам: достаточно передать ссылку на документацию, например в Confluence.

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

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

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

Третий вредный совет: определяйте и гоните сроки без оснований

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

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

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

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

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

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

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

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

  • Сроки не берутся из ниоткуда. Сначала оценка (неповерхностная), потом срок.
  • Риски есть всегда. Чем больше «белых пятен» в проекте (недостаток документации, неустойчивость системы, проблемы с наличием свободных стендов, отсутствие специалистов в команде), тем выше риски.
  • Риски всегда (!) учитываются в поставленных сроках. Не страшно умножить на коэффициент риска срок, страшно потом понять, что не успеваете к заявленному сроку.

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

Четвёртый вредный совет: никогда не спрашивайте пользователей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак:

  • Одно правильно проведённое интервью может сохранить миллионы.
  • Одно непроведённое интервью может лишить вас бюджета, мотивации, репутации.
  • Нет объективного опыта. Любая уверенность — только в нашей голове. Проверяйте.
  • Сделайте процесс расспрашивания частью своей жизни. Только так можно приблизиться к истине и найти «то самое».

Пятый вредный совет: не позволяйте себя критиковать

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

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

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

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

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

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

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

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

  • Руководитель всех умнее, а даже если и нет, спорить с ним не нужно, проблем не оберёшься.
  • Задачи надо «хватать» и делать как можно быстрее, все риски предусмотрит руководитель.
  • Важно быть первым и лучшим в коллективе.
  • Если случился провал, отвечает всегда руководитель.

В команде:

  • Если дело спорится, то успех общий.
  • Если происходит факап, то провал тоже общий.
  • Ответственность распространяется на всю команду.
  • Лид фильтрует всю поступающую извне информацию и превращает её в конкретные задачи для команды.

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

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

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

Вывод:

  1. Самонадеянность — главный враг лида.
  2. Ответственность — общая.
  3. Всегда прогоняйте через фильтр критического мышления собственные и чужие мысли, идеи, поступки.
  4. И главное. Формула здоровых отношений в команде — если есть, что возразить, критикуй, критикуя — обосновывай, если есть, что предложить, предлагай (да-да, не всегда есть решение прямо здесь и сейчас, но увидеть, когда что-то не так, и сказать, почему не так, — воля и благо каждого).

В завершение

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

  1. Улучшайте продукт только в скоупе.
  2. Бейтесь за чистоту документации.
  3. Управляйте сроками осознанно.
  4. Задавайте много вопросов.
  5. Побеждайте командой и с командой.

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

0
20 комментариев
Написать комментарий...
Дмитрий Конопля

Не совсем понимаю ваш треугольник "Срок, Бюджет, Результат". Первые два понятия вполне измеримы, а чем измерять Результат - не ясно. Возможно вы имели ввиду классический "Cost Time Quality triangle", так как качество ещё можно условно измерить.

Совет "Определяйте и гоните сроки без оснований" не верный, так как важнее всего именно продукт, а не его код. Иногда важнее давать жёсткий (но адекватный) дедлайн свыше, чем постоянно спрашивать команду о сроке. Дедлайн даёт понимание всем участникам команды, что этот тот финиш, к которому надо придти, и если идти не получается, то иногда надо и бежать (работа в выходные или овертайм). И по моему опыту - когда команда прошла через тяжёлый дедлайн, но всё успела в самый последний срок и с должным качеством, то это только сплачивает людей.

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

Ответить
Развернуть ветку
Олег Новак

Уточню первый абзац - Вы об этом классическом треугольнике? https://en.wikipedia.org/wiki/Project_management_triangle

Ответить
Развернуть ветку
Дмитрий Конопля

Он в том числе хорошо подходит, так как скоуп задач легко измерим. Я же говорил про именно треугольник Cost Time Quality triangle, так как используем его для "торгов" со стейкхолдерами. "Цена, Качество, Время - выберите 2 важных для вас и мы подпишем договор".

Ответить
Развернуть ветку
Олег Новак

Простите, я перепутал с Agile. Там качество не является предметом торга.

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Спасибо за комментарий! @Олег Новак показал в ссылке ту версию треугольника, что я имел ввиду. Результат = скоуп, в данном случае. Прошу прощения за неточность, обычно оперирую такими терминами - вопросов не вызывало пока :)

Про сроки. Если дедлайн адекватный - согласен полностью. Как же часто бывало в моей практике - срок прилетает "сверху", где бизнес определяет, что вот эта маленькая функциональность - дело двух дней работы джуна. А по факту за ней стоит рефакторинг системы). Утрирую конечно, но я думаю, что мысль донес.

Поэтому все задачи от бизнеса я стараюсь провести через тех-ревью (хотя бы поверхностное). В сжатых сроках ничего смертельного нет, а вот в невыполнимых (неадекватных) умирает мотивация, особенно если успеть все же не удалось, как ни гнали. Бывали, конечно же (намного реже), и позитивные моменты - когда успевали несмотря ни на что и это объединяло.

Здесь соглашусь лишь отчасти. Все же, работы над проектом очень завязаны с друг-другом. Это происходит как в последовательном сообщении, так и на этапе работы определенного специалиста - когда ему требуются уточнения, консультации. Если брать и делать бездумно по задаче - то часто и получается, что "ну ты же накосячил, я просто задачу делал". Я всегда стараюсь обсуждать задачи, получать обратную связь и сводить людей для обсуждения. И получается так, что бэкэнщик вроде как участвует в работе дизайнера, а тестировщик - в работе фронта. Конечно, это может быть моей локальной прихотью, я не 20 лет в разработке. Но думаю, что любой продукт - это люди, в первую очередь.

Ответить
Развернуть ветку
Денис Шергин

Интересно, продолжайте.

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

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Спасибо, буду! Я как раз имел ввиду, что аналитик="документатор", поэтому все в одном пункте. Не думал, что кого-то может смутить)

Ответить
Развернуть ветку
Zoya Shakhova

Читать стало лень, но картинки посмотрела, они - прекрасные!)

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Спасибо :) В них и есть вся суть, вообщем-то

Ответить
Развернуть ветку
Serge Sokolov

Гагарин не говорил поехали. Точнее он сказал это на реконструкции полета, когда все уже было позади, и означало это -  поехали к Звездам (Кремлевским и наградным). Что он говорил сидя в кресле перед стартом когда примерно знал, что шансы его 50/50, этого никто не знает, как не знает, что было со всеми до него  у которых были (или им так сказали) такие же 50/50. 

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Спасибо, не знал) Тем не менее, в моей фразе вроде бы противоречий нет :)

Ответить
Развернуть ветку
Сергей Токарев

спасибо за шпаргалку

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Пожалуйста :)

Ответить
Развернуть ветку
Bulat Ziganshin
- Если случился провал - отвечает всегда руководитель.  

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

Ответить
Развернуть ветку
Сергей Гусенков
Автор

Верхнеуровнево - это руководитель команды. Здесь про восприятие ответственности и санкции в такого вида структурах, а не про декомпозицию факапов и анализ.

Ответить
Развернуть ветку
Alexander

Восприятие ответственности, декомпозиция факапов. Мы наблюдаем дефективного менеджера во всей красе.

Ответить
Развернуть ветку
Vladimir Ivanov

А кто может пояснить, что значит общая ответственность и как она выражается более конкретно? Уволят всех? Премию не дадут? Что то ещё?

Ответить
Развернуть ветку
Сергей Гусенков
Автор

То, что вы перечислили, имеет место быть, конечно же. Для меня ответственность - понимание, что каждый член команды (а не один крайний/крайние) может повлиять на результат или его отсутствие. Непонимание этого ведет, в первую очередь, к потерянному командному духу. А его очень сложно восстановить.

Ответить
Развернуть ветку
Vladimir Ivanov

Так а ответственность то как выражается? Что каждый может повлиять на результат? Какая то подмена понятий

Ответить
Развернуть ветку
Сергей Гусенков
Автор

1. Ответственность при работе над продуктом - понимание, что каждый человек в команде влияет на процесс и результат. Значит, она общая.

2. Ответственность, в плане кнута и пряника (санкций и премий) выражается по-разному, в зависимости от компании. Где-то это расформирование/расширение, где-то депремирование/премирование, где-то перевод продукта в другую продуктовую команду/передача новых продуктов в команду.

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда