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

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

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

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

Часть II

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

Глава 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3. Знакомство со стартовой колодой

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

В компании ThoughtWorks такой подход часто используется для анализа той части первичных работ над проектом, о которой практически ничего не говорится ни в экстремальном программировании, ни в скраме. Речь идет о закладке проекта (project chartering). Мы знали, что глубокий шестимесячный анализ и упражнения в сборе требований нам не подходят, но не могли придумать какую-нибудь более легковесную альтернативу. И именно в таких условиях Робину Гиббонсу пришла в голову мысль о стартовой колоде: быстром, легком способе извлечения из проекта самой его сути и рассказа об общем понимании задачи всей команде и другим участникам проекта.

3.4. Как это работает

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

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

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

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

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

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

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

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

3.5. Сущность стартовой колоды

Ниже перечислены основные вопросы и упражнения, прорабатываемые на этапе концептуализации проекта.

1. Зачем мы здесь собрались? Это быстрое напоминание о нашей цели, наших клиентах, а также о том, почему мы решили заняться данным проектом в первую очередь.

2. Составление блицрезюме. Если бы у нас было 30 секунд, за которые нужно описать наш проект в двух фразах, что бы мы о нем сказали?

3. Разработка оформления продукта. Если бы мы быстро листали журнал и наткнулись на рекламу нашего продукта или услуги, то что бы она нам сообщила, и еще важнее – согласились ли бы мы за это заплатить?

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

5. Встреча с коллегами. Сообщество специалистов, занятых в проекте, всегда больше, чем кажется. Почему бы не пригласить их на кофе, чтобы все могли познакомиться друг с другом?

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

7. Что не дает нам покоя? Иногда в ходе выполнения проектов происходят неприятные вещи. Но если поговорить о них и подумать, как их избежать, то, возможно, все будет не так плохо.

8. Определение временных параметров. Сколько времени займет проект: три месяца, а может, шесть или девять?

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

10. Что нам требуется для достижения результата? Сколько времени будет длиться проект? Сколько он будет стоить? И какая команда нам нужна для реализации этого проекта?