Преподаватель Финансового университета Тигран Басеян рассказал Нетологии о своем опыте работы в корпоративном стартапе Боржоми и управлении ожиданиями.
Сколько раз после неудачного проекта я думал: «Теперь все пойдет иначе, я набрался опыта. Такие вещи я больше не буду делать. И такие проекты брать не буду». Чувствуете боль? Узнаете себя?
Есть такая рубрика — поделись тем, что узнал на опыте — потом и кровью. Поделюсь несколькими приемами управления ожиданиями, которым я был бы рад лет 8 назад в начале карьеры в IT.
Я уверен, что во всем виновата картина с Джимом Кэрри «Всегда говори «да»». Но мы с вами люди взрослые и должны понимать, что для бизнеса любой ответ «да» — это затраты. И еще хуже, если ты не можешь ответить на вопрос «Почему да?» и «Как так получилось?»
Из словаря: «Управление ожиданиями — когда вы приводите картину мира пользователей,
заказчика, спонсора проекта и других заинтересованных лиц в максимально возможное соответствие реальности, чтобы столкновение с ней было настолько безболезненным, насколько возможно».
Соответствие реальности, что это такое? Речь о создании единого «реального». То есть уменьшении разницы между ожиданиями и происходящим, которая возникает, когда:
В этой статье последовательно расскажу о каждом пункте и дам практические инструменты, которые помогут разрешить ограничения в этих сферах.
Если переформулировать боли выше, то управление ожиданиями — это:
Полгода назад я перешел в корпоративный стартап — и оказался не готов к тому, что все гипотезы должны быть привязаны к конкретной цели и сформулированы смартом. Я привык работать, полагаясь на свою интуицию, хотя часто она меня подводила. И это был один из самых запоминающихся Aha-моментов.
Самая распространенная проблема при постановке целей — их абстрактность:
На днях разговаривал со своим бывшим коллегой, который поставил себе цель «улучшить главную страницу сайта». Вроде цель, как цель, но из нее не очень понятно, что вообще значит улучшить, что нужно сделать и когда, как измерить результат.
Чтобы превратить абстрактную цель в конкретную, удобно использовать методологии постановки цели. Их существует много, самая простая и популярная — SMART.
Методика включает в себя пять основных характеристик, которым каждая цель должна соответствовать:
Цель должна быть конкретной. Конкретность — четкое понимание результата, которого необходимо достичь.
Плохой пример: «Сделать интерфейс лучше». В таком случае неясно, чем текущий интерфейс плох, что нужно улучшать. Над какой метрикой?
Хороший пример: «Увеличить конверсию в целевое действие с 1% до 3%». Такая конкретная формулировка сразу дает понимание объема работы, альтернативные задачи, например, какие инструменты применить.
Цель должна быть измеримой. У каждой цели должна быть какая-то величина измерения. С ее помощью можно понять, достигли вы нужного результата или нет.
В примере выше такая величина — конверсионные показатели для лендинга. Если говорить про другие примеры, то часто мы хотим сесть на диету или ходить в зал. Но непонятно, сколько раз нужно сходить, чтобы достичь цели. Одного раза достаточно или нет? Вот тут бы лучше сработало «Провести 10 тренировок в зале до 31 января 2019 года».
Цель должна быть достижимой. Достижимость цели влияет на мотивацию. Необязательно ставить себе совсем простые цели, потому что интерес в таком случае тоже пропадает. Но как бы вы ни хотели, ваш мозг вряд ли будет относиться серьезно к цели «Побывать на луне к 1 февраля 2019 года». А вот цель «Издать статью к 1 февраля 2019 года» кажется куда более достижимой и от этого интересной.
Цель должна быть значимой для вас. Значимость в SMART методологии — величина вклада, который принесет решение этой задачи в достижение стратегических целей компании.
Цель должна быть ограничена во времени. Цель «Выучить английский» будет гораздо менее эффективной, чем «Сдать сертификацию TOEFL минимум на 95 баллов к 15 декабря 2019 года». Когда появляется временная отметка, к которой нужно получить результат, мозг в автономном режиме строит условный таймлайн. Вы понимаете, что для сдачи сертификации нужно выучить, например, 800 слов. Мозг понимает, что сделать это за 3 дня нереально, поэтому нужно составить план.
Недавно слышал в одном разговоре:
— Я своим на этот месяц поставил план на Х рублей, думаю они смогут сделать примерно 70%.
— А зачем?
— Есть несколько причин: первая, больше план — значит первоначальный легче сделают. Слышал про ОКР? Так вот это крутая тема для управления, Гугл работает по ней. Надо ставить КПЭ выше, чтобы человек больше 70 процентов не выполнял.
Если подобный разговор услышать от руководителя отдела продаж, то можно легко представить, что таким образом он мотивирует свою команду подняться и работать. Но если говорить про ИТ проекты и продукты, то такой подход неэффективен и пагубен. Во-первых, об ОКР вы можете почитать на странице.
OKR (от англ. Objectives and Key Results — цели и ключевые результаты) — метод, который используют в менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль над реализацией поставленных задач. Метод OKR был разработан в корпорации Intel. После получил распространение в ряде крупных технологических компаний, в том числе в Google, LinkedIn, Zynga.
Вообще техника обещать/поставить более высокий план, чтобы сделать стандарт — это скользкая дорожка:
Я видел другой вариант постановки планов/целей, делать их завышенными для команды и заниженными при презентации заказчикам. Но риски в этом подходе те же, что и в предыдущем изложении. Вы рискуете при невыполнении завышенного плана потерять команду.
Итог: ставить планы, которые реально выполнить и за которые можно поручиться.
SMART может диагностировать и синхронизировать старт работы над проектом, создав общую точку — точку начала координат. Но скорость движения у каждого своя, поэтому нужны инструменты для синхронизации работы.
В начале статьи мы остановились на создании поля для эффективной коммуникации за счет постановки правильной цели. А что по поводу принятия решения, какой должна быть цель?
Узнаете вопросы ниже:
Проблема в подобных высказываниях — отсутствие ассоциирования себя с целями и задачами команды. Тем самым пресловутым командным духом и не пахнет в подобных «командах». Подробнее про семь примеров значения командной работы можно почитать на сайте. Я же приведу пример исследования Ури Хассеса:
Профессор Принстоновского Института Нейронаук Ури Хассес в ходе своего исследования обнаружил неожиданную мозговую активность участников обмена историями. «Удивительна не только схожесть мозговой активности у всех слушателей. Мало того, и у рассказчика историй активность мозга была очень похожа — несмотря на то, что он вел рассказ, а остальные слушали», — говорит Хассес. Обмен мнениями, историями может улучшать производительность сотрудников. Они могут начать чувствовать, думать и делать то же, что и герои услышанных историй.
В чем же причина синергичности командной работы и как это связано с постановкой целей? А связь здесь теснее некуда. Здоровая командная коммуникация приводит к созданию так называемой «Кристаллизации команды». Прошедшая кристаллизацию команда — группа людей, столь сильно связанных, что целое становится больше суммы составляющих его частей.
Преимуществами работы в команде будут следующие:
Вы должны использовать команду для создания общей цели, тогда вы сможете выстроить стартовую точку — не факт, что она будет верная. Но как минимум — ваша команда будет в нее верить и идти с вами в одном направлении.
Не буду погружаться в психологическую сторону вопроса и разбираться в разных моделях управления разработкой. Вместо этого проанализирую коммуникативную составляющую командной работы и поищу ответы на два вопроса:
Ключевое понятие для разбора ошибок — коммуникация. Как мы привыкли работать в командах? Классический цикл разработки выглядит так: придумать, разработать, измерить результат.
Длина этих циклов от 1 недели до 4 недель по Agile. В таких условиях на коммуникации между членами команды не остается времени — мы все спешим реализовать намеченные задачи. И все бы ничего, но почему часть работы идет «в стол»?
Чтобы эффективно работать над проектом и взаимодействовать с командой, важно ответить на вопросы:
И логичным шагом в любой методологии разработки будет пуститься в мир приоритизации backlog. Как это сделать — использовать методику RICE? Или ICE? А если наш продукт только создается и мы толком ничего не знаем?
Представлю вам еще один инструмент, который я активно использую в рамках обучающего процесса, работы в стартапах, да и по жизни.
Как можно быстрее проверять предположения команды? Если у вас есть цель, команда генерирует способы ее достижения — гипотезы. Список гипотез растет с каждым днем: если в начале это всего 1−2, то к концу недели может быть уже 20−30.
Как их приоритизировать? Здесь помогут два инструмента:
Об этом позднее.
HADI-циклы — это один из инструментов методологии, с помощью которой «прокачивают» стартапы. Суть HADI проста. Почти любое действие оказывает влияние на какую-то определенную метрику. Если изменения «прикрутить» к показателям заранее, то есть сформулировать гипотезы, весь процесс изменений будет контролируемым. Словом, вы будете понимать, как ваши действия повлияли на результат, и сможете быстро тестировать идеи, отбрасывая нерабочие.
Цикл управления начинается с гипотезы: если мы сделаем Х, то это повлияет на Y, за время T. Используем SMART для формирования гипотезы. «Мы предполагаем, сделаем лендинг и получим новых клиентов. Эту формулировку записываем в ячейку H — гипотезы.
Как мы получим клиентов? Что нужно сделать для этого? Нужно заказать дизайн, сверстать, выложить лендинг, настроить рекламную кампанию. Этот план действий записываем в ячейку A — действия.
Сколько клиентов мы ожидаем? Если 100 новых клиентов придет, это хорошо, нас устроит? А 50? А 10? А всего один? А ни одного? Иногда оказывается, что даже если ни один клиент не пришел, вы еще не считаете гипотезу не подтвержденной. Клиентов не было, но были заявки, просто не получилось их правильно обработать. На что вы будете смотреть и что измерять, чтобы подтвердить гипотезу? Это будет количество заявок, звонков или продаж и за какой период? Пишем это в ячейку D — данные. В ячейку I с выводами пишем, при каком значении метрики считать гипотезу подтвержденной.
Что вы будете делать, если гипотеза не подтвердится? Скорее всего, искать другой способ достичь того же результата, получить 20 новых клиентов. То есть сформулируете и начнете проверять следующую гипотезу. А если подтвердится? Тоже будете проверять следующую гипотезу, ведущую вас дальше к цели. Ответы на эти вопросы тоже нужно сформулировать заранее, прежде чем начинать действовать. Они дополняют ячейку I — выводы.
После формулировки гипотезы члены команды оценивают сложность ее реализации и веру в успех от 1 до 10. Каждый должен обосновать свое мнение. После проставления всех оценок таблицу нужно сортировать по возрастанию сложности и убыванию веры. В результате наверху окажутся те гипотезы, над которыми нужно работать команде.
HADI — это инструмент быстрых экспериментов на проекте, а не наказания команды
Примеры таблицы из кейса Carrot Quest
В своей работе в рамках стартапа мы использовали гибридный HADIH, основное отличие было в том, что каждая строка в рамках гипотезы оканчивалась не только набором Инсайтов, а новыми Гипотезами, которые вытекали из полученных инсайтов. Эти новые гипотезы в конце итерации включались в общий backlog гипотез, проходили приоритезацию по вере и сложности. Таким образом в рамках работы над текущей гипотезой мы могли генерировать связанные гипотезы для новых итераций
Я в своей команде придерживался следующего подхода к организации итераций и встреч:
Методик управления ожиданиями в проектной работе много, но проблемы различия в ожиданиях по ходу выполнения работы, при демонстрации результатов — симптомы другой, более серьезной проблемы.
Можно прочесть множество умных книжек, как лавировать между запросами, приземлять ожидания, не принимать запросы, но для меня это все лежит в области принятия решений командой и открытости коммуникаций.
Нужно организовывать командную работу так, чтобы каждый понимал цель, в том числе и заказчик. Нужно создавать условия, при которых ваша команда зажжется работой, будет искать пути достижения поставленной глобальной цели.
Обещаю, что это будет некомфортно сперва, да и потом тоже, рост — это всегда болезненно.
Курсы Нетологии для дизайнеров интерфейсов:
Сколько раз после неудачного проекта я думал: «Теперь все пойдет иначе, я набрался опыта. Такие вещи я больше не буду делать. И такие проекты брать не буду». Чувствуете боль? Узнаете себя?
Есть такая рубрика — поделись тем, что узнал на опыте — потом и кровью. Поделюсь несколькими приемами управления ожиданиями, которым я был бы рад лет 8 назад в начале карьеры в IT.
Я уверен, что во всем виновата картина с Джимом Кэрри «Всегда говори «да»». Но мы с вами люди взрослые и должны понимать, что для бизнеса любой ответ «да» — это затраты. И еще хуже, если ты не можешь ответить на вопрос «Почему да?» и «Как так получилось?»
«Ваши ожидания — ваши проблемы» — что значит управлять ожиданиями
Из словаря: «Управление ожиданиями — когда вы приводите картину мира пользователей,
заказчика, спонсора проекта и других заинтересованных лиц в максимально возможное соответствие реальности, чтобы столкновение с ней было настолько безболезненным, насколько возможно».
Соответствие реальности, что это такое? Речь о создании единого «реального». То есть уменьшении разницы между ожиданиями и происходящим, которая возникает, когда:
- Нечетко сформулирована цель, то есть каждый идет в своем направлении.
- Нет коммуникаций между членами команды, руководителем, заказчиками.
- Каждый видит реализацию по-своему.
В этой статье последовательно расскажу о каждом пункте и дам практические инструменты, которые помогут разрешить ограничения в этих сферах.
Если переформулировать боли выше, то управление ожиданиями — это:
- Создание единых и понятных целей.
- Создание единой площадки для коммуникаций между всеми заинтересованными сторонами.
- Синхронизация того, над чем и как работает команда.
SMART: как ставить цели проекта
Полгода назад я перешел в корпоративный стартап — и оказался не готов к тому, что все гипотезы должны быть привязаны к конкретной цели и сформулированы смартом. Я привык работать, полагаясь на свою интуицию, хотя часто она меня подводила. И это был один из самых запоминающихся Aha-моментов.
Правильно сформулированная цель позволяет отсечь ненужное, создать единый язык коммуникаций между членами команды.
Самая распространенная проблема при постановке целей — их абстрактность:
На днях разговаривал со своим бывшим коллегой, который поставил себе цель «улучшить главную страницу сайта». Вроде цель, как цель, но из нее не очень понятно, что вообще значит улучшить, что нужно сделать и когда, как измерить результат.
Чтобы превратить абстрактную цель в конкретную, удобно использовать методологии постановки цели. Их существует много, самая простая и популярная — SMART.
Методика включает в себя пять основных характеристик, которым каждая цель должна соответствовать:
Specific
Цель должна быть конкретной. Конкретность — четкое понимание результата, которого необходимо достичь.
Плохой пример: «Сделать интерфейс лучше». В таком случае неясно, чем текущий интерфейс плох, что нужно улучшать. Над какой метрикой?
Хороший пример: «Увеличить конверсию в целевое действие с 1% до 3%». Такая конкретная формулировка сразу дает понимание объема работы, альтернативные задачи, например, какие инструменты применить.
Measurable
Цель должна быть измеримой. У каждой цели должна быть какая-то величина измерения. С ее помощью можно понять, достигли вы нужного результата или нет.
В примере выше такая величина — конверсионные показатели для лендинга. Если говорить про другие примеры, то часто мы хотим сесть на диету или ходить в зал. Но непонятно, сколько раз нужно сходить, чтобы достичь цели. Одного раза достаточно или нет? Вот тут бы лучше сработало «Провести 10 тренировок в зале до 31 января 2019 года».
Achievable
Цель должна быть достижимой. Достижимость цели влияет на мотивацию. Необязательно ставить себе совсем простые цели, потому что интерес в таком случае тоже пропадает. Но как бы вы ни хотели, ваш мозг вряд ли будет относиться серьезно к цели «Побывать на луне к 1 февраля 2019 года». А вот цель «Издать статью к 1 февраля 2019 года» кажется куда более достижимой и от этого интересной.
Relevant
Цель должна быть значимой для вас. Значимость в SMART методологии — величина вклада, который принесет решение этой задачи в достижение стратегических целей компании.
Time bound
Цель должна быть ограничена во времени. Цель «Выучить английский» будет гораздо менее эффективной, чем «Сдать сертификацию TOEFL минимум на 95 баллов к 15 декабря 2019 года». Когда появляется временная отметка, к которой нужно получить результат, мозг в автономном режиме строит условный таймлайн. Вы понимаете, что для сдачи сертификации нужно выучить, например, 800 слов. Мозг понимает, что сделать это за 3 дня нереально, поэтому нужно составить план.
Не надо завышать цели
Недавно слышал в одном разговоре:
— Я своим на этот месяц поставил план на Х рублей, думаю они смогут сделать примерно 70%.
— А зачем?
— Есть несколько причин: первая, больше план — значит первоначальный легче сделают. Слышал про ОКР? Так вот это крутая тема для управления, Гугл работает по ней. Надо ставить КПЭ выше, чтобы человек больше 70 процентов не выполнял.
Если подобный разговор услышать от руководителя отдела продаж, то можно легко представить, что таким образом он мотивирует свою команду подняться и работать. Но если говорить про ИТ проекты и продукты, то такой подход неэффективен и пагубен. Во-первых, об ОКР вы можете почитать на странице.
OKR (от англ. Objectives and Key Results — цели и ключевые результаты) — метод, который используют в менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль над реализацией поставленных задач. Метод OKR был разработан в корпорации Intel. После получил распространение в ряде крупных технологических компаний, в том числе в Google, LinkedIn, Zynga.
Вообще техника обещать/поставить более высокий план, чтобы сделать стандарт — это скользкая дорожка:
- При идеальном выполнении работы вы не способны достигнуть поставленную цель, недостижимую по определению. Подобная работа не может вдохновлять. Значит — это приведет к тому, что ваша команда начнет стрессовать, уставать, а потом выгорать.
- Заказчики будут ждать именно оптимистичного сценария, хотя он нереалистичен, а значит им никак не объяснить, что все пошло правильно, просто цель была завышенной.
Я видел другой вариант постановки планов/целей, делать их завышенными для команды и заниженными при презентации заказчикам. Но риски в этом подходе те же, что и в предыдущем изложении. Вы рискуете при невыполнении завышенного плана потерять команду.
Итог: ставить планы, которые реально выполнить и за которые можно поручиться.
Коммуникации в работе
SMART может диагностировать и синхронизировать старт работы над проектом, создав общую точку — точку начала координат. Но скорость движения у каждого своя, поэтому нужны инструменты для синхронизации работы.
Настраиваем точку начала координат
В начале статьи мы остановились на создании поля для эффективной коммуникации за счет постановки правильной цели. А что по поводу принятия решения, какой должна быть цель?
Узнаете вопросы ниже:
- «Почему все решает он? Я тоже хочу».
- «Почему меня не ценят»?
- «Я все сделал класно, просто эта штука и раньше не работала».
- «Я сразу сказал, что эта идея не полетит».
Проблема в подобных высказываниях — отсутствие ассоциирования себя с целями и задачами команды. Тем самым пресловутым командным духом и не пахнет в подобных «командах». Подробнее про семь примеров значения командной работы можно почитать на сайте. Я же приведу пример исследования Ури Хассеса:
Профессор Принстоновского Института Нейронаук Ури Хассес в ходе своего исследования обнаружил неожиданную мозговую активность участников обмена историями. «Удивительна не только схожесть мозговой активности у всех слушателей. Мало того, и у рассказчика историй активность мозга была очень похожа — несмотря на то, что он вел рассказ, а остальные слушали», — говорит Хассес. Обмен мнениями, историями может улучшать производительность сотрудников. Они могут начать чувствовать, думать и делать то же, что и герои услышанных историй.
Цель и коммуникации
В чем же причина синергичности командной работы и как это связано с постановкой целей? А связь здесь теснее некуда. Здоровая командная коммуникация приводит к созданию так называемой «Кристаллизации команды». Прошедшая кристаллизацию команда — группа людей, столь сильно связанных, что целое становится больше суммы составляющих его частей.
Преимуществами работы в команде будут следующие:
- В общем у команды большее количество опыта и знаний, чем у каждого отдельно взятого ее участника.
- Команда эффективнее отдельных людей в отношении ошибок и устранения их последствий.
- Решение, принятое в команде, скорее одобряют те, кому предстоит его выполнять.
- Члены команды скoрее способны отождествить себя с собственными действиями и вкладом в решение принятое командой. Вероятность тoгo, чтo oни воспримут решение группы кaк правильное — выше.
- Участники команды учатся друг у другa и стимулируют друг друга в процессе взаимного обучения.
Вы должны использовать команду для создания общей цели, тогда вы сможете выстроить стартовую точку — не факт, что она будет верная. Но как минимум — ваша команда будет в нее верить и идти с вами в одном направлении.
Как работать с циклами разработки?
Не буду погружаться в психологическую сторону вопроса и разбираться в разных моделях управления разработкой. Вместо этого проанализирую коммуникативную составляющую командной работы и поищу ответы на два вопроса:
- Почему я жду одного, а команда делает другое?
- Почему мы понимаем проблему одинаково, но у нас не получается ее решить?
Ключевое понятие для разбора ошибок — коммуникация. Как мы привыкли работать в командах? Классический цикл разработки выглядит так: придумать, разработать, измерить результат.
Длина этих циклов от 1 недели до 4 недель по Agile. В таких условиях на коммуникации между членами команды не остается времени — мы все спешим реализовать намеченные задачи. И все бы ничего, но почему часть работы идет «в стол»?
Чтобы эффективно работать над проектом и взаимодействовать с командой, важно ответить на вопросы:
- Что принесет пользу, а что нет?
- Как приоритизировать backlog, как поставить задачи, над которыми нужно работать?
- Что вообще делать?
И логичным шагом в любой методологии разработки будет пуститься в мир приоритизации backlog. Как это сделать — использовать методику RICE? Или ICE? А если наш продукт только создается и мы толком ничего не знаем?
HADI в работе
Представлю вам еще один инструмент, который я активно использую в рамках обучающего процесса, работы в стартапах, да и по жизни.
Как можно быстрее проверять предположения команды? Если у вас есть цель, команда генерирует способы ее достижения — гипотезы. Список гипотез растет с каждым днем: если в начале это всего 1−2, то к концу недели может быть уже 20−30.
Как их приоритизировать? Здесь помогут два инструмента:
- HADI-циклы;
- командная оценка «веры и сложности» работы с гипотезой
Об этом позднее.
HADI-циклы — это один из инструментов методологии, с помощью которой «прокачивают» стартапы. Суть HADI проста. Почти любое действие оказывает влияние на какую-то определенную метрику. Если изменения «прикрутить» к показателям заранее, то есть сформулировать гипотезы, весь процесс изменений будет контролируемым. Словом, вы будете понимать, как ваши действия повлияли на результат, и сможете быстро тестировать идеи, отбрасывая нерабочие.
Hypothesis
Цикл управления начинается с гипотезы: если мы сделаем Х, то это повлияет на Y, за время T. Используем SMART для формирования гипотезы. «Мы предполагаем, сделаем лендинг и получим новых клиентов. Эту формулировку записываем в ячейку H — гипотезы.
Actions
Как мы получим клиентов? Что нужно сделать для этого? Нужно заказать дизайн, сверстать, выложить лендинг, настроить рекламную кампанию. Этот план действий записываем в ячейку A — действия.
Data
Сколько клиентов мы ожидаем? Если 100 новых клиентов придет, это хорошо, нас устроит? А 50? А 10? А всего один? А ни одного? Иногда оказывается, что даже если ни один клиент не пришел, вы еще не считаете гипотезу не подтвержденной. Клиентов не было, но были заявки, просто не получилось их правильно обработать. На что вы будете смотреть и что измерять, чтобы подтвердить гипотезу? Это будет количество заявок, звонков или продаж и за какой период? Пишем это в ячейку D — данные. В ячейку I с выводами пишем, при каком значении метрики считать гипотезу подтвержденной.
Incites
Что вы будете делать, если гипотеза не подтвердится? Скорее всего, искать другой способ достичь того же результата, получить 20 новых клиентов. То есть сформулируете и начнете проверять следующую гипотезу. А если подтвердится? Тоже будете проверять следующую гипотезу, ведущую вас дальше к цели. Ответы на эти вопросы тоже нужно сформулировать заранее, прежде чем начинать действовать. Они дополняют ячейку I — выводы.
HADI таблицы
После формулировки гипотезы члены команды оценивают сложность ее реализации и веру в успех от 1 до 10. Каждый должен обосновать свое мнение. После проставления всех оценок таблицу нужно сортировать по возрастанию сложности и убыванию веры. В результате наверху окажутся те гипотезы, над которыми нужно работать команде.
HADI — это инструмент быстрых экспериментов на проекте, а не наказания команды
Примеры таблицы из кейса Carrot Quest
HADIH — гибридный HADI
В своей работе в рамках стартапа мы использовали гибридный HADIH, основное отличие было в том, что каждая строка в рамках гипотезы оканчивалась не только набором Инсайтов, а новыми Гипотезами, которые вытекали из полученных инсайтов. Эти новые гипотезы в конце итерации включались в общий backlog гипотез, проходили приоритезацию по вере и сложности. Таким образом в рамках работы над текущей гипотезой мы могли генерировать связанные гипотезы для новых итераций
Как строили итерации
Я в своей команде придерживался следующего подхода к организации итераций и встреч:
- В самом начале внедрения методологии мы провели сессию в 2 часа со всеми членами команды и заказчиком, чтобы создать максимальное количество гипотез по продукту. Все гипотезы были оцифрованы и занесены в таблицу, мы с командой заполнили столбцы H, A, D. В результате каждая гипотеза получилась в формате SMART.
- Следующая встреча была с командой и трекером — он использовал разные методики разработки и помогал, задавая вопросы. Оценивали каждую гипотезу по вере и сложности. При этом я добавил к оценке «Время реализации», чтобы считать capacity команды на неделю
- Мы проводили каждую пятницу встречу по завершению текущей итерации и старту следующей. На встрече мы дополняли таблицу инсайтами и новыми гипотезами, делились результатами работы, принимали решение о масштабировании каких-либо гипотез.
Нужно ли управлять ожиданиями?
Методик управления ожиданиями в проектной работе много, но проблемы различия в ожиданиях по ходу выполнения работы, при демонстрации результатов — симптомы другой, более серьезной проблемы.
Можно прочесть множество умных книжек, как лавировать между запросами, приземлять ожидания, не принимать запросы, но для меня это все лежит в области принятия решений командой и открытости коммуникаций.
Нужно организовывать командную работу так, чтобы каждый понимал цель, в том числе и заказчик. Нужно создавать условия, при которых ваша команда зажжется работой, будет искать пути достижения поставленной глобальной цели.
Обещаю, что это будет некомфортно сперва, да и потом тоже, рост — это всегда болезненно.
Курсы Нетологии для дизайнеров интерфейсов:
- курс «Product Manager»
- курс «Project Manager»
- курс «Гибкие методологии управления проектами: Agile, Scrum, Kanban»
