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

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

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

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

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

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

Этап 1. Мозговой штурм о достоинствах вашего проекта

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

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

Чувствуете разницу?

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

Этап 2. Создание слогана

Основа хорошего слогана – максимальное количество смысла в минимальном количестве слов. Не нужно описывать три перечисленные ниже компании, так как их слоганы говорят сами за себя.

♦ Acura – «За рулём или на ложе, а всё лучше помоложе»[5]5
  В оригинале: The true definition of luxury. Yours («Истинное воплощение роскоши. Вашей»). – Примеч. пер.


[Закрыть].

♦ FedEX – «Весь мир по расписанию»[6]6
  В оригинале: Peace of mind («Спокойствие и уверенность»). – Примеч. пер.


[Закрыть].

♦ Starbucks – «Рухни в прохладу»[7]7
  В оригинале: Rewarding everyday moments («Воздавая должное повседневности»). – Примеч. пер.


[Закрыть].

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

Этап 3. Разработка упаковки

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

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

Итак, переходим к оформлению упаковки!

Не пытайтесь сразу создать шедевр. Просто возьмите ватман, фломастеры, бумажные наклейки, иголочки и все, что еще может понадобиться. Озвучьте ваш слоган. Расскажите покупателям о пользе программы. Потратьте 15 минут на создание такой качественной упаковки, на которую вы только способны.

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

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

Знакомя клиента с ожидаемым функционалом проекта, важно рассказать не только о том, что вы собираетесь сделать, но и о том, чего вы делать не планируете.

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

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

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

Все, что ВХОДИТ в проект, требует от нас глубокого внимания. Здесь мы имеем дело с большими блоками, из которых собираемся сложить наш проект. Это могут быть важнейшие функции (например, система отчетности) или общие задачи (например, масштабируемость в стиле Amazon).

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

К НЕРЕШЕННЫМ задачам относится то, с чем еще предстоит определиться. Это очень важный раздел, отражающий истинную природу большинства софтверных проектов. У всех людей может быть свое мнение о том, без чего можно обойтись. В итоге все НЕРЕШЕННОЕ должно перекочевать В проект или остаться ВНЕ его.

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

Полностью определив объем работ по проекту, двигаемся дальше. Знакомимся с нашими коллегами.

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

Вопрос на миллион долларов

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

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

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

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

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

Мой первый большой промах

Никто не застрахован от ошибок. Одну из самых больших профессиональных ошибок я совершил, когда работал руководителем команды в ThoughtWorks. Тогда мы выполняли один заказ для Microsoft.

Я взялся за работу и приступил к выполнению проекта, считая, что наш коллектив выглядит вот так:

И какое-то время все было нормально. Команда работала гибко. Мы регулярно делали хорошие программы и радовались жизни.

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

♦ Одни стремились пересмотреть архитектуру нашего продукта (как будто она вообще нуждалась в пересмотре!).

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

♦ А третьи желали изучить нашу документацию (какую еще документацию!).

Кто все эти люди? Откуда они взялись? И почему они так стремились сорвать наше расписание?

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

Я, конечно, стал ругаться с незваными гостями по поводу того, что они вмешиваются в наше расписание. Но дело было как раз в том, что сначала я не понимал: количество участников проекта всегда больше, чем вам кажется[8]8
  The Blind Men and the Elephant [Sch03].


[Закрыть].

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

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

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

Кофе, пончики и чистосердечность

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

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

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

Но самый важный компонент налаживания отношений с коллегами – это, конечно же, чистосердечность.

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

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

УЧЕНИК: Мастер, многие из твоих уроков требуют участия владельцев или спонсоров. Что, если они недоступны или просто очень заняты и не могут отвечать на подобные вопросы о проекте?

МАСТЕР: Тогда можешь себя поздравить. Ты только что обнаружил крупное уязвимое место своего проекта.

УЧЕНИК: А в чем заключается риск?

МАСТЕР: В незаинтересованности клиента. Если клиент не интересуется проектом, то этот проект подвергается опасности, еще не начавшись. Если у клиента нет времени рассказать, зачем ты пишешь для него эту программу, то, возможно, ее вообще не стоит писать.

УЧЕНИК: Ты имеешь в виду, что проект нужно остановить?

МАСТЕР: Я имею в виду, что для успешной реализации проекта необходим вклад клиента и владельца. Без этого проект уже глохнет, хотите вы этого или нет.

УЧЕНИК: И если так, то что делать?

МАСТЕР: Нужно ясно и настойчиво рассказать клиенту, что требуется сделать, чтобы такой проект завершился успешно. Возможно, клиент действительно очень занят и запланировал слишком много дел. Если так, скажите, что можете поговорить, когда он освободится. До того вы поработаете с другими клиентами.

УЧЕНИК: Спасибо, сэнсэй. Я подумаю об этом.

Что дальше?

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

