Я собрала несколько вопросов, которые помогут вам пройти утренне-кофейный тест на продакта.

Попробуйте ответить:

1. Умеете ли вы разбивать большую непонятную задачу на маленькие понятные?

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

Например, желания пользователей — ездить на такси по побережью, необходимость бизнеса — заработать 1 000 500 денег в этом году, а возможность команды — написать крутейшего бота в Telegram, нужно превратить в подробно расписанный свод задач, где каждый член команды будет знать, ЧТО нужно сделать и ЗАЧЕМ.

2. Любите ли вы людей?

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

3. Готовы ли вы к постоянному взаимодействию с командой?

Продакт практически постоянно и неустанно отвечает на вопросы: «Зачем мы это делаем? Почему именно так?» Только он (наш любимый и уважаемый продакт) знает ответ на этот вопрос.

4. Готовы ли вы всеми возможными способами изучать желания пользователей?

Суперсила продакта — отделять свои желания от желаний пользователей.

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

5. Вы любите анализировать информацию?

Почему пользователи бросают просмотр видео на YouTube на середине? Почему после добавления новой функции в такси-боте количество поездок сократилось вдвое? Это типичные вопросы, на которые продакт ищет ответы, анализируя данные и делая выводы.

6. Вы готовы из неопределенности выдвигать гипотезы?

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

Например, когда японская Toyota впервые вышла на рынок США, они столкнулись с неожиданным: машины не продавались, потому что в них не было подставок для колы, которые американские покупатели ожидали. Несмотря на это, команда Toyota не отступила, адаптировала продукт и добилась успеха.

7. Вы готовы брать ответственность за свои слова и действия?

Как продакт, вы будете принимать ключевые решения: что разрабатывать в первую очередь, какие функции включать, какие гипотезы проверять.

Выдвинутые гипотезы могут оказаться (и чаще всего оказываются) неверными. Задача продакта — вовремя это понять, признать ошибку и остановить трату времени, денег и сил компании. Эти ошибки не должны вас выбить из колеи на месяц, иначе так и поработать-то не успеете.

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

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

Если же ответы — «нет», напишите, что вас смущает. Разберемся вместе!

Спасибо, что провели это утро со мной.

Обнимаю! ❤️ На связи.

• Определение
• Основные обязанности продакт-менеджера
• Почему продакты важны?
• Важные навыки для старта карьеры продакт-менеджера
• Покорится ли вам продакт-менеджмент?

Задумывались ли вы, почему некоторые приложения становятся нашими любимыми? Почему вам нравится ваш любимый мессенджер с "самолетиком"? Потому что между появлением идеи такого приложения и его появлением в магазине приложений с ним работал продакт-менеджер. Что же он сделал?

В этой статье, дорогой читатель, мы разберем, кто такой продакт-менеджер (продакт-менеджер | продакт-овнер | владелец продукта, менеджер по продукту | product owner | product manager) и чем он занимается.

Определение

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

Основные обязанности продакт-менеджера

1. Понимание потребностей клиентов: продакт исследует рынок, изучает конкурентов и анализирует поведение пользователей, чтобы понять их запросы.
   Пример результата исследования: клиенты хотят изучать английский онлайн.
2. Определение целей продукта: вместе с бизнесом, командой разработки и на основе потребностей пользователей продакт формулирует понятные цели продукта, направляющие процесс разработки.
   Разработать сайт, привлечь 3х преподавателей и 6 студентов, затем создать приложение и привлечь десять преподавателей и 30 студентов.
3. Составление плана развития продукта: продакт определяет последовательность добавления ключевых функций.
   К 15 февраля добавляется возможность залогиниться на сайте, видеозвонки и обмен сообщениями между преподавателем и студентом.
4. Взаимодействие с командой: продакт объясняет разработчикам, дизайнерам, аналитикам и другим специалистам, "что и зачем мы делаем".
   На странице логина предоставляем возможность ввести мобильный телефон и сгенерировать пароль.
5. Непрерывное улучшение: продакт анализирует производительность продукта после запуска, собирает обратную связь от пользователей и отвечает за обновления для повышения удовлетворенности пользователей и прибыли бизнеса.

Почему продакты важны?

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

Важные навыки для старта карьеры продакт-менеджера

