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

Дмитрий Бельков

Возможно, ты начинаешь руководить проектом. И тебе нужна понятная практика, а не теория. В книге собраны ответы на 26 реальных вопросов — с чего начать проект, как писать письма заказчику, можно ли менять озвученные решения и многие другие.Одна глава — ответ на один вопрос. Просто, понятно, с конкретными советами и примерами. Можешь смотреть оглавление и шагать сразу на нужную страницу. Но лучше прочитать последовательно. Так картинка у тебя в голове будет стройнее и полнее. Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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