О грубости и слабом менеджменте.

Давно не секрет, что одной из ролей, которые выполняет менеджмент в организации, является т.н. "поощрение-наказание". Это не означает порку, но в любой доступной форме менеджмент должен демонстрировать, какое поведение является приемлемым, а какое нет.

Точно так же не секрет, что менеджмент как прослойка страдает от разного рода искажений и откровенного членовредительства - от коррупции до некомпетентности. Эти явления напрямую влияют на возникновение перекосов в системе "поощрение-наказание", а значит, ведут к целому букету организационных проблем.

И сегодня мне попалась статья, которая, признаюсь, испортила мне настроение. Речь идет о грубости на работе. По оценкам, 98% сотрудников получали грубое отношение на работе в течение последнего года! Исследователи задались вопросом - если грубость на работе влечет за собой массу проблем (падение мотивации, проблемы со здоровьем, потерю ключевых людей), то, очевидно, здравомыслящий менеджмент принимает адекватные меры?

Как бы не так! Вот какие данные получили авторы из разных исследований:
🉐Сотрудники, которые сообщали о грубости в свой адрес, в большинстве своем воспринимались менеджментом как зачинщики, даже если доказано не совершали ничего плохого.
🉐Сотрудники, которые демонстрировали грубость к другим менеджментом как грубияны не воспринимались, под одним из двух условий: тесные отношения с боссом или топ-перформеры.
🉐Жертвы грубости воспринимаются менеджментом как сравнительно хуже работающие независимо от конкретных метрик производительности.

Как же уберечься от такой вопиющей предосудительности? Авторы исследования предлагают менеджерам проходить тренинги, схожие с тренингами судей и присяжных. А что вы можете сделать прямо сейчас:
❇️Сознательно разделяйте релевантную и нерелевантную информацию;
❇️Инвестируйте столько времени, сколько потребуется;
❇️Распознавайте и осознавайте влияние контекста и личных искажений на принятие решений;
❇️Проактивно изучайте когнитивные ловушки, в которые мы попадаем. Предупрежден - значит вооружен.

Сознательного вам управления.

#beardthink #практика

О итерациях и практиках.

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

Всем гибкости!

#beardthink #практика #agile

Пятничное. И месяц закрыли.

#beardlaugh

Об обязательности устава и говорящих пациентах.

Итак, в одном из предыдущих постов мы ликвидировали конфликт определений и разобрались с тем, что же такое Устав проекта. Следующим в повестке дня стоит вопрос его обязательности на проектах.

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

Разумеется, нет! История необходима для того, чтобы понять, с каким диагнозом поступил, как проходит лечение, какие прогнозы или изменения его состояния происходят. Пройдет какое-то время, и пациенты покинут палату, а врачам предстоит отчет об эффективности и результативности лечения, а также обучение молодых интернов на базе этой документации. Исходя из этого, я могу назвать четыре артефакта, которые считаю обязательными в абсолютно всех проектах:

🈯️ Устав проекта (Project Charter);
🈯️ Данные о ходе работ (Work Performance Data);
🈯️ Журнал изменений (Change Log);
🈯️ Выученные уроки (Lessons Learned).

Вопрос только в том, какой "толщины" будет "история болезни" у вашего пациента.

#beardthink #практика

​​О конференциях и стабильности.

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

Помимо традиционного для наших краев TBD вместо тем докладов некоторых спикеров, мое внимание привлек доклад, скриншот которого я привожу тут.

На дворе 2020 год, через год Аджайл Манифесту исполняется 20 лет. Это уже давно "новый ватерфол", который пытаются прислонить куда угодно - от маркетинга до бухгалтерий. А тема доклада "Что такое аджайл и аджайл мышление". И мы по-прежнему говорим о том, что "с аджайлом команды деливерят больше за то же время".

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

А вы посетили бы такую конференцию?

#beardlearn #мероприятия

О бесплатных вебинарах и рекламе.

В ковидное время множество программ обучения перекочевали онлайн, что логично и правильно. Изменилась и концепция продвижения этих программ. Перед их запуском нынче модно давать "бесплатные вебинары", чтобы закинуть наживку.