1. Коммуникация: умение чётко излагать мысли, договариваться с командой и объяснять любые концепции простыми словами.
2. Критическое мышление: умение анализировать данные, находить корень проблемы и предлагать решения.
3. Клиентоориентированное (customer-driven) мышление: понимание потребностей пользователей и предложение соответствующих решений.
4. Планирование и приоритизация: определение степени важности задач и управление временем, в которое эти задачи будут сделаны.
5. Гибкость и адаптивность: быстрая реакция на изменения в целях проекта, желания пользователей и долгосрочные внешние тренды.
6. Базовые навыки аналитики: работа с данными, умение извлекать и интерпретировать ключевые метрики.
7. IT-словарь и процессы: для старта достаточно понимания терминов, которые употребляются товарищами из IT, а со временем и опытом придет понимание того, как устроены процессы в IT-командах.

Покорится ли вам продакт-менеджмент?

Если вам нравится решать сложные задачи, общаться с людьми и воплощать идеи в реальность, продакт-менеджмент может стать идеальным стартом вашей IT-мечты.

Надеюсь, было полезно!

Если у вас остались вопросы, пишите скорее!

❤️ Ставьте лайки и подписывайтесь.

Обнимаю! На связи.

• 1 шаг: убедитесь, что вам нравится общаться с людьми, или протестируйте ваши soft skills
• 2 шаг: убедитесь, что вам нравится придумывать что-то новое, или протестируйте ваши product skills
• 3 шаг: изучите инструменты анализа рынка, конкурентов и ваших потенциальных пользователей
• 4 шаг: Найдите любимый метод приоритизации
• 5 шаг: Потренируйтесь планировать
• 6 шаг: Прочитайте про продуктовую документацию
• 7 шаг: Изучите, какие бывают продуктовые метрики
• 8 шаг: Протестируйте разные инструменты для работы IT-команд
• 9 шаг: Потренируйтесь быть продактом
• 10 шаг: Будьте готовы всегда знать ответ на вопрос что и зачем вы делаете.

Если вы ещё не в полной мере убеждены, что вы понимаете, кто такой продакт-менеджер, то советую начать со статьи "Кто такой продакт-менеджер?". А если вы уже прочитали эту статью и полностью понимаете, кто это такой, то добро пожаловать!

Все счастливые продакт-менеджеры счастливы по-своему, но начинать, пожалуй, каждый должен одинаково.

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

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

А теперь давайте к делу — к списку шагов, с которых мы рекомендуем начать совсем еще маленьким продактам.

1 шаг: убедитесь, что вам нравится общаться с людьми, или протестируйте ваши soft skills

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

2 шаг: убедитесь, что вам нравится придумывать что-то новое, или протестируйте ваши product skills

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

3 шаг: изучите инструменты анализа рынка, конкурентов и ваших потенциальных пользователей

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

Например, концепция индивидуальной сборки компьютеров компанией Dell стала основой для кастомизации в модной индустрии — и теперь Shein шьёт одежду по запросам пользователей.

4 шаг: Найдите любимый метод приоритизации

Как продакт, вы будете определять в какой последовательности будут появляться улучшения в вашем продукте. Для определения важности задач можно пользоваться различными подходами. Для ознакомления можно изучить популярные — RICE и MoSCoW; или мои любимые — User Story Mapping и Value|Effort Matrix.

5 шаг: Потренируйтесь планировать

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

В IT это называется RoadMap — почитайте, что понимается под RoadMap.

6 шаг: Прочитайте про продуктовую документацию

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

Можно ознакомиться с подходами User Story и Jobs-to-be-Done, чтобы у вас появился ориентир — как может, но не обязана, выглядеть продуктовая документация.

7 шаг: Изучите, какие бывают продуктовые метрики

Когда документация написана, передана команде разработки, и ваш продукт работает, то можно проанализировать, насколько удачной была ваша идея — для этого можно посмотреть на разные метрики вашего продукта.

Например, на сколько процентов увеличилось количество новых пользователей в месяц.

8 шаг: Протестируйте разные инструменты для работы IT-команд

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

Каждый шаг, описанный в этой статье » это задача на вашей доске.

9 шаг: Потренируйтесь быть продактом

Представьте, что к вам пришёл «бизнес» — Павел, у которого есть разработчик и идея создать мессенджер.

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

Это будет примером вашей продуктовой стратегии и продемонстрирует работодателю ваши критическое мышление, аналитические навыки и умение формулировать мысли.

10 шаг: Будьте готовы всегда знать ответ на вопрос что и зачем вы делаете.

Надеюсь, было полезно!

А если у вас остались любые вопросы — задавайте их скорее.

❤️ Ставьте лайки и подписывайтесь на телеграм-канал

Обнимаю! На связи

