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

Таблица 3.1. Наиболее распространенные просчеты в определении конечной цели проекта

Процесс планирования

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

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

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

Рис. 3.3. Взаимосвязь между уровнями планирования

Черновой вариант каждого входящего в планирование документа должен быть готов как можно раньше, чтобы до выработки окончательной версии включить в него все обратные связи, выработанные командой. Это могут быть простые циклы обратной связи между документами плана, изображенные на рис. 3.3. После создания чернового варианта анализа потребностей рынка – MRD, появится возможность приступить к работе над концептуальным документом, во время которой будут возникать новые вопросы, касающиеся этого анализа, улучшающие документ до его завершения. Эта же схема работы повторяется при разработке всех документов. Таким образом, даже если сроки окончания разработки документов плана поджимают, некоторые перекрытия по времени разработки каждого из них пойдут только на пользу и повысят качество всего процесса. Как показано на рис. 3.4, когда разработка проекта достигает середины (стадии выполнения), распространение вверх по структуре планирования подобных обратных связей дается все труднее, хотя и не исключается. (Можно считать, что рис. 3.4 иллюстрирует работу нанятой по контракту команды, сфера влияния которой ограничена выработкой технических условий и определением характера и объема работ.)

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

Повседневная работа

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

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

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

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

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

Исследование потребительских запросов и допускаемые при этом просчеты

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

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

Таблица 3.2. Типичные методы исследования потребительских запросов

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

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

В оригинале «Usability study». – Примеч. ред.

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

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

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

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

Объединяем все вместе – выработка требований

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

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

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

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

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

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

• Ведомственная информационная страница долго загружается, заставляя пользователя ждать.

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

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

• Результаты поиска трудно просматривать в существующем формате.

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

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

• Отсутствует способ сохранения предпочтений или вариантов появления домашней страницы.

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

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

Проблемы превращаются в сценарии

Поскольку постановка задач отражает текущее состояние дел, проект нуждается в чем-то другом, отражающем состояние, которое будет достигнуто по завершении работы. С этой целью нужно переработать постановку задач в нечто иное, называемое формулировкой характеристик или сценарием. Для этого существует масса различных способов. Одним из самых популярных считается метод сценариев использования (use-cases),[23 - Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).] но существуют и другие методы.

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

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

Итак, возможные характеристики проекта X:

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

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

• Веб-сайт обеспечит простой автоматизированный доступ к защищенным услугам.

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