Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание Вперёд

Глава IX. Планируем ответственность, коммуникации, качество

Входы:

• Концепция проекта
• ИСР (WBS) и ресурсы, распределенные по работам
• Команда проекта

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

Распределяем ответственность

Что мне делать дальше?

В предыдущей главе мы говорили о том, как распределяются ресурсы по работам (шаг 4). Одновременно с таким «назначением» распределяется и ответственность за выполнение конкретного пакета или действия.

Если вы действительно привлекали команду к формированию ИСР (WBS) и прочим элементам планирования – то каждый сотрудник уже «в курсе», за какие работы ему придется взяться и в какие сроки уложиться. Не думайте, что ПМ на этом можно остановиться!

Представьте, что произойдет, если вы дадите страт выполнению работ прямо сейчас? Действительно ли каждый член команды понимает, за какую работу браться первой? А что делать, когда он ее закончит? А если одна работа должна выполняться после другой – как понять, что соответствующий этап выполнен и можно приступать?

Каждый член команды должен знать свои приоритеты и понимать где их можно посмотреть, а также откуда почерпнуть уточняющую информацию (помните – ИСР, ИСР-словарь, результаты обследования?). На вашем проекте могут действовать различные правила: «сделал работу – позови – покажи – берись за следующую», или «сделал первое по списку – отпишись – берись за второе». Возможно, «младшие» члены команды будут уточнять постановку у более опытных.

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

Помните, раздавать поручения в фазе исполнения проекта – не работа ПМ!

Я еще за что-то отвечаю?

Помимо самих работ – обратите внимание на распределение ответственностей за то, что не находит отражения в ИСР (WBS).

Вы помните, что ИСР (WBS) – это работы по созданию продукта? Он может не включать отдельных работ по контролю качества, по выявлению и отслеживанию рисков и т.д. Найдите способ договориться с командой о распределении ответственностей такого рода.

Фиксируйте договоренности. Сделайте это для каждой области знаний или для каждой роли вашей команды.

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

Матрица ответственности может выглядеть, следующим образом:

	Член команды:	Олег	Василий	Петр
Работа:
Выявление и отслеживание рисков			Г	В
Контроль качества продукта			В	Г
Ведение переговоров в фазе инициации		В	Г
…

Г – главный ответственный, В – вспомогательный ответственный

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

Постарайтесь не оставить «белых пятен». Все аспекты проекта должны иметь своего исполнителя, если это не вы – позаботьтесь, чтобы он был назначен.

Планируем коммуникации

Распределяя ответственность – самое время договориться о коммуникациях.

Этот, во многом интуитивно-понятный аспект управления проектом, по некоторым данным, отнимает у ПМ до 90% его рабочего времени. Правильно спланированные коммуникации помогут вам серьезно снизить собственные трудозатраты.

Очень существенным является выбор метода. Будет ли общение на ту или иную тему вестись устно или письменно? В последнем случае – требуются ли согласовательные подписи (и чьи) или можно ограничиться сообщением по электронной почте? Важен ли формат такого письма?

Руководствуйтесь здравым смыслом.

Наиболее существенные аспекты коммуникаций, которые всегда стоит оговаривать в любом проекте это:

• Отчеты команды о выполненных работах
• Методы коммуникаций с представителями заказчика и пользователями
• Коммуникации со спонсором

Отчеты команды о выполненных работах.

Отчеты должны быть организованы наиболее удобным для обеих сторон способом. Их необходимо адаптировать к конкретным используемым на проектах методологиям (так, при разработке ПО согласно методологии «водопад» отчеты о выполнении работ будут драматически отличаться от таковых, если применяются «гибкие» (Agile) методики).

Однако, есть несколько общих правил, которых стоит придерживаться на любом проекте:

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