• Введение: Бэклог Шредингера
• Волки и овцы
• Неравномерная загрузка
• Пузырь сверхважности
• Глобальные проблемы: Кто здесь главный?
• Сферические приоритеты в вакууме

Введение: Бэклог Шредингера

Дорогие читатели, добро пожаловать в шестую главу нашей эпопеи.

Ссылка на предыдущие главы тут

В этой главе мы обсудим проблему “Бэклога Шредингера” или “Списка задач, которого не существовало”. Далее под бэклогом будем понимать отсортированный по приоритету список задач.

Что получите вы?
Вы узнаете, почему важно обсуждать приоритеты не только с собой любимым, но и с командой.

Волки и овцы

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

Формально процесс выглядел так: бизнес дает X сверхважных задач, команда начинает их выполнять. В момент N, когда сделана только часть из X задач, появляется еще Y сверхважных задач. Для бизнеса приоритет всех задач массива [X; Y] одинаков — сверхважный. Поэтому команда сама решала, какую задачу делать первой, исходя из загрузки команды и готовности архитектуры.

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

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

Однако результаты работы показали, что бизнес недоволен сроками и качеством разработки. Тогда провели исследование и часть проблем удалось решить, изменив подход к оценке задач (см. главу 5), но это не решило проблему недовольства бизнеса.

Неравномерная загрузка

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

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

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

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

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

Пузырь сверхважности

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

Приоритет сверхважных задач определялась исключительно личными потребностями владельца бизнеса, а их ценность зависела от его настроения.

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

Ни одна реализация сверхважной задачи не привела к выходу на прод.

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

Заранее продолжительность актуальности неизвестна, потому что никаких внешних признаков определения такой актуальности не существовало.

Это не были показания внутренних метрик, это не были внешние сезонные факторы - актуальность зависела только от внутренних ощущений бизнеса и личных отношений с основным инвестором или потенциальными клиентами.

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

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

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

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

Глобальные проблемы: Кто здесь главный?

Проблема «несуществующего бэклога» вновь напомнила о фундаментальных проблемах The StartUp:

1. Неправильное понимание ролей в команде.
2. Отсутствие коммуникации между бизнесом и командой.

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

Сферические приоритеты в вакууме

Какие выводы будут полезны вам, дорогие читатели?

Разговаривайте с бизнесом, коллегами, сотрудниками. Старайтесь делать так, чтобы все находились на одной волне (on the same page).

Приоритеты — это относительная величина (а не то, что вы подумали, прочитав заголовок). Если у вас все задачи — блокеры-сверхважные, значит у вас все задачи неважные пришло время пересмотреть приоритеты.

Полезно учитывать мнение всех заинтересованных сторон при определении приоритетов задач: явное распределение веса голосов всех заинтересованных сторон в команде и подсчет средневзвешенного приоритета задач может на первом этапе решить проблему приоритезации.

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

На этой ноте завершим главу про приоритеты и бэклог.

Спасибо, что дочитали! Делитесь, как вы определяете приоритеты в своих командах.

❤️Ставьте лайки и подписывайтесь.

Обнимаю! На связи.

• Введение
• Реальность команды
• Неоправданные ожидания бизнеса
• Новый подход: сроки от менеджера
• Почему же сроки, озвученные СТО, не выполнялись
• В оценку надо было включить всех участников процесса
• Оценки должны озвучивать исполнители
• Заключение

Введение

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

Почему из всех проблем, которую мы обсудили в Главе 4, была выбрана именно эта проблема? Она существовала в компании практически вечно и попытки её решения в The StartUp — это квинтэссенция всех других проблем.

Ссылка на предыдущие главы тут

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

Реальность команды

Что происходило в команде после появления новой задачи от бизнеса?

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

То есть новая задача проходила следующий путь: через несколько дней она попадала к дизайнерам; через несколько недель — к аналитикам, через несколько месяцев — в разработку. После этого: 1–3 недели на разработку, тестирование, приемку операционной командой.

И вуа-ля! — задача попадала на прод спустя полгода.

Неоправданные ожидания бизнеса

А как же для бизнеса выглядел этот черный ящик, в который попадала его задача?

Новая идея передавалась команде, и, поскольку до этого команда «ничего не делала», она тут же бралась за задачу. Но вуа-ля, разработка занимала полгода!

Через полгода бизнес и менеджеры встречались на демо. И у бизнеса был закономерный для его картины мира вопрос: «Почему задача делалась полгода?»

Ответы варьировались в зависимости от того, кто из менеджеров был на демо: «Разработка долго делала», «Дизайнеры долго рисовали», «Аналитики не могли выбрать решение».

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

