Решебник начинающего руководителя проекта

Что произойдет, если ты этого не сделаешь? Да все, что угодно. В зависимости от того, чей именно контекст не был учтен. Чаще всего делается проект из контекста «Сдать и получить 5». А значит, и результат дальше защиты не идет. Он достигнет своего контекста и благополучно скукожится. Но может выстрелить другой риск, когда представитель любой стороны проекта, контекст которого мы не учли, может спровоцировать полную остановку проекта в середине процесса, и ты не достигнешь даже минимального результата.

И это мы еще не окунулись в конкретику описания Результата с точки зрения проекта в части функциональных и нефункциональных требований, архитектуры, стека технологий и т. д. Пока мы только описали контекст результата и его важные аспекты, которые надо будет учитывать в работе. А именно:

– Мы очертили границы будущего результата. Поняли, что делаем в принципе, а чего не будем делать точно.

– Мы поняли основной интерес и мотивацию каждой стороны проекта.

– Мы утвердили приоритеты и ограничения, а также образ будущего проекта (после наступления «нашего» результата).

Все это поможет нам в формулировке «правильного» результата и в расчете достижимого «Как сделать результат» (т. е. его плана).

Если тебе удалось сформулировать и утвердить со всеми сторонами контекст проекта, поздравляю! Ты достигла первого промежуточного результата. Твоя система уже появляется на свет. Да, пока она выглядит как набор тезисов, правил, ограничений, но это уже она – единственная и неповторимая в своем роде. Дальше тебе придется все время держать этот контекст в голове и с каждым шагом, задачей, собранием, рабочим днем своего проекта двигать результат от «абстракции» к реальной рабочей системе.

Зачастую команда на старте уходит в обсуждение процессов, подходов, технологий, дизайна, мотивации и маркетинга. Все это можно и нужно обсуждать, но только в контексте полученного результата! В нашем кейсе результат – это информационная система, которая автоматизирует конкретные бизнес-процессы и сценарии работы.

Результат важнее процессов!

Исходя из этого выставляй приоритеты, разрешай споры и фокусируй работу.

Повторим в очередной раз главное, что надо запомнить из этой главы:

– Главное – результат.

– Результат должен быть получен в определенный срок.

– В распоряжении у тебя есть люди, их квалификация, инструменты и крайне ограниченные другие ресурсы.

– Обсуждение деталей проекта должно проходить в контексте планируемого финального результата.

Помни об этом постоянно, пока выполняешь роль менеджера.

За что отвечаю я? \ Роль менеджера проекта

Люди разные нужны, люди разные важны! Если именно так перефразировать стихотворение Сергея Михалкова, то точно попадешь в корпоративную политику большинства компаний из отрасли информационных технологий.

Так случилось, что в IT основной ресурс, используемый при выполнении проектов, – это интеллект. Мы не будем называть членов команды «ресурсами», потому что это обидно. Но на наших с тобой графиках и расчетах проекта будет именно так. Каждый член команды вносит свой интеллектуальный вклад в результат, и он, вклад, зависит от роли, которую принял на себя участник проекта в команде.

Давай прикинем, какие бывают роли в проектах и какого вклада ждать от каждого представителя команды.

– Разработчик – «производитель» программного кода и, собственно, создатель программного продукта. Именно он создает осязаемый результат. Главный его вклад – регулярное производство новых функций и возможностей в финальном продукте.

– Ведущий разработчик / техлид – тот же разработчик, но способный принимать архитектурные и сложные технические решения относительно разработки. Как правило, это самый опытный из разработчиков, хлебнувший горя (зачеркнуто) и сделавший несколько реальных проектов. Его вклад в результат – организация разработки от локального кода до выкладки в промышленную эксплуатацию, качество кода, его документирования, технические метрики продукта, показывающие, что система «жива». Этот специалист отвечает за непрерывность, скорость и качество написания кода всеми разработчиками.

– Аналитик, дизайнер, архитектор, проектировщик – довольно близкие по смыслу роли. Это специалисты, способные представить будущий продукт в виде модели: процессов, сценариев, дизайнов интерфейса, модулей, сервисов, объектов и компонент. Зачем? Да чтобы уменьшить вероятность ошибки в разработке. Чем шире и качественнее проведено предварительное моделирование, тем меньше вероятность, что разработчики «выбросят» уже написанный код из-за появившихся уточнений/требований.

Их результат – архитектурная схема, концепция, описание сценариев и состав пользовательских экранов, постановка задачи в разработку.

