Менеджер от боженьки


Channel's geo and language: Belarus, Russian
Category: Technologies


Проджект менеджмент в IT.
Рома Ковалевский — о современных деливери практиках, продуктовой разработке, эджайле и как стать классным менеджером.
Сообщество проджект менеджеров: @pm_sovet
Для связи: @romkovalevsky

Related channels

Channel's geo and language
Belarus, Russian
Statistics
Posts filter


Как оценки увеличиваются х3 на пустом месте (пример)

Недавно оценивал большой проект. Чтобы его сделать, надо обновить десятки сервисов, принадлежащие 12 командам.

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

Ну-ну. В итоге суммарная оценка 12 команд - 50 инженереных недель. А оценка спецназа - 18!

Работа одна и та же, а разница в 3 раза, откуда такая разбежка? Причины, на мой взгляд, такие:

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

2\ Чем меньше людей в проекте, тем меньше времени уходит на коммуникацию и тем быстрее идет работа;

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

3.8k 0 27 6 110

#реклама

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

Две результативные программы по карьерному росту:

1. Карьерное сопровождение – для тех, кто хочет найти новую работу и заполучить крутой оффер.

2. Карьерный трек – для тех, кто хочет прокачаться в профессии, стать более крутым профессионалом, подготовленным и востребованным потом выйти на рынок труда.

Что под капотом?

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

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

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

Оставить заявку на консультацию можно — здесь.


Быстрое ревью документов: как в Амазоне
 
Кто хоть раз просил CPO поревьювать документ с новой инициативой, знает, что напомнить о просьбе придется минимум пару раз. Если компания большая, и стейкхолдеров у инициативы много, на простое ревью легко уходит 2-3 календарные недели. Потому что у каждого сейка таких просьб по нескольку в неделю.
 
Увидел новую технику, как получить фидбек на документ быстро:
 
➡ собираешь всех на мит
➡ 5 минут рассказываешь про инициативу
➡ все садятся читать и комментировать док, выключают камеру
➡ когда прочитали, включают камеру обратно
➡ оставшееся время проходитесь по комментариям, спорите, определяете следующие шаги.
 
В таком варианте ты как бы бронируешь время человека под ревью, добавляя инвайт в его календарь. В итоге результат у тебя на руках всего за час, а времени потрачено плюс-минус столько же. Обсуждение тоже идет хорошо, потому что народ загрузил инициативу себе в оперативную память.

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


Как выбрать, что рефакторить - ч.2 анализируем код

Представьте, что ваш стартап пережил фазу бурного роста и СТО решил, что пора побить монолит на сервисы поменьше. Сделал классную презу, заручился поддержкой СПО и тимлидов и получил зеленый свет. С чего начать такой проект? Какой сервис взять в работу первым? Где наибольшая ценность от рефакторинга?

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

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

Сложность - это объем логики принятия решений в функциях исходного кода. Ее можно узнать, подключив сервисы вроде CodeScense или SonarQube. И хотя существуют различные способы, как ее подсчитать, самый популярный из них - цикломатическую сложность - придумали еще в 70-х и используют до сих пор.

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

Окей, допустим, таких файлов 100 из 300. Но мы же не будем с ходу переписывать 30% проекта. Какие из них прям самые невыносимые?

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

Функционал вроде Настроек, Логаута, Смены пароль, меняются редко. Даже если в нем высокая сложность, его обслуживание стоит недорого. А раз так, то и снижать эту стоимость нет смысла. Про такой код говорят “Работает - не трогай”.

И наоборот, в фиче Урок Йоги продакт постоянно ставит новые эксперименты. Если в ней высокая complexity, то с каждым юзкейсом программистам все труднее и труднее писать новый код и менять растущие в объеме файлы. Это выливается в растущие оценки и долгий поиск багов.

Такие фичи стоит приоритезировать для рефакторинга в первую очередь.

————————

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


Как выбрать, что рефакторить - ч.1 оцениваем пользу

TL;DR

На техдолг нужно смотреть, как на обычные фичи - с точки зрения ценности и метрик. Альтернативный вариант, если это невозможно - посмотреть “что болит” в коде. Самым полезным для рефакторинга будет код, удовлетворяющий двум условиям: 1) высокая complexity 2) часто меняется.