Но что забывали обсудить на таких встречах? Какой срок ожидал бизнес? С какого момента этот срок отсчитывался?

Новый подход: сроки от менеджера

После нескольких таких неприятных разговоров бизнес понял: комфортнее обсуждать сроки с CTO. Он был спокоен, умен и разделял ценность бизнеса — работать по 25 часов в сутки.

CTO озвучивал: «Это займёт неделю». Бизнес рад, что фича будет готова через неделю. CTO рад, что бизнес доволен.

Оставалось сделать так, чтобы “дизайн + проработка + разработка +  тестирование + приемка” заняли неделю.

Сколько раз за 5 лет получилось это сделать? Правильный ответ найдете в нашей новой книге: “Ровно 0”.

Почему же сроки, озвученные СТО, не выполнялись

Причины были следующими:

1. Не был учтён Roadmap: задача не оказывалась первой в списке (last in — last out).
2. Разработка оценивалась не с исполнителями, которые знают нюансы архитектуры и кода, а менеджером, который сам не пишет код.
3. Не было учтено время на проработку до и тестирование после разработки.

Игнорирование этих факторов позволяли краткосрочно порадовать бизнес, а долгосрочно снова попасть на демо, где бизнес недоволен сроками и кто-то в этой жизни неправ.

Но команда постепенно осознавала все проблемы и находила решения.

В оценку надо было включить всех участников процесса

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

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

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

“- Может выкинуть их вообще?

- А может и выкинуть.

- А вдруг что-то разломается

- А вдруг нет”

Самым убедительным аргументом для бизнеса стал опыт аутсорс-разработки, где аналитики и архитекторы отсутствовали, и всё было жутко неприспособленным к изменениям, к тому же даже СТО был не готов от них избавиться.

QA-инженеры были самым непонятным и постоянно вызывающим полнейшее недовольство фактором. “Почему вообще надо что-то тестировать? Почему разработчики сами не тестируют? А самое интересное — уже если тестируют, то почему все равно есть баги."

Короткий аргумент был такой: “пробовали без куашников, качество было плохое”.

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

Примерно через год после первой нереалистичной оценки СТО начали учитываться все этапы разработки. Это был прорыв: бизнес понял, что команда разработки состоит не только из разработчиков.

Но первоначальная проблема осталась. Сроки всё равно не выполнялись.

Оценки должны озвучивать исполнители

Оценки — это тема достойная дискурса и мы его проведем в отдельной статье. Здесь мы принимаем как данность: бизнес начал спрашивать оценки и их нужно было давать.

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

Да простит меня наша команда, но это был совершенно дивный процесс, как в фильмах: все сидят у компьютеров, задают друг другу перекрестные вопросы, пытаются понять, что из себя представляет эта фича. Для меня, как для продакта это было очень мило, потому что “я не несла ответственности за эти циферки в WBS”, — думала я до первого раза, пока не стала одним из тех менеджеров, который стал ответственный “за всё.”

В итоге появлялись прелестные детализированные WBS; бизнес мог сразу понять, где можно сократить сроки или затраты; команда получала ясность по задачам.

Иногда в оценке были указаны конкретные люди, потому что мы знали, что Сережа лучше всех разберется с приколами Safari.

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

Но бизнес требовал оценки, и команда давала ему то, что удовлетворяло его потребности.

Частично такая качественная оценка, конечно, решала проблему сроков: у бизнеса больше не было иллюзии, что задача попадёт на прод через неделю. Кроме того, некоторые фичи меняли свой изначальный облик, потому что оказывались слишком дорогими.

Постепенно детальная оценка стала рутиной и вошла в культуру проекта.

Заключение

Внимательный читатель заметил, что мы не обсудили проблему с Roadmap. Сделали мы это намеренно, потому что неумолимо следуем тайм-лайну. Проблема RoadMap — не совпадающие приоритеты бизнеса и команды, дошла до команды позже. Вот поэтому и разберем мы ее в последнюю очередь - как раз в следующей главе.

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

❤️Ставьте лайки, задавайте вопросы, подписывайтесь.

Обнимаю! На связи.

• Введение
• Бедный CEO, богатый CEO
• Бизнес и его новая дифференцированная команда
• Бизнес все еще недоволен командой
• Глобальные заблуждения команды
• Последствия
• Заключение
• Непрошенный совет

Введение

Наш The Startup со ставками мы оставили в состоянии, когда завершился Чемпионат Мира по футболу - 2018.

Ссылка на предыдущие главы тут

