Карта стейкхолдеров, карта эмпатии, agile чаще проваливается, мотивация по Герчикову, эффект Черномырдина, цезари, запрещенные фразы и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест», а теперь ещё и в удобной базе знаний, где я собрал свыше 1700 статей по управлению проектами - с резюме, тегами и даже pdf-ками.
Основы, гайды и инструменты
Как составить карту стейкхолдеров
Как с помощью карты заинтересованных сторон понять, кто влияет на решение и чьё мнение критично для хода проекта. В основу авторы взяли простую схему с зонами влияния и интереса, которая помогает не забыть «невидимых» участников и заранее выстроить с ними отношения. Типовые случаи применения (запуск продукта, выход на рынок, сложные корпоративные внедрения) и пошаговые инструкции прилагаются. Плюс рекомендуется регулярно обновлять карту по фазам проекта, чтобы коммуникация всегда была «в тонусе».
Исследование показало, Agile-проекты проваливаются на 268% чаще
Пересказ результатов опроса инженеров в США и Великобритании - и внезапно у англосаксов гибкие проекты чаще сходят с дистанции, и наоборот, чётко зафиксированные ожидания повышают вероятность успеха. Однако не всё так просто, и хвала автору, что замечает это - во втором случае респондентам явно нравится не собственно waterfall, а связь с реальной большой проблемой и психологическая безопасность команды (все знают, куда идти и как долго идти). В общем, думайте…
Карта эмпатии: как понять клиента и составить рабочую схему
Материал объясняет, как карта эмпатии помогает увидеть мотивацию, страхи и ожидания клиента, не домысливая, а фиксируя дословные высказывания из интервью и отзывов. Авторы делают пошаговый разбор: когда составлять (от старта проекта до падения продаж), какие блоки включать и почему негативный опыт тоже важно заносить в карту. В итоге получается простая основа для требований и плана взаимодействия со стейкхолдерами.
Управление проектами: чек-лист для порядка
Краткий перечень ежедневных “пунктиков” для РП, дисциплинируем себя и команду: содержание работ (устав и структура), расписание (критический путь и резервы), команда (распределение ролей и наблюдение за нагрузкой), заинтересованные стороны (карта влияния и план общения) и прочие скучные, но важные вещи.
Ради чего люди ходят на работу? Пять типов мотивации по Герчикову
Кто-то знает, кто-то не знает, но это довольно известная типология мотивации сотрудников (инструментальная, профессиональная, патриотическая, «хозяйская» и избегательная). Для каждого типа - на что “жать”/ как вовлекать и что демотивирует, с учетом, что чистые типы - это абстракция, а чаще всего типы смешаны. Короче, пряники и кнуты нужно дифференцировать по типу личности.
30+ мессенджеров под разные бизнес-задачи. Чем заменить Teams, Slack и Jabber?
Обзор отечественных и вообще доступных на РФ-рынке решений для корпоративной переписки и совместной работы, разбитых по сценариям: асинхронное взаимодействие, «единое окно» общения и дополнение к основному рабочему инструменту. Есть практические критерии выбора вроде управления доступами, защиты переписки, поиска по чатам и интеграции с внутренними системами. Вывод, в общем, простой - выбирать надо не «по моде», а по рабочему сценарию и требованиям безопасности.
Делегирование без боли: как передавать задачи, чтобы их не возвращали обратно
Эссе о том, почему постановка «сделай вот так, как я бы сделал» ломает и людей, и сроки (потому что убивает инициативу и превращает лидера в «бутылочное горлышко»). А как надо? Автор предлагает схему: дать контекст задачи (зачем это нужно бизнесу), обрисовать ожидаемый результат (что именно должно быть на выходе) и дать свободу способов исполнения. (Там сложнее, еще договариваться о критериях приёмки, промежуточной демонстрации и тд, но в целом норм).
Как фанфик по Гарри Поттеру стал лучшей книгой по рациональному мышлению для программистов
Да, вот так вот - материал про легендарный фанфик про ГП (я лично даже начинал читать…). Коротко - про полезные приемы типа: обновления гипотез по мере появления данных, борьбы с искажениями мышления, силы экспериментов. Отдельно подчёркивается важность различать совпадение и причинно-следственную связь при разборе инцидентов. В целом - учимся сами и учим команду сомневаться в первых объяснениях, проверять альтернативы и фиксировать, что именно привело к улучшению (или ухудшению).
Jira для управления тестовыми проектами: советы по организации работы и документированию
Пошаговый разбор того, как настроить систему задач под нужды QA: фильтры и язык запросов для быстрых выборок, массовые операции для изменений «пачкой», публикация выборок на панелях.Много примеров и советов.
Парадокс Джевонса и «эффект Черномырдина» ИТ проектов: как оптимизация приводит к катастрофе
О том, как улучшение отдельного узла системы может усилить нагрузку на весь поток и обернуться падением качества. Парадокс Джевонса - это когда повышение эффективности увеличивает потребление ресурса. В проектах это проявляется как «успели больше — на нас свалили ещё». (ну и что-то напоминающее «хотели как лучше, а получилось как всегда»).
Разработка и управление требованиями
Систематизация работы с требованиями: от постановки цели и границ до формулировок, сценариев и критериев приёмки. Отдельный акцент — на свойства «качественного требования»: однозначность, проверяемость, осуществимость, связность с другими, на ведение единой структуры артефактов, прослеживаемость от задачи до результата и порядок изменения требований с оценкой влияния.
Почему ваше проектное управление никогда не будет работать
Автор разбирает типичные иллюзии: попытку заменить ясные цели количеством совещаний, надежду «урегулировать» неопределённость регламентами и веру в «срок из воздуха». Корни сбоев — отсутствие понятного результата для пользователя, несогласованные приоритеты и слабая ответственность за решение. Что делать? Вести единый список работ, делать открытые критерии «готово», ограничить параллельность и регулярно проверять пользу.
Эссе напоминает: технический долг — это сознательное заимствование времени (“по-быренькому” залатаем), за которое мы потом платим ростом сложности и рисков. И опасность не в самом долге, а в том, что о нём забывают и не закладывают погашение. Что предлагает автор - вести явный реестр долгов, оценивать «процентов» (во что выливаются задержки и ошибки) и плановую долю времени на возврат.
Kaiten после 7 лет в Jira: рассказываю про свой опыт
Автор сравнивает многолетнюю работу в крупной системе учёта задач с переходом на более лёгкий инструмент. Главная идея - избыточная сложность настроек, полей и схем статусов со временем начинает жить собственной жизнью и мешать работе. Соответственно, переход дал упрощение и повысил скорость работы. Адептам джиры не читать)
«По-старому нельзя, а как по-новому — не знали»: как мы изменили отдел разработки в Kaiten
Было много ритуалов, разрозненные обсуждения и перегрузки. А пришли к вычищению части ритуалов, к сквозному потоку задач с понятными этапами и ограничением незавершённых работ, а также правилами постановки/приемки задач. Результат — предсказуемость, меньше переделок и снижение стресса у исполнителей и руководителей.
Как провалить гос.IT-проект: 5 фатальных ошибок, из-за которых мы потеряли 98% бюджета
Кейс про личный провал с госами: неподъёмный объём работ, туманная цель, двойное руководство, закупки «как получится», отсутствие единого окна решений и прочие “прелести”, закончившиеся факапами. Основной вывод - начинать с чёткой задачи и полномочий: кто принимает решения, как согласуются изменения и что будет считаться результатом.
Менеджер проекта - карьера и навыки
Почему люди слышат не то, что вы говорите?
Простая, но важная статья - автор через личные кейсы показывает, как один и тот же разговор по-разному воспринимают люди с разным опытом и настроем. Даже такие вещи, как непривычная пунктуация, перекос в акцентах или «оценка результативности» без контекста порождают стресс и ошибочные выводы. Что делать? Проверять понимание («как ты это понял?»), подбирать подачу под адресата и не заменять смысл риторикой. Эмпатия и регулярные встречи один на один снижают шум в коммуникации и предотвращают накопление обид.
Начальник контролировал всё: ввел отчеты по часам, просил скрин экрана и считал походы в туалет
Ух, мощная статья - сама по себе и по собранным комментариям. На примерах разбираются бессмысленные форматы отчётности: «таблицы по часам», всеобщие видеосовещания-пересказы, «видеодневники» и внезапные требования «срочно отчитаться». Ну и рецепты “как правильно” - вместо тотального контроля прозрачность по данным: сводки задач в трекере, короткие рабочие созвоны, редкие показы результатов и отчёты, собранные автоматически. Отчётность «ради формы» подменяет работу, усиливает ошибки и ведёт к выгоранию.
Почему управлять людьми сложнее, чем писать код
Код предсказуем, а люди — нет: у сотрудников есть эмоции, личные обстоятельства и разные трактовки «готово». Автор подчёркивает важность бережной обратной связи, личных встреч и проговаривания очевидных вещей — иначе «сделано» для разных ролей значит разное. Конфликты и выгорание замечают раньше, если есть доверие и регулярный контакт, а критику подают лично и конкретно. Короче, надо менять фокус с инструментов на культуру и состояние команды.
«Генералы», «Цезари» и «Псевдоэксперты»: как договориться со сложным заказчиком
Что-то вроде практической типологии трудных клиентов: «вечно недовольный», «генерал», «цезарь», «истерик» и «скрытая угроза» — с признаками и рабочими тактиками. Советы варьируются от переговоров «через равных по статусу» и апелляции к нормам — до «двойной фиксации» договорённостей и аккуратного перевода решения в «его идею».
Нужная статья, хоть и не про менеджмент. Автор трезво описывает перекосы рынка, в котором мы с вами работаем: избыток новичков, слабое качество при завышенных ожиданиях и ужесточение отбора компаниями. Прогноз — больше очных собеседований, тщательная проверка резюме (привет, волки и чатгпт) и возврат к внутреннему росту из поддержки и начальных ролей. Параллельно усиливается кризис среднего возраста у опытных специалистов и эйджизм, но бизнесу всё равно придётся «вспомнить ценность экспертизы».
Про роль тимлида, а также несколько простых и полезных советов
Статья в каком-то смысле приземляет роль тимлида: это не «суперразработчик» и не «психотерапевт на полставки», а человек, который ведёт команду к результату. Его задача - понятные договорённости, распределение ответственности, регулярная обратная связь и защита времени на разработку. Не надо героизма, в общем)
Памятка менеджеру: Запрещённые фразы в IT. Часть 2
Автор разбирает ещё две «токсичные» фразы, которые портят отношения с заказчиком и командой и демонстрируют беспомощность и нежелание управлять. Вместо них предлагается использовать более уместный язык: уточнение контекста, предложение вариантов и договорённость о следующем шаге. И вообще, в статье много приземлённых формулировок, которые помогают выходить из тупиков на встречах.
Если у вас больше 5 созвонов в день — пора увольняться. Или начать делать это
А что “это”? А это запрет на крупные собрания без повестки, перенос статуса в трекер, короткие «точечные» синки и асинхронные апдейты. Поменьше ритуальных встреч, побольше “часов тишины” и информирования через систему, а не в совещаниях/созвонах.
Зовите тимлида! 5 историй о том, как помочь себе и своей команде
Пять кейсов из практики тимлидов: рост команды без потери фокуса, старт в новой роли, нестандартный найм, развитие сотрудника и распознавание тревожных сигналов. И главная тема - это что нужно слушать сигналы и вовремя реагировать на них.
Agile в эпоху удалёнки: что делать, если митинги больше не работают?
На удалёнке привычные ритуалы «разбухают» и теряют смысл, поэтому автор предлагает сместить акцент на асинхронность, короткие синки и работу по сигналам из системы. Стендапы превратить в текст, ретро разбирать не как в театральном кружке, а по фактам, планирование вестичерез единый бэклог и чёткие допуски. Меньше «контролировать голосом», больше визуализировать поток и ограничения.
Короткий манифест против «вечной пожарной команды». Автор призывает забить на “срочные задачи” и ограничить незавершённую работу, вернуть очередность и договориться о канале для экстренных случаев. Ну и нужны явные критерии «что такое срочно» и кто вправе это объявлять.
Команда проекта
Как правильно вести учёт рабочего времени
Коллеги из weeek объясняют, что учёт времени - не про слежку, а про планирование и выравнивание нагрузки. Отсюда и роли ответственных (кадровая служба, администраторы систем, руководители направлений и руководители проектов), основные форматы учёта (по дням, по задачам и др.) и как выбирать их под тип работ. Есть критерии выбора инструмента: простота фиксации, отчёты по людям и задачам, связка с задачником и календарями.
Онбординг в графиках: как превратить адаптацию в измеримый и предсказуемый процесс
Материал предлагает рассматривать адаптацию новичков как понятный процесс с метриками (к примеру, время до продуктивности, доля самостоятельных задач, скорость прохождения обучения). Это помогает увидеть узкие места: где теряются дни, где не хватает наставника или учебных материалов.
Сотрудник «буддист»: анализ уязвимостей и краткий мануал для руководителя
Буддист - это тип сотрудника, который внешне спокоен и не вступает в конфликты, но легко уходит в пассивное сопротивление. Главные риски с таким товарищем - размытые договорённости, отсутствие явных сроков и надежда на «само как-нибудь сложится». А способ работы с ним - это максимальная точность целей, результатов, критериев и т.д.
Как создать самообучающуюся команду: рабочие инструменты, способы мотивации и чек-лист
Статья собирает практику постоянного обучения прямо в потоке работы. Тут и короткие разборы ошибок, и обмен знаниями, и наставничество, и «малые эксперименты». Важно создать цикл «заметили -попробовали - измерили - внедрили», только так обучение даёт результат, а не копит презентации.
Пять паттернов поведения: где у команды «кнопки» и почему люди выгорают?
Автор выделяет пять устойчивых моделей реакции людей на неопределённость, от «око за око» до рационалистского поиска правил, - и показывает, как каждая ведёт к напряжению и усталости. Один и тот же управленческий приём вызывает разную реакцию в зависимости от паттерна. А значит, надо подбирать подачу: кому-то нужны чёткие границы, кому-то — поддержка, кому-то — логика и правила.
Как за один слайд увидеть, кого в команду нанимать, кого учить, а что перестать делать
Что-то вроде простой «карты выбора» на один слайд: ценность задачи для цели × способность команды выполнить её сейчас. В одном поле карты нанимаем, в другом - учим своих, в третьем - отказываемся или откладываем. Инструмент снимает «хотелки» и возвращает обсуждение найма к пользе и возможности. Результат - меньше распыления и понятная стратегия роста компетенций.
Общение с социопатом: руководство по выживанию
Прагматичный взгляд на работу с соципатами) Кратко - надо фиксировать договорённости письменно, избегать личных тем, не втягиваться в «игры», эскалировать по правилам. На собраниях - только факты и решения, в переписке - проверяемые пункты и сроки.
Как одновременно заонбордить три новые команды
Реальный опыт одновременной адаптации трёх команд. Что помогло - так это единая программа, наставники, база знаний и календарь первых недель. И если вы сделали общие правила постановки задач и одинаковые критерии «готово», то и кривотолков и недопониманий будет меньше. В качестве метрик смотрим на скорость выхода на самостоятельные задачи и долю блокеров на каждом шаге.