Искусство управления IT-проектами Беркун Скотт
Руководитель проекта, как правило, несет ответственность за объединение усилий всех участников встреч и дискуссий на решении ключевых вопросов и за фиксацию достигнутых итогов в доступном для всей группы месте. Возникшие вопросы или проблемы должны быть соответствующим образом распределены и обсуждены на следующей встрече.
Исследование потребительских запросов и допускаемые при этом просчеты
Существует множество разнообразных неправильных подходов к информации о потребителях. Одно утверждение о том, что с интересами потребителя надо считаться, само по себе ничего не значит. Проще всего заявить: «Мы заботимся о потребителях» или «Самое важное – это удовлетворить запросы потребителя», поскольку вряд ли кто-нибудь спросит, как эти утверждения отразятся на деятельности организации. Даже при том, что в последнее десятилетие был достигнут большой прогресс в конкретизации методов исследования и анализа потребительских запросов, большинство этих методов так и не были внедрены в работу организаций управленческой или технической направленности. В практике команд по разработке проектов до сих пор непривычным является привлечение к работе специалистов, обличенных правами принятия решений и занимающихся изучением потребительских запросов, разработкой интерфейсов и улучшением потребительских свойств изделий.
Безусловно, самая распространенная ошибка – это целиком и полностью полагаться на один-единственный метод исследований. Основная проблема всех исследований, как научных, так и любых других, состоит в том, что конкретное исследование позволяет оценить только одну точку зрения на проблему (мы вернемся к обсуждению этого вопроса в главе 8). Каждый исследовательский метод хорош для оценки одних параметров и не пригоден для оценки других (табл. 3.2). Вы же не станете использовать спидометр для взвешивания или запрос о состоянии своего счета в банке для получения сведений о кровяном давлении (хотя эти два показателя могут быть взаимосвязаны), так и индивидуальные и групповые опросы могут подходить для одних целей и не подходить для других.
Таблица 3.2. Типичные методы исследования потребительских запросов
1 Группа опрашиваемых стремится настроиться на полезную отдачу. Никто не хочет обидеть пригласивших, и все проявляют чрезмерную активность в обсуждении идей.
2 Оцените свое собственное усердие при участии в последнем опросе. Если вы никогда ничем подобным не занимались, задумайтесь над тем, что собой представляют люди, которые тратят уйму времени на участие в опросах.
3 В оригинале «Usability study». – Примеч. ред.
Специалисты по исследованию пользовательских запросов занимаются двумя делами: они выбирают метод на основании тех вопросов, на которые должна ответить команда проектировщиков, и пользуются несколькими методами для нейтрализации ограничений и перекосов, возникающих при индивидуальных подходах. В табл. 3.2 показаны некоторые главные исследовательские методы и их основные достоинства и недостатки.
Когда я работал руководителем отдела программирования в компании Microsoft с самой лучшей командой проектировщиков, у меня был доступ ко многим источникам информации. Я часто запрашивал ответы на специфические вопросы, выходившие за рамки обычных, и в организации всегда находились грамотные специалисты, удовлетворяющие мои запросы. В других, менее обеспеченных квалифицированной поддержкой командах, мне приходилось обходиться собственными силами (как правило, менее успешно, поскольку я был загружен другой работой и не был знатоком под стать узким специалистам).
Но даже при нехватке ресурсов или финансирования полдня работы, потраченные на поиск ответов на вопросы плана, могут иногда дать вполне приемлемые результаты. Со временем мастерство в проведении этого вида исследований будет возрастать, сокращая будущие временные затраты. Важнее всего то, что проделав часть этой работы самостоятельно, вы станете больше разбираться в данном вопросе и сможете нанять кого-нибудь для этой работы, если будет, наконец, выделен соответствующий бюджет или штатные единицы.
Повысить ценность данных помогут здравый смысл и некоторая доля скепсиса. Предположения должны подвергаться сомнениям, а те или иные известные необъективные моменты различных видов исследований должны быть выявлены при представлении данных исследований. Совершенных форм представления данных не существует: всегда имеют место необъективность, настороженность, допустимые погрешности и скрытые детали. Руководитель проекта должен уметь видеть сквозь все необъективные нюансы и разумно использовать всю имеющуюся информацию для принятия наилучших решений.
Объединяем все вместе – выработка требований
При планировании создается большой объем информации и возникает непростая задача, как ее свести к простому плану действий. По большому счету, все взгляды, результаты исследований и стратегические основы синтезируются в единый концептуальный документ. Об этом особом документе мы поговорим в следующей главе. Но на более низком уровне простейшим инструментом становится набор требований.
Для многих проектов требования являются средством определения их направленности. Требования по определению означают, что команда (с ведома заказчика) к моменту завершения проекта должна их удовлетворить. В наипростейшем смысле определением требований является заказ пиццы с пепперони. Вы объявляете изготовителю пиццы, что вы, собственно, желаете получить. Он может уточнить требования, задавая вопросы («Не желаете ли вы вдобавок минеральной воды?»), или детально обговорить требования («У нас в данный момент нет пепперони, не подойдет ли взамен салями?»). В более сложном случае, при разработке программного продукта, получить качественно выработанные требования намного труднее. Существует множество различных способов интерпретации абстрактных идей, усложняющих процесс выработки требований («Сделайте более высокоскоростной или более отказоустойчивый продукт»).
Для выработки и документирования требований существует ряд устоявшихся методов, и я рекомендую ознакомиться с ними самостоятельно.[22] В зависимости от уровня имеющихся при выдвижении требований полномочий применяются различные способы решения этой задачи, позволяющие достичь хороших результатов. Особенности этих методов и способы их применения в данной книге не рассматриваются. Тем не менее один метод, отличающийся простотой, легкостью в применении и эффективностью, я могу вам предложить – это метод постановки задач.
Постановка задач – это описание в одном-двух предложениях конкретных проблем конечных пользователей или клиентов, которые должны быть получены из результатов проведенных исследований или из конкретных пользовательских запросов. Они должны быть изложены в формате, позволяющем понять суть проблемы или потребности, взятой из набора, относящегося к потребительскому взгляду на проект (в противовес взглядам разработчика или бизнесмена). Тем самым будет гарантирована поддержка точки зрения потребителя, она не будет искажена другими точками зрения.
В качестве примера далее приводится перечень, полученный в ходе постановки задач по разработке корпоративного веб-сайта:
• С домашней страницы затруднен поиск часто востребуемых разделов.
• Ведомственная информационная страница долго загружается, заставляя пользователя ждать.
• Страница запросов к базе данных сбоит при работе с большими таблицами, вынуждая пользователей начинать все заново.
• Веб-сайт не обеспечивает автоматического доступа к защищенным услугам, а ручной доступ отнимает много времени.
• Результаты поиска трудно просматривать в существующем формате.
• На странице регистрации не обеспечен контроль вводимой информации в обязательные поля, поэтому при вводе легко ошибиться.
• Страница состояния не включает информацию об электронной почте, и пользователи не могут узнать, почему их электронная почта не работает.
• Отсутствует способ сохранения предпочтений или вариантов появления домашней страницы.
Заметьте, что это – не отчет об ошибках. Возможно, данные проблемы ранее не рассматривались как обязательные условия работы веб-сайта. Постановка задач должна быть более масштабной и отличаться по виду от перечня ошибок, поскольку сама идея состоит в том, чтобы ухватить упущенные детали, относящиеся к потребительскому взгляду, а не оценивать все неудачи с точки зрения разработчика.
Каждое из этих утверждений, выраженное одним предложением, может сопровождаться доказательствами или примерами (скажем, копией экрана, иллюстрирующей суть проблемы, или ссылкой на результаты изучения потребительских запросов или других исследований, вскрывших проблему), помогающими изложить предысторию и объяснить, почему и при каких обстоятельствах возникает данная проблема (или почему этому функциональному упущению придается такое значение). Но эти подкрепляющие доказательства не должны смешиваться с самой формулировкой проблемы, с техническими планами или деловыми задачами. Смысл формулировки этих потребительских проблем должен касаться лишь пользователей и их нужд.
Проблемы превращаются в сценарии
Поскольку постановка задач отражает текущее состояние дел, проект нуждается в чем-то другом, отражающем состояние, которое будет достигнуто по завершении работы. С этой целью нужно переработать постановку задач в нечто иное, называемое формулировкой характеристик или сценарием. Для этого существует масса различных способов. Одним из самых популярных считается метод сценариев использования (use-cases),[23] но существуют и другие методы.
Каждый сценарий представляет собой краткое описание возможностей клиента, открывающихся в результате реализации проекта, или тех задач, в выполнении которых отпала необходимость, поскольку в результате работы над проектом они были автоматизированы. Идея состоит в том, чтобы описать все это с потребительской точки зрения, избегая при этом любых описаний способов достижения результатов (отложив их на потом). А на этом этапе намного важнее предоставить команде возможность обсудить, какой их сценариев имеет наибольшую ценность. На расстановке сценариев по приоритетам должен отразиться анализ их бизнес-потенциала или возможностей технической реализации.
Сама по себе формулировка характеристик должна стать способом наиболее легкого представления обо всем, что удалось выяснить в отношении потребительских запросов, и о том, в чем будет заключаться потребительская направленность проекта. Основываясь на предыдущем перечне потребительских запросов, определим, на что могут быть похожи некоторые формулировки характеристик.
Итак, возможные характеристики проекта X:
• Часто востребуемые разделы можно будет легко обнаружить на домашней странице.
• Результаты поиска будут представлены в доступном для большинства пользователей виде, допускающем беглый просмотр.
• Веб-сайт обеспечит простой автоматизированный доступ к защищенным услугам.
• Регистрационная страница позволит упростить безошибочный ввод информации.
• Ведомственная информационная страница будет загружаться, по крайней мере, так же быстро, как и домашняя страница.
• Интерфейс запросов к базе данных будет по надежности сопоставим с остальными компонентами системы.
• Пользователи получат возможность видеть состояние сервера электронной почты в простом и удобном формате.
• У пользователей будет удобный способ сохранять свои предпочтения при настройке системы.
Формулировка характеристик ни в коем случае не должна включать описание конкретной конструкции, в ней вместо этого должно быть объяснение влияния решений на потребителя. Проще, конечно, сказать, чем сделать. Большинство творческих личностей любят решать проблемы и сделают это автоматически. Загвоздка в том, что скоропалительные решения зачастую бывают поверхностными. Перед принятием решений нужно дать проблемам возможность как следует уложиться в сознании. Нужно просто попросить людей во время совещаний по планированию записать возникающие у них идеи по решениям и обсудить их чуть позже. Исключение можно сделать для тех идей, которые полностью вычеркивают проблему из списка или переводят ее в разряд несущественных.
Формулировки характеристик можно примерно расположить в порядке важности, что позволить очертить границы проекта. Когда дело дойдет до конструирования, оно пойдет значительно быстрее, поскольку все будут работать над достижением единых результатов (вместо того чтобы отвлекаться на предпочитаемые ими собственные идеи решения проблем). Поскольку очень многое зависит от этих коротких описаний, они должны быть выполнены с особой тщательностью и с учетом того, насколько долго они пригодятся команде проектировщиков. Зачастую, чтобы привести все в порядок, их нужно по нескольку раз просматривать и перерабатывать, но как только они приобретут окончательную форму, потребность в их корректировке по ходу проекта будет возникать крайне редко.
Объединение деловых и технологических требований
К перечню потенциальных характеристик, выведенных из исследований потребительских запросов, могут быть добавлены дополнительные характеристики, удовлетворяющие деловым и технологическим соображениям. Но сначала нужно ответить на главный вопрос: для чего, собственно, предназначены эти дополнительные требования, если они ничего не дают потребителям? Перед добавлением новых характеристик нужно пересмотреть существующий перечень, чтобы посмотреть, какие из уже имеющихся характеристик представляют эти деловые и технические соображения. Таким образом, общая направленность всей дискуссии будет сосредоточена на выгодах потребителя без запрета на определенные технологические или деловые соображения. Любые характеристики, не основанные на запросах потребителей, должны подвергаться пересмотру, чтобы удостовериться, что они не создадут у потребителей отрицательного впечатления.
Иногда требуется добавить какую-нибудь характеристику, способствующую увеличению объема продаж, несмотря на ее сомнительную ценность для конечного пользователя, или для удовлетворения потребительских запросов. Но проведение планирования в первую очередь вокруг исследований потребительских запросов, выявления проблем и формулировки характеристик заставит всех оперировать аргументацией в данном контексте. Это дает руководителю проекта осознание равных условий для характеристик, представляющих насущные интересы как потребителя, так и организации.
Выводы
• Разные проекты требуют различных подходов к планированию.
• Результаты планирования часто определяются тем, кто и какими полномочиями обладал. На планирование оказывают влияние три вида полномочий, связанные с определением перечня требований, конструированием и финансированием.
• Существует ряд общих разработок для планирования проекта: документы, отражающие анализ потребностей рынка (MRD), документы, определяющие концепцию и рамки проекта, технические условия и документы структурной декомпозиции работ (WBS).
• Наиболее действенный способ планирования проекта требует учета трех равнозначных взглядов: бизнесмена, разработчика и потребителя. Взгляд на проект с точки зрения потребителя зачастую оказывается наиболее недооцененным и неправильно использованным.
• Постановка вопросов наводит на правильные размышления и эффективно направляет энергию планировщиков в нужное русло.
• Процесс выработки требований не отличается простотой, но есть хорошие рекомендации для его успешной реализации.
• Формулировка проблем и выработка сценариев представляют собой простейший способ определения перечня требований и доведения его до участников проекта. Эти документы легко превращаются в конструкторские идеи, сохраняя видение главных и второстепенных составляющих проекта.
Упражнения
1. Составьте список лиц, обладавших конструкторскими, технологическими и деловыми полномочиями при реализации вашего последнего проекта. Была ли эта информация разъяснена команде с самого начала? Был ли правильным подбор людей для принятия подобных решений? Как это повлияло на проект?
2. Из трех взглядов на проект – с точки зрения бизнесмена, разработчика и потребителя – какой был представлен меньше других в последнем, реализованном вами проекте? Как это повлияло на качество конечного изделия?
3. Какова суть некоторых проблем определения требований, не рассмотренных выше? Встречались ли вам заказчики, запрашивающие характеристики, являвшиеся на ваш взгляд ошибочными, или заказчики, менявшие свое мнение уже после начала работы над проектом, как должны разрешаться подобные разногласия?
4. Предположим, вы были руководителем проекта, при работе над которым инженеры и бизнесмены недолюбливали друг друга, и вели войну вокруг основных решений. Какие действия можно было предпринять с вашей стороны для улучшения взаимоотношений? (Подсказка: Какие вопросы не были подняты? Какие точки зрения не были представлены?)
5. Представим, что вы решили саботировать проект на этапе планирования. Составьте список наиболее действенных мер, с помощью которых можно было бы завалить все дело. (Если затрудняетесь, то представьте, что возмездие вас не волнует.)
6. Составьте список мер, которые вы в качестве руководителя, а не саботажника могли бы предпринять для предотвращения действий или в ответ на меры, перечисленные в предыдущем списке.
7. Какие в проекте были признаки осложнений, потребовавшие слишком большого внимания при планировании? Что можно было бы сделать, если вы как руководитель проекта заметили бы все эти признаки?
8. Вы когда-нибудь видели человека, пользующегося какими-нибудь вашими разработками? Проведите собственное, совершенно неформальное изучение потребительских свойств продукта. Дайте потенциально новому клиенту рыночный проспект по своему продукту, усадите его перед этим программным продуктом и попросите опробовать все, что согласно этому проспекту позволено делать с вашим продуктом. Не оказывайте абсолютно никакой помощи, как бы этого ни хотелось. Вы узнаете куда больше о важности исследований запросов потребителей, чем из любой книги на эту тему.
9. Должен ли специалист, составляющий требования, быть тем же самым человеком, который будет конструировать удовлетворяющее им изделие? В чем заключаются проблемы, когда один и тот же человек делает оба дела? В чем заключаются проблемы, когда этим занимаются разные люди?
Глава 4. Разработка качественных концептуальных документов
Одной из сложнейших задач, относящихся к руководству командами разработчиков, является задача сплочения людей во имя общих целей в течение длительного периода времени. Не существует руководителей, которые не опасались бы, что принятые ими решения никто не воспримет. Возможно, мотивы, руководствуясь которыми люди прислушивались к ним сегодня, завтра будут забыты или проигнорированы. Еще хуже, если сами руководители утрачивают чувство направления, в котором, как предполагается, они ведут проект. Поэтому сложность руководства проектом заключается не только в его запуске в нужном направлении, но и в том, чтобы строго придерживаться выбранного пути.
В главе 3 был дан краткий обзор документов планирования, где были упомянуты документы, отражающие анализ потребностей рынка (MRD), концептуальные документы и технические условия. В данной главе основное внимание уделено концептуальным документам как наиболее важной составляющей всех материалов планирования. Я объясню, почему на разработку концептуальных документов стоит потратить определенные усилия, какими качествами должны обладать лучшие образцы этих документов, как извлечь из них пользу на протяжении всего процесса реализации проекта. При правильном подходе к делу разработкой концептуальных документов завершается исходная фаза планирования (рис. 4.1).
Рис. 4.1. Готовый концептуальный документ знаменует окончание фазы планирования, так же как готовность технических условий означает окончание фазы проектирования
Прежде чем приступить к изложению темы, следует сделать одно замечание: для деления всей области, охватываемой этим документом, существует множество различных способов. В некоторых организациях вообще не используются MRD-документы или бизнес-планы, а относящиеся к ним вопросы попадают сразу в концептуальный документ. Несколько раз я принимал участие в весьма скромных проектах, где вся концептуальная информация помещалась в технические условия. Поэтому не стоит волноваться насчет количества необходимых документов и их названий: я думаю, что главное не в этом. Мои рекомендации подойдут любому используемому вами процессу планирования.
В чем ценность ведения записей
Дэниел Бурстин (Daniel Boorstin), автор великолепных работ «The Creators» (Vintage, 1993) и «The Discoverers» (Vintage, 1985), как-то сказал, что письменное слово было величайшей из всех технологий, когда-либо изобретенных человеком. Без него нам пришлось бы всецело зависеть от нашей печально известной своей дырявостью памяти,[24] занимаясь такими сложными вещами, как создание динамита (гм, в каком весовом соотношении должны быть нитроглицерин и древесный уголь?) или ядерного реактора (а куда исчезает уран?). Применительно к работе над проектом записи дают возможность однократно определить характер технической работы или зафиксировать общие для всей команды цели, а затем многократно использовать эти сведения. Документирование деталей принятых решений перекладывает с нашей памяти на бумагу все заботы о точности их формулировок и сохранности, после чего их можно восстановить в памяти, всего лишь взглянув на записи. Такая разгрузка памяти позволяет нам решать поставленную задачу полным ходом, имея под рукой ее описание, и пребывать в полной уверенности, что мы всегда, если понадобится (собьемся с курса, столкнемся с разногласиями или запутаемся), сможем вернуться к написанному. Из этого следует, что чем больше в работе сложностей и чем больше прилагаемых к ней усилий, тем выше вероятность того, что запись некоторых деталей решения повысит шансы на ее успешное выполнение.
Чем крупнее проект, тем сложнее и запутаннее будет характер работы. Команде из трех человек для координации усилий может хватить и разговора в вестибюле, но команда из двадцати, ста или тысячи человек, работающих в разных часовых поясах, такой возможности лишена. В данном случае кто-то действительно должен определить общий план всей работы и оформить его в виде доступного для всех документа, на который каждый мог бы легко сослаться.
В достаточно крупной организации документирование служит также средством доведения намерений команды до всех заинтересованных лиц. Если группа А может представить свои основные идеи и решения в виде краткого документа, то группы Б и В смогут понять намерения группы А и сразу же поднять вопросы или составить отзывы. Чем сложнее и запутаннее проект, тем важнее становится роль таких кратких документов, поскольку у сложного проекта больше шансов на недопонимание и дорогостоящие ошибки. А в качестве дополнительного преимущества появляется возможность быстрого ввода в строй новых сотрудников (независимо от их должностной принадлежности), потому что они смогут прочитать подборку основных идей проекта самостоятельно и их не нужно будет специально вводить в курс дела.
Какой по объему концептуальный документ вам нужен?
Мне попадались концептуальные документы объемом в 50 страниц, состоящие из тщательно отформатированных результатов исследований, диаграмм и стратегических замыслов. Приходилось сталкиваться и с документами всего в пару страниц с маркированными пунктами, сопровождаемыми пояснениями, объемом в несколько предложений. Необходимая степень детализации структуры и вида документов плана зависит от характера проекта. Нужно избавиться от догмы, что документы плана – это нечто жестко заданное. В конце концов, это всего лишь документы. Степень их детализации или своеобразия зависит от сущности проекта и культуры проработки документов плана, присущей той или иной команде. Тем не менее качественно разработанные концептуальные документы, хотя и охватывают по сути одни и те же вопросы, отличаются глубиной и серьезностью подхода.
Рассмотрение следующих вопросов поможет вам определить структурную сложность и трудоемкость вашего концептуального документа:
• Много ли обоснованных вопросов имеется у самой команды относительно будущей работы? Насколько люди осведомлены о предстоящей работе и о важности ее результатов?
• Сколько разных людей будет вовлечено в реализацию проекта? Сколько различных организаций представляют эти люди? Каким образом вы сможете правильно оценить ожидаемый вклад каждой организации?
• Насколько подробно вам лично хотелось бы обосновать заложенные в концепцию решения. (Удачно составленная концепция способна сама по себе дать многим вполне достаточное представление о сути проекта.)
• В какой мере вы допускаете влияние сторонних организаций на основную направленность проекта?
• Сколько проницательности, компетентности и рассудительности потребуется от руководителя проекта при принятии ключевых проектных решений? (Очевидно, именно эти свойства будут востребованы при выработке концепции.)
• Насколько глубоко команда сможет вмешиваться в стратегию проекта в процессе работы над его реализацией?
• Какие объемы исследований в процессе планирования проекта ожидает от вас руководство? Как вы будете доводить до руководства результаты этих исследований?
• Возникнет ли в последующем необходимость напоминать команде о целях проекта? Склонны ли сотрудники возвращаться к спорам по отдельным положениям, с которыми они совсем недавно согласились?
Чем детальнее и точнее вы ответите на данные вопросы, тем большую ценность приобретет концептуальный документ. Если к вашему проекту относится лишь малая толика вопросов, подход должен быть простым и неформальным. А если вы считаете, что к вашей ситуации подходит большинство вопросов, и при их чтении испытываете какой-то внутренний холодок, значит, вам следует отнестись к ответам на них со всей серьезностью.
Скорее всего эти вопросы имеют отношение к руководству проектами, чем к самому концептуальному документу. Тем не менее концептуальный документ – это единственное средство обратиться ко многим из них одновременно. Даже при работе в одиночку (вариант супермена-одиночки) составление неформального концептуального документа (к примеру, перечня конечных целей) на неделю, месяц или год имеет большое значение для завершения этих периодов времени, имея в результате то, чем можно было бы гордиться. Как только положения документа лягут на бумагу, станет намного проще относиться к ним со всей ответственностью, даже если дело касается только лично вас.
Общекомандные и индивидуальные цели
Для подробного разговора о концептуальном документе необходимо дать определение нескольким терминам. Понятия концепции, общекомандной цели и просто цели часто смешивают. Я же собираюсь их использовать в следующем толковании:
Концепция определяет главные цели, относящиеся к проекту в целом. Может также включать концептуальные положения или сверхзадачу. (Главные цели, определяемые в концептуальном документе, иногда называют задачами, чтобы отличать их от целей более низкого уровня.)
Общекомандные цели. Подраздел концепции, относящийся к сфере ответственности конкретной команды, определяемый несколько глубже, чем общая концепция. (Например, команда А может отвечать за разработку базы данных и достижение связанных с этим целей, а команда Б – за разработку поисковой машины и решение сопутствующих задач, но обе эти команды работают в рамках общей концепции проекта.)
Индивидуальные цели. Подраздел общекомандных целей, являющийся сферой ответственности отдельного работника.
Для небольших проектов разница между общекомандными и индивидуальными целями может быть незначительной (рис. 4.2). Проект даже может быть настолько мал, что ее и вовсе не будет. Но для больших проектов, в работу над которыми вовлекаются 50 и более человек, необходимо определить и этот уровень. Работая практически на протяжении всей своей карьеры в составе больших команд (заведомо больше 50 человек), я привык иметь дело с этими тремя уровнями: уровнем, относящемся ко всему проекту в целом (уровень концепции), уровнем, относящемся к отдельным деталям или областям проекта (уровень команды), и уровнем персональных задач для каждого работающего над проектом специалиста (индивидуальный уровень). Первые два уровня являются общими для всей команды, а третий относится к работнику и его руководителю.
Рис. 4.2. Три уровня целей
Давайте в качестве примера возьмем некий проект создания корпоративного веб-сайта под названием «Гидра»:
• Концепция. Веб-сайт «Гидра» предоставит удобный доступ к большинству наиболее востребованных источников корпоративной информации (поиск, учет, инвентарь, внутренние ресурсы, перевозки) из единого места с использованием простого и понятного интерфейса.
• Общекомандные цели. Команда А будет отвечать за создание доступных и простых в применении систем поиска и учета. Команда Б будет отвечать за создание систем инвентаризации, учета внутренних ресурсов и перевозок.
• Индивидуальные цели. Фрэд (из команды А) будет заниматься проектированием и разработкой всех функций, необходимых для поисковой системы. Майк (из команды Б) будет курировать все работы по общему устройству веб-сайта и вырабатывать технические условия на создание интерфейса для «Гидры». Боб (из команды Б) будет заниматься проектированием и разработкой всех функций, необходимых для учета внутренних ресурсов и перевозок.
Здесь прослеживается строгая наследственность сверху вниз: общекомандные цели происходят из целей проекта, а индивидуальные цели – в основном, из сферы целей общекомандных (наиболее важным исключением может стать индивидуальная потребность в обучении или профессиональном росте, которая не может быть удовлетворена в рамках проекта). Если все три уровня хорошо проработаны, станет заметной ежедневная работа всех участников проекта, каждый будет иметь мотивацию на выполнение работы, имеющей для него вполне определенный смысл и являющейся его непосредственным вкладом в реализацию всего проекта. На создание подобной структуры стоит потратить время. Благодаря ей возникает вполне естественный дух сотрудничества и упрощается управление проектом (см. рис. 4.2).
Этим трем уровням определения должны соответствовать различные документы (или, как минимум, различные обсуждения). Чтобы сохранить целостность концепции проекта, возглавить разработку общего концептуального документа должен руководитель группы или руководитель всего проекта. Затем он должен потребовать от руководителей разработки отдельных компонентов или частей проекта перевести общие указания в цели, относящиеся к их сферам ответственности, по возможности выделяя их них определенные темы и задачи. И наконец, рядовые исполнители должны обсудить со своими руководителями команд свои индивидуальные цели и сферы ответственности, вытекающие из общекомандных целей.
Пять качеств хорошей концепции
Поскольку первоисточником всех целей является основная концепция, руководитель всего проекта должен приложить немалые усилия именно к ее созданию, чем к выработке других первичных планирующих документов. Хорошая концепция должна отвечать пяти важнейшим характеристикам: она должна быть достаточно простой, целенаправленной, консолидирующей, вдохновляющей и хорошо запоминаемой.
Простота
Самое важное направление работы – это упрощение смысла проекта. Хорошая концепция должна предоставить ответы на основные вопросы и вооружить всех исполнителей инструментом для принятия решений в рамках их собственной работы. Хотя концепция вызовет и новые вопросы, но в количественном отношении их должно быть меньше тех, на которые уже даны ответы. На ранних стадиях работы над проектом его участники должны постоянно ссылаться на концепцию – при ведении дискуссий, в переписке по электронной почте и на совещаниях, – активно используя ее в качестве вспомогательного инструмента для принятия решений. Руководитель проекта должен внимательно отслеживать ход работы, стремиться уточнить и пересмотреть концепцию, с готовностью включая в нее ранее пропущенные вопросы, повышающие ее полезность для команды. Концепция не должна быть похожа на священную реликвию, заключенную в стеклянный футляр. Она должна больше походить на правила хорошей настольной игры, предоставляя разъяснения для всех ее участников, четко очерчивая границы дозволенного и быстро улаживая споры или налаживая взаимопонимание. Она должна быть потерта на изгибах и краях от постоянного использования и испещрена пометками на полях. Концепция должна быстро положить конец всем подготовительным переговорам и вселить в людей уверенность в успешном претворении проекта в жизнь.
Целенаправленность
Концептуальный документ – это первоисточник целей проекта. Он задает тон правильной формулировке целей, определяет их количество и объем возможных корректировок в ходе реализации проекта. Четко сформулированная цель определяет ясность намерений всех специалистов команды. Люди должны знать, что именно является критерием достижения цели, а необходимая для этого информация должна предоставляться в формулировке самой цели. Они также должны иметь возможность легко различать, какие действия, скорее всего, будут соответствовать цели, а какие нет. Формулировка целей – дело трудное и крайне субъективное, требующее многократных уточнений для достижения четкости и ясности. Чем меньше будет глобальных целей, тем более действенным станет концептуальный документ. По грубым прикидкам концептуальный документ проекта должен содержать от трех до пяти глобальных целей (для примера см. представленный далее список положений хорошо проработанной концепции).
Для правильной формулировки целей широко используется деловой подход, выражаемый акронимом SMART (Specific, Measurable, Action-oriented, Realistic, Timely – точность, измеряемость, действенность, реалистичность, своевременность). Идея состоит в том, что если цель соответствует этим пяти требованиям, то, скорее всего, она достаточно хорошо определена для дальнейшего использования (тем не менее остаются субъективные рассуждения о том, насколько конкретной или реалистичной должна быть цель). При формулировке цели можно воспользоваться и другим приемом – отнестись к ней максимально придирчиво и задаться вопросом, не провалится ли проект, если его цель будет достигнута в точном соответствии с ее формулировкой. Затем нужно подумать, а нельзя ли более точно сформулировать цель, нет ли какой-нибудь дополнительной, уточняющей информации.
Консолидирующая способность
Чтобы концептуальный документ приобрел какое-либо влияние, в нем должны быть консолидированы разноплановые идеи. Он должен впитать ключевые мысли исследователей, аналитиков, специалистов по стратегическому планированию и т. д. и стать лучшим выражением этих мыслей. Любая концепция будет считаться для команды неудачной, если понимание потребует от читателя проделать чуть ли не половину авторской работы.
По этой причине лучше всего отделить цели и директивы от всех вспомогательных аргументов и исследований, на основе которых велось планирование. Должно быть определено конкретное место (в виде простого веб-сайта), где можно будет легко отыскать все дополнительные доводы и материалы, что должно подстегнуть всех усердствующих (или скептиков) погружаться в глубины, не отраженные в самом концептуальном документе. Консолидация не означает, что материал должен быть преподнесен в виде нагромождения из случайных подборок справочной информации, она подразумевает наличие некой логической последовательности. При подаче материала должны использоваться единые шаблоны, форматы, или, по крайней мере, вся информация должна легко собираться в единый печатный том: не ради процесса как такового, а потому, что так материал будет легче читаться. Это заставит кого-то (желательно, главного босса) определить конкретное количество ссылок или первоисточников, с которыми должны быть ознакомлены все участники проекта. Указанное количество должно быть отличным от нуля, но в то же время оно не должно превышать пятнадцать или двадцать документов, статей или сообщений.
Вдохновляющая способность
Вдохновению никогда не способствуют какие-либо поверхностные факторы (а оно, между прочим, необходимо даже весьма поверхностным людям). Чтобы войти в сознание людей, нужна абсолютно понятная, практически ценная задача, ожидающая своего решения, и команда, способная на ее решение и проявляющая к ней определенный интерес. Несмотря на то что в этом деле может помочь убежденность лидера и его умение оказывать влияние на людей, значение качества идей, заложенных в концептуальном документе, ничуть не умаляется. Если читателям концепции будет предложено ясное представление имеющихся возможностей и дан четкий план их реализации, появятся и люди, способные вдохновиться решением обозначенной проблемы. Программисты и инженеры имеют особенность черпать вдохновение в решении сложных технических проблем, но и в существующей практической задаче, которая должна решаться в рамках проекта, подобные сложности найти совсем не трудно. Каждый должен понять, что проект финансируется с целью решения определенной практической, а не только технологической задачи.
Запоминаемость
Запоминаемость предполагает наличие двух условий: во-первых, идеи должны иметь смысл, и во-вторых, они должны отложиться в сознании читателей и оставаться в нем на весь срок работы над проектом. Они могут запомниться не более чем несколькими характерными особенностями, но этого будет достаточно для уверенности исполнителей в правильной направленности их повседневной работы. (Если концептуальный документ слишком сложен для понимания, добиться желаемого эффекта невозможно. Люди редко запоминают то, в чем не могут разобраться.)
Запоминанию больше всего способствует прямое и простое изложение мыслей. Если вы сможете впечатлить сутью принятых решений и понятно их изложить, то даже не до конца согласные с ними люди будут помнить их намного дольше, чем решения концептуального документа, изложенные неубедительно и запутанно, но полные идей, в которые они безоглядно верят. Поэтому стремитесь к понятному и убедительному изложению концептуальных взглядов. Вооружите команду четкой концепцией и образом мышления в отношении предстоящей работы. Старайтесь избегать ярких идей, способных увлечь людей на короткое время, или увлечений вычурными и сиюминутными тенденциями, которые могут через пару недель «сойти на нет», полностью обесценивая ранее соответствовавшие им идеи.
Ключевые моменты
В основу концепции должны быть положены ответы на многие из приводимых далее вопросов. Обычно эти ответы становятся основными заголовками концептуального документа или перечисляются в конце, в разделе вопросов и ответов. (Даже если данные вопросы не нашли свое место в основном документе и отражены в приложении, предполагается, что инженерам свойственно переходить к последним страницам в надежде отыскать что-либо негативное в противовес всему изложенному ранее.)
Для ответа на многие из приводимых далее вопросов требуется привлечение специалистов по рыночным исследованиям, по изучению потребительских запросов, по проектированию изделий или других доступных вам экспертов, причем делать это нужно своевременно. Часть вопросов намеренно совпадает с вопросами из предыдущей главы, которая посвящалась планированию. Отличие состоит в том, что эти вопросы рассматриваются строго в ракурсе приоритетов и решений, а не содержимого и предположений. Хотя в ходе планирования отводится место и исследованиям, концепция должна быть преподнесена в утвердительной и убедительной форме.
Каким одним предложением можно определить конкретный выпуск изделия в рамках этого конкретного проекта? (Это часто называется концептуальным положением, или, как говорят штатные шутники команды разработчиков, «формулировкой заблуждения». Примеры подобных предложений будут вскоре предоставлены.)
• Как этот проект содействует целям организации? Почему он важнее других проектов, которые также могут содействовать достижению этих целей?
• Какие сценарии или потребительские свойства являются основными для данного проекта? (Приоритет – 1.)
• Какие сценарии или потребительские свойства, не являющиеся основными, желательно реализовать? (Приоритет – 2.)
• Что представляют собой потребители продукта? Какие проблемы решаются в их интересах реализацией данного проекта? Какими очевидными признаками или исследованиями (в противовес мнениям и предположениям) подкреплены эти утверждения? Как потребители справляются со своей работой без продукта, реализуемого данным проектом?
• Кто представляет в организации стороны, заинтересованные в данном проекте (люди, облеченные полномочиями по реализации данного проекта, которые не обязательно должны быть пользователями создаваемого в его рамках продукта)? Какая роль им отводится в проекте? (Заинтересованные стороны будут рассмотрены в главе 16.)
• Почему потенциальные потребители станут покупать изделие или подписываться на услугу? (Туманные фразы вроде «потому что это круто» или «потому что им не из чего выбирать» в качестве ответа не годятся. Тем не менее допустим краткий обзор того, на что эти потребители тратят средства в данный момент и как новый продукт впишется в их образ жизни, бюджет или устоявшиеся привычки. Разумеется, если имеется в виду продукт из сферы информационных технологий, может прозвучать и ответ «потому что им не из чего выбирать».)
• Кто является конкурентом в данной области и как продукт, создаваемый в рамках проекта, выдерживает сравнение с изделиями этого конкурента? (В число конкурирующих факторов должны включаться предыдущие реализации подобных проектов или всевозможные нетехнологичные альтернативы, такие как карандаш и бумага. Для наладонного органайзера Palm Pilot простейшей конструкции в качестве первичного конкурента должна рассматриваться обыкновенная бумага, а не другие электронные устройства.)
• Какие решения, направленные на удовлетворение потребительских нужд, были востребованы или предложены, но определенно не станут частью проекта?
• Какие существуют не связанные с технологией подходы к исследованию проблемы?
• Что не планируется выполнять в рамках проекта? (Перечислите без лишнего педантизма те идеи, которые могут кем-то рассматриваться в качестве части проекта, но в него не войдут. Включите в рассмотрение деловые и потребительские взгляды на проект, если очередь до них еще не доходила.)
• Каковы более-менее вероятные возможности провала данного проекта и как их можно исключить или свести к минимуму? (В ранних прикидках могут быть только оценки рисков без планов, как их избежать или справиться с ними.)
• Что в успехе данного проекта зависит от других компаний или групп? Зависит ли успех других компаний или групп от реализации данного проекта?
• Как в общем представлении будет распределена работа между командами? Кто возглавит каждое из основных направлений проекта, какими полномочиями будут наделены эти люди?
• Какие были выдвинуты предположения, от которых зависит успех проекта? В какой степени данный проект зависит от других проектов, компаний или организаций?
Каждый вопрос или положение первостепенной важности требует серьезного обдумывания. Руководитель проекта должен отыскать самых толковых и скептически настроенных специалистов команды и поручить им найти уязвимости в логике и обоснованиях, стоящих за ключевыми положениями. Поскольку эти положения лягут в основу всего остального, они должны быть неопровержимыми. Процесс оценки положений проекта лучше провести неформально, один на один или в очень маленькой группе, чтобы руководитель проекта смог объединить все критические замечания и учесть новые взгляды на проект после каждой дискуссии.
Умение четко излагать мысли
Даже тем из нас, кто обладает способностью неплохо излагать свои мысли, концептуальные и руководящие документы предоставляют потенциальное средство выделиться. Совершенно неожиданно появляется возможность продемонстрировать всей организации полет своей мысли – слишком трудно подавить в себе эгоистические искушения. Но претенциозность сама себя и губит, поскольку вместо передачи идей она их просто затмевает.
Простота дается не легко
Наиболее распространенной ошибкой при изложении концепции является приравнивание сложности мысли к сложности ее представления. Вопреки расхожим мнениям, изложение сложных идей простым и доступным языком требует значительно большего времени, чем наоборот (подобная взаимосвязь распространяется и на написание программного кода, и на сочинение статей). Основные идеи концепции могут запросто потеряться в десяти страницах выводов, пояснений, графиков и диаграмм. Включение большого количества вспомогательного материала может свидетельствовать лишь о ненадежности авторских выкладок и неумении кратко излагать свои мысли (почитайте любой академический или философский журнал, и вы найдете массу подобных примеров). К сожалению, эту манеру легко перенять. Ей свойственно зарождаться в верхушке организации и, просачиваясь вниз, становиться причиной трудно искоренимых уровней скверного стиля общения. В некоторых компаниях иногда сразу и не поймешь, что документ написан на родном языке.
Поэтому концептуальный документ определяет не только направление проекта. Он задает тон и устанавливает качественный уровень общения, который людям следует ожидать друг от друга в процессе работы над проектом. Благодаря концептуальному документу у руководителей команд появляется шанс показать всем остальным, как можно перенять этот стиль и организовать качественный обмен информацией. И наоборот, если концептуальный документ раздут, перегружен непонятными словами, высокопарно изложен, изобилует теорией, непоследователен или содержит бредовые идеи, не стоит удивляться тому, что и проект в результате будет страдать теми же недостатками.
Хорошие концептуальные документы никогда не отходят от основных идей. Они обходятся без предисловий, оговорок и введений, в них не делается попыток скрыть ключевые (и, возможно, спорные) решения, определяющие суть проекта. Поэтому они зачастую невелики по объему и легко читаются. Мне приходилось просматривать множество скверно составленных и раздутых концептуальных документов, которые пугали отнюдь не чрезмерной оригинальностью мысли, а своими физическими размерами. Эффект был неизменным – их просто никто не читал.
У хорошей разработки только один главный автор
Многие из виденных мною крайне неудачно разработанных концептуальных документов были созданы комиссиями. Порой немногочисленные комиссии могут действовать в качестве хорошего резонатора, но им никогда не удастся сыграть роль ведущего автора или человека, облеченного правами принимать решения. Если нет исключительного взаимопонимания и общего видения (которые, принимая во внимание политику работы комиссий, обычно легко предаются анафеме), перспективы выработки комиссией ясного, краткого и емкого документа весьма сомнительны. Поэтому руководитель проекта или лидер нуждается в полномочиях, позволяющих ему стать автором концепции и выработать ее единолично с полным осознанием того, что суть его работы состоит не в письменном выражении собственной индивидуальности, а в кратком изложении лучших идей и замыслов, выработанных в его организации. Этот главный автор должен стремиться к сотрудничеству, позволяющему свести лучшие идеи и мнения других специалистов в единый документ.
Каноническим примером единоличного авторства служит Декларация независимости США. В 1776 году Континентальный конгресс сформировал комиссию для выработки этого документа. Комиссия собиралась несколько раз, однако осознав особую важность такой характеристики документа, как доходчивость, поручила разработать проект Томасу Джефферсону. Джефферсон поступил так же, как я рекомендую поступать и команде проектировщиков, – он разработал множество проектов и принял участие в их обсуждении в Конгрессе, по нескольку раз пересматривая некоторые из них. Несколько недель спустя, группа представила Конгрессу окончательный вариант документа. Автор не должен быть постоянно на виду, Джефферсон в процессе работы над Декларацией не занимался сбором подписей и согласованиями. Он просто получил полномочия и использовал свой талант во благо всей группы разработчиков.
Качество не определяется объемом
Следует понимать, что ясная мысль не требует многостраничного изложения. Самые действенные руководящие документы в мире не отличались большим объемом. Конституция США, включая Билль о правах, содержит всего лишь 7000 слов (около 6 страниц). Десять заповедей состоят из 300 слов. Великая хартия вольностей – из 5000. Светлые головы способны извлечь из идей самую суть и выразить их намного доходчивее любых описаний, занимающих вдвое больше места. Не следует путать понятия объема и качества. К сожалению, из-за того, что объем дается легче, чем качества, мы иногда поддаемся следующему искушению: «Если ничего хорошего не выходит, то можно выиграть хотя бы за счет объема, а вдруг никто не заметит разницы» (еще одна привычка в работе авторитетных комиссий). Итак, с учетом всего вышеизложенного, вполне уместно спросить меня о том, почему же я не сократил объем этой книги. Виноват, не смог.
Все эти рассуждения предполагают, что к назначению человека, который будет заниматься созданием предварительных версий концептуальных документов и их пересмотром, нужно подходить со всей ответственностью. Вполне возможно, что наилучшим проводником идей в организации окажется человек, не имеющий высоких титулов. Скорее всего, выработка хорошей концепции потребует авторства одного из руководителей проекта, способного трезво оценить наряду со своими собственными сильные и слабые стороны людей, работающим под его началом.
Прикидки, пересмотры и переработки
В каждой организации бытуют собственные представления о том, как вести планирование проекта. Я не могу предложить вам какой-нибудь простой план из пяти этапов, начинающийся с первого дня, когда никакой концепции еще нет и в помине, и заканчивающийся днем двадцатым (или пятым, или пятидесятым), когда на стол кладется вполне готовая всеми одобренная концепция. В зависимости от того, каким объемом полномочий вы наделены, для всех необходимых согласований и проведения всех переговоров может потребоваться немалый срок.
Важно то, что процесс выработки концепции начинается еще до того, как завершается работа над тем проектом, которым команда занята в данный момент, и этот процесс должен быть завершен ко времени, когда команда будет готова с полной отдачей сил заняться новым проектом. Иногда в завершающей фазе предыдущего проекта можно отвлечь кого-нибудь от текущей работы с тем, чтобы он потратил половину своего рабочего времени на предварительную проработку рассмотренных ранее вопросов. Затем руководитель команды сможет подхватить у него эстафету и выработать предварительную версию концепции значительно быстрее, чем в том случае работы в одиночку.
Зачастую в крупных организациях наиболее ответственная часть этого процесса не обходится без участия старшего руководства, чтобы можно было согласовать с ним задачи предстоящей работы (см. главу 16). Нет ли у генерального директора или у других руководителей планов в масштабе всей организации, которые могут повлиять на задуманный проект? Есть ли специалисты или ведущие руководители, у которых обязательно следует проконсультироваться? Есть ли в организации представители руководящего звена (на уровне команд или организации в целом), обладающие нужным опытом или политическим влиянием, с которыми стоит наладить взаимоотношения? Ожидают ли от нас выработки каких-нибудь ключевых идей или, по крайней мере, принимают ли во внимание такую возможность? Нужны ли мы для выработки чего-либо подобного в интересах других проектов, осуществляемых организацией, что могло бы способствовать успеху в их реализации?
В лучшем случае представители высшего руководства сами дадут внятные ответы на некоторые из этих вопросов, осознав, что если они оставят ключевые вопросы вообще без ответов, то в проект будет внесена никому не нужная неопределенность. В худшем случае на плечи руководителя проекта ляжет тяжкое бремя и ему придется самостоятельно найти ответы на данные вопросы и очертить реальные границы проекта, пользуясь методом проб и ошибок. (Конечно, если вы работаете в небольшой организации, где ответить на вопросы способны только вы сами или люди, равные вам по положению, вся ответственность в сфере управления, плохо это или хорошо, ложится, естественно, на вас.)
В любом случае суть работы от этого не меняется. Выстраивая график проектирования, начиная со времени завершения предыдущего проекта и заканчивая тем сроком, к которому работа над новым проектом должна уже идти полным ходом, нужно выбрать промежуточные контрольные точки, определяющие готовность предварительной версии, ее рассмотрение с участием всех основных специалистов команды и завершение разработки первого варианта концепции проекта. Ожидается, что в каждой контрольной точке рассмотрения определенное время будет тратиться на переработку и улучшение предварительной версии (не стоит рассчитывать, что в конце каждой рабочей встречи все будут согласно кивать головами). Начните с малого, постепенно наращивая поддержку процесса выработки основных идей, улучшая их содержание после каждой предоставившейся возможности для их всесторонней оценки. Рабочий график данного процесса должен быть доведен до всех заинтересованных лиц (рис. 4.3), и люди, входящие в состав небольшой рабочей группы, не должны прятаться в отдаленных офисах или других зданиях. Они должны быть постоянно на виду и доступны команде (разумеется, с учетом того, что их не следует без дела отвлекать от работы над текущим проектом). Поощрение расспросов и открытости всегда помогают плавному переходу к работе над новым проектом.
Составной частью этого процесса должна стать презентация всей команде (на так называемом общем совещании) ключевых идей и чернового варианта концепции, которую следует провести не слишком поздно, чтобы не превратить все в пустую формальность, но и не слишком рано, чтобы можно было уже вести разговор по существу. Несмотря на то что новых руководителей часто охватывает чувство страха перед подобным мероприятием, если совещание проводится в тот момент, когда основные идеи уже сформированы, но вопросы еще остаются, каждому участнику проекта представится возможность воспринять концепцию как нечто живое и доступное. Они не станут отвергать концепцию, если в ней еще есть что-то, на что они могут повлиять или по поводу чего могут задать вопросы. Если концепция создается с проведением многократных обсуждений и предоставлением благоприятных возможностей для высказывания критических замечаний, то ее представление команде будет выглядеть естественным событием для всех присутствующих.
Рис. 4.3. Основной график рассмотрения и корректировки концептуального документа
Как только концептуальный документ будет готов, стадия планирования завершится (см. рис. 4.3). Команда должна располагать информацией, необходимой для успешного проектирования в соответствии с поставленными целями. Если работа над концепцией велась в той последовательности, которая показана на рис. 4.2, команда должна приступить к проектированию, поскольку основные направления ей были известны заранее.
Перечень неудачных положений концепции (которых следует избегать)
За свою профессиональную карьеру мне приходилось читать десятки концептуальных документов и самые плохие из них содержали одни и те же стереотипы. Плохо составленные концепции не имеют целостности, не предлагают никакого плана и не выражают совокупности мнений. Вместо этого в них излагаются размышления и прописные истины. Если в концепции нет четкого взгляда на то, что должно быть сделано, руководители команд никогда не станут работать с душой, обрекая проект на провал. Герой фильма «Бойцовский клуб» («Fight club») Тайлер Дурден (Tyler Durden) говорит: «Если вы воткнете себе сзади перья, то все равно не станете курицей». Если вы создаете документ с надписью «концепция» на титульном листе, это еще не означает, что в результате вы получите именно концепцию. Можно делать все по правилам, проводить совещания, пользоваться формализованными документами и все же упустить всю суть, ради которой и создается концептуальный документ. Точно так же, как титул «руководитель проекта» не означает волшебного превращения всего, что вы делаете в действии руководителя, присваивание какому-нибудь документу название концептуального не означает, что он возымеет описанный выше эффект.
В табл. 4.1 представлено несколько типичных формулировок, встретившихся мне во внушительно выглядевших концептуальных документах, которые обесценивали их в глазах руководства проектом.
Таблица 4.1. Типичные примеры неудачных концептуальных положений
Примеры концептуальных положений и целей проекта
В данном разделе я приведу несколько примеров удачных концептуальных положений и целей проекта, исходя из собственного опыта. Кое-что в деталях я изменил, но это не помешает составить представление о том, на что направлен проект и какие цели могут преследоваться на основе предложенной концепции.
Вот примеры вполне удачных концептуальных положений:
• SuperEdit 3.0 – это инструмент редактирования, предназначенный для опытных литературных редакторов, позволяющий облегчить их работу, ведущуюся по пяти самым распространенным сценариям, более надежный и быстродействующий по сравнению с SuperEdit 2.0.
• Superwidgets.com станет ведущим веб-сайтом Интернета, предназначенным для приобретения разного рода небольших приспособлений и устройств снабженцами средних по величине компаний. Он сделает весь процесс приобретения простым, легким и надежным.
• В версии 5.5 Helpdesk Automated Services Site (HASS) будут учтены десять самых распространенных претензий, предъявленных пользователями из числа преподавателей и студентов университета, при этом исключаются любые негативные влияния на среднюю производительность, надежность или на время отклика системы.
В качестве примера удачных целей проекта приводится перечень, использовавшийся разработчиками наладонного органайзера Palm Pilot:[25]
1. Габариты. Устройство должно помещаться в карман рубашки, быть достаточно легким, чтобы не выглядеть громоздким.
2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).
3. Простота. Устройство должно быть в обращении не сложнее бумажного листка, готово к работе сразу после включения и иметь простые элементы управления.
4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.
Удачно сформулированные цели проекта, подобные перечисленным, отличаются простотой и ясностью и описывают порядок вещей, который должен сложиться по завершении работы. Следует помнить, что простота является обратной стороной сложности. Было весьма не просто конструктивно и технологически создать устройство, удовлетворяющее всем обозначенным целям. Представленные ранее примеры удачных концептуальных положений могут оказаться трудновыполнимыми для подобных проектов. В зависимости от того, что именно означают понятия «ведущий», «более простой в использовании» и «самые важные претензии», они могут обернуться немалыми трудностями в реализации проекта.
Обоснование концептуальных положений и целей
Требования, изложенные в концептуальных положениях или в целях проекта, должны быть раскрыты или объяснены в других разделах документа. Значение этих положений для пользовательских нужд, облегчения работы, надежности или учета наиболее распространенных претензий должно быть в достаточной степени разъяснено, чтобы можно было принять вполне обоснованные решения. Если важность данных положений позволяет им стать частью концепции, стало быть, их целесообразно сопроводить конкретными разъяснениями специалистов с такой же степенью детализации и определенности, с которой формулируются технологические цели. Если поставлена цель добиться «простоты использования», но по этому поводу никем не предоставлено никаких разъяснений, команда не будет настроена на достижение этой цели. При выработке концепции руководство должно оценивать потребности в ресурсах для успешной реализации проекта и определять способы заполнения пробелов, имеющихся в ресурсах и мастерстве разработчиков (можно выбрать обучение персонала, поднаем специалистов, корректировку самой концепции или скрещивание пальцев на удачу).
Концепции должны быть наглядными
Указывая пальцем на Луну, не перепутайте палец с Луной.
Дзен-буддистская притча
Концепции, или по-иному, системы взглядов, названы именно так потому, что они предполагают обращение к нашей способности сформировать визуальное представление какого-то конечного результата. Разглядывая какую-нибудь картину, мы одновременно воспринимаем несколько уровней заложенной в ней информации. Многим самым сложным концептуальным положениям и идеям изображения придают наглядность – изображения воспринимаются намного быстрее и понятнее, чем словесные описания. Я десятки раз в своем офисе вел переговоры с программистами или с разработчиками архитектуры компьютерных систем, которые настойчиво пытались докопаться до сути приводимых аргументов, и все заканчивалось лишь тогда, когда кто-нибудь из нас, в конце концов, подходил к доске, воплощал идею в эскизе и спрашивал: «Вы именно это имели в виду?» После чего обычно раздавался взрыв хохота, вызванный осознанием того факта, что мы затратили впустую уйму времени, пытаясь объяснить суть объектной модели или конструктивных особенностей на словах или на пальцах, в то время как сделать это с помощью доски и фломастера было намного проще и быстрее. Думаю, что в американской культуре основной упор делается на развитие навыков устной речи и умение производить математические выкладки, а не на развитие артистических и изобразительных способностей, поэтому многим профессионалам для приобретения соответствующих навыков требуется некоторая практика. Я убежден, что мы многое теряем, забывая об эффективности выражения идей изобразительными средствами.
Все лучшие образцы концептуальных документов включали элементы визуализации в виде набросков, макетов или прототипов конечного вида продукта, получаемого при условии следования предложенной концепции. Все они сопровождались пояснительными материалами и предварительными прикидками, которые позволяли получить достаточное представление о сути идеи и помогали целям, изложенным в концепции, укрепиться в сознании изучающих ее людей. Благодаря этому становилось понятным, что макеты далеки от конечной версии создаваемого продукта. Слишком далеки. Зато они являются ранней попыткой наполнить содержанием идеи, заложенные в концепцию, и являются своеобразным предположением, позволяющим обсуждать саму работу, а не только представление о ней, предложенное концепцией.
Макеты и прототипы зачастую воспринимаются консервативно настроенными инженерами и программистами намного лучше, чем любые диаграммы объектных моделей или примеры кода. В отличие от этих привычных форм абстрактного отображения информации визуальные прототипы показывают нечто пока не существующее, но вполне осуществимое в будущем. Архитекторы небоскребов и конструкторы автомобилей создают множество физических макетов и прототипов, помогающих им осмыслить идеи, над которыми они работают, и получить на них отзывы со стороны. Создатели кинофильмов для тех же целей используют доску с эскизами, изображающими сцены из фильма. В концептуальных документах, претендующих на качественное исполнение, не следует избегать подобных технологий. Демонстрация эскиза конечного вида продукта позволяет каждому осмыслить его вклад в общее дело. После этого входящие в команду разработчики нацеливаются не просто на создание того или иного компонента, у них возникает представление о том, где и в чем этот компонент найдет применение, когда разработка программного продукта будет завершена.
Наглядное представление неочевидных вещей
Если проект не имеет никакого отношения к пользовательскому интерфейсу или к интерактивному общению с пользователями, это еще не означает, что он не может быть наглядно представлен. Следует задаться вопросом, какие изменения произойдут в случае реализации проекта? Возможно, концепция касается устранения некоторых чисто человеческих проблем или неудовлетворенностей (медлительность серверов, склонность баз данных к частым сбоям и т. д.). Все это может быть наглядно показано путем демонстрации (или симуляции) одного и того же веб-сайта до начала и после окончания работ, или прототипа, позволяющего сравнивать последовательность необходимых действий пользователя до и после, выражая тем самым, насколько все может упроститься с применением новой архитектуры или новой структуры базы данных.
Существует множество способов визуализации идей, сколь бы абстрактными или технократическими они ни казались. Если проект позволит пользователям проводить меньше времени за рабочим столом, нарисуйте рядом с этим столом пустой стул. Если проект ускорит работу базы данных, покажите два демонстрационных ролика, отражающих ее работу до и после. Если отказоустойчивость встроенной системной API-функции повысится на 10 %, предоставьте показания тестовой программы, используемой для измерения данного параметра до и после реализации проекта. Как бы это ни было скучно для команды, но ей нужно дать наглядное представление о границах индивидуальной работы.
Если конечный результат работы не может быть наглядно представлен даже в виде эскиза, макета или схемы, я готов утверждать, что концепция вряд ли будет правильно истолкована. Если вы не в состоянии найти какое-нибудь визуальное представление того, что изменится в этом мире под влиянием проекта, стоит призадуматься, не направлен ли этот проект на создание совершенно бесполезных вещей или достаточно ли он понятен, чтобы быть успешно претворенным в жизнь.
Искусство представления вида будущего изделия и визуализации идей, особенно если к этому процессу привлекаются результаты изучения потребительского спроса, является прерогативой проектировщиков. Иногда их называют дизайнерами потребительских товаров, проектировщиками изделий или даже специалистами по художественному конструированию. Искусством визуализации идей и превращению абстрактных замыслов в детали того, что увидят потребители, можно овладеть только на профессиональной основе. Хотя подобный талант присущ некоторым разработчикам и руководителям проектов, немногим из них удается обратить его в истинное мастерство. Если ставятся цели добиться простоты использования продукта и удовлетворения потребительских запросов, то услуги дизайнеров должны быть востребованы на самых ранних стадиях проработки проектов, а привнесение этого аспекта в концепцию должно стать лишь одним из возможных естественных вкладов в проект со стороны этих специалистов. Если эти услуги дизайнеров привлечены на достаточно ранней стадии и руководство обеспечило реальное внедрение приложенных ими усилий в проект, то это приведет не только к чисто внешней привлекательности продукта, но и будет способствовать повышению его потребительских качеств.
Ежедневное поклонение концептуальным положениям
Один из оригинальных экземпляров Конституции США помещен в музейное хранилище в Вашингтоне, округ Колумбия, за толстыми листами из сверхпрочного стекла. Хотя этот экземпляр хранится в безопасном и надежном месте, я уверен, что в таком формате его читали немногие. Когда идеи недоступны или остаются в тени, они постепенно уходят в небытие (если только из-за особой ценности их не делают музейными экспонатами). Даже в краткосрочных проектах легко утратить ту общую для проекта канву, в которую должны вписываться ежедневные решения, и недостаток видения основных идей способствует возникновению этой разновидности энтропии. Люди могут быть загружены до предела и успешно работать над решением частных задач, но без частой сверки курса с общими ориентирами им будет довольно трудно понять, что все они движутся в правильном направлении. Концепция, или сборник основных идей и целей проекта, является частью общего процесса, и поэтому она должна постоянно присутствовать в коридорах и офисах людей, выполняющих свою работу.
Чтобы концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах. Их открытое обсуждение должно вестись на еженедельных или ежемесячных совещаниях после предварительной публичной зачитки. Если командой используется демонстрационный экран или другие вспомогательные средства визуализации, то ключевые моменты должны быть отображены на первом слайде или первой странице. Большинство сотрудников в любое время должны быть в состоянии назвать основные цели проекта, по крайней мере, те из них, к которым они имеют непосредственное отношение или за реализацию которых несут личную ответственность.
Но этих мер явно не достаточно для поддержания концепции в актуальном состоянии. Лишь то, что люди ее запомнили, еще не означает, что они ее используют в своей работе. Сохранение актуальности концепции требует усилий со стороны руководства команды. Оно должно постоянно обращаться к тем самым мотивам, которые и привели к созданию самой концепции.
В процессе работы над реализацией проекта на каждом совещании по подведению итогов или постановке задач обращайтесь к следующим вопросам:
1. Насколько точно концепция отражает наши цели, определенные для этого проекта?
2. Помогает ли концепция ведущим и рядовым сотрудникам принимать решения, а также отклонять запросы, не имеющие к ней отношения?
3. Есть ли достойные обсуждения изменения концептуальных положений, позволяющие положительно ответить на два первых вопроса?
Если руководство организации в состоянии сохранять актуальность концептуального документа, то предоставляет такую же возможность и всем остальным. Концепция и цели проекта сохраняют жизненные силы и могут служить постоянным источником мотивации и ясности действий всей команды.
Но это вовсе не означает, что концепция должна подвергаться частым корректировкам. Наоборот, существенные изменения, после того как проект наберет полные обороты, должны быть событием исключительным. Но, как и в случае с поправками к Конституции, вполне вероятно, что при определенных обстоятельствах вносимые изменения будут вполне оправданы. И такая возможность позволяет сохранять у всех четкость представлений и осмысленность основных концептуальных замыслов.
Выводы
• Концептуальные документы являются квинтэссенцией всех остальных материалов планирования и находят свое выражение в едином обобщенном плане.
• Документирование приносит пользу и создателю концепции, и всей команде. Тем самым закладываются основы для проведения дискуссий и рабочие ориентиры, не зависящие от нашей «дырявой» памяти.
• Степень детализации вашего концептуального документа зависит от особенностей команды и самого проекта.
• Цели команды должны быть производными от целей, определенных в концепции, а индивидуальные цели, в свою очередь, от целей, поставленных перед командой.
• Хорошая концепция отличается простотой, запоминаемостью, целенаправленностью, способностью консолидировать усилия участников проекта и вдохновлять их на его реализацию.
• Объем не является эквивалентом качества. А краткость требует больших усилий.
• Концепция должна сохранять актуальность за счет ее повседневной сверки с решениями, принимаемыми в ходе реализации проекта.
Читать бесплатно другие книги:
