Распространённые ошибки при обсуждении целей проекта

Очень часто на встрече по обсуждению целей проекта все думают не о конечных целях, а о том, что и как надо сделать для их достижения.

Проведите рабочую встречу так, чтобы помочь всем сосредоточиться на конечных результатах, а не на деталях реализации. Чтобы добиться этого, описывайте результаты существительными, а не глаголами. Иногда может помочь mind map — визуализирует иерархическую структуру проекта.

Mind Mapping, или как заставить свой мозг работать лучше / Хабр

@badtechproject

#пятничное
@badtechproject

Микроменеджмент 🧟

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

@badtechproject

Хорошая подборка вакансий для PM’ов

https://facancy.ru/vacancies/18-vakansii-dlia-project-menedzherov-v-krupnykh-kompaniiakh

@badtechproject

Метод MoSCoW: учимся фокусироваться на главном🌇

Недавно узнал об одном из методов приоритизации, который используется в p3express.
Ничего особенного, на самом деле в нем нет, но вдруг, кому-то понравится из-за названия😁

Впервые этот метод стали применять в Oracle UK в 1994 году, после чего он стал неотъемлемой частью DSDM (Dynamic Systems Development Method: https://ru.wikipedia.org/wiki/DSDM).

Все задачи или требования делятся на 4 категории: must, should, could, would.
• Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.
• Should – не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».
• Could – желательные требования, которые можно сделать, если останется время и будут ресурсы.
• Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.

@badtechproject

Шаблоны - сила 💪

Шаблоны — это это то, что позволяет сократить time to market и масштабировать решения с наименьшими затратами ресурсов. Шаблонов бояться не нужно - это один из лучших инструментов для старта работы.

👉🏼 Имейте шаблонный набор для агенды. К примеру такие разделы:
📍 Обязательные участники
📍 Цель встречи
📍 Текущий статус
📍 Следующие шаги
📍 Открытые вопросы

👉🏼 Имейте шаблон для первого письма при онбординге сотрудника.

👉🏼 Имейте шаблон для задачи в JIRA.

👉🏼 Имейте шаблон письма при уходе в отпуск.

Шаблоны позволяют не забывать что-то важное, шаблоны наталкивают на мысль.

Шаблоны - это круто!

@badtechproject
#projectmanagement #productmanagement #SOFTWARE #PO #PM #TPM #CAREER

Сложные подчиненные

«Одной из основных причин появления у нас в коллективах сложных подчиненных оказывается… является сам руководитель, который где-то не заметил успехов сотрудника и не похвалил его, где-то в мелочах не пошел навстречу, где-то сам спровоцировал, где-то публично покритиковал, где-то перестал приходить вовремя на работу, где-то пообещал и не выполнил, а где-то поставил задачу и не проверил, как она выполняется.»

Максим Батырев: «Сложные подчиненные. Практика российских руководителей.»

@badtechproject

Токсичность или требовательность?

В какой момент требовательность результата стала токсичностью?

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

Каждый раз, когда приходится начинать обсуждение постановки четких целей, дедлайнов и т.п., людям начинает казаться, что ты слишком токсичен.
Хм…разве результат - это не то, для чего мы работаем?
А собери 5 разных лидеров продукта и спроси о целях, которых мы стремимся достичь и услышишь 5 разных мнений.

Свою работу надо ориентировать на достижение результата, а не на имитацию.

@badtechproject

Ситуационное лидерство

Я стал замечать одну проблему у middle manager‘ов, которые начинают руководить другими менеджерами в рамках своих проектов: западает понимание стилей руководства, которые нужно применять и когда это делать.

С чего стоит начинать для погружения в вопрос?

Ситуационное лидерство - это стиль управления людьми, предполагающий использование одного из четырех стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче.

👉🏼 S1 - директивность, говорим что и как делать. При этом сотрудник не хочет и не может.
👉🏼 S2 - наставничество, совмещаем мотивацию и конкретные руководства к действиям. При этом сотрудник мотивирован, но не знает «как».
👉🏼 S3 - поддержка, участие в принятии решений и поддержка, но решение принимает сам сотрудник. Сотруднику не хватает уверенности в себе.
👉🏼 S4 - делегирование, полная передача полномочий, прав и ответственности. Держитесь крепче и получайте удовольствие😉

В общем, разберитесь, кто перед вами и действуйте соотвественно.

@badtechproject

Фундаментальная ошибка атрибуции😩

Хорошо, что есть пояснение:

“…руководители склонны объяснять поступки сотрудника особенностями его личности, не учитывая, что его поведение в большей степени зависит от той ситуации и тех условий, которые создает сам руководитель.” Максим Батырев: «Сложные подчиненные. Практика российских руководителей.»

Пример из практики: есть начальник подразделения, который регулярно жалуется на отсутствие инициативы со стороны сотрудников, у него совсем нет времени и высокая загрузка, потому что каждый вопрос ему приходится решать самостоятельно.
Отсутствие инициативы - это следствие. Причина - неумение руководителя делегировать 🤷🏻

@badtechproject

Хороший гайд по конфликтам

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

Статья больше ориентируется на HR, но гайд полезен будет и тем, кто находится в конфликте и тем, кто выступает арбитром или модератором.

Как понять, что есть конфликт:
👉🏼 Люди начинают избегать взаимодействия с теми, с кем у них есть проблемы.
👉🏼 Эмоциональные всплески
👉🏼 Боязнь ошибок
👉🏼 Запреты работают лучше, чем советы из-за страха ошибиться

#career

@badtechproject

Писать письма ночью

Некоторые время назад я писал пост о том, почему не стоит писать письма в выходные https://t.me/badTechProject/18 и как это делать, «не привлекая внимание санитаров».

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

Но случай заставил меня задуматься еще об одной проблеме: усталость собеседника и его неверное прочтение вашего письма.

Случай: у меня заканчивался крупный проект и в пятницу вечером я начал писать «спасибо» на исполнителей и их боссов (квартал заканчивается и полугодие: самое время перед перфоманс-ревью поблагодарить всех), люди тоже активно отвечали. На часах 23:30…

К минусам подобных писем: если бы я начал рассылать отчеты или поручения и его тут же бы видели получатели?
Что будет, если они устали (семья или работа, отняли силы)?
Точно ли они прочитают мой посыл верно?
А что будет, если нет? Может быть в ответ на поручение меня пошлют куда подальше?

А как на счет отчета? Вдруг, босс начнет придираться к каждой строчке?

В лучшем случае, человек отложит мое письмо на понедельник и забудет его прочитать, тогда мне всего лишь придется напомнить о нем.

А в худшем, мне что-то начнут отвечать и совсем не то, что я хотел бы увидеть.

Старая мудрость: думай о читателе.

#career

@badtechproject

Кто о чем, а менеджеры про планирование

Как планировать так, чтобы не было больно

Во многих организациях сейчас идет горячая пора планирования на 2024.
Статья давно лежит у меня в заметках, я не совсем согласен с автором и не готов также радикально смотреть на вещи, но вот пара принципов, которым я стараюсь следовать и сам:

💯 ключевая задача при планировании выбрать то, чем не надо заниматься. Вот тут я готов голосовать всеми руками и ногами «за».

🤷🏻 планирование, тестирование, обсуждение новых идей должно идти заранее, а не в горячке формирования годовых OKR/KPI/планов. Это два разных подхода к планированию.

😱 уменьшайте зависимости в проектах. Это вторая важная работа любого менеджера.

🙈планирования снизу вверх - не работает. В контексте статьи и того, что не надо смешивать существующие проекты и новые инициативы, я согласен. Если же вырвать из контекста, то больше склоняюсь к тому, что это один из лучших подходов к планированию.

@badtechproject