Проектный дайджест
описание
🔧 Управление проектами без буллшита 📌 Инструменты, кейсы, разборы — всё, чтобы быть менеджером, которому не стыдно смотреть в зеркало 🤝 По рекламе - https://mugs-fly-f31.craft.me/8lslXivoJv34nh
1 410
подписчиков
Охват к подписчикам
52,7%
ERR
Реакции к просмотрам
1,22%
210 на 23 постов
Пересылки к просмотрам
1,05%
180
Постов в день
0,1
всего 23
Где отзываются чаще
доля реакций к просмотрам- 16 авг.без подписи4,76%
- 22 авг. 2024 г.#Прочитал “Практическое руководство ИТ лидера” Раду Спатару. Искал интересные новинки по управлению проектами - и нашел эту книгу. Издана в цифре буквально летом, описание и содержание - в точку, да и сама книга рассказывает про управление IT-трансформацией, формировании IT-культуры в организации, управление проектами,но… 😐 Судя по всему, это перевод англоязычной книги, изданной самим автором на Амазоне в марте 2024 (причем это третье издание, а второе вышло в феврале😁). Перевод выложили на Литрес, при этом инфо о переводчике нет, а на отзывы о книге отвечает якобы сам автор (!). 😐Информации об авторе крайне мало, и даже показалось, что это нейросеть, но, похоже, это реальный человек, имеющий отношение к проджект-менеджменту, - вот его профиль в линкедине и PMI. Теперь о книге: Достоинства: 🟢Книга кратко (193 стр.) рассказывает о комплексе задач и процессов, с которыми может столкнуться IT-менеджер/лидер/директор/руководитель, от знакомства с текущим ИТ-ландшафтом в организации и формирования стратегии изменений и до управления проектами и использования AI. 🟢Большое количество “примеров из жизни” 🟢 Много чек-листов и других инструментов самопроверки. Недостатки: 🚫 Минималистичный объем для такого предмета - это “галопом по Европам”. Увы, ни одна из тем не получает нужного освещения, и получается такой “карманный справочник”, к которому вряд ли захочется вернуться, если только вы не студент. Весь текст выглядит как реферат, набор общеизвестных принципов, собранных в одном месте. 🚫 Ужасный перевод, в худших традициях “промпта”: множество опечаток и ошибок, корявый синтаксис, суконный язык. 🚫 Часть терминов, диаграмм и таблиц осталась без перевода с английского. В целом, не рекомендую эту книгу никому - разве что вы захотите найти негативный ("как-не-надо") пример профессиональной литературы. Если тема “ИТ-менеджмента” вам интересна, лучше почитайте недавний перевод “Карьера Software Engineering Manager”.2,64%
- 12 июл.🔥 Заждались? С вами снова самые интересные материалы по управлению проектами за 2 недели 1/2 🔫 Великая иллюзия Agile: как индустрия променяла инженерную науку на средневековый эмпиризм Тадам - и снова у нас радикальная критика Agile. Автор обвиняет индустрию в мнимой победе: классическая инженерия якобы вовсе не требовала двигаться строго по «водопаду» и давно использовала итерации. А вот проблемы аджайл принес - подменил системное проектирование короткими циклами, ритуалами, надеждой, что архитектура как-нибудь возникнет по дороге. В итоге получаем лоскутность. Текст местами сгущает краски, зато интересный. 🤨 От хаоса к системе: как мы выстроили процесс Discovery (часть 2) Как превратить подготовку требований из "шаманства" отдельных аналитиков в воспроизводимый процесс. Задача проходит преданализ, оформление постановки по шаблону, рецензирование, согласование с бизнесом и техническим руководителем, проверку тестировщиком и только затем попадает на общее обсуждение команды. Главное (хоть и банально) - не жалейте время и деньги на предпроектную работу. 😱 Внедрили Scrum, но Agile так и не случился. Почему? Эссе о том, почему установка доски, проведение ретроспектив и переименование совещаний не превращают компанию в гибкую. Коротко - из-за культуры. Там, где решения по-прежнему принимает начальник, а ошибка воспринимается как повод найти виноватого, самоорганизация обычно остаётся красивой витриной. Поэтому начинать внедрение стоит не с выбора модного фреймворка, а с диагностики управленческой среды и ее подходимости для нововведений. 😢 Как считать экономическую эффективность внедрения ИТ-решений. Переводим функционал в деньги “А сколько мы на этом заработаем?” - страшный вопрос от бизнеса) Вот автор и предлагает двигаться от решения к конкретным изменениям бизнес-показателей (снижению простоев, затрат, аварийности или продолжительности операций), а затем переводить их в денежный эффект. Полезный материал для подготовки обоснований проектов перед собственником. 😔 IT-шная конфликтология или как заказчик всегда прав О том, почему техническая правота сама по себе редко помогает выиграть спор с заказчиком. Кратко - бизнес оценивает сроки и риски не по сложности кода, а по тому, насколько понятно специалист объяснил последствия, ограничения и стоимость решения. Поэтому автор советует говорить на языке целей заказчика, фиксировать договоренности, заранее описывать неблагоприятные сценарии и привлекать коллег, когда собственных аргументов недостаточно. 😁 Книга среднего уровня — 2. Перфекционизм руководителя Классный текст про отказ от желания, чтобы вся команда делала одновременно всё и идеально. То, что помогало хорошему специалисту выделяться, на управленческой должности превращается в источник задержек у подчиненных. Доведение вообще каждого результата до совершенства хорошо съедает ресурсы, хотя часто достаточно просто качественно выполненной работы в разумный срок. 😧 RICE, ICE, MoSCoW: когда фреймворк приоритизации вас топит Про то, что все эти ваши фреймворки не панацея, а даже наоборот. RICE перемножает несколько субъективных оценок и выдаёт якобы убедительное число, ICE особенно легко ломается на разном понимании сложности, а в MoSCoW все интересанты быстро объявляют свои задачи обязательными - и всё, конец. Решение - да, надо использовать приоритезацию, но и включать голову при принятии решения. (И ответственность брать на себя, а не сваливать на инструмент) 😘 Мягкая сила в жестких дедлайнах: 7 принципов влияния для PM и тимлидов Если слышали про принципы Роберта Чалдини про влияние в маркетинге, то вот они, но в проектах. Взаимность, последовательность, социальное доказательство, авторитет, симпатия, дефицит, единство и прочее. Что-то у автора выглядит здраво, а что-то уже на грани манипуляций (с) - например намеренно начинать переговоры с завышенного срока или формировать у сотрудника чувство долга. Но и это интересно почитать, чтобы в такое не вляпаться)2,47%
- 7 авг.без подписи2,45%
- 26 июл.без подписи2,42%
- 9 апр.🔥 Самые интересные материалы по управлению проектами за 2 недели 💻Основы, гайды и инструменты 📢 У проекта шесть параметров и все важны. Проектный тетраэдр, а не треугольник Попытка расширить классический проектный треугольник. Вместо трёх классических параметров (срок, бюджет, объём) автор предлагает смотреть сразу на шесть: добавляются качество, риски и ценность. В реальных проектах провал почти никогда не выглядит как «не уложились только в срок», потому что при давлении по срокам и деньгам почти всегда жертвуют качеством, полезностью результата и уровнем принимаемых рисков. 🏐 Документальное сопровождение создания ИТ-продуктов в рамках выполнения ИТ-проектов Академично-практический текст про то, как вообще выстраивать комплект проектной документации при создании ИТ-продуктов. Автор исходит из того, что национальные стандарты задают рамку, но не жёстко диктуют единственный набор документов, поэтому состав проектной документации должен определяться контекстом, заинтересованными сторонами, стилем управления и ресурсами. Текст не сводит всё к культу ГОСТов, а пытается собрать более осмысленную структуру документального сопровождения, пригодную для реальной проектной практики. 🟢 Гибкость важнее функций: как за неделю мы адаптировали систему для Waterfall-проектов под Agile Понятный и прикладной кейс про то, что главная проблема многих систем управления проектами — не отсутствие нужной галочки в чек-листе, а негибкость, из-за которой процессы приходится ломать под инструмент. Сначала покупают одну систему для классических проектов, потом вторую для Agile-команд, потом третью для ещё одного сценария — и в итоге получают лишние лицензии, ручное сведение данных и вечный рассинхрон. Авторы предлагают свой подход и продукт, позволяющий пересобрать текущую систему под новые процессы, вплоть до добавления сущности спринта, отдельных представлений и Scrum-доски. ➡️ От хаоса к гармонии: роль ИИ-ассистента в проектной трансформации Как AI-ассистент может стать не просто игрушкой для генерации текста, а инструментом наведения порядка в проектной среде. В целом, это скорее туториал и кейс о применении ИИ в проектной трансформации,который показывает конкретную роль помощника в документообороте, коммуникациях, поиске знаний и снижении ручной рутины — именно там, где проектные процессы чаще всего расползаются в хаос. 🐈⬛ SAFe, платформенные команды и ИИ в разработке: как устроен IT в MANGO OFFICE Хороший разбор организационного устройства крупной IT-функции через призму SAFe, платформенных команд и роли ИИ в разработке. Статья не ограничивается ритуальным «мы внедрили SAFe и стали счастливы», а прямо проговаривает, зачем он понадобился: водопад мешал быстро выпускать фичи и видеть реальный прогресс, а компании нужен был единый сквозной фреймворк. Плюс авторы не замалчивают шероховатости: роли Product Manager, Product Owner и системного архитектора на стыках действительно могут давать зазоры ответственности, где терялись задачи. ☁️ Как на самом деле запускаются изменения в компании О том, что запуск изменений почти никогда не сводится к объявлению «с понедельника работаем по-новому». Сначала нужно сознательно поднять внимание к теме, потом не дать стартовой энергии раствориться в операционке, а затем перевести изменения в регулярный управленческий контур — через цели, метрики и повторяемые коммуникации. В общем, изменения состоялись не тогда, когда про них много говорят, а когда они перестают называться изменениями и становятся просто нормальным способом работы. 🔔 Зачем нужны нефункциональные требования к ПО и откуда их взять Полезный базовый текст про ту часть требований, которую все признают важной, но регулярно оставляют на потом. ФТ отвечают на вопрос «что делает система», а НФТ — «как, когда, где и с какими качественными характеристиками она это делает», причем именно они во многом определяют архитектуру, эксплуатацию и размер будущих затрат. Если НФТ не записаны, они всё равно существуют, просто живут в головах нескольких людей и становятся источником потери знаний и будущих проблем.1,98%
- 14 июл.🔥Самые интересные материалы по управлению проектами за 2 недели 2/2 😪Какие книги помогли мне перестать «тушить пожары» и начать управлять командой? Небольшая подборка управленческой литературы, составленная инженером, которому пришлось учиться руководить уже по ходу работы. О книгах Тома Демарко, Патрика Ленсиони и других - и как они помогли ему разобраться с конфликтами, доверием, ответственностью и постоянным режимом аврала, причем все на реальных ситуациях. 😑МВА на минималках «Модель Айсберг для определения типа сотрудников в команде» Предельно простая типология сотрудников, основанная всего на двух показателях: сколько человек обещает и сколько в итоге делает. В итоге четыре типа — от громкого имитатора деятельности до незаметного сотрудника, который систематически выдает больше обещанного. Модель интересна еще и тем, что диагностирует руководителя: например, почему сильный специалист предпочитает молчать о своей работе. 🤪PMBOK Guide 8: в 2 раза меньше принципов и больше свободы Обзор восьмой редакции PMBOK как отхода от представления об управлении проектами как о наборе обязательных процессов и шаблонов. Количество принципов сократилось, основное внимание сместилось к созданию ценности, адаптации подхода под конкретную ситуацию, ответственности руководителя за осмысленный выбор методов. Стандарт старается примирить все модели, не объявляя ни одну из них правильной по умолчанию. 😪Ваши постмортемы — это поминки. И добрая половина процессов в компании тоже Текст разделяет организационные процессы на (1) инструменты, которые меняют реальность, и (2) символические ритуалы, которые лишь создают ощущение контроля. Среди второго и постмортем, после которого никто не меняет настройки, приоритеты или правила работы. Его роль часто сводится совсем не к предотвращению следующей аварии, а к коллективному переживанию предыдущей. В общем, кроме поминок, нужно проследить, что именно стало иначе после выполнения процесса. 😢Вы прочитали ТЗ. Теперь прочитайте его еще раз О том, почему недостаточно буквально выполнить написанное в техническом задании. Да потому что требования почти неизбежно содержат пробелы, неявные предположения и внутренние противоречия, а маленькая просьба “добавить кнопку” быстро обрастает много чем. Автор предлагает проверять, помимо формулировки задачи, еще и пользовательский сценарий, бизнес-цель, граничные случаи, последствия изменений и связь с остальной системой. 😶Ретро: Не Ной Слабо, Ной Достойно. Как Превратить Жалобы в Профит Типа кейс превращения ретроспективы из регулярной комнаты ярости в рабочий инструмент улучшения процессов. Сначала команда раз в две недели пыталась вспомнить всё, что её раздражало, выпускала пар и возвращалась к тем же проблемам. А потом… Ситуацию изменили единое пространство для фиксации наблюдений и обязательное превращение жалоб в конкретные действия. Жалобы важны, но польза и ценность появляются только тогда, когда за ними удаётся найти наблюдаемый факт и проверяемое изменение. 🥺Профессия «погоняла» теряет смысл: 80% менеджеров пойдут лесом Провокационный прогноз о нашем (?) будущем в мире ИИ. Под угрозой - руководители-передатчики, которые распределяют задачи сверху вниз и собирают статусы снизу вверх. Теперь это автоматизируется, а небольшие команды специалистов, усиленных агентами, смогут выполнять без передастов. Но все не так мрачно - постановка целей, разрешение противоречий, принятие решений, развитие людей и ответственность за систему по-прежнему нужны. 😈Закон Брукса: почему нанять ещё людей — худшее решение, когда проект горит Ликбез по закону - добавление людей в уже опаздывающий программный проект часто не ускоряет, а ещё сильнее задерживает его. Новичков нужно вводить в контекст, обучать и подключать к коммуникациям, соответственно, опытные начинают тратить на это время. Ну и не каждую задачу можно разделить между исполнителями. Это не значит, что расширять команды бессмысленно, но вот в момент кризиса найм часто служит психологически удобной заменой более трудным решениям.1,60%
- 11 мар.🔥 Самые интересные материалы по управлению проектами за 2 недели 😐 Менеджер проекта - карьера и навыки 😛 Создатели, менеджеры и люди процесса. Кто на самом деле двигает продукт Автор делит участников продуктовой организации на три группы: создатели делают продукт руками и головой, менеджеры растят и усиливают этих людей, а "люди процесса" отвечают за ритуалы, стандарты и фреймворки. Главная мысль в том, что процесс сам по себе не зло, но в больших компаниях он слишком легко превращается в самоцель и начинает жить отдельной жизнью, подменяя лидерство и ответственность формальными правилами. 🙌 ИИ не делает вас лучше как лидера. Зато сэкономит часы на рутине - опыт 4 руководителей Kaiten собрал практические кейсы четырех руководителей и показывает интересную картину: ИИ сильнее всего помогает не в стратегии и лидерстве, а в рутине - отчетах, метриках, протоколах встреч, инструкциях, резюме интервью и предварительном анализе данных из таск-трекеров. Освобожденное время можно направить на управленческое мышление, но сами решения, приоритеты и интерпретации никто с человека не снимает. ✨ Почему жесткий тайм-менеджмент больше не работает Текст критикует тотальный таймбоксинг, когда весь день нарезан на плотные слоты без воздуха и запаса, и объясняет, почему такой подход так соблазнителен: мозг любит иллюзию контроля и награждает нас уже на этапе красивого планирования. В статье это названо "дофаминовым авансом" - ощущением, будто работа уже сделана, хотя реально мы всего лишь аккуратно заполнили календарь. В итоге жесткий тайм-менеджмент нередко становится легализованной прокрастинацией: человек чувствует себя организованным, но при первом же отклонении реальности начинает сыпаться и терять не только план, но и ощущение управляемости. 🧐 Уволить 40% штата из-за ИИ: как плохой менеджмент прячут за красивыми технологиями Статья разбирает "ИИ-камуфляж" - ситуацию, когда массовые сокращения оправдывают технологиями, хотя на деле речь идет о старом добром управленческом решении, упакованном в модную риторику. Автор не отрицает силу ИИ как инструмента, но настаивает: одно дело - использовать модели как помощников, и совсем другое - прикрывать ими увольнение значительной части штата, будто технология уже сама по себе оправдывает такие шаги. 🔫 Я следил, чтобы команда не выгорела. Выгорел сам Выстраданный текст о том, как перфекционизм и привычка держать все под контролем не исчезают при переходе из разработки в менеджмент, а просто находят новую форму: процессы, коммуникации, онбординг, ретроспективы, формулировки задач, встречи 1-1. Хороший менеджер действительно должен заботиться о понятности, ритме и качестве работы команды, но если не понять, где можно ослабить контроль, эта забота начинает пожирать самого руководителя. в целом, менеджерское выгорание часто рождается не из безразличия, а как раз из гиперответственности и постоянной внутренней проверки, "достаточно ли хорошо все устроено". 😃 ИТ-лидер в финтехе: не менеджер, а "операционный центр" кросс-функциональной команды Т1 описывает роль ИТ-лидера в финтехе как точку пересечения двух вертикалей - технологической и бизнесовой, где нужно одновременно удерживать сроки, качество и ресурсы. Те самые стримы и кросс-функциональные команды - это попытка совместить скорость продуктовой разработки, требования регулятора и высокую цену ошибок. Поэтому ИТ-лидер здесь не сводится ни к Scrum Master, ни к техлиду, ни к проектному менеджеру в чистом виде: его задача - превращать амбициозные бизнес-идеи в реалистичный поток поставки, не позволяя ни бизнесу "перегреть" команду, ни разработке уйти в бесконечный рефакторинг.1,58%
- 7 мая🔥 Самые интересные материалы по управлению проектами за 2 недели 🤣 Менеджер проекта - карьера и навыки 😵💫 Я "нанял" AI-команду разработки и управлял ею через Kanban: опыт на реальном продукте Очень любопытный и приземленный кейс про управление не "одним умным чатиком", а целым конвейером AI-агентов как проектной командой. Автор строит вокруг агентов полноценный пайплайн (бэклог, исследование задачи, спецификацию, реализацию, верификацию и тд). При этом с ростом доли AI ценность процесса не падает, а наоборот растет, потому что предоставленный себе агент очень быстро начинает производить хаос вместо результата. 🤢Трудности перевода: как мы назначили контрибьютора тимлидом и чему это нас научило Хороший ретроспективный текст о переходе от плоского управления к более структурированной модели, где внутри растущей команды приходится выделять тимлидов. Речь идет не про формальное повышение "самого сильного инженера", а про более тонкий и рискованный переход: когда у человека есть экспертность и влияние как контрибьютора, но роль тимлида требует уже другой логики - фокусировки, координации и управленческого перевода между уровнями системы.. 🏠 50 оттенков порока: за что команды ненавидят тимлидов О типовых лидерских грехах, которые команды считывают особенно остро: микроменеджмент, лицемерие, манипуляции, плохая обратная связь и ощущение непогрешимости руководителя. Статья строится вокруг реального разговора лидов о том, где заканчивается управление и начинается давление, чем манипуляция отличается от шантажа и почему даже хорошие намерения быстро портятся без саморефлексии. ⛔️ Манипуляции в жизни ИТ менеджера В команде всегда есть отношения, а значит, всегда есть и попытки влиять друг на друга не только через формальные роли и рациональные аргументы. Автор не идеализирует рабочую среду и предлагает смотреть на управленческую жизнь без наивности: начальники могут давить, исполнители - молча соглашаться на невыполнимое, а вся система - производить выгорание под видом "надо собраться". Нужно распознавать подобные механики, не растворяться в них и сохранять рабочую эффективность и собственные границы. 👍 Управление тимлидами: не контроль, а системное лидерство Управление несколькими тимлидами - это принципиально другая задача, чем управление отдельными разработчиками. И автор описывает типичный провал первого уровня: кажется, что опытные лиды "и так все знают", а на практике руководитель быстро превращается в бутылочное горлышко, на котором замыкаются решения, а вокруг начинает разрастаться микроменеджмент. Поэтому на уровне управления лидами нужно уже не операционно контролировать людей, а выстраивать систему лидерства, где работает распределение ответственности, зрелость решений и самостоятельность без потери общего направления. 😎 Кризис "переходного" возраста в управлении проектами: история преодоления Рефлексивный текст о профессиональном кризисе, который приходит не от неуспеха, а как раз после внешне успешного достижения цели. Роль РП получена, ожидания общества и компании выполнены, а вместо удовлетворения приходит апатия, снижение энергии и потеря интереса к работе. Все потому, что управленческая роль может съедать смысл, если человек не успевает переосмыслить, зачем он вообще в ней находится. И текст как раз про внутреннюю цену карьерного перехода и необходимость заново собрать себя уже после достижения "правильной" цели.1,56%
- 9 мар.🔥 Самые интересные материалы по управлению проектами за 2 недели 🙏Команда проекта 🌚 Новая норма ИТ-команд: недоговаривать Автор описывает распространенную проблему «дефицита внимания» как, увы, скрытую норму рабочих отношений. Руководители недообъясняют, коллеги достраивают смысл сами, а команда тратит силы уже не на решение задачи, а на интерпретацию того, «что на самом деле имелось в виду». В итоге информационный вакуум быстро превращается в демотивацию, подозрения и токсик-вайб. Причем всё это особо не поменять - недосказанность в командах никуда не денется, поэтому сотруднику важно уметь распознавать этот вакуум. 🌞 Ричард Гельдрейх из Valve о работе в геймдеве и корпоративной культуре Если вы, как и я, мечтали работать в компаниях а-ля Вальв, то вот можно почитать этот перевод откровенного текста Ричарда Гельдрейха о «самоорганизующихся» компаниях, где внешняя свобода и культ гениальности легко маскируют внутренние игры, манипуляции и неочевидные механизмы власти. Надо быть осторожнее с корпоративным маркетингом, не раскрывать работодателю лишнюю личную информацию и не путать красивый образ компании с качеством среды. Потому что за фасадом «плоской структуры» может скрываться не взрослая автономия, а довольно токсичная борьба без явных правил и ответственности. 🌞 «Прикинься шлангом и не высовывайся»: главное правило работы в системе О столкновении молодого, инициативного сотрудника с системой, где старание, инициативность и желание делать лучше далеко не всегда ведут к признанию или росту. В жестко иерархичных структурах выживает не тот, кто работает сильнее, а тот, кто лучше понимает негласные правила и умеет не раздражать систему лишней заметностью. 🌚 Как за неделю собрать курс для отдела поддержки по базе знаний компании У многих компаний уже есть всё нужное для быстрого обучения - статьи в базе знаний, рабочие инструкции, CRM или клиентская система, - но нет упакованного курса. Статья как раз о том, как превратить существующий контент в учебный контур без долгой методической стройки: взять готовые статьи, связать их в последовательность, добавить тесты, дедлайны, статусы прохождения и получить рабочий онбординг почти без переписывания материалов. 🌚 Почему Крош становится тимлидом, а Нюша выгорает: психология привязанности в ИТ-командах (Специально для фанатов) Автор переносит теорию типов привязанности в профессиональную среду и показывает, как эмоциональная устойчивость, реакция на фидбек, отношение к дистанции и потребность в одобрении влияют на карьеру в ИТ едва ли не сильнее, чем техническая глубина. Надёжный тип легче выдерживает обратную связь, конфликты и рост ответственности, поэтому чаще естественно дорастает до лидских ролей; тревожный и избегающий типы по-разному уязвимы к перегрузке, неопределенности и выгоранию. Короче, не все проблемы сотрудников решаются советом «будь увереннее», потому что за их рабочим поведением часто стоит более глубокий эмоциональный паттерн. 👁 Как давление ожиданий ломает коммуникации в команде О том, как высокие стандарты незаметно переходят в токсичную перфекционистскую культуру: люди перестают задавать вопросы, боятся озвучивать риски и смягчают формулировки до такой степени, что важная информация теряет остроту и смысл. У процесса несколько фаз - от культа безупречного результата до самоцензуры и страха ошибки. В итоге команда вроде бы остаётся профессиональной и собранной, но на деле всё больше молчит о проблемах, а значит, снижает собственную способность исправлять курс вовремя. 😔 Системный аналитик в эпоху ChatGPT: эволюция или революция Одна из самых практичных статей в подборке: автор не спорит, заменит ли ИИ аналитика (гм…), а прямо показывает, что именно модели уже умеют делать хорошо - черновики требований, user stories, структурирование интервью, поиск противоречий, прототипы диаграмм и API-описаний. Но главный тезис не в автоматизации, а в смещении роли: аналитик всё меньше “писатель документов” и всё больше редактор, валидатор, синтезатор контекста и проектировщик процессов в команде.1,51%
- 28 мар.🔥 Самые интересные материалы по управлению проектами за 2 недели 😐 Основы, гайды и инструменты 😵 Простые хлопоты: когда проекту действительно нужно управление Концептуальная статья о том, что управленческие действия в проектах слишком часто происходят по ритуалу, а не по реальной необходимости. Автор предлагает метафору «температуры» — уровня накопленной неопределённости, которая растёт по мере появления дефектов, задержек, искажений понимания и других скрытых потерь. Дальше строится упрощённая модель, в которой вмешательства менеджмента рассматриваются как способ «охлаждать» проект, когда неопределённость становится опасной. 😏 Что такое канбан на практике: изучаем доски, WIP-лимиты и метрики Хороший базовый разбор канбана для тех, кто до сих пор считает, что канбан — это просто доска с колонками и карточками. А это прежде всего способ управлять потоком работы. В статье есть исторический заход от Toyota к адаптации подхода в разработке ПО, а затем разбор ключевых элементов: доска, карточки, колонки, сигналы проблем, ограничения WIP и метрики потока. Для опытных людей здесь вряд ли будет откровение, но как вводный и одновременно «отрезвляющий» материал — вполне удачно. 🦶 От стратегии до проектов: для чего бизнесу переходить к портфельному управлению Про портфельное управление - оно нужно не потому, что звучит солидно, а потому, что инициатив становится слишком много, а денег и людей - слишком мало. Схема такая: собрать единый реестр инициатив, зафиксировать бюджеты, сроки, риски и владельцев, а потом принимать инвестиционные и приоритизационные решения на общей картине. Отдельно полезен блок о признаках, когда портфель у компании уже де-факто есть, просто он не управляется. 😨 Как я запилил свой Scrum Poker, потому что все остальные — отстой Живой и немного хулиганский текст из серии «меня достали плохие инструменты, поэтому я собрал свой». Автор начинает с боли планинг-покера (лаги, тяжёлые решения, зависимость от Jira и отсутствие нужных функций), а затем показывает, каким сделал свой сервис. Из фич — удобное управление сессиями, автоматический расчёт среднего и архитектура с быстрым стартом и минимумом инфраструктурной возни. 😈 Как плохое ТЗ может удвоить стоимость проекта Здесь тезис максимально прямой: длинное и подробное ТЗ не только не гарантирует успех, но часто создает ложное чувство определенности и толкает команду к избыточной разработке. Автор критикует привычку описывать заранее решение, а не пользовательскую проблему, и показывает, как это ведет к раздутому объему функциональности, сроков и бюджета. Предлагается более лёгкий подход: минимальный набор требований, фокус на потребностях пользователя, user story, критерии приёмки и постепенная детализация по ходу работы. 😢 Никого не повышают за простые решения О перекосе, который знаком почти любой команде: сложные решения выглядят «впечатляюще», а простые — как будто слишком банальны, чтобы считать их достижением. Во многих компаниях сотрудники бессознательно получают больше признания за архитектурную навороченность, чем за элегантное решение, которое быстрее внедряется, легче поддерживается и лучше переживает будущее. 😔 Юридическая гигиена ИТ-проектов или как отстоять код, деньги и нервы Для тех, кто привык считать договор чем-то вторичным по сравнению с требованиями и сроками. Разработка софта почти всегда требует смешанной договорной конструкции, потому что здесь переплетаются подряд, НИОКР и вопросы лицензирования или отчуждения прав. Дальше акцент смещается на ТЗ как часть договора. 🙂Как правильно оформлять РИДы в ИТ-проектах, чтобы не создавать спорных ситуаций Хороший разбор темы, которую в проектах часто упрощают до формулы «всё, что сделали, автоматически наше». На практике статья показывает, что с результатами интеллектуальной деятельности всё тоньше: нужно смотреть, где был реальный творческий вклад исполнителя, а где — просто использование готовых инструментов, библиотек, UI-китов или материалов по лицензии.1,45%
- 14 мар.🔥 Самые интересные материалы по управлению проектами за 2 недели 🤗Основы, гайды, кейсы 🚬PMBOK 8. Что изменилось? Автор делает обзор ожидаемых изменений в PMBOK 8 и показывает, что развитие стандарта все дальше уходит от жестких "процессных списков" к более гибкому, принципиальному и контекстному взгляду на управление проектами. В центре внимания - не только артефакты и процедуры, но и адаптация подхода под среду, работу с ценностью, неопределенностью и реальными потребностями команды и организации. 🥺 Матрица Эйзенхауэра в корпоративной системе: почему не работает и что делать О том, почему популярная личная техника приоритизации часто ломается в корпоративной среде. Кратко - потому что задачи в компании редко принадлежат одному человеку, срочность и важность зависят от контекста команды, а квадраты быстро начинают противоречить реальной системе зависимостей и обязательств. Тем не менее матрица - это тема, но надо опираться на более прозрачные правила приоритета, владельцев решений и наблюдаемые критерии. 👍 Системы управления ИТ-проектами: подборка российских решений 2026 Ииииии очередной обзор российского ландшафта систем управления проектами. В этот раз с упором на то, что выбирать инструмент нужно по зрелости процессов, требованиям к безопасности, гибкости настройки, интеграциям и масштабу команды. В главных ролях: SimpleOne SDLC, Битрикс24, ADVANTA, Kaiten, Weeek, YouGile и другие. 😎 Зачем командам разработки и QA концепция DoR и DoD, и как не превратить ее в бюрократию Три аббревиатуры в названии - это про сущности, которые часто смешивают: критерии приемки отвечают на вопрос, что именно должно уметь решение, а DoR и DoD - в каком состоянии задача может войти в работу и считаться завершенной. Польза от DoR/DoD - синхронизации ожиданий между аналитиками, разработкой, тестированием и бизнесом. 🥺 Петля на шее: почему фидбек душит проект и как это остановить О ситуации, когда обратная связь из полезного инструмента превращается в бесконечный тормоз (узнали? согласны?). Замечаний становится слишком много, а еще и поступают они слишком поздно, не имеют общего приоритета и фактически не помогают двигаться к результату. Ну и проект начинает задыхаться - команда все время что-то дорабатывает, но ощущение прогресса исчезает. 😰 Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось В целом-то понятно, как: размытые цели, постоянные переносы, скрытые проблемы, разрыв между формальным статусом и реальным положением дел, потеря доверия между участниками. Статья предлагает и антикризисную логику действий: быстро собрать факты, пересобрать картину рисков, вернуть прозрачную коммуникацию, сократить хаос в приоритетах и зафиксировать реалистичный маршрут выхода из провала. 🥰 Почему проваливаются проекты? 5 столпов, на которых держится успех “Магнит” раскладывает успешный проект не на “магические качества сильного РП”, а на набор опор: понятная цель, работа с ожиданиями, прозрачная коммуникация, дисциплина исполнения и способность адаптироваться по мере изменений. Когда одна из этих опор проседает, проект еще может выглядеть живым, но начинает разрушаться изнутри - через конфликт интерпретаций, потерю доверия, накопление скрытых проблем и т.д. 🥺 Техническое задание – что это и для кого Текст возвращает ТЗ к его базовой функции: это договоренность между участниками о том, что именно создается, в каких границах, с какими условиями и по каким критериям можно понять, что работа выполнена правильно. ТЗ нужно разным людям по-разному: заказчику - чтобы зафиксировать ожидания, исполнителю - чтобы понимать объем и ограничения, тестированию - чтобы проверять результат, а менеджменту - чтобы управлять сроками и рисками.1,41%