Котел ПМа

2021-04-09 14:15:56 ​​#ЖилбылПМ
Он сделал из рабочей группы настоящую команду, отлично отстроил все процессы, все важное задокументировал… И заскучал.
Но через неделю клиент попросил добавить еще одного девелопера.
И понеслось : найм, storming, выравнивание баланса между девелопментом и тестированием. В общем, недолго ПМ скучал на своем «идеальном» проекте. Відкрити / Коментувати

2021-04-06 12:53:25 ​​Prison Break. Escaped defects

У меня есть метрика-любимчик. Только тссс, не рассказывайте другим метрикам по качеству!
Это escaped defects.
Она показывает, скольким багам-удальцам удалось проскочить нашу доблестную команду тестировщиков и попасть на продакшен.
Понятно, что не у всех дефектов в приложениях одинаковая серьезность (severity). И не на каждый клиент попросит хотфикс.
Но вот те критичные, которые пришлось исправлять в срочном порядке, мы с командой будем тщательно изучать.

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

Это как будто у нас сбежавший преступник. Мы его в камеру вернем, конечно.
Но если не проанализировать побег, то жди и других беглецов.

А черешня на торте — это презентация результатов анализа для клиента.
Мы показываем, что сделали работу над ошибками, нашли возможные улучшения в процессе и оценили целесообразность их внедрения.
Так и клиенту спокойнее, и мы получаем карт-бланш на желанные изменения. Відкрити / Коментувати

2021-04-02 11:37:36 ​​One shot - one hit

Помните заметку "Благими намерениями"? Где самую сложную и непонятную фичу, вокруг которой строилась вся идея стартапа, оставили на самый конец? Потратили много времени и денег прежде, чем признали, что таки да, не можем мы это реализовать.

Поделюсь примером, когда риски были корректно оценены, и работа с ними спланирована на старте проекта.
Это был стартап, приложение для онлайн тренировок.
И для успеха проекта было крайне важно, чтоб видео на звонке было высокого качества из любой точки Швеции, включая поля и фермы. Надо заметить, что у них 4G покрытие несколько лет назад было не чета нашему, и шансы были неплохие.
До того, как заказать у нас разработку, клиент сделал самостоятельное исследование, проконсультировался с владельцами других шведских продуктов, которые зависят от качества видео звонков. И пришел к нам уже с требованием использовать конкретное стороннее решение для видео связи.
Мы понимали, что видео - сердце нашего приложения. И если "сердцебиение" будет не стабильным, то смысла наводить марафет и писать другие фичи тоже нет. Поэтому сфокусировались именно на этой части нашего продукта.
Мы сделали поверхностный анализ видео решения, изучили API документацию, запросили несколько встреч у их службы поддержки, чтоб посмотреть демо и задать вопросы.
Убедились, что продукт многообещающий, и не стали навязывать клиенту масштабное исследование альтернатив.
После чего сделали подтверждение концепта (proof of concept) - минимальное мобильное приложение, где ничего не было, кроме интеграции с Video API.
И отправили клиента в поля и леса тестировать качество связи. Ни один клиент в полях не пострадал, все было по обоюдному согласию, они были крайне заинтересованы в раннем тестировании ключевой гипотезы.
И только когда мы получили результаты, которые всех устроили, мы продолжили разработку остальной функциональности, которую определи как MVP.
У клиента не было бюджета на поиск и тестирование альтернативных решений. У нас был только один выстрел.
Но если бы мы промахнулись, клиент хотя бы не потратил бы все свои сбережения на релиз продукта, в котором не было бы ценности.
Стартап выжил и приносит своим владельцам прибыль. Відкрити / Коментувати

2021-03-26 13:54:45 ​​Мука. Хозяйкам на заметку. (Это все еще канал о менеджменте )

Какой сорт муки лучше - высший или второй?
И если предательский голосок в голове нашептывает: "Высший, выбери высший. Высший- всегда лучше", то гони его метлой!
Правильно будет сначала задать вопрос "А что готовим?"
Если сдобу или соусы, то да, очищенный сорт подойдет лучше.
Если пряники или пельмени - то второй сорт прекрасно подходит для этих целей. И по содержанию ценных веществ (белка, витаминов, минеральных веществ, клетчатки) мука второго сорта превосходит муку высших сортов.