Чувствуете?

Понимаете, что происходит?

Выполняя один за другим этапы концептуализации проекта, мы начинаем лучше понимать его смысл и функционал.

♦ Мы узнаем, зачем выполняем этот проект.

♦ У нас хорошее блицрезюме.

♦ Мы знаем, как будет оформлен наш продукт.

♦ Мы определяем объем работ по проекту.

♦ Мы начинаем достаточно хорошо понимать, с кем нам придется работать на этом проекте.

Знаю, о чем вы думаете. Хватит контекста! Когда же мы перейдем к делу и поговорим о том, как именно выполняется проект? И ответ будет дан прямо сейчас.

Из главы 5 вы узнаете, как выглядит техническое решение нашего проекта и как будет проходить его реализация.

Глава 5
Воплощение в реальность

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

На данном этапе нам предстоит:

♦ представить техническое решение;

♦ рассмотреть некоторые риски;

♦ определиться с длительностью проекта;

♦ уяснить, каких именно результатов нужно достичь (так или иначе, ситуация обязательно решится);

♦ показать спонсорам, что необходимо для проекта.

Но сначала давайте продемонстрируем решение.

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

Рассказывать о решении и представлять его на суд команды и заказчика полезно по нескольким причинам:

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

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

♦ мы сообщаем о возможных рисках.

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

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

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

Если вы размышляете о том, работать ли с проприетарными или свободно распространяемыми инструментами, поделитесь вашими соображениями с командой (в некоторых компаниях можно работать не со всеми свободными инструментами).

Архитектуру нужно подбирать одновременно с командой

Как говорится, если в руке большой молоток, все вокруг начинает напоминать гвозди[9]9
  Афоризм принадлежит Марку Твену. – Примеч. пер.


[Закрыть].

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

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

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

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

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

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

Почему говорить о рисках полезно

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

Но обсуждение рисков – отличный способ донести до людей, что нужно для успешного завершения проекта.

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

♦ у нас нет команды, которая работает вместе;

♦ наш клиент не интересуется ходом проекта;

♦ мы не контролируем среду, в которой идет разработка;

♦ у нас нет чего-то еще, что требуется для успешной реализации проекта.

Блумберг о риске

Согласитесь, Майкл Блумберг кое-что знает о рисках. Как основатель финансовой компании Bloomberg и мэр Нью-Йорка он нередко уподоблялся штурману, ведущему судно среди рифов.

В книге Bloomberg by Bloomberg [Blo01] Майкл рассказывает о своем излюбленном методе, помогающем справляться с рисками.

1. Формулировать все проблемы, которые потенциально могут. возникнуть.

2. Очень хорошо думать о том, как избежать таких проблем.

3. Затем окончательно с ними разобраться.

Философия Майкла Блумберга заключается в том, что никогда не удается предусмотреть всего и что ни один план не совершенен. Жизнь преподносит сюрпризы, а подать иск против нее у вас не получится. Привыкните к этому. Или вы знаете, что происходит, или не знаете и никогда не узнаете. Что до остального, просто принимайте жизнь такой, какая она есть.

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

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

♦ Сообщать о проблемах, связанных с проектом, нужно на раннем этапе. Не ждите, пока мина замедленного действия рванет. Если у вас есть сложности или вы видите какие-то риски, неустранение которых может привести к срыву проекта, разобраться с ними нужно уже сейчас.

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

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

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

Как определить риски, требующие тщательной проработки

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

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

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

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

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

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

О том, как делается оценка при гибкой разработке, мы подробно поговорим в главе 7. А пока предположим, что команда уже оценила длительность проекта и здесь мы просто представляем результаты работы.

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

Задумывайтесь о мелочах

Возможно, вы не слышали о Рэнди Мотте, но это легендарная фигура в мире Fortune 500[10]10
  Список 500 крупнейших промышленных корпораций США. – Примеч. пер.


[Закрыть]. Он помог разработать знаменитую на весь мир систему хранения данных и управления запасами сети магазинов Wal-Mart. Она позволяет менеджерам в реальном времени отслеживать различные особенности: например, печенье с каким именно ароматом лучше всего продается в конкретном супермаркете, оборудованном такой системой. Рэнди внедрил подобную систему и в компании Dell, чтобы быстро фиксировать увеличение количества продукции на складе и предлагать скидки на товары, которых накопилось слишком много. Сейчас Рэнди работает директором по информационным технологиям в компании Hewlett-Packard и помогает проводить модернизацию внутренних систем компании, стоящую $1 млрд.

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

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

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

Рэнди Мотт и гибкая разработка приходят к одинаковому выводу при определении длительности IT-проектов: чем быстрее, тем лучше, предпочтительно – полгода или меньше.

Перспективы длительности проекта

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

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

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

Разницу между этими вариантами мы рассмотрим, когда будем говорить о таком выборе в разделе 8.4.

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