{"id":9208,"title":"\u0412 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u044f\u0445 \u043d\u0430 vc.ru \u043f\u043e\u044f\u0432\u0438\u043b\u0438\u0441\u044c \u0441\u0442\u0438\u043a\u0435\u0440\u044b","url":"\/redirect?component=advertising&id=9208&url=https:\/\/vc.ru\/promo\/326527-lyubite-rugat-servisy-vk-etot-tekst-dlya-vas&placeBit=1&hash=032d65c70fe5fc63c371cf935d9281ebe7529d9359ff65d7499233043c93d674","isPaidAndBannersEnabled":false}

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

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

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

4

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

0

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

0

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

0

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

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

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

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

0

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

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

2

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

1

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

2

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

0

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

2

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

0

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

1

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

0

- Если случился провал - отвечает всегда руководитель.  

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

1

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

0

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

0

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

0

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

0

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

0

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

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

0
Читать все 20 комментариев
eBay: 64% покупателей не жалеют о своих покупках в Черную пятницу

Черная пятница — одно из главных событий этой недели: тысячи покупателей находятся в поиске лучших скидок. А что происходит после Черной пятницы? eBay опросил около 1000 россиян и выяснил, считают ли они выгодными покупки, совершенные во время самой большой распродажи года.

Разговор PRO: аналитика рекламы

Эксперты компании Registratura, входящей в iConText Group, вместе со своим клиентом «Олант» приняли участие в спецпроекте AdIndex.ru, где поговорили о рекламной аналитике.
Сергей Ерофеев, генеральный директор Registratura, Андрей Сахаров, руководитель отдела продаж Registratura, и Филипп Иванов, директор по интернет-маркетингу и e-commerce «Олант»…

Зимний набор на оплачиваемую стажировку в Тинькофф Старт: какие задачи решают стажеры

Стажировка пройдет по направлениям: аналитика, QA, бэкенд-разработка (Java, C++, Python, Scala, .Net, Golang), фронтенд, мобильная разработка (iOS и Android), ML, маркетинг и менеджмент образовательных проектов.

Фото: Курьер Delivery Club из Рыбинска в ретро-форме Статьи редакции

Сотруднику выдали шинель и фуражку, а рюкзак поменяли на ящик с кожаными ремешками.

IKEA начала сдавать в Токио квартиры в 10 м² за $0,86 в месяц, чтобы показать, что в них тоже можно жить Статьи редакции

Внутри есть мини-спальня, рабочая зона, диван, стиральная машина и другое.

Юбилей кешбэка: как в 130 лет выглядеть «на все сто»

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

Плюшки – от робота, а преференции – для резидента

Как наладить взаимовыгодное сотрудничество на территории ОЭЗ «Технополис Москва».

Как обустроить домашнюю студию звукозаписи при скромном бюджете Статьи редакции

Почему сведённый трек нужно проверять на паршивой Bluetooth-колонке, какие плагины выгоднее брать новичку и с каким синтезатором работал Ханс Циммер, создавая саундтрек к «Тёмному рыцарю», — в пересказе Pitchfork.

AudioMunk
«Как иронично, что фирме в сфере психического здоровья плевать на психическое здоровье собственных работников» Статьи редакции

Сотрудники Spring Health жалуются на соучредительницу Эйприл Го: она запугивает их, увольняет при всех, вынуждает работать по 70 часов в неделю и не нанимает тех, кто спрашивает про переработки. Го объясняет: «Мы носимся как безголовые цыплята, потому что на кону человеческие жизни».

Эйприл Го — на ноябрь 2021 года самая молодая женщина-директор компании с оценкой более $1 млрд Slush
null