Так и с ожидаемым уровнем качества на проекте. Не всегда клиенту нужно иметь систему "без дефектов". Часто сроки поставки или содержание релиза значат для клиента гораздо больше, чем высокий уровень качества и бесперебойность работы.
И здесь наша задача, как менеджеров, понять, какие у клиента приоритеты и ограничения, определить с ним acceptance criteria для продукта и организовать работу таким образом, чтоб гарантировать именно ожидаемый уровень качества - не выше и не ниже.
Потратить больше времени и денег клиента, чтоб выдать ему продукт выше качеством, чем он заказал, будет такой же управленческой ошибкой, как и отдать систему, которая не дотягивает до критериев приемки.

Пример самых простых acceptance criteria. Может подойти для бизнес системы, которую мы разрабатываем с нуля. Відкрити / Коментувати

2021-03-23 13:28:25 Культура команды строится на ценностях, убеждениях и поведении ее членов. Это про то, как люди идут к общей цели и как относятся друг к другу.
Можно было бы написать много постов на эту тему:
как формировать культуру,
какие риски, если ее не формировать,
привести примеры ценностей и моделей поведения, на которых можно построить разные культуры,
поделиться примерами, как культура команды в сложных ситуациях помогала вытянуть проект из кризиса,
помощь в адаптации новичков к неписанным правилам в команде и много чего еще.
Но зачем писать много текста, если можно один раз обо всем этом поговорить?

26 марта видео трансляция PM Meetup на Open Tech Week.
И одна из заявленных тем как раз “How to build a great team culture and why it matters”.
Это будет не доклад с презентацией, а живое интервью, где мы сможем все у Юли Шкуратовой подробно расспросить.
Регистрируйся, готовь свои вопросы, и до скорой встречи! Відкрити / Коментувати

2021-03-22 14:27:33 ​​Без бумажки ты

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

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

Дальше за дело взялся переводчик. И здесь надо сделать небольшое лирическое отступление. В мусульманских странах существует ежегодный налог, который направляется на благотворительность. Налог этот обязателен для всех. Название довольно романтичное – закят.
Переводчик, не вдаваясь особо в подробности и, видимо, пользуясь услугами Гугл транслейта, перевел непонятное, но знакомо звучащее слово, как вы думаете как? Правильно думаете – как «закат». И с чистой совестью ушел считать деньги за выполненную работу.

Волшебный договор продолжил путешествие к юристу и ПМу, которых должен был насторожить странный пассаж в тексте, что компания должна «заплатить закат». Но не насторожил!
Выходит, что к процессу все стороны подошли формально: переводчик формально сделал перевод, юрист и ПМ формально читали, а в итоге…

Нет, в итоге закончилось все неплохо, эту странность все же вовремя отловили и разобрались что к чему. Но что если бы нет? Тогда компания неожиданно для себя должна была бы заплатить по договору дополнительный налог в размере 10% от суммы контракта, что и составляло почти всю маржу проекта.

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

А вы как считаете, на ком в данном случае лежит бОльшая ответственность за этот факап?
#PMfuckup Відкрити / Коментувати

2021-03-19 19:19:53 ​​Несколько дней назад на открытом вебинаре в IAMPM я рассказала о том, как работать с изменениями, чтоб проект не погряз в хаосе. Но такую широкую тему за час не покрыть при всем желании, и даже с моим высоким темпом речи.
Не говоря уже о том, чтобы подробно разобрать кейсы участников и отработать практические навыки определения и обработки изменений.
Для более глубокого погружения человечество придумало интенсивные курсы и тренинги.
Коллеги из IAMPM разработали курс PM Hard Skills 2. Он как раз о change management-е, и не только.
Кроме работы с внешними и внутренними изменениями, в программе также заявлены:
Контроль выполнения проекта.
Мониторинг эффективности разработки и улучшение результатов.
Отслеживание эффективности проекта, опираясь на метрики.
Завершение и передача проектов.
Понимание процессов адаптации и управление ею в компаниях с разной структурой.

