Рабочее планирование

Лекция 8. Реализация проекта

Выводы

Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Для того чтобы стать лидером, необходимо:

· Признание командой профессиональной компетентности и превосходства лидера.

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

Мотивация должна начинаться с подбора сотрудников в команду. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.

Рабочая группа прежде, чем она станет эффективной командой, должна пройти четыре обязательных последовательных стадии: 1) Forming, 2) Storming, 3) Norming, 4) Performing.

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

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

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

Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист. Трудоемкость элементарной работы каждого из исполнителей должна быть от 4 до 20 чел.*час. Если трудоемкость задачи не укладывается в эти пределы, следует провести декомпозицию работы.

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

В зависимости от уровня профессионализма и зрелости команды проекта распределение работ может осуществляться либо директивно с жесткой постановкой срока и контролем исполнения каждой задачи, либо эти полномочия делегируются исполнителям. В этом случае они сами выбирают задачи последовательно в соответствие с приоритетами, а их выполнение анализируется периодически на статус митинге. Можно рекомендовать еженедельные собрания по статусу проекта всей команды или, если проект достаточно большой, то ключевых его частников: руководителей подпроектов и лидеров команд. Хорошее время для этого утро понедельника, поскольку участники проекта, особенно студенты, которые совмещают учебу и работу, часто работают в выходные, но, разумеется, не потому, что аврал, а потому что им так удобнее. Обсуждаются, как правило, всего три вопроса:

· Угрозы и проблемы.

· Анализ результатов за неделю.

· Уточнение приоритетов задач на новую неделю.

Как правило, нет смысла оценивать процент реализации работы в промежуточном состоянии, поскольку, если задача передана в тестирование, то это вовсе не означает, что 70% работы сделаны. На этапе тестирования может быть выявлена ошибка проектирования и вся работа начнется заново. Рекомендация — использовать правило «50/100». Если работа по задаче начата, то следует учитывать ее, как выполненную на 50%. А 100% поучает только протестированная и документированная работа.