В новой главе нашего цикла вы, дорогие читатели, узнаете о "дворцовом перевороте" против CEO, установлении нетипичного для современного IT процесса и последствиях, которые возникли из-за всего этого.

Бедный CEO, богатый CEO

В предыдущей главе мы познакомились с CEO, большим поклонником Agile-подхода и многочисленных встреч. По доступной нам информации, именно встречи крайне раздражали коллег, потому что мешали им работать работу.

Коллеги, а именно CTO, CPO и арт-директор, имея доступ к телефонным и личным встречам с владельцем бизнеса, пытались донести до него, что CEO не удовлетворяет требованиям классного менеджера и не выполняет свои обязанности.

Когда появится больше достоверной информации о том, что еще смущало коллег в работе CEO, напишем дополнительную главу.

После нескольких месяцев методичного давления владелец бизнеса принял решение уволить СЕО.

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

Вот так свершился "дворцовый переворот", и первый CEO покинул проект.

Бизнес и его новая дифференцированная команда

После свержения CEO началась новая эра для всех участников проекта. СТО стал фаворитом основателя, арт-директор остался важной, но не основной фигурой в команде менеджеров, а CPO испытывал на себе сложности корпоративной политики.

Бизнес все еще недоволен командой

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

Увольнений не происходило, но все же это было крайне изматывающе!

Будучи внутри, казалось, что вокруг царит хаос, и только ты знаешь, как правильно: "Только так и никак иначе" — ведь это ты придумал.

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

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

Итак, проблемы и попытки их единоличного решения:

Проблема 1: Бизнес недоволен скоростью разработки и отсутствием понятных сроков.

CTO, пытаясь удовлетворить потребность бизнеса в сроках, озвучивал нереальные сроки, которые не могли быть выполнены.

Проблема 2: Недовольные потенциальные клиенты, которым не хватало всего "одной функциональности".

Бизнес без лишнего промедления после очередной перезентации продукта клиенту отправлял задачу менеджерам, передвигал RoadMap, функциональность разрабатывалась, а клиент всё равно не приходил…

Глобальные заблуждения команды

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

Первое: команда решает задачи бизнеса

Проблема, возникающая из-за этого заблуждения: разное понимание ролей в команде.

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

Все попытки предложить более оптимальное решение приводили к диалогу: "Я в бизнесе ставок 30 лет, а вы?"

На протяжении примерно двух лет лучшие умы IT-мира занимались поиском оптимальных решений для проблемы, озвученной бизнесом. Но каждое демо заканчивалось вердиктом: "Очень долго делали, и всё надо переделать."

Второе: у каждого есть своя зона ответственности

Внутри IT-команды казалось, что у менеджеров есть свои роли, однако CTO диктовал аналитикам, как писать требования; дизайнер, благодаря особым отношениям с бизнесом, вмешивался в технические решения, а продакт фактически не влиял на приоритеты.

Почему так происходило? На встречах с бизнесом менеджерские роли были формальными: для бизнеса никто не отвечал за конкретную часть продукта, но каждый должен был объяснить, "почему эта фича была сделана именно так, почему за такой срок", чтобы владелец мог найти виноватых и их уволить. Однако, в итоге, никто не нёс ответственности ни за что. Все расходились с новыми задачами и порцией "мотивации".

“Мотивация” - наставления, в которых каждый менеджер, вся команда и конечный результат подвергались критике и стимулировались порцией санкций. Пример красочной мотивации: “Если в следующий раз снова получится плохо, закрою самого сильного бэкендера в кабинете, пока он не перепишет всё, как мне надо…"

Третье: план бизнеса = стратегические цели

Примерно раз в квартал бизнес проводил неформальные встречи с менеджерами, на которых формировался новый список приоритетных задач. Эти задачи подавались как ключевые: их реализация обеспечит полноценный релиз на прод и компания начнет получать ненулевой доход.

Менеджеры на основе этих задач составляли стратегический план — RoadMap на 3–12 месяцев, который представляли команде. Вооружившись этим планом, команда начинала работу.

Однако на следующей встрече с бизнесом (которая могла пройти через месяц или полгода) выяснялось, что:

• часть задач RoadMap уже потеряла актуальность, так как их нужно было реализовать сразу после первого обсуждения, а не спустя месяцы;
• другие задачи откладывались на неопределённое будущее, «когда будет свободное время»;
• приоритет смещался на новые задачи.

Цикл повторялся: команда каждый раз принимала новый RoadMap как устойчивый план, но он неизменно менялся.

Последствия

К чему это все привело?

