🔥Самые интересные материалы по управлению проектами за 2 недели

2/2

😪Какие книги помогли мне перестать «тушить пожары» и начать управлять командой? Небольшая подборка управленческой литературы, составленная инженером, которому пришлось учиться руководить уже по ходу работы. О книгах Тома Демарко, Патрика Ленсиони и других - и как они помогли ему разобраться с конфликтами, доверием, ответственностью и постоянным режимом аврала, причем все на реальных ситуациях.

😑МВА на минималках «Модель Айсберг для определения типа сотрудников в команде» Предельно простая типология сотрудников, основанная всего на двух показателях: сколько человек обещает и сколько в итоге делает. В итоге четыре типа — от громкого имитатора деятельности до незаметного сотрудника, который систематически выдает больше обещанного. Модель интересна еще и тем, что диагностирует руководителя: например, почему сильный специалист предпочитает молчать о своей работе.

🤪PMBOK Guide 8: в 2 раза меньше принципов и больше свободы Обзор восьмой редакции PMBOK как отхода от представления об управлении проектами как о наборе обязательных процессов и шаблонов. Количество принципов сократилось, основное внимание сместилось к созданию ценности, адаптации подхода под конкретную ситуацию, ответственности руководителя за осмысленный выбор методов. Стандарт старается примирить все модели, не объявляя ни одну из них правильной по умолчанию.

😪Ваши постмортемы — это поминки. И добрая половина процессов в компании тоже Текст разделяет организационные процессы на (1) инструменты, которые меняют реальность, и (2) символические ритуалы, которые лишь создают ощущение контроля. Среди второго и постмортем, после которого никто не меняет настройки, приоритеты или правила работы. Его роль часто сводится совсем не к предотвращению следующей аварии, а к коллективному переживанию предыдущей. В общем, кроме поминок, нужно проследить, что именно стало иначе после выполнения процесса.

😢Вы прочитали ТЗ. Теперь прочитайте его еще раз О том, почему недостаточно буквально выполнить написанное в техническом задании. Да потому что требования почти неизбежно содержат пробелы, неявные предположения и внутренние противоречия, а маленькая просьба “добавить кнопку” быстро обрастает много чем. Автор предлагает проверять, помимо формулировки задачи, еще и пользовательский сценарий, бизнес-цель, граничные случаи, последствия изменений и связь с остальной системой.

😶Ретро: Не Ной Слабо, Ной Достойно. Как Превратить Жалобы в Профит Типа кейс превращения ретроспективы из регулярной комнаты ярости в рабочий инструмент улучшения процессов. Сначала команда раз в две недели пыталась вспомнить всё, что её раздражало, выпускала пар и возвращалась к тем же проблемам. А потом… Ситуацию изменили единое пространство для фиксации наблюдений и обязательное превращение жалоб в конкретные действия. Жалобы важны, но польза и ценность появляются только тогда, когда за ними удаётся найти наблюдаемый факт и проверяемое изменение.

🥺Профессия «погоняла» теряет смысл: 80% менеджеров пойдут лесом Провокационный прогноз о нашем (?) будущем в мире ИИ. Под угрозой - руководители-передатчики, которые распределяют задачи сверху вниз и собирают статусы снизу вверх. Теперь это автоматизируется, а небольшие команды специалистов, усиленных агентами, смогут выполнять без передастов. Но все не так мрачно - постановка целей, разрешение противоречий, принятие решений, развитие людей и ответственность за систему по-прежнему нужны.

😈Закон Брукса: почему нанять ещё людей — худшее решение, когда проект горит Ликбез по закону - добавление людей в уже опаздывающий программный проект часто не ускоряет, а ещё сильнее задерживает его. Новичков нужно вводить в контекст, обучать и подключать к коммуникациям, соответственно, опытные начинают тратить на это время. Ну и не каждую задачу можно разделить между исполнителями. Это не значит, что расширять команды бессмысленно, но вот в момент кризиса найм часто служит психологически удобной заменой более трудным решениям.