Delivery sync
– это встреча менеджера проекта с руководителем раз в 1-3 недели, где обсуждается состояние проекта.
Для руководителя это возможность своими глазами убедиться, что на проекте все ОК.
Например, руководитель спрашивает «А что будет, когда в этот сервис зайдёт +100% пользователей?». И через такие вопросы ищет, где стрельнет.
Для менеджера деливери синк, это повторяющаяся напоминалка посмотреть на проект под критическим углом. К встрече ведь надо подготовиться! И самому сперва подумать, где стрельнет.
Еще через деливери синк менеджер учится у своего руководителя.
Когда я работал в Оксаджайле, мы открывали джиру с моим менеджером Стасом, и начиналось: «А почему не успели вот эти задачи в прошлом спринте? Как ты понимаешь, что успеете в следующем? А как заказчик отреагировал?». В первый год я сильно прокачался как ПМ, благодаря тем беседам.
На встрече обычно идут по чек-листу: скоуп, сроки, команда, заказчик, метрики. Вот один из чек-листов, которые мы использовали в то время.
Сейчас, в продуктовой компании, я участвую в деливери синках у нескольких команд, работа которых находится на критическом пути в моих программах. Иногда задаю вопросы, а иногда помогаю продактам и тимлидам на них отвечать.
———
Знаю, что во многих компаниях в той или иной форме проводят деливери синк.
Как он у вас называется? Ищу название на русском, которое передает суть встречи.
– это встреча менеджера проекта с руководителем раз в 1-3 недели, где обсуждается состояние проекта.
Для руководителя это возможность своими глазами убедиться, что на проекте все ОК.
Например, руководитель спрашивает «А что будет, когда в этот сервис зайдёт +100% пользователей?». И через такие вопросы ищет, где стрельнет.
Для менеджера деливери синк, это повторяющаяся напоминалка посмотреть на проект под критическим углом. К встрече ведь надо подготовиться! И самому сперва подумать, где стрельнет.
Еще через деливери синк менеджер учится у своего руководителя.
Когда я работал в Оксаджайле, мы открывали джиру с моим менеджером Стасом, и начиналось: «А почему не успели вот эти задачи в прошлом спринте? Как ты понимаешь, что успеете в следующем? А как заказчик отреагировал?». В первый год я сильно прокачался как ПМ, благодаря тем беседам.
На встрече обычно идут по чек-листу: скоуп, сроки, команда, заказчик, метрики. Вот один из чек-листов, которые мы использовали в то время.
Сейчас, в продуктовой компании, я участвую в деливери синках у нескольких команд, работа которых находится на критическом пути в моих программах. Иногда задаю вопросы, а иногда помогаю продактам и тимлидам на них отвечать.
———
Знаю, что во многих компаниях в той или иной форме проводят деливери синк.
Как он у вас называется? Ищу название на русском, которое передает суть встречи.
👍87❤25🔥19🤡3
Интервал вместо даты завершения проекта
Когда оцениваешь небольшой проект на 3-6 месяцев, очень трудно назвать точный день его завершения.
Будет 1 декабря или 2-ое? Обычно на этапе оценки у нас не так много данных, чтобы дать настолько точный прогноз.
Эту проблему решают несколькими способами:
1️⃣Как есть перевести трудозатраты в длительность и назвать дату. Например, 480 часов = 3 месяца от сейчас = 2 декабря. Проблема в том, что даже крошечный риск сдвинет эту дату, а значит мы с самого начала даем нереалистичное обещание.
2️⃣Добавить рисков, и назвать 30-ое декабря, но тогда могут вернуться с вопросами почему так долго.
3️⃣Можно сказать просто – закончим в декабре. Это ОК для больших проектов на 6+ месяцев, но для более коротких выходит снова слишком большой буфер.
Хорошая альтернатива – оценивать дату завершения в неделях (или спринтах). Например, закончим на 50-ой неделе (в 25 спринте), это вторая неделя декабря.
Так, у стейкхолдеров появляется достаточно точное ожидание по срокам. А у команды – зазор в целую неделю. Можно и в понедельник, 8-ого декабрая проект сдать, а можно и в пятницу, 12-ого.
Когда оцениваешь небольшой проект на 3-6 месяцев, очень трудно назвать точный день его завершения.
Будет 1 декабря или 2-ое? Обычно на этапе оценки у нас не так много данных, чтобы дать настолько точный прогноз.
Эту проблему решают несколькими способами:
1️⃣Как есть перевести трудозатраты в длительность и назвать дату. Например, 480 часов = 3 месяца от сейчас = 2 декабря. Проблема в том, что даже крошечный риск сдвинет эту дату, а значит мы с самого начала даем нереалистичное обещание.
2️⃣Добавить рисков, и назвать 30-ое декабря, но тогда могут вернуться с вопросами почему так долго.
3️⃣Можно сказать просто – закончим в декабре. Это ОК для больших проектов на 6+ месяцев, но для более коротких выходит снова слишком большой буфер.
Хорошая альтернатива – оценивать дату завершения в неделях (или спринтах). Например, закончим на 50-ой неделе (в 25 спринте), это вторая неделя декабря.
Так, у стейкхолдеров появляется достаточно точное ожидание по срокам. А у команды – зазор в целую неделю. Можно и в понедельник, 8-ого декабрая проект сдать, а можно и в пятницу, 12-ого.
🔥86👍45❤18😁6
Анонимный фидбек vs неанонимный
Когда мы собираем фидбек для перфоманс ревью, есть два способа, как это сделать – анонимно и нет.
С одной стороны, когда люди оставляют фидбек анонимно, он становится гораздо откровенее. Когда я знаю, что никто не придет с расспросами, я гораздо охотнее напишу, что продакт-директор – самодур.
С другой стороны, именно потому, что фидбек неанонимный, я вынужден пояснить, что продакт-директор бывает невнимателен к мнению команды, а также продавливает свои решения силой. Когда под фидбеком стоит мое имя, я лишний раз подумаю, что в нем написать. Не желая прослыть треплом, я вспомню примеры, детали, а это как раз самое ценное в фидбеке!
Я пробовал разные варианты, и самым эффективным, мне кажется, собирать фидбек неанонимно, а делиться уже анонимно, без имен. Так, я могу доуточнить детали у автора, если его обратная связь на уровне “продакт-директор – самодур”. А у самого автора появляется больше безопасности, чтобы говорить честно.
А вы как делаете?
Когда мы собираем фидбек для перфоманс ревью, есть два способа, как это сделать – анонимно и нет.
С одной стороны, когда люди оставляют фидбек анонимно, он становится гораздо откровенее. Когда я знаю, что никто не придет с расспросами, я гораздо охотнее напишу, что продакт-директор – самодур.
С другой стороны, именно потому, что фидбек неанонимный, я вынужден пояснить, что продакт-директор бывает невнимателен к мнению команды, а также продавливает свои решения силой. Когда под фидбеком стоит мое имя, я лишний раз подумаю, что в нем написать. Не желая прослыть треплом, я вспомню примеры, детали, а это как раз самое ценное в фидбеке!
Я пробовал разные варианты, и самым эффективным, мне кажется, собирать фидбек неанонимно, а делиться уже анонимно, без имен. Так, я могу доуточнить детали у автора, если его обратная связь на уровне “продакт-директор – самодур”. А у самого автора появляется больше безопасности, чтобы говорить честно.
А вы как делаете?
👍54❤7
👍3
👍2
Дожимать
Вспоминая проекты, которые я профукал, понимаю, что в некоторых тупо не дожал.
Решения, коммуникацию, риски.
Например, на одном проекте мы пропустили часть подготовки, из-за чего релиз провалился. За пару недель до этого я ходил-рассказывал всем о том, что “кажется мы падаем”, но делал это не слишком убедительно, и стейкхолдеры не считали серьезность проблемы. Не дожал.
Или в другой раз, мы решили переписать половину бекенда, чтобы пофиксить критичный баг. Идея с первого дня была спорной, уверенности в глазах разработки не читалось. Я это заметил, но забил, “делегировал”. Не вкопался в детали, не настоял сделать PoC, не поискал экспертизы снаружи. В итоге через полгода, мы не смогли зарелизиться и проблема осталась нерешенной. Снова не дожал.
Дожимать трудно. Часто это значит поднять неудобный вопрос или указать, что человек чего-то не сделал. Донести такое сообщение так, чтобы и проблему четко обозначить, не срезать углы, и еще и человека не обидеть – безумно трудно. Это я уже не говорю про внутренее сопротивление в таких разговорах.
Дожимать также не всегда уместно. Например, был у меня один сложный клиент, сам тот еще дожиматель. В момент, когда он сам оказался неправ, разумнее было дать ему сохранить лицо, чем дожимать.
Дожимание – сложное искусство, которому я постоянно учусь. Практики хватает, особенно в корпе, где миллион стейкхолдеров с разными интересами. Пару раз в неделю стабильно я нахожу себя в ситуации, где приходится выбирать между быть “удобным менеджером” и быть“дожимателем дел и вопросов”. Скажу по правде, второе получается далеко не всегда.
Вспоминая проекты, которые я профукал, понимаю, что в некоторых тупо не дожал.
Решения, коммуникацию, риски.
Например, на одном проекте мы пропустили часть подготовки, из-за чего релиз провалился. За пару недель до этого я ходил-рассказывал всем о том, что “кажется мы падаем”, но делал это не слишком убедительно, и стейкхолдеры не считали серьезность проблемы. Не дожал.
Или в другой раз, мы решили переписать половину бекенда, чтобы пофиксить критичный баг. Идея с первого дня была спорной, уверенности в глазах разработки не читалось. Я это заметил, но забил, “делегировал”. Не вкопался в детали, не настоял сделать PoC, не поискал экспертизы снаружи. В итоге через полгода, мы не смогли зарелизиться и проблема осталась нерешенной. Снова не дожал.
Дожимать трудно. Часто это значит поднять неудобный вопрос или указать, что человек чего-то не сделал. Донести такое сообщение так, чтобы и проблему четко обозначить, не срезать углы, и еще и человека не обидеть – безумно трудно. Это я уже не говорю про внутренее сопротивление в таких разговорах.
Дожимать также не всегда уместно. Например, был у меня один сложный клиент, сам тот еще дожиматель. В момент, когда он сам оказался неправ, разумнее было дать ему сохранить лицо, чем дожимать.
Дожимание – сложное искусство, которому я постоянно учусь. Практики хватает, особенно в корпе, где миллион стейкхолдеров с разными интересами. Пару раз в неделю стабильно я нахожу себя в ситуации, где приходится выбирать между быть “удобным менеджером” и быть“дожимателем дел и вопросов”. Скажу по правде, второе получается далеко не всегда.
🔥151❤60👍46👏7😇4👀3😁2💩1
Новый закон по Accessibility софта в Европе
Летом в Европе вступает в силу закон о доступности European Accessibility Act (EAA). Под его действие попадает любой бизнес, у которого есть сайт или приложение. Проверьте, не касается ли вас, а я расскажу немного деталей.
Чтобы выполнить требования закона, нужно соответствеовать стандарту WCAG 2.1 на уровне АА. Это главный в мире стандарт доступности, разработанный умными дядьками из World Wide Web Consortium еще в 1999 году.
Штрафы за невыполнение закона могут быть в районе 5-20К. А в Ирландии даже могут посадить в тюрьму!
Есть ли тут деньги
Еще как!
Задачи по доступности часто оказываются внизу беклога, т.к. на первый взгляд не приносят денег. Но это не совсем так. Вот несколько фактов для презентации вашему CPO:
▫️в США живет 61 миллион человек с ограниченными возможностями.
▫️70% из них выбирают продукты, в которых есть поддержка доступности.
▫️Расходы людей с ограниченными возможностями, составлют $8 трлн ежегодно.
Рынок есть, и немаленький, осталось научиться на нем зарабатывать.
Какие требования нужно выполнить
На практике, комплайенс означает поддержку 55 требований WCAG в продукте.
Среди них много логичных, которые сделают любой интерфейс удобнее. Например, размер иконок должен быть не меньше 24 пикселей или текст должен хорошо контрастировать с фоном.
По моим ощущениям, у среднестатистического сайта большая часть работы сведется к простановке лейблов и тегов, которые используют скрин ридеры. Кстати, посмотрите, как слепые пользуются инстой с его помощью.
Самый серьезный риск для разработки, на мой взгляд, касается пункта про портретный режим. Реализовать его поддержку с нуля в приложении безумно дорого.
Инструменты для разработки
Бесплатные тулы, которые сделают аудит вашего приложения или сайта:
▫️Accessibility Inspector, iOS;
▫️Accessibility Scanner, Android;
▫️Lighthouse, web.
Летом в Европе вступает в силу закон о доступности European Accessibility Act (EAA). Под его действие попадает любой бизнес, у которого есть сайт или приложение. Проверьте, не касается ли вас, а я расскажу немного деталей.
Чтобы выполнить требования закона, нужно соответствеовать стандарту WCAG 2.1 на уровне АА. Это главный в мире стандарт доступности, разработанный умными дядьками из World Wide Web Consortium еще в 1999 году.
Штрафы за невыполнение закона могут быть в районе 5-20К. А в Ирландии даже могут посадить в тюрьму!
Есть ли тут деньги
Еще как!
Задачи по доступности часто оказываются внизу беклога, т.к. на первый взгляд не приносят денег. Но это не совсем так. Вот несколько фактов для презентации вашему CPO:
▫️в США живет 61 миллион человек с ограниченными возможностями.
▫️70% из них выбирают продукты, в которых есть поддержка доступности.
▫️Расходы людей с ограниченными возможностями, составлют $8 трлн ежегодно.
Рынок есть, и немаленький, осталось научиться на нем зарабатывать.
Какие требования нужно выполнить
На практике, комплайенс означает поддержку 55 требований WCAG в продукте.
Среди них много логичных, которые сделают любой интерфейс удобнее. Например, размер иконок должен быть не меньше 24 пикселей или текст должен хорошо контрастировать с фоном.
По моим ощущениям, у среднестатистического сайта большая часть работы сведется к простановке лейблов и тегов, которые используют скрин ридеры. Кстати, посмотрите, как слепые пользуются инстой с его помощью.
Самый серьезный риск для разработки, на мой взгляд, касается пункта про портретный режим. Реализовать его поддержку с нуля в приложении безумно дорого.
Инструменты для разработки
Бесплатные тулы, которые сделают аудит вашего приложения или сайта:
▫️Accessibility Inspector, iOS;
▫️Accessibility Scanner, Android;
▫️Lighthouse, web.
👍54❤19🔥16👌1
Встречи без экшн айтемов
Все уже давно знают, что стоит записывать следущие шаги по результатам встречи. Это менеджерская база, так же как готовить темы для встречи.
Тем не менее я сам тыщу раз забивал на экшн айтемы. Например, думая, что раз вокруг меня такая сеньорная команда, то зачем. Мы же взрослые, ответственные люди, раз обсудили, значит, сделаем. Ага, ну да.
Нет, часто, оно и правда потом делалось. Но иногда оказывалось, что один не так понял, а второй забыл. И тогда дела продалбывались почти наверняка.
Например, обсуждая с командой недавний инцидент, приходим к тому, что причина непонятна и надо собрать больше данных.
Магия экшн айтемов в том, что когда начинаешь записывать, всплывает неудобная конкретика:
▫️один думал, что данные соберут аналитики.
▫️у аналитиков в этом спринте времени нет.
▫️а данные по проблемным сессиям у нас, оказывается, вообще не логируются.
Поэтому лучше записывать. Даже сениор директоры, работа которых мне иногда видна, записывают и не стесняются. И вы не стесняйтесь.
Все уже давно знают, что стоит записывать следущие шаги по результатам встречи. Это менеджерская база, так же как готовить темы для встречи.
Тем не менее я сам тыщу раз забивал на экшн айтемы. Например, думая, что раз вокруг меня такая сеньорная команда, то зачем. Мы же взрослые, ответственные люди, раз обсудили, значит, сделаем. Ага, ну да.
Нет, часто, оно и правда потом делалось. Но иногда оказывалось, что один не так понял, а второй забыл. И тогда дела продалбывались почти наверняка.
Например, обсуждая с командой недавний инцидент, приходим к тому, что причина непонятна и надо собрать больше данных.
Магия экшн айтемов в том, что когда начинаешь записывать, всплывает неудобная конкретика:
▫️один думал, что данные соберут аналитики.
▫️у аналитиков в этом спринте времени нет.
▫️а данные по проблемным сессиям у нас, оказывается, вообще не логируются.
Поэтому лучше записывать. Даже сениор директоры, работа которых мне иногда видна, записывают и не стесняются. И вы не стесняйтесь.
👍148❤41🔥17🤔1
Менеджерский трюк: вынести проблемный скоуп в отдельный майлстоун
Представьте, что вы запланировали 2 месяца на майлстоун-А, в котором нужно перевести сайт на английский язык.
Начали разработку, и поначалу все шло хорошо. Через пару недель обнаружили проблему в лендингах. Чтобы нормально использовать их на нескольких языках, нужно сначала порефакторить способ доставки ключей перевода. Иначе перевести лендинги возможно, но получится прям совсем костыльное решение. СТО в глаза будет стыдно смотреть.
И вот трюк:
🎩Поддержку лендингов выносим в отдельный майлстоун-Б.
Обосновываем так:
Когда мы закладывали 2 месяца на проект, то исходили из того, что лендинги заведутся легко, из коробки. Но оказалось, что они не поддерживают мультиязычность. Поэтому наш майлстоун-А все еще ЗЕЛЕНЫЙ, а поддержку лендингов мы сделаем позже, в майлстоуне-Б.
Формально проект был перевести весь сайт, и лендинги входят в его скоуп. По-хорошему, надо оставлять лендинги в майлстоуне-А и красить его в КРАСНЫЙ.
В заказной разработке обычно так и поступают, если заранее не включили мультиязычность в assumptions. И идут по пути костылей, потому что финансы важнее косых взглядов СТО.
В продуктовой компании посмотрят, что на лендинги ходит 5% пользователей, и скажут, что главная цель – перевести сайт – выполнена на 95%, вот и славно.
«Торги» скоупом – обычное дело на любом проекте. Трюк именно в том, что бы отделить проблемный скоуп от основной работы. Так, им легче потом торговать, а проект остается ЗЕЛЕНЫМ.
Представьте, что вы запланировали 2 месяца на майлстоун-А, в котором нужно перевести сайт на английский язык.
Начали разработку, и поначалу все шло хорошо. Через пару недель обнаружили проблему в лендингах. Чтобы нормально использовать их на нескольких языках, нужно сначала порефакторить способ доставки ключей перевода. Иначе перевести лендинги возможно, но получится прям совсем костыльное решение. СТО в глаза будет стыдно смотреть.
И вот трюк:
🎩Поддержку лендингов выносим в отдельный майлстоун-Б.
Обосновываем так:
Когда мы закладывали 2 месяца на проект, то исходили из того, что лендинги заведутся легко, из коробки. Но оказалось, что они не поддерживают мультиязычность. Поэтому наш майлстоун-А все еще ЗЕЛЕНЫЙ, а поддержку лендингов мы сделаем позже, в майлстоуне-Б.
Формально проект был перевести весь сайт, и лендинги входят в его скоуп. По-хорошему, надо оставлять лендинги в майлстоуне-А и красить его в КРАСНЫЙ.
В заказной разработке обычно так и поступают, если заранее не включили мультиязычность в assumptions. И идут по пути костылей, потому что финансы важнее косых взглядов СТО.
В продуктовой компании посмотрят, что на лендинги ходит 5% пользователей, и скажут, что главная цель – перевести сайт – выполнена на 95%, вот и славно.
«Торги» скоупом – обычное дело на любом проекте. Трюк именно в том, что бы отделить проблемный скоуп от основной работы. Так, им легче потом торговать, а проект остается ЗЕЛЕНЫМ.
👍94🔥19😁4❤3🤮2🖕1
Команда не вкладывается в оценки. Что делать?
Представьте, что приходите менеджером в новую команду. Быстро понимаете, что есть проблема с деливери – команда успевает завершить 60-70% того, что пообещала.
Что будете делать?
Вот буду делать я:
▫️проверю, как именно собирается статистика.
▫️спрошу у команды, в чем главная причина на их взгляд.
▫️проверю описание задач, понятно ли из них, что делать.
▫️проверю, что фичи разбиты на задачи размером хотя бы в 1-2 дня.
▫️уточню, самостоятельно ли команда дает оценку или кто-то делает это за нее.
▫️проверю, что в итерацию заложено время на риски и непрограммирование – встречи, тестирование и т.д.
▫️проверю, не успевает вся команда или 1-2 человека.
90% команд, с которыми мы работали над улучшением деливери, имели по крайней мере одну проблему из списка выше.
Представьте, что приходите менеджером в новую команду. Быстро понимаете, что есть проблема с деливери – команда успевает завершить 60-70% того, что пообещала.
Что будете делать?
Вот буду делать я:
▫️проверю, как именно собирается статистика.
▫️спрошу у команды, в чем главная причина на их взгляд.
▫️проверю описание задач, понятно ли из них, что делать.
▫️проверю, что фичи разбиты на задачи размером хотя бы в 1-2 дня.
▫️уточню, самостоятельно ли команда дает оценку или кто-то делает это за нее.
▫️проверю, что в итерацию заложено время на риски и непрограммирование – встречи, тестирование и т.д.
▫️проверю, не успевает вся команда или 1-2 человека.
90% команд, с которыми мы работали над улучшением деливери, имели по крайней мере одну проблему из списка выше.
🔥144👍44❤32🤔4😁1👀1
“Совет директоров” проекта (Steering Comittee)
Когда делаешь проект в большой компании, у тебя могут быть сотни стейкхоледров. Общаться со всеми лично врядли успеешь. Поэтому договариваешься о представителе из каждого юнита и решаешь вопросы уже с ними.
Раз в месяц главные представители собираются вместе, чтобы обсудить, как идут дела. Типо, как “совет директоров” проекта.
Такая встреча называется Steering committee, обычно сокращают до SteerCo.
По сути, это просто встреча с большими дядьками и тетьками, чтобы обкашлять вопросы.
Ценность стирко в принятных решениях.
Можно неделями пытаться договориться с продактами из разных отделов, кому делать кусок скоупа. Но когда собираются топ-стейкхолдеры, такие решения принимаются мгновенно. Это шанс для менеджера решить самые сложные блокеры.
———
Если знаете подходящий перевод для steering comittee – напишите в комментах.
Когда делаешь проект в большой компании, у тебя могут быть сотни стейкхоледров. Общаться со всеми лично врядли успеешь. Поэтому договариваешься о представителе из каждого юнита и решаешь вопросы уже с ними.
Раз в месяц главные представители собираются вместе, чтобы обсудить, как идут дела. Типо, как “совет директоров” проекта.
Такая встреча называется Steering committee, обычно сокращают до SteerCo.
По сути, это просто встреча с большими дядьками и тетьками, чтобы обкашлять вопросы.
Ценность стирко в принятных решениях.
Можно неделями пытаться договориться с продактами из разных отделов, кому делать кусок скоупа. Но когда собираются топ-стейкхолдеры, такие решения принимаются мгновенно. Это шанс для менеджера решить самые сложные блокеры.
———
Если знаете подходящий перевод для steering comittee – напишите в комментах.
👍76🔥19❤9👨💻4
Замечать успехи команды (Recognition)
Работая с несколькими топ-левел стейкхолдерами в этом году, заметил, как круто они отмечают успехи других. Порой буквально на ровном месте.
Например:
▫️”Ребята, настраиваю трекинг задач на проекте на 100 команд. Есть удачные примеры?”.
“Спроси Анну, она построила супер удобный трекинг для проекта Х в прошлом году”.
▫️”Я вычитаю твой документ до пятницы. Кстати, хочу сказать спасибо за то, как ты затащил тот проект без особой поддержки”.
▫️”Поздравляем Алекса с повышением до Senior product manager. Он сделал проекты А, Б и Ц, которые вырастили конвесию в…”. Такие письма менеджер Алекса отправляет на всю компанию.
Бывает, ответ на какой-то вопрос топа начинается издалека, и человек дает явно лишних продробностей. Но даже тут:
▫️“Спасибо, что объяснил, как работает сервис аутентификации. Не знал, что у него столько клиентов. Сейчас я хочу узнать о …”
В большой компании плохо видны успехи коллег. Пофиксить это можно через специальную тулу для благодарностей. Такая штука хорошо работает на вовлеченность команды. Писал о ней тут.
Вообще, хвалить в публичном пространстве – важная роль топов. На этих сообщениях и строится культура компании.
Работая с несколькими топ-левел стейкхолдерами в этом году, заметил, как круто они отмечают успехи других. Порой буквально на ровном месте.
Например:
▫️”Ребята, настраиваю трекинг задач на проекте на 100 команд. Есть удачные примеры?”.
“Спроси Анну, она построила супер удобный трекинг для проекта Х в прошлом году”.
▫️”Я вычитаю твой документ до пятницы. Кстати, хочу сказать спасибо за то, как ты затащил тот проект без особой поддержки”.
▫️”Поздравляем Алекса с повышением до Senior product manager. Он сделал проекты А, Б и Ц, которые вырастили конвесию в…”. Такие письма менеджер Алекса отправляет на всю компанию.
Бывает, ответ на какой-то вопрос топа начинается издалека, и человек дает явно лишних продробностей. Но даже тут:
▫️“Спасибо, что объяснил, как работает сервис аутентификации. Не знал, что у него столько клиентов. Сейчас я хочу узнать о …”
В большой компании плохо видны успехи коллег. Пофиксить это можно через специальную тулу для благодарностей. Такая штука хорошо работает на вовлеченность команды. Писал о ней тут.
Вообще, хвалить в публичном пространстве – важная роль топов. На этих сообщениях и строится культура компании.
❤65👍21🔥9💯2🤔1
Улучшенная версия реестра рисков – RAID
Чтобы было удобно следить за рисками, их часто вносят в отдельную табличку. Пишут, в чем именно риск, как будем его предотвращать и кто ответственный.
Это реестр рисков.
Иногда, кроме рисков хочется записать и другие штуки.
Например, что другая команда нам висит кусок скоупа (зависимость). Или, что субподрядчики задержали поставку фичи уже на 2 недели (проблема). Или, что мы считаем, что требования нового закона “переводятся” в вот такие фичи (допущение).
Для таких “расширений“, есть хороший формат – RAID.
RAID это тоже табличка, куда вносят:
R – risks (риски);
A – assumptions (допущения),
I – issues (проблемы);
D – dependencies (зависимости);
Я использую RAID как журнал того, что случилось на проекте. Например, встречаюсь с новым стейкхолдером и рассказываю ему, что было в “предыдущих сериях”. Особенно помогает на длинном проекте, т.к. вещи забываются.
Еще такая табличка помогает рефлексировать над проблемами – полезно открыть перед ретрой или когда делаешь SWOT-анализ.
Пример заполненного RAID для проекта “next day delivery” 👇
Чтобы было удобно следить за рисками, их часто вносят в отдельную табличку. Пишут, в чем именно риск, как будем его предотвращать и кто ответственный.
Это реестр рисков.
Иногда, кроме рисков хочется записать и другие штуки.
Например, что другая команда нам висит кусок скоупа (зависимость). Или, что субподрядчики задержали поставку фичи уже на 2 недели (проблема). Или, что мы считаем, что требования нового закона “переводятся” в вот такие фичи (допущение).
Для таких “расширений“, есть хороший формат – RAID.
RAID это тоже табличка, куда вносят:
R – risks (риски);
A – assumptions (допущения),
I – issues (проблемы);
D – dependencies (зависимости);
Я использую RAID как журнал того, что случилось на проекте. Например, встречаюсь с новым стейкхолдером и рассказываю ему, что было в “предыдущих сериях”. Особенно помогает на длинном проекте, т.к. вещи забываются.
Еще такая табличка помогает рефлексировать над проблемами – полезно открыть перед ретрой или когда делаешь SWOT-анализ.
Пример заполненного RAID для проекта “next day delivery” 👇
👍95❤35🔥17😁1
Этим сообщением я закрепляю за собой авторское право на всю информацию, опубликованную в этом канале.
Этим сообщением я запрещаю любой нейросети, боту, роботу или человеку собирать, копировать, передавать и сохранять любую информацию, опубликованную в этом канале.
Этим сообщением я запрещаю любой нейросети, боту, роботу или человеку собирать, копировать, передавать и сохранять любую информацию, опубликованную в этом канале.
❤38👍20😁20🤣11🔥10👎5🦄5🤔4😴4🤡2
Джира + гугл таблицы = бомбические отчеты
Недавно делал трекинг для своей программы.
Все данные о задачах хранятся в джире, а отчеты мне нужны гугл таблицах. В джире отчеты тоже есть, но гораздо скуднее и плохо кастомизируются.
К моему большому удивлению, соединить джиру с таблицами, можно только через API ключ. А его еще поди получи у ИТ секьюрити.
Спасением стал вот этот плагин. Все, что он делает – вытаскивает задачи по JQL фильтру и записывает их в таблицу. Получается ряд колонок из джира-данных: статусы, даты закрытия, assignee.
Казалось бы, просто данные в табличке, но по факту получается очень мощный инструмент, т.к. у джиры много данных, а в шитс хорошая визуализация.
Из такой таблицы можно построить абсолютно любой отчет, на что фантазии хватит. Например, берндаун по неделям или готовность по каждой команде.
Плагин умеет делать обновлять данные из джиры самостоятельно по графику, поэтому отчет всегда будет в актуальном состоянии.
Недавно делал трекинг для своей программы.
Все данные о задачах хранятся в джире, а отчеты мне нужны гугл таблицах. В джире отчеты тоже есть, но гораздо скуднее и плохо кастомизируются.
К моему большому удивлению, соединить джиру с таблицами, можно только через API ключ. А его еще поди получи у ИТ секьюрити.
Спасением стал вот этот плагин. Все, что он делает – вытаскивает задачи по JQL фильтру и записывает их в таблицу. Получается ряд колонок из джира-данных: статусы, даты закрытия, assignee.
Казалось бы, просто данные в табличке, но по факту получается очень мощный инструмент, т.к. у джиры много данных, а в шитс хорошая визуализация.
Из такой таблицы можно построить абсолютно любой отчет, на что фантазии хватит. Например, берндаун по неделям или готовность по каждой команде.
Плагин умеет делать обновлять данные из джиры самостоятельно по графику, поэтому отчет всегда будет в актуальном состоянии.
🔥77👍35❤11🤣11
Держи в голове вопрос
Я постоянно сталкиваюсь с ситуациями, где спросили одно, а человек отвечает на другое.
Например:
Еще это очень распространенная ошибка мок-интервью:
Каюсь, я и сам такой, иногда начинаю валить контекстом, как из пулемета. Все потому, что хочется отгрузить максимум деталей, чтобы человек меня получше понял. Итс окей!
Проблема в том, что мы порой забываем, о чем нас вообще спросили.
Штука, которая помогает лично мне, это держать в голове вопрос, который задали.
Если понимаю, что ухожу в дебри, то сам себе напоминаю вслух:
Или:
Я постоянно сталкиваюсь с ситуациями, где спросили одно, а человек отвечает на другое.
Например:
⁃ Какие задачи вы закроете, если мы добавим человека вам на проект?
⁃ Понимаешь, этот проект вылетает с первого дня, требования неточные, стейкхолдеры по неделе не отвечают…
⁃ [так а задачи? 🫠]
Еще это очень распространенная ошибка мок-интервью:
⁃ Расскажи про самую сложную техническую задачку на прошлой работе.
⁃ Вообще, мне еще со школы нравилось прогать. Понятно, что менеджерам это не всегда нужно….
⁃ [
так а задача?
🫠]
Каюсь, я и сам такой, иногда начинаю валить контекстом, как из пулемета. Все потому, что хочется отгрузить максимум деталей, чтобы человек меня получше понял. Итс окей!
Проблема в том, что мы порой забываем, о чем нас вообще спросили.
Штука, которая помогает лично мне, это держать в голове вопрос, который задали.
Если понимаю, что ухожу в дебри, то сам себе напоминаю вслух:
- Отвечая на твой вопрос, с дополнительным человеком, мы закроем эпики….
Или:
- Я наверное плохо объяснил, как связаны неточные требования и что дополнительно мы закроем. Давай объясню….
👍87❤30🔥8😁7💯3💩1
Эпик фейл
Как-то раз я получил самое обычное письмо от заказчика. Проблема была технической и я попросил разработчика ответить. Вопрос решился, заказчик остался доволен и даже написал, что мы молодцы.
Это был немного закрытый и не особенно щедрый на благодарности заказчик. Я решил воспользоваться ситуацией и похвалить разработчика, тем более, что это было одно из первых его писем.
Пишу на русском: “Пашка, красава, что все разрулил! Он обычно хмуро отвечает, а тут даже похвалил“. Вскоре приходит ответ, тоже на русском: "Я не есть хмурый”. От заказчика. 🤦
Эта история научила меня проверять получателей письма, прежде чем нажать кнопку отправить. А для новых тредов я сначала пишу письмо, а получателей заполняю прямо перед отправкой, чтоб наверняка.
Фейлы бывают у всех и это ОК. Через них хорошо учиться, например, проверять отправителя в письме.
Расскажете про свои?
Как-то раз я получил самое обычное письмо от заказчика. Проблема была технической и я попросил разработчика ответить. Вопрос решился, заказчик остался доволен и даже написал, что мы молодцы.
Это был немного закрытый и не особенно щедрый на благодарности заказчик. Я решил воспользоваться ситуацией и похвалить разработчика, тем более, что это было одно из первых его писем.
Пишу на русском: “Пашка, красава, что все разрулил! Он обычно хмуро отвечает, а тут даже похвалил“. Вскоре приходит ответ, тоже на русском: "Я не есть хмурый”. От заказчика. 🤦
Эта история научила меня проверять получателей письма, прежде чем нажать кнопку отправить. А для новых тредов я сначала пишу письмо, а получателей заполняю прямо перед отправкой, чтоб наверняка.
Фейлы бывают у всех и это ОК. Через них хорошо учиться, например, проверять отправителя в письме.
Расскажете про свои?
😁181👍55❤24🙈12🔥6
12 oz mouse (поллитровая мышь) – популярный мультик из середины нулевых. В нем гениальные диалоги в духе Саус парка и Масяни.
Недавно я пересмотрел несколько серий, и удивился, как многие из них будто списаны с наших ИТ реалий:
Недавно я пересмотрел несколько серий, и удивился, как многие из них будто списаны с наших ИТ реалий:
😁134🔥50❤16😢3