Меня зовут Вадим Кузенков, я руковожу проектным офисом и работаю с командами в компании KODE. За плечами — 18 лет опыта в управлении проектами.
Весной мы проводили первую стажировку по проджект-менеджменту. На первой лекции я рассказывал, что такое проект для настоящего PM и какие методологии нужно использовать, чтобы уверенно им управлять. Решил поделиться материалом с вами.
Чем он может быть полезен? Вы сможете проверить свою осознанность, начать строить мост над пропастью между теорией и практикой, возможно — избавиться от стереотипов. Материал прежде всего ориентирован на джунов в PM, но будет полезен и другим IT-специалистам. Развеем миф, что попугая можно повысить до PM, если научить его говорить «ну что там?»
Но для прожект-менеджера этого недостаточно: нужно всегда учитывать содержание проекта, стоимость и время работ. Эти элементы называются тройственной ограниченностью.
Треугольник управления проектами: скоуп, стоимость и время работ. Соблюдая баланс между элементами, мы получаем качественный продукт
Суть треугольника заключается в том, что нельзя выбрать всё сразу — нужно стараться соблюдать баланс между элементами. В зависимости от задач и процессов проекта можно выбрать два ограничения, жертвуя при этом третьим.
Много, дёшево и быстро не получится, хотя это принципиальная позиция многих заказчиков. Здесь советую познакомиться с армянской народной сказкой «Жадный Вартан» — она наглядно иллюстрирует, что бывает в таком случае.
Определение проекта для настоящего PM:
Мероприятие по созданию продукта или результата в конкретные сроки, бюджет и с надлежащим качеством и/или определённым скоупом.
Scrum — набор инструментов, фреймворк, с помощью которого реализуется Agile-подход. В Scrum работа ведётся спринтами — одинаковыми по продолжительности итерациями.
Kanban — метод управления разработкой и визуализации процессов. Точно определяет, что нужно производить, когда и сколько. Исторически канбан — просто доска, сейчас из него делают отдельный фреймворк — канбан-метод.
Waterfall — условно существующая каскадная модель разработки. Здесь процесс воспринимается как поток, а переход от одного этапа к другому происходит только после успешного завершения предыдущего.
Эти понятия пересекаются и взаимодействуют между собой следующим образом:
Каскадная модель разработки предполагает последовательное прохождение этапов: анализ требований, проектирование, реализация, тестирование, интеграция и поддержка. Переход от одной фазы к другой невозможно без полного завершения предыдущей.
Ей противостоит итерационная модель, когда создание продукта осуществляется параллельно с непрерывным анализом результатов и корректировкой предыдущих этапов работы. Чаще всего такая модель выбирается, когда на первых этапах не определить общий объём работ.
В качестве примера могу привести 2 проекта из нашего портфеля: Whiskas и Utair. На первом была чёткая дата релиза, понятный скоуп и ограниченный бюджет. На втором — неопределённая дата релиза, бэклог задач на полтора года и нефиксированный бюджет, который рассчитывался из количества часов, потраченных командой в месяц.
Разумеется, на этих проектах применялись разные модели разработки.
На текущий момент итерационная модель и Agile в целом — лучшее, что придумали с точки зрения доставки ценности (качества и скорости) пользователям. Остановимся именно на этих понятиях.
Сразу стоит оговориться, что гибкость Agile — это не избавление от рамок и всего того, что было лень делать при стандартном подходе. Многие воспринимают именно так, но это верный путь к провалу.
Как и любую философию, Agile нужно постичь. Как в любой философии, её принципы — это преувеличение, обнажение для того, чтобы было понятнее. Это не фреймворк, а потому применять его нужно осознанно.
1. Люди и взаимодействие важнее процессов и инструментов
Уклон в процессы слишком формализует и убивает горизонтальные коммуникации, значит снижает скорость доставки ценности. В таких компаниях пишут служебные записки и нужно поставить 10 подписей перед согласованием главным. Скорость доставки фич может упасть, иногда — до нуля.
В 2016 году мы начали разработку мобильного приложения для авиакомпании Utair. В начале сотрудничества внешний провайдер API работал только по заданию. Это усложняло коммуникацию между командами, и процессы длились дольше, чем нам хотелось бы. Мы настроили канал прямой коммуникации, ввели weekly scrum of scrums и тем самым достигли нужной синергии.
Но что будет, если полностью удариться в первую часть принципа — людей и взаимодействия, игнорируя вторую — процессы и инструменты? Люди будут решать все вопросы неконтролируемо и хаотично. Постоянное взаимодействие снизит эффективность и оставит ощущение, что ты ничего полезного не сделал. Очень быстро станет ясно, что, кроме взаимодействия, нужно ещё и работать.
Например, в какой-то момент мы столкнулись с ситуацией, когда разработчики стали жаловаться на частые отвлечения, потому что не хватало времени спокойно подумать над кодом. Мы прислушались и постепенно внедрили «часы тишины». Это время, когда разработчики могут спокойно кодить, не боясь, что их выдернут из процесса.
2. Рабочий продукт важнее исчерпывающей документации
Давайте подумаем, что будет, если наплевать на документацию? Получим быструю выгоду и большой риск, который принято называть bus-factor.
Теперь представьте, что в вашем full-agile проекте единственного бэкендера («больше и не надо, ведь ему иногда и так приходится тестировать») подкосила болезнь. Он, конечно, вернётся на проект, но только через месяц, когда окончательно поправится. Думаю, не нужно объяснять, что будет с проектом?
Если мы начнём упарываться в частую демонстрацию продукта, то рискуем выпасть из критического пути — порядка выполнения задач. Принцип Agile говорит «давайте быстрее продукт», и фреймворк Scrum реализует его как «давайте делать частые демо». Но это может серьёзно повлиять на порядок работы у разработчиков, особенно на больших проектах. Иногда, с точки зрения сроков, будет выгоднее выстроить критический путь так, чтобы было удобнее разрабатывать, а не показывать.
А что будет, если и шагу не давать без спеки и требований? Вероятностьрезиста выпуска проекта в срок будет крайне мала. Скорее всего, вы утоните в согласованиях.
Выход может быть следующим:
— начинать разработку на части требований;
— ретроспективно актуализировать требования, если они поменялись в ходе разработки.
3. Сотрудничество с заказчиком важнее согласования условий контракта
Тесное сотрудничество с заказчиком нужно для того, чтобы сформировать с ним доверительные отношения и его сопричастность к проекту. Чем больше заказчик участвует в процессе, тем больше он считает получившийся результат и своим тоже. Вместе с этим процессы разработки продукта становятся прозрачнее и уменьшаются риски, что проект не будет принят. Чувствуете разницу между тем, чтобы увидеть результат через полгода или быть в курсе развития проекта каждые 2 недели?
В заказной разработке эти два понятия — сотрудничество и согласование условий — не являются антагонистами. Скорее, они представляют собой два параллельных потока. В интересах компании следить за обоими: не законтрактуешься — не получишь денег.
У нас был кейс, когда мы сильно увлеклись вовлечением заказчика в проект и не успели вовремя согласовать новый скоуп работ. Это привело к тому, что 2 месяца остались не оплачены. Всё потому, что с крупным заказчиками документооборот занимает приличное время, а на государственных проектах вообще может требовать отдельного менеджера и команды. Lessons learned. Благодаря этой истории мы приняли решение передать процесс согласований условий контракта аккаунт-менеджерам.
4. Готовность к изменениям важнее следования изначальному плану.
На мой взгляд, это самый тяжёлый пункт, потому что тут замешана психология.
Строго следуя плану, рискуешь выпустить то, что будет не нужно. Люди, которые создают продукт, чувствуют дискомфорт, когда приходится работать в стол, откладывать релиз или бросать дело на полпути. Никому не нравится делать ненужную работу или выкидывать свой результат. Работая в геймдеве, я встречал даже слёзы, когда из-за банальной смены сеттинга пришлось завернуть целую линейку персонажей одной из художниц.
Не иметь вообще никакого плана ещё хуже. Есть риск заиграться с улучшениями и не выпустить проект, застряв на этапе «давайте вот это ещё допилим». Этот недуг я называю «релизная импотенция». Ей подвержены многие ПМ-ы, продакты и заказчики.
В итоге у нас получится примерно такая картина:
— полёт фантазии дизайнера на 15 релизов вперёд;
— суровая реальность в виде приложения, которое лишь в общих чертах напоминает требования и дизайн.
Остаток ваших коммуникационных скиллов вы потратите на тушение локальных подгораний QA-инженера и объяснения, что именно нужно тестировать. 5 спринтов в таком режиме — вас можно будет выносить.
Этот менеджер закончился — несите нового!
Каждый проект требует индивидуального подхода. То, что работало на одном, может не сработать на другом. Чтобы классно управлять проектами, PM ищет золотую середину в каждом принципе Agile, отталкиваясь от конкретного кейса.
Источник статьи: https://habr.com/ru/post/568906/
Весной мы проводили первую стажировку по проджект-менеджменту. На первой лекции я рассказывал, что такое проект для настоящего PM и какие методологии нужно использовать, чтобы уверенно им управлять. Решил поделиться материалом с вами.
Чем он может быть полезен? Вы сможете проверить свою осознанность, начать строить мост над пропастью между теорией и практикой, возможно — избавиться от стереотипов. Материал прежде всего ориентирован на джунов в PM, но будет полезен и другим IT-специалистам. Развеем миф, что попугая можно повысить до PM, если научить его говорить «ну что там?»
Что такое проект?
Классическое определение звучит так: проект — это временное мероприятие с целью создания уникального продукта или результата.Но для прожект-менеджера этого недостаточно: нужно всегда учитывать содержание проекта, стоимость и время работ. Эти элементы называются тройственной ограниченностью.
Суть треугольника заключается в том, что нельзя выбрать всё сразу — нужно стараться соблюдать баланс между элементами. В зависимости от задач и процессов проекта можно выбрать два ограничения, жертвуя при этом третьим.
Много, дёшево и быстро не получится, хотя это принципиальная позиция многих заказчиков. Здесь советую познакомиться с армянской народной сказкой «Жадный Вартан» — она наглядно иллюстрирует, что бывает в таком случае.
Определение проекта для настоящего PM:
Мероприятие по созданию продукта или результата в конкретные сроки, бюджет и с надлежащим качеством и/или определённым скоупом.
Карта звёздного неба менеджера
Agile — философия (система ценностей, гибкий образ мышления, mindset), которая помогает разработчикам делать новые продукты быстрее и качественнее с точки зрения бизнеса.Scrum — набор инструментов, фреймворк, с помощью которого реализуется Agile-подход. В Scrum работа ведётся спринтами — одинаковыми по продолжительности итерациями.
Kanban — метод управления разработкой и визуализации процессов. Точно определяет, что нужно производить, когда и сколько. Исторически канбан — просто доска, сейчас из него делают отдельный фреймворк — канбан-метод.
Waterfall — условно существующая каскадная модель разработки. Здесь процесс воспринимается как поток, а переход от одного этапа к другому происходит только после успешного завершения предыдущего.
Эти понятия пересекаются и взаимодействуют между собой следующим образом:
Какой подход выбрать?
Глобально существует 2 модели разработки: каскадная и итерационная.Каскадная модель разработки предполагает последовательное прохождение этапов: анализ требований, проектирование, реализация, тестирование, интеграция и поддержка. Переход от одной фазы к другой невозможно без полного завершения предыдущей.
Ей противостоит итерационная модель, когда создание продукта осуществляется параллельно с непрерывным анализом результатов и корректировкой предыдущих этапов работы. Чаще всего такая модель выбирается, когда на первых этапах не определить общий объём работ.
В качестве примера могу привести 2 проекта из нашего портфеля: Whiskas и Utair. На первом была чёткая дата релиза, понятный скоуп и ограниченный бюджет. На втором — неопределённая дата релиза, бэклог задач на полтора года и нефиксированный бюджет, который рассчитывался из количества часов, потраченных командой в месяц.
Разумеется, на этих проектах применялись разные модели разработки.
На текущий момент итерационная модель и Agile в целом — лучшее, что придумали с точки зрения доставки ценности (качества и скорости) пользователям. Остановимся именно на этих понятиях.
Сразу стоит оговориться, что гибкость Agile — это не избавление от рамок и всего того, что было лень делать при стандартном подходе. Многие воспринимают именно так, но это верный путь к провалу.
Agile ≠ Лень ≠ Серебряная пуля
Как и любую философию, Agile нужно постичь. Как в любой философии, её принципы — это преувеличение, обнажение для того, чтобы было понятнее. Это не фреймворк, а потому применять его нужно осознанно.
Разберём 4 основополагающих принципа Agile и рассмотрим случаи перекоса в одну или другую часть утверждения
Чтобы было проще понять принципы Agile, я буду давать много примеров. Пусть это чужой опыт и его эффективность низка, но точно лучше теории.1. Люди и взаимодействие важнее процессов и инструментов
Уклон в процессы слишком формализует и убивает горизонтальные коммуникации, значит снижает скорость доставки ценности. В таких компаниях пишут служебные записки и нужно поставить 10 подписей перед согласованием главным. Скорость доставки фич может упасть, иногда — до нуля.
В 2016 году мы начали разработку мобильного приложения для авиакомпании Utair. В начале сотрудничества внешний провайдер API работал только по заданию. Это усложняло коммуникацию между командами, и процессы длились дольше, чем нам хотелось бы. Мы настроили канал прямой коммуникации, ввели weekly scrum of scrums и тем самым достигли нужной синергии.
Но что будет, если полностью удариться в первую часть принципа — людей и взаимодействия, игнорируя вторую — процессы и инструменты? Люди будут решать все вопросы неконтролируемо и хаотично. Постоянное взаимодействие снизит эффективность и оставит ощущение, что ты ничего полезного не сделал. Очень быстро станет ясно, что, кроме взаимодействия, нужно ещё и работать.
Например, в какой-то момент мы столкнулись с ситуацией, когда разработчики стали жаловаться на частые отвлечения, потому что не хватало времени спокойно подумать над кодом. Мы прислушались и постепенно внедрили «часы тишины». Это время, когда разработчики могут спокойно кодить, не боясь, что их выдернут из процесса.
2. Рабочий продукт важнее исчерпывающей документации
Давайте подумаем, что будет, если наплевать на документацию? Получим быструю выгоду и большой риск, который принято называть bus-factor.
Теперь представьте, что в вашем full-agile проекте единственного бэкендера («больше и не надо, ведь ему иногда и так приходится тестировать») подкосила болезнь. Он, конечно, вернётся на проект, но только через месяц, когда окончательно поправится. Думаю, не нужно объяснять, что будет с проектом?
Если мы начнём упарываться в частую демонстрацию продукта, то рискуем выпасть из критического пути — порядка выполнения задач. Принцип Agile говорит «давайте быстрее продукт», и фреймворк Scrum реализует его как «давайте делать частые демо». Но это может серьёзно повлиять на порядок работы у разработчиков, особенно на больших проектах. Иногда, с точки зрения сроков, будет выгоднее выстроить критический путь так, чтобы было удобнее разрабатывать, а не показывать.
А что будет, если и шагу не давать без спеки и требований? Вероятность
Выход может быть следующим:
— начинать разработку на части требований;
— ретроспективно актуализировать требования, если они поменялись в ходе разработки.
3. Сотрудничество с заказчиком важнее согласования условий контракта
Тесное сотрудничество с заказчиком нужно для того, чтобы сформировать с ним доверительные отношения и его сопричастность к проекту. Чем больше заказчик участвует в процессе, тем больше он считает получившийся результат и своим тоже. Вместе с этим процессы разработки продукта становятся прозрачнее и уменьшаются риски, что проект не будет принят. Чувствуете разницу между тем, чтобы увидеть результат через полгода или быть в курсе развития проекта каждые 2 недели?
В заказной разработке эти два понятия — сотрудничество и согласование условий — не являются антагонистами. Скорее, они представляют собой два параллельных потока. В интересах компании следить за обоими: не законтрактуешься — не получишь денег.
У нас был кейс, когда мы сильно увлеклись вовлечением заказчика в проект и не успели вовремя согласовать новый скоуп работ. Это привело к тому, что 2 месяца остались не оплачены. Всё потому, что с крупным заказчиками документооборот занимает приличное время, а на государственных проектах вообще может требовать отдельного менеджера и команды. Lessons learned. Благодаря этой истории мы приняли решение передать процесс согласований условий контракта аккаунт-менеджерам.
4. Готовность к изменениям важнее следования изначальному плану.
На мой взгляд, это самый тяжёлый пункт, потому что тут замешана психология.
Строго следуя плану, рискуешь выпустить то, что будет не нужно. Люди, которые создают продукт, чувствуют дискомфорт, когда приходится работать в стол, откладывать релиз или бросать дело на полпути. Никому не нравится делать ненужную работу или выкидывать свой результат. Работая в геймдеве, я встречал даже слёзы, когда из-за банальной смены сеттинга пришлось завернуть целую линейку персонажей одной из художниц.
Не иметь вообще никакого плана ещё хуже. Есть риск заиграться с улучшениями и не выпустить проект, застряв на этапе «давайте вот это ещё допилим». Этот недуг я называю «релизная импотенция». Ей подвержены многие ПМ-ы, продакты и заказчики.
Но есть и обратная сторона гибкости
Если мы будем придерживаться гибкости на каждом этапе разработки — она будет расти в геометрической прогрессии. Гибкости перемножатся!
В итоге у нас получится примерно такая картина:
- Аналитик написал требования сразу на весь скоуп фичи, включая кейсы за пределами оговорённого скоупа.
- Дизайнер нарисовал флоу таким, каким оно будет через 15 релизов.
- Бэкендер сделал один метод из необходимых 4. Причём по ходу разработки изменил вложенность и типы переменных, потому что так «правильней».
- Разработчику на пальцах объяснили, что нужно сейчас делать, а что может подождать до 15 релиза. Он сделал задачу, попутно договорившись на словах с дизайнером об элементах, которые он забыл отрисовать.
- А теперь давай представим, что это дошло до QA:
— полёт фантазии дизайнера на 15 релизов вперёд;
— суровая реальность в виде приложения, которое лишь в общих чертах напоминает требования и дизайн.
Остаток ваших коммуникационных скиллов вы потратите на тушение локальных подгораний QA-инженера и объяснения, что именно нужно тестировать. 5 спринтов в таком режиме — вас можно будет выносить.
Этот менеджер закончился — несите нового!
И что делать?
Соблюдать разумный баланс и искать золотую середину.Каждый проект требует индивидуального подхода. То, что работало на одном, может не сработать на другом. Чтобы классно управлять проектами, PM ищет золотую середину в каждом принципе Agile, отталкиваясь от конкретного кейса.
Источник статьи: https://habr.com/ru/post/568906/