Во-вторых, не заставляйте людей без нужды много писать. Отчет о результатах должен разумно соотноситься по трудоемкости с самим результатом. Учтите также, что, подавляющее большинство технических специалистов не любят писать и сочинять документы. Для них вы можете использовать это как «наказание» («кто забыл прислать отчет – в следующий раз пишет эссе на пол страницы за всю команду»); однако не демотивируйте таких людей с самого начала. Если вам нужна цифра (сколько тебе осталось по задачке в часах?) – просите цифру и все. Если нужны комментарии – позвоните, или оставьте их на усмотрение разработчика. Помните, не все одинаково относятся к созданию даже коротких текстов.

Методы коммуникаций с заказчиком

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

Аналитику понадобилось съездить на объект и еще раз переговорить с пользователем – можно ли ехать сразу? Или позвонить пользователю и уточнить удобное время? Или обязательно каждый раз договариваться с его начальником?

А что если возникли вопросы к самому заказчику (скажем, директору крупного завода)? Удобно ли ему позвонить на мобильник? Или через секретаря? Или послать вопрос почтой? Или по всем вопросам за заказчика решения принимает его заместитель, и директора лучше вовсе не беспокоить?

Нарушение гласных и негласных правил предприятия – в долгосрочной перспективе ни к чему хорошему вас не приведет. Определите «правила игры» на поле заказчика и доведите их до всей команды. Это существенно снизит количество и уровень потенциальных конфликтов.

Коммуникации со спонсором

Главное, что интересует спонсора в ходе выполнения проекта – укладывается ли тот в треугольник сейчас и сохранится ли это по окончании проекта? Как правило, нюансы хода работ спонсора не очень волнуют (для этого он нанял вас).

Оговорите со спонсором до фазы исполнения – как именно вы будете держать его в курсе. Обычно, одним из самых удобных инструментов для этого является «график вех» (о нем мы упоминали в главе VIII во время шага 6 «создание расписания»).

Планируем качество

Что означает термин «качество»?

Говорить об управлении качеством в отрыве от проекта или организации – очень тяжело. Само понятие качества ИТ-продуктов тесно сплетено с технологиями, используемыми для их создания. Мы ограничимся лишь описанием важнейших терминов и практик.

Качество – это некий уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям.

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

«Золотая сервировка» (gold platting) - добавление в продукт возможностей и функциональности, которые хоть и приятны заказчику, но не были им запрошены и не являются необходимыми для закрытия работ. Такое увлечение команды ненужными улучшениями очень характерно для ИТ-проектов.

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

Предотвращение «золотой сервировки» – задача ПМ. Основные причины – она съедает драгоценные ресурсы проекта (время, деньги). Даже если в результате этого, выполнение проекта не пострадает – ресурсы вовсе не бесплатны для самой организации.

Как планировать качество?

Планирование данной сферы предполагает ответы на главные вопросы: «что есть качество на нашем проекте?» и «как мы будем его достигать?».

На первый вопрос помогут ответить документированные требования (концепция проекта + ИСР + Словарь ИСР) и компетентные мнения нашей команды.

Документированные требования позволяют нам понять ожидание заказчика и пользователей, а командные усилия – найти способ их достижения. Как построить работы, чтобы действительно выдать заказчику систему, функционирующую в режиме 24*7*365, как он и просил? Как реализовать информационный обмен и устранение коллизий между распределенными системами, в объеме доступных нам спецификаций? На подобные вопросы ищут ответы эксперты вашей команды (возможно, при помощи «хозяев ресурсов»).

«Хозяева ресурсов» могут очень сильно помочь вам в планировании качества. В большинстве организаций именно они отвечают за развитие навыков своих подчиненных, наставничество и кураторство.

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

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

Таким образом, планирование качества на проекте предполагает использование экспертных знаний и навыков членов команды («как продукт, соответствующий требованиям»), предотвращение «золотой сервировки» и проверка результатов закупок.

Выходы:

• Дополнительные документы, описывающие ответственность (матрица ответственности / текстовые описания)
• Договоренности об отчетах (устно или письменно)
• Представление о способах контроля качества
• Запросы на изменения

Назад Содержание Вперёд