Немного вступления (не самореклама): в далёком 2003 году я пришёл работать юным программистом в бухгалтерию, пришлось изучать матчасть области в которой нужно кодить и спустя 2 года бухгалтерия поглотила меня. Минуло лет 15, я уже успел вырваться из лап бух.учёта, вызывает меня как то руководитель и начинает говорить про модные слова: цифровую трансформацию, проектное управление, Agile и прочее. Выяснилось, что мне предстоит собирать команду и развивать эти направления в компании.
Прошли годы, было перечитано тонны статей, часы видеоуроков, обсуждено с коллегами сотни митингов, набито много шишек на практике. Но пришёл опыт того, что работает и не работает в проектном управлении. А также осознание, что каждый этап нашей жизни и каждая работа проект, а не процесс.
Итак, попробую пройтись по основным тезисам. Кому то что то может показаться очевидным, но буду рад, если кому то принесёт пользу.
Тезис 1. Соревнования Waterfall и Agile не существует
Так же, как не существует соревнования молотка и отвёртки. У каждого своё предназначение. Мы ищем инструмент для решения задачи, а не наоборот. Утрирую, но всё же многие привыкли ассоциировать:
Waterfall – дорожные карты, паспорта проектов, матрицы ролей, карты рисков и ещё груда прочей документации с детальными ТЗ на множество листов. И месяцы подготовки всего этого. И не факт, что после этого, что то реализуется.
Agile – содружество позитивных айтишников и бизнеса, которые за чашечкой кофе придумывают в бэклог очередную фичу и за день(неделю) её уже внедряют для пользователей.
Увы, но 50/50 оба утверждения как верны, так и не верны. Почему? Читаем дальше)
Тезис 2. Waterfall не догма, что строго по PMBoK
PMBoK как свод знаний по управлению проектами весьма детально и дотошно описывает нам структуру проекта, этапы и документацию, которая должна появляться. И одной из моих ошибок было в своё время «действовать по учебнику». Почти не работает, нудно, долго и дорого. Однако, это помогло взять от него самое полезное для основной массы проектов в сокращённом виде:
В дорожных картах потребность уже давно почти никто не отрицает. Нужно обязательно, даже если в команде один человек и проект это переезд из точки А в точку Б. План действий как чек-лист лишним не будет;
Из паспорта проекта обязательно нужны цели (максимум по SMART), треугольник (контент-бюджет-сроки), требования к MVP, помимо целей неплохи и допущения (что точно не делаем);
Разбивку на этапы с ощутимым результатом и критериями его приёмки (где-то запахло спринтами);
Ролевая модель, очень важно понимать всем кто/что делает на проекте и что не делает.
Тезис 3. Agile не значит, что никакой документации
Agile манифест многие читали, но и поняли многие по разному. Ориентация на результат не означает, что в проекте не нужна документация, что ТЗ – зло, ровно как и комментарии в коде. Нужен баланс (снова бухгалтерия в голове) между быстрым результатом и пониманием, что продукту ещё жить годами. В том числе будут меняться команды, и натыкаясь на легаси код без артефактов будут заниматься не развитием продукта, а очередным рефакторингом (когда упёрлись в потолок) или вообще переписыванием с нуля.
Тезис 4. Часть команды, часть корабля
Не смотря на избитость фразы, она по прежнему актуальна. Важно всё: микроклимат, ритуалы от kick-off (вводной встречи на проекте) до дейли/викли митингов, от демо пользователям до ретро (когда то его называли бы разбором полётов). Нужен контакт, как внутри команды, так и с внешними участниками: заказчиками, вендорами и т.д. Что делать для этого и ка мотивировать, при условии, что нужно ещё и работу делать по проекту? Пробовать находить подход, разговаривать как в варианте One-to-one, так и групповые обсуждения. Модерировать и фасилитировать не только встречи, но и конфликты, причём чем раньше, тем лучше. Но начинать аккуратно, не все готовы критиковать или слушать критику, раскрываться и говорить как есть. Есть и множество около или вне рабочих активностей, которые могут внести единение и командный дух: геймификация, оранжевые пятницы, совместные мероприятия, стендапы.
Тезис 5. Учиться, учиться и ещё раз учиться (с)
Если хотите быть ментором для своей команды и вовлекать людей в процесс, то начинать нужно с себя. В том числе составлять свой ИПР с метриками и ретроанализам как эффективности того или иного способа обучения, так и полезности тех или иных приобретенных хард/софт скиллов. Как говорил мой преподаватель по геодезии: "Лишняя профессия за плечами не тянет". Не стесняйтесь развиваться в соседних отраслях, расширяйте кругозор, это обязательно пригодится. Исходя из этих же соображений переходите к ИПР членов команды. Здесь то же нужно учитывать и релевантность программы обучения и то, что большая часть обучения идёт в ходе работы и использования гугла. Не стесняйтесь помогать, но помощь не должна быть непрошенной и тем паче высокомерной.
Тезис 6. Учиться на ошибках и признавать их
Думаю это боль многих вне зависимости от возраста. PM/начальник/тимлид конечно эксперт по многим вопросам, но это не значит, что не погрешим. Поверьте, объективное признание своей неправоты при команде не роняет ваш ранг, а наоборот повышает градус доверия. Ретроспектива очень помогает выявить причины ошибок и вырабатывать превентивные меры. Главное на этом не останавливаться, а вносить это в общую базу знаний (F.A.Q.), ибо память человеческая так устроена, что невольно свои промахи стараемся забыть. Могут также помочь отдельные практики из психологии.
Тезис 7. Абстрагирование
Я часто привожу пример при кинофильмы, когда камера показывает человека, а потом плавно отъезжает в космос. Так же необходимо поступать с анализом любой задачи, смотреть шире, на пересекающиеся процессы, на соседние сервисы, на используемые данные. А вот тут начинает помогать кругозор, как общий, так отраслевой и предметный.
Тезис 8. Хороший план сегодня лучше идеального завтра (с)
Этот тезис для перфекционистов, а также для людей, думающих, что они точно не такие. Можно бесконечно писать самое полноценное ТЗ или красивое юзер стори или идеально оптимизированный код, но продукт/фича всегда нужны вчера, в лучшем случае сегодня. Старайтесь заставлять себя есть слона по частям, подходить итерационно к реализации задачи, при этом не теряя фокус на финальной цели. Здесь снова вспомним про комбо Waterfall и Agile.
Тезис 9. Разработка и проектное управление это тоже бизнес-процесс
Всем известна картинка про качели, ТЗ и программиста. У любого бизнес процесса всегда есть начало, действия участников и завершение (не всегда с результатом). Есть множество вариаций как этапов проекта, так и процесса разработки. Остановлюсь этапах разработки какой либо фичи: начало(появилась задача или идея), интервью (поиск и опрос стейкхолдеров), аналитика (при этом также важно абстрагироваться от навязанного пользователем способа реализации и понимать точно зачем это делается), ревью и пользовательское и техническое согласование требований (бизнес, системных, ТЗ, юзер стори и т.д.), сама разработка и архитектурные/инфраструктурные изменения, техническое тестирование (самими разработчиками, в т.ч. между собой), функциональное (тот, кто писал ТЗ должен понять, что вообще то получилось, демо или пользовательская приемка, внедрение (перенос в прод, обучение, сбор обратной связи, бэклог пожеланий багфиксов)
Тезис 10. Вместо эпилога
Конечно ещё о многом хотелось бы поделиться, но тогда это уже вышло бы за рамки статьи. Так что тезисы в данном случае ими и останутся, не претендуя на полноту, не отвечая на вопрос как, но дая рекомендации что нужно делать.
Интересных вам проектов, прокачки полезных скиллов, самоорганизующихся команд и позитивного невыгорания. Как говорят в интернете: подписывайтесь, ставьте лайки.
