Каждый менеджер мечтает о команде, которая не зассыт сказать, что у него в зубах что-то застряло.
(на ушко)
(на ушко)
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.
Есть такой метод разработки продуктов, который придумали в Амазоне - Working Backwards. Суть его том, чтобы начать с конца - представить, что продукт уже готов и осталось лишь написать пресс-релиз.
Когда использовать
WB подойдет для проработки любой идеи - например, нового процесса, фичи или целого продукта. Его задача - разложить твое предложение по полочкам, как будто объясняешь для человека с улицы. Такое погружение в контекст призвано помочь принять решение, нужна нам эта фича или нет. Чтобы не было так, что какой-то чувак решил внедрить оплату криптой, потому что на прошлом его проекте это сделали и было норм.
Из чего состоит
В процессе working backwards ты создаешь одноименный документ. В нем есть две части:
Пресс-релиз - письмо, которое ты отправишь в день запуска. Тут ты делаешь вид, что твоя фича уже готова, А\Б тест подтвердил гипотезу, и теперь вы раскатываете ее на всех пользователей. А в письме ты рассказываешь коллегам, как круто все прошло.
Ответы на 5 главных вопросов:
📌 Кто конечный пользователь?
Пассажиры такси, существующие пользователи Bolt, в пользовательских группах “Молодые родители” (4,5M).
📌 Какая у него проблема или в чем ты видишь проблему на рынке?
В среднем 2 раза в месяц отравляют ребенка в школу в спешке.
📌 Какое у нее будет решение? UX
Кнопка “вызвать водителя для ребенка”, см. скриншоты
📌 Какой самый главный бенефит получит клиент, когда его получит?
Доверить доставку ребенка надежному водителю и сэкономить 4 часа в месяц.
📌 Какой будет импакт от решения проблемы (в бабках)
Результаты тестов показали прогнозируемую конверсию в 3-4%, что выражено в 34M MRR.
Смысл в том, что готовя WB и отвечая на все эти вопросы, находя цифры и разбираясь причины, ты в итоге составляешь док, по которому всем все понятно. Самый крутой WB - это тот, после прочтения которого продакт директор вскакивает и говорит: “бросаем все и берем в работу завтра же!”
Чем лучше сделан WB, чем точнее исследована проблема и выше уверенность в ней, тем выше шанс, что фичу утвердят (или сам по дороге поймешь, что оно того не стоит).
Но даже для великолепно составленного WB нет гарантии, что его возьмут в разработку. Не все идеи запустятся, и большая часть написанных доков все равно будет сделана в стол. И это не баг, а фича, потому что идей много, а ресурсов мало.
Мой опыт
В этом году я успел написать один WB (обычно это работа продакта) для программы по модернизации нашей мобильной архитектуры. И где-то с десяток поревьювил. Самым ценным мне как раз показались комментарии и ревью, особенно когда читают люди из соседних отделов или из другой платформы.
Больше о WB читайте в блоге амазона или в одноименной книге. Кстати, чувак, который ее написал, присутствовал при внедрении процесса в компании и лично ходил на ревью и демки нового процесса, когда его презентовали Безосу в 2004.
Поиск работы. Meetings notes после интервью
Если скрининг прошел хорошо, и рекрутер готов идти с вами дальше, то следующий шаг для него - отправить резюме нанимающему менеджеру.
Обычно его сопровождают короткими заметками с главными плюсами кандидата, вроде “может начать через неделю” или “5 лет опыта в видео домене”.
За 30 мин скрининга, конечно, сложно увидеть прям все сильные стороны. Поэтому, наша задача - помочь рекрутеру понять какие мы классные и как подходим компании.
Если вы собеседуетесь в компанию мечты, потратьте еще 20 минут, чтобы облегчить жизнь рекрутеру (он оценит!), и напишите вот такое письмо:
Если скрининг прошел хорошо, и рекрутер готов идти с вами дальше, то следующий шаг для него - отправить резюме нанимающему менеджеру.
Обычно его сопровождают короткими заметками с главными плюсами кандидата, вроде “может начать через неделю” или “5 лет опыта в видео домене”.
За 30 мин скрининга, конечно, сложно увидеть прям все сильные стороны. Поэтому, наша задача - помочь рекрутеру понять какие мы классные и как подходим компании.
Если вы собеседуетесь в компанию мечты, потратьте еще 20 минут, чтобы облегчить жизнь рекрутеру (он оценит!), и напишите вот такое письмо:
Средство от хандры для менеджеров
Найдено средство от осенней, зимней, весенней и летней хандры. Работает для проджектов, продактов и тимлидов.
💊Зироинбоксан
Симптомы:
- кажется, что дел скопилось больше, чем физически можешь успеть.
- испытываешь затруднения при поиске писем.
Принцип действия:
Действие препарата основано на очищении входящих сообщений в почте. Пациенты отмечают улучшение настроения, ощущение легкости и свободы. Оказывает моментальный эффект уже от 5 писем в инбоксе.
💊Зироинбоксан. В каждом почтовом клиенте вашего города.
Найдено средство от осенней, зимней, весенней и летней хандры. Работает для проджектов, продактов и тимлидов.
💊Зироинбоксан
Симптомы:
- кажется, что дел скопилось больше, чем физически можешь успеть.
- испытываешь затруднения при поиске писем.
Принцип действия:
Действие препарата основано на очищении входящих сообщений в почте. Пациенты отмечают улучшение настроения, ощущение легкости и свободы. Оказывает моментальный эффект уже от 5 писем в инбоксе.
💊Зироинбоксан. В каждом почтовом клиенте вашего города.
Почему мы не попадаем в оценки
Оценки, блин, неточные. Постоянно в них не попадаешь.
Даже закладывая буфер х2, все равно легко промахнуться. И, хотя x2 в лоб, конечно, никто заложить не даст, каждый следующий менеджер добавляет к оценке предыдущего еще 30% сверху на всякий случай. Так что на выходе получается и х2, и x3 и все что хочешь.
⁃ Что делать, чтобы точнее попадать в оценки?
⁃ Лучше понимать предмет и условия оценки. Чем больше мы знаем о проекте, тем точнее оценка.
Помните, какая большая разбежка бывает на старте каждого проекта? Первые 3-4 спринта случаются вылеты даже 30-40%. (Опытные менеджеры на этом месте просто обещают катастрофически мало, но это уже другая история).
А потом через полгода-год на этом же проекте, с этой же командой максимум 5-10% вылет. Почему так?
Потому что за это время мы узнали много нового о том, с чем работаем и убрали риски:
🤞 сработает ли эта библиотека;
🤞 так ли крут тот фронтедер, каким было его резюме;
🤞 как часто ПО будет менять задачи в спринте и насколько хорошо их прорабатывать;
Получается, со временем проектные знания растут сами по себе, а с ними и точность оценки. В принципе, можно плыть по течению и, спустя время, оценки станут немного точнее. Но так каждый джун умеет, поэтому в следующий раз мы порассуждаем о том, какими трюками ПМ может ускорить этот процесс.
Оценки, блин, неточные. Постоянно в них не попадаешь.
Даже закладывая буфер х2, все равно легко промахнуться. И, хотя x2 в лоб, конечно, никто заложить не даст, каждый следующий менеджер добавляет к оценке предыдущего еще 30% сверху на всякий случай. Так что на выходе получается и х2, и x3 и все что хочешь.
⁃ Что делать, чтобы точнее попадать в оценки?
⁃ Лучше понимать предмет и условия оценки. Чем больше мы знаем о проекте, тем точнее оценка.
Помните, какая большая разбежка бывает на старте каждого проекта? Первые 3-4 спринта случаются вылеты даже 30-40%. (Опытные менеджеры на этом месте просто обещают катастрофически мало, но это уже другая история).
А потом через полгода-год на этом же проекте, с этой же командой максимум 5-10% вылет. Почему так?
Потому что за это время мы узнали много нового о том, с чем работаем и убрали риски:
🤞 сработает ли эта библиотека;
🤞 так ли крут тот фронтедер, каким было его резюме;
🤞 как часто ПО будет менять задачи в спринте и насколько хорошо их прорабатывать;
Получается, со временем проектные знания растут сами по себе, а с ними и точность оценки. В принципе, можно плыть по течению и, спустя время, оценки станут немного точнее. Но так каждый джун умеет, поэтому в следующий раз мы порассуждаем о том, какими трюками ПМ может ускорить этот процесс.
Топ посты 2023
- Как выглядит рабочий день проджект менеджера
- Этикет видео звонков
- Как я стал ИТ менеджером
- Прогулочные встречи
- Fix price flexible scope модель
- Примеры вопросов на интервью в европейской компании
- Резюме, часть 1, часть 2
- Уходить с бесполезных встреч
- Спринт беклог на разных стадиях продукта
- Английские сокращения, которые встретятся на работе за рубежом
Друзья, спасибо, что читали менеджера от боженьки в этому году! Если захотите порекомендовать канал другу-менеджеру, просто перешлите ему этот пост. Я буду вам очень за это благодарен ❤️
С наступающим!
- Как выглядит рабочий день проджект менеджера
- Этикет видео звонков
- Как я стал ИТ менеджером
- Прогулочные встречи
- Fix price flexible scope модель
- Примеры вопросов на интервью в европейской компании
- Резюме, часть 1, часть 2
- Уходить с бесполезных встреч
- Спринт беклог на разных стадиях продукта
- Английские сокращения, которые встретятся на работе за рубежом
Друзья, спасибо, что читали менеджера от боженьки в этому году! Если захотите порекомендовать канал другу-менеджеру, просто перешлите ему этот пост. Я буду вам очень за это благодарен ❤️
С наступающим!
Год в европейской продуктовой компании
Прошел 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% такая же, как у нас. Нету такого, что "забудьте все, что вы знали до этого". И проблемы плюс-минус те же: продакты не хотят делать техдолг, инженеры не хотят обновлять таски в джире, топы не хотят ждать фичу еще целый месяц. Ничего нового :)
Таким был мой короткий опыт в одной компании.
Уверен, что найдутся ребята, у что-то было по-другому. Мне очень любопытно вас послушать. Поделитесь своими наблюдениями в комментариях?
Прошел 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% такая же, как у нас. Нету такого, что "забудьте все, что вы знали до этого". И проблемы плюс-минус те же: продакты не хотят делать техдолг, инженеры не хотят обновлять таски в джире, топы не хотят ждать фичу еще целый месяц. Ничего нового :)
Таким был мой короткий опыт в одной компании.
Уверен, что найдутся ребята, у что-то было по-другому. Мне очень любопытно вас послушать. Поделитесь своими наблюдениями в комментариях?
#реклама_по_любви
Стратоплан был моим первым обучением менеджменту. В то время Орлов и Панкратов учили классическим штукам: типы личности Адизеса, матрица доверие \ прозрачность, как делать классные презентации. Супер актуальные скилы на все времена.
Теперь они заточили классическую программу под ИТ специфику и сделали курсы для тимлидов и СТО. И приглашают нас с вами на бесплатный интенсив. (Потом, понятно, что-то продавать будут, но это потом!).
Детали:
С 22 по 25 января, Школа менеджмента «Стратоплан» проводит открытые, бесплатные практические курсы — Teamlead:201 и СТО:201.
На них будут разбирать практические кейсы и упражнения, как в жизни:
◽️как строить отношения с командой и разруливать конфликты;
◽️как оставаться актуальным как программист, ведь я теперь не пишу код;
◽️как презентовать результаты своей работы, чтобы босс был доволен.
Обучение проходит каждый день, с 18 до 21 МСК.
Почитайте полную программу курса на сайте и, если отзывается - регистрируйтесь и приходите учиться. Стратоплан любит давать бонусный контент, поэтому даже если просто зарегистрируетесь, то получите аж 6 видео по техническому управлению.
👉Регистрация на Teamlead:201
👉Регистрация на СТО:201
Стратоплан был моим первым обучением менеджменту. В то время Орлов и Панкратов учили классическим штукам: типы личности Адизеса, матрица доверие \ прозрачность, как делать классные презентации. Супер актуальные скилы на все времена.
Теперь они заточили классическую программу под ИТ специфику и сделали курсы для тимлидов и СТО. И приглашают нас с вами на бесплатный интенсив. (Потом, понятно, что-то продавать будут, но это потом!).
Детали:
С 22 по 25 января, Школа менеджмента «Стратоплан» проводит открытые, бесплатные практические курсы — Teamlead:201 и СТО:201.
На них будут разбирать практические кейсы и упражнения, как в жизни:
◽️как строить отношения с командой и разруливать конфликты;
◽️как оставаться актуальным как программист, ведь я теперь не пишу код;
◽️как презентовать результаты своей работы, чтобы босс был доволен.
Обучение проходит каждый день, с 18 до 21 МСК.
Почитайте полную программу курса на сайте и, если отзывается - регистрируйтесь и приходите учиться. Стратоплан любит давать бонусный контент, поэтому даже если просто зарегистрируетесь, то получите аж 6 видео по техническому управлению.
👉Регистрация на Teamlead:201
👉Регистрация на СТО:201
Соцпакет: сажаем деревья на годовщину работы
Одна из плюшек в HelloFresh - за каждый отработанный год компания сажает одно дерево.
Я об этом слышал, и к своей первой годовщине уже готовился ехать с лопатой в какой-нибудь грюневальд. Но оказалось, что физический труд айтишников несет для бизнеса определенные риски, поэтому за нас все делает компания growmytree.com.
Они высаживают саженцы в Эфиопии, Уганде, Танзании и других отдаленных местах планеты. При этом привлекают супер незащищенные слои местного населения, позволяя им немного заработать. В общем, все в плюсе.
Так за все время мы (ну, почти мы) высадили около 3,000 деревьев. По-моему, это классный и необычный selling point, которым можно козырнуть при найме.
------
Кстати, программа Apple, по которой они хотят стать carbon-neutral к 2030 году, тоже состоит из высадки деревьев, чтобы компенсировать загрязнения от производства айфончиков.
Одна из плюшек в HelloFresh - за каждый отработанный год компания сажает одно дерево.
Я об этом слышал, и к своей первой годовщине уже готовился ехать с лопатой в какой-нибудь грюневальд. Но оказалось, что физический труд айтишников несет для бизнеса определенные риски, поэтому за нас все делает компания growmytree.com.
Они высаживают саженцы в Эфиопии, Уганде, Танзании и других отдаленных местах планеты. При этом привлекают супер незащищенные слои местного населения, позволяя им немного заработать. В общем, все в плюсе.
Так за все время мы (ну, почти мы) высадили около 3,000 деревьев. По-моему, это классный и необычный selling point, которым можно козырнуть при найме.
------
Кстати, программа Apple, по которой они хотят стать carbon-neutral к 2030 году, тоже состоит из высадки деревьев, чтобы компенсировать загрязнения от производства айфончиков.
Карта клиента
С некоторыми клиентами работать одно удовольствием. А бывает, попадаются трудные личности.
У меня, например, был один чел, который заплатил приличную сумму за проект и пропал. Дело было в Мексике, проект был для правительства, и что с челом случилось на самом деле никто не знает. Приемку мы проводили уже с другим.
В карточках выше я описал типажи клиентов и их особенности, которые доставляют нам, менеджерам, больше всего проблем. Ставь лайк, если узнал своего.
Иллюстрации: Анастасия Вишневская.
С некоторыми клиентами работать одно удовольствием. А бывает, попадаются трудные личности.
У меня, например, был один чел, который заплатил приличную сумму за проект и пропал. Дело было в Мексике, проект был для правительства, и что с челом случилось на самом деле никто не знает. Приемку мы проводили уже с другим.
В карточках выше я описал типажи клиентов и их особенности, которые доставляют нам, менеджерам, больше всего проблем. Ставь лайк, если узнал своего.
Иллюстрации: Анастасия Вишневская.
Метод освоенного объема (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, чтобы следить за попаданием в бюджет и срок.
Метод освоенного объема (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, чтобы следить за попаданием в бюджет и срок.
Критический путь
Метод критического пути - самый популярный способ оценки сроков проектов и фич. Им пользуются менеджеры в аутсорсе, продукте, геймдеве и даже на стройке. Бывает, что даже неосознанно - настолько метод легкий и интуитивный.
Суть его в том, чтобы расставить задачи в плане так, чтобы срок проекта был минимальным. Иными словами, критический путь - это самая длительная последовательность задач, которая приведет к завершению проекта.
Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).
Предположим, что все дизайны согласовывает лично СЕО, поэтому приложение мы не начинаем, пока дизайн не завершен. Пресс-релиз можно писать в любое время.
Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.
Зачем нужен критический путь.
Во-первых, построить расписание. Чтобы это сделать, мы максимально распараллеливаем все задачи, пока это не вредит качеству и минимизируем простои между ними.
В примере выше распараллелить можно две задачи: разработку бекенда (его можно начинать одновременно с дизайном) и пресс-релиз (можно написать в любое время). Само приложение можно начинать после согласования дизайна, распараллелить эти две задачи нельзя. Значит, они обе находятся на критическом пути и их суммарная длительность, это и есть длительность всей фичи.
Во-вторых, понять какие задачи влияют на дату завершения фичи. В нашем примере это снова дизайн и приложение. Если любая из них задерживается, то задерживается и вся фича. Задержек мы не хотим, значит, за этими задачами будем следить пристальнее остальных и делать все, чтобы они закончились вовремя. Например, если в команде есть мидл фуллстек и сениор фуллстек, то приложение логичнее отдать сениору, чтобы снизить вероятность задержки.
Задержки с бекендом и пресс-релизом для нас не так важны - они не на критическом пути. Даже если они задержатся, это не повлияет на дату завершения фичи.
При работе с критическим путем главная задача менеджера не позволять ему расти, чтобы не ехало расписание.
Метод критического пути - самый популярный способ оценки сроков проектов и фич. Им пользуются менеджеры в аутсорсе, продукте, геймдеве и даже на стройке. Бывает, что даже неосознанно - настолько метод легкий и интуитивный.
Суть его в том, чтобы расставить задачи в плане так, чтобы срок проекта был минимальным. Иными словами, критический путь - это самая длительная последовательность задач, которая приведет к завершению проекта.
Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).
Предположим, что все дизайны согласовывает лично СЕО, поэтому приложение мы не начинаем, пока дизайн не завершен. Пресс-релиз можно писать в любое время.
Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.
Зачем нужен критический путь.
Во-первых, построить расписание. Чтобы это сделать, мы максимально распараллеливаем все задачи, пока это не вредит качеству и минимизируем простои между ними.
В примере выше распараллелить можно две задачи: разработку бекенда (его можно начинать одновременно с дизайном) и пресс-релиз (можно написать в любое время). Само приложение можно начинать после согласования дизайна, распараллелить эти две задачи нельзя. Значит, они обе находятся на критическом пути и их суммарная длительность, это и есть длительность всей фичи.
Во-вторых, понять какие задачи влияют на дату завершения фичи. В нашем примере это снова дизайн и приложение. Если любая из них задерживается, то задерживается и вся фича. Задержек мы не хотим, значит, за этими задачами будем следить пристальнее остальных и делать все, чтобы они закончились вовремя. Например, если в команде есть мидл фуллстек и сениор фуллстек, то приложение логичнее отдать сениору, чтобы снизить вероятность задержки.
Задержки с бекендом и пресс-релизом для нас не так важны - они не на критическом пути. Даже если они задержатся, это не повлияет на дату завершения фичи.
При работе с критическим путем главная задача менеджера не позволять ему расти, чтобы не ехало расписание.
Границы системы
Когда приходишь в новый проект это всегда стресс. Заметил, что часть этого стресса у меня вызывает то, что я не вижу границы системы. То есть из чего состоит приложение, где оно заканчивается и где граница моей ответственности.
Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”
Как понять границы системы быстрее?
Посмотреть на систему с точки зрения пользователей, фич, кода и интеграции. Подробнее про каждый пункт:
1️⃣ Начать рекомендую с типов пользователей. Их обычно не очень много и, поняв их цели, можно уже прикинуть систему. Плюс, даже если у вас простое приложение для обработки фоточек, здесь часто обнаруживаются скрытые системы, вроде админки.
2️⃣ Пройтись по всем экранам приложения. Дизайнеры часто делают карту всех экранов со стрелочками-переходами, тоже полезная вещь.
3️⃣ Выписать список сервисов и SDK, которыми пользуется прила. Здесь снова невидимые штуки вроде хостинга медиа файлов. Особенно важно найти платные, т.к. за счета от них ПМа тоже будут спрашивать.
4️⃣ Найти точки интеграции с другими командами. Бывает, что вашим сервисом для обрезки фоток пользуется соседняя команда, которая пилит свой продукт на вашей технологии. Если этот сервис упадет, то пострадают не только ваши пользователи, но и соседний продукт - к этому лучше быть готовым.
Когда понимаешь границы системы, появляется больше уверенности в собственных действиях и стресса становится в разы меньше.
А какие у вас лайфхаки?
----------
UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке;
Когда приходишь в новый проект это всегда стресс. Заметил, что часть этого стресса у меня вызывает то, что я не вижу границы системы. То есть из чего состоит приложение, где оно заканчивается и где граница моей ответственности.
Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”
Как понять границы системы быстрее?
Посмотреть на систему с точки зрения пользователей, фич, кода и интеграции. Подробнее про каждый пункт:
1️⃣ Начать рекомендую с типов пользователей. Их обычно не очень много и, поняв их цели, можно уже прикинуть систему. Плюс, даже если у вас простое приложение для обработки фоточек, здесь часто обнаруживаются скрытые системы, вроде админки.
2️⃣ Пройтись по всем экранам приложения. Дизайнеры часто делают карту всех экранов со стрелочками-переходами, тоже полезная вещь.
3️⃣ Выписать список сервисов и SDK, которыми пользуется прила. Здесь снова невидимые штуки вроде хостинга медиа файлов. Особенно важно найти платные, т.к. за счета от них ПМа тоже будут спрашивать.
4️⃣ Найти точки интеграции с другими командами. Бывает, что вашим сервисом для обрезки фоток пользуется соседняя команда, которая пилит свой продукт на вашей технологии. Если этот сервис упадет, то пострадают не только ваши пользователи, но и соседний продукт - к этому лучше быть готовым.
Когда понимаешь границы системы, появляется больше уверенности в собственных действиях и стресса становится в разы меньше.
А какие у вас лайфхаки?
----------
UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке;
Как выбрать, что рефакторить - ч.1 оцениваем пользу
TL;DR
На техдолг нужно смотреть, как на обычные фичи - с точки зрения ценности и метрик. Альтернативный вариант, если это невозможно - посмотреть “что болит” в коде. Самым полезным для рефакторинга будет код, удовлетворяющий двум условиям: 1) высокая complexity 2) часто меняется.
————————
Спроси любого программиста, он всегда насобирает техдолга на год работы. Тут древний фреймворк, который ни разу не обновлялся, там легаси, которое уже никто в команде не понимает.
Как понять, какой рефакторинг стоит брать в работу, а что можно отложить на потом?
Как и любую задачу в беклоге, рефакторинг нужно рассматривать с точки зрения ценности.
Например, перепишем модуль рендеринга, чтобы фотки грузились быстрее. Благодаря этому, меньше пользователей будут отваливаться на долгом шаге загрузки фоток, и общая конверсия в покупку вырастет.
Ценность такой задачи легко посчитать в деньгах, она понятна бизнесу и имеет все шансы попасть в спринт. Продакт тоже доволен - задачи по рефакторингу можно сравнивать с обычными фичами и применять к ним те же процессы.
Проблема в том, что далеко не все технические задачи можно так запросто перевести в метрики и деньги...
TL;DR
На техдолг нужно смотреть, как на обычные фичи - с точки зрения ценности и метрик. Альтернативный вариант, если это невозможно - посмотреть “что болит” в коде. Самым полезным для рефакторинга будет код, удовлетворяющий двум условиям: 1) высокая complexity 2) часто меняется.
————————
Спроси любого программиста, он всегда насобирает техдолга на год работы. Тут древний фреймворк, который ни разу не обновлялся, там легаси, которое уже никто в команде не понимает.
Как понять, какой рефакторинг стоит брать в работу, а что можно отложить на потом?
Как и любую задачу в беклоге, рефакторинг нужно рассматривать с точки зрения ценности.
Например, перепишем модуль рендеринга, чтобы фотки грузились быстрее. Благодаря этому, меньше пользователей будут отваливаться на долгом шаге загрузки фоток, и общая конверсия в покупку вырастет.
Ценность такой задачи легко посчитать в деньгах, она понятна бизнесу и имеет все шансы попасть в спринт. Продакт тоже доволен - задачи по рефакторингу можно сравнивать с обычными фичами и применять к ним те же процессы.
Проблема в том, что далеко не все технические задачи можно так запросто перевести в метрики и деньги...
Как выбрать, что рефакторить - ч.2 анализируем код
Представьте, что ваш стартап пережил фазу бурного роста и СТО решил, что пора побить монолит на сервисы поменьше. Сделал классную презу, заручился поддержкой СПО и тимлидов и получил зеленый свет. С чего начать такой проект? Какой сервис взять в работу первым? Где наибольшая ценность от рефакторинга?
Один из вариантов - посмотреть на техдог с точки зрения файлов. Все наше приложение состоит из файлов, в которых хранятся экраны, API, интеграции и конфигурации. Чем больше фич, тем больше кода и тем больше файлов. В небольшом приложении по занятию йогой может быть, скажем, 300 файлов.
Чтобы определить скоуп рефакторинга, посмотрим на два параметра: сложность и частоту изменения файлов.
Сложность - это объем логики принятия решений в функциях исходного кода. Ее можно узнать, подключив сервисы вроде CodeScense или SonarQube. И хотя существуют различные способы, как ее подсчитать, самый популярный из них - цикломатическую сложность - придумали еще в 70-х и используют до сих пор.
Когда программисты пишут новую фичу и задействуют в ней файлы с низкой сложностью, это не вызывает у них раздражения. Короткие файлы легко читать и изменять, в них не запутаешься. Но когда в файле уже больше 300 строк, добавить 5 новых и ничего не сломать уже проблематично. Раздражать программистов мы не хотим, поэтому нас интересуют файлы с высокой сложностью.
Окей, допустим, таких файлов 100 из 300. Но мы же не будем с ходу переписывать 30% проекта. Какие из них прям самые невыносимые?
Здесь мы смотрим на второй параметр - изменяемость. Она показывает, как часто программисты вносят изменения в файлы, когда пишут новые фичи или исправляют баги.
Функционал вроде Настроек, Логаута, Смены пароль, меняются редко. Даже если в нем высокая сложность, его обслуживание стоит недорого. А раз так, то и снижать эту стоимость нет смысла. Про такой код говорят “Работает - не трогай”.
И наоборот, в фиче Урок Йоги продакт постоянно ставит новые эксперименты. Если в ней высокая complexity, то с каждым юзкейсом программистам все труднее и труднее писать новый код и менять растущие в объеме файлы. Это выливается в растущие оценки и долгий поиск багов.
Такие фичи стоит приоритезировать для рефакторинга в первую очередь.
————————
Недавно на работе мы думали, как определить самую важную часть скоупа для технического проекта длиной в несколько лет. Попробовали описанную технику (нашли ее здесь) и результат нас удовлетворил. Оказалось, что найденные файлы совпали с тем, что программисты субъективно назвали самой важной частью проекта. А это хороший знак.
Представьте, что ваш стартап пережил фазу бурного роста и СТО решил, что пора побить монолит на сервисы поменьше. Сделал классную презу, заручился поддержкой СПО и тимлидов и получил зеленый свет. С чего начать такой проект? Какой сервис взять в работу первым? Где наибольшая ценность от рефакторинга?
Один из вариантов - посмотреть на техдог с точки зрения файлов. Все наше приложение состоит из файлов, в которых хранятся экраны, API, интеграции и конфигурации. Чем больше фич, тем больше кода и тем больше файлов. В небольшом приложении по занятию йогой может быть, скажем, 300 файлов.
Чтобы определить скоуп рефакторинга, посмотрим на два параметра: сложность и частоту изменения файлов.
Сложность - это объем логики принятия решений в функциях исходного кода. Ее можно узнать, подключив сервисы вроде CodeScense или SonarQube. И хотя существуют различные способы, как ее подсчитать, самый популярный из них - цикломатическую сложность - придумали еще в 70-х и используют до сих пор.
Когда программисты пишут новую фичу и задействуют в ней файлы с низкой сложностью, это не вызывает у них раздражения. Короткие файлы легко читать и изменять, в них не запутаешься. Но когда в файле уже больше 300 строк, добавить 5 новых и ничего не сломать уже проблематично. Раздражать программистов мы не хотим, поэтому нас интересуют файлы с высокой сложностью.
Окей, допустим, таких файлов 100 из 300. Но мы же не будем с ходу переписывать 30% проекта. Какие из них прям самые невыносимые?
Здесь мы смотрим на второй параметр - изменяемость. Она показывает, как часто программисты вносят изменения в файлы, когда пишут новые фичи или исправляют баги.
Функционал вроде Настроек, Логаута, Смены пароль, меняются редко. Даже если в нем высокая сложность, его обслуживание стоит недорого. А раз так, то и снижать эту стоимость нет смысла. Про такой код говорят “Работает - не трогай”.
И наоборот, в фиче Урок Йоги продакт постоянно ставит новые эксперименты. Если в ней высокая complexity, то с каждым юзкейсом программистам все труднее и труднее писать новый код и менять растущие в объеме файлы. Это выливается в растущие оценки и долгий поиск багов.
Такие фичи стоит приоритезировать для рефакторинга в первую очередь.
————————
Недавно на работе мы думали, как определить самую важную часть скоупа для технического проекта длиной в несколько лет. Попробовали описанную технику (нашли ее здесь) и результат нас удовлетворил. Оказалось, что найденные файлы совпали с тем, что программисты субъективно назвали самой важной частью проекта. А это хороший знак.
Быстрое ревью документов: как в Амазоне
Кто хоть раз просил CPO поревьювать документ с новой инициативой, знает, что напомнить о просьбе придется минимум пару раз. Если компания большая, и стейкхолдеров у инициативы много, на простое ревью легко уходит 2-3 календарные недели. Потому что у каждого сейка таких просьб по нескольку в неделю.
Увидел новую технику, как получить фидбек на документ быстро:
➡ собираешь всех на мит
➡ 5 минут рассказываешь про инициативу
➡ все садятся читать и комментировать док, выключают камеру
➡ когда прочитали, включают камеру обратно
➡ оставшееся время проходитесь по комментариям, спорите, определяете следующие шаги.
В таком варианте ты как бы бронируешь время человека под ревью, добавляя инвайт в его календарь. В итоге результат у тебя на руках всего за час, а времени потрачено плюс-минус столько же. Обсуждение тоже идет хорошо, потому что народ загрузил инициативу себе в оперативную память.
Вариант эффективный, но лишняя энергия все равно уходит. Пока спросишь всех, как прошли выходные и какие планы на отпуск уже устанешь улыбаться.
Поэтому мне больше нравится гибридный вариант - каждый обязуется прочитать док перед встречей, а собираетесь вы только чтобы принять решение.
Кто хоть раз просил CPO поревьювать документ с новой инициативой, знает, что напомнить о просьбе придется минимум пару раз. Если компания большая, и стейкхолдеров у инициативы много, на простое ревью легко уходит 2-3 календарные недели. Потому что у каждого сейка таких просьб по нескольку в неделю.
Увидел новую технику, как получить фидбек на документ быстро:
➡ собираешь всех на мит
➡ 5 минут рассказываешь про инициативу
➡ все садятся читать и комментировать док, выключают камеру
➡ когда прочитали, включают камеру обратно
➡ оставшееся время проходитесь по комментариям, спорите, определяете следующие шаги.
В таком варианте ты как бы бронируешь время человека под ревью, добавляя инвайт в его календарь. В итоге результат у тебя на руках всего за час, а времени потрачено плюс-минус столько же. Обсуждение тоже идет хорошо, потому что народ загрузил инициативу себе в оперативную память.
Вариант эффективный, но лишняя энергия все равно уходит. Пока спросишь всех, как прошли выходные и какие планы на отпуск уже устанешь улыбаться.
Поэтому мне больше нравится гибридный вариант - каждый обязуется прочитать док перед встречей, а собираетесь вы только чтобы принять решение.