Дать сохранить лицо
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.
PM стрим со мной
На прошлой неделе сходил на стрим о ПМстве в роли спикера.
Там у всех директорские роли (кроме меня 🙊). Это как раз те, кто сегодня нанимает проджектов в Минске. Если думаете менять работу, то обязательно послушайте кого ищут в 2021 из первых уст.
Темы все насущные:
- как стать PM, что делать, кого читать и у кого поучиться;
- что происходит с методологиями в пандемию;
- роль Delivery manager и чем она отличается от PM;
Запись можно посмотреть тут: https://youtu.be/7vxs9ClL-Vs
На прошлой неделе сходил на стрим о ПМстве в роли спикера.
Там у всех директорские роли (кроме меня 🙊). Это как раз те, кто сегодня нанимает проджектов в Минске. Если думаете менять работу, то обязательно послушайте кого ищут в 2021 из первых уст.
Темы все насущные:
- как стать PM, что делать, кого читать и у кого поучиться;
- что происходит с методологиями в пандемию;
- роль Delivery manager и чем она отличается от PM;
Запись можно посмотреть тут: https://youtu.be/7vxs9ClL-Vs
YouTube
Современный Project Management
Обсудили с лидерами PM-индустрии 3 волны Agile, Delivery Management и менторство.
В закрепленном комментарии полезные ссылки.
⌛️ Таймкоды:
00:00 Знакомство
02:33 Классические подходы в управлении - Agile
05:36 2 модели применения Agile
12:14 Как живется…
В закрепленном комментарии полезные ссылки.
⌛️ Таймкоды:
00:00 Знакомство
02:33 Классические подходы в управлении - Agile
05:36 2 модели применения Agile
12:14 Как живется…
"Ясно, понятно"
- это последняя книга Максима Ильяхова, автора "Пиши, сокращай" и "Новые правила деловой переписки".
Я очень советую ее прочитать менеджерам и всем, кто работает с клиентами. Она помогает прокачать наш самый важный навык - коммуникацию.
В книге много примеров того, как быть удобным для собеседника. Она учит задавать правильные вопросы самому себе, прежде чем вообще что-то сказать:
- какой контекст у человека? что ему надо объяснять, а что он, по идее, знает? насколько он технически подкован?
- какие у него интересы? что для него будет важно, а какую инфу можно опустить?
Представьте, что делаете спринт репорт для своего босса. Там допустимо написать, что программисты балбесы (бывает и такое). Но этот же самый отчет у заказчика вызовет недоумение. Жалуетесь на своих собственных программистов? Для клиента такая версия отчета не пойдет, в ней много внутряка, который ему знать не нужно.
Берегите контекст, читайте "Ясно, понятно".
- это последняя книга Максима Ильяхова, автора "Пиши, сокращай" и "Новые правила деловой переписки".
Я очень советую ее прочитать менеджерам и всем, кто работает с клиентами. Она помогает прокачать наш самый важный навык - коммуникацию.
В книге много примеров того, как быть удобным для собеседника. Она учит задавать правильные вопросы самому себе, прежде чем вообще что-то сказать:
- какой контекст у человека? что ему надо объяснять, а что он, по идее, знает? насколько он технически подкован?
- какие у него интересы? что для него будет важно, а какую инфу можно опустить?
Представьте, что делаете спринт репорт для своего босса. Там допустимо написать, что программисты балбесы (бывает и такое). Но этот же самый отчет у заказчика вызовет недоумение. Жалуетесь на своих собственных программистов? Для клиента такая версия отчета не пойдет, в ней много внутряка, который ему знать не нужно.
Берегите контекст, читайте "Ясно, понятно".
Обещать меньше, делать больше
Когда я начинал работать ПМом мне тяжело давались переговоры с клиентами. Боялся, что заказчик подумает что мы лохи, не умеем делать сайты, развернется и уйдет. Всегда хотелось выглядеть представителем серьезной, опытной студии, использовать крутые технологии. Например, делать А/Б тесты.
На деле, разрабатывая сайты с бюджетом в 160 часов, ни на какие хотелки и А/Б тесты времени не остается. Задача ПМа в этом случае - сослаться на ограниченность бюджета и строго охранять проданный скоуп. Прости, дорогой заказчик.
У меня это не всегда получалось. Иногда клиент просил что-то мелкое и само собой разумеющиеся. Я входил в положение и брал в работу. В результате страдали бюджет компании или поставка. В обоих случаях, это была моя вина.
Сейчас я это понимаю, и чаще говорю "нет", чем "да". В конечном итоге выгоднее быть честными в том, что мы точно можем сделать, а что может-быть-влезет-в-самом-конце-если-останется-бюджет. Потому что, когда клиент замечает разницу между обещанием и поставкой, он расстраивается и винит команду.
Иногда звезды сходятся и в конце проекта остается немного времени и бюджета. И если потратить его на хотелки клиента, он надолго это запомнит и будет рекомендовать нас другим. Даже старые косяки забудутся.
Когда я начинал работать ПМом мне тяжело давались переговоры с клиентами. Боялся, что заказчик подумает что мы лохи, не умеем делать сайты, развернется и уйдет. Всегда хотелось выглядеть представителем серьезной, опытной студии, использовать крутые технологии. Например, делать А/Б тесты.
На деле, разрабатывая сайты с бюджетом в 160 часов, ни на какие хотелки и А/Б тесты времени не остается. Задача ПМа в этом случае - сослаться на ограниченность бюджета и строго охранять проданный скоуп. Прости, дорогой заказчик.
У меня это не всегда получалось. Иногда клиент просил что-то мелкое и само собой разумеющиеся. Я входил в положение и брал в работу. В результате страдали бюджет компании или поставка. В обоих случаях, это была моя вина.
Сейчас я это понимаю, и чаще говорю "нет", чем "да". В конечном итоге выгоднее быть честными в том, что мы точно можем сделать, а что может-быть-влезет-в-самом-конце-если-останется-бюджет. Потому что, когда клиент замечает разницу между обещанием и поставкой, он расстраивается и винит команду.
Иногда звезды сходятся и в конце проекта остается немного времени и бюджета. И если потратить его на хотелки клиента, он надолго это запомнит и будет рекомендовать нас другим. Даже старые косяки забудутся.
Какие отчеты делает менеджер
Никто, конечно, не любит отчеты, но они - часть нашей работы. Поэтому сегодня разбираем только обязательные для продукта и аутсорса. Поехали:
1️⃣ Sprint report. Что сделали за последние 2 недели, что не сделали, всякие графики, риски. Пример.
2️⃣ Потраченный бюджет для клиента. В этом отчете говорится сколько часов и денег потратила команда на задачи в проекте за период. Обычно делается раз в месяц, чтобы на его основе выставить счет клиенту. Пример.
3️⃣ Потраченные часы сотрудников для компании. Почти то же, что и предыдущий, но с поправками на невыставленные часы. Иногда бывает так, что за некоторые работы, клиент не платит. Например, если в фикс-прайс контракте прописан месяц поддержки. Тогда команда чинит баги после релиза бесплатно. Эту разницу "выставлено клиенту" / "сделано бесплатно" надо учитывать для финансистов компании, что и отражает этот отчет. В продукте его тоже делают, чтобы посчитать затраты на собственную разработку.
4️⃣ Incident report. Когда на продакшене беда, все суетятся и думают как починить проблему. На следующий день, когда страсти поутихнут, надо подвести итоги потерь. Пример недавнего аутэджа у Фейсбука.
5️⃣ Отчет по разработанным фичам. Иногда работаешь на российскую фирму, а деньги из апстора (или от клиента) приходят на дочернюю компанию, например, в США. Так делают, чтобы не держать деньги в наших банках. Так вот, в этом случае российское юрлицо передает права на разработку американскому, как будто одна фирма наняла другую. Отчет странный, но встречается часто.
Эти репорты ПМ делает постоянно. Но иногда просят сделать что-то кастомное, например, по качеству или успеваемости поставки. Поэтому важно иметь хороший спринт репорт, который покрывает все основные проектные темы.
Никто, конечно, не любит отчеты, но они - часть нашей работы. Поэтому сегодня разбираем только обязательные для продукта и аутсорса. Поехали:
1️⃣ Sprint report. Что сделали за последние 2 недели, что не сделали, всякие графики, риски. Пример.
2️⃣ Потраченный бюджет для клиента. В этом отчете говорится сколько часов и денег потратила команда на задачи в проекте за период. Обычно делается раз в месяц, чтобы на его основе выставить счет клиенту. Пример.
3️⃣ Потраченные часы сотрудников для компании. Почти то же, что и предыдущий, но с поправками на невыставленные часы. Иногда бывает так, что за некоторые работы, клиент не платит. Например, если в фикс-прайс контракте прописан месяц поддержки. Тогда команда чинит баги после релиза бесплатно. Эту разницу "выставлено клиенту" / "сделано бесплатно" надо учитывать для финансистов компании, что и отражает этот отчет. В продукте его тоже делают, чтобы посчитать затраты на собственную разработку.
4️⃣ Incident report. Когда на продакшене беда, все суетятся и думают как починить проблему. На следующий день, когда страсти поутихнут, надо подвести итоги потерь. Пример недавнего аутэджа у Фейсбука.
5️⃣ Отчет по разработанным фичам. Иногда работаешь на российскую фирму, а деньги из апстора (или от клиента) приходят на дочернюю компанию, например, в США. Так делают, чтобы не держать деньги в наших банках. Так вот, в этом случае российское юрлицо передает права на разработку американскому, как будто одна фирма наняла другую. Отчет странный, но встречается часто.
Эти репорты ПМ делает постоянно. Но иногда просят сделать что-то кастомное, например, по качеству или успеваемости поставки. Поэтому важно иметь хороший спринт репорт, который покрывает все основные проектные темы.
Project vs Program manager
Если вы присматривались к работе в продуктовой компании за пределами СНГ, то замечали, как редко там встречается должность project manger. ПМов на западе действительно меньше.
Обычно их заменяют связкой engineering manager (тимлид + немного менеджерских обязанностей) + product manager.
В больших продуктах есть похожая на проджекта роль - program manager. Это человек, который отвечает за большую инициативу, в рамках которой делают несколько проектов. Например, программ в Gmail может отвечать за интеграцию гугл рекламы Adwords и координировать работу 2 команд из разных продуктов - Adwords и Gmail.
Его миссия - связывать несколько команд единой стратегией и целью. Он асайнит людей на проекты, запускает новые, синхронизирует их работу, чтобы получить согласованный результат на выходе.
На прошлой работе я был как раз програмным менеджером. Мы делали продукт по поиску списывальшиков на онлайн экзаменах силами шести команд. Одна делала интеграцию с LMS, другая интерфейс для ревизоров, третья - онбординг для университетов и так далее. Всеми этими проектами управляло 2 менеджера, которых курировал я.
Это интересная работа, если вы устали от операционки на уровне баг-стори и готовы к масштабу уровня релиз-роудмап.
В блоге Atlassian очень понятно объяснили, чем отличаются эти две роли:
Если вы присматривались к работе в продуктовой компании за пределами СНГ, то замечали, как редко там встречается должность project manger. ПМов на западе действительно меньше.
Обычно их заменяют связкой engineering manager (тимлид + немного менеджерских обязанностей) + product manager.
В больших продуктах есть похожая на проджекта роль - program manager. Это человек, который отвечает за большую инициативу, в рамках которой делают несколько проектов. Например, программ в Gmail может отвечать за интеграцию гугл рекламы Adwords и координировать работу 2 команд из разных продуктов - Adwords и Gmail.
Его миссия - связывать несколько команд единой стратегией и целью. Он асайнит людей на проекты, запускает новые, синхронизирует их работу, чтобы получить согласованный результат на выходе.
На прошлой работе я был как раз програмным менеджером. Мы делали продукт по поиску списывальшиков на онлайн экзаменах силами шести команд. Одна делала интеграцию с LMS, другая интерфейс для ревизоров, третья - онбординг для университетов и так далее. Всеми этими проектами управляло 2 менеджера, которых курировал я.
Это интересная работа, если вы устали от операционки на уровне баг-стори и готовы к масштабу уровня релиз-роудмап.
В блоге Atlassian очень понятно объяснили, чем отличаются эти две роли:
This media is not supported in your browser
VIEW IN TELEGRAM
Буддисты и автоматизация
Это буддийский молитвенный барабан. На его поверхность наносят тексты священных писаний. Считается, что когда покрутишь барабан, то молитва как будто прочиталась.
Буддисты прошаренные. Зачем читать одну молитву в минуту, если можно сразу 30? Прогулялся вдоль храма, накрутил десяток барабанов, нахлопотал здоровья, денег и чего еще хочешь.
Покажите молитвенный барабан коллегам из соседнего отдела, которые до сих пор делают отчеты по аналитике вручную.
Это буддийский молитвенный барабан. На его поверхность наносят тексты священных писаний. Считается, что когда покрутишь барабан, то молитва как будто прочиталась.
Буддисты прошаренные. Зачем читать одну молитву в минуту, если можно сразу 30? Прогулялся вдоль храма, накрутил десяток барабанов, нахлопотал здоровья, денег и чего еще хочешь.
Покажите молитвенный барабан коллегам из соседнего отдела, которые до сих пор делают отчеты по аналитике вручную.
Ходить по собесам
Давайте вскроем ящик Пандоры. Зазорно ли ходить на собеседования в другие компании, когда уже есть работа?
Я думаю, что нет, т.к. мы с вами на рынке труда, со всеми вытекающими последствиями. Работа - не романтические отношения, где любовь до гроба и пока смерть не разлучит нас. Поэтому распространенный аргумент о лояльности компании все-таки мимо. Такие устои морально устарели, сейчас все меняют работу раз в 2-3 года (не берем в рассмотрение директорские роли и выше, для них другие правила игры). Ну и если компания с тобой честна, то никак не пострадает от того, что ты выяснишь свое положение на рынке.
На самом деле ходить по собесам и общаться с рекрутерами полезно. Это дает несколько важных штук:
1️⃣ Уверенность в себе и завтрашнем дне. Когда поступает пару предложений в месяц, то понимаешь, что не пойдешь по миру, если на текущем месте что-то пойдет не так. Так избавляешься от зачатков синдрома самозванца, когда думаешь, что компания делает тебе одолжение, давая работу.
2️⃣ Знание своей стоимости на рынке. Когда тебе предлагают +-300 долларов в районе текущей зп, то все ОК. Значит, сейчас ты получаешь свою честную, рыночную зп. Всегда будут места, где трава чуть зеленее. А вот если предлагают +700 и больше, и сразу в нескольких компаниях, то есть повод задуматься. Цифры условные, у всех разная зп, лучше, конечно, в процентах считать.
3️⃣ Понимание, каких знаний сейчас не хватает до следующего карьерного скачка. Иногда собеседование заканчивается отказом. Это нормально. Когда получаешь отказ, значит недотягиваешь до позиции, на которую хочешь. Отлично! По вопросам, которые задают, и финальному фидбеку можно хорошо порефлексировать и составить план роста.
Мне хватает 2-3 интервью в год, чтобы иметь более-менее ясное представление о себе и "оставаться в форме".
А вам?
Давайте вскроем ящик Пандоры. Зазорно ли ходить на собеседования в другие компании, когда уже есть работа?
Я думаю, что нет, т.к. мы с вами на рынке труда, со всеми вытекающими последствиями. Работа - не романтические отношения, где любовь до гроба и пока смерть не разлучит нас. Поэтому распространенный аргумент о лояльности компании все-таки мимо. Такие устои морально устарели, сейчас все меняют работу раз в 2-3 года (не берем в рассмотрение директорские роли и выше, для них другие правила игры). Ну и если компания с тобой честна, то никак не пострадает от того, что ты выяснишь свое положение на рынке.
На самом деле ходить по собесам и общаться с рекрутерами полезно. Это дает несколько важных штук:
1️⃣ Уверенность в себе и завтрашнем дне. Когда поступает пару предложений в месяц, то понимаешь, что не пойдешь по миру, если на текущем месте что-то пойдет не так. Так избавляешься от зачатков синдрома самозванца, когда думаешь, что компания делает тебе одолжение, давая работу.
2️⃣ Знание своей стоимости на рынке. Когда тебе предлагают +-300 долларов в районе текущей зп, то все ОК. Значит, сейчас ты получаешь свою честную, рыночную зп. Всегда будут места, где трава чуть зеленее. А вот если предлагают +700 и больше, и сразу в нескольких компаниях, то есть повод задуматься. Цифры условные, у всех разная зп, лучше, конечно, в процентах считать.
3️⃣ Понимание, каких знаний сейчас не хватает до следующего карьерного скачка. Иногда собеседование заканчивается отказом. Это нормально. Когда получаешь отказ, значит недотягиваешь до позиции, на которую хочешь. Отлично! По вопросам, которые задают, и финальному фидбеку можно хорошо порефлексировать и составить план роста.
Мне хватает 2-3 интервью в год, чтобы иметь более-менее ясное представление о себе и "оставаться в форме".
А вам?
Ходите на собесы, когда не собираетесь менять работу?
Anonymous Poll
4%
Хожу больше 6 раз в год
6%
Хожу 3-5 раз в год
26%
Хожу пару раз в год
64%
Не хожу
Неприкосновенность оценки
В зрелых инженерных организациях есть принцип неприкосновенности оценки. То есть то, что команда оценила в 2 месяца, ставится в план как 2 месяца. Нельзя просто придти и сказать, "мне пофигу, сделаете за месяц". Нет никакого смысла ставить месяц, все равно ведь не сделают.
Когда сейл и прод действуют сообща, понимая, что гребут в одной лодке, клиент остается довольным. Как ни странно, но ИТ бизнес тоже растет благодаря сарафанному радио и отзывам. Поэтому последнее слово в оценках остается за технарями.
В других компаниях следуют противоположной тактике. Сейлы оценивают проекты сами, исходя из платежеспособности клиента. А когда передают контракт в продакшн, он нередко заваливается по срокам из-за неточной оценки. Клиент уходит расстроенный, а сейлы ищут новую "жертву", благо, рынок огромный. Такие фирмы обычно небольшие, до 50 человек, (репутационные потери просто не дают вырасти) и с активной текучкой сотрудников.
Интересно, как обстоят дела в очень зрелых инженерных организациях, вроде Тесла или Эпл? Ведь атмосфера страха и высокая конкуренция на короткой дистанции все же дают результат.
Всем известно, что Стив Джобс, например, тот еще булли. Он уволил чувака, который засомневался, что тот сможет создать коммерчески успешную мышку. Возможно, благодаря такому подходу Эпл и создала столько крутых продуктов. Говорит ли Илон Маск "мне похер как эта штука взлетит, но за 3 недели, или вы все уволены"?
В зрелых инженерных организациях есть принцип неприкосновенности оценки. То есть то, что команда оценила в 2 месяца, ставится в план как 2 месяца. Нельзя просто придти и сказать, "мне пофигу, сделаете за месяц". Нет никакого смысла ставить месяц, все равно ведь не сделают.
Когда сейл и прод действуют сообща, понимая, что гребут в одной лодке, клиент остается довольным. Как ни странно, но ИТ бизнес тоже растет благодаря сарафанному радио и отзывам. Поэтому последнее слово в оценках остается за технарями.
В других компаниях следуют противоположной тактике. Сейлы оценивают проекты сами, исходя из платежеспособности клиента. А когда передают контракт в продакшн, он нередко заваливается по срокам из-за неточной оценки. Клиент уходит расстроенный, а сейлы ищут новую "жертву", благо, рынок огромный. Такие фирмы обычно небольшие, до 50 человек, (репутационные потери просто не дают вырасти) и с активной текучкой сотрудников.
Интересно, как обстоят дела в очень зрелых инженерных организациях, вроде Тесла или Эпл? Ведь атмосфера страха и высокая конкуренция на короткой дистанции все же дают результат.
Всем известно, что Стив Джобс, например, тот еще булли. Он уволил чувака, который засомневался, что тот сможет создать коммерчески успешную мышку. Возможно, благодаря такому подходу Эпл и создала столько крутых продуктов. Говорит ли Илон Маск "мне похер как эта штука взлетит, но за 3 недели, или вы все уволены"?
Я тебя услышал
Знаете, когда говорят "я тебя услышал" в значении "я понял твое мнение и мне на него наплевать"? В английском тоже есть подобного рода ехидные фразочки. Вот их расшифровка:
As per my last email = In case you didn't fucking read what I wrote before;
To reiterate = I'm not fucking saying it again;
Thank you for your input = No one fucking asked you;
Moving forward = That was the last time this shit came over;
As a kindly reminder = In case you fucking forgot;
Hope this email finds you well = Honestly, don't give a fuck about your life;
How can I help you to solve it? = This takes too fucking long. Solve it fast, I don't care how;
Best regards = тут либо fuck you, либо wish you the best, как повезет;
Знаете, когда говорят "я тебя услышал" в значении "я понял твое мнение и мне на него наплевать"? В английском тоже есть подобного рода ехидные фразочки. Вот их расшифровка:
As per my last email = In case you didn't fucking read what I wrote before;
To reiterate = I'm not fucking saying it again;
Thank you for your input = No one fucking asked you;
Moving forward = That was the last time this shit came over;
As a kindly reminder = In case you fucking forgot;
Hope this email finds you well = Honestly, don't give a fuck about your life;
How can I help you to solve it? = This takes too fucking long. Solve it fast, I don't care how;
Best regards = тут либо fuck you, либо wish you the best, как повезет;
Как держать беклог чистым
В тайм менеджмент есть такое правило двух минут. Если ответить на письмо занимает 2 минуты и меньше, то сделай это сразу, не откладывай в долгий ящик. Тогда инбокс будет пустой. И даже как-то немного приятнее станет работать, как когда порядок на столе.
Аналогичное правило можно применить и для беклога. У нас в команде оно звучит так:
❗❗ Если задача занимает меньше получаса, то делай ее сразу, не заноси в беклог.
Это дешевле, чем каждый раз спотыкаться об нее, пролистывая список задач.
К тому же экономится время на фокусе и контексте. Пока разработчик работает над фичей, ее устройство у него в "оперативной памяти". Правочки вылетают из Xcode, как горячие пирожки.
Когда он переходит на другую фичу, то подробности первой из памяти удаляются. Чтобы через месяц вернуться и что-то в ней доделать, придется вспоминать, как этот код работает. На это уйдет немного лишнего времени, поэтому лучше сразу.
В тайм менеджмент есть такое правило двух минут. Если ответить на письмо занимает 2 минуты и меньше, то сделай это сразу, не откладывай в долгий ящик. Тогда инбокс будет пустой. И даже как-то немного приятнее станет работать, как когда порядок на столе.
Аналогичное правило можно применить и для беклога. У нас в команде оно звучит так:
❗❗ Если задача занимает меньше получаса, то делай ее сразу, не заноси в беклог.
Это дешевле, чем каждый раз спотыкаться об нее, пролистывая список задач.
К тому же экономится время на фокусе и контексте. Пока разработчик работает над фичей, ее устройство у него в "оперативной памяти". Правочки вылетают из Xcode, как горячие пирожки.
Когда он переходит на другую фичу, то подробности первой из памяти удаляются. Чтобы через месяц вернуться и что-то в ней доделать, придется вспоминать, как этот код работает. На это уйдет немного лишнего времени, поэтому лучше сразу.
Еще один приемчик:
❗❗ Заводи все корнер кейсы, очень редкие баги, таски, которые хорошо бы когда-нибудь сделать, но прямо щас давайте отложим в отдельный проект.
Тоже чтобы не болтались под ногами и не раздували беклог. Смысл в том, что если их сейчас не стыдно отложить, то 99% что до них уже никогда не доберутся.
У нас такой список называется "Postponed bugs". В нем около 30 задач, в то время как во всем беклоге в районе 150.
❗❗ Заводи все корнер кейсы, очень редкие баги, таски, которые хорошо бы когда-нибудь сделать, но прямо щас давайте отложим в отдельный проект.
Тоже чтобы не болтались под ногами и не раздували беклог. Смысл в том, что если их сейчас не стыдно отложить, то 99% что до них уже никогда не доберутся.
У нас такой список называется "Postponed bugs". В нем около 30 задач, в то время как во всем беклоге в районе 150.
Лайфхаки в SaaS
На текущей работе я отвечаю в том числе за поддержку клиентов. Поэтому не могу пройти мимо круто построенного пользовательского опыта.
--------------------------------------
Зашел недавно на hotjar.com в поисках тулы для пользовательских интервью. За 30 сек не понял, решит сайт мою проблему или нет, и пошел спрашивать в саппорт. Здесь меня ждал сюрприз.
Сервис предлагает два варианта:
- "Написать в поддержку (среднее время ответа 1-2 бизнес дня)" или
- "Узнать в центре знаний (6-7 минут)"
Трюк здесь в том, что у всех SaaS есть и поддержка, и центр знаний (это обычный FAQ). И все отвечают примерно за 2 дня. Но hotjar с помощью трех слов о скорости ответа сделал второй вариант очевидно более привлекательным. В него будут чаще конвертиться, и меньше писать в саппорт. С такой формулировкой даже лентяй вроде меня задумается, стоит ли ждать 2 дня, если можно получить ответ почти сразу, поискав на сайте.
👍 Лайк!
На это еще не все. Жму "написать в поддержку", описываю свой юзкейс. И тут сбоку всплывают превью статей из того же FAQ, на основе ключевых слов моего запроса. То есть, когда, казалось бы, я уже ушел в поддержку, все еще есть шанс сконвертить меня в FAQ.
И это настолько естественно и ненавязчиво, что выглядит как забота о моем времени, хотя по факту ребята пытаются сэкономить на своих костах поддержки.
👍👍 Суперлайк!
На текущей работе я отвечаю в том числе за поддержку клиентов. Поэтому не могу пройти мимо круто построенного пользовательского опыта.
--------------------------------------
Зашел недавно на hotjar.com в поисках тулы для пользовательских интервью. За 30 сек не понял, решит сайт мою проблему или нет, и пошел спрашивать в саппорт. Здесь меня ждал сюрприз.
Сервис предлагает два варианта:
- "Написать в поддержку (среднее время ответа 1-2 бизнес дня)" или
- "Узнать в центре знаний (6-7 минут)"
Трюк здесь в том, что у всех SaaS есть и поддержка, и центр знаний (это обычный FAQ). И все отвечают примерно за 2 дня. Но hotjar с помощью трех слов о скорости ответа сделал второй вариант очевидно более привлекательным. В него будут чаще конвертиться, и меньше писать в саппорт. С такой формулировкой даже лентяй вроде меня задумается, стоит ли ждать 2 дня, если можно получить ответ почти сразу, поискав на сайте.
👍 Лайк!
На это еще не все. Жму "написать в поддержку", описываю свой юзкейс. И тут сбоку всплывают превью статей из того же FAQ, на основе ключевых слов моего запроса. То есть, когда, казалось бы, я уже ушел в поддержку, все еще есть шанс сконвертить меня в FAQ.
И это настолько естественно и ненавязчиво, что выглядит как забота о моем времени, хотя по факту ребята пытаются сэкономить на своих костах поддержки.
👍👍 Суперлайк!
Стадии развития команды
Психолог Брюс Такман предложил модель развития команды, которая хорошо ложится на наш ИТ мир. Менеджеры любят к ней апелировать и спрашивать на собеседованиях. Она несложная, убедитесь сами:
❗❗ Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.
Давайте рассмотрим каждую из них.
👋 Forming
На первой стадии все учтивы и доброжелательны, присматриваются друг к другу. Конфликтов избегают. Людям хочется произвести хорошее впечатление, поэтому они работают чуть лучше и больше обычного. Для менеджера это главное время зарабатывать авторитет и устанавливать границы что можно, а что нельзя.
🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.
Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".
На производительности это сказывается плохо, из-за споров и разногласий работа делается долго.
🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.
На этой стадии ПМ уже задумывается о делегировании.
💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.
Вот и все, теперь вы знаете модель Такмана.
--------------------------------
Картинка отсюда
Психолог Брюс Такман предложил модель развития команды, которая хорошо ложится на наш ИТ мир. Менеджеры любят к ней апелировать и спрашивать на собеседованиях. Она несложная, убедитесь сами:
❗❗ Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.
Давайте рассмотрим каждую из них.
👋 Forming
На первой стадии все учтивы и доброжелательны, присматриваются друг к другу. Конфликтов избегают. Людям хочется произвести хорошее впечатление, поэтому они работают чуть лучше и больше обычного. Для менеджера это главное время зарабатывать авторитет и устанавливать границы что можно, а что нельзя.
🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.
Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".
На производительности это сказывается плохо, из-за споров и разногласий работа делается долго.
🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.
На этой стадии ПМ уже задумывается о делегировании.
💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.
Вот и все, теперь вы знаете модель Такмана.
--------------------------------
Картинка отсюда
Зачем это надо
Зная эту схему, можно принимать управленческие решения с оглядкой на текущее состояние команды.
Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.
👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.
А по вашим?
Зная эту схему, можно принимать управленческие решения с оглядкой на текущее состояние команды.
Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.
👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.
А по вашим?
Как вырасти в ПМ (или в кого угодно)
Часто в директе спрашивают "Как перейти в ПМы?". Сегодня расскажу про самый простой и органичный, на мой взгляд, способ. Он состоит из 2х шагов.
Шаг 1. Спроси у своего менеджера, чем ему помочь.
У твоего менеджера точно много работы. Часть ее он будет рад делегировать. Попроси отдать тебе какую-нибудь простую задачу и научись делать ее хорошо.
Например, ты работаешь единственным тестером на проекте. Пишешь своему ПМу: "Саша, вот ты проводишь демо спринта каждые 2 недели. Мне хочется расти, можешь показать как ты его готовишь? Я бы мог продемить несколько фич в следующий раз, если тебе ОК. У тебя наверняка других дел по горло :)". Если Саша не мудак, то, скорее всего, ему ОК и он все покажет.
Потом Саша уйдет в отпуск и попросит провести ретру. Потом подключиться на звонок с клиентом. Так ты попробуешь одну задачу, вторую, третью и со временем получишь опыт по большинству обязанностей проджекта. Какие-то из них тебе даже отдадут на постоянной основе! Например, проектные отчеты любой ПМ с удовольствием делегирует навсегда 😎.
Проект растет, нанимают еще одного QA и, видя твою активность, назначают QA лидом. А там уже и до ПМ полшага.
Шаг 2. Внутренние собеседования.
Если целишься в работу проджекта, надо точно знать, чего ждут работодатели. Открой сайт с вакансиями ПМ и выпиши оттуда обязанности. Это список того, в чем надо разобраться и в идеале попробовать на шаге 1.
Научившись делать большую часть из них, пробуй пройти собеседование. Для начала проведи его в текущей компании, здесь к тебе более лояльны.
Найди ресурсного менеджера ПМов, расскажи ему, чем занимался и попроси прособеседовать тебя, как будто он нанимает обычного менеджера с рынка. Кстати, отзывы Саши тут могут пригодиться.
С первого раза работу вряд ли предложат. Но точно дадут фидбек, что надо докачать и может даже помогут с подготовкой. В этом преимущество проходить собес именно на текущем месте. Повторишь спустя 3 месяца, и через несколько таких итераций работа твоя.
Конечно же, на всех этапах подготовки помогут хорошие курсы, книги для новичков, семинары и так далее. Но это ты и сам знаешь.
------------------------------------------
Это универсальный подход. Пробуя новые задачи под присмотром человека, который уже умеет их делать, легко получить новые навыки. Как раньше из подмастерьев росли Микеланжело и Рафаэль, так и сейчас растут из разработчика в тимлида, из проджекта в продакты и в кого угодно вообще.
Часто в директе спрашивают "Как перейти в ПМы?". Сегодня расскажу про самый простой и органичный, на мой взгляд, способ. Он состоит из 2х шагов.
Шаг 1. Спроси у своего менеджера, чем ему помочь.
У твоего менеджера точно много работы. Часть ее он будет рад делегировать. Попроси отдать тебе какую-нибудь простую задачу и научись делать ее хорошо.
Например, ты работаешь единственным тестером на проекте. Пишешь своему ПМу: "Саша, вот ты проводишь демо спринта каждые 2 недели. Мне хочется расти, можешь показать как ты его готовишь? Я бы мог продемить несколько фич в следующий раз, если тебе ОК. У тебя наверняка других дел по горло :)". Если Саша не мудак, то, скорее всего, ему ОК и он все покажет.
Потом Саша уйдет в отпуск и попросит провести ретру. Потом подключиться на звонок с клиентом. Так ты попробуешь одну задачу, вторую, третью и со временем получишь опыт по большинству обязанностей проджекта. Какие-то из них тебе даже отдадут на постоянной основе! Например, проектные отчеты любой ПМ с удовольствием делегирует навсегда 😎.
Проект растет, нанимают еще одного QA и, видя твою активность, назначают QA лидом. А там уже и до ПМ полшага.
Шаг 2. Внутренние собеседования.
Если целишься в работу проджекта, надо точно знать, чего ждут работодатели. Открой сайт с вакансиями ПМ и выпиши оттуда обязанности. Это список того, в чем надо разобраться и в идеале попробовать на шаге 1.
Научившись делать большую часть из них, пробуй пройти собеседование. Для начала проведи его в текущей компании, здесь к тебе более лояльны.
Найди ресурсного менеджера ПМов, расскажи ему, чем занимался и попроси прособеседовать тебя, как будто он нанимает обычного менеджера с рынка. Кстати, отзывы Саши тут могут пригодиться.
С первого раза работу вряд ли предложат. Но точно дадут фидбек, что надо докачать и может даже помогут с подготовкой. В этом преимущество проходить собес именно на текущем месте. Повторишь спустя 3 месяца, и через несколько таких итераций работа твоя.
Конечно же, на всех этапах подготовки помогут хорошие курсы, книги для новичков, семинары и так далее. Но это ты и сам знаешь.
------------------------------------------
Это универсальный подход. Пробуя новые задачи под присмотром человека, который уже умеет их делать, легко получить новые навыки. Как раньше из подмастерьев росли Микеланжело и Рафаэль, так и сейчас растут из разработчика в тимлида, из проджекта в продакты и в кого угодно вообще.
Кейс про плохие новости
Представьте, что с вашего проекта решили уйти сразу 2 человека - разработчик Паша и тестировщица Оксана. Сотрудники ценные, не хотелось их терять, поэтому целую неделю вы обсуждали варианты, как им остаться. К сожалению, договориться не получилось и ребята уже гарантировано уходят.
Переговоры с Пашей закончились во вторник, с Оксаной - в четверг.
Представьте, что с вашего проекта решили уйти сразу 2 человека - разработчик Паша и тестировщица Оксана. Сотрудники ценные, не хотелось их терять, поэтому целую неделю вы обсуждали варианты, как им остаться. К сожалению, договориться не получилось и ребята уже гарантировано уходят.
Переговоры с Пашей закончились во вторник, с Оксаной - в четверг.