1. Затраты на переделывания: технические решения, подвергавшиеся постоянному изменению, были затратными и не приносили ожидаемого эффекта.
2. Гонка приоритетов: пока команда только начинала разбираться с задачами, бизнес уже ожидал готового результата.
3. Недовольство и непонимание: бизнес не получал того, что хотел, а команда не имела чёткого понимания истинных потребностей бизнеса.
4. Отсутствие роста: новые клиенты не появились, и финансовые ожидания не оправдались.

Заключение

Стало ли лучше, когда команда начала осознавать свои заблуждения? Нет, потому что глобальная проблема — отсутствие открытого диалога — осталась с проектом навсегда.

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

Непрошенный совет

Давайте определять границы ответственности и доверять друг другу. Давайте согласовывать все ожидания заранее.

А главное — давайте постоянно сверять часы, чтобы не пришлось всё начинать сначала.

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

❤️ Ставьте лайки и подписывайтесь.

Обнимаю! На связи.

А вы знаете про классификацию компаний, которая разделяет компании по стилю их управления и принятия решений?

Вот тут можно подробно про это почитать, если будет интересно.

Какие я бы сделала выводы после работы в красной компании: я больше не хочу работать в такой компании, а если честно, то:

1. Определяйте границы ответственности в команде и в компании
2. Давайте в этой зоне ответственности свободу действий
3. Договаривайтесь об всем вышеперечисленном заранее
4. Постоянно "сверяйте часы", чтобы все участники были уведомлены о курсе вашего корабля.

А в каком типе компании вы работаете?

В исторический момент для нашего проекта, когда показалось, что нашу миссию начали понимать, я решила начать писать про проект NewBie. Этот цикл статей под названием «Игра в StartUp» будет посвящен всем нюансам жизни стартапа и его создателей [иногда больше похожих на слуг]. Вы узнаете, как появилась идея, как она развивается в режиме Live, какие решения принимаются, и почему именно такие (ответ на этот вопрос будет не всегда). Вместе с нами вы испытаете все взлеты и падения, которые несет с собой жизнь стартапа.

Какую пользу от всего цикла получишь ты, дорогой читатель? Честный список ошибок, которые мы уже успели допустить и их ретро-разбор. "Надо быть реалистом" — пожалуй, станет основным лейтмотивом нашего повествования. Но, наверное, самое ценное в этом — понимание, что в своих неуспешных (или не сразу успешных) стартапах ты не одинок.

Немного истории...25 сентября 2024 года исполнился ровно год с начала разработки NewBie, продуктовая проработка началась в июне 2023. Я хотела начать этот цикл раньше, чтобы это было действительно в режиме реального времени, но его [времени] не было. Сейчас времени тоже нет, но уже стоит начинать писать, а то все забудется.

А что собственно со статусом?

Чтобы было ясно в какой точке сейчас находится проект, зафиксируем:

• MVP продукта сейчас на проде (чтобы вас не отвлекать, ссылки дам в конце статьи),
• на стартап было потрачено несколько десятков тысяч долларов, заработано ровно 0 долларов,
• у нас есть активный аккаунт в социальной сети с картинками (не хочу, чтобы были проблемы с публикациями на русском языке),
• у нас есть маркетинговая стратегия MVP и грандиозные планы.

И самое главное  — у NewBie есть маленькая, но уже такая взрослая и профессиональная команда — люблю каждого из них.

Думаю ли я, что мы станем миллионерами на нашем проекте? Честно говоря, нет. У нас даже AI-то нет…и мы скорее живем вопреки AI, а не благодаря.

Верю ли я, что наша идея добрая, светлая и справедливая? Безусловно, да. Всем сердцем я верю в нашу идею.

Идея проекта

Наша идея глобально — проверять правдивость информации в интернете и за его пределами, чтобы делиться этим с миром.

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

Если чат GPT расскажет: “Гарвард провел исследования мозга человека и выяснил, что 1 шоколадка в день увеличивает количество нейронов в мозге на 10 000”. И даже даст ссылку на это исследование.

Как убедиться что хотя бы что-то из этого правда? NewBie версия 2.0 проанализирует информацию и покажет доказательства, оставляя только правдивые факты.

Most viable product

Но начинать сразу с глобальной идеи мы не стали, да и не смогли бы. В рамках MVP мы сузили предметную область и целевую аудиторию: сосредоточились на проверке правдивой информации об оффлайн-бизнесах в Буэнос-Айресе.

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

Для проверки гипотезы мы предлагаем свой метод предоставления независимого объективного описания ресторанов в Буэнос-Айресе.

