Как понять, кто перформер, а кто нет
В небольшой команде все варятся в общем информационном пузыре. Народу мало, проектов мало, все на виду. Если новый лид айосник оказался лодырем, это быстро станет заметно.
В большой не так, здесь легко затеряться.
Лид айсоник может каждые 4 месяца прыгать с проекта на проект. И тогда подбить его перфоманс становится трудно, т.к. у тебя, как у его менеджера просто нет инфы, как он переоформил. Ты, конечно, поспрашиваешь фидбека у других людей, кто с ним работал, но тут свои риски.
Для тех, кто делает пипл менеджмент такая непрозрачность, это большая проблема.
Есть классный инструмент, который ее решает - Small Improvements. Его главный функционал - написать публичный комплимент о коллеге.
В линкедине вы наверняка видели посты со словом Kudos, когда люди хвалят друг друга и выражают признательность. Тут то же самое.
Лид айосник сделал классный tech proposal новой фичи - напиши ему Kudos, чтобы все знали, какой он красавчик. Менеджер из другой команды быстро сделал то, что вы просили (в отличие от других менеджеров-бездельников) - Kudos. Продакт провел крутой воркшоп без воды и соплей - Kudos. Так ты “хвалишь при всех”, причем сразу на всю компанию.
Все кудосы собираются в общую ленту. Можно смотреть, какие кудосы получили твои ребята. Можно смотреть, кто тащер в других командах.
Люди не станут просто так хвалить друг друга за фигню (если вы не привяжите кудосы к kpi, конечно). Если пишут, то за дело. Получается честный, справедливый и адресный фидбек.
Теперь, если к тебе в команду месяц назад перешел айосник и надо сделать его годовое ревью, у тебя есть качественный источник информации.
В Small improvements кроме Kudos есть еще функционал 1-1, перф ревью, 360 фидбек и всякое такое. Но наверняка, есть и другие хорошие сервисы с Kudos. Напишите в комментарии, если пользовались такими.
-----------------
UPD: в комментах многие пишут, что в их компании такой подход не работает (спасибо, что делитесь опытом 🤝). Кудосы получают не реальные герои, те, кто общается с большим количеством людей или просто более говорливые и харизматичные люди.
Я думаю, это вопрос культуры. А любая культура всегда идет сверху.
Чтобы система работала, менеджеры должны:
- хвалить за успехи и результаты, а не ожидаемую работу или просто "спасибо";
- постоянно писать кудосы своей команде;
- напоминать писать кудосы другим;
Здесь тот же принцип, что и с пустой джирой, опозданием на встречи и невыполнением любых обещаний: сначала сам начни делать, а потом проси команду.
В небольшой команде все варятся в общем информационном пузыре. Народу мало, проектов мало, все на виду. Если новый лид айосник оказался лодырем, это быстро станет заметно.
В большой не так, здесь легко затеряться.
Лид айсоник может каждые 4 месяца прыгать с проекта на проект. И тогда подбить его перфоманс становится трудно, т.к. у тебя, как у его менеджера просто нет инфы, как он переоформил. Ты, конечно, поспрашиваешь фидбека у других людей, кто с ним работал, но тут свои риски.
Для тех, кто делает пипл менеджмент такая непрозрачность, это большая проблема.
Есть классный инструмент, который ее решает - Small Improvements. Его главный функционал - написать публичный комплимент о коллеге.
В линкедине вы наверняка видели посты со словом Kudos, когда люди хвалят друг друга и выражают признательность. Тут то же самое.
Лид айосник сделал классный tech proposal новой фичи - напиши ему Kudos, чтобы все знали, какой он красавчик. Менеджер из другой команды быстро сделал то, что вы просили (в отличие от других менеджеров-бездельников) - Kudos. Продакт провел крутой воркшоп без воды и соплей - Kudos. Так ты “хвалишь при всех”, причем сразу на всю компанию.
Все кудосы собираются в общую ленту. Можно смотреть, какие кудосы получили твои ребята. Можно смотреть, кто тащер в других командах.
Люди не станут просто так хвалить друг друга за фигню (если вы не привяжите кудосы к kpi, конечно). Если пишут, то за дело. Получается честный, справедливый и адресный фидбек.
Теперь, если к тебе в команду месяц назад перешел айосник и надо сделать его годовое ревью, у тебя есть качественный источник информации.
В Small improvements кроме Kudos есть еще функционал 1-1, перф ревью, 360 фидбек и всякое такое. Но наверняка, есть и другие хорошие сервисы с Kudos. Напишите в комментарии, если пользовались такими.
-----------------
UPD: в комментах многие пишут, что в их компании такой подход не работает (спасибо, что делитесь опытом 🤝). Кудосы получают не реальные герои, те, кто общается с большим количеством людей или просто более говорливые и харизматичные люди.
Я думаю, это вопрос культуры. А любая культура всегда идет сверху.
Чтобы система работала, менеджеры должны:
- хвалить за успехи и результаты, а не ожидаемую работу или просто "спасибо";
- постоянно писать кудосы своей команде;
- напоминать писать кудосы другим;
Здесь тот же принцип, что и с пустой джирой, опозданием на встречи и невыполнением любых обещаний: сначала сам начни делать, а потом проси команду.
Английские сокращения, которые встретятся на работе за рубежом
🇬🇧 ETA - expected time of arrival.
Начнем с любимого вопрос менеджеров - когда будет готово?
🇬🇧EOD - end of day.
- Какой ETA у этой фичи?
- EOD.
Аналогично, EOW - end of the week.
🇬🇧СС - carbon copy.
Никто не расшифровывает СС, а просто ставят в копию:
Вы охренели, не сделали мою часть проекта! СС @Василий_Петрович.
🇬🇧 FTE - full-time employee.
Если в команде 2 разработчика фуллтайм, и 1 на пол-ставки, то говорят что в команде 2,5 FTE.
🇬🇧PTO - paid time off.
Не знаю, честно говоря, зачем тут делать упор на paid, но часто слышу, что так говорят. Особенно, в контексте parent leave.
🇬🇧OOO - out of the office.
На следующей неделе я буду в отпуске, так что все вопросики направляйте Василию Петровичу и держите меня в СС.
🇬🇧BRB - be right back.
Когда на звонке все сидят с включенными камерами, а к тебе в дверь звонит курьер и надо его встретить. Тогда ты пишешь в чате brb, как бы шепча всем присутствующим на ушко “я отойду на минутку, ща буду”, чтобы никто не дай бог не подумал, что тебе просто надоело слушать.
🇬🇧TBD - to be determined.
Так можно написать, когда, например, вы определились с датой релиза для фазы 1, а вот фаза 2 пока хз (TBD) когда будет готова.
🇬🇧WDYT? - what do you think?
Помню, как впервые увидел это в чате и подумал, wtf? Потом погуглил, и узнал, что это просто сокращенное что думаешь?
🇬🇧LMK - let me know.
Почти то же, что и wdyt.
🇬🇧FYI - for your information.
К твоему сведению….только не такое формальное.
🇬🇧IDK - I don’t know.
Я хз кароч.
🇬🇧AFAIK - as far as I know.
Насколько я знаю.
🇬🇧nvm - nevermind.
Забей.
🇬🇧ty, thx - thank you, thanks.
Если thx еще можно догадаться что такое, то с ty я орал, когда узнал что это просто спасибо.
🇬🇧dm - direct messages.
Цену отправил в лс (dm).
🇬🇧 ETA - expected time of arrival.
Начнем с любимого вопрос менеджеров - когда будет готово?
🇬🇧EOD - end of day.
- Какой ETA у этой фичи?
- EOD.
Аналогично, EOW - end of the week.
🇬🇧СС - carbon copy.
Никто не расшифровывает СС, а просто ставят в копию:
Вы охренели, не сделали мою часть проекта! СС @Василий_Петрович.
🇬🇧 FTE - full-time employee.
Если в команде 2 разработчика фуллтайм, и 1 на пол-ставки, то говорят что в команде 2,5 FTE.
🇬🇧PTO - paid time off.
Не знаю, честно говоря, зачем тут делать упор на paid, но часто слышу, что так говорят. Особенно, в контексте parent leave.
🇬🇧OOO - out of the office.
На следующей неделе я буду в отпуске, так что все вопросики направляйте Василию Петровичу и держите меня в СС.
🇬🇧BRB - be right back.
Когда на звонке все сидят с включенными камерами, а к тебе в дверь звонит курьер и надо его встретить. Тогда ты пишешь в чате brb, как бы шепча всем присутствующим на ушко “я отойду на минутку, ща буду”, чтобы никто не дай бог не подумал, что тебе просто надоело слушать.
🇬🇧TBD - to be determined.
Так можно написать, когда, например, вы определились с датой релиза для фазы 1, а вот фаза 2 пока хз (TBD) когда будет готова.
🇬🇧WDYT? - what do you think?
Помню, как впервые увидел это в чате и подумал, wtf? Потом погуглил, и узнал, что это просто сокращенное что думаешь?
🇬🇧LMK - let me know.
Почти то же, что и wdyt.
🇬🇧FYI - for your information.
К твоему сведению….только не такое формальное.
🇬🇧IDK - I don’t know.
Я хз кароч.
🇬🇧AFAIK - as far as I know.
Насколько я знаю.
🇬🇧nvm - nevermind.
Забей.
🇬🇧ty, thx - thank you, thanks.
Если thx еще можно догадаться что такое, то с ty я орал, когда узнал что это просто спасибо.
🇬🇧dm - direct messages.
Цену отправил в лс (dm).
Как окупаются тимбилдинги и корпоративы
На первой работе я думал, вау, компания так балует сотрудников, кормит нас красной рыбкой на корпоративе. Затем оказалось, что в некоторых фирмах по пятницам пиво и пиццу! Это казалось уже каким-то социальным экспериментом.
На деле такие ивенты нужны в первую очередь самой компании. Они повышают лояльность и вовлеченность сотрудников. Народ больше дружит, эффективнее работает и реже увольняется. И это все за каких-то 100-200 баксов на человека в год!
Недавно я устраивал тимбилдинг для своего отдела. Через час я слышу, что половина людей говорит о работе. Уже под другим градусом откровенности, но все же.
По той же причине топ компании строят мега-крутые офисы. Идея в том, чтобы люди проводили в них как можно больше времени. Когда у тебя под рукой спортзал, ресторан и массаж, то из офиса как будто и незачем уезжать. Все есть в кампусе. Ну а если вдруг придет хорошая идея по работе, то ты как раз уже в подходящей обстановке.
В общем, компания вкладывается в плюшки, чтобы ты поработал лишние 30 минут. Или познакомился с коллегой получше и стал более эффективным. Для кого-то это справедливая сделка, просто надо понимать, что если ты не платишь за товар (красную рыбку на корпоративе), то ты и есть товар.
Некоторые ребята, считают ее не такой справедливой и рассуждают так. Раз тимбилдинг, это рабочий ивент, то давайте проводить его в рабочее время. Но тут уже у компании юнит-экономика не сходится.
Я смотрю на тимбилдинги, как на возможность понетворкать (так же, как и на конференции). А нетворк - это моя забота. Если я хочу работать в этом месте, то для меня важны люди и контакт с ними, важно выстраивать эти связи. Это мне надо. Отношения, это вообще большая часть работы менеджера.
А раз так, то и на лазертаг меня зовите, и на картинг.
На первой работе я думал, вау, компания так балует сотрудников, кормит нас красной рыбкой на корпоративе. Затем оказалось, что в некоторых фирмах по пятницам пиво и пиццу! Это казалось уже каким-то социальным экспериментом.
На деле такие ивенты нужны в первую очередь самой компании. Они повышают лояльность и вовлеченность сотрудников. Народ больше дружит, эффективнее работает и реже увольняется. И это все за каких-то 100-200 баксов на человека в год!
Недавно я устраивал тимбилдинг для своего отдела. Через час я слышу, что половина людей говорит о работе. Уже под другим градусом откровенности, но все же.
По той же причине топ компании строят мега-крутые офисы. Идея в том, чтобы люди проводили в них как можно больше времени. Когда у тебя под рукой спортзал, ресторан и массаж, то из офиса как будто и незачем уезжать. Все есть в кампусе. Ну а если вдруг придет хорошая идея по работе, то ты как раз уже в подходящей обстановке.
В общем, компания вкладывается в плюшки, чтобы ты поработал лишние 30 минут. Или познакомился с коллегой получше и стал более эффективным. Для кого-то это справедливая сделка, просто надо понимать, что если ты не платишь за товар (красную рыбку на корпоративе), то ты и есть товар.
Некоторые ребята, считают ее не такой справедливой и рассуждают так. Раз тимбилдинг, это рабочий ивент, то давайте проводить его в рабочее время. Но тут уже у компании юнит-экономика не сходится.
Я смотрю на тимбилдинги, как на возможность понетворкать (так же, как и на конференции). А нетворк - это моя забота. Если я хочу работать в этом месте, то для меня важны люди и контакт с ними, важно выстраивать эти связи. Это мне надо. Отношения, это вообще большая часть работы менеджера.
А раз так, то и на лазертаг меня зовите, и на картинг.
Хорошие и плохие формулировки для увольнения
Увольнение - супер стрессовый момент. Переживать его болезненно, порой люди месяцами приходят в себя.
Сотруднику, конечно, в сто раз хуже, но и для менеджера это сложная ситуация. Просто произнести “ты уволен” пипец как тяжело. Слова здесь играют максимально важную роль и напортачить здесь легко.
Вот несколько формулировок, которые мне кажутся приемлимыми:
Нормально:
- Мы решили завершить с тобой рабочие отношения.
- Мы решили расторгнуть наш рабочий договор.
- Мы останавливаем наше сотрудничество.
- Мы больше не можем работать вместе.
Ну так:
- Мы решили попрощаться с тобой.
- У нас нет возможности продолжить наше сотрудничество (лукавство, потому что если нету возможности, то это сокращение, а не увольнение).
Плохо:
- Ты уволен (жестковато)
- Мы больше не нуждаемся в твоих услугах (я вам что, гараж сдаю? каких услугах?)
- Тебе / нам пора двигаться дальше (а раньше мы на месте стояли? куда двигаться?)
- Мы решили отпустить тебя (а раньше я что, привязан был?)
Дальше в разговоре надо обязательно объяснить, почему так произошло, с чем именно человек не справился, что вы советуете ему исправить в будущем. Еще хорошо показать, как вы - его менеджер - пытались помочь, но не получилось. Но это вы и без меня знаете.
Какие еще есть популярные формулировки? Напишите в комментарии 👇
Увольнение - супер стрессовый момент. Переживать его болезненно, порой люди месяцами приходят в себя.
Сотруднику, конечно, в сто раз хуже, но и для менеджера это сложная ситуация. Просто произнести “ты уволен” пипец как тяжело. Слова здесь играют максимально важную роль и напортачить здесь легко.
Вот несколько формулировок, которые мне кажутся приемлимыми:
Нормально:
- Мы решили завершить с тобой рабочие отношения.
- Мы решили расторгнуть наш рабочий договор.
- Мы останавливаем наше сотрудничество.
- Мы больше не можем работать вместе.
Ну так:
- Мы решили попрощаться с тобой.
- У нас нет возможности продолжить наше сотрудничество (лукавство, потому что если нету возможности, то это сокращение, а не увольнение).
Плохо:
- Ты уволен (жестковато)
- Мы больше не нуждаемся в твоих услугах (я вам что, гараж сдаю? каких услугах?)
- Тебе / нам пора двигаться дальше (а раньше мы на месте стояли? куда двигаться?)
- Мы решили отпустить тебя (а раньше я что, привязан был?)
Дальше в разговоре надо обязательно объяснить, почему так произошло, с чем именно человек не справился, что вы советуете ему исправить в будущем. Еще хорошо показать, как вы - его менеджер - пытались помочь, но не получилось. Но это вы и без меня знаете.
Какие еще есть популярные формулировки? Напишите в комментарии 👇
Процессы vs их отсутствие
С процессами жить в кайф. Понятно что и как работать, пользуешься готовыми гайдлайнами и шаблонами, не тратишь время на поиск нужных инструментов.
Проблема процессов в том, что их поддержка стоит денег. Надо постоянно что-то писать на вики, рисовать схемы, договариваться с другими отделами, следить, чтобы процессы не протухли, платить за лицензии, в конце концов.
Без процессов жить тоже круто - делаешь так, как имеет смысл в моменте.
Инцидент на проде? Починили и забыли, postmortem пройдет в голове программиста автоматически сразу после деплоя. Выкинули из спринта половину задач, чтобы помочь сейлам закрыть сделку? Супер, денежки на счету важнее красивого берндаун чарта.
Пока ситуация позволяет жить без процесса - не усложняй себе жизнь. Чем меньше у тебя процессов, тем больше времени остается на реальную работу.
В какой-то момент ты заметишь, что жить без процесса стало дорого. Например, твое приложение выросло и ошибки в проде стали заметно влиять на выручку. Значит, пришло время прикручивать логирование, мониторинг и вводить postmortem.
Можно прикрутить все это с 1 дня, супер быстро фиксить баги и иметь довольного тимлида. Но какой в этом смысл, если где-то плачет продакт, не нашедший маркет фит?
С процессами жить в кайф. Понятно что и как работать, пользуешься готовыми гайдлайнами и шаблонами, не тратишь время на поиск нужных инструментов.
Проблема процессов в том, что их поддержка стоит денег. Надо постоянно что-то писать на вики, рисовать схемы, договариваться с другими отделами, следить, чтобы процессы не протухли, платить за лицензии, в конце концов.
Без процессов жить тоже круто - делаешь так, как имеет смысл в моменте.
Инцидент на проде? Починили и забыли, postmortem пройдет в голове программиста автоматически сразу после деплоя. Выкинули из спринта половину задач, чтобы помочь сейлам закрыть сделку? Супер, денежки на счету важнее красивого берндаун чарта.
Пока ситуация позволяет жить без процесса - не усложняй себе жизнь. Чем меньше у тебя процессов, тем больше времени остается на реальную работу.
В какой-то момент ты заметишь, что жить без процесса стало дорого. Например, твое приложение выросло и ошибки в проде стали заметно влиять на выручку. Значит, пришло время прикручивать логирование, мониторинг и вводить postmortem.
Можно прикрутить все это с 1 дня, супер быстро фиксить баги и иметь довольного тимлида. Но какой в этом смысл, если где-то плачет продакт, не нашедший маркет фит?
Какое письмо прочитают
В этом году я вел пару проектов, в которых участвовало много команд. Самый большой затрагивал 33 команды, вместе с которыми мы раскатывали обновление реакта на фронте.
Когда координируешь такое количество зависимостей, коммуникация играет критическую роль. Чтобы люди поняли и сделали то, о чем ты их просишь, нужно сформулировать задачу максимально понятно.
Самое базовое, что надо упомянуть это:
- в чем суть задачи (гайдлайны, примеры, сколько примерно займет);
- почему мы это делаем;
- какие команды участвуют;
- какие сроки.
С этой инфой другие менеджеры уже могут что-то планировать.
Экспериментируя с форматом, я заметил, что влияет не только ЧТО ты пишешь, но и КАК. Ниже несколько таких экспериментов и как они влияют на реакцию:
📧Отправить письмо на [email protected] - 10 очков
📧Отправить письмо только на тех, кто участвует в проекте - 20
📧Отправить письмо утром - 10 (вечером = минус 10)
📧Перечислить команды \ тимлидов, от кого именно нужна помощь - 40
📧Упомянуть потенциальную прибыли от проекта (в деньгах) - 30
📧Поставить в копию менеджеров тех людей, от кого нужна помощь - 50
📧Поставить в копию СТО - 100
📧Написать то же самое каждому в личку - 70
📧Написать то же самое в публичный слак канал каждой команды - 100
📧Написать то же самое в джира тикете и перевести на менеджера - 30
Какие приемы у вас работают?
В этом году я вел пару проектов, в которых участвовало много команд. Самый большой затрагивал 33 команды, вместе с которыми мы раскатывали обновление реакта на фронте.
Когда координируешь такое количество зависимостей, коммуникация играет критическую роль. Чтобы люди поняли и сделали то, о чем ты их просишь, нужно сформулировать задачу максимально понятно.
Самое базовое, что надо упомянуть это:
- в чем суть задачи (гайдлайны, примеры, сколько примерно займет);
- почему мы это делаем;
- какие команды участвуют;
- какие сроки.
С этой инфой другие менеджеры уже могут что-то планировать.
Экспериментируя с форматом, я заметил, что влияет не только ЧТО ты пишешь, но и КАК. Ниже несколько таких экспериментов и как они влияют на реакцию:
📧Отправить письмо на [email protected] - 10 очков
📧Отправить письмо только на тех, кто участвует в проекте - 20
📧Отправить письмо утром - 10 (вечером = минус 10)
📧Перечислить команды \ тимлидов, от кого именно нужна помощь - 40
📧Упомянуть потенциальную прибыли от проекта (в деньгах) - 30
📧Поставить в копию менеджеров тех людей, от кого нужна помощь - 50
📧Поставить в копию СТО - 100
📧Написать то же самое каждому в личку - 70
📧Написать то же самое в публичный слак канал каждой команды - 100
📧Написать то же самое в джира тикете и перевести на менеджера - 30
Какие приемы у вас работают?
Как запускать большие проекты с зависимостями от других команд - Dependency mapping
Представьте, что разрабатываете фичу по отправке картинок в чат. Чтобы ее сделать, картинки нужно сохранить на сервер. За хранение всех данных в апе отвечает отдельная команда - data storage squad. Как убедить их взять нашу фичу в работу?
Можно вытащить их продакта на звонок, рассказать, какая это крутая фича, сколько она принесет денег компании и славы продакту, если взять ее уже в следующий спринт.
Правда у data storage squad есть свой роудмап со своими дедлайнами и стейкхолдерами. Даже если они вдохновятся нашей идеей, не факт, что они смогут тут же ее приоритезировать. Скорее всего, ответ будет “давайте через 2 квартала”.
Следующий шаг - эскалировать в своего менеджера или СТО. Если у нас нету полномочий ставить людей на проекты, то нужно найти того, у кого они есть, чтобы разобраться с зависимостью и запланировать проект.
В небольшой компании, где новые проекты стартуют нечасто, это вполне рабочий вариант. Обычно здесь 1 команда отвечает за 1 продукт. Поэтому и зависимостей не так много, СТО вполне может управлять этим вручную.
В большой компании новые проекты стартуют постоянно и над 1 продуктом работает сразу 5-10-20 команд. Зависимостей тут дофига и решать их по мере возникновения тяжело, нужен какой-то процесс. Обычно он является частью планирования, и повторяется раз в квартал или год. Называется dependency mapping и выглядит так:
👉 продакт пишет документ, описывающий проект;
👉 все команды собираются на воркшоп, где представляют свои проекты и обмениваются зависимостями;
👉 все принимают или отклоняют зависимости других;
👉 принятые зависимости идут в беклоги команд, по ним можно планировать разработку;
В первом посте в комментариях я более подробно опишу этот процесс.
По большому счету, на dependency mapping происходит все то же самое, что и на первом шаге, когда мы ходили к продакту. Только тут все команды делают это одновременно.
Плюс такого процесса в том, что не надо ждать, пока закончится какой-то эксперимент или там VP вернется из отпуска, чтобы принять решение. Есть четкий дедлайн за 2 недели дать ответ по всем зависимостям. Поэтому все фокусируются на этом планировании, быстро друг с другом договариваются и бегут вместе делать большие проекты.
Представьте, что разрабатываете фичу по отправке картинок в чат. Чтобы ее сделать, картинки нужно сохранить на сервер. За хранение всех данных в апе отвечает отдельная команда - data storage squad. Как убедить их взять нашу фичу в работу?
Можно вытащить их продакта на звонок, рассказать, какая это крутая фича, сколько она принесет денег компании и славы продакту, если взять ее уже в следующий спринт.
Правда у data storage squad есть свой роудмап со своими дедлайнами и стейкхолдерами. Даже если они вдохновятся нашей идеей, не факт, что они смогут тут же ее приоритезировать. Скорее всего, ответ будет “давайте через 2 квартала”.
Следующий шаг - эскалировать в своего менеджера или СТО. Если у нас нету полномочий ставить людей на проекты, то нужно найти того, у кого они есть, чтобы разобраться с зависимостью и запланировать проект.
В небольшой компании, где новые проекты стартуют нечасто, это вполне рабочий вариант. Обычно здесь 1 команда отвечает за 1 продукт. Поэтому и зависимостей не так много, СТО вполне может управлять этим вручную.
В большой компании новые проекты стартуют постоянно и над 1 продуктом работает сразу 5-10-20 команд. Зависимостей тут дофига и решать их по мере возникновения тяжело, нужен какой-то процесс. Обычно он является частью планирования, и повторяется раз в квартал или год. Называется dependency mapping и выглядит так:
👉 продакт пишет документ, описывающий проект;
👉 все команды собираются на воркшоп, где представляют свои проекты и обмениваются зависимостями;
👉 все принимают или отклоняют зависимости других;
👉 принятые зависимости идут в беклоги команд, по ним можно планировать разработку;
В первом посте в комментариях я более подробно опишу этот процесс.
По большому счету, на dependency mapping происходит все то же самое, что и на первом шаге, когда мы ходили к продакту. Только тут все команды делают это одновременно.
Плюс такого процесса в том, что не надо ждать, пока закончится какой-то эксперимент или там VP вернется из отпуска, чтобы принять решение. Есть четкий дедлайн за 2 недели дать ответ по всем зависимостям. Поэтому все фокусируются на этом планировании, быстро друг с другом договариваются и бегут вместе делать большие проекты.
Уходить с бесполезных встреч
Чтобы митинг прошел хорошо, нужна подготовка - позвать правильных людей, обозначать агенду, высылать заранее материалы.
Но как ни готовься, иногда встреча все равно заходит куда-то не туда. Например, застревают на одном вопросе, уходят в сторону или просто позвали кучу народу в формате «сходи, послушай». Сидеть на таких - мука и путь к выгоранию.
Высшим классом в такой ситуации считается сказать «коллеги, вижу, что я не добавляю ценности этому разговору» и выйти.
Чтобы так сказать, нужны смелость и определенная культура в компании. Где-то могут увидеть в таком поступке неуважение и даже грубость. Это же все равно, что развернуть большой плакат с надписью «встреча - кошмар, организатор - балбес». Хотя наша цель лишь тратить время с умом.
Если вы руководитель и хотите, чтобы такая культура пробивалась в команде, вам нужно самому пару раз так уйти с митов. И народ подхватит.
Тыщу раз слышал эту фразу «не стесняйтесь уходить, если встреча бесполезна для вас”. Но реально это работало, только когда люди видели, что менеджеры сами делают то, что советуют другим (<-совет на века).
На прошлой неделе как раз был свидетелем такой ситуации. Минут через 10 после начала тимлид сказал «знаете, вопрос ко мне почти не относится, я пожалуй пойду. Напишите потом, если будет что-то для меня». И ничего, никто не умер, даже наоборот, оставшиеся немного оживились и разговор пошел быстрее.
Чтобы митинг прошел хорошо, нужна подготовка - позвать правильных людей, обозначать агенду, высылать заранее материалы.
Но как ни готовься, иногда встреча все равно заходит куда-то не туда. Например, застревают на одном вопросе, уходят в сторону или просто позвали кучу народу в формате «сходи, послушай». Сидеть на таких - мука и путь к выгоранию.
Высшим классом в такой ситуации считается сказать «коллеги, вижу, что я не добавляю ценности этому разговору» и выйти.
Чтобы так сказать, нужны смелость и определенная культура в компании. Где-то могут увидеть в таком поступке неуважение и даже грубость. Это же все равно, что развернуть большой плакат с надписью «встреча - кошмар, организатор - балбес». Хотя наша цель лишь тратить время с умом.
Если вы руководитель и хотите, чтобы такая культура пробивалась в команде, вам нужно самому пару раз так уйти с митов. И народ подхватит.
Тыщу раз слышал эту фразу «не стесняйтесь уходить, если встреча бесполезна для вас”. Но реально это работало, только когда люди видели, что менеджеры сами делают то, что советуют другим (<-совет на века).
На прошлой неделе как раз был свидетелем такой ситуации. Минут через 10 после начала тимлид сказал «знаете, вопрос ко мне почти не относится, я пожалуй пойду. Напишите потом, если будет что-то для меня». И ничего, никто не умер, даже наоборот, оставшиеся немного оживились и разговор пошел быстрее.
Дата релиза
Вместе с продактом готовим к релизу небольшой внутренний продукт.
Делаем чек-лист, что нужно для запуска: демка, слайды, документация, отзывы от ранних пользователей, письмо с релизом, фидбек кого-то из топов, метрики, по которым потом оценим полезность продукта.
Дошли до выбора даты. Говорит, Рома, надо найти день, когда другие команды ничего не релизят, чтобы мы были в центре внимания хотя бы неделю.
Вот до этого я не додумался!
Напишите в комментах по какому принцип выбирали дату запуска фичи или продукта у себя.
Вместе с продактом готовим к релизу небольшой внутренний продукт.
Делаем чек-лист, что нужно для запуска: демка, слайды, документация, отзывы от ранних пользователей, письмо с релизом, фидбек кого-то из топов, метрики, по которым потом оценим полезность продукта.
Дошли до выбора даты. Говорит, Рома, надо найти день, когда другие команды ничего не релизят, чтобы мы были в центре внимания хотя бы неделю.
Вот до этого я не додумался!
Напишите в комментах по какому принцип выбирали дату запуска фичи или продукта у себя.
Каждый менеджер мечтает о команде, которая не зассыт сказать, что у него в зубах что-то застряло.
(на ушко)
(на ушко)
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% вылет. Почему так?
Потому что за это время мы узнали много нового о том, с чем работаем и убрали риски:
🤞 сработает ли эта библиотека;
🤞 так ли крут тот фронтедер, каким было его резюме;
🤞 как часто ПО будет менять задачи в спринте и насколько хорошо их прорабатывать;
Получается, со временем проектные знания растут сами по себе, а с ними и точность оценки. В принципе, можно плыть по течению и, спустя время, оценки станут немного точнее. Но так каждый джун умеет, поэтому в следующий раз мы порассуждаем о том, какими трюками ПМ может ускорить этот процесс.
