Ну, что) продолжим наше общение)))

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

В любой крупной компании, и даже на уровне государства, существуют Стандарты по проектной деятельности, которые призваны стандартизировать и систематизировать проектную документацию и организацию работы по разработке ПО.

Очень часто, это солидные документы, с огромным количеством подписей и согласований, на создание которых тратится время, сопоставимое со временем потраченным на разработку ПО, по которому готовится документация. А если потребуется внесение изменений, то получается еще один виток согласований, а то и не один (далеко не один). А когда в согласовании таких документов участвуют подразделения, которые никак не заинтересованы в результатах проекта, или, например, руководители таких подразделений выстраивают целую систему «пыток и унижений» для подразделений участников согласований, прикрываясь регламентами и инструкциями, теша своё самолюбие и расширяя уровень собственной значимости и ввысь и в ширь, то процесс согласования становится очень мучительным и сложным и совсем теряет связь с разработкой ПО. При этом весь этот процесс согласования документации не гарантирует ни качество, ни нужный результат для Функционального заказчика.

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

Что же нужно РП и команде проекта, чтобы был нужный результат, в нужные сроки и в рамках заявленного бюджета?

Первое, должен быть документ, с которого всё начинается. Это могут быть ФТТ (Функционально-технические требования), это может быть ТЗ (Техническое задание), Протокол, Мемо, Презентация, любой документ, где определены границы реализации проекта. Из этого документа должно быть всем понятно, хотя бы примерно, Что мы делаем (Функциональный объем), С кем мы делаем (Организационный объем), Когда мы делаем (сроки). В идеале этот документ написан простым языком, понятным в первую очередь ФЗ (Функциональному заказчику). Документ должен быть согласован с двух сторон (Заказчик и Исполнитель).

Второе, на основании первого документа, составляется Дорожная карта проекта. Конечно, MS Project прекрасен, но реально свою роль он выполняет только на небольших проектах, где все работы можно разместить на листе А4, не более, потому что, когда список работ переваливает за 1000, а то и за 100, в нём уже теряется суть, смысл и связь))) Но тут я не настаиваю, дело вкуса и привычки, но ни на одном моём проекте MS Project не просуществовал от начала и до конца проекта, конечно, я говорю про проекты длительностью от года и высокой степенью трудоёмкости. Дорожная карта должна представлять из себя простой график, в идеале на одном слайде презентации, где выделены основные этапы реализации проекта с календарными сроками, например – Сбор/детализация требований (Уточняем первый документ), Проектирование (Решаем как, на чем, с кем и что делаем), Разработка (Делаем, что определили), Тестирование, ОПЭ, ПЭ. Детализация сроков, в зависимости от длительности проекта – месяц/квартал/полугодие/год. На этой дорожной карте также рекомендую отмечать периоды привлечения Заказчика, чтобы сюрпризов не было)). Этот документ также обязательно должен быть согласован с двух сторон (Заказчик и Исполнитель).

Третье, простое, на первый взгляд – Контактная карта проекта), где указан актуальный список всех участников проекта, с указанием Ролей в проекте и функциональностей в ответственности, а также телефоны и почта. Казалось бы, что тут такого)))? Но! У меня был такой проект в опыте, который шел не один год, так там команда, не только не знала всех участников со своей стороны, но не знала и Заказчика, к кому и с каким вопросом можно обращаться), что порождало постоянное недовольство со стороны Заказчика, что и привело проект в итоге к грустному вялотекущему финалу. Такой документ нужен и внутри команды, для понимания распределения ответственности и ролей в команде, для понимания контактов, чтобы найти нужного эксперта, а также, как, к кому и с каким вопросом можно обращаться на стороне Заказчика. Этот документ также полезен для любого нового участника команды. Для крупных Заказчиков полезен такой документ, как Матрица ответственности, т. к. в нём прописывается, кто за что отвечает и кто и что согласовывает (они же не знают без этого документа).

Четверное, конечно же, План График проекта. Это основной инструмент Руководителя проектов. В зависимости от взаимоотношений с ФЗ, этот документ можно вести или в максимально понятном виде для Исполнителя, или же для Заказчика, чтобы сам процесс реализации был прозрачен для двух сторон. Но! Опять же, моё субъективное профессиональное суждение – он тоже не должен быть избыточным. Да, он более детальный чем Дорожная карта, да, там уже есть конкретные даты и конкретные фамилии ответственных, но он тоже не должен быть нечитабельным и неинформативным. Он тоже должен быть понятным и простым для восприятия всех участников проекта, а главное, каждому эксперту должно быть понятно, к какой дате он должен сделать свой объем работ.

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

Шестое, Карта рисков, Текущий статус. На каждом проекте, который планирует быть успешным, проходят постоянные статусы с Заказчиком. Где, по-хорошему, в рабочей атмосфере обсуждается текущий статус, проблемы, риски, методологические вопросы. Т. е. происходит своеобразная сверка понимания, в т. ч. на уровне руководства, где мы находимся, что делаем, какие нужны ресурсы и какие есть риски. А если есть риски, значит должна быть определена фамилия, которая нивелирует эти риски, что и должно быть зафиксировано в работающей Карте рисков. Я видела на проектах Карты рисков в объеме, сопоставимом с нетленным произведением «Война и Мир», но это тоже не гарантировало успешности проекта, поэтому, просто, понятно, доступно и с указанием ответственного, это должно быть в Карте рисков и в отчете по Текущему статусу проекта.

Седьмое, Общий ресурс проекта. В каждом проекте обязательно должно быть общее хранилище всей документации. Там должны храниться все документы, презентации, протоколы, мемо и пр. Т. е. – вся история любой документации по проекту. К сожалению, иногда приходится что-то доказывать ФЗ, почему мы сделали именно так, а в этом как раз и помогают зафиксированные договоренности, которые находятся на общем ресурсе, и опять же, это нужный ресурс для всей команды, тем более для новых участников)

Вот, как-то так)

Прям получилось семь, как Семь чудес света, пусть это будет Семь необходимых инструментов для Руководителя проектов, чтобы увидеть Свет в конце проекта))))