Кому нужна версия MVP: жителям города, которые хотят удобно найти для себя “именно то качественное место”.

Анонс следующих глав

В следующей главе вы узнаете, как было решено заниматься запуском MVP: поговорим об продуктовой проработке и первой (и пока единственной) команде разработки.

А вы пока переходите по ссылкам ниже, задавайте свои вопросы и комментируйте прочитанное.

Спасибо, что дочитали! ❤️

Жду вас в следующих главах.

Ссылочки

MVP стартапа

Аккаунт с картинками

Хочу поделиться феноменом, который меня чрезвычайно удивил, — “сбор и анализ обратной связи”.

Для меня, как для человека, крайне недоверчивого к миру больших денег и большого бизнеса, было совершенно очевидно, что сбором и анализом обратной связи занимается 90% бизнеса, и из них:

• половина делает это [анализ], чтобы потом больше продать (ни в коем случае не для улучшения продукта);
• еще 40% игнорируют ее [обратную связь] и отправляют все наши лайки, комменты и отзывы в замечательную папку “Корзина”;
• и только 10% из 90%, то есть 9% всего бизнеса, по моим оценкам, основанным на недоверии к добропорядочности бизнеса и наблюдении за ним, добросовестно собирают обратную связь от пользователей и анализируют её с целью улучшить продукт.

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

“Ну хватит томить”, скажете вы.

История вот в чём: сервис Canva [не реклама, хотя хотелось бы] начал анонсировать повышение цены с 1 декабря 2024 года примерно с августа 2024 года (за четыре месяца до повышения).

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

И вот 16 октября у меня в профиле Canva появляется новое уведомление, уже не такое яркое и красочное, в котором говорится, что они “отменили повышение цены”.

Я захожу на инфо-страницу и вижу там своими собственными глазами, что действительно отменили. Отменили, представляете?

Не знаю, насколько пресс-служба Canva откровенна в своем письме, но в нем говорится [перевод близкий к оригиналу]:

“Мы хотели перевести вас [команды до 5 человек] на более дорогой тариф, потому что ценность нашего продукта за последние 4 года значительно выросла. Однако, выслушав обратную связь от пользователей, мы отказались от этих изменений.”

Эта история так меня впечатлила, что я снова начала верить, что мои оценочные 9% действительно существуют.

Спасибо всем кто дочитал до конца!

Вы герои!

Обнимаю! На связи.

• Введение
• Команда родилась
• Новый менеджмент
• Как идеи бизнеса превращались в продукт
• Все команды счастливы одинаково
• Приоритизация и другие уроки ЧМ-2018
• Заключение

Введение

В этой главе нашей эпопеи расскажу про то как выглядела первая in-house команда разработки нашего уже родного The StartUp, какие у нее были цели и какие результаты получились, а также посмотрим, что делал бизнес и как поменялось его отношение к разработке.

Ссылка на предыдущие главы тут

А что получите вы, мои дорогие читатели? Вы получите опыт построения IT-команды с нуля, узнаете какие 50 оттенков менеджеров бывает и конечно вместе со мной заглянете за кулисы VIP-беттинга.

Команда родилась

Создание своей команды разработки началось с найма CEO, по совместительству большого поклонника Agile подхода. CEO, благодаря своим обширным социальным связям в IT-сообществе, собрал первую команду: аналитик, дизайнер и СТО. А СТО пригласил первых разработчиков, CPO и команду тестирования. CPO, в свою очередь, пополнил команду своими аналитиками и пригласил в команду арт-директора.

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

Бизнес хотел знать в лицо буквально каждого сотрудника в новой команде.

У бизнеса был запрос на лучших специалистов, и, по моему мнению, этот запрос был выполнен на 100%. Команда была великолепной. Обнимаю каждого!

Новый менеджмент

Процесс общения команды с бизнесом происходил через менеджмент: CEO, CTO, CPO и арт-директор лично и часто общались с основателем. Остальная команда (за исключением операционной) находилась в другой локации и встречалась с владельцем бизнеса 1–2 раза в год, когда всё становилось плохо. Встречи с ТОП-менеджментом на 70% носили характер “про жизнь”, но после каждой встречи команда выходила с важными новыми наставлениями и порцией мотивации: улучшить процесс, ускорить разработку, срочно внедрить новую фичу, нарисовать новый дизайн и переделать старый. Основатель бизнеса де-факто был владельцем продукта — все идеи новых фичей, которые шли в разработку, исходили только от него.

У каждого из менеджеров команды были свои "супер-силы".

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