– Тестировщики, они же QA/QC-специалисты, они же специалисты по контролю качества. Их ключевая цель – дать вселенной увидеть ровно тот результат, который нужен на самом деле. Их результат – отсутствие замечаний и ошибок в будущей системе и факт того, что система работает «как надо», т. е. поддерживает целевые процессы.

– DevOps-инженер организует и настраивает инфраструктуру как для самой команды, так и для будущей реальной системы. На старте, как правило, тесно работает с техлидом, чтобы организовать рабочее пространство команды так, как тот задумал. Его результат – правила сборки кода каждого разработчика в общий репозиторий и настроенные окружения:

– DEV, т. е. для разработки;

– QA для тестирования;

– UAT (user acceptance testing), предназначенный для приемки продукта.

– Менеджер. Это ты. И у тебя много дел. Давай попробуем обозначить основные твои обязанности и результаты:

– Контроль достижения результата – ты должна осознавать, как команда дойдет до результата, отслеживать изменения на этом пути. Твой результат – это достижимый план проекта и его регулярная актуализация.

– Работа с рисками – ты должна предвидеть ситуации, негативно влияющие на результат, и устранять или уменьшать их. Твой результат – это когда команда достигает поставленных по плану ключевых результатов, отрабатывая риски на уровне мелких работ.

– Работа с качеством – полученный результат должен соответствовать как ожиданиям качества от заказчика, так и собственным требованиям к качеству команды, например, таким, как качество кода, качество документации и базы знаний, тестовых сценариев. Каждый проектный результат проверен и соответствует заявленному качеству: протестирован, продемонстрирован, подтвержден опытным путем и т. д.

– Работа с коммуникациями – выстраивание всех коммуникационных потоков в проекте: как внутри, так и наружу. Результат: отсутствие простоев или лишней работы из-за «не договорились», отсутствие конфликтов с внешними относительно команды ролями.

Это роли. От проекта к проекту каждая роль может исполняться отдельным человеком или один человек может подхватывать несколько ролей. Помни: каждый новый специалист «съест» кусочек ресурса проекта. Ты должна понимать, каким результатом для команды обосновано присутствие в ней каждого участника.

Не в каждом проекте нужен выделенный представитель каждой роли. Оцени необходимость в результате каждой роли и прими решение, насколько она важна, критична для этого проекта.

Акцент твоей работы в роли менеджера будет меняться по ходу проекта:

– Старт проекта. Ничего не понятно, результат существует в виде общей концепции, риски «не получить результат в конце» максимальны. Ты акцентируешь свое внимание на понимании архитектуры/концепции и построении плана проекта. Выстраиваешь основные потоки коммуникаций. Основная задача – выйти из предпроектного тумана «ничего не понятно» и перейти в штатный режим работы.

– Проект. Когда работа встает на стабильные рельсы и разработчики начинают «строгать» фичи, а также появляются осязаемые кусочки результата, ты переключаешься на контроль и управление ожиданиями: демонстрируешь промежуточные результаты, получаешь уточнения и новые вводные, актуализируешь путь к успеху, т. е. план проекта. Это этап производства – тебе надо в заявленные сроки и с ожидаемым качеством прийти к целевому результату.

– Завершение проекта. Когда же проект близится к финалу и кусочки соединяются в итоговое решение, ты переключаешься на качество во всех его проявлениях и на введение решения в эксплуатацию. Основная задача – запустить решение в эксплуатацию. А значит, оно должно работать, и работать хорошо. А пользователи должны хотеть им пользоваться.

Этап проекта диктует менеджеру, как отрабатывать риски и планы, ускорять поставки и управлять изменениями, как шлифовать качество и оформлять результат.

Я намеренно не упоминаю выше такие пункты, как «проведение дэйли», «совещания» и «заведение задач»: ведь сами по себе эти действия не несут результата – это всего лишь инструменты, которые команда может применять, а может и не применять для улучшения своего результата.

Итак, краткие тезисы этой главы:

– Ролей в команде разработки много. Каждая – для своего результата. Определи целевой результат и, исходя из него и доступной команды, распредели роли.

– Роль не равно человек. Береги ресурсы, если проекту не нужна/не ценна работа какой-то роли.

– Роль менеджера – в достижении общего результата.

– Акценты в твоей работе зависят от текущего состояния результата всего проекта.

Ну все понятно, а начинать-то с чего? \ Старт проекта

Как гласит один из законов Мерфи, «все, что хорошо начинается, кончается плохо. Все, что плохо начинается, кончается еще хуже».

От правильного старта проекта зависит довольно многое. Чем лучше подумать на старте, тем меньше потом придется переделывать. Это совершенно не значит, что надо долго думать и мало делать. Делать-то как раз надо много, и с самого начала.