Текст книги "Искусство управления IT-проектами"

Провидцам от технологии не дано осознать различие между выполнимым и желаемым.

Эдвард Мендельсон (Edward Mendelson)

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

Единственный способ избежать подобной ситуации – приступить к проектированию и разработке сверху вниз, то есть с того, что пользователь увидит на экране, спускаясь сначала к высокоуровневым компонентам, а затем – к рабочим элементам. Как только появится предварительная концепция с набросками всего, с чем будет работать пользователь, инженеры и технологи должны взять на себя ответственность за то, чтобы их замыслы соответствовали этой концепции. Можно ли сделать то, что будет спроектировано? Какие для этого могут понадобиться компромиссные решения? Какие ограничения должны быть учтены? В ходе работы ведутся дискуссии, перемещаемые вниз и вверх по уровням проектирования, и специалисты разного профиля, входящие в команду, обеспечивают по мере хода этого процесса соблюдение целостности того, с чем придется работать пользователю, не вторгаясь в область того, что возможно получить (и должно быть получено) от разработчиков. Конструкторская мысль будет продвигаться в двух направлениях: от ожидаемого пользовательского восприятия вниз к технологии и от практической технологии вверх к пользовательскому восприятию (рис. 5.5).

Рис. 5.5. Правильно организованный процесс проектирования объединяет ориентацию на пользователя и практическое рассмотрение доступной технологии. Если изолировать один из компонентов, то другой неизменно от этого пострадает

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

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

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

1. Динамически выстраивать страницы по приоритетам на основе их востребованности.

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

3. Провести смысловую группировку материала домашней страницы с точки зрения пользователей.

Прежде чем какой-нибудь разработчик задумается над реализацией этих идей, кто-то должен взвесить их ценность с точки зрения пользовательского восприятия. Возможно, выяснится, что как бы привлекательно они не выглядели в абстрактном представлении, никто из присутствующих не в состоянии придумать приемлемую конструкцию,[34]34
  Основные принципы веб-дизайна изложены в книге Стива Крага (Steve Krug) «Don’t Make Me Think» (New Riders Press, 2005), а типовые ошибки, допускаемые при разработке пользовательского интерфейса, рассмотрены в книге Джефа Джонсона (Jeff Johnson) «GUI Bloopers». Нанять консультанта по потребительским свойствам или дизайну можно на веб-сайте http://www.upassoc.org/people_pages/consultants_directory/index.html или обратиться к автору через веб-сайт www.scottberkun.com/services.


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

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

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

Если цели проекта вполне ясны, а решаемые проблемы обозначены, то последующие обсуждения обычно проходят в дружелюбной атмосфере. Естественно, бывают и разногласия, но когда все пытаются решить одну и ту же проблему, конфликты не заходят слишком далеко. И учитывая то внимание, которое ранее в этой главе я уделял значению широты взглядов, подобные неувязки могут привести людей к расширению их поля зрения. В соответствии с правилами импровизации, чья-нибудь идея может стать для другого человека, имеющего иные подходы или мнения, отправной точкой для предложения какого-нибудь совершенно необычного и более удачного, по сравнению с ранее предложенным, варианта. Вот что думает по этому поводу кинорежиссер Терри Гильям (Terry Gilliam):

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

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

• Многие команды не могут правильно распорядиться временем между выработкой требований и формулировкой технических условий.

• Это время лучше потратить на тщательное исследование требований и замысла проекта.

• Идеи могут быть удачными или неудачными только по отношению к целям проекта или к другим идеям.

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

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

• Лучшей исходной точкой для проектирования служит пользовательское восприятие.

• Идеи воплощаются в проекты в ходе переговоров между специалистами разного профиля.

1. Найдите человека, которого считаете по сравнению с собой более способным к творческому мышлению. Спросите его, откуда берутся его идеи и какие привычки им выработаны для повышения продуктивности творческой работы. Попробуйте на неделю перенять одну из таких привычек. (Если вы затрудняетесь припомнить кого-нибудь, кто бы подошел на эту роль, возьмите за образец Пикассо, Эйнштейна или кого-нибудь другого знаменитого мыслителя в вашей области.)

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

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

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

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

6. Какую проблему вы пытаетесь решить, читая эту книгу? Выполняя эти упражнения? Существует ли ситуация, в которой вопрос: «Какую проблему вы пытаетесь решить?» бесполезен?

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

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

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

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