"Ну что ты, в самом деле, пристала к этим встречам?" - скажет внимательный читатель. "У меня недостаточно литературного таланта, чтобы объяснить на сколько сильно CEO любил встречи", - отвечу я.

CTO читал много книг и первые пять лет был "женат" на работе. Наш герой хотел выстроить процесс разработки так, чтобы всё было быстро и дешево, а главное — чтобы все работали по 25 часов в сутки. До прихода в нашу историю CTO работал на галере, и практики микроменеджмента галеры активно применялись в команде.

CPO, по сути глава аналитики, хотел, чтобы work-life balance способствовал созданию качественного продукта, эффективным демо для бизнеса и гармонии в команде. Он защищал сотрудников от нападок CTO и владельца бизнеса. CPO стремился разобраться в прикладной области и много общался с операционной командой.

Иногда казалось, что мы все его рабочие дети — такая витала забота.

Арт-директор был неприклонен и влюблен в дизайн. Единственный, кто мог оспорить готовый дизайн, был основатель. У остальных не было ни единого шанса. “Долго, дорого, почти невозможно”, - никакие аргументы не действовали на арт-директора, и дизайн не менялся ни на 1 пиксель.

Как идеи бизнеса превращались в продукт

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

То, что в начале кажется хаосом, после многократного повторения становится процессом.

Кому бы ни была вброшена задача, сначала рисовался детальный дизайн, поскольку в процессе его согласования суть фичи могла измениться на 180 градусов. Буквально каждый пиксель клиентского дизайна согласовывался с бизнесом, чаще всего в несколько итераций. На таких согласованиях иногда присутствовал CPO, СТО или оба, чтобы быть в курсе запросов бизнеса из первых уст.

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

Дальнейший процесс был стандартный: разработка -> QA -> UAT операционной командой -> PROD для демонстрации бизнесу -> сбор многочисленных замечаний -> возврат на новый круг.

Детально процесс разработки сформирован не был, но глобально все двигалось в сторону Scrum с итерациями, синками и ритуалами.

Основной целью первой новой команды разработки было подготовить продукт к Чемпионату Мира-2018. На это было примерно полгода.

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

Все команды счастливы одинаково

Операционная команда, конечно, тоже готовилась к Чемпионату, больше морально. Ей предстояло не просто провести чемпионат, а продемонстрировать продукт клиентам в его лучшем виде.

Операционная команда нестрого разделилась на 2 группы: беттинг и IT. Беттинговая часть команды готовилась принимать ставки в прематче и лайве, и общаться с клиентами через чат. А айтишная часть команды занималась подготовкой требований (я бы назвала это PRD: начальный уровень), которые впоследствии превращались аналитиками в задачи на разработку.

Чемпионат Мира-2018 - это концентрированный стресс 15 часов в сутки

Количество клиентов на ЧМ увеличилось в 10 раз. Неопытная операционная команда не стала идеальным слаженным организмом, но ставки мы принимали...чаще всего в чате, потому что продукт еще не был совершенным. Прием ставок в чате, когда матч уже идет (в лайве) - это как лететь самолете в турбулентности - тебя мотает, а ты ничего не можешь с этим поделать, и ко всему прочему, на тебя кричит пилот.

Жизнь операционной команды усложнялась, на тот момент, еще сырым бэк-офисом, из-за чего было решено дублировать все ставки в Excel. В последний день чемпионата благодаря этому документу и двойной проверке была выявлена ошибка, которая сэкономила компании $150,000.

Приоритизация и другие уроки ЧМ-2018

Для операционной команды любая проблема на проде казалась критичной. Каждый день чемпионата начинался с сообщений команде разработки о проблемах на проде. Источника этих сообщений прозвали "Алина-блокер на проде" (да, дорогой читатель, это имя неспроста кажется тебе знакомым). Команда разработки героически помогала находить обходные пути всем проблемам. Мы справились: релизились на прод всего пару-тройку раз за время ЧМ.

Чемпионат мира выявил проблемы в продукте и показал направления для улучшений.

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

Заключение

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

Операционная команда (по крайне мере та ее часть, которая не ушла в IT c головой) перестала быть самоназначенными аналитиками, продактами и тестировщиками, а стала источником истины в предметной области и стала по-настоящему принимать ставки.

Бизнес не был доволен качеством и скоростью разработки, поэтому было решено масштабировать продукт, увеличивать количество разработчиков и увольнять неэффективных менеджеров.

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

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

❤️ Ставьте лайки и подписывайтесь.

Обнимаю! На связи.