Гибкое управление IT-проектами. Руководство для настоящих самураев - страница 13



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

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

Часть II

Концептуализация проекта при гибкой разработке

Глава 3

Главное – никого не забыть


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

♦ неумение задавать правильные вопросы;

♦ боязнь задавать сложные вопросы.

В этой части мы поговорим о мощной методике построения перспектив, которую условно назовем стартовой колодой (inception deck). Она помогает найти ответы на 10 вопросов, без которых лучше не начинать какой-либо софтверный проект. Испытав команду на данном этапе, вы узнаете, все ли нужные люди подобраны для проекта и в правильном ли направлении вы движетесь. Это произойдет еще до написания самой первой строки кода.

3.1. Из-за чего погибает большинство проектов

В начале любого нового проекта люди обычно имеют поразительно разные представления об общей цели.



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

И проблема не в том, что нам не удалось прийти к общему мнению уже на старте (это естественно). Проблема в том, что проекты начинаются еще до того, как найдены все нужные люди.


Ошибочное мнение о том, что консенсус достигнут там, где его нет и в помине, губит большинство проектов.


Нам нужно сформулировать план, который:

♦ позволяет сообщить команде цели, суть проблемы и контекст, в котором реализуется проект, так, чтобы при работе сотрудники могли принимать осознанные решения;

♦ предоставляет владельцам информацию, помогающую им решить, браться или не браться за дело, начинать проект или нет.



Единственный способ выстроить такой план – не бояться задавать вопросы.

3.2. Не избегайте сложных вопросов

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



Как видите, начиная любое новое дело (то есть проект), вы имеете большой простор для постановки вопросов и при этом ничего не теряете. Можно задавать общие вопросы, например, как приведенные ниже.

♦ Насколько опытна ваша команда?

♦ Занимались ли вы такими вещами ранее?

♦ Сколько денег у нас в распоряжении?

♦ Кто отдает приказы в этом проекте?

♦ Не смущает ли вас ситуация, когда в проекте участвуют два аналитика и тридцать разработчиков?

♦ Перечислите проекты, для работы над которыми вам пришлось пригласить команду молодых специалистов, практически незнакомых с объектно-ориентированным программированием, и успешно переделать устаревшую систему мейнфрейма для работы с Ruby on Rails – и сделать все это с помощью гибкой методологии.


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