————————

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

Как понять, какой рефакторинг стоит брать в работу, а что можно отложить на потом?

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

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

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

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

————————
О других классических методах приоритезации читайте в папке с топ продуктовыми каналами.


Границы системы

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

Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”

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

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

2️⃣ Пройтись по всем экранам приложения. Дизайнеры часто делают карту всех экранов со стрелочками-переходами, тоже полезная вещь.

3️⃣ Выписать список сервисов и SDK, которыми пользуется прила. Здесь снова невидимые штуки вроде хостинга медиа файлов. Особенно важно найти платные, т.к. за счета от них ПМа тоже будут спрашивать.

4️⃣ Найти точки интеграции с другими командами. Бывает, что вашим сервисом для обрезки фоток пользуется соседняя команда, которая пилит свой продукт на вашей технологии. Если этот сервис упадет, то пострадают не только ваши пользователи, но и соседний продукт - к этому лучше быть готовым.

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

А какие у вас лайфхаки?

----------

UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке;

12.3k 0 119 14 164

Критический путь

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

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

Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).

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

Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.

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

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

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

Задержки с бекендом и пресс-релизом для нас не так важны - они не на критическом пути. Даже если они задержатся, это не повлияет на дату завершения фичи.

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

12.6k 0 139 27 142

Метод освоенного объема (EVA)

Метод освоенного объема (Earned Value Analysis) - техника из PMBoK, которую используют для отслеживания прогресса. С ее помощью ты ответишь на 2 главных вопроса проджект менеджмента, которые задают на любом проекте:
❓успеваем ли мы в срок и
❓вкладываемся ли в бюджет.

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

Проще всего понять, как работает EVA на примере.

Допустим, у нас проект из 8 задач, которые надо сделать за 4 дня. Мы прикинули, что будем делать по 2 задачи в день. На третий день по факту сделано 4 задачи, на которые ушло 28 часов, при первоначальной оценке 32 (см. колонки Planned value и Actual Cost).

Что можно сказать о проекте? Для этого посчитаем 2 показателя:

CPI - индекс успеваемости по бюджету (cost performance index). Здесь он равен 1,14, значит, в бюджет мы вкладываемся. И наоборот - если CPI < 1, значит, в изначальный бюджет мы не попадаем.

SPI - индекс успеваемости по расписанию (schedule performance index). В примере он 0,44, значит, в расписание мы не попадаем, причем сильно. Аналогично, если SPI > 1, значит, мы идем с опережением графика.

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

Поиграйте с оценкой и фактом во второй вкладке, чтобы лучше понять, как работает CPI и SPI.

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

На проектах с относительными оценками EVA не особенно применим*, потому что у каждой задачи есть только planned значение - оценка в стори поинтах. Мы не считаем, сколько реально стори поинтов она заняла, поэтому не можем вычислить затраты (actual cost).
💬Если вам удалось прикрутить EVA к относительным оценкам, поделитесь в комментах, как это работает. В первом комменте расскажу одну реализацию, которую видел сам.

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

13.6k 3 340 26 130

Карта клиента

С некоторыми клиентами работать одно удовольствием. А бывает, попадаются трудные личности.

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

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

Иллюстрации: Анастасия Вишневская.

13k 2 234 20 271

Соцпакет: сажаем деревья на годовщину работы

Одна из плюшек в HelloFresh - за каждый отработанный год компания сажает одно дерево.

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

Они высаживают саженцы в Эфиопии, Уганде, Танзании и других отдаленных местах планеты. При этом привлекают супер незащищенные слои местного населения, позволяя им немного заработать. В общем, все в плюсе.

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

------

Кстати, программа Apple, по которой они хотят стать carbon-neutral к 2030 году, тоже состоит из высадки деревьев, чтобы компенсировать загрязнения от производства айфончиков.


#реклама_по_любви

Стратоплан был моим первым обучением менеджменту. В то время Орлов и Панкратов учили классическим штукам: типы личности Адизеса, матрица доверие \ прозрачность, как делать классные презентации. Супер актуальные скилы на все времена.

Теперь они заточили классическую программу под ИТ специфику и сделали курсы для тимлидов и СТО. И приглашают нас с вами на бесплатный интенсив. (Потом, понятно, что-то продавать будут, но это потом!).

