Как оценивать задачи, ABCDE для РП, эффективные разборы полетов, умирающий и вечно живой Agile, любовь и работа, идеальное собеседование, гору от ума и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Основы и гайды
Основная цель использования разных типов задач — повысить понятность и удобство управления проектами и работой команды. Базовые типы - new feature, feature improvements, testcase, bug, но каждый из них можно детализировать или связать с такими параметрами, как источник, интенсивность, время выполнения, платформа и т.д.
Абсолютные оценки в часах не работают. Они не учитывают неопределенности, возникающие в процессе работы. Для решения этой проблемы автор предлагает три подхода: 1) использовать не экспертные оценки, а статистику, 2) использовать не часы, а условные единицы (“попугаи”), 3) оглянуться на “попугаев” из прошлых спринтов. Ну и в идеале все это считать автоматически, скриптами.
Еще один материал на эту тему. Здесь рецепт иной: декомпозируем - закладываем буфер с учетом неопределенностей - смотрим исторические данные - обсуждаем с исполнителем - считаем разные сценарии. И получаем диапазон трудозатрат и времени.
Простой, но интересный метод. Делим все задачи на А (абсолютно приоритетные), B (средний), C (низкий), D (делегировать), E (вычеркнуть). Подробности, сравнения с MOSCOW, преимущества и пример применения - в материале.
Полезное про инцидент-менеджмент, применимый к проектам и десантам. Постмортем - что-то вроде разбора полетов, но после крушения) Они позволяют установить причины возникновения проблемы, предотвратить повторение инцидента, а также выявить системные недостатки. Статья - про принципы проведения постмортемов и этапы: сбор данных, восстановление хронологии, определение источника отказа, разработка плана действий и документирование.
Цель спринта — это ключевой элемент планирования, который помогает команде понимать образ результата, а не просто делать разрозненный набор задач. Чтобы цель была “хорошей”, нужно потрудиться над ее определением. Например, с помощью методик FOCUS, INVEST, SMART. В статье подробно раскрыт каждый метод и приведены примеры плохих и хороших целей.
Автор предлагает решения для интеграции Agile в бизнес-процессы, чтобы сделать компанию более адаптивной и ориентированной на клиента. Важным аспектом является совместная работа бизнес-подразделений и IT для приоритезации задач и устранения технического долга.
Многие организации, пытаясь самостоятельно перейти на Agile, совершают одни и те же ошибки, что негативно сказывается на сотрудниках. Автор подчеркивает, что Agile — это не просто релизы каждые две недели, а трансформация корпоративной культуры и доверие к команде. Для успешного внедрения Agile необходимо системное и последовательное изменение подходов, начиная с руководства.
Илья Павличенко (scrum.ru) написал целую книгу про построение аджайл-компаний, а это - ключевые мысли. И я очень рекомендую почитать, действительно интересно для РП, архитекторов, CEO и собственников. Если совсем кратко - фреймворков много, готовые полезны для новичков, но универсальных моделей формирования гибкой культуры нет. И по взмаху волшебной палочки ничего не произойдет - нужен правильный оргдизайн и альянс менеджеров и агентов изменений для успешной трансформации
Интервизия — это встреча коллег для обсуждения сложных рабочих кейсов с соблюдением строгих правил и конфиденциальности, что создает безопасную атмосферу для открытого общения. Она помогает переосмыслить опыт, увидеть новые возможности, выйти из тупика и получить поддержку. Участники получают ценные инсайты и развивают профессиональные навыки. Материал - руководство по проведению интервизий.
Проектные и продуктовые команды часто формулируют задачи с точки зрения технических решений, а не реальных потребностей пользователей. Это приводит к перегруженным и дорогостоящим продуктам, которые сложно разрабатывать и поддерживать. Если сместить фокус с функциональности на реальные потребности пользователей, можно значительно сократить объем работы, уменьшить затраты и ускорить выход продукта на рынок. Как это сделать - в статье Дмитрия Курдюмова.
Многие команды недолюбливают спринт‑ретроспективы, считая их бесполезными или формальными встречами, которые не приводят к реальным изменениям. Однако при правильном подходе этот инструмент может стать мощным механизмом для постоянного улучшения процессов разработки и повышения удовлетворенности команды работой. Секрет - в привязке к конкретным данным, использовании метрик. Автор предлагает фреймворк 4L’s (Что получилось, Чему научились, Чего не хватало, Чего хотелось бы) и дает пошаговую инструкцию по проведению ретро.
Хотя и утверждается, что «работающий продукт важнее исчерпывающей документации», качественная документация на самом деле поддерживает порядок и слаженность работы команды, а главное — ускоряет поставку, а не замедляет ee, как иногда ошибочно считают. Материал - про факторы пользы качественной доки. А еще там есть неплохой шаблон доки для описания API.
Документацию нужно писать каждому. Иначе получится ситуация, когда этот скилл развивает только один член команды, что чревато плачевными последствиями – коллега может выгореть, заболеть, покинуть компанию, при этом поддерживать старую и писать новую кто-то должен. Написание документации – важный скилл для всех. Это должно стать привычкой. Столкнулись с болью – записали. Решили – дописали. В целом, классная и простая статья о действительно важном.
Напоследок ликбез по SD. В этом материале - про масштабирование баз данных, SQL и NoSQL, их особенности и выбор между ними.
Менеджер проекта - карьера и навыки
Если вбить фразу «как стать project-менеджером» в поисковую строку, можно найти множество курсов по данному направлению. Проблема в том, что все курсы являются платными. А авторы взяли и подготовили программу обучения, которая состоит только из бесплатных курсов. Программа неплохо структурирована и включает курсы на Ютубе, статьи на интернет-ресурсах, телеграм-каналы.
Не очень серьезная статья Петра Жаркова про отношения с компанией и их параллели с отношениями с противоположным полом. Всё это в контексте менеджмента проектов и CJM.
Автор - геймер со стажем и делится неординарным подходом к тренировке управленческих навыков. Его инструмент - это игра Squad, она предлагает уникальный шанс «прокрутить» в сжатом формате типичные командные и управленческие ситуации: быстро формировать рабочие процессы, налаживать коммуникацию, распределять роли и нести ответственность за решения.
Cоветы, которые помогут вам оценить стоимость и продолжительность проекта по не слишком детальному техническому заданию или по поверхностным характеристикам систем клиента. Например, методика создания калькулятора проекта, использование опросников, озвучивание взвешенной оценки и допущение дополнительных работ и т.д.
На рынке труда появляется все больше вакансий Scrum-мастеров. Статья - о том, кто это такие, зачем они нужны бизнесу и какую роль специалисты играют в команде. Если коротко - Scrum-мастер обучает команду методу, направляет сотрудников и помогает им учиться на ошибках и самосовершенствоваться, организует и фасилитирует встречи, на которых проходят групповые обсуждения.
Хороший кейс про переезд на не очень-то и известный аналог сервиса. Хороший и как собственно пример проекта перехода, и как обзор практической применимости “наших” аналогов Notion.
Не стоит торопиться со Скрамом, если вы ещё не постигли, как вообще планировать, организовывать и координировать. Иначе будете бегать с этой доской «todo – in progress– done» и не понимать, почему всё то же самое остаётся «in progress» уже третью неделю. А постигать можно при помощи умных и полезных книг, которых автор рекомендует много, от классики (Файоль, Тейлор, Друкер) и до свежака (Завертайлов, Пименов, Бындю).
Да уж, манги у нас еще не было (#ВЭтомГодуЯВпервые), - но это обзор бизнес-манги от (якобы) титулованного эксперта. Книга - про организационное развитие, о том, как быть и руководить в современных реалиях, ведь «требования к сотрудникам как никогда высоки, а управлять командой как никогда сложно». И что делать, чтобы сплотить сотрудников, создать командный дух и благоприятные условия на рабочем месте.
Команда проекта
“Если ваш сотрудник не успевает жить — он не успевает работать”. Work-life balance — это про то, как сделать так, чтобы люди не считали вашу компанию каторгой. Потому что выгоревший сотрудник = потраченные деньги на поиск нового. А если научить людей жить и работать в балансе, они сами начнут генерить идеи, от которых у конкурентов сгорит проводка. Автор дает ряд рекомендаций по формированию нормальной культуры в команде и компании.
Гайд о том, как провести аудит знаний в команде, чтобы зафиксировать корпоративную экспертизу, устранить неэффективность и обеспечить команде быстрый доступ к информации.
Команда T2 (Теле2, а не Терминатор) - про свой онбординг. Сделали гайд в формате презентации, в котором расписали про первые дни, про полезные материалы, нарисовали “дерево с коллегами” (пожалуйста, без шуток!) и вообще расписали процессы, с которыми столкнется новичок в команде.
На собеседовании многие сотрудники хороши и кажется, что ты со своим опытом точно уж не ошибёшься. Но проходит испытательный срок, полгода, год и кто-то действительно радует, а кто-то откровенно портит жизнь остальным. Автор дает что-то вроде типологии и примеров последних. Среди них - те, кто пришел на работу “пересидеть” и получить красивую должность, те, кто не принял правила компании, те, кто не вписался в команду. Рекомендации, что с ними делать, - присутствуют.
Кирилл Мокевнин написал супер-пост про собесы. Делать ли тестовое, сколько собесов норм, как проводить, как делать “разогрев” и какие вопросы задать, что включить в основную часть (с очень конкретными вопросами), чем закончить и что делать после интервью.
Мой (и не только) личный хит - статья “ИТ-психолога” про наши комплексы и особенности восприятия мира у тех, кто учится и расширяет кругозор. С акцентом как раз на боли - чем больше знаешь, тем больше понимаешь, сколько еще неизвестно и сколь много ресурсов тебе не хватает. Это нормально, говорит автор, и дает рекомендации, как остыть и прекратить грызть себя.
Отличный текст от тимлида из “Вайлдбериз” - о том, как наибольшее внимание уделять важным вещам (стратегии, культуре, ключевым метрикам), а не тушению пожаров и ручной работе.
Про T-shape подход в ИТ, который хорошо известен, и тем не менее есть нюансы. Да, такой Т-спец развивается, находит новые нестандартные подходы в решении задач, глубоко погружается в сферу, - но, вместе с тем, теряет владение менее востребованными навыками. К тому же есть риски неправильного входа в смежные области, которые приводят к поверхностным знаниям.