Глава 6. Как правильно распорядиться имеющимися идеями

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

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

По этим причинам период времени между завершением первичного планирования и составлением технических условий всегда и на любой стадии работы дается нелегко. Команды, естественно, испытывают крайнее напряжение, когда на горизонте замаячит первый основной контрольный срок (то есть срок сдачи технических условий). Даже если люди не говорят об этом, многие понимают, что не все пока еще обсуждаемые идеи могут выжить. Может не хватить времени, средств или людей для создания всего, что находится в сфере обсуждения. Люди начинают задумываться о способах, которые позволили бы снять с себя ответственность или сгладить углы. Хуже того, некоторые идеи и замыслы могут конфликтовать друг с другом. У автомобиля может быть только один двигатель, а у дома – лишь одна крыша, и если предлагаются три разных варианта, понятно, что большинство из них не пройдет.

С данным периодом времени связано одно довольно грустное наблюдение: в воздухе витает масса хороших идей, которым, вероятно, так и не суждено будет где-нибудь приземлиться. Возможно, самым худшим, что было в моей карьере на данном этапе проекта, связано с созданием Internet Explorer 4.0. (Если вам не интересно в очередной раз читать про войну, можете сразу переходить к следующему разделу.)

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

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

В первые месяцы существования проекта IE 4.0 мы получили настоящий вал программ. Параллельно мы пытались перейти от небольших команд и релизов (а-ля IE 2.0 и 3.0) к выпуску главного продукта. Мы были вовлечены в гонки, развернувшиеся между компаниями Microsoft и Netscape, из которых пресса раздула войну не на жизнь, а на смерть. А затем наш продукт перешел в разряд стратегических уже в соответствии с внутренней политикой компании. В таких условиях любому было бы нелегко удержать судно на плаву. И, как и в большинстве проектов, стоило только наступить переходному моменту от планирования к разработке, как возникло столкновение мнений и амбиций. Людям пришлось принимать первые трудные для себя решения, они почувствовали груз ответственности. На фоне явного нарастания неуверенности и напряженности одно оставалось неизменным – сроки. На горизонте нетерпеливо маячила очередная календарная дата, приближавшаяся с наступлением каждого следующего дня.[35]35
  Чувство обреченности оказавшегося в плену у времени хорошо передано в песне группы They Might Be Giants под названием «Older»: «This day will soon be at an end, and now it's even sooner, and now it's even sooner. And now it’s sooner still». («День скоро подойдет к концу, и времени все меньше, меньше. И вот его почти что не осталось».)


[Закрыть]

Решение, которому посвящена данная глава, заключается в умении грамотно разобраться в пространстве возможных замыслов. Кто-то должен спланировать работу и поэтапно провести команду по пути от исследований к выработке технических условий. Если под рукой нет ни одного корифея проектирования или разработки (в предыдущей главе мы говорили, что это было бы наилучшим выходом из положения), бремя этой работы придется взвалить на плечи первого попавшегося руководителя проекта. Подхватывая эстафету у главы 5, мы возвращаемся к тому моменту, когда идея уже родилась, и продолжаем путь по направлению к выработке технических условий (которые станут темой следующей главы).

Наиболее распространенной ошибкой является представление процесса проектирования в виде своеобразного рубильника, который можно включать и выключать, когда захочется. Развивая эту фантазию, можно представить следующий ход событий: однажды вы обнаруживаете, что сроки поджимают, а в вашем распоряжении еще слишком много идей и замыслов (и слишком мало готовых решений), но вы говорите команде: «Итак, с идеями мы покончили. Берите проект и приступайте к программированию. Вперед!» Даже если представить, что в вашем распоряжении вполне зрелый проект (чего на самом деле быть не может), подобное непредсказуемое поведение собьет с толку и дезориентирует всю команду. Вплоть до этого момента все занимались проектом, для окончательной готовности которого требовалось время. Без указания конкретной даты у них могло сложиться впечатление, что они имеют право принимать важные решения вплоть до 23 часов 59 минут суток, предшествующих дате готовности технических условий.

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

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

Рис. 6.1. Пространство решения проблем по мере приближения к контрольной точке должно сужаться

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

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

Причины этого явления могут быть разными.

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

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

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