Если вы каким-то чудом еще не познакомились с agile, то эта публикация - отличный способ войти в мир гибких методологий. Вы узнаете про Agile-манифест, про распространенные сферы применения, про подходящие типы команд, преимущества и недостатки, про инструменты (канбан, скрам, XP, Crystal). Отдельный блок - про то, как начать использовать Agile в вашей команде и как решать возникающие проблемы. Рекомендую!
HADI-цикл - это часть методологии Agile, которая предполагает разбивку проекта на этапы планирования, реализации и оценки промежуточных результатов. Материал кратко рассказывает о концепции HADI, ее плюсах и минусах и ошибках на пути к реализации.
PERT-диаграмма — инструмент визуализации планов по проекту. Она нужна для согласованности связанных и несвязанных этапов проекта, для планирования масштабных и многозадачных проектов, которым требуется много ресурсов — времени, сотрудников, знаний, и чем-то похожа на диаграмму Гантта.
Правильно определенные метрики на этапе проработки требований и при необходимости их уточнение после внедрения, выгодны как заказчику, так и команде разработки. Это позволяет создать востребованный и удобный продукт, показывает необходимость мониторинга показателей приживаемости.
Отличный и емкий сборник рекомендаций по сбору требований, которые повысят успех такой встречи, - от подготовки (анализ аудитории, прогнозы, определение цели и повестки) к проведению и подготовке мемо (договоренности по итогам встречи, со сроками и ответственными).
Практические рекомендации по улучшению процесса постановки и ведения задач: каким должно быть описание задачи, чем помогают шаблоны (и автор делится своими шаблонами), как вести задачи, чтобы они не “протухали”.
В центре внимания - подготовка бэклога в соответствии с критериями готовности (DoR), формирование общего представления о цели спринта, создание планов реализации.
Статья ценна не только изложением основ “сторипойнтов” и методики Planning Poker, но и демонстрацией тех ошибок, которые можно допустить при переходе на такой формат оценки задач.
Для каждого проекта есть ограниченное количество времени и ресурсов. По мере развертывания проектов вы можете столкнуться с трудностями и неожиданными событиями, которые заставят вас пересмотреть распределение ресурсов и внести изменения в график проекта.
Про вертикальное и горизонтальное управление проектами - два подхода, учитывающие различные организационные потребности и требования проекта. Вертикальный - для команд, где решающее значение имеет иерархия, постановка задач и сроков “сверху вниз”. Горизонтальный - “плоский” кросс-функциональный подход, когда постановка задач, как и вся коммуникация, происходят на одном и том же уровне.
Зная, какие вопросы по управлению проектами задавать, вы можете быть проактивны в запросе информации, необходимой для обеспечения того, чтобы проект развивался в соответствии с планом. Примеры вопросов: “Кто наш клиент и чего мы пытаемся ему помочь достичь?”, “Кто наши заинтересованные стороны и какова их роль в проекте?”, Каков наш базовый бюджет?”, “Есть ли у нас навыки и ресурсы, которые могут помочь нам в этом проекте?”.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2✍1
Шикарный текст от PM из Ланита. Общая тема - как построить и перестроить свою жизнь и рабочие процессы, если вы стали менеджером проекта. Из рекомендаций: начать нужно с самоопределения “я - руководитель”, даже если у вас нет опыта и нет полного понимания процессов. Не менее важно - развивать в себе навыки коммуникации, навыки планирования и ряд других компетенций. Рекомендую материал!
Тоже советы и рекомендации тем, кто только входит в роль проджекта или менеджера. Главное: приоритезация, личные встречи и неформальные коммуникации с коллегами, разработка индивидуальных планов, анализ рисков при принятии решений и много другого.
Про основные столпы подготовки IT-менеджеров. В их числе автор видит системную теоретическую подготовку, практику менеджмента, личный опыт. При этом в менеджменте нет серебряных пуль, и каждый случай индивидуален. Решение, подошедшее одному управленцу, не факт, что подойдет другому. Слишком разные контексты, составы команд и ситуации.
Когда вы вступаете в должность в качестве руководителя или старшего менеджера проекта, одной из первых и самых важных задач является понимание текущих процессов управления проектами. Этот процесс, часто называемый аудитом, позволяет определить точку «As Is…» — текущее состояние дел в компании. Без четкого понимания текущей ситуации невозможно разработать эффективный план действий и начать внедрение улучшений.
Статья для тех руководителей проектов, кто сталкивался с "граблями" и двойными стандартами в управлении проектов и для тех, кто хочет об этом узнать больше - преодолевать барьеры взаимодействия с неадекватными заказчиками, токсичными стейкхолдерами, "двойными стандартами" руководства, "царственной отрешенностью" безопасников и саботажем ключевых пользователей.
Что делать, если сроки срываются, а вы не виноваты? Что делать, если заказчик требует невозможного, а сказать «нет» нельзя? Что делать, если вы чувствуете, что вы везде крайний, а никаких инструментов повлиять на ситуацию у вас нет? Ничего этого нет в PMBoK или Agile Manifest. Как сделать действительно качественный продукт, как принести прибыль компании, а себе заработать денег, вас не научат на курсах владения MS Project.
В чем разница между “таск-менеджером” и “менеджером проектов” и что нужно сделать, чтобы управление проектами ценилось за его стратегические преимущества и добавленную стоимость в вашей организации.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤1⚡1
☝️ «Часть Команды — часть Корабля». Или почему негативные роли должны быть в каждой команде
Хорошая тема в контексте обсуждений “токсичности” и “аутсайдеров”. Автор фокусируется на модели Белбина, ролях и отдельно на роли “Вдохновителя” - участник команды, который вроде бы и не нужен, и конкретной пользы не приносит, но критически важен для здоровья проекта.
☝️ Мы всё время убиваем время? Про (бес)полезные созвоны
Часто разработчики выдвигают – созвоны бесполезны, они тратят очень дорогое время разработчика, и получается, что специалисты вместо работы о чем-то постоянно разговаривают. Но всё кардинально меняется, когда ты становишься ответственным не за свой конкретный код, а за результат команды в целом.
☝️ Как выстроить работу команды и отпустить тимлида в отпуск
Cитуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Материал о том, как исправить такую ситуацию.
☝️ Как увидеть три важнейших софт-скилла, чтобы нанять лучшего инженера
Кратко: 1) ему не пофигу на работу, 2) самонаводимость, 3) внутренний локус контроля. Также автор рассказывает про “темную сторону” этих навыков, которые могут даже навредить команде и проекту.
☝️ Tips - Improving Effectiveness of Scrum Teams
Одна из обязанностей, которую должен выполнять Scrum Master, - сделать скрам-команду эффективной. Для этого нужно сосредоточиться на развитии сотрудничества, самоуправления, понимании целей и, конечно, качестве работы и техническом совершенствовании.
🐳 Что на самом деле убило легендарную Nokia? И виноват ли в этом Agile
Про Agile в компании Nokia и почему гибкость не спасла, а возможно, погубила финскую легенду. Коротко: несмотря на то, что команды разработки вовсю использовали Agile, руководство компании не придерживалось ценностей Agile-манифеста: не было сотрудничества бизнеса и IT, не уделялось внимание техническому совершенству, а принцип простоты пал жертвой корпоративных интересов.
🐳 От малышей к гигантам индустрии: как мы научили инжиниринговую компанию Agile-подходу
Интересный опыт перевода не-ИТшной компании на гибкие методологии в проектной работе.
🐳 Несовпадение целей: Не проблема для успешной реализации проектов
Материал развивает тезис о том, что полного согласия относительно целей в проекте может и не быть, и это совершенно нормально.
🐳 Создание ИИ продуктов по Scrum: опыт компании Таймлист 1С
Разработчики сервиса по расшифровке и протоколированию совещаний рассказывают, как скрам помог им сделать успешный продукт.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1🙏1
Друзья,
небольшое объявление!
Сейчас проходит Всероссийский отбор инклюзивных практик (проектов) «Открыто для всех» .
Я состою в Экспертном совете этого масштабного конкурса, и вместе с коллегами мы занимаемся поиском и отбором решений для адаптации граждан с ограниченными возможностями здоровья.
Если вы или ваша команда занимаетесь разработкой таких решений в сфере ИТ, дизайна, корпоративной политики, туризма, - поделитесь своим решением с организаторами,
обменивайтесь опытом, тиражируйте на федеральном уровне!
Подробнее о конкурсе: https://smarteka.com/inclusive
небольшое объявление!
Сейчас проходит Всероссийский отбор инклюзивных практик (проектов) «Открыто для всех» .
Я состою в Экспертном совете этого масштабного конкурса, и вместе с коллегами мы занимаемся поиском и отбором решений для адаптации граждан с ограниченными возможностями здоровья.
Если вы или ваша команда занимаетесь разработкой таких решений в сфере ИТ, дизайна, корпоративной политики, туризма, - поделитесь своим решением с организаторами,
обменивайтесь опытом, тиражируйте на федеральном уровне!
Подробнее о конкурсе: https://smarteka.com/inclusive
2🔥4👍1👏1
✅ «Почему так долго?» Откуда появляются заторы в задачах и как их устранить
Затор или узкое место - это некий ресурс, производительность которого меньше или равно спросу. Авторы следуют концепции Голдратта, а в качестве инструмента для оптимизации проектного / производственного процесса и ликвидации узких мест предлагают канбан-доску и работу с WIP-лимитами.
✅Математика надёжности. Доклад Яндекса
Крайне интересный и полезный доклад по управлению рисками и “надежностью”. Помимо технической составляющей (автор выстраивает матмодель надежности) и интереса для системного аналитика, материал определяет простую и эффективную стратегию работы с рисками, полезную для любого менеджера проектов.
✅Памятка по BPMN и BPMN-диаграммам
Сбер решил помочь тем, кто не знает наизусть BPMN. В “памятку” включены: общая концепция, события, действия, шлюзы, потоки, дорожки. Есть пример применения.
✅Требования безопасности: пособие для аналитика
Большой и интересный текст про то, как правильно и обоснованно формулировать требования безопасности на проекте (как часть нефункциональных требований). Когда мы понимаем логику их формулирования, мы начинаем больше включать критическое мышление, и если требования, затрагивающие безопасность, спускают нам «сверху», нас уже так просто не запутать. А когда мы уже умеем дискутировать на тему безопасности, тогда мы можем достигать выгодных компромиссов и с другими типами требований.
✅How to Create a Story Map When Writing User Stories
Большая статья Майка Кона о том, что такое Story Map (“карта пользовательских историй”), как она помогает командам выявить потребности пользователей, упорядочить бэклог продукта, расставить приоритеты.
✅What Are Agile Spikes? When and Why Do Teams Use Spikes?
Спайк - понятие, связанное с фреймворком XP и означающее практику по исследованию и прототипированию, как правило, плохо предсказуемые в плане трудозатрат и сроков. Статья - про то, как и для чего использовать этот ценный инструмент (по мнению автора, они нужны только для задач с очень высокой неопределенностью).
✅How to Make a Process Improvement Plan (Free Template)
План улучшения процесса — это документ, в котором описывается, как улучшить ваши бизнес-процессы после их выявления и анализа. Это важный инструмент управления бизнес-процессами , который также поможет сократить напрасные усилия и повысить производительность работы команд. Он помогает уменьшить любые трения, которые существуют в процессах, и обеспечивает соответствие процессов нормативным требованиям, когда это необходимо. В статье - подробное описание такого плана и шаблон для использования на проектах.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4🔥2❤1
Если вы руководитель проектов, то рано или поздно к вам придут и потребуют (не попросят, а именно потребуют) сделать Быстро, Качественно и Недорого. Проблема в том, что сделать все три пункта одновременно невозможно. Фраза «делаем быстро, качественно, недорого – выберите любые два» крылатая не просто так. Но как же быть, если от вас хотят невозможного а другой работы нет?
Автор (из Ozon Tech) часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработки. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Статья для тех, кто хочет стать Руководителем проектов, или уже является Руководителем проектов. Ну и для всех, кто сталкивается с ними, чтобы понимать, что вам ждать, а чего ждать не стоит (и есть ли у РП волшебная палочка, которая позволяет взмахом выполнять все сроки, поднимая одновременно маржинальность проекта, или ее нет). Кратко: у успешного РП есть 4 главных качества: (1) умение решать проблемы и находить выход из любой ситуации, (2) коммуникации, коммуникации и коммуникации, (3) аккуратность и исполнительская дисциплина, (4) желание делать хороший продукт и помогать своему заказчику.
Очень своеобразный подход у автора, да еще и с отсылками к Гарри Поттеру. По существу, это большой и эмоциональный гайд по “пути РП” для тех, кто только осваивается в профессии. Почему важно, чтобы старт проекта был громким? Как растить свою репутацию в глазах специалистов и топ-менеджеров? Какому типу РП быть ближе и зачем? Как оценивать планы, бюджеты, сроки: Как управлять конфликтами? В этих статьях минимум теории, они за пределами методологий, это “советы бывалых”, и достаточно прагматичные.
Почему креативное мышление является ключевым навыком не только для условно творческих специальностей, но и для успешного менеджера проектов в IT, и почему креативность и менеджмент гораздо ближе друг к другу, чем нам кажется.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍3❤1🔥1
Всадники (т.е. симптомы): отсутствие в команде общего понимания целей и задач, отсутствие в команде взаимного уважения и признания чужих компетенций, плюрализм мнений, неудачный проект. Против каждого всадника (и главное, причин, которые за ним стоят) есть приемы, которыми автор делится.
Про то, что работа команды напоминает деятельность организма (клетки) и системы - в том плане, что команда тоже имеет свои границы, соприкасающиеся с внешней средой. Равно как и внутренние границы - распределение ролей и обязанностей внутри команды.
“Северсталь” - про реализацию проекта, формулирование бизнес-целей, сбор требований, оценку рисков, определение функций, проектирование, дизайн и кучу интеграций. SAP нынче в специфическом положении, но про такой опыт, еще и классно описанный, читать одно удовольствие.
Небольшой кейс от “Контура” по ситуации, когда нужна интеграция, а документации нет. Если что, автору даже пришлось по-настоящему регистрировать себя и своих знакомых на площадке сервиса, чтобы разобраться, как все работает, и отследить корректность интеграции.
Как проект автора помог компании из Новой Зеландии сократить временные затраты благодаря оптимизации бизнес-процессов. Много деталей, схем и фотографий)
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥4✍1❤1
🟢Инструменты системного аналитика: методология, софт, сервисы
Небольшой обзор инструментов, которые автор активно использует в своей работе: это и учебные материалы (курс “Анализ требований”, сайт BPMN2.ru и т.д.), и программы и сервисы (Lazarus IDE для прототипирования, OBS Studio для быстрой записи демо, Joplin и Typora для работы с текстом. Отдельный блок - про использование AI в работе (генерация сценариев, пиктограмм, инструкций и т.д.).
🟢«Почему так сложно и так некрасиво»: 4 подводных камня при внедрении базы знаний
Если компания обращается к первой попавшейся, скорее всего, внедрить ее гладко и с первого раза не получится. Одной функции недостает, другая работает, но с перебоями и багами. Авторы из Teamly разбираются, какие подводные камни можно обнаружить во время внедрения БЗ и как их избежать.
🟢Как сделать wiki, корпоративную библиотеку, публичную базу знаний и проектную документацию
Про корпоративную wiki и подготовку проектной документации на примере сервиса Weeek.
🟢Аналоги Miro — топ альтернатив Миро
Участники обзора - сервисы IDroo, Эсборд, МТС Линк, Padlet, Jamboard, Witeboard, Mural, Conceptboard, Ziteboard и даже Trello.
🟢Мы запустили простой и понятный трекер для управления потоком задач — Scrumo
И подробно, с картинками, рассказывают о его функционале, возможностях и перспективах развития.
🟢Системы управления проектами для разных по размеру компаний и отраслей с ценами на 2024 год
Автор категоризировал все сервисы по отраслям и размеру компаний, добавил стоимость и краткое описание. В списке: Strive, ЛидерТаск, Ёжка (от Ростелекома), Shtab, MooTeam, Planiro, Мегаплан, Planfix, EvaProject, Yandex Tracker, Bitrix24, Yaga, Directum Projects, Periscope, ELMA BPM, Advanta, а также отраслевые решения.
🟢Таск-трекер для разработки IT-продуктов, в котором разрабатываем свой IT-продукт
Разработчики таск-трекера O!task рассказывают про свое решение - и про возможности для управления проектами, и про то, как используют его сами для разработки.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤🔥3❤2🔥2
#Прочитал “Практическое руководство ИТ лидера” Раду Спатару.
Искал интересные новинки по управлению проектами - и нашел эту книгу. Издана в цифре буквально летом, описание и содержание - в точку, да и сама книга рассказывает про управление IT-трансформацией, формировании IT-культуры в организации, управление проектами,но…
😐 Судя по всему, это перевод англоязычной книги, изданной самим автором на Амазоне в марте 2024 (причем это третье издание, а второе вышло в феврале😁). Перевод выложили на Литрес, при этом инфо о переводчике нет, а на отзывы о книге отвечает якобы сам автор (!).
😐Информации об авторе крайне мало, и даже показалось, что это нейросеть, но, похоже, это реальный человек, имеющий отношение к проджект-менеджменту, - вот его профиль в линкедине и PMI.
Теперь о книге:
Достоинства:
🟢 Книга кратко (193 стр.) рассказывает о комплексе задач и процессов, с которыми может столкнуться IT-менеджер/лидер/директор/руководитель, от знакомства с текущим ИТ-ландшафтом в организации и формирования стратегии изменений и до управления проектами и использования AI.
🟢 Большое количество “примеров из жизни”
🟢 Много чек-листов и других инструментов самопроверки.
Недостатки:
🚫 Минималистичный объем для такого предмета - это “галопом по Европам”. Увы, ни одна из тем не получает нужного освещения, и получается такой “карманный справочник”, к которому вряд ли захочется вернуться, если только вы не студент. Весь текст выглядит как реферат, набор общеизвестных принципов, собранных в одном месте.
🚫 Ужасный перевод, в худших традициях “промпта”: множество опечаток и ошибок, корявый синтаксис, суконный язык.
🚫 Часть терминов, диаграмм и таблиц осталась без перевода с английского.
В целом, не рекомендую эту книгу никому - разве что вы захотите найти негативный ("как-не-надо") пример профессиональной литературы. Если тема “ИТ-менеджмента” вам интересна, лучше почитайте недавний перевод “Карьера Software Engineering Manager”.
Искал интересные новинки по управлению проектами - и нашел эту книгу. Издана в цифре буквально летом, описание и содержание - в точку, да и сама книга рассказывает про управление IT-трансформацией, формировании IT-культуры в организации, управление проектами,но…
😐 Судя по всему, это перевод англоязычной книги, изданной самим автором на Амазоне в марте 2024 (причем это третье издание, а второе вышло в феврале😁). Перевод выложили на Литрес, при этом инфо о переводчике нет, а на отзывы о книге отвечает якобы сам автор (!).
😐Информации об авторе крайне мало, и даже показалось, что это нейросеть, но, похоже, это реальный человек, имеющий отношение к проджект-менеджменту, - вот его профиль в линкедине и PMI.
Теперь о книге:
Достоинства:
Недостатки:
В целом, не рекомендую эту книгу никому - разве что вы захотите найти негативный ("как-не-надо") пример профессиональной литературы. Если тема “ИТ-менеджмента” вам интересна, лучше почитайте недавний перевод “Карьера Software Engineering Manager”.
Please open Telegram to view this post
VIEW IN TELEGRAM
Литрес
Практическое Руководство ИТ-Лидера — Раду Спатару | Литрес
Преобразуйте своё ИТ-лидерство с третьим изданием книги "Практическое руководство ИТ-лидера"Готовы ли вы освоить сложный мир управления ИТ? Независимо от того, являетесь ли вы опытным директором ИТ, …
2🔥4👍2😱1
В мире победившего эджайла, SCRUM, как один из наиболее популярных методологических фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков она стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами.
За кликбейтным названием - статья про положительные стороны скрама (и его пользу) и про негативные: сложности с адаптацией, негибкость, высокие затраты на внедрение. Особенно достается скрам-мастерам, из-за неопытности и избыточности которых проекты идут ко дну.
А для тех, кто не хочет дискуссий, - вики-материал про историю скрама, роли скрам-команды, принципы фреймворка, отличия от канбана и бонусом - инструкция по внедрению скрама в управление проектом.
Добротный гайд по работе с бэклогом: для чего нужен, как формируется, как приоритезировать (MoSCoW). В качестве примера автор взял подготовку к подходу в магазин - пример не идеальный, но понятный.
Если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным.
Текст от разработчиков Компас-3D, среди инструментов повышения / достижения качества - декомпозиция требований, использование и тщательная подготовка и приоритезация user-story, управление изменениями требований.
Материал скорее для стратсессий, портфельного управления проектами и поиска новых решений. Эвристический подход, который позволяет команде анализировать текущую ситуацию и определять приоритетные направления и новые фичи.
Коллеги из Naumen выбрали 6 частых ошибок сбора требований. В том числе: не звать на встречу функциональных (?) пользователей, не выяснять детали, не фиксировать для всех договоренности, использовать размытые формулировки, соглашаться на нереализуемые требования, а также не использовать блок-схемы.
Рецепт авторов - фреймворк P3.express, один из самых молодых в проектном управлении. В статье дается пошаговый гайд по его применению на примере софта Directum Projects.
Интересный текст про сторипойнты (если кто забыл, это способ/единица оценки задач, принятая в гибких фреймворках). Автор честно признается, что принятые абстрактные СП (которые “в попугаях”) работают плохо и эффективны менее, чем “конкретные” СП, выраженные в часах и днях. В итоге получилось, что термин “СП” в команде остался, но по сути был подменен на привычные “трудозатраты в днях” (один сторипойнт = 1 день). В комментариях отметили, что СП - прежде всего для задач с высокой неопределенностью, но, похоже, подмена СП на человекодни - это общая практика)
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥5❤🔥1👍1🙏1
⭐️Руководитель проектов: как говорить заказчику «нет», когда заказчик хочет слышать только «да»?
Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять?
Кратко: не говорить «нет», а говорить «давайте поглядим, что мы можем сделать».
⭐️Чем руководители проектов отличаются друг от друга (джун vs миддл vs синьор)
Автор считает, что грейды могут быть не только у разрабов, но и у менеджеров, и приводит свою таксономию, что должен уметь джун/мидл/сеньор-проджект. Все основано на реальном опыте и собесах. При этом внезапно РП-джуны у него могут рассчитывать на зарплату в 180 - 230k, - и это не может не радовать))
⭐️Не базовые навыки. Как расширить свои возможности и найти новые подходы в работе
Если вы устали от рутины и хотите “расширить сознание” (и заодно доход), то автор советует изучить несколько полезных тем (и дает рекомендации, на что обратить внимание), в том числе базы данных, интеграция и API, PlantUml, Python etc.
⭐️Как я прошел путь от администратора до руководителя проектов
Рассказ РП о своем карьерном пути - что помогло, что помешало, как за 9 месяцев из гуманитария стать типа настоящим “проджектом в ИТ”.
⭐️Как фронтендеру стать тимлидом кросс-функциональной команды
Статья от Авито, чей подход к менеджменту лично мне очень симпатичен. Эта статья детализирует роль техлида и показывает, что главным в ней становятся не столько технические навыки, сколько навыки развития команды, планирования, взаимодействия с подрядчиками, декомпозиции задач и ответственность за реализацию фичей.
⭐️«Ты не управляешь моей жизнью!» Как не сгореть в многозадачности: 3 способа сохранить концентрацию
Все РП знают эту проблему - поток информации и необходимость коммуникации с командой и заказчиком сносит на своем пути все “помидоры” и другие техники фокусировки. Автор рассказывает о своих удачных (и неудачных) инструментах, которые позволяют сохранять “мыслетопливо”.
⭐️Как стать проджект-менеджером в IT: большой разговор о профессии
1,5-часовой подкаст с опытным РП на больные темы: как строится рабочий день РП, как решать конфликты, на какую ЗП рассчитывать, что делать, если коллеги игнорируют, надо ли сертифицироваться, куда расти и т.д.
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥5❤1👍1
⭐️Как создать почву для развития софтскилов у сотрудников
85% успеха на работе зависит от социальных навыков и умения работать с людьми. И лишь 15% приходится на технические навыки, то есть то, что мы называем хардскилами.
Материал о том, как развивать эти самые софт-скиллы у команды и (шире) сотрудников компании от Яндекса. Основное: вводите практику обратной связи, формируйте комьюнити с общей микрокультурой , поощряйте межкомандное взаимодействие, предлагайте задачи за рамками прямой ответственности - и поменьше гиперконтроля.
⭐️Куда и как развиваться системному аналитику, если «потолок» уже близко
“Круглый стол” о сценариях роста СА. Можно стать “лидером компетенции”, который отвечает за развитие компетенций других СА в команде. Можно - “solution-архитектором”, стоящим на границе между техническим решением / техническими специалистами и бизнесом. И можно Product Owner’ом, - в этом случае новой задачей станет определение точек развития и привлекательности продукта.
⭐️Система онбординга комфорт-класса
Про трудности онбординга и авторские рецепты его оптимизации. Онбординг делится на две категории - общий (в компанию) и локальный (в команду), со своими разными наборами активностей. Заниматься им нужно не ad hoc, а целенаправленно, с актуальными инструкциями. Важно формировать и транслировать сотрудникам правильные (адекватные) ожидания и не забывать делать промежуточный контроль. В целом, материал большой и полезный, безусловно рекомендую.
⭐️Why Shared Goals Matter
Про важность общих целей для команды - и про то, что весьма немногие действительно заботятся о формировании общей “целевой культуры” в коллективе.
⭐️How to Identify Different Work Styles for Better Productivity
Все мы разные, со своим подходом к работе, своими циркадными ритмами (жаворонки/совы), своими горизонтами планирования и т.д. Как только разные люди объединяются в одну команду, встает вопрос о синхронизации работы, без которой неизбежно возникнут проблемы. Материал о том, как сделать команду из участников с разными стилями работы продуктивной.
Please open Telegram to view this post
VIEW IN TELEGRAM
3❤4👍1🙏1
🟢Как лень научила нас поддерживать проектную документацию актуальной
Когда наша команда начала расти, мы заметили, что поддерживать документацию актуальной стало сложнее, а связанные с этим проблемы только усилились. Например, на релизе происходил полный хаос: результат не соответствует первоначальной задумке; половина сотрудников не в курсе, что должно было получиться; тестировщики отмечают баги, которых нет, потому что используют устаревшую информацию. Приходилось останавливаться и объяснять каждый момент отдельно, рискуя сорвать дедлайн.
Как преодолели: тщательно продумали структуру, встроили документацию в производственный процесс, сделали удобные шаблоны, организовали непрерывную актуализацию.
🟢Как приоритизировать проекты в рамках компании, или как мы научились сравнивать несравнимое
Lamoda использует для приоритезации фич/инициатив показатель ROI - коэффициент окупаемости инвестиций. Не продуктовые метрики, а вот именно “за сколько времени окупятся затраты на фичу”. Публикация раскрывает, как в компании устроен процесс оценки ROI фич, как работает команда таких оценщиков, как инициативы превращаются в проекты.
🟢Очень простая и даже местами детская задача — во что она превратилась
Сотрудник металлургического завода - о том, как реализовали для производства проект автоматизированного мониторинга цвета (и соответственно стадию готовности) руды в процессе сепарации.
Универсальный шаблон постановки бизнес задачи или product brief
Инструмент для продактов, но взглянуть на него можно и остальным. Product brief состоит из 5 полей - аудитория, проблема (точка роста), гипотеза, решение, метрики.
🟢От разработки до миграции: как Axenix в сжатые сроки организует в Kaiten сложные проекты
Демонстрация реального использования сервиса для управления ИТ-проектами, с картинками и примерами.
🟢WEEEK vs Kaiten: какой таск-менеджер выбрать
Попытка сравнения трекеров - рабочее пространство, инструментарий, работа с задачами и командой, ведение документации и т.п.
🟢Bitrix, Trello, Asana: не статья-обзор, а личный опыт поиска дешевого и удобного планера
Да, там личный опыт использования. Любопытный, конечно, мув в сторону Трелло (в нынешних условиях), но в итоге остановились авторы на другом отечественном сервисе.
🟢Карта реализации историй
Авторская методология, похожая (и родственная) на карту историй Александра Бындю, развивающая технику User Story Mapping.
🟢Какую доску выбрать вместо miro. Обзор российских решений
На фоне проблем с Miro - еще один текст про “импортозаменители”. В списке - Эсборд, Pruffme, GetLocus, МТС Линк, Flip, Microboard.
🟢Вместо Miro: почему МТС Линк Доски — лучший выбор для вашей команд
Расширенная презентация сервиса от разработчиков.
🟢Как создать wiki для компании
Про то, зачем wiki и для чего, какие типы могут быть, а также как создать эффективную wiki - пошагово, от определения аудитории и до управления актуализацией. Плюс выборка сервисов для их создания.
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥5❤1👍1
Покер планирования — это как швейцарский нож для энтузиастов Agile, который помогает оценивать задачи, избегая влияния лидеров и долгих обсуждений. Публикация отвечает на 10 вопросов, связанных с этим методом: как правильно использовать, в чем его магия и почему так ценится в Agile-сообществах.
Наверняка, многие из вас работали в проекте, где был полный бардак с требованиями и документацией. Материал рассказывает, как можно навести порядок практически в любом проекте или хотя бы сделать его чуть более упорядоченным и понятным.
Взгляд на требования с позиции QA-специалиста: Что такое требования и какими они бывают, что делать, если требований нет или почти нет, как проводить тестирование требований, элементы качества требований и т.д.
Что такое нотации, зачем они нужны, и какие виды моделирования бизнес-процессов существуют в природе, основные элементы нотации BPMN и пример ее практического применения.
Поддержание документации на высоком уровне — залог успешного управления проектом и обеспечения его качественного выполнения. Документация обязана быть надежным помощником, а не обузой. Публикация - о базовых принципах и методах работы с документаций.
Небольшой, но полезный гайд по основам интеграции для тех, кто не очень в теме: API, монолит/микросервисы, поток данных, шины данных, типы интеграций,
Этические нормы имеют решающее значение для успеха проекта и поддержания доверия заинтересованных сторон. Этическое поведение в управлении проектами необходимо для обеспечения успеха при сохранении доверия, ответственности и целостности. Для менеджеров проектов жизненно важно отдавать приоритет этическим практикам, создавая среду, в которой заинтересованные стороны уверены в процессе и результате.
Решение проблем клиентов важнее совершенствования Scrum. Нам платят не за практику Scrum — или любой другой конкретной гибкой структуры, — а за решение проблем наших клиентов в рамках заданных ограничений. Пока мы доставляем ценность для бизнеса, никого не волнуют конкретные инструменты или фреймворки, которые мы используем. Если вас больше волнует процесс, чем результаты, пришло время пересмотреть свои приоритеты.
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥5❤2👍1
Делегирование является ключевым навыком руководителей, поскольку позволяет освободить время для других видов деятельности и развивать персонал. Эффективное делегирование позволяет извлечь много пользы. Материал о том, на что нужно обратить внимание руководителю при передаче отдельной функции исполнителю.
Автор материала часто наблюдает за парадоксальной ситуацией «пчелы против меда», когда работу тормозят именно те, кому этот проект нужен больше всех. На примере одного кейса - откуда берутся подобные ситуации, как их можно исправить и с чего начать спасение своего продукта.
Чем более сложными становятся ИТ-проекты, тем больше им требуется функциональных лидеров — тимлидов и техлидов. Эти роли в команде объединяют административные и технические обязанности и открывают новые карьерные перспективы для сотрудников.
Как специалисты становятся тимлидами и техлидами? В чем разница между ними? Какие навыки для них нужны?
Стоит ли идти в тимлиды? Автор публикации давно “прыгает” между менеджментом и разработкой и до сих пор однозначно не ответил на этот вопрос. Цель статьи – не просто пожаловаться на эту роль, а скорее подсветить самые главные проблемы, которые для кого-то станут красным флагом при принятии важного решения в жизни.
РП – это коммуникатор. Он коммуницирует в две стороны: слева - те, кто ждет от него результат (заказчики), справа - те, с помощью кого он этот результат должен дать (команда). Формально для новоиспеченного руководителя проектов работа с командой выглядит проще простого: получи оценку, спланируй, поставь задачи, да плюй в потолок, ожидая выполнения. Успех? Не тут-то было...
Интересный, хоть и небесспорный опыт автора - от менеджера / РП в Сбере к проваленному собеседованию на agile-коуча и дальше к успешной карьере в крупном бизнесе, а потом и свой бизнес.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤4👍2✍1
⚽️ Команда проекта
🔴 Кросс-функциональная команда: что это, как создать и управлять
Кросс-функциональная команда — группа людей из разных отделов с разными навыками, которые работают вместе для достижения общей цели. Сила таких команд — в создании среды, где каждый член команды вносит уникальный вклад в достижение общей цели. Атмосфера обмена знаниями и опытами содействуют сотрудничеству и инновациям.
🔴Как избежать выгорания в команде? — Процессы, методологии и современные технологии…
Выгорание — это проблема, с которой может столкнуться любая команда разработки, но правильные процессы, методологии и современные технологии могут значительно снизить риски. Современные методологии, автоматизация, разнообразие задач, учет возможностей команды и регулярная обратная связь — все это помогает создать здоровую рабочую среду, где каждый участник команды может работать эффективно, не боясь выгореть.
🔴Как отсветофорить навыки сотрудника, или Основные принципы работы со “Звездной картой”
«Звездная карта» — это таблица, в которой указаны компетенции каждого сотрудника: его навыки или знания. Это могут быть технические навыки или soft skills. При желании их можно комбинировать. Это инструмент для быстрого принятия решений. Поэтому информация должна считываться легко. Для этого оценки визуализируются по принципу светофора. Уровни экспертности просты: от 0 до 4 экспертного уровня. Каждый уровень подсвечивается своим цветом. Наглядная визуализация позволяет оперативно оценить сотрудника и видеть его динамику.
🔴Cистемный аналитик с ЗП 400+. Найти за 30 дней
Если вы ищете СА в команду или сами хотите получить оффер, то вот что-то вроде туториала для подготовки к прохождению технического собеседования. С кейсами реальных собеседований, мыслями автора и выводами.
🔴 Дейлики с таймером, созвоны по пропускам и оверлап: 7 шагов, которые помогли нашей команде не созваниваться по любому поводу
Если рабочее расписание похоже на рутину колл-центра и день начинается и заканчивается звонками, с результатами на работе можно попрощаться, потому что вместо KPI сотрудники начинают считать количество созвонов за день. Авторы материала рассказывают, как они вытащил команду из дня сурка, висящего на телефоне, и что из этого вышло.
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍3🙏2❤1
📎 Анализ, декомпозиция и оценка задач: от теории к практике
Авторская методика работы с задачами. Кратко: больше времени выделять на анализ задачи и окружения, упор на декомпозицию, чаще тренировать навык оценки, внимательно относиться к коммуникации (чтобы все всё однозначно понимали), не стесняться адаптировать процесс под команды.
📎 Планирование и декомпозиция задач
Мнение о важности планирования рабочих задач, об улучшении процессов компании через использование BI. Всё на примере Jira.
📎 Разработка проектов через интуицию — Passion-Driven Decision Making
Автор считает, что в некоторых проектах самые эффективные решения не всегда основаны на данных. Наоборот, он использует метод принятия решений, основанный на страсти/интуиции. Суть этого подхода не в полном игнорировании данных, а в том, чтобы отдавать предпочтение интуиции, творческому подходу и глубокому пониманию красоты и предназначения.
📎 Как требования в банках к ИБ усложняют архитектуру прикладных сервисов: кейс внедрения ВКС
О специфике требований к ИТ-инфраструктуре в банках и о том, как реализация этих требований отражается даже на вполне простых проектах.
📎 Как мы применили Скрамбан и остались довольны: Кейс Инферит Клаудмастер
Очень обстоятельный, со множеством полезных ссылок кейс внедрения канбана (на джире) в скрам-разработку, использование метрик, имплементацию тайм-бокса. В итоге получился хоть и франкенштейн, но вполне эффективный.
📎 Agile и инжиниринг: путь к новым принципам работы
Опыт внедрения Agile в проектном бюро - с проблемами, препятствиями, граблями и хэппи-эндом.
📎 Заказная разработка. Ищем баланс между добром и злом
Выбор подрядчика для заказной ИТ-разработки может быть коварным: кажется, что все под контролем, но один неверный шаг — и проект рискует оказаться в хаосе. Авторы анализируют, с какими трудностями сталкиваются заказчики в ходе проектов, и как выбрать надежного подрядчика.
📎 <Не>Страшное слово эстимация, или Как я впервые оценивала время на тестирование и перебрала
Однажды автора статьи попросили сделать эстимацию (оценку трудозатрат на тестирование). Автор воспользовалась рядом методик, и в итоге… оказалось, что оценка превысила результат на 26 часов. Почему так произошло и как правильно - в статье.
📎 Чем короче спринт, тем лучше? Как найти оптимальную длительность спринта?
Мнение о том, что спринты вовсе не обязаны быть короткими и даже (по классике) 2-недельными. Автор благополучно использует 3-недельные спринты и делает выводы, почему они вполне себе эффективны.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3❤2👍1
Кейс отказа от Яндекс.Трекера (в котором не было нужной отчетности) и перехода на Kaiten. Про настройку воркфлоу, применение скрама, визуализацию спринтов и т.д.
Новость об уходе Notion в сентябре породила целую волну качественных обзоров аналогов системы.
Еще один обзор заменителей Miro.
Для тех, кто хочет прокачать матчасть и/или получить диплом.
В обзор вошли: Weeek, Планфикс, Yougile, Kaiten, Strive, O!Task, Aspro, Shtab, LeaderTask, Яндекс.Трекер, Мегаплан, TeamStorm, Битрикс24, Glabix и др.
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍3🙏3🔥1
✅ Что такое Диаграмма Исикавы: как построить и применять её в проекте
Подробно и с примерами про диаграмму Исикавы (она же диаграмма «скелет рыбы» или «рыбья кость») - инструмент для проактивного управления рисками и решения проблем через установку причинно-следственных связей.
✅ Полное руководство по созданию эффективного отчёта о статусе проекта
Отчёт о статусе проекта — документ с общей информацией о делах в проекте. Он помогает согласовать действия команды и понять, укладывается ли она в сроки, есть ли проблемы в работе и нужно ли что-то делать. В такой отчёт входят статусы текущих задач, успехи, ближайшие планы, риски и проблемы, которые могут возникнуть по ходу работы над проектом. Материал - о том, зачем и кому нужен отчет и как правильно его подготовить.
✅ Обзор Agile подходов к масштабированию: LeSS, SAFe и Nexus
Многие компании, успешно работающие по Agile в одной команде, сталкиваются с проблемой масштабирования. Когда число команд растет, а Agile-принципы не адаптируются на более высокий уровень, начинается хаос. Команды теряют синхронность, задачи не выполняются в срок, и возникают проблемы с прозрачностью процессов. Чтобы справиться с этими вызовами, были созданы фреймворки масштабирования, такие как LeSS, SAFe и Nexus. Статья - про их суть и область применения.
✅ Диаграммы последовательности — единственная хорошая вещь, которую UML привнес в разработку ПО
Про историю UML, про то, как большая часть UML была отправлена на свалку истории программного обеспечения (да, вот так)). И про то, почему диаграммы последовательностей все еще ценны и как мы можем наилучшим образом их использовать.
✅ Управление большими проектами: как правильно засунуть слона в холодильник
Как при помощи MS Project и MS Excel решить задачу еженедельного планирования работ команды для средних ИТ-проектов длительностью от 3 месяцев до года и с командой до 15 человек.
✅ Проектная аналитика: агрегирование требований заказчика и создание тех. задания
Аналитика проекта нужна для верного понимания ожиданий заказчика, определения объема проекта, грамотного планирования бюджета. На этапе аналитики формируется структура проекта. Это комплексный процесс, который закладывает основу для успешной разработки. На примере автор рассматривает ключевые этапы: агрегацию требований, прототипирование и документирование.
✅ Kafka для самых маленьких разработчиков, аналитиков и тестировщиков
Основы работы с популярным брокером сообщений для тех, кто не понимает, но хочет разобраться)
Please open Telegram to view this post
VIEW IN TELEGRAM
2⚡3🔥3❤1
⚽️ Менеджер и команда проекта
🔴 Как привычка переспрашивать спасает меня от факапов: фильтры восприятия и петли обратной связи на примере велосипедиста
О важных в работе менеджера и управлении командой темах: что такое фильтры восприятия и петли обратной связи, как в них не запутаться и как применять, чтобы в команде на удаленке все понимали друг друга с полуслова.
🔴 О пользе регламентов в жизни руководителя ИТ разработки
Нередко РП предпочитают вести проект по наитию, в обход скучных регламентов. И зря: тем самым они саботируют работу компании, подставляют себя и команду. Да, многие регламенты не идеальны, но помнить, уважать и следовать им все-таки стоит. Почему - читайте в материале.
🔴 Не дай мозгу себя обмануть: 5 когнитивных искажений, распространённых в IT
Мозг человека не идеален, когнитивные ошибки бессознательны. Однако осознание их существования помогает критично относиться к собственному мышлению, отлавливая когнитивные «ловушки» заранее, еще на стадии появления. Статья - о самых основных, которые встречаются в повседневности чаще всего. Особенно в IT: в разработке, в управлении проектами, в оценке рисков и т. д.
🔴 Schedule Variance: What Is It & How Do I Calculate It?
Про работу с отклонениями от план-графика проекта. Менеджерам проектов приходится планировать работу, управлять людьми, управлять бюджетами и решать технологические проблемы. Но как менеджер проекта узнает, находится ли проект в рамках графика или отстает?
🔴 Чем занимается системный аналитик: разбираем на примере
Про софт- и хардскиллы СА. В том числе автор включает в них описание процессов (умение проектировать BPMN-диаграмму, activity diagram и sequence diagram), проектирование REST API, проектирование баз данных, прогнозирование рисков, коммуникации с стейкхолдерами и т.д.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤3🔥3👍1
🥇 Декомпозиция задач: съесть слона по кусочкам
Представьте, что у вас есть масштабный проект: разрабатываемое приложение предназначено для девяти компаний и состоит из шести компонентов (или модулей, или подсистем). В проекте задействованы три мини-команды, и основная задача — декомпозировать и описать задачи для всех членов проектной команды. Как автор научился “есть слона”, правильно “нарезав” проект на задачи, - читайте в материале.
🥇 Почему мы не просим ТЗ от клиента, а составляем его сами
Авторы не используют брифы, не просят заказчика написать ТЗ, - вместо этого они сами составляют задание и считают смету. Хороший материал с примерами и конкретикой.
🥇 Почему котику лучше в коробке, или Как мы сокращаем этап ревью и согласования документации
Можно ли написать такую спецификацию требований / документацию, по которой вопросов не будет вообще? Если ее будут читать, то без вопросов не обойтись. Но снизить их число можно, тем самым сэкономив свое время и время команды. Для этого автор добавляет в доку бизнес-контекст, дает краткое описание изменений, указывает обоснование решений, делает описания конкретными и т.д.
🥇 Как одно бизнес-требование чуть не сорвало интеграцию двух больших компаний. Рассказываю, что нас спасло
Захватывающий кейс, интересный и своим удачным спасением, и процессами компании-подрядчика, от лица которой пишет автор.
🥇 Как мы выстроили экосистему разработки на 1С в Росатоме и победили техдолг
Опыт работы с техдолгом Гринатома - как он копился, как его решили контролировать, с помощью чего (инструментом стала конфигурация “СППР” от 1С), - и к чему это привело.
🥇 Заплатки на Scrumban: Tips & Tricks
Автор столкнулся на проекте с неработающим Agile у заказчика, и в итоге получился гибридно-эклектичная, но якобы вполне эффективная методика.
🥇 Гибкие методологии для решения реальных проблем команды: комбинация Kanban и Scrum
Опыт сервиса бронирования отелей - от выбора методологии и встройки канбана в скрам до проблем измерения эффективности и коммуникации.
🥇 Кейс "Мосгипротранс": как мы автоматизировали подготовку проектной документации и ИТ-поддержку
Как компании удалось организовать работу поддержки, систематизировать решение специфических задач вне ИТ и выстроить взаимодействие с аутсорсинговыми компаниями на базе единой платформы Service Desk.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3🙏1