🔥 Самые интересные материалы по управлению проектами за 2 недели
Основы, гайды, кейсы (ч.2)
🐱 Как фанфик по Гарри Поттеру стал лучшей книгой по рациональному мышлению для программистов
Да, вот так вот - материал про легендарный фанфик про ГП (а какие фанфики читаете вы, мы знаем). Коротко - про полезные приемы типа: обновления гипотез по мере появления данных, борьбы с искажениями мышления, силы экспериментов. Отдельно подчёркивается важность различать совпадение и причинно-следственную связь при разборе инцидентов. В целом - учимся сами и учим команду сомневаться в первых объяснениях, проверять альтернативы и фиксировать, что именно привело к улучшению (или ухудшению).
🐱 Jira для управления тестовыми проектами: советы по организации работы и документированию
Пошаговый разбор того, как настроить систему задач под нужды QA: фильтры и язык запросов для быстрых выборок, массовые операции для изменений «пачкой», публикация выборок на панелях.Много примеров и советов.
🐈 Парадокс Джевонса и «эффект Черномырдина» ИТ проектов: как оптимизация приводит к катастрофе
О том, как улучшение отдельного узла системы может усилить нагрузку на весь поток и обернуться падением качества. Парадокс Джевонса - это когда повышение эффективности увеличивает потребление ресурса. В проектах это проявляется как «успели больше — на нас свалили ещё». (ну и что-то напоминающее «хотели как лучше, а получилось как всегда»).
🐱 Разработка и управление требованиями
Систематизация работы с требованиями: от постановки цели и границ до формулировок, сценариев и критериев приёмки. Отдельный акцент - на свойства «качественного требования»: однозначность, проверяемость, осуществимость, связность с другими, на ведение единой структуры артефактов, прослеживаемость от задачи до результата и порядок изменения требований с оценкой влияния.
🐱 Почему ваше проектное управление никогда не будет работать
Автор разбирает типичные иллюзии: попытку заменить ясные цели количеством совещаний, надежду «урегулировать» неопределённость регламентами и веру в «срок из воздуха». Корни сбоев — отсутствие понятного результата для пользователя, несогласованные приоритеты и слабая ответственность за решение. Что делать? Вести единый список работ, делать открытые критерии «готово», ограничить параллельность и регулярно проверять пользу.
😺 Маленькое эссе о техдолге
Эссе напоминает: технический долг — это сознательное заимствование времени (“по-быренькому” залатаем), за которое мы потом платим ростом сложности и рисков. И опасность не в самом долге, а в том, что о нём забывают и не закладывают погашение. Что предлагает автор - вести явный реестр долгов, оценивать «процентов» (во что выливаются задержки и ошибки) и плановую долю времени на возврат.
🐱 Kaiten после 7 лет в Jira: рассказываю про свой опыт
Автор сравнивает многолетнюю работу в крупной системе учёта задач с переходом на более лёгкий инструмент. Главная идея - избыточная сложность настроек, полей и схем статусов со временем начинает жить собственной жизнью и мешать работе. Соответственно, переход дал упрощение и повысил скорость работы. Адептам джиры не читать)
Основы, гайды, кейсы (ч.2)
Да, вот так вот - материал про легендарный фанфик про ГП (а какие фанфики читаете вы, мы знаем). Коротко - про полезные приемы типа: обновления гипотез по мере появления данных, борьбы с искажениями мышления, силы экспериментов. Отдельно подчёркивается важность различать совпадение и причинно-следственную связь при разборе инцидентов. В целом - учимся сами и учим команду сомневаться в первых объяснениях, проверять альтернативы и фиксировать, что именно привело к улучшению (или ухудшению).
Пошаговый разбор того, как настроить систему задач под нужды QA: фильтры и язык запросов для быстрых выборок, массовые операции для изменений «пачкой», публикация выборок на панелях.Много примеров и советов.
О том, как улучшение отдельного узла системы может усилить нагрузку на весь поток и обернуться падением качества. Парадокс Джевонса - это когда повышение эффективности увеличивает потребление ресурса. В проектах это проявляется как «успели больше — на нас свалили ещё». (ну и что-то напоминающее «хотели как лучше, а получилось как всегда»).
Систематизация работы с требованиями: от постановки цели и границ до формулировок, сценариев и критериев приёмки. Отдельный акцент - на свойства «качественного требования»: однозначность, проверяемость, осуществимость, связность с другими, на ведение единой структуры артефактов, прослеживаемость от задачи до результата и порядок изменения требований с оценкой влияния.
Автор разбирает типичные иллюзии: попытку заменить ясные цели количеством совещаний, надежду «урегулировать» неопределённость регламентами и веру в «срок из воздуха». Корни сбоев — отсутствие понятного результата для пользователя, несогласованные приоритеты и слабая ответственность за решение. Что делать? Вести единый список работ, делать открытые критерии «готово», ограничить параллельность и регулярно проверять пользу.
Эссе напоминает: технический долг — это сознательное заимствование времени (“по-быренькому” залатаем), за которое мы потом платим ростом сложности и рисков. И опасность не в самом долге, а в том, что о нём забывают и не закладывают погашение. Что предлагает автор - вести явный реестр долгов, оценивать «процентов» (во что выливаются задержки и ошибки) и плановую долю времени на возврат.
Автор сравнивает многолетнюю работу в крупной системе учёта задач с переходом на более лёгкий инструмент. Главная идея - избыточная сложность настроек, полей и схем статусов со временем начинает жить собственной жизнью и мешать работе. Соответственно, переход дал упрощение и повысил скорость работы. Адептам джиры не читать)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2❤1👍1💘1 1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😸 #Менеджер проекта - карьера и навыки (ч.1)
😹 Почему люди слышат не то, что вы говорите?
Простая, но важная статья - автор через личные кейсы показывает, как один и тот же разговор по-разному воспринимают люди с разным опытом и настроем. Даже такие вещи, как непривычная пунктуация, отсутствие смайликов, перекос в акцентах или «оценка результативности» без контекста порождают стресс и ошибочные выводы. Что делать? Проверять понимание («как ты это понял?»), подбирать подачу под адресата и не заменять смысл риторикой. Эмпатия и регулярные встречи один на один снижают шум в коммуникации и предотвращают накопление обид.
😼 Начальник контролировал всё: ввел отчеты по часам, просил скрин экрана и считал походы в туалет
Ух, мощная статья - сама по себе и по собранным комментариям. На примерах разбираются бессмысленные форматы отчётности: «таблицы по часам», всеобщие видеосовещания-пересказы, «видеодневники» и внезапные требования «срочно отчитаться». Ну и рецепты “как правильно” - вместо тотального контроля прозрачность по данным: сводки задач в трекере, короткие рабочие созвоны, редкие показы результатов и отчёты, собранные автоматически. Отчётность «ради формы» подменяет работу, усиливает ошибки и ведёт к выгоранию.
🙀 Почему управлять людьми сложнее, чем писать код
Код предсказуем, а люди — нет: у сотрудников есть эмоции, личные обстоятельства и разные трактовки «готово». Автор подчёркивает важность бережной обратной связи, личных встреч и проговаривания очевидных вещей — иначе «сделано» для разных ролей значит разное. Конфликты и выгорание замечают раньше, если есть доверие и регулярный контакт, а критику подают лично и конкретно. Короче, надо менять фокус с инструментов на культуру и состояние команды.
😿 «Генералы», «Цезари» и «Псевдоэксперты»: как договориться со сложным заказчиком
Что-то вроде практической типологии трудных клиентов: «вечно недовольный», «генерал», «цезарь», «истерик» и «скрытая угроза» — с признаками и рабочими тактиками. Советы варьируются от переговоров «через равных по статусу» и апелляции к нормам — до «двойной фиксации» договорённостей и аккуратного перевода решения в «его идею».
😾 Про IT в 2025 году
Нужная статья, хоть и не про менеджмент. Автор трезво описывает перекосы рынка, в котором мы с вами работаем: избыток новичков, слабое качество при завышенных ожиданиях и ужесточение отбора компаниями. Прогноз — больше очных собеседований, тщательная проверка резюме (привет, волки и чатгпт) и возврат к внутреннему росту из поддержки и начальных ролей. Параллельно усиливается кризис среднего возраста у опытных специалистов и эйджизм, но бизнесу всё равно придётся «вспомнить ценность экспертизы».
😺 Про роль тимлида, а также несколько простых и полезных советов
Статья в каком-то смысле приземляет роль тимлида: это не «суперразработчик» и не «психотерапевт на полставки», а человек, который ведёт команду к результату. Его задача - понятные договорённости, распределение ответственности, регулярная обратная связь и защита времени на разработку. Не надо героизма, в общем)
😻 Памятка менеджеру: Запрещённые фразы в IT. Часть 2
Автор разбирает ещё две «токсичные» фразы, которые портят отношения с заказчиком и командой и демонстрируют беспомощность и нежелание управлять. Вместо них предлагается использовать более уместный язык: уточнение контекста, предложение вариантов и договорённость о следующем шаге. И вообще, в статье много приземлённых формулировок, которые помогают выходить из тупиков на встречах.
Простая, но важная статья - автор через личные кейсы показывает, как один и тот же разговор по-разному воспринимают люди с разным опытом и настроем. Даже такие вещи, как непривычная пунктуация, отсутствие смайликов, перекос в акцентах или «оценка результативности» без контекста порождают стресс и ошибочные выводы. Что делать? Проверять понимание («как ты это понял?»), подбирать подачу под адресата и не заменять смысл риторикой. Эмпатия и регулярные встречи один на один снижают шум в коммуникации и предотвращают накопление обид.
Ух, мощная статья - сама по себе и по собранным комментариям. На примерах разбираются бессмысленные форматы отчётности: «таблицы по часам», всеобщие видеосовещания-пересказы, «видеодневники» и внезапные требования «срочно отчитаться». Ну и рецепты “как правильно” - вместо тотального контроля прозрачность по данным: сводки задач в трекере, короткие рабочие созвоны, редкие показы результатов и отчёты, собранные автоматически. Отчётность «ради формы» подменяет работу, усиливает ошибки и ведёт к выгоранию.
Код предсказуем, а люди — нет: у сотрудников есть эмоции, личные обстоятельства и разные трактовки «готово». Автор подчёркивает важность бережной обратной связи, личных встреч и проговаривания очевидных вещей — иначе «сделано» для разных ролей значит разное. Конфликты и выгорание замечают раньше, если есть доверие и регулярный контакт, а критику подают лично и конкретно. Короче, надо менять фокус с инструментов на культуру и состояние команды.
Что-то вроде практической типологии трудных клиентов: «вечно недовольный», «генерал», «цезарь», «истерик» и «скрытая угроза» — с признаками и рабочими тактиками. Советы варьируются от переговоров «через равных по статусу» и апелляции к нормам — до «двойной фиксации» договорённостей и аккуратного перевода решения в «его идею».
Нужная статья, хоть и не про менеджмент. Автор трезво описывает перекосы рынка, в котором мы с вами работаем: избыток новичков, слабое качество при завышенных ожиданиях и ужесточение отбора компаниями. Прогноз — больше очных собеседований, тщательная проверка резюме (привет, волки и чатгпт) и возврат к внутреннему росту из поддержки и начальных ролей. Параллельно усиливается кризис среднего возраста у опытных специалистов и эйджизм, но бизнесу всё равно придётся «вспомнить ценность экспертизы».
Статья в каком-то смысле приземляет роль тимлида: это не «суперразработчик» и не «психотерапевт на полставки», а человек, который ведёт команду к результату. Его задача - понятные договорённости, распределение ответственности, регулярная обратная связь и защита времени на разработку. Не надо героизма, в общем)
Автор разбирает ещё две «токсичные» фразы, которые портят отношения с заказчиком и командой и демонстрируют беспомощность и нежелание управлять. Вместо них предлагается использовать более уместный язык: уточнение контекста, предложение вариантов и договорённость о следующем шаге. И вообще, в статье много приземлённых формулировок, которые помогают выходить из тупиков на встречах.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2 2❤1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😃 #Команда проекта
🇨🇦 Как правильно вести учёт рабочего времени
Коллеги из weeek объясняют, что учёт времени - не про слежку,большого брата и просмотр камер, а про планирование и выравнивание нагрузки. Отсюда и роли ответственных (кадровая служба, администраторы систем, руководители направлений и руководители проектов), основные форматы учёта (по дням, по задачам и др.) и как выбирать их под тип работ. Есть критерии выбора инструмента: простота фиксации, отчёты по людям и задачам, связка с задачником и календарями.
🙄 Онбординг в графиках: как превратить адаптацию в измеримый и предсказуемый процесс
Материал предлагает рассматривать адаптацию новичков как понятный процесс с метриками (к примеру, время до продуктивности, доля самостоятельных задач, скорость прохождения обучения). Это помогает увидеть узкие места: где теряются дни, где не хватает наставника или учебных материалов. Эх, мечты...
🫧 Сотрудник «буддист»: анализ уязвимостей и краткий мануал для руководителя
Буддист - это тип сотрудника, который внешне спокоен и не вступает в конфликты, но легко уходит в пассивное сопротивление. Главные риски с таким товарищем - размытые договорённости, отсутствие явных сроков и надежда на «само как-нибудь сложится». А способ работы с ним - это максимальная точность целей, результатов, критериев и т.д.
🤕 Как создать самообучающуюся команду: рабочие инструменты, способы мотивации и чек-лист
Статья собирает практику постоянного обучения прямо в потоке работы. Тут и короткие разборы ошибок, и обмен знаниями, и наставничество, и «малые эксперименты». Важно создать цикл «заметили -попробовали - измерили - внедрили», только так обучение даёт результат, а не копит презентации.
😩 Пять паттернов поведения: где у команды «кнопки» и почему люди выгорают?
Автор выделяет пять устойчивых моделей реакции людей на неопределённость, от «око за око» до рационалистского поиска правил, - и показывает, как каждая ведёт к напряжению и усталости. Один и тот же управленческий приём вызывает разную реакцию в зависимости от паттерна. А значит, надо подбирать подачу: кому-то нужны чёткие границы, кому-то — поддержка, кому-то — логика и правила.
😠 Как за один слайд увидеть, кого в команду нанимать, кого учить, а что перестать делать
Что-то вроде простой «карты выбора» на один слайд: ценность задачи для цели × способность команды выполнить её сейчас. В одном поле карты нанимаем, в другом - учим своих, в третьем - отказываемся или откладываем. Инструмент снимает «хотелки» и возвращает обсуждение найма к пользе и возможности. Результат - меньше распыления и понятная стратегия роста компетенций.
😒 Общение с социопатом: руководство по выживанию
Прагматичный взгляд на работу с социопатами (узнали? согласны?) Кратко - надо фиксировать договорённости письменно, избегать личных тем, не втягиваться в «игры», эскалировать по правилам. На собраниях - только факты и решения, в переписке - проверяемые пункты и сроки.
🤟 Как одновременно заонбордить три новые команды
Реальный опыт одновременной адаптации трёх команд. Что помогло - так это единая программа, наставники, база знаний и календарь первых недель. И если вы сделали общие правила постановки задач и одинаковые критерии «готово», то и кривотолков и недопониманий будет меньше. В качестве метрик смотрим на скорость выхода на самостоятельные задачи и долю блокеров на каждом шаге.
✅ И напомню, что все дайджесты, с тегами, рубриками, ссылками и даже pdf - тут.
Коллеги из weeek объясняют, что учёт времени - не про слежку,
Материал предлагает рассматривать адаптацию новичков как понятный процесс с метриками (к примеру, время до продуктивности, доля самостоятельных задач, скорость прохождения обучения). Это помогает увидеть узкие места: где теряются дни, где не хватает наставника или учебных материалов. Эх, мечты...
Буддист - это тип сотрудника, который внешне спокоен и не вступает в конфликты, но легко уходит в пассивное сопротивление. Главные риски с таким товарищем - размытые договорённости, отсутствие явных сроков и надежда на «само как-нибудь сложится». А способ работы с ним - это максимальная точность целей, результатов, критериев и т.д.
Статья собирает практику постоянного обучения прямо в потоке работы. Тут и короткие разборы ошибок, и обмен знаниями, и наставничество, и «малые эксперименты». Важно создать цикл «заметили -попробовали - измерили - внедрили», только так обучение даёт результат, а не копит презентации.
Автор выделяет пять устойчивых моделей реакции людей на неопределённость, от «око за око» до рационалистского поиска правил, - и показывает, как каждая ведёт к напряжению и усталости. Один и тот же управленческий приём вызывает разную реакцию в зависимости от паттерна. А значит, надо подбирать подачу: кому-то нужны чёткие границы, кому-то — поддержка, кому-то — логика и правила.
Что-то вроде простой «карты выбора» на один слайд: ценность задачи для цели × способность команды выполнить её сейчас. В одном поле карты нанимаем, в другом - учим своих, в третьем - отказываемся или откладываем. Инструмент снимает «хотелки» и возвращает обсуждение найма к пользе и возможности. Результат - меньше распыления и понятная стратегия роста компетенций.
Прагматичный взгляд на работу с социопатами (узнали? согласны?) Кратко - надо фиксировать договорённости письменно, избегать личных тем, не втягиваться в «игры», эскалировать по правилам. На собраниях - только факты и решения, в переписке - проверяемые пункты и сроки.
Реальный опыт одновременной адаптации трёх команд. Что помогло - так это единая программа, наставники, база знаний и календарь первых недель. И если вы сделали общие правила постановки задач и одинаковые критерии «готово», то и кривотолков и недопониманий будет меньше. В качестве метрик смотрим на скорость выхода на самостоятельные задачи и долю блокеров на каждом шаге.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2 2❤1👍1💘1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
👀 Команда проекта
😱 Смирись: ты ненормальный
Один из залайканных текстов - ну и обоснованно) Он про “распаковку” мечтаний и о том, что прежде чем менять карьеру, надо честно разложить, из каких будней состоит желаемая роль, задавать приземленные вопросы о реальной работе, а не любоваться картинкой будущего. И да, успешные специалисты готовы годами повторять одно и то же, и это нормально для тех, кому эта рутина по вкусу. Не бойтесь однообразия и духоты/занудства, если тема и деятельность вам по кайфу (ведь по кайфу, да?).
😃 От раздражителя к гению: работает ли знаменитый подход Патрика Ленсиони в IT?
Авторы потестили модель “шести гениев” Ленсиони, разложив работу на этапы (задумка, изобретение, оценка, гальванизация, поддержка, доводка), отметили у себя зоны “гения”, “навыка” и “раздражителя”, а затем обсудили, как это проявляется в повседневных процессах внутри команды. А проявляется в виде общего словаря для быстрой коммуникации более осознанный найм и ротацию внутри команды (типа надо,чтобы сотрудник как раз был в зоне “гения”).
🤝 Дисциплина и желание учиться: по каким критериям проджекту в финтехе оценивать разработчиков-джунов
Как проектный руководитель растит новичков вместе с наставником и куратором - он следит за дисциплиной, темпом в спринтах, готовностью задавать вопросы и ориентацией на результат. Первые недели - в основном внутренние задачи; а к реальным бизнес-функциям джуна допускают уже после адаптации и осознанных предложений. И зрелость чекают не по “идеальному коду”, а по умению выбирать разумные упрощения ради проверки гипотез и соблюдения сроков.
🍕 Симулятор команды — вместо десятка ретроспектив
В Dodo придумали простую игру. Суть - участники команды временно меняются ролями и на практике отыгрывают работу коллег, решая реальные кейсы в ускоренном игровом формате.Игра длится несколько условных рабочих дней, каждый день состоит из короткого митинга и двухминутной “работы”. Участники тянут задачи из бэклога, распределяют их и придумывают, как бы выполнили их в роли коллеги. После нескольких итераций команда подводит итоги и делится инсайтами. Главная цель - прочувствовать “эффект кресла”, то есть увидеть трудности, ожидания и перегрузку других ролей изнутри, - и как результат лучше сработаться.
📖 Две книги о проблемах ИТ-команд
Автор рассказывает о двух своих книгах для менеджмента. Первая - про сотрудников, которые тянут команду вниз: от “души компании” и “критика-иллюзиониста” до перфекциониста, срывающего сроки в погоне за идеалом. Даются приёмы работы с каждым типом. Вторая - про типовые конфликты: от “спора о кондиционере” и ревью кода до соперничества и несогласованных полномочий. Лейтмотив обеих книг - успех проекта зависит не только от техники управления проектом, но и от поведения участников, их ожиданий и культуры общения.
🔄 Я не работал и просто двигал тикеты, и меня повысили
Провокационный опыт: как в некоторых коллективах поощряется видимость занятости - дробление задач, созвоны для передышки, запас по срокам, имитация вовлеченности. И соответственно, как руководителю ловить такие практики без тотального контроля, отслеживая движение важных задач, динамику обсуждений, время на этапах и соблюдение сроков.
😐 Как создать сплочённый коллектив без скучных тимбилдингов
Материал даёт понятное определение сплоченной команды и ее признаки: доверие, взаимовыручка, общие цели, вовлеченность и совместное переживание успехов. Есть даже “тест на необходимость сплочения”, в который включены симптомы вроде редких инициатив, текучести и усталости в коллективе. Дальше - набор рабочих идей: больше прозрачности, регулярные неформальные обсуждения, ритуалы поддержки, системная обратная связь и разумное распределение ответственности. Надеемся, что в вашей команде всё именно так😛
Один из залайканных текстов - ну и обоснованно) Он про “распаковку” мечтаний и о том, что прежде чем менять карьеру, надо честно разложить, из каких будней состоит желаемая роль, задавать приземленные вопросы о реальной работе, а не любоваться картинкой будущего. И да, успешные специалисты готовы годами повторять одно и то же, и это нормально для тех, кому эта рутина по вкусу. Не бойтесь однообразия и духоты/занудства, если тема и деятельность вам по кайфу (ведь по кайфу, да?).
Авторы потестили модель “шести гениев” Ленсиони, разложив работу на этапы (задумка, изобретение, оценка, гальванизация, поддержка, доводка), отметили у себя зоны “гения”, “навыка” и “раздражителя”, а затем обсудили, как это проявляется в повседневных процессах внутри команды. А проявляется в виде общего словаря для быстрой коммуникации более осознанный найм и ротацию внутри команды (типа надо,чтобы сотрудник как раз был в зоне “гения”).
Как проектный руководитель растит новичков вместе с наставником и куратором - он следит за дисциплиной, темпом в спринтах, готовностью задавать вопросы и ориентацией на результат. Первые недели - в основном внутренние задачи; а к реальным бизнес-функциям джуна допускают уже после адаптации и осознанных предложений. И зрелость чекают не по “идеальному коду”, а по умению выбирать разумные упрощения ради проверки гипотез и соблюдения сроков.
В Dodo придумали простую игру. Суть - участники команды временно меняются ролями и на практике отыгрывают работу коллег, решая реальные кейсы в ускоренном игровом формате.Игра длится несколько условных рабочих дней, каждый день состоит из короткого митинга и двухминутной “работы”. Участники тянут задачи из бэклога, распределяют их и придумывают, как бы выполнили их в роли коллеги. После нескольких итераций команда подводит итоги и делится инсайтами. Главная цель - прочувствовать “эффект кресла”, то есть увидеть трудности, ожидания и перегрузку других ролей изнутри, - и как результат лучше сработаться.
Автор рассказывает о двух своих книгах для менеджмента. Первая - про сотрудников, которые тянут команду вниз: от “души компании” и “критика-иллюзиониста” до перфекциониста, срывающего сроки в погоне за идеалом. Даются приёмы работы с каждым типом. Вторая - про типовые конфликты: от “спора о кондиционере” и ревью кода до соперничества и несогласованных полномочий. Лейтмотив обеих книг - успех проекта зависит не только от техники управления проектом, но и от поведения участников, их ожиданий и культуры общения.
Провокационный опыт: как в некоторых коллективах поощряется видимость занятости - дробление задач, созвоны для передышки, запас по срокам, имитация вовлеченности. И соответственно, как руководителю ловить такие практики без тотального контроля, отслеживая движение важных задач, динамику обсуждений, время на этапах и соблюдение сроков.
Материал даёт понятное определение сплоченной команды и ее признаки: доверие, взаимовыручка, общие цели, вовлеченность и совместное переживание успехов. Есть даже “тест на необходимость сплочения”, в который включены симптомы вроде редких инициатив, текучести и усталости в коллективе. Дальше - набор рабочих идей: больше прозрачности, регулярные неформальные обсуждения, ритуалы поддержки, системная обратная связь и разумное распределение ответственности. Надеемся, что в вашей команде всё именно так
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3 2👍1🔥1💘1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🙂 Менеджер проекта - карьера и навыки
😱 Разделяй и властвуй: как не погрязнуть в режиме многозадачности
Автор показывает, что “многозадачность” чаще иллюзия, чем реальный навык: мозг просто мечется между делами, падает качество и растет усталость. Выход - сознательно возвращаться к однозадачности: упорядочивать реестр дел, расставлять приоритеты и защищать отрезки сосредоточенной работы. Из приемов - матрица Эйзенхауэра и метод помодоро, плюс гигиена внимания и короткие восстановления. Ну и ежедневно подводить итоги и корректировать рутину под себя.
🔫 Поворот туда: 8 историй о том, как бывшие юристы, врачи и логисты стали менеджерами проектов
Не знаю, откуда вы (не) пришли к роли РП, но вот подборка жизненных кул-стори о смене профессии, которые пригодятся тем, кто хочет свичнуться в управление проектами. Общие мотивы героев — опора на прошлый опыт, обучение, поддержка окружения и честная переоценка ожиданий по доходу (да, часть потеряла в деньгах, но типа довольна и считает, что всё впереди).
🙂 Фазовый переход: как из инженера стать руководителем команды
О смене роли с исполнителя на руководителя: от “сам всё сделаю” к делегированию, ответственности за людей и результат. Авторы делают акцент на первые шаги: выравнивание ожиданий с руководством, договоренности с командой, общие правила готовности тасок и прозрачные цели. Из ловушек выделены микроконтроль, страх конфликтов и т.п., а из рекомендаций - регулярные личные встречи, защита времени разработчиков и ясная обратная связь.
😵 Книга Хватит выгорать! Инструкция для руководителей: ключевые тезисы и ссылки
Обзор книги для руководителей о том, как распознавать ранние признаки истощения и перестраивать рабочую среду до кризиса. В центре внимания - ритм нагрузки, понятные приоритеты, оговоренные границы и поддержка восстановления. Из практики: договоренности о времени без созвонов, трезвая постановка целей, корректировка объема. Короче, заставляем сотрудников отдыхать и игнорить нас на выходных и по ночам…
😴 Настройка процесса поддержки в Yandex Tracker
Как пошагово выстроить линию поддержки: очереди, категории обращений, статусы, правила эскалации и сроки реакции, шаблоны карточек, автоматические действия, уведомления и сводные панели для контроля загрузки и прочее нужное для сервис-деска.
📱 Великие усложняторы: кризис управления верхнего уровня
Автор описывает ситуацию, когда наверху (ну или вы сами) любят усложнять ради усложнения - бесконечные отчеты, комитеты, инициативы без эффекта перегружают людей и гасят ответственность. Цель подменяется ритуалами, модными практиками и постоянными “перестройками” без оценки пользы. Что делать: упрощать контур управления, обозначать ясные полномочия на уровне команд, ограничивать параллельные инициативы, держать открытую связь с пользователями.
📞 Project Manager/Product Manager/Program Manager: в чём разница и зачем это бизнесу?
Статья разводит три часто путаемые (наверное) роли. Менеджер проекта отвечает за сроки, бюджет, качество и риски, менеджер продукта - за востребованность и рост ценности, менеджер программ - за согласование множества инициатив под стратегические цели. Соотв., у них разные горизонты планирования, типовые метрики и круг общения каждой роли, от пользователей до руководителей компании.
🤗 Delivery Manager и Project Manager в реальных кейсах
А тут еще про две роли, которые часто рядом. И сравнивают их на четырех ситуациях: срыв релиза, перерасход бюджета, критический дефект в эксплуатации и внезапные изменения требований. ПМ фокусируется на перепланировании, контроле сроков и прозрачной коммуникации; а DM оценивает влияние на бизнес, качество релизов, устойчивость решения и часто подключает техническую экспертизу.
Автор показывает, что “многозадачность” чаще иллюзия, чем реальный навык: мозг просто мечется между делами, падает качество и растет усталость. Выход - сознательно возвращаться к однозадачности: упорядочивать реестр дел, расставлять приоритеты и защищать отрезки сосредоточенной работы. Из приемов - матрица Эйзенхауэра и метод помодоро, плюс гигиена внимания и короткие восстановления. Ну и ежедневно подводить итоги и корректировать рутину под себя.
Не знаю, откуда вы (не) пришли к роли РП, но вот подборка жизненных кул-стори о смене профессии, которые пригодятся тем, кто хочет свичнуться в управление проектами. Общие мотивы героев — опора на прошлый опыт, обучение, поддержка окружения и честная переоценка ожиданий по доходу (да, часть потеряла в деньгах, но типа довольна и считает, что всё впереди).
О смене роли с исполнителя на руководителя: от “сам всё сделаю” к делегированию, ответственности за людей и результат. Авторы делают акцент на первые шаги: выравнивание ожиданий с руководством, договоренности с командой, общие правила готовности тасок и прозрачные цели. Из ловушек выделены микроконтроль, страх конфликтов и т.п., а из рекомендаций - регулярные личные встречи, защита времени разработчиков и ясная обратная связь.
Обзор книги для руководителей о том, как распознавать ранние признаки истощения и перестраивать рабочую среду до кризиса. В центре внимания - ритм нагрузки, понятные приоритеты, оговоренные границы и поддержка восстановления. Из практики: договоренности о времени без созвонов, трезвая постановка целей, корректировка объема. Короче, заставляем сотрудников отдыхать и игнорить нас на выходных и по ночам…
Как пошагово выстроить линию поддержки: очереди, категории обращений, статусы, правила эскалации и сроки реакции, шаблоны карточек, автоматические действия, уведомления и сводные панели для контроля загрузки и прочее нужное для сервис-деска.
Автор описывает ситуацию, когда наверху (ну или вы сами) любят усложнять ради усложнения - бесконечные отчеты, комитеты, инициативы без эффекта перегружают людей и гасят ответственность. Цель подменяется ритуалами, модными практиками и постоянными “перестройками” без оценки пользы. Что делать: упрощать контур управления, обозначать ясные полномочия на уровне команд, ограничивать параллельные инициативы, держать открытую связь с пользователями.
Статья разводит три часто путаемые (наверное) роли. Менеджер проекта отвечает за сроки, бюджет, качество и риски, менеджер продукта - за востребованность и рост ценности, менеджер программ - за согласование множества инициатив под стратегические цели. Соотв., у них разные горизонты планирования, типовые метрики и круг общения каждой роли, от пользователей до руководителей компании.
А тут еще про две роли, которые часто рядом. И сравнивают их на четырех ситуациях: срыв релиза, перерасход бюджета, критический дефект в эксплуатации и внезапные изменения требований. ПМ фокусируется на перепланировании, контроле сроков и прозрачной коммуникации; а DM оценивает влияние на бизнес, качество релизов, устойчивость решения и часто подключает техническую экспертизу.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3❤2👏2 2💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🕺 Команда проекта
👨💻 Управление кросс‑функциональной командой
Кросс-функциональные команды состоят из экспертов непохожих специальностей — каждый из своей команды. Профессионалов временно перебрасывают на определённый вид работы: отдельный проект, спринт или комплексную задачу. Гайд рассказывает, как управлять временно созданной командой на временно возникающие задачи. Примером выступит объединение команд для клиентского проекта внутри агентства
😎 От интроверта до CTO: как прокачать коммуникации и построить систему обучения в команде
CTO крупной компании про свой путь от "немого интроверта" до руководителя, для которого коммуникации - главный инструмент. Как учился у продажников разговаривать с людьми, почему архитектура - это еще больше про общение, чем про технологии, и как пандемия заставила перестроить командные связи. Про обучение - простое правило "учишься нужному бизнесу - оплачиваем полностью; перспективному - 50/50; для себя - поддержим морально", плюс обязательное "выучил - расскажи команде".
😠 6 принципов эффективной коммуникации с коллегами (или нет?)
Любимый жанр - сатирический список "правил", которые на деле разрушают работу: не здоровайтесь, пишите приказным тоном, не давайте вводных, шлите голосовые "на полчаса", ставьте нереальные сроки и пишите в чаты по ночам (узнали себя??). Понятно, что цель как раз показать показать обратное, но читатель легко узнает офисные боли. Мораль: уважение к времени и психике коллег - основа продуктивности.
😳 Командная работа без выгорания: как вести IT-команду
Разбор тихого выгорания, которое не в форме скандала, а в режиме постепенной потери энергии и смысла, которую руководители замечают, когда человек уже "умственно уволился". Основные причины - перегруз и микроменеджмент, фокус на ошибках и неадекватное распределение задач между уровнями (джунам - туман, сеньорам - рутина). Из рецептов: автономия вместо удушающего контроля, регулярная обратная связь, ясная "карта роста" и работа со смыслами.
💩 Возвращаем команде ответственность на все деньги
Три практики, которые вернули команде вовлеченность и предсказуемость. (1) Сроки оценивает сама команда: тогда исчезают "чужие ожидания" и появляется личная ответственность за план.(да, звучит наивно). (2) Команда сама презентует результаты на ревью - это повышает сопричастность и качество обсуждения. (3) Выращивание "мини-директоров" по зонам (тестирование, аналитика, дизайн, фронт, бэк) позволяет делегировать решения.
😰 Почему тревожники - лучшие сотрудники?
Бу! Затревожились? Я вот да, и теперь радуюсь. Оказывается, люди с повышенной тревожностью более тщательно проверяют детали, соблюдают сроки, заранее просчитывают риски и часто сильны в эмпатии. Но и (и)риски тоже есть: критика воспринимается как угроза, токсичная среда бьет особенно сильно, поэтому таких тревожников лид должен защищать, хвалить за прогресс и давать безопасную обратную связь.
⛔️ От хаоса к системе: как построить эффективный онбординг в ИТ-команде
Как вслед за бурным ростом команды пришло понимание: без единой схемы онбординга новички тонут в вопросах "кто за что отвечает?" и "где что лежит". В итоге пришло решение прописать структуру команды и зон ответственности, собрать базу знаний со скриншотами, назначить ментора и ввести регулярные 1-на-1 по расписанию. Отдельный блок - доступы: пошаговый гайд сократил этап с трех дней запросов до одного рабочего дня; ну а дальше - погружение через простые задачи и матрица компетенций как маршрут развития. Да, и главной метрикой успеха стала самостоятельность: по набору критериев онбординг может закончиться раньше/позже испытательного срока.
Кросс-функциональные команды состоят из экспертов непохожих специальностей — каждый из своей команды. Профессионалов временно перебрасывают на определённый вид работы: отдельный проект, спринт или комплексную задачу. Гайд рассказывает, как управлять временно созданной командой на временно возникающие задачи. Примером выступит объединение команд для клиентского проекта внутри агентства
CTO крупной компании про свой путь от "немого интроверта" до руководителя, для которого коммуникации - главный инструмент. Как учился у продажников разговаривать с людьми, почему архитектура - это еще больше про общение, чем про технологии, и как пандемия заставила перестроить командные связи. Про обучение - простое правило "учишься нужному бизнесу - оплачиваем полностью; перспективному - 50/50; для себя - поддержим морально", плюс обязательное "выучил - расскажи команде".
Любимый жанр - сатирический список "правил", которые на деле разрушают работу: не здоровайтесь, пишите приказным тоном, не давайте вводных, шлите голосовые "на полчаса", ставьте нереальные сроки и пишите в чаты по ночам (узнали себя??). Понятно, что цель как раз показать показать обратное, но читатель легко узнает офисные боли. Мораль: уважение к времени и психике коллег - основа продуктивности.
Разбор тихого выгорания, которое не в форме скандала, а в режиме постепенной потери энергии и смысла, которую руководители замечают, когда человек уже "умственно уволился". Основные причины - перегруз и микроменеджмент, фокус на ошибках и неадекватное распределение задач между уровнями (джунам - туман, сеньорам - рутина). Из рецептов: автономия вместо удушающего контроля, регулярная обратная связь, ясная "карта роста" и работа со смыслами.
Три практики, которые вернули команде вовлеченность и предсказуемость. (1) Сроки оценивает сама команда: тогда исчезают "чужие ожидания" и появляется личная ответственность за план.(да, звучит наивно). (2) Команда сама презентует результаты на ревью - это повышает сопричастность и качество обсуждения. (3) Выращивание "мини-директоров" по зонам (тестирование, аналитика, дизайн, фронт, бэк) позволяет делегировать решения.
Бу! Затревожились? Я вот да, и теперь радуюсь. Оказывается, люди с повышенной тревожностью более тщательно проверяют детали, соблюдают сроки, заранее просчитывают риски и часто сильны в эмпатии. Но и (и)риски тоже есть: критика воспринимается как угроза, токсичная среда бьет особенно сильно, поэтому таких тревожников лид должен защищать, хвалить за прогресс и давать безопасную обратную связь.
Как вслед за бурным ростом команды пришло понимание: без единой схемы онбординга новички тонут в вопросах "кто за что отвечает?" и "где что лежит". В итоге пришло решение прописать структуру команды и зон ответственности, собрать базу знаний со скриншотами, назначить ментора и ввести регулярные 1-на-1 по расписанию. Отдельный блок - доступы: пошаговый гайд сократил этап с трех дней запросов до одного рабочего дня; ну а дальше - погружение через простые задачи и матрица компетенций как маршрут развития. Да, и главной метрикой успеха стала самостоятельность: по набору критериев онбординг может закончиться раньше/позже испытательного срока.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3🔥3 2💘1 1
“Управление проектами для заинтересованных сторон (стейкхолдеров)” (В.Воропаев, Я.Гельруд, О.Клименко)
Ассоциация “Проектный Альянс” выпустила книгу, посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.
Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.
👍 Плюсы:
✅ Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.
✅ Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.
✅ Комплексность. Не одна мат.модель, а набор, от детерминированных до вероятностных, с разбором их ограничений для сложных проектов. В итоге получается обобщенная сетевая модель.
✅ Несколько точек зрения, соответствующих разным стейкхолдерам: инвестора, заказчика, поставщика, регулирующих органов, коммерческой службы и, конечно, команды проекта. Каждому — свои цели, функции, компетенции и метрики. И еще отдельная карта связей.
✅ Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.
✅ Есть практическая оптика для разных ролей: таблицы с ожиданиями, целями, ограничениями и инструментами по каждой стороне призваны помочь быстро собрать «карту интересов» под конкретный портфель/программу. Причем тут без формул 👍
😑 Особенности
🔹 Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.
🔹 Математический аппарат - это и достоинство, и порог входа. Но, с другой стороны, есть понятные гуманитариям выводы, и если они ок, то дальше можно погружаться и в расчеты с шарящими коллегами.
🔹 Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам, финансам и решениям стейкхолдеров. Если вы привыкли «от Jira к стратегии», придётся развернуть взгляд.
❗️ Резюме.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.
Ассоциация “Проектный Альянс” выпустила книгу, посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.
Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍4🔥4 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🔄 Основы, гайды, инструменты (часть 1)
🍔 Почему Agile больше не спасает проекты в России?
Автор эпатирует, и Agile в РФ не умер - он "приземлился" в гибриды под реальность импортозамещения, ограничений и давления сроков. Ритуалы и "чистые" фреймворки в крупных компаниях уступают месту упрощенным процессам с упором на DevOps и автоматизацию (спасибо ИИ и бьютификации). Малые команды сохраняют гибкость, но тоже меньше гоняются за формой и больше - за результатом. И самое главное - это нормально)
🔄 Wardley Map: прекратить переизобретать и сфокусироваться на ценности продукта
А это такой инструмент. Карты Уордли помогают увидеть, что покупается "как товар", а что требует собственных инвестиций, и сопоставить это с ценностью для пользователя. Картирование вскрывает лишние "велосипеды" и подсвечивает, где лучше стандартизировать, а где можно удариться в эксперименты. Как результат - получаем более реалистичную стратегию и понятные приоритеты.
🪳 Метод MoSCoW - универсальный инструмент для приоритизации задач любого масштаба
Классическая схема Must/Should/Could/Won’t (пользуйтесь, пока не запретили) объясняется на примерах из продуктовой и личной практики, где они могут и сочетаться с другими методиками (например, тот же RICE). Еще хорошо написано, как эти инструменты помогают общаться с заказчиками при переносах сроков.
🪙 Канбан-каденции: пошаговое руководство по внедрению в команде
Канбан-каденции — это регулярные встречи команды, которые помогают всем быть на одной волне: видеть, что происходит, синхронизироваться и постепенно улучшать работу. Похоже на дейлик, но если в дейлике смотрят насколько до конца рабочего дня цель спринта, то в каденции - фокусируются на процессе. Всего типов каденций целых семь, и статья их описывает плюс рекомендует, с чего лучше начать.
🐶 Как сделать диаграмму Ганта в Google Таблицах: пошаговая инструкция с примерами
Диаграмма Ганта — один из самых популярных инструментов для визуализации и отслеживания задач в управлении проектами. Статья о том, как собрать нормальную диаграмму без специальных программ, а в онлайн-экселе, без мазохизма . Много скринов и примеров.
🍌 Как правильно формулировать нефункциональные требования
О том, что "падения на проде" часто идут не от логики, а от неописанных НФТ - производительности, надежности, безопасности, удобства, совместимости и др. У автора есть конкретные метрики вместо расплывчатых "быстро/удобно", с опорой на ISO 25010 и реальную проверку через нагрузочные, юзабилити-тесты и SLA/SLO. Ещё поясняется, как вытаскивать у бизнеса численные ожидания (время отклика, допустимый простой, поддерживаемые платформы) и не забывать про регуляторику.
🔑 Система документации для проектного офиса: создаем живую модель, а не очередную бюрократию
Автор предлагает каркас: разделить этапы и статусы проектов, согласовать глоссарий и собрать "умную таблицу" пакетов документов под каждое состояние. Это дает единый источник “истины”, снимает гонку версий в почте/чатах и упрощает онбординг новых участников. Вместо "вечных шаблонов" - вечные принципы обновления и регулярная ревизия.
🐧 Оценка сроков выполнения задач: покоряем закон Хофштадтера
Разбор интересного кейса, где "6 месяцев" на проект растянулись почти на 2 года (хе-хе, не так уж и много), иллюстрирует разницу между оценкой и обязательством. Куда деваться, если проекты так непредсказуемы? Автор советует говорить в вероятностях, закладывать в сроки "открытие масштаба" и фиксировать неопределенность явным буфером. Дополнительно важно увязывать риски с соседними функциями - маркетингом, продажами, поддержкой, чтобы коллеги вас не возненавидели (если еще не поздно).
Автор эпатирует, и Agile в РФ не умер - он "приземлился" в гибриды под реальность импортозамещения, ограничений и давления сроков. Ритуалы и "чистые" фреймворки в крупных компаниях уступают месту упрощенным процессам с упором на DevOps и автоматизацию (спасибо ИИ и бьютификации). Малые команды сохраняют гибкость, но тоже меньше гоняются за формой и больше - за результатом. И самое главное - это нормально)
А это такой инструмент. Карты Уордли помогают увидеть, что покупается "как товар", а что требует собственных инвестиций, и сопоставить это с ценностью для пользователя. Картирование вскрывает лишние "велосипеды" и подсвечивает, где лучше стандартизировать, а где можно удариться в эксперименты. Как результат - получаем более реалистичную стратегию и понятные приоритеты.
Классическая схема Must/Should/Could/Won’t (пользуйтесь, пока не запретили) объясняется на примерах из продуктовой и личной практики, где они могут и сочетаться с другими методиками (например, тот же RICE). Еще хорошо написано, как эти инструменты помогают общаться с заказчиками при переносах сроков.
Канбан-каденции — это регулярные встречи команды, которые помогают всем быть на одной волне: видеть, что происходит, синхронизироваться и постепенно улучшать работу. Похоже на дейлик, но если в дейлике смотрят на
Диаграмма Ганта — один из самых популярных инструментов для визуализации и отслеживания задач в управлении проектами. Статья о том, как собрать нормальную диаграмму без специальных программ, а в онлайн-экселе, без мазохизма . Много скринов и примеров.
О том, что "падения на проде" часто идут не от логики, а от неописанных НФТ - производительности, надежности, безопасности, удобства, совместимости и др. У автора есть конкретные метрики вместо расплывчатых "быстро/удобно", с опорой на ISO 25010 и реальную проверку через нагрузочные, юзабилити-тесты и SLA/SLO. Ещё поясняется, как вытаскивать у бизнеса численные ожидания (время отклика, допустимый простой, поддерживаемые платформы) и не забывать про регуляторику.
Автор предлагает каркас: разделить этапы и статусы проектов, согласовать глоссарий и собрать "умную таблицу" пакетов документов под каждое состояние. Это дает единый источник “истины”, снимает гонку версий в почте/чатах и упрощает онбординг новых участников. Вместо "вечных шаблонов" - вечные принципы обновления и регулярная ревизия.
Разбор интересного кейса, где "6 месяцев" на проект растянулись почти на 2 года (хе-хе, не так уж и много), иллюстрирует разницу между оценкой и обязательством. Куда деваться, если проекты так непредсказуемы? Автор советует говорить в вероятностях, закладывать в сроки "открытие масштаба" и фиксировать неопределенность явным буфером. Дополнительно важно увязывать риски с соседними функциями - маркетингом, продажами, поддержкой, чтобы коллеги вас не возненавидели (если еще не поздно).
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥4 3👍2 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
👀 Основы, гайды, инструменты (часть 2)
👀 Таски есть, системы нет
Про пять болей задач в разработке, от неясных постановок до техдолга. Идея автора - тянуть факты и инциденты в одно место, где будет видно зависимости, причины, принятую модель и границы. И делать это должен ИИ (опять этот ИИ), который быстрее кожаных найдет разрывы, долговые узлы и ключевые проблемы (см дальше).
😱 Таски есть, системы нет: о ключевой проблеме
А ключевая проблема - это то, что нет единого образа системы и общего языка управления потоками задач. Из-за этого задачи живут сами по себе, а не встраиваются в целостный контур. Решение автору видится в общих принципах представления информации, согласованных стереотипах и "едином источнике правды". При этом сами инструменты вторичны: без модели любая доска превращается в ленту.
🤗 Жизнь после внедрения глазами системного и бизнес-аналитиков
Да, поддержка - не "хвост проекта", а отдельный режим работы с собственными правилами. Нужны SLA, понятные каналы,отдельная доска в битриксе, канбан-подход к потоку, договоренности с соседними командами и дисциплина в документации. Автор делится практиками рутинных ритуалов, чтобы не тонуть в "пожарах" и переключениях.
👍 ТОП-10 канбан-досок для управления задачами в 2025 году
Обзор сравнивает популярные доски по настройке колонок, WIP-лимитам, автоматизации и аналитике, а также по тарифам и целевым сценариям. Упомянуты варианты для маленьких команд и крупных процессов, различия в интеграциях и отчетности - Кайтен (да, это их текст…), Shtab, Teamly, Aspro, TeamStorm, любимый Битрикс24 и т.д.
👀 Дневник проекта: заметки на полях
Подборка антипаттернов управления проектами: старт без образа результата, набор фич, собранный рандомно "по дороге", зависимость от одного сценария без плана Б. В рецептах - метод RICE для приоритизации, явные критерии приемки до кода и обязательная (!) работа с рисками. Отдельный акцент - на защите проектного документа и согласовании ожиданий до работы спринтов.
🙂 Напомню, что все дайджесты, со ссылками, тегами, pdf-ками и с удобным поиском можно посмотреть на спец.сайте. Пользуйтесь как базой знаний для себя и коллег!
Про пять болей задач в разработке, от неясных постановок до техдолга. Идея автора - тянуть факты и инциденты в одно место, где будет видно зависимости, причины, принятую модель и границы. И делать это должен ИИ (опять этот ИИ), который быстрее кожаных найдет разрывы, долговые узлы и ключевые проблемы (см дальше).
А ключевая проблема - это то, что нет единого образа системы и общего языка управления потоками задач. Из-за этого задачи живут сами по себе, а не встраиваются в целостный контур. Решение автору видится в общих принципах представления информации, согласованных стереотипах и "едином источнике правды". При этом сами инструменты вторичны: без модели любая доска превращается в ленту.
Да, поддержка - не "хвост проекта", а отдельный режим работы с собственными правилами. Нужны SLA, понятные каналы,
Обзор сравнивает популярные доски по настройке колонок, WIP-лимитам, автоматизации и аналитике, а также по тарифам и целевым сценариям. Упомянуты варианты для маленьких команд и крупных процессов, различия в интеграциях и отчетности - Кайтен (да, это их текст…), Shtab, Teamly, Aspro, TeamStorm, любимый Битрикс24 и т.д.
Подборка антипаттернов управления проектами: старт без образа результата, набор фич, собранный рандомно "по дороге", зависимость от одного сценария без плана Б. В рецептах - метод RICE для приоритизации, явные критерии приемки до кода и обязательная (!) работа с рисками. Отдельный акцент - на защите проектного документа и согласовании ожиданий до работы спринтов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5 3❤1🔥1💘1 1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6😢3❤1👍1
🔥 Самые интересные материалы по управлению проектами за 2 недели
⚔️ Основы, гайды, инструменты
🐑 8 примеров диаграмм Ганта: от классической до с зависимостями и ресурсами
Отличный текст для любителей и заложников Ганта. Показаны разные варианты диаграммы: иерархический, с зависимостями, с критическим путём и распределением ресурсов. Для каждого - когда применять, какую управленческую задачу закрывает и чего опасаться (напр., перегруз визуализацией, неверные связи). Есть мини-инструкции по построению и рабочие лайфхаки из практики. Полезно как для старта, так и для "пересборки" вашего план-графика.
🔧 Пропускная способность в Канбан: как считать throughput
Вы же прочитали сейчас вслух это слово, да? Автор пишет про разницу между velocity (план в спринте) и throughput (фактическое число завершенных элементов за единицу времени). Поясняет, как собирать данные, строить распределение и зачем смотреть в паре с другими показателями - cycle time и WIP. И на что влияет этот показатель (позволяет делать прогнозы и корректировать ожидания заказчика).
😊 Как экономить время на фиче, растянув её на три спринта
Кейс МТС про то, как укоротить цикл поставки ценности, когда фича "размазывается" на месяцы и теряет актуальность. Команда экспериментально ужала процесс до двух спринтов, пересобрав цепочку согласований, протокол демо и порядок работы с зависимостями. Самое главный вывод авторов - что если слегка забить на сроки, но при этом снять организационные задержки и иметь понятные критерии готовности, то всё получится даже лучше, чем в случае жесткого дедлайна и короткого спринта.
🍪 Одна грязная чашка, или как мелкий беспорядок разрушает великие компании
Если вы в мелочах (не критичных для процесса) допускаете бардак и несистемность, то… у автора статьи для нас плохие новости) На примерах "разбитых окон", “грязных чашек” и неубранных наблюдателей он показывает, как мелкие сигналы хаоса множат нарушения и снижают стандарты работы. Среда "учит" поведению, поэтому порядок в деталях - это не душнилово и педантизм, а профилактика системных проблем. Будешь убирать мелкие разрывы (имена файлов, правила общения, чистоту рабочих зон - будешь тратить меньше сил на "пожары", получишь меньше когнитивного шума и более предсказуемую дисциплину.
🍪 Я собрал 21 канбан-доску на все случаи жизни (от запуска IT-продукта до похода на свидание)
Больше для досуга, чем для вашей работы, но… вот большая подборка готовых канбан-досок: от обучения и путешествий до подарков и "апокалипсис-канбана". В каждой автор прописал назначение, определил структуру колонок и подсказки, как держать фокус и отслеживать прогресс.
💰 Миграция здорового человека: как переехать на новую IT-систему без нервного срыва
Структурированный план переезда на новую версию ITSM. Сначала ребята сделали аудит интеграций и процессов, затем - план переноса данных, пилотный запуск, катовер (это план раскатки, если кто не знал) и пост-мониторинг. Авторы предлагают чек-листы и логику "никакой импровизации в день X". Ну и в качестве выигрыша получаем меньше регрессий, меньше легаси и всякие релизные новинки.
😌 Чем заменить Jira и MS Project? Обзор российского решения для комплексного управления проектами
Обзор системы Project Ruler (видимо, рекламный, но информативный). Система закрывает не только задачи и проекты, но и портфельный уровень - инициативы, приоритизацию под цели, базу знаний, с общим акцентом на “платформенность”, которая должна заменить собой привычный “зоопарк” софта. Также приведены сценарии внедрения и экономический эффект.
😱 "Мы думали, это займёт три дня": как сократить разрыв между бизнесом и IT
Автор называет главной проблемой "разорванный ландшафт": бизнес и IT живут в разных реальностях, а это ведёт к монолитам, лишним интеграциям и срывам сроков. А решение? Надо смотреть на ландшафт совместно - как на единую систему зарабатывания денег, разделять домены и назначать владельцев процессов. Нужны совместные аудиты, участие архитекторов в бизнес-встречах и договоренности о границах ответственности.
🐑 8 примеров диаграмм Ганта: от классической до с зависимостями и ресурсами
Отличный текст для любителей и заложников Ганта. Показаны разные варианты диаграммы: иерархический, с зависимостями, с критическим путём и распределением ресурсов. Для каждого - когда применять, какую управленческую задачу закрывает и чего опасаться (напр., перегруз визуализацией, неверные связи). Есть мини-инструкции по построению и рабочие лайфхаки из практики. Полезно как для старта, так и для "пересборки" вашего план-графика.
Вы же прочитали сейчас вслух это слово, да? Автор пишет про разницу между velocity (план в спринте) и throughput (фактическое число завершенных элементов за единицу времени). Поясняет, как собирать данные, строить распределение и зачем смотреть в паре с другими показателями - cycle time и WIP. И на что влияет этот показатель (позволяет делать прогнозы и корректировать ожидания заказчика).
Кейс МТС про то, как укоротить цикл поставки ценности, когда фича "размазывается" на месяцы и теряет актуальность. Команда экспериментально ужала процесс до двух спринтов, пересобрав цепочку согласований, протокол демо и порядок работы с зависимостями. Самое главный вывод авторов - что если слегка забить на сроки, но при этом снять организационные задержки и иметь понятные критерии готовности, то всё получится даже лучше, чем в случае жесткого дедлайна и короткого спринта.
Если вы в мелочах (не критичных для процесса) допускаете бардак и несистемность, то… у автора статьи для нас плохие новости) На примерах "разбитых окон", “грязных чашек” и неубранных наблюдателей он показывает, как мелкие сигналы хаоса множат нарушения и снижают стандарты работы. Среда "учит" поведению, поэтому порядок в деталях - это не душнилово и педантизм, а профилактика системных проблем. Будешь убирать мелкие разрывы (имена файлов, правила общения, чистоту рабочих зон - будешь тратить меньше сил на "пожары", получишь меньше когнитивного шума и более предсказуемую дисциплину.
Больше для досуга, чем для вашей работы, но… вот большая подборка готовых канбан-досок: от обучения и путешествий до подарков и "апокалипсис-канбана". В каждой автор прописал назначение, определил структуру колонок и подсказки, как держать фокус и отслеживать прогресс.
Структурированный план переезда на новую версию ITSM. Сначала ребята сделали аудит интеграций и процессов, затем - план переноса данных, пилотный запуск, катовер (это план раскатки, если кто не знал) и пост-мониторинг. Авторы предлагают чек-листы и логику "никакой импровизации в день X". Ну и в качестве выигрыша получаем меньше регрессий, меньше легаси и всякие релизные новинки.
Обзор системы Project Ruler (видимо, рекламный, но информативный). Система закрывает не только задачи и проекты, но и портфельный уровень - инициативы, приоритизацию под цели, базу знаний, с общим акцентом на “платформенность”, которая должна заменить собой привычный “зоопарк” софта. Также приведены сценарии внедрения и экономический эффект.
Автор называет главной проблемой "разорванный ландшафт": бизнес и IT живут в разных реальностях, а это ведёт к монолитам, лишним интеграциям и срывам сроков. А решение? Надо смотреть на ландшафт совместно - как на единую систему зарабатывания денег, разделять домены и назначать владельцев процессов. Нужны совместные аудиты, участие архитекторов в бизнес-встречах и договоренности о границах ответственности.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2🔥2 2💘1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😐 Проджект-менеджер, навыки и карьера
🕺 Тимлид и agile: как команда стала пионером продуктового подхода в Банке
Команда Уралсиба хвастается, как ушла от "водопада" к продуктовому подходу и уже много спринтов стабильно поставляет работающий функционал. Из значимого - срезали бюрократию, меньше согласований и протоколов, больше быстрых встреч по сути и общих демо раз в три недели. На старте буксовали из-за нехватки декомпозиции (приводят грустный пример даже), но выручили прозрачные роли, право просить помощь и дисциплина. Итог - всё прекрасно и бизнес стал доверять еще больше)
🤬 Как заткнуть внутреннего критика и получить отличный результат проще и быстрее?
Для вас, перфекционистки! При всех ваших плюсах, автор считает, что ориентация на некое расплывчатое “качество” тянет вас к бесконечной "полировке" и срыву дедлайнов. И предлагает сменить оптику: мерять не "идеальность", а скорость старта, простоту самого решения, ясность и раннюю обратную связь. Надо упрощать задачи под имеющиеся ресурсы, проверять сложные узлы вплоть до рисования в тетрадке, быстрее прототипировать и доделывать не под абстрактные идеалы, а под задачи бизнеса.
😋 Исполнитель vs руководитель: как я перешла на сторону управления
Личный путь из роли администратора проектов в руководители: сначала - насмотренность и инициативы сверх должностных обязанностей, потом - теория и менторство. Ключевой сдвиг - от "что сделать" к "зачем и как лучше", с управлением рисками, ресурсами и качеством результата. Автор подчёркивает ценность поддержки руководителя и "малых побед" вроде самостоятельного ведения сложного внедрения. Советы желающим перейти - пробовать управленческие задачи заранее, развивать коммуникативные навыки и искать наставника.
🐕 ИТ-менеджер, который перестал быть "пожарным". История управления 40 проектами и система, которая меня спасла
Кейс - на одного менеджера свалилось 20+ проблемных проектов, и спасла его не "героика", а система из десяти заповедей принципов. Кртк: группировка схожих проектов, использование шаблонов документов, обязательная база знаний и циклы рутин (да) по расписанию. Плюс "правило пяти задач в день", быстрые ответы на простые запросы, умение отложить "неидущую" проблему. И плюс внимание к личным психо-эмо-ресурсам (хобби, восстановление).
😨 Проектный офис: база знаний для обучения и повышения квалификации сотрудников
О том, что база знаний в ПМО - это не архив, а именно среда обучения: онбординг, методологии, уроки проектов и ответы на частые вопросы. Такой подход снимает "утечку знаний", снижает нагрузку на экспертов и выравнивает стандарты между командами. В статье дан план внедрения: пилотная группа, понятная структура, первые 5–7 шаблонов и глоссарий, регламент обновлений и мотивация авторов.
🥣 Рынок эйчара
Как не упомянуть один из топовых текстов месяца) Про любимых всеми HR-специалистов, как скрининги отсекают кандидатов еще до встречи с командой, как эйчары принимают решения по чек-листам и "табличкам". Примеры "блиц-опросов" с перекрученной терминологией (очень знакомо) и отказов без чтения резюме. Увы, выросла роль посредника, а не нанимающей команды - и это тормозит здравый отбор. Особенно с учетом изменений на рынке труда…
Команда Уралсиба хвастается, как ушла от "водопада" к продуктовому подходу и уже много спринтов стабильно поставляет работающий функционал. Из значимого - срезали бюрократию, меньше согласований и протоколов, больше быстрых встреч по сути и общих демо раз в три недели. На старте буксовали из-за нехватки декомпозиции (приводят грустный пример даже), но выручили прозрачные роли, право просить помощь и дисциплина. Итог - всё прекрасно и бизнес стал доверять еще больше)
Для вас, перфекционистки! При всех ваших плюсах, автор считает, что ориентация на некое расплывчатое “качество” тянет вас к бесконечной "полировке" и срыву дедлайнов. И предлагает сменить оптику: мерять не "идеальность", а скорость старта, простоту самого решения, ясность и раннюю обратную связь. Надо упрощать задачи под имеющиеся ресурсы, проверять сложные узлы вплоть до рисования в тетрадке, быстрее прототипировать и доделывать не под абстрактные идеалы, а под задачи бизнеса.
Личный путь из роли администратора проектов в руководители: сначала - насмотренность и инициативы сверх должностных обязанностей, потом - теория и менторство. Ключевой сдвиг - от "что сделать" к "зачем и как лучше", с управлением рисками, ресурсами и качеством результата. Автор подчёркивает ценность поддержки руководителя и "малых побед" вроде самостоятельного ведения сложного внедрения. Советы желающим перейти - пробовать управленческие задачи заранее, развивать коммуникативные навыки и искать наставника.
Кейс - на одного менеджера свалилось 20+ проблемных проектов, и спасла его не "героика", а система из десяти заповедей принципов. Кртк: группировка схожих проектов, использование шаблонов документов, обязательная база знаний и циклы рутин (да) по расписанию. Плюс "правило пяти задач в день", быстрые ответы на простые запросы, умение отложить "неидущую" проблему. И плюс внимание к личным психо-эмо-ресурсам (хобби, восстановление).
О том, что база знаний в ПМО - это не архив, а именно среда обучения: онбординг, методологии, уроки проектов и ответы на частые вопросы. Такой подход снимает "утечку знаний", снижает нагрузку на экспертов и выравнивает стандарты между командами. В статье дан план внедрения: пилотная группа, понятная структура, первые 5–7 шаблонов и глоссарий, регламент обновлений и мотивация авторов.
Как не упомянуть один из топовых текстов месяца) Про любимых всеми HR-специалистов, как скрининги отсекают кандидатов еще до встречи с командой, как эйчары принимают решения по чек-листам и "табличкам". Примеры "блиц-опросов" с перекрученной терминологией (очень знакомо) и отказов без чтения резюме. Увы, выросла роль посредника, а не нанимающей команды - и это тормозит здравый отбор. Особенно с учетом изменений на рынке труда…
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6 3❤1💘1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😍 Проджект-менеджер, навыки и карьера (I)
🥺 Как делегировать задачи и не стать эксплуататором: ищем золотую середину
Автор предлагает приземленный набордеда руководителя: качественный найм под контекст, индивидуальный план адаптации, постановка задач с ясным смыслом и планом от самого исполнителя (а не от постановщика), контрольные точки вместо микроменеджмента и запрет обратного делегирования.
😂 Выгорание – это манипуляция (памятка, как не выгорать для ИТ менеджера)
Тезис статьи - отпуск (хоть на три дня, хоть на 2 недели) не лечит систему и не помогает от выгорания, если в самой рабочей рутине нет границ и возможностей для оперативного восстановления. Концентрацию на 8 часов ежедневно и месяцами подряд поддерживать невозможно, потому нужно встроить заботу о себе в режим дня. Автор делится личным списком "коротких/средних/длинных" переключений и формулирует позицию: выгорают те, кто не удержал границы и тянет героизм в одиночку, поэтому планирование преемственности и защита личного времени - часть профессионализма.
😢 Мы тонем: как менеджер спасал свои проекты
История о том, как проекты жили в чатах и Excel, статусы устаревали, задачи терялись, сроки плыли. Потом решили сделать переход в единую систему управления проектами - и он дал общий план (включая диаграмму Ганта и критический путь), карточки с красными индикаторами, коммуникацию прямо в задачах😐 и согласования. В итоге шаблоны проектов и дашборды по загрузке сократили ручную рутину, повысили рентабельность и перевели разговор с руководством на язык данных, а команда перестала "тонуть" в бардаке переписок.
😨 Чувство вины, размытые ТЗ и страх говорить: о чем молчит ваша команда
Автор предлагает заменять культуру поиска виноватого культурой “разбора контекста”. Косяк и прокрастинация - это часто сигнал о неясности критериев или перегрузе, а не о лени сотрудника. Делу помогают открытые разговоры на ретро/синках, явное формулирование опасений и запросов о помощи, а также перевод ошибок из "клейма" в входные данные для улучшения процесса.
😂 Менеджер в квадрате: как принцип "Одна голова хорошо, а две лучше" работает на практике
Кейс про то, как в проектном офисе с 80 проектами в квартал еженедельные часовые статусы "по 45 секунд на проект" не давали глубины (внезапно, да?), поэтому ввели роль куратора: опытный менеджер ведет 3–4 команды, проводит недельные 30-минутные сессии и синхронизируется с руководителем. Такая надстройка разгружает общего руководителя, повышает качество обратной связи и масштабирует развитие менеджеров через регулярную поддержку с ближней дистанции.
😔 Флуд, "звоночек на 5 минут", голосовое гендира в час ночи: 7 рабочих привычек, которые ненавидит каждый
Анти-топ офисных привычек: бесконечные чаты, пассивная агрессия, "всегда на связи", бесцельные пятиминутки, голосовые вместо текста, игнор и т.п. Автор предлагает приземленные контр-меры - перенос переписок в трекер задач, "тихие часы", фиксирование итогов созвонов, авторасшифровка голосовых и мягкая модерация флуда. Короче, всё для того, чтобы разговоры перестали подменять работу и ничего не терялось.
🤔 Проверьте, развито ли у вас ресурсное мышление, и чего вы себя лишаете, если нет?
"Ресурсное мышление" тут определено как умение создавать возможности в дефиците, когда нет ресурсов. Не ждать идеальных условий, а менять контекст под задачу. На примерах автор показывает, как перепридумывать правила игры и пытаться получать результат там, где обычно отступают.
Автор предлагает приземленный набор
Тезис статьи - отпуск (хоть на три дня, хоть на 2 недели) не лечит систему и не помогает от выгорания, если в самой рабочей рутине нет границ и возможностей для оперативного восстановления. Концентрацию на 8 часов ежедневно и месяцами подряд поддерживать невозможно, потому нужно встроить заботу о себе в режим дня. Автор делится личным списком "коротких/средних/длинных" переключений и формулирует позицию: выгорают те, кто не удержал границы и тянет героизм в одиночку, поэтому планирование преемственности и защита личного времени - часть профессионализма.
История о том, как проекты жили в чатах и Excel, статусы устаревали, задачи терялись, сроки плыли. Потом решили сделать переход в единую систему управления проектами - и он дал общий план (включая диаграмму Ганта и критический путь), карточки с красными индикаторами, коммуникацию прямо в задачах
Автор предлагает заменять культуру поиска виноватого культурой “разбора контекста”. Косяк и прокрастинация - это часто сигнал о неясности критериев или перегрузе, а не о лени сотрудника. Делу помогают открытые разговоры на ретро/синках, явное формулирование опасений и запросов о помощи, а также перевод ошибок из "клейма" в входные данные для улучшения процесса.
Кейс про то, как в проектном офисе с 80 проектами в квартал еженедельные часовые статусы "по 45 секунд на проект" не давали глубины (внезапно, да?), поэтому ввели роль куратора: опытный менеджер ведет 3–4 команды, проводит недельные 30-минутные сессии и синхронизируется с руководителем. Такая надстройка разгружает общего руководителя, повышает качество обратной связи и масштабирует развитие менеджеров через регулярную поддержку с ближней дистанции.
Анти-топ офисных привычек: бесконечные чаты, пассивная агрессия, "всегда на связи", бесцельные пятиминутки, голосовые вместо текста, игнор и т.п. Автор предлагает приземленные контр-меры - перенос переписок в трекер задач, "тихие часы", фиксирование итогов созвонов, авторасшифровка голосовых и мягкая модерация флуда. Короче, всё для того, чтобы разговоры перестали подменять работу и ничего не терялось.
"Ресурсное мышление" тут определено как умение создавать возможности в дефиците, когда нет ресурсов. Не ждать идеальных условий, а менять контекст под задачу. На примерах автор показывает, как перепридумывать правила игры и пытаться получать результат там, где обычно отступают.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3 2 2👍1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😛 Проджект-менеджер, навыки и карьера (II)
🙅♂️ Какие навыки необходимо развивать, если хотите стать руководителем
Если коротко, то брать ответственностьдаже когда не просят, проявлять инициативы и закрывать сложные задачи еще до должности, плюс работать по выходным поддерживать высокий уровень компетентности и производительности. Отдельный акцент на чистой коммуникации (умение "продать" результат), эмоциональной зрелости и работе с конфликтами. По сути, это короткая дорожная карта роста от специалиста к руководителю.
🧣 Риск - это не страшно: как команде проектного офиса превратить угрозы в точки роста
Автор (из интегратора) показывает, как карта/реестр рисков и база знаний превращают пожаротушение на проекте в предсказуемый процесс. “Всего-то” нужно внедрить хоть какое-то управление рисками - категории рисков, вероятности, планы реагирования и ежегодная ревизия. В примерах - разложение рисков по подразделениям, связка с “уроками проектов” (типа постмортемов) и автоматизация триггеров в системе управления работой. Всё это помогает команде действовать на опережение, а не по факту “пожара”.
PS. Помню, проходил курс РП в Яндексе. У нас было два куратора, причем один из СБЕРа, и обе сказали, что "мда, риски, конечно, мы особо не просчитываем и карты не составляем, да и не нужны они"...
🦯 Рецензия на книгу "Паттерны коммуникации: руководство для ИТ -разработчиков и архитекторов"
Книга Джеки Рид предлагает рассматривать общение как набор повторяемых ситуаций с паттернами и антипаттернами, чтобы не "импровизировать" каждый раз с нуля. Упор на визуальные средства, ясность аудитории и уровень абстракции делает навык конструктивного диалога таким же воспроизводимым, как архитектурные решения в коде, - и этот инструмент не устаревает вместе со стеком. И да, надо будет почитать саму книгу…
😮💨 Опасная середина: как ИИ изменит роли скрам -мастеров и аджайл -коучей
Тезисно, - ИИ вымывает менеджеров процессов и оставляет ценность там, где требуется интегративное мастерство: организационные изменения, работа с данными и политикой, системное мышление и коучинг руководителей. Рекомендации - выйти из "опасной середины" через новую модель компетентности, автоматизировать рутину и сосредоточиться на построении обучающейся организации. Короче, ура, нас еще не хоронят.
💪 Кризис – это возможности для роста: как мы переходили на отечественный софт
Интересный кейс проекта по массовой замене привычных инструментов (Windows/Outlook/Skype) на Astra Linux, R7 Office и TrueConf. Этот переход обрушил на линию лавину обращений и удвоил среднее время обработки, но единая база знаний с ролями, временные обходные решения, выделение "третьей линии" и связка с ITSM выровняли поток. Плюс внутренние утилиты, плюс приоритизация автоматизации по трудозатратам - и в итоге экономия на обращении и рост удовлетворенности.
Если коротко, то брать ответственность
Автор (из интегратора) показывает, как карта/реестр рисков и база знаний превращают пожаротушение на проекте в предсказуемый процесс. “Всего-то” нужно внедрить хоть какое-то управление рисками - категории рисков, вероятности, планы реагирования и ежегодная ревизия. В примерах - разложение рисков по подразделениям, связка с “уроками проектов” (типа постмортемов) и автоматизация триггеров в системе управления работой. Всё это помогает команде действовать на опережение, а не по факту “пожара”.
PS. Помню, проходил курс РП в Яндексе. У нас было два куратора, причем один из СБЕРа, и обе сказали, что "мда, риски, конечно, мы особо не просчитываем и карты не составляем, да и не нужны они"...
Книга Джеки Рид предлагает рассматривать общение как набор повторяемых ситуаций с паттернами и антипаттернами, чтобы не "импровизировать" каждый раз с нуля. Упор на визуальные средства, ясность аудитории и уровень абстракции делает навык конструктивного диалога таким же воспроизводимым, как архитектурные решения в коде, - и этот инструмент не устаревает вместе со стеком. И да, надо будет почитать саму книгу…
Тезисно, - ИИ вымывает менеджеров процессов и оставляет ценность там, где требуется интегративное мастерство: организационные изменения, работа с данными и политикой, системное мышление и коучинг руководителей. Рекомендации - выйти из "опасной середины" через новую модель компетентности, автоматизировать рутину и сосредоточиться на построении обучающейся организации. Короче, ура, нас еще не хоронят.
Интересный кейс проекта по массовой замене привычных инструментов (Windows/Outlook/Skype) на Astra Linux, R7 Office и TrueConf. Этот переход обрушил на линию лавину обращений и удвоил среднее время обработки, но единая база знаний с ролями, временные обходные решения, выделение "третьей линии" и связка с ITSM выровняли поток. Плюс внутренние утилиты, плюс приоритизация автоматизации по трудозатратам - и в итоге экономия на обращении и рост удовлетворенности.
Please open Telegram to view this post
VIEW IN TELEGRAM
1 2 2❤1🔥1🙏1💘1
Друзья и коллеги!
😱 Незаметно вас стало почти 1200 - это очень круто ! Приятно видеть среди читателей и начинающих ПМов, и опытных коллег 😛 , и зубров-корпоратов, и авторитетных властителей дум...
Сегодня "Проектный дайджест" - это своеобразный продукт, включающий тг-канал, рубрику на Хабре и лендинг с базой знаний.
И нам кажется, самое время задать вопросы на тему "А как вы видите дальнейшее развитие канала и продукта? Что ок, что не ок, что добавить, что убрать?"...
И если вы выделите 4-5 минут, чтобы ответить на такие вопросы, - это будет лучший вклад в развитие "Проектного дайджеста".
Поможете?👀
https://docs.google.com/forms/d/e/1FAIpQLSd8y1OGAjIhBCtC4s-xWqh6lfca2na6d5tLGVDnka4z9xlYtg/viewform
Сегодня "Проектный дайджест" - это своеобразный продукт, включающий тг-канал, рубрику на Хабре и лендинг с базой знаний.
И нам кажется, самое время задать вопросы на тему "А как вы видите дальнейшее развитие канала и продукта? Что ок, что не ок, что добавить, что убрать?"...
И если вы выделите 4-5 минут, чтобы ответить на такие вопросы, - это будет лучший вклад в развитие "Проектного дайджеста".
Поможете?
https://docs.google.com/forms/d/e/1FAIpQLSd8y1OGAjIhBCtC4s-xWqh6lfca2na6d5tLGVDnka4z9xlYtg/viewform
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Опрос «Проектный дайджест»
Это анонимный опрос для улучшения “Проектного дайджеста” (ТГ-канал + онлайн-база знаний). Ответы займут ~4–5 минут. Именно на основе ваших ответов мы будем менять формат, темы и удобство использования. Спасибо!
1 4👍2🔥2👏1 1
Проектный дайджест pinned «Друзья и коллеги! 😱 Незаметно вас стало почти 1200 - это очень круто ! Приятно видеть среди читателей и начинающих ПМов, и опытных коллег 😛 , и зубров-корпоратов, и авторитетных властителей дум... Сегодня "Проектный дайджест" - это своеобразный продукт, включающий…»
🔥 Самые интересные материалы по управлению проектами за 2 недели
😔 Основы, гайды, кейсы, инструменты (I)
😎 19 видов диаграмм: какие бывают и как выбрать подходящую в 2026 году
Путеводитель по визуализациям объясняет, под какой вопрос подходит каждый тип графика: сравнение, распределение, состав, связь, изменение во времени. На примерах авторы показывают типичные ошибки вроде перегруза деталями, 3D‑эффектов и злоупотребления «пирогами», когда точнее подойдут столбики или водопад (а то и любимая сводная таблица 😉).
😐 Генри Гант и его диаграмма: путь от идеи до современных инструментов менеджмента
Краткая история метода Ганта — от бумажных линеек до онлайн‑сервисов с зависимостями, критическим путем и ресурсами. И объяснение, почему «лента задач» помогает держать сроки. Поясняются базовые элементы диаграммы Ганта и кейсы, где она дает максимум эффекта, если не усложнять и не пытаться вести ей все подряд. Главная польза диаграммы — видимость узких мест и точек, где проект реально держится.
🗒 Scrum и Kanban: отличия и советы по выбору методологии
Сравнение двух подходов: Scrum подходит там, где нужны ритм, роли и инкременты в спринтах. Kanban же - это непрерывный поток с WIP‑лимитами и временем прохождения. Статья касается метрик и типовых контекстов: разработка нового функционала, поддержка и операции, смешанные команды, и подсказывает, где уместен тот самый Scrumban.
😔 Идеи потерявшие смысл: Scrum и ООП
Автор возвращает Scrum к исходной логике месячного спринта и полного цикла улучшений вместо «галочек» ради процесса (там еще про ООП, но это отдельная история). Ну а критика коротких спринтов — в том, что исчезает пространство для анализа, критериев готовности и адаптации команды.
😘 Тайм ‑менеджмент: как правильно управлять временем
Систематизация базовых принципов личной и проектной эффективности: двигаться от целей к задачам, планировать реалистично, регулярно чинить свою систему и не перегревать себя множеством техник сразу. Авторы разбирают популярные приемы (матрица приоритетов, блочное планирование, «съесть лягушку», пакетная обработка, тверк), а также дают признаки того, что ваша схема дала сбой и пора упростить. Если совсем кратко — надо выбрать 1–2 привычки и связать их с недельными целями.
😱 Как дозированные боль и страдание делают нас счастливее и успешнее?
Популярный разбор нейробиологии мотивации: умеренный дискомфорт и тренировочные «провалы» могут укреплять систему вознаграждения, если чередуются с восстановлением. Речь о «ямах» дофамина, дисциплине и том, почему бесконечная гонка без пауз разрушает и результат, и настроение.
🍌 Как измерить удовлетворенность пользователей, у которых нет выбора
Когда аудитория привязана к корпоративному продукту (у которого нет особых альтернатив), классические NPS и ретеншн мало что говорят — важнее смотреть на эффективность выполнения задач, ошибки и когнитивную нагрузку. Тут‑то авторы и предлагают прикладной фреймворк (в духе CASTLE) и свои особые метрики. Такой подход якобы позволяет точечно улучшать критические шаги, а не «усредненную любовь к продукту».
Путеводитель по визуализациям объясняет, под какой вопрос подходит каждый тип графика: сравнение, распределение, состав, связь, изменение во времени. На примерах авторы показывают типичные ошибки вроде перегруза деталями, 3D‑эффектов и злоупотребления «пирогами», когда точнее подойдут столбики или водопад (а то и любимая сводная таблица 😉).
Краткая история метода Ганта — от бумажных линеек до онлайн‑сервисов с зависимостями, критическим путем и ресурсами. И объяснение, почему «лента задач» помогает держать сроки. Поясняются базовые элементы диаграммы Ганта и кейсы, где она дает максимум эффекта, если не усложнять и не пытаться вести ей все подряд. Главная польза диаграммы — видимость узких мест и точек, где проект реально держится.
Сравнение двух подходов: Scrum подходит там, где нужны ритм, роли и инкременты в спринтах. Kanban же - это непрерывный поток с WIP‑лимитами и временем прохождения. Статья касается метрик и типовых контекстов: разработка нового функционала, поддержка и операции, смешанные команды, и подсказывает, где уместен тот самый Scrumban.
Автор возвращает Scrum к исходной логике месячного спринта и полного цикла улучшений вместо «галочек» ради процесса (там еще про ООП, но это отдельная история). Ну а критика коротких спринтов — в том, что исчезает пространство для анализа, критериев готовности и адаптации команды.
Систематизация базовых принципов личной и проектной эффективности: двигаться от целей к задачам, планировать реалистично, регулярно чинить свою систему и не перегревать себя множеством техник сразу. Авторы разбирают популярные приемы (матрица приоритетов, блочное планирование, «съесть лягушку», пакетная обработка, тверк), а также дают признаки того, что ваша схема дала сбой и пора упростить. Если совсем кратко — надо выбрать 1–2 привычки и связать их с недельными целями.
Популярный разбор нейробиологии мотивации: умеренный дискомфорт и тренировочные «провалы» могут укреплять систему вознаграждения, если чередуются с восстановлением. Речь о «ямах» дофамина, дисциплине и том, почему бесконечная гонка без пауз разрушает и результат, и настроение.
Когда аудитория привязана к корпоративному продукту (у которого нет особых альтернатив), классические NPS и ретеншн мало что говорят — важнее смотреть на эффективность выполнения задач, ошибки и когнитивную нагрузку. Тут‑то авторы и предлагают прикладной фреймворк (в духе CASTLE) и свои особые метрики. Такой подход якобы позволяет точечно улучшать критические шаги, а не «усредненную любовь к продукту».
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3 3👍2🔥1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😔 Основы, гайды, кейсы, инструменты (II)
🫥 Краткий курс по менеджменту за 10 минут: база, которая вытянет любой проект
Базированный конспект ключевых основ PM: цели - декомпозиция - приоритизация - коммуникации - риски - контроль исполнения- сделаем позже, с простыми (ну и вроде рабочими же) правилами вроде «фиксируйте критерии готовности» и «держите короткий список приоритетов». Показаны базовые артефакты (доска задач, регулярные статусы, чек ‑листы) и типичные ошибки перегрева процесса ради процесса.
😁 Играем в Канбан на работе
Практический разбор канбан‑подхода от коллег из Контура - через игровой формат (всё для молодёжи!): прозрачность работы, ограничение WIP, вытягивание вместо "запихивания" и плавная оптимизация потока. На примерах показано, как метрики (lead/cycle time) связываются с реальными задержками и чем опасно скрытое многозадачие.
🤔 Глобальный упадок качества ПО: как катастрофа стала нормой
Провокационный текст о деградации качества софта: тонкие устройства и сервисы регулярно ломаются в простых сценариях, а срывы воспринимаются как неизбежная цена скорости. Знакомо, да? Среди причин этого кошмара - сложность стеков, дефицит тестирования «по месту использования» и культ релиза вместо культуры устойчивости. Текст мотивирует вернуться к инженерной дисциплине и осмысленным метрикам качества.
😢 Горе от Ума — почему IT‑проекты пишутся долго и стоят дорого (иногда)
Прикольная заметка и для менеджеров, и для заказчиков: одних «умных разработчиков» для проекта мало, проект ломается на ожиданиях, расплывчатых требованиях и постоянных мелких изменениях. Автор настаивает на согласованных границах, критериях «готово» и ответственности за каждую «быструю правку», иначе рост стоимости неизбежен. И в целом, четкая постановка проблемы помогает разговаривать о сроках и бюджете без розовых очков.
😰 Чему не учат на курсах бизнес‑аналитика: почему шаблоны ТЗ мешают работе
Шаблоны ТЗ создают ложное чувство завершенности и подменяют анализ копированием разделов, из‑за чего реальная потребность пользователя теряется. Автор предлагает идти от цели и сценариев, фиксировать ограничения и эффекты, а шаблон использовать как итоговую упаковку, а не как «каркас мышления».
🪨 Как запускать проекты без команды? Главное о кросс‑командном проджект‑менеджменте
Руководитель, у которого нет своей команды, тянет проект через влияние. Отсюда возникают карта стейкхолдеров, общая цель, понятные артефакты, договоренные ритмы и прозрачные правила приоритизации. Для таких команд важны ранние «малые победы» и аккуратная политика, потому что чужие ресурсы дают под измеримый результат, а прогресс фиксируется в открытых каналах.
🥲 Проектный офис: как соединить регламенты, базу знаний и совместную работу
Кейс QSOFT о том, как склеить процессы, знания и операционку в единую экосистему, чтобы перестать латать дыры десятком инструментов. Авторы показывают, как такой контур экономит время и бюджет, устраняет разрыв между «планами сверху» и реальной работой команд и как онбординг/управление рисками переводятся на рельсы единого пространства. Материал хорош как ориентир для минимально жизнеспособного проектного офиса.
🤷♀️ Чем заменить MS Project? 7 российских ИСУП
Обзор дает краткие «профили» инструментов с плюсами и минусами: Kaiten (сильный Канбан, но без классического планирования), Планфикс (гибкая автоматизация, но скромнее по ресурсному планированию), Битрикс24 (универсальность экосистемы, но тяжелый интерфейс😐 ), GanttPRO (простая диаграмма Ганта), WEEEK и др. Это помогает быстро сопоставить контекст проекта и ожидания по диаграммам, ресурсам и интеграциям.
Базированный конспект ключевых основ PM: цели - декомпозиция - приоритизация - коммуникации - риски - контроль исполнения
Практический разбор канбан‑подхода от коллег из Контура - через игровой формат (всё для молодёжи!): прозрачность работы, ограничение WIP, вытягивание вместо "запихивания" и плавная оптимизация потока. На примерах показано, как метрики (lead/cycle time) связываются с реальными задержками и чем опасно скрытое многозадачие.
Провокационный текст о деградации качества софта: тонкие устройства и сервисы регулярно ломаются в простых сценариях, а срывы воспринимаются как неизбежная цена скорости. Знакомо, да? Среди причин этого кошмара - сложность стеков, дефицит тестирования «по месту использования» и культ релиза вместо культуры устойчивости. Текст мотивирует вернуться к инженерной дисциплине и осмысленным метрикам качества.
Прикольная заметка и для менеджеров, и для заказчиков: одних «умных разработчиков» для проекта мало, проект ломается на ожиданиях, расплывчатых требованиях и постоянных мелких изменениях. Автор настаивает на согласованных границах, критериях «готово» и ответственности за каждую «быструю правку», иначе рост стоимости неизбежен. И в целом, четкая постановка проблемы помогает разговаривать о сроках и бюджете без розовых очков.
Шаблоны ТЗ создают ложное чувство завершенности и подменяют анализ копированием разделов, из‑за чего реальная потребность пользователя теряется. Автор предлагает идти от цели и сценариев, фиксировать ограничения и эффекты, а шаблон использовать как итоговую упаковку, а не как «каркас мышления».
Руководитель, у которого нет своей команды, тянет проект через влияние. Отсюда возникают карта стейкхолдеров, общая цель, понятные артефакты, договоренные ритмы и прозрачные правила приоритизации. Для таких команд важны ранние «малые победы» и аккуратная политика, потому что чужие ресурсы дают под измеримый результат, а прогресс фиксируется в открытых каналах.
Кейс QSOFT о том, как склеить процессы, знания и операционку в единую экосистему, чтобы перестать латать дыры десятком инструментов. Авторы показывают, как такой контур экономит время и бюджет, устраняет разрыв между «планами сверху» и реальной работой команд и как онбординг/управление рисками переводятся на рельсы единого пространства. Материал хорош как ориентир для минимально жизнеспособного проектного офиса.
Обзор дает краткие «профили» инструментов с плюсами и минусами: Kaiten (сильный Канбан, но без классического планирования), Планфикс (гибкая автоматизация, но скромнее по ресурсному планированию), Битрикс24 (универсальность экосистемы, но тяжелый интерфейс
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2 2⚡1👍1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🙂 Основы, гайды, кейсы, инструменты (I)
🙂 Метод Монте-Карло: что это и как работает
Отличный гайд по методу, поясняется идея "много случайныхзагонов прогонов вместо одной сложной формулы": из трех оценок (оптимистичной, наиболее вероятной, пессимистичной) строят распределение, гоняют тысячи симуляций и получают вероятности сроков/бюджета. Плюс даются простые примеры в Excel и наметки для Python👊 .
🍽 Метод швейцарского сыра: как избегать ошибок и управлять временем
(Пусть запрещенный сыр будет хотя бы в наших методах!!) Суть - "есть задачу дырочками": начинать с малого и простого, быстро получить кусочки готовности и поддерживать мотивацию, вместо того чтобы бояться монолитной работы. Разобраны принципы, бытовые и рабочие примеры (от уборки-стирки до подготовки отчета), есть сравнение с методами "лягушки" и "слона" и советы, как применять подход к срочным задачам.
🤩 Как сделать планирование спокойным и предсказуемым: статистические практики управления, которые помогают команде Рунити
Непростой и неповерхностный текст о том, как коллеги мощно задействовали статистику при оценке работы команды и, главное, при прогнозах на срок реализации фич и обещания сроков. За год команда прошла путь от ручных оценок до предсказуемого статистического процесса. Cycle Time стал короче, хвост распределения - уже, доля блокировок - меньше. Разница между медианой и средним сократилась втрое, а прогнозы стали совпадать с фактическими сроками. Ключевое - изменилась культура работы: вместо обсуждений "успеем - не успеем - сдвинем крайний срок на неделю" появились аргументы и данные.
🤗 Практическое применение Теории ограничений на производстве. Часть 5: про ценообразование
Еще сложный текст из очень перспективной области ТОС (знаю, тут есть ее фанаты). На это раз автор касается цены продукта (или проекта) и ее связи с “узкими местами”. Получается формула типа “изделие (ваш продукт) должно "оплатить" долю операционных расходов пропорционально времени на бутылочном горлышке плюс переменные издержки. Для ситуаций "заказов хватает" цель — максимизировать прибыль на единицу времени узкого места, а не смотреть на себестоимость материалов.
🎄 5 факапов внедрений, или почему всего не предусмотришь
Кейсы провалов от сети Dodo, от селфи на киосках до "умной выдачи". Когда софт встречается с офлайном (“бумага vs овраги”), всплывают неожиданные эффекты, которые ломают красивый план. Выводы по каждому факапу разные: прототипировать на реальной площадке, заранее включать локализацию/поведение клиентов, оговаривать план Б,делать бэкапы каждый день и держать каналы обратной связи с операционной деятельностью.
🤗 Confluence и Jira — все. Чем заменить сервисы Atlassian Data Center
Статья фиксирует таймлайн сворачивания коробочных Atlassian: новых лицензий с марта 2026, расширений с 2028, поддержка до 2029. Отсюда и риски — уязвимости, невозможность апдейтов и простои критичных процессов. Ну и, собственно, даны направления замены и аргументы в пользу миграции заранее, чтобы не остаться потом один на один с устаревшими системами.
🤪 Как испортить ПО до начала разработки? Вредные советы планирования
Любимая рубрика вредных советов. В этот раз - как сломать проект еще на этапах MVP, ревью требований, декомпозиции и назначения дедлайнов. Например, за счет подмены цели фичами или же параллельной разработки без синхронизации. Что-то вроде чек-листа анти-паттернов планирования и путь команды от них к устойчивому процессу.
😇 Нефункциональные требования. Список, который вспоминают в последний день перед релизом. Часть 1
Автор систематизирует НФТ и фокусируется на трех, которые напрямую бьют по деньгам: производительность, доступность и масштабируемость/ C примерами формулировок и подсказками про разные режимы нагрузки (норма/пик/авария). Кратко: НФТ — это про то, как работает система, их нужно фиксировать заранее и измерять наблюдаемыми метриками, иначе команда расплачивается регрессами и простоями. Узнали же, да?
Отличный гайд по методу, поясняется идея "много случайных
(Пусть запрещенный сыр будет хотя бы в наших методах!!) Суть - "есть задачу дырочками": начинать с малого и простого, быстро получить кусочки готовности и поддерживать мотивацию, вместо того чтобы бояться монолитной работы. Разобраны принципы, бытовые и рабочие примеры (от уборки-стирки до подготовки отчета), есть сравнение с методами "лягушки" и "слона" и советы, как применять подход к срочным задачам.
Непростой и неповерхностный текст о том, как коллеги мощно задействовали статистику при оценке работы команды и, главное, при прогнозах на срок реализации фич и обещания сроков. За год команда прошла путь от ручных оценок до предсказуемого статистического процесса. Cycle Time стал короче, хвост распределения - уже, доля блокировок - меньше. Разница между медианой и средним сократилась втрое, а прогнозы стали совпадать с фактическими сроками. Ключевое - изменилась культура работы: вместо обсуждений "успеем - не успеем - сдвинем крайний срок на неделю" появились аргументы и данные.
Еще сложный текст из очень перспективной области ТОС (знаю, тут есть ее фанаты). На это раз автор касается цены продукта (или проекта) и ее связи с “узкими местами”. Получается формула типа “изделие (ваш продукт) должно "оплатить" долю операционных расходов пропорционально времени на бутылочном горлышке плюс переменные издержки. Для ситуаций "заказов хватает" цель — максимизировать прибыль на единицу времени узкого места, а не смотреть на себестоимость материалов.
Кейсы провалов от сети Dodo, от селфи на киосках до "умной выдачи". Когда софт встречается с офлайном (“бумага vs овраги”), всплывают неожиданные эффекты, которые ломают красивый план. Выводы по каждому факапу разные: прототипировать на реальной площадке, заранее включать локализацию/поведение клиентов, оговаривать план Б,
Статья фиксирует таймлайн сворачивания коробочных Atlassian: новых лицензий с марта 2026, расширений с 2028, поддержка до 2029. Отсюда и риски — уязвимости, невозможность апдейтов и простои критичных процессов. Ну и, собственно, даны направления замены и аргументы в пользу миграции заранее, чтобы не остаться потом один на один с устаревшими системами.
Любимая рубрика вредных советов. В этот раз - как сломать проект еще на этапах MVP, ревью требований, декомпозиции и назначения дедлайнов. Например, за счет подмены цели фичами или же параллельной разработки без синхронизации. Что-то вроде чек-листа анти-паттернов планирования и путь команды от них к устойчивому процессу.
Автор систематизирует НФТ и фокусируется на трех, которые напрямую бьют по деньгам: производительность, доступность и масштабируемость/ C примерами формулировок и подсказками про разные режимы нагрузки (норма/пик/авария). Кратко: НФТ — это про то, как работает система, их нужно фиксировать заранее и измерять наблюдаемыми метриками, иначе команда расплачивается регрессами и простоями. Узнали же, да?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2👏1 1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🥺 Основы, гайды, кейсы, инструменты (II)
😽 Оценка задач: исследовательские и типовые задачи
Ключевая мысль - исследовательские задачи и типовые живут в разных "вселенных" планирования. К первым неприменимы обычные оценки сроков, их надо таймбоксить (ок, выделять слот времени) и измерять рост уверенности, а вот ко вторым нужно применять декомпозицию, аналоги и статистику.
🎅 Когда ТЗ — не боль, а удовольствие: Use Case
Практический шаблон юзкейсов от аналитика Okko. Есть два блока (акторы [точки входа] и сценарии), пошаговые "действие > результат", альтернативы и исключения. Автор сравнивает "табличные" и компактные форматы и показывает, как держать юзкейсы короче, но полезнее, не теряя важные ветки.
🐱 Как затянуть команду в таск-трекер, чтобы она реально в нем работала
Автор разбирает, почему "доска ради доски" не заводится, и дает рабочую схему: сначала описать реальный процесс (колонки, приоритеты, кто и когда что делает), затем ввести простые и проверяемые правила, назначить "евангелиста" (тоже не любите это слово?) процесса, обеспечить прозрачность между отделами и быстрый доступ (десктоп+мобильное приложение), переводить общение в карточки задач и регулярно поощрять публично в самой системе. А главное - внимание к конкретике! Потому что фразы типа "в пятницу в 12:00 надо актуализировать приоритеты” повышают вовлеченность в разы и убирает иллюзию контроля через разноцветные карточки.
🤪 Я больше не верю своей команде — последняя надежда на разноцветную диаграмму
Кейс фаундера, который перестал верить словам про статусы (в активном поиске) и перешел к накопительной диаграмме потока (CFD). Теперь в слоях "Новые/В работе/На проверке/Готово" стало видно, где скапливаются узкие места, как "толстеют" сегменты и где работа замерла. И это позволило точечно найти причину бутылочного горлышка (в данном кейсе - тестирование), отследить зависания по отделам, перестать паниковать при технологических простоях и в итоге ускорить выполнение задач на 15–20% за счет регулярных пятничных разборов по цифрам, а не по ощущениям.
🤪 Управляем техдолгом, пока он не начал управлять нами
Этакая практическая памятка. Автор рекомендует выделить техдолг прямо в отдельный бэклог, приоритизировать и планировать его, проводить ретро, держать метрики (скорость, дефекты, время простоя), управлять ресурсами/экспертизой. Победить техдолг невозможно, но можно контролировать его масштаб и влияние на команду и продукт, чтобы вернуть предсказуемость и спокойный темп работы.
🤪 ИИ в управлении проектами: как я применяю нейросети в реальных проектах и что получается
Автор показывает, где ИИ реально экономит время ПМ-а: черновики регламентов/ТЗ, структурирование хаотичных данных, поиск фактов, прототипирование, а также быстрые презентации. И что не менее важно - где он бесполезен: стратегические решения, работа с людьми, контекст и ответственность. В итоге ИИ усиливает сильных менеджеров, освобождая время на стратегию, но в руках слабых дает "уверенность в неверных решениях", поэтому автоматизация рутины должна сочетаться с критическим мышлением и проверкой исходных допущений.
🍑 Инструменты для проектного офиса, которые действительно работают
Что-то вроде "минимального комплекта" для проектного офиса от Teamly: умные таблицы как единый трекер (фильтры, группировки и т.д.), проектные шаблоны рабочих пространств для быстрого старта, бизнес-процессы как пошаговые инструкции, база знаний с встраиваемыми объектами и интерактивные доски/майнд-карты для совместного моделирования.
Ключевая мысль - исследовательские задачи и типовые живут в разных "вселенных" планирования. К первым неприменимы обычные оценки сроков, их надо таймбоксить (ок, выделять слот времени) и измерять рост уверенности, а вот ко вторым нужно применять декомпозицию, аналоги и статистику.
Практический шаблон юзкейсов от аналитика Okko. Есть два блока (акторы [точки входа] и сценарии), пошаговые "действие > результат", альтернативы и исключения. Автор сравнивает "табличные" и компактные форматы и показывает, как держать юзкейсы короче, но полезнее, не теряя важные ветки.
Автор разбирает, почему "доска ради доски" не заводится, и дает рабочую схему: сначала описать реальный процесс (колонки, приоритеты, кто и когда что делает), затем ввести простые и проверяемые правила, назначить "евангелиста" (тоже не любите это слово?) процесса, обеспечить прозрачность между отделами и быстрый доступ (десктоп+мобильное приложение), переводить общение в карточки задач и регулярно поощрять публично в самой системе. А главное - внимание к конкретике! Потому что фразы типа "в пятницу в 12:00 надо актуализировать приоритеты” повышают вовлеченность в разы и убирает иллюзию контроля через разноцветные карточки.
Кейс фаундера, который перестал верить словам про статусы (в активном поиске) и перешел к накопительной диаграмме потока (CFD). Теперь в слоях "Новые/В работе/На проверке/Готово" стало видно, где скапливаются узкие места, как "толстеют" сегменты и где работа замерла. И это позволило точечно найти причину бутылочного горлышка (в данном кейсе - тестирование), отследить зависания по отделам, перестать паниковать при технологических простоях и в итоге ускорить выполнение задач на 15–20% за счет регулярных пятничных разборов по цифрам, а не по ощущениям.
Этакая практическая памятка. Автор рекомендует выделить техдолг прямо в отдельный бэклог, приоритизировать и планировать его, проводить ретро, держать метрики (скорость, дефекты, время простоя), управлять ресурсами/экспертизой. Победить техдолг невозможно, но можно контролировать его масштаб и влияние на команду и продукт, чтобы вернуть предсказуемость и спокойный темп работы.
Автор показывает, где ИИ реально экономит время ПМ-а: черновики регламентов/ТЗ, структурирование хаотичных данных, поиск фактов, прототипирование, а также быстрые презентации. И что не менее важно - где он бесполезен: стратегические решения, работа с людьми, контекст и ответственность. В итоге ИИ усиливает сильных менеджеров, освобождая время на стратегию, но в руках слабых дает "уверенность в неверных решениях", поэтому автоматизация рутины должна сочетаться с критическим мышлением и проверкой исходных допущений.
Что-то вроде "минимального комплекта" для проектного офиса от Teamly: умные таблицы как единый трекер (фильтры, группировки и т.д.), проектные шаблоны рабочих пространств для быстрого старта, бизнес-процессы как пошаговые инструкции, база знаний с встраиваемыми объектами и интерактивные доски/майнд-карты для совместного моделирования.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2 2🔥1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😛 Менеджер проекта: карьера и навыки
😟 Три роли руководителя: Родитель, Ребенок, Взрослый
Автор адаптирует модель Эрика Берна к управлению: "Родитель" забирает ответственность и выращивает послушных исполнителей, "Ребенок" скидывает решения вниз и прячется от ответственности, "Взрослый" задает правила, делегирует и разделяет ответственность. Ключ к здоровой команде — чаще оставаться во "Взрослом" состоянии, иначе система скатывается в токсичность и ручное управление.
👓 Ошибки в управлении проектами начинающего проджект-менеджера
Собрание “граблей", среди которых размытый скоуп проекта, потерянный бюджет, излишне оптимистичные сроки. Рецепт — постоянное вовлечение заказчика, фиксация изменений и использование трехточечных оценок (и их аналогов) вместо "взяли на веру". Вывод - учиться лучше на чужих ошибках, но свои все равно неизбежны, поэтому важно быстро их распознавать и корректировать курс.
💃 Что делать, если нарвался на микроменеджера в команде
Кратко - понять его мотивацию (обычно это тревожность), заранее давать прозрачность по прогрессу, договариваться о фиксированных слотах отчетности и не "подкармливать" страхи хаотичными реакциями. В целом, не надо перевоспитывать систему, - вместо этого надо строить границы, а вот режим "микро" допустим только при реальном пожаре.
🦯 Обратная связь без боли: как давать фидбэк, который не демотивирует
О том, что фидбэк должен иметь цель (например, обучить/исправить/признать), опираться на наблюдаемое поведение, завершаться планом помощи - ну, и не забывать про своевременную похвалу как способ закрепить нужную модель. "Фидбэк ради фидбэка" — пустая трата времени, человек должен уходить с ощущением "знаю, что менять и где поддержка".
😃 Чему менеджеры могут научиться у разработчиков
Простые, но действенные уроки из инженерной культуры, в том числе "не задокументировал — не было", “автоматизируй повторы”, “проводи регулярный рефакторинг процессов”, “относись к ревью как к совместному улучшению, а не критике”. И еще вместо редких "перезапусков" — мелкие улучшения по принципу CI/CD-управления.
🧣 Наставничество со стороны руководителей проектов и направлений
О том, как выстроить систему, в которой руководитель-наставник будет ускорять онбординг, снижать текучесть и сохранять знания. В общем, что-то типа "Расскажи — Покажи — Сделай", плюс выделенное время, асинхронная коммуникация и забота о выгорании.
😐 "План любой ценой": почему российский менеджмент превратил работу в выживание и можно ли с этим бороться
Колонка о "постсоветском синдроме", который проявляется в культе героизма вместо процессов, микроменеджменте, приказном стиле, экономии на людях и двойных стандартах — все это ведет к выгоранию и слабым результатам. Противоядие — доверие, делегирование, обучение и ориентация на лояльность/качество, а не на авралы и показуху.
Автор адаптирует модель Эрика Берна к управлению: "Родитель" забирает ответственность и выращивает послушных исполнителей, "Ребенок" скидывает решения вниз и прячется от ответственности, "Взрослый" задает правила, делегирует и разделяет ответственность. Ключ к здоровой команде — чаще оставаться во "Взрослом" состоянии, иначе система скатывается в токсичность и ручное управление.
Собрание “граблей", среди которых размытый скоуп проекта, потерянный бюджет, излишне оптимистичные сроки. Рецепт — постоянное вовлечение заказчика, фиксация изменений и использование трехточечных оценок (и их аналогов) вместо "взяли на веру". Вывод - учиться лучше на чужих ошибках, но свои все равно неизбежны, поэтому важно быстро их распознавать и корректировать курс.
Кратко - понять его мотивацию (обычно это тревожность), заранее давать прозрачность по прогрессу, договариваться о фиксированных слотах отчетности и не "подкармливать" страхи хаотичными реакциями. В целом, не надо перевоспитывать систему, - вместо этого надо строить границы, а вот режим "микро" допустим только при реальном пожаре.
О том, что фидбэк должен иметь цель (например, обучить/исправить/признать), опираться на наблюдаемое поведение, завершаться планом помощи - ну, и не забывать про своевременную похвалу как способ закрепить нужную модель. "Фидбэк ради фидбэка" — пустая трата времени, человек должен уходить с ощущением "знаю, что менять и где поддержка".
Простые, но действенные уроки из инженерной культуры, в том числе "не задокументировал — не было", “автоматизируй повторы”, “проводи регулярный рефакторинг процессов”, “относись к ревью как к совместному улучшению, а не критике”. И еще вместо редких "перезапусков" — мелкие улучшения по принципу CI/CD-управления.
О том, как выстроить систему, в которой руководитель-наставник будет ускорять онбординг, снижать текучесть и сохранять знания. В общем, что-то типа "Расскажи — Покажи — Сделай", плюс выделенное время, асинхронная коммуникация и забота о выгорании.
Колонка о "постсоветском синдроме", который проявляется в культе героизма вместо процессов, микроменеджменте, приказном стиле, экономии на людях и двойных стандартах — все это ведет к выгоранию и слабым результатам. Противоядие — доверие, делегирование, обучение и ориентация на лояльность/качество, а не на авралы и показуху.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2 2 1