Все бы было ничего, но и я лично, и мои коллеги, кто делился опытом, отмечают стремительный перекос пропорции реклама/полезность в сторону первой. Расскажу такую историю. Недавно побывал на вебинаре по продажам, тема была действительно интересно заявлена. И каким-то образом я проспал момент, что этот вебинар предназначен для продажи буткемпа за много денег. Чтобы вы понимали абсурд ситуации, модератор вебинара рассказывала об этом буткемпе, буквально перебивая автора темы, пытаясь делать перебивки между разделами контента. Апофигеем этой феерии стала секция вопросов в конце вебинара, которая была просто прервана на 30% отвеченных вопросов в пользу дополнительной рекламы скидок на этот буткемп. И такие случаи в последнее время не единичны.

Чтобы не тратить свое время зря, поразмыслите над следующими пунктами:
🈯️ Увидев встречу в ФБ, оглянитесь в поисках организатора вебинара, найдите причину его запуска. 5 минут анализа могут сэкономить час-полтора вашего вечера.
🈯️ Посещайте мероприятия с темами, которые вас волнуют прямо сейчас. Если это для общего развития, быстрее будет прочесть блог.
🈯️ Конечно же, если вам интересно получить понимание о главном мероприятии, которое планируется, или получить на него скидку, это отличная возможность послушать спикера.
🈯️ Не стесняйтесь уходить с середины, если понимаете, что ситуация заходит в тупик. Ваше время - невозобновляемый ресурс.
🈯️ Самое главное и самое неприятное - не ждите чудес на бесплатных вебинарах. Бизнес есть бизнес, и если за информацию можно взять денег, за нее будут брать деньги. А если она бесплатна - значит, это кому-нибудь нужно =).

Этот несложный чеклист может легко сохранить вам пару-тройку часов в месяц на семью и друзей.

Подходите к своему обучению с умом. И хороших выходных!

#beardthink #beardlearn

О релизном планировании и слепоте от скорости.

Солидные 10% опрошенных ранее заявили, что Уставу проекта не место в гибких подходах. Давайте разберемся, так ли это.

В контексте продуктовой разработки, любой скраммастер скажет, что у нас есть Видение продукта и Цель спринта. Видение продукта - всеобъемлющая цель существования продукта, которая помогает направлять людей и принимать решения по развитию продукта. Цель Спринта - инструмент из Скрам Гайда, который разрабатывается в процессе планирования и отвечает команде на вопрос "зачем мы разрабатываем инкремент". Вроде бы все отлично и понятно. Проблемы начинают возникать на этапе, когда бизнесу становится интересно, а когда же функциональность, готовая для рынка (minimum marketable feature - MMF), до этого рынка дойдет. Или сколько времени (читай - денег) на нее нужно потратить, соответственно, как монетизироваться. Если мы взглянем на Видение продукта или Цель спринта, то мы найдем много вдохновения, у продвинутых владельцев продукта и скраммастеров - какие-то метрики. Отвечают ли они на заданные вопросы?

Нет. На заданные вопросы отвечает релизное планирование, которое многими либо критикуется, либо просто упускается по незнанию. Результатом которого должен быть артефакт, который задаст рамку на следующие несколько спринтов, а также поможет с управлением ожиданиями бизнеса и команды. На что же это может быть похоже? =)

Хорошо, хорошо, вы не хотите писать Устав. В конце концов, ребята на Lean Coffee засмеют. Что ж, у меня есть чем вам помочь:
🈯️ 1-Page Charter
🈯️ А3 Charter
🈯️ GO Product Roadmap

Эти инструменты работают прямо из коробки. Естественно, если есть понимание, вы вольны менять что угодно. К примеру, я часто использую GOPR с добавлением рисков и состава команды.

