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

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

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

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

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

Один из оригинальных экземпляров Конституции США помещен в музейное хранилище в Вашингтоне, округ Колумбия, за толстыми листами из сверхпрочного стекла. Хотя этот экземпляр хранится в безопасном и надежном месте, я уверен, что в таком формате его читали немногие. Когда идеи недоступны или остаются в тени, они постепенно уходят в небытие (если только из-за особой ценности их не делают музейными экспонатами). Даже в краткосрочных проектах легко утратить ту общую для проекта канву, в которую должны вписываться ежедневные решения, и недостаток видения основных идей способствует возникновению этой разновидности энтропии. Люди могут быть загружены до предела и успешно работать над решением частных задач, но без частой сверки курса с общими ориентирами им будет довольно трудно понять, что все они движутся в правильном направлении. Концепция, или сборник основных идей и целей проекта, является частью общего процесса, и поэтому она должна постоянно присутствовать в коридорах и офисах людей, выполняющих свою работу.

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

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

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

1. Насколько точно концепция отражает наши цели, определенные для этого проекта?

2. Помогает ли концепция ведущим и рядовым сотрудникам принимать решения, а также отклонять запросы, не имеющие к ней отношения?

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

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

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

• Концептуальные документы являются квинтэссенцией всех остальных материалов планирования и находят свое выражение в едином обобщенном плане.

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

• Степень детализации вашего концептуального документа зависит от особенностей команды и самого проекта.

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

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

• Объем не является эквивалентом качества. А краткость требует больших усилий.

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

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

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

3. Исследуйте историю прорицателей. Выберите любых двух из следующего списка: Ганди, Малкольм Х, Торо, Будда, Сократ, Иисус Христос или Конфуций. Какими были их мировоззренческие концепции? Как они развивали свои идеи? Что они делали для выражения этих идей? Для их продвижения и популяризации?

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

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

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

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

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

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

Глава 5. Откуда берутся идеи

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

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

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

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

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

Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий

Смириться с этим можно только в том случае, если предстоящая работа продолжительна по срокам, предельно проста и понятна. Неопределенность этого периода времени сглаживается заурядностью предстоящей творческой работы. В противном случае неопределенность процесса проектирования продукта предрекает команде неудачу.[26]26
  Если команда получает заказ на прорывную разработку, но подходит к планированию как к рутинной рядовой работе, нужно быть настороже. Это похоже на нейрохирургическую операцию, проводимую с использованием бытовой аптечки. Если планирование не отвечает сложности задач, так или иначе готовьтесь к провалу.


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

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

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

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

Требования имеют решающее значение. Они являются отправной точкой для зарождения идей и потенциальных решений. Если в требованиях определено, что «это будет сарай зеленого цвета», то все задействованные в проектировании специалисты будут думать о всем разнообразии зеленых сараев. Из этого можно извлечь двоякую пользу. Во-первых, из рассмотрения исключается масса ненужных идей (можно будет с легкостью поставить на место тех, кто уже заготовил эскизы голубых космических кораблей). Во-вторых, проектировщики получают возможность задавать вопросы, ведущие к дополнительным исследованиям требований. Эти вопросы могут быть вполне конкретными, например: «Подойдут ли светлые оттенки зеленого или нужен только темно-зеленый цвет? Какова должна быть площадь сарая?», или более общими, например: «Для чего будет использоваться сарай? Предусматривается ли чердак? Он и обойдется недорого, и в хозяйстве пригодится». В зависимости от того, кто несет ответственность за выработку требований и проектирование (см. главу 3), принимать решения, какими должны быть ответы на эти вопросы или предлагать их измененные варианты, будут разные люди, наделенные соответствующими полномочиями. Но стремление задавать вопросы, уточняющие требования и повышающие их качество, должно поощряться.

Итак, чем больше внимания уделено выработке требований, тем выше шансы на то, что проектировщики найдут соответствующие им решения. Если требования не сформулированы, проектировщикам придется работать на собственный страх и риск (то есть если вы ведете проектирование, не имея требований, в ваших собственных интересах составить их самостоятельно). В качестве примерного руководства по улучшению требований я привожу краткий перечень типовых ошибок, которых следует избегать во время разработки этих требований.[27]27
  Дополнительный материал можно найти в книге Дональда Гауса (Donald Gause) и Джеральда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).


[Закрыть]

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

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

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

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

 Постарайтесь уточнить или исключить все случайно вкравшиеся неоднозначные понятия. Такие слова, как быстрый, большой, маленький, хороший, красивый и удобный, понятны лишь в сравнении. Их неопределенность может устраивать только в том случае, когда все участники выработки требований (заказчики, руководители, программисты и т. д.) согласны отложить их уточнение до следующих переговоров. В противном случае каждый составитель требований не захочет вносить уточнения там, где это ему не выгодно. Зачастую простейшим способом устранения неоднозначности является установка определенных границ («Наша домашняя веб-страница должна загружаться в Firefox как минимум с такой же скоростью, как страница www.cnn.com, но лучше, если она будет загружаться так же быстро, как www.oreilly.com»). При этом должны быть легко различимы абсолютные (должно быть так) и желательные (было бы неплохо, но можно обойтись) требования.

Используя одну из постановок задач, рассматриваемых в главах 3 и 4, рассмотрим один из вариантов качественной формулировки отдельного требования:

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

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