Детали:

С 22 по 25 января, Школа менеджмента «Стратоплан» проводит открытые, бесплатные практические курсы — Teamlead:201 и СТО:201.

На них будут разбирать практические кейсы и упражнения, как в жизни:

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

Обучение проходит каждый день, с 18 до 21 МСК.

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

👉Регистрация на Teamlead:201

👉Регистрация на СТО:201


Год в европейской продуктовой компании

Прошел 1 год, с тех пор как я работаю в HelloFresh.

Ниже я описал свои впечатления и объяснил, чем работа в Европе отличается от СНГ.

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

- Нельзя пукнуть без документа и данных
Хочешь сделать новый дэшборд? Переписать кусок легаси? Напиши документ. Документ нужен, чтобы найти слабые места в твоей идее и решить, стоит ли тратить на нее время. В документ очень важно включать данные. Если ты хочешь решить проблему, для который пока нету данных - скорее всего, ее никогда не возьмут в работу. У меня было так, когда я не смог собрать данные о том, как краши влияют на конверсию. Бывает, что найти данные труднее, чем решить задачу. Тогда это создает ненужное, на мой взгляд, усложнение. Но в общем случае помогает уверенно ответить на вопрос “а не херню ли я делаю”.

- Испыт 6 месяцев,
зато потом фиг выкинешь. А если ты отработал год и потом лишился работы, тебе платят что-то типо 70% твоей зп в течение 6 месяцев, пока не найдешь новую (за точность цифр не ручаюсь, но принцип такой). Правда есть еще PIP и hire to fire. Напишу про это побольше, когда разберусь в нюансах.

- В менеджменте нет случайных людей
Все без исключения менеджеры моего уровня, с кем я сталкивался - супер крутые спецы. Половина из них в нашем регионе легко были бы на позиции директора по продукту или разработке в небольшой компании на 50-200 человек. Меня ни разу не посещала мысли “как тебя до сих пор не уволили с такими софт скиллами?”, что, к сожалению, иногда случалось в Минске. Зато много раз думал “каким фигом ты успеваешь столько всего делать?”. Как следствие, здесь прямо ощущается конкуренция за повышение, ресурсы, приоритеты.

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

- Топ менеджмент (директоры, vp) = топ спикеры
Они рассказывают о решаемых проблемах, как на тед толке. Все супер последовательно, четко, понятно, резонно. Не видел ни одного топ менеджера, который бы бэкал и мэкал. Иногда есть ощущение, как будто смотришь предвыборную кампанию. Это заметно даже в сглаженных формулировках, например:
- Lastly, we’ve got a higher skip rate on stand ups;
- We received limited cooperation on the project.

- Большинство проблем все равно те же
Работа в Европе все равно на 90% такая же, как у нас. Нету такого, что "забудьте все, что вы знали до этого". И проблемы плюс-минус те же: продакты не хотят делать техдолг, инженеры не хотят обновлять таски в джире, топы не хотят ждать фичу еще целый месяц. Ничего нового :)

Таким был мой короткий опыт в одной компании.

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

11.3k 2 127 50 538

Топ посты 2023

- Как выглядит рабочий день проджект менеджера
- Этикет видео звонков
- Как я стал ИТ менеджером
- Прогулочные встречи
- ​Fix price flexible scope модель
- Примеры вопросов на интервью в европейской компании
- Резюме, часть 1, часть 2
- Уходить с бесполезных встреч
- Спринт беклог на разных стадиях продукта
- ​Английские сокращения, которые встретятся на работе за рубежом

Друзья, спасибо, что читали менеджера от боженьки в этому году! Если захотите порекомендовать канал другу-менеджеру, просто перешлите ему этот пост. Я буду вам очень за это благодарен ❤️

С наступающим!


Почему мы не попадаем в оценки

Оценки, блин, неточные. Постоянно в них не попадаешь.

Даже закладывая буфер х2, все равно легко промахнуться. И, хотя x2 в лоб, конечно, никто заложить не даст, каждый следующий менеджер добавляет к оценке предыдущего еще 30% сверху на всякий случай. Так что на выходе получается и х2, и x3 и все что хочешь.

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