Релизное планирование - одно из средств борьбы с так называемой "слепотой от скорости" (Speed Blindness у Оливера Леманна). Этот феномен можно объяснить метафорой про тигриных жуков. Они являются одними из самых быстрых живых существ на планете. В то же время, ученых в свое время интересовал вопрос - почему, обладая такой скоростью, жук в погоне двигается зигзагами и с остановками? Причина оказалась в том, что насекомое движется так быстро, что натурально ничего не видит по сторонам. Поэтому оно вынуждено периодически останавливаться и осматриваться. И в нашем случае, Цель спринта слишком мала для обоснования выпуска массивных частей функциональности, а Видение продукта слишком далеко, чтобы на пути к нему ни разу не споткнуться. Именно для предотвращения "слепоты от скорости" нам и нужны путевые камни побольше (релизы) и их документация (аджайл-варианты Уставов).

Для более детальной информации рекомендую вот эту статью Романа Пихлера.

#beardthink #практика

Об уставах на все случаи жизни.

Подведем итоги ответов на тему Устава проекта.

1️⃣ Устав проекта - важнейший артефакт для любого проекта.
2️⃣ Не воспринимайте Устав как документ. Это концепция организации информации о проекте в одном месте, с целью облегчения к ней доступа и легкого выравнивания ожиданий сторон.
3️⃣ Поэтому даже в гибких подходах Уставы важны и нужны.
4️⃣ Если у вас есть сомнения по поводу применимости Устава для вашего проекта, задайте себе вопрос о размере Устава или его форме, а не его наличии.

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

#beardthink #практика

Не забывайте о своих маленьких победах! И хороших выходных.

#beardlaugh

Об осуществлении стратегии при помощи тактики.

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

Наш процесс продаж ориентирован на работу с топ-менеджментом на стороне клиента. В момент, когда сделка становится более реальной, на сцену выходит, как я его называю, "project execution level" - ПМы (или другие роли) с обеих сторон, ответственностью которых является воплощение стратегических задач, которые поставило руководство. Именно в этот момент главной сложностью является выравнивание участников всех уровней вокруг целей проекта или программы. Должен сказать, что наши сейлы справляются отлично, мы действительно глубоко копаем в бизнес-ценность и программное управление, предоставляем клиентам комплексные решения и не боимся бросать им вызовы. Но иногда чудеса начинаются там, где их не ждешь. Итак, кейс.

У клиента "Рога и копыта" стоит стратегическая тема - радикально преобразить устаревший продукт, чтобы оставаться конкурентным с молодыми стартапами, которые изначально инвестируют в UX. Открытую под эту цель программу полностью отдают нашей команде. И со стороны клиента ее курирует Джон. Проблема в том, что Джон по скиллсету является техническим лидером продукта, а не проектным или программным руководителем.

Сначала Джон выражал свое глубокое неудовольствие нашим желанием общаться с конечными пользователями. В конце концов, он и его руководитель и без этого отлично знают, что должно быть в продукте. Потом его перестало устраивать количество рекомендаций и новшеств, которые мы привносим в процесс разработки, потому что это отвлекает разработчиков от кодирования (для понимания, продукт существовал 5 лет без единого дизайнера в команде). Позже, он начал напрямую вмешиваться в исследовательский процесс, пытаясь навязывать желаемые компоненты в дизайн-систему. Апофеозом такого "менеджмента" стала следующая ситуация:

🈯️ Джон принял решение переформатировать наше участие в программе путем высвобождения наших UX-спецов в пользу внутренних свеженанятых джуниоров;
🈯️ Пока происходила передача проекта, эти джуниоры были определены в другие внутренние проекты;
🈯️ Как итог, Джон рисует вайрфреймы в Миро самостоятельно и хвастается, насколько это легко и просто =). Не нужно лишний раз говорить о качестве этой работы.

Что же, с точки зрения программного менеджмента, Джон делает не так?