Для желающих поменять профессию пожарного на профессию ПМа, дарю скидку 20% на PM Hard Skills 2 по промокоду «Я от Елизаветы Бондаренко»
Скидок всего 3, и их получат первые, кто зарегистрируется на курс https://bit.ly/3lvPoYW
Кроме того, организаторы пришлют запись моего вебинара всем, кто оставит заявку. Вне зависимости от того, купишь ты курс или нет. Вдруг вот ты не знал, что бы такого полезного послушать в выходные? Відкрити / Коментувати

2021-03-15 12:14:33 Как PM’у работать с изменениями, чтоб проект не скатился в хаос?

Сопротивление изменениям бесполезно. Они так же природны, как дождь.
Что стоит за клиентским «отлично, а теперь все нужно переделать», «бросайте все задачи и берите в работу эту фичу», «давайте перенесем релиз с августа на июнь»?
И как с этим работать менеджеру, если сопротивление бесполезно?
Хорошая новость: мокнуть под дождем из изменений не обязательно. Во время прямой трансляции 17 марта я поделюсь своим опытом «приручения стихии».
Change management как зонтик, накидка и резиновые сапоги.

На вебинаре ты узнаешь:
Что не все изменения несут боль и страдания.
Как работать с изменениями в разных парадигмах управления проектами (Scrum, Kanban, PMI).
Что делать с изменениями при жестких ограничениях на проекте.
Простые правила, которые сделают контроль за изменениями легче: краткое резюме граблей за 11 лет моего РМ-ского опыта.
Приходи с вопросами и кейсами. Регистрируйся здесь. Відкрити / Коментувати

2021-03-12 16:20:53 Спрячь своего внутреннего супергероя

"Кто в ночи на бой спешит, Побеждая зло? Твердый клюв, отважный вид, Чёрное крыло.
Черный плащ!
Только свистни — он появится!"

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

Но так ли это нужно остальным?
Возможно, ребята и вспылили. Но остынут, подумают над аргументами друг друга и договорятся. И будут еще больше уважать товарища за профессионализм и классные контраргументы.

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

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

Разберем кейс.
В командном чате какая-то нездоровая атмосфера. Диалог примерно следующего содержания:
Девелопер: А почему ты не протестировал эту фичу?
Тестировщик: Потому что я тестировал другую. На дейлике слушать нужно было вообще-то про мои планы.
Девелопер: Я-то слушал. А вот чем ты слушал, когда ПО сказал, что моя фича - самая приоритетная?

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

Допустим, пришел опечаленный тестировщик. Говорит, что его не уважают, в общем чате с грязью смешивают.
Уточняем, какой помощи он от нас ждет. Научить девелопера вежливости? Или коучинга как противостоять мелкому хамству? Или оградить его от дальнейшего общения с этим разработчиком?

Если не выяснить, какой исход для него благоприятный, то можно вообще не на то направить усилия.
Например, ты учишь его постоять за себя. А он ждал извинений.
Ты потратил время и усилия. А он все равно тобой, как менеджером, не доволен.

Вообще это классный вопрос про ожидаемые действия - спасает не только на работе.
Жалуется друг на свое начальство. Ты чего, дорогой друг, хочешь? Совета? Чтоб тебя пожалели? Помощи в поиске новой работы? Відкрити / Коментувати

2021-03-09 17:14:21 ​​Благими намерениями…

#PMfuckup
Просчеты на этапе стратегического планирования, как правило, выливаются в самые крупные фейлы.
Если на старте участники проекта не договорились между собой о ролях, не подвергли критическому анализу идею продукта, не обсудили бизнес вэлью, не проработали план реализации и возможность реализовать задумку в принципе – все это прямая дорога в страну обманутых надежд.
Хотите примеры? Их есть у нас. Подброшено в котел ПМа подписчиком.

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

Помните «Теорию Большого Взрыва» и идею сделать телевизор, который бы все показывал в 3D? Ну чем не стартап? Популярность это решение получило бы совершенно точно. Только вот технической возможности реализовать идею не было. Нет, мы не собирались делать 3D телевизор. И это не единственная разница между нами и героями ситкома. Самая большая разница в том, что они дальше обсуждения идеи не пошли, а мы на нашем проекте пошли.

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

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

Бойтесь своих благих намерений и не беритесь за то, чего сделать заведомо не можете. Даже если очень хочется».
To be continued Відкрити / Коментувати