Помните, какая большая разбежка бывает на старте каждого проекта? Первые 3-4 спринта случаются вылеты даже 30-40%. (Опытные менеджеры на этом месте просто обещают катастрофически мало, но это уже другая история).

А потом через полгода-год на этом же проекте, с этой же командой максимум 5-10% вылет. Почему так?

Потому что за это время мы узнали много нового о том, с чем работаем и убрали риски:

🤞 сработает ли эта библиотека;

🤞 так ли крут тот фронтедер, каким было его резюме;

🤞 как часто ПО будет менять задачи в спринте и насколько хорошо их прорабатывать;

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


Средство от хандры для менеджеров

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

💊Зироинбоксан

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

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

💊Зироинбоксан. В каждом почтовом клиенте вашего города.


Поиск работы. Meetings notes после интервью

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

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

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

Если вы собеседуетесь в компанию мечты, потратьте еще 20 минут, чтобы облегчить жизнь рекрутеру (он оценит!), и напишите вот такое письмо:

15.2k 1 231 22 249

Working backwards

Есть такой метод разработки продуктов, который придумали в Амазоне - Working Backwards. Суть его том, чтобы начать с конца - представить, что продукт уже готов и осталось лишь написать пресс-релиз.

Когда использовать
WB подойдет для проработки любой идеи - например, нового процесса, фичи или целого продукта. Его задача - разложить твое предложение по полочкам, как будто объясняешь для человека с улицы. Такое погружение в контекст призвано помочь принять решение, нужна нам эта фича или нет. Чтобы не было так, что какой-то чувак решил внедрить оплату криптой, потому что на прошлом его проекте это сделали и было норм.

Из чего состоит
В процессе working backwards ты создаешь одноименный документ. В нем есть две части:

Пресс-релиз - письмо, которое ты отправишь в день запуска. Тут ты делаешь вид, что твоя фича уже готова, А\Б тест подтвердил гипотезу, и теперь вы раскатываете ее на всех пользователей. А в письме ты рассказываешь коллегам, как круто все прошло.

Ответы на 5 главных вопросов:
📌 Кто конечный пользователь?
Пассажиры такси, существующие пользователи Bolt, в пользовательских группах “Молодые родители” (4,5M).

📌 Какая у него проблема или в чем ты видишь проблему на рынке?
В среднем 2 раза в месяц отравляют ребенка в школу в спешке.

📌 Какое у нее будет решение? UX
Кнопка “вызвать водителя для ребенка”, см. скриншоты

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

📌 Какой будет импакт от решения проблемы (в бабках)
Результаты тестов показали прогнозируемую конверсию в 3-4%, что выражено в 34M MRR.

Смысл в том, что готовя WB и отвечая на все эти вопросы, находя цифры и разбираясь причины, ты в итоге составляешь док, по которому всем все понятно. Самый крутой WB - это тот, после прочтения которого продакт директор вскакивает и говорит: “бросаем все и берем в работу завтра же!”

Чем лучше сделан WB, чем точнее исследована проблема и выше уверенность в ней, тем выше шанс, что фичу утвердят (или сам по дороге поймешь, что оно того не стоит).

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

Мой опыт
В этом году я успел написать один WB (обычно это работа продакта) для программы по модернизации нашей мобильной архитектуры. И где-то с десяток поревьювил. Самым ценным мне как раз показались комментарии и ревью, особенно когда читают люди из соседних отделов или из другой платформы.

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


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

(на ушко)


Дата релиза

Вместе с продактом готовим к релизу небольшой внутренний продукт.

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

Дошли до выбора даты. Говорит, Рома, надо найти день, когда другие команды ничего не релизят, чтобы мы были в центре внимания хотя бы неделю.

Вот до этого я не додумался!

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

18.5k 0 34 18 130

Уходить с бесполезных встреч

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

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

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

Чтобы так сказать, нужны смелость и определенная культура в компании. Где-то могут увидеть в таком поступке неуважение и даже грубость. Это же все равно, что развернуть большой плакат с надписью «встреча - кошмар, организатор - балбес». Хотя наша цель лишь тратить время с умом.

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

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

18.7k 1 159 25 248
20 last posts shown.