㊙️ Джон не имеет компетенций по управлению проектами или программами в продуктовой компании. Конкретнее, он ничего не знает и не хочет слышать о user-centered design, UX research, design thinking.
㊙️ Джон не знает, как встраиваются discovery процессы в общий поток доставки ценности.
㊙️ Будучи проектным/программным руководителем по роли, Джон не считает нужным сверяться со стратегией компании при принятии важных решений.
㊙️ Джон не обновляет/не создает планы, если это продиктовано решениями, которые он принимает.
㊙️ Джона не заботит реализация выгод от программы, которую мы выполняем, он уверен, что программа выполняется "для него".
㊙️ Джон считает, что он все знает в домене и ему нечему учиться.
㊙️ Главная техника приоритезации для Джона - HiPPO (Highest paid person's opinion).

Не будь как Джон.

#beardthink #практика

О конкурсах и признании.

В этом году я удостоился чести стать одним из членов жюри на Ukrainian IT Awards в номинации "Менеджмент". Вместе с многоопытными коллегами из разных стран, доменов и компаний, мы будем выбирать лучшего ИТ менеджера Украины в 2020 году.

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

https://itawards.ua/

О достижениях и PfMP.

В среду я посетил вебинар Анатолия Савина - первого в Украине человека, сдавшего экзамен Portfolio Management Professional (PfMP).

Что для себя выписал:
🈯️ Подготовка заняла около 6 месяцев.
🈯️ Свободное владение английским (чтение без запинок) - обязательное условие сдачи. Экзамен не переведен, а каким языком написаны Стандарты знает любой, кто их пытался читать.
🈯️ Фазы "проекта по сдаче экзамена" - оформление заявки, проверка полноты заявки, аудит, панельный обзор.
🈯️ Заявки на аудит отбираются случайным образом, и таких немного.
🈯️ Но так или иначе, будет интервью с живым человеком. Это интервью нельзя пройти, если у кандидата нет существенного практического опыта в управлении портфелями.
🈯️ Ютуб - лучший инструмент для подготовки к экзамену.
🈯️ Для лучшего восприятия, не нужно зубрить теорию. Привязывайте концепции ПМИ к реальному опыту.

От себя добавлю, что как и в других вебинарах на данную тему, главная мысль - "боритеся - поборете". Подготовка + практический опыт - залог сдачи тяжелых экзаменов ПМИ.

#beardlearn

Ребята, если у кого есть в команде дизайнеры - пожелайте им хороших выходных. Выставьте им коктейль. У них тяжелая работа, правда.

https://www.youtube.com/watch?v=jVhlJNJopOQ&ab_channel=SaturdayNightLive

#beardlaugh

О характеристиках менеджера и кислороде.

Отвечая на вопросы, какие навыки культивировать в себе, чтобы стать отличным менеджером, предлагаю ознакомиться с результатами Project Oxygen by Google.

Итак, отличный менеджер по версии Гугла:

1️⃣ Является хорошим коучем
2️⃣ Отдает команде полномочия и не микроменеджит
3️⃣ Создает инклюзивное командное пространство, демонстрирует заинтересованность в успехе и хорошем самочувствии сотрудников
4️⃣ Продуктивен и ориентирован на результат
5️⃣ Является отличным коммуникатором - слушает и делится информацией
6️⃣ Помогает в карьерном развитии и обсуждает производительность
7️⃣ Имеет четкое видение и стратегию для команды
8️⃣ Обладает необходимыми навыками, чтобы помогать команде советами
9️⃣ Сотрудничает в рамках всей компании (в оригинале - Collaborates across Google)
🔟 Принимает решения.

Ссылка на оригинал в кнопке под сообщением.

Интересно, что этот перечень включает в себя как хард-скиллы (например, п.1 и п.8), так и софт-скиллы (например, п.5).

А какую из этих характеристик вы будете улучшать в ближайшее время?

#beardthink #карьера

Про рост и Дудя.

Продолжаем тему скиллов, характеристик и Гугла. Я наткнулся на пост Андрея Дороничева, директора по продуктам Гугла, многим известного как один из героев фильма Дудя про Кремниевую долину (все ссылки под постом). В этом посте он рассуждает о развитии лидерства, как он его видит. Мне показалось, что модель заслуживает ознакомления.

Итак, прямая речь:

1️⃣ Вы Стажер. Вы умеете выполнять поручения, действуя по инструкции. Иногда ошибаетесь.
Ваша миссия: учиться.

2️⃣ Вы Ассистент. Вы умеете выполнять не четко сформулированные задания. Задаёте уточняющие вопросы когда требуется.
Ваша миссия: помогать.

3️⃣. Вы Исполнитель. Самостоятельно отслеживаете задачи по мере поступления. Выбираете одно из подходящих известных решений.
Ваша миссия: следовать процессу.

4️⃣ Вы Специалист. Вы полностью берете на себя ответственность за решение задач и приходите с планом. Придумываете нестандартные и уникальные решения.
Ваша миссия: решать проблемы.

5️⃣ Вы Эксперт. Вы полностью отвечаете за область сложных задач и разрабатываете лучшие решения самостоятельно. Вы - "ракета с лазерным наведением": когда вам указали на цель, вы точно ее достигните.
Ваша миссия: находить лучшее решение.

6️⃣ Вы Ведущий Эксперт. Вы не только самостоятельно находите решения, но теперь вы ещё и формулируете новые задачи. На этом этапе вы "ракета с тепловым наведением" - чувствуете цель и следуете за ней.
Ваша миссия: видеть новые задачи и возможности.

7️⃣ Вы Управленец. Вы идентифицируете задачи и находите людей, которые их решат. Нанимаете и управляете сотрудниками.
Ваша миссия: строить структуру, способную находить и решать задачи.

8️⃣. Вы Директор. Вы отвечаете за стратегию и культуру команды. Находите, растите и назначаете управленцев. Дизайните структуру команды и процессы.
Ваша миссия: создать среду в которой сформируется структура, находящая и решающая задачи.

Найдите себя и оцените следующие шаги!

#beardthink #карьера

Прямо мои последние несколько недель.

С выходными всех!

#beardlaugh

Про обновления и Скрам.

Ну что же, год обновлений и улучшений продолжается! Вслед за второй версией Kanban Maturity Model, пятой версией Scaled Agile Framework и уже анонсированным седьмым изданием PMBoK, свежее обновление ожидается и для Scrum Guide!

Сам фреймворк уже давно вышел за рамки своего Руководства, которое ощутимо устарело. Тем интереснее будет узнать, каким образом авторам удалось сделать его еще более less prescriptive. Я обязательно изложу свое мнение по релизу после него. В то же время, вы можете все узнать из первых уст.

https://www.scrum.org/resources/2020-scrum-guide-launch-event

Увидимся там!

#beardlearn #beardthink

О честности и СAPM.

Ко мне часто обращаются с запросом на разработку карьерного плана и плана обучения. Иногда, в ходе дискуссий всплывал вопрос - имеет ли смысл получать сертификацию Certified Assosiate in Project Management (CAPM) или же просто бежать и терпеть в сторону PMP.

Несмотря на то, что многие стремятся к вожделенному РМР, нужно учесть, что опыт многих проектных руководителей не позволит пройти это испытание малой кровью. Интернет полнится историями о ПМах, которые при пилотной сдаче какого-нибудь пробного теста получают 30-50%, и потом героическими усилиями за полгода-год вызубривают ПМБоК + 1-2 вспомогательные книги типа Риты и таки сдают РМР. Становятся ли они после этого уверенными практиками?

Главная причина, почему так происходит - ваша организация (и предыдущие) не использует лучшие практики управления проектами. Вы можете быть "хорошим ПМом по версии вашей компании", даже сеньором, но вам будет сложно с экзаменом. РМР состоит из ситуационных задач, которые требуют понимания работы хорошего проектного руководителя.

Конечно же, как и любой другой экзамен, РМР можно "взломать" и все выучить. Грета Блаш в своей статье о разнице между САРМ и РМР отмечает, что несвоевременное получение РМР порождает специалистов, которые not able to manage their way out of a paper bag - теоретиков, но не практиков. Поэтому, если у вас недостаточно опыта или ваша организация не позволяет использовать лучшие практики в боевых задачах - сертифицируйтесь на CAPM, набирайтесь опыта и возвращайтесь.

Так или иначе, обучение - непрерывно. Не пытайтесь проглотить больше, чем способны откусить.

#beardthink #карьера

Оказывается, каждый первый четверг ноября отмечают International Project Management Day. С чем я вас всех и поздравляю!

Анализируйте проекты и не бойтесь задавать сложные вопросы.

#beardlaugh

И таки я согласен.

#beardlaugh