КомпаниякакПродукт
В этой статье я хочу поделится своими мыслями о том, как эволюционировало за последние десятилетия понимание того, для кого создаётся любая компания.
Эта статья не является “истиной в последней инстанции”, а лишь отражает мой взгляд на этот вопрос. И мне очень интересны ваши мысли и критика этого подхода.
Для начала я сразу хочу сказать, что не считаю ни одну из трёх позиций “правильной” или “ошибочной”. Напротив, я считаю необходимым учитывать все 3 позиции для достижения успеха.
И так, начнём с самой базовой идеи…
Компания нужна для зарабатывания денег
С такой точки зрения целевая аудитория создаваемого “продукта” (компании) – это владельцы бизнеса, которые должны получать как можно больше прибыли.
Основная задача такого бизнеса заработать как можно больше денег. Всеми правдами и неправдами. Я думаю, что бизнес перестроечных времён в России можно считать самым ярким примером.
Целевая аудитория:
- Владельцы бизнеса
С течением времени становится очевидно, что из-за стремления получить максимальную прибыль сейчас, компания теряет клиентов, сильно уменьшая свой доход в будущем. Из-за этого появился следующий взгляд:
Компания должна быть клиентоориентированной
В таком случае целевая аудитория нашего “продукта” – это клиенты компании, которые собственно и являются источником денег. Значит бизнес должен сделать их счастливыми, чтобы они заплатили побольше денег. Что в итоге принесёт много денег владельцам бизнеса.
Переход к этому этапу происходит тогда, когда становится ясно, что для увеличения прибыли нужно сделать так, чтобы клиенты покупали чаще, больше и регулярнее. Для этого “приходится” включить клиента в целевую аудиторию и начать думать о том, как сделать хорошо для него. Ну и логика такова, что если клиенту хорошо, то он и заплатить готов. А потом ещё и вернётся вместе с друзьями, которые тоже купят что-нибудь.
Но, конечно же, всегда важно держать в голове и то, что всё это должно приносить прибыль потому, что без прибыли компания закроется, да и владельцы будут несчастливы.
То есть, наша целевая Аудитория:
- Клиенты
- Владельцы бизнеса
Этот подход сейчас является очень популярным. Про заезженность термина “клиентоориентированность” уже очень злобно шутят в книгах (например, в этой). При этом идея этого подхода, в самом-то деле, замечательная. Делать клиентов счастливыми, делать им хорошо, быть полезными – это всё хорошо и даже иногда “социально ответственно”.
Неприязнь к этому подходу появляется во многом из-за того, что идея “клиентоориентированности” идёт от высшего руководства, которое из лучших побуждений (или стремления заработать побольше) пытается впихнуть эту идею в голову сотрудников. Но они не знают как это сделать. Ведь их дело “execution”, а не обучение сотрудников. И получается как в этом анекдоте:
Пришли мыши к мудрой сове попросить совета, как им избежать участи быть съеденными обнаглевшими котами. Сова говорит им: “Станьте ежиками. Если вы будете колючими, вас никто не съест!” Обалдевшие от восторга мыши побежали домой, там опомнились и снова вернулись к сове. “Сова, расскажи – а как нам стать ежиками?” А Сова им в ответ: “Мое дело – стратегия!”.
Как вы понимаете, при таком раскладе сотрудников многих компаний уже кривит от слова “клиентоориентированность”.
И, как ответ на эту проблему, в последние годы в мире набирает силу следующая идея…
Компания является продуктом, который топ-менеджмент создаёт для сотрудников
В таком случае целевая аудитория компании – это сотрудники компании. Соответственно, компания проектируется под целевую аудитория, поэтому сотрудники знают как пользоваться этим “продуктом”. То есть, знают как правильно и эффективно работать в компании. Поэтому они хорошо работают, создавая ценность для клиентов компании. А это значит, что клиенты будут готовы платить деньги. А это уже делает счастливыми третью аудиторию – владельцев компании.
Можно провести аналогию с компьютерными играми. Некоторые компании похожи на игру “Весёлая ферма”. Только вместо выращивания фруктов, овощей и скота, они обслуживают клиентов. При чём часто ещё и используется схожая система вознагражения “игрока” за достижения. Как вы, навреняка, знаете, в “Весёлой ферме” игроки не только самозабвенно тратят многие часы своего времени, но и ещё и много денег!
Представьте себе что будет, если использовать для проектирования компании те же подходы, которые использованы при проектировании этой игры… может быть вам придётся перестать тратить безумное количество денег на “мотивацию и контроль сотрудников”, но придётся что-то делать с огромной очередью людей, которые хотят работать у вас!
Если вы хотите больше узнать о том, возможно ли это, то можете почитать о компании Zappos.
На размышления о таком взгляде на компании меня подтолкнуло прочтение следующих книг:
- ЦЕЛЬ ІІ. Дело не в везенье – Элия М. Гольдратт – в этой книге прямым текстом идёт речь о том, что у любой современной компании 3 крупных сегмента в целевой аудитории – сотрудники, клиенты и владельцы. И даже герой в книге решает, что приоритет должен быть именно таким – в первую очередь сотрудники, потом клиенты, а затем владельцы.
- The Connected Company – Dave Gray, Thomas Vander Wal – в этой книге описывается, что компании, оказывающие услуги должны проектировать свою компанию для своих сотрудников так, чтобы сотрудники, действуя естественным для себя образом, смогли оказать великолепную услугу для клиентов компании.
Эти книги утвердили меня в понимании того, что при создании компании и её развитии можно применить весь тот мощный инструментарий, который был накоплен за последние годы в проектировании интерфейсов программных продуктов. Так же применимы те же метрики, которые используются для построения клиентской воронки ARM (Acquisition, Retention и Monetization) или более подробные AARRR (Acquisition, Activation, Retention, Refferals, Revenue).
Давайте рассмотрим сотрудников, как пользователей продукта “компания”. Этот продукт проектируют том-менеджеры компании. В таком случае общая картина получается такой:
- Изначально “нагоняется трафик” – мы конвертируем соискателей работы в работников компании. Конечно, не всех подряд, а только тех, кто подходит. Происходит Acquisition.
- Затем сотрудник выходит впервые на работу, ему рассказывают что и как, он понимает свои цели, задачи и полномочия, работает над первым проектом. Таким образом происходит Activation.
- Поработав у нас 2-3 месяца, сотрудник либо доволен и хочет оставаться с нами, либо подумывает о смене работы. Это и есть Retention.
- Cотрудник предлагает нам своих знакомых профессионалов, как кандидатов для собеседования. Это Referalls.
- Сотрудник, выполняя свою работу, делает людей во внешнем мире счастливыми, тем самым принося доход (это команды в продуктах и проектах). Либо снижая затраты на работу компании, тем самым снижая себестоимость (это админы, бухгалтерия и т.п.).
И есть ещё одно важное наблюдение, которое можно сделать смотря с этой точки зрения. Сотрудники сами не создают систему, по которой работают. Они лишь следуют тем сценариям, которые явно или не явно заложены “проектировщиками” компании.
При создании ИТ-продуктов проектировщик и product owner не имеют права сказать “мы всё сделали хорошо, а пользователи просто тупят и не понимают моей задумки, поэтому и не покупают у нас наш продукт”. Точнее, конечно, они могут, но таких людей надо ещё на собеседовании выгонять. Точно так же и топ-менеджмент осознанно или неосознанно проектирует свою компанию (подбор людей, их вход в компанию, их ежедневная работа, их взаимодействия, их развитие и т.п.). Поэтому и фраза про то, что “этот проект не успешен потому, что разработчики (или менеджеры) тупили” на самом деле обозначает, что этот аспект работы компании был недостаточно хорошо спроектирован, не учитывал какие-то из сценариев, что и привело к проблеме.
Таким образом, при создании компании с такой позиции целевая аудитория выглядит так:
- Сотрудники компании
- Клиенты
- Владельцы бизнеса
То есть, если сложить всё вместе, то получается следующее:
- для топ-менеджмента компания является продуктом, который они создают для сотрудников;
- сотрудники создают продукт (-ы) для клиентов, принося им пользу и делая их счастливыми;
- клиенты в свою очередь с радостью платят деньги, что делает счастливыми владельцев компании.
Такая вот точка зрения.
Твитнуть
Поделиться
Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Большие элементы в Бэклоге продукта (PBI) — причина неприятных сюрпризов и повышенной вариативности в Спринте. Чем больше задача, тем больше неизвестных. Большие PBI с трудом вмещаются в Спринт, а Владелец Продукта и стейкхолдеры могут долго не видеть результатов работы Скрам-команд.
Недавно я начал работать с двумя фиче-командами. Владелец Продукта поместил наверх Бэклога одну огромную фичу, которая, по предварительной оценке, должна была занять команды на много Спринтов вперёд.
На актуализации Бэклога Продукта присутствовали обе команды в полном составе (Multi-Team PBR). Мы декомпозировали, оценили и подготовили Бэклог Продукта к планированию за восемь шагов.
Шаг 1. Определить связь PBI с бизнес-целью
Мы обсудили, что связывает PBI с ближайшей бизнес-целью: с увеличением конверсии заявок с сайта (CR). Если ранее вы не определили бизнес-цель, то техника Impact Mapping и её вариация Extended Impact Mapping точно помогут на этом шаге.Шаг 2. Описать PBI в формате «кто, что и зачем»
Я часто использую такой формат описания элементов Бэклога Продукта:- кто — пользовательский сегмент или персона;
- что — краткое описание задачи;
- зачем — бизнес-ценность или ценность для пользователя.
Шаг 3. Разбить PBI в малых группах
Мы сформировали четыре группы по 3–5 человек и отправили их на рабочии станции в опенспейсе, где они в течение 20 минут декомпозировали PBI. Ребята использовали паттерны разбиения и другие техники, в частности, User Story Mapping. Если команды ещё не владеют навыками декомпозиции, нужно провести обучающий воркшоп.
Шаг 4. Представить варианты разбиения
У нас получились четыре варианта декомпозиции. Теперь я хотел, чтобы мы нашли самое ценное в каждом из них. Для этого мы прошлись по каждой рабочей станции, где нам презентовали каждый из вариантов разбиения. На каждой станции мы пробыли не более пяти минут.
Шаг 5. Провести финальную «склейку»
Я попросил Владельца Продукта и нескольких представителей команд сделать финальную «склейку» различных вариантов декомпозиции. Для этого мы принесли все флипчарты и повесили их на стену. Владелец Продукта выбирал наиболее удачные части и размещал их на финальной версии.
Шаг 6. Оценить и приоритезировали полученные фичи
К этому моменту гигантская фича была разбита на более мелкие элементы. Я попросил представителей из каждой команды провести экспресс-оценку при помощи «рубашечных размеров». Затем Владелец Продукта упорядочил все полученные фичи. В итоге мы получили 11 фич, самые приоритетные из которых должны были комфортно поместиться в двухнедельном Спринте.
Шаг 7. Прояснить приоритетные PBI
Каждая группа, взяв одну фичу из верхушки Бэклога Продукта, прояснила её на рабочей станции. Через 20 минут на каждой станции появились:- описание фичи,
- обновлённая оценка,
- приемочные критерии,
- бизнес- и пользовательская ценности.
Шаг 8. Обсудить полученную ценность
Перед закрытием встречи я попросил озвучить полученные ценности и зафиксировать результат на флипчарте. Это были оценки, цель на квартал, полная картина происходящего.Выводы
- Предпочитайте использовать Multi-Team PBR, когда Бэклог Продукта актуализируют сразу несколько команд.
- Всегда начинайте обсуждение PBI со связи с бизнес-целью.
- Декомпозируйте элементы Бэклога Продукта с помощью паттернов разбиения и техники User Story Mapping.
- Работайте в малых группах и форматах мирового кафе, трейдшоу или коктейльной вечеринки.
- Для лучшего взаимодействия используйте бумагу, флипчарты, ножницы или стикеры.
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.
Условия задачи
Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.Что происходит
Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
- возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
- стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
- рабочий процесс перестаёт быть прозрачным.
Решение
Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:- объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
- помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
- научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
- помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
- визуализировать поток работы. Прозрачность — залог успеха;
- устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
- объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Итоги
Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:- декомпозиция работы на небольшие PBI;
- визуализация потока работы в Спринте и поиск основных узких мест;
- устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
- планомерная ликвидация технического долга.