Для подробного разговора о концептуальном документе необходимо дать определение нескольким терминам. Понятия концепции, общекомандной цели и просто цели часто смешивают. Я же собираюсь их использовать в следующем толковании:
Концепция определяет главные цели, относящиеся к проекту в целом. Может также включать концептуальные положения или сверхзадачу. (Главные цели, определяемые в концептуальном документе, иногда называют задачами, чтобы отличать их от целей более низкого уровня.)
Общекомандные цели. Подраздел концепции, относящийся к сфере ответственности конкретной команды, определяемый несколько глубже, чем общая концепция. (Например, команда А может отвечать за разработку базы данных и достижение связанных с этим целей, а команда Б – за разработку поисковой машины и решение сопутствующих задач, но обе эти команды работают в рамках общей концепции проекта.)
Индивидуальные цели. Подраздел общекомандных целей, являющийся сферой ответственности отдельного работника.
Для небольших проектов разница между общекомандными и индивидуальными целями может быть незначительной (рис. 4.2). Проект даже может быть настолько мал, что ее и вовсе не будет. Но для больших проектов, в работу над которыми вовлекаются 50 и более человек, необходимо определить и этот уровень. Работая практически на протяжении всей своей карьеры в составе больших команд (заведомо больше 50 человек), я привык иметь дело с этими тремя уровнями: уровнем, относящемся ко всему проекту в целом (уровень концепции), уровнем, относящемся к отдельным деталям или областям проекта (уровень команды), и уровнем персональных задач для каждого работающего над проектом специалиста (индивидуальный уровень). Первые два уровня являются общими для всей команды, а третий относится к работнику и его руководителю.
Рис. 4.2. Три уровня целей
Давайте в качестве примера возьмем некий проект создания корпоративного веб-сайта под названием «Гидра»:
• Концепция. Веб-сайт «Гидра» предоставит удобный доступ к большинству наиболее востребованных источников корпоративной информации (поиск, учет, инвентарь, внутренние ресурсы, перевозки) из единого места с использованием простого и понятного интерфейса.
• Общекомандные цели. Команда А будет отвечать за создание доступных и простых в применении систем поиска и учета. Команда Б будет отвечать за создание систем инвентаризации, учета внутренних ресурсов и перевозок.
• Индивидуальные цели. Фрэд (из команды А) будет заниматься проектированием и разработкой всех функций, необходимых для поисковой системы. Майк (из команды Б) будет курировать все работы по общему устройству веб-сайта и вырабатывать технические условия на создание интерфейса для «Гидры». Боб (из команды Б) будет заниматься проектированием и разработкой всех функций, необходимых для учета внутренних ресурсов и перевозок.
Здесь прослеживается строгая наследственность сверху вниз: общекомандные цели происходят из целей проекта, а индивидуальные цели – в основном, из сферы целей общекомандных (наиболее важным исключением может стать индивидуальная потребность в обучении или профессиональном росте, которая не может быть удовлетворена в рамках проекта). Если все три уровня хорошо проработаны, станет заметной ежедневная работа всех участников проекта, каждый будет иметь мотивацию на выполнение работы, имеющей для него вполне определенный смысл и являющейся его непосредственным вкладом в реализацию всего проекта. На создание подобной структуры стоит потратить время. Благодаря ей возникает вполне естественный дух сотрудничества и упрощается управление проектом (см. рис. 4.2).
Этим трем уровням определения должны соответствовать различные документы (или, как минимум, различные обсуждения). Чтобы сохранить целостность концепции проекта, возглавить разработку общего концептуального документа должен руководитель группы или руководитель всего проекта. Затем он должен потребовать от руководителей разработки отдельных компонентов или частей проекта перевести общие указания в цели, относящиеся к их сферам ответственности, по возможности выделяя их них определенные темы и задачи. И наконец, рядовые исполнители должны обсудить со своими руководителями команд свои индивидуальные цели и сферы ответственности, вытекающие из общекомандных целей.
Пять качеств хорошей концепции
Поскольку первоисточником всех целей является основная концепция, руководитель всего проекта должен приложить немалые усилия именно к ее созданию, чем к выработке других первичных планирующих документов. Хорошая концепция должна отвечать пяти важнейшим характеристикам: она должна быть достаточно простой, целенаправленной, консолидирующей, вдохновляющей и хорошо запоминаемой.
Простота
Самое важное направление работы – это упрощение смысла проекта. Хорошая концепция должна предоставить ответы на основные вопросы и вооружить всех исполнителей инструментом для принятия решений в рамках их собственной работы. Хотя концепция вызовет и новые вопросы, но в количественном отношении их должно быть меньше тех, на которые уже даны ответы. На ранних стадиях работы над проектом его участники должны постоянно ссылаться на концепцию – при ведении дискуссий, в переписке по электронной почте и на совещаниях, – активно используя ее в качестве вспомогательного инструмента для принятия решений. Руководитель проекта должен внимательно отслеживать ход работы, стремиться уточнить и пересмотреть концепцию, с готовностью включая в нее ранее пропущенные вопросы, повышающие ее полезность для команды. Концепция не должна быть похожа на священную реликвию, заключенную в стеклянный футляр. Она должна больше походить на правила хорошей настольной игры, предоставляя разъяснения для всех ее участников, четко очерчивая границы дозволенного и быстро улаживая споры или налаживая взаимопонимание. Она должна быть потерта на изгибах и краях от постоянного использования и испещрена пометками на полях. Концепция должна быстро положить конец всем подготовительным переговорам и вселить в людей уверенность в успешном претворении проекта в жизнь.
Целенаправленность
Концептуальный документ – это первоисточник целей проекта. Он задает тон правильной формулировке целей, определяет их количество и объем возможных корректировок в ходе реализации проекта. Четко сформулированная цель определяет ясность намерений всех специалистов команды. Люди должны знать, что именно является критерием достижения цели, а необходимая для этого информация должна предоставляться в формулировке самой цели. Они также должны иметь возможность легко различать, какие действия, скорее всего, будут соответствовать цели, а какие нет. Формулировка целей – дело трудное и крайне субъективное, требующее многократных уточнений для достижения четкости и ясности. Чем меньше будет глобальных целей, тем более действенным станет концептуальный документ. По грубым прикидкам концептуальный документ проекта должен содержать от трех до пяти глобальных целей (для примера см. представленный далее список положений хорошо проработанной концепции).
Для правильной формулировки целей широко используется деловой подход, выражаемый акронимом SMART (Specific, Measurable, Action-oriented, Realistic, Timely – точность, измеряемость, действенность, реалистичность, своевременность). Идея состоит в том, что если цель соответствует этим пяти требованиям, то, скорее всего, она достаточно хорошо определена для дальнейшего использования (тем не менее остаются субъективные рассуждения о том, насколько конкретной или реалистичной должна быть цель). При формулировке цели можно воспользоваться и другим приемом – отнестись к ней максимально придирчиво и задаться вопросом, не провалится ли проект, если его цель будет достигнута в точном соответствии с ее формулировкой. Затем нужно подумать, а нельзя ли более точно сформулировать цель, нет ли какой-нибудь дополнительной, уточняющей информации.
Консолидирующая способность
Чтобы концептуальный документ приобрел какое-либо влияние, в нем должны быть консолидированы разноплановые идеи. Он должен впитать ключевые мысли исследователей, аналитиков, специалистов по стратегическому планированию и т. д. и стать лучшим выражением этих мыслей. Любая концепция будет считаться для команды неудачной, если понимание потребует от читателя проделать чуть ли не половину авторской работы.
По этой причине лучше всего отделить цели и директивы от всех вспомогательных аргументов и исследований, на основе которых велось планирование. Должно быть определено конкретное место (в виде простого веб-сайта), где можно будет легко отыскать все дополнительные доводы и материалы, что должно подстегнуть всех усердствующих (или скептиков) погружаться в глубины, не отраженные в самом концептуальном документе. Консолидация не означает, что материал должен быть преподнесен в виде нагромождения из случайных подборок справочной информации, она подразумевает наличие некой логической последовательности. При подаче материала должны использоваться единые шаблоны, форматы, или, по крайней мере, вся информация должна легко собираться в единый печатный том: не ради процесса как такового, а потому, что так материал будет легче читаться. Это заставит кого-то (желательно, главного босса) определить конкретное количество ссылок или первоисточников, с которыми должны быть ознакомлены все участники проекта. Указанное количество должно быть отличным от нуля, но в то же время оно не должно превышать пятнадцать или двадцать документов, статей или сообщений.
Вдохновляющая способность
Вдохновению никогда не способствуют какие-либо поверхностные факторы (а оно, между прочим, необходимо даже весьма поверхностным людям). Чтобы войти в сознание людей, нужна абсолютно понятная, практически ценная задача, ожидающая своего решения, и команда, способная на ее решение и проявляющая к ней определенный интерес. Несмотря на то что в этом деле может помочь убежденность лидера и его умение оказывать влияние на людей, значение качества идей, заложенных в концептуальном документе, ничуть не умаляется. Если читателям концепции будет предложено ясное представление имеющихся возможностей и дан четкий план их реализации, появятся и люди, способные вдохновиться решением обозначенной проблемы. Программисты и инженеры имеют особенность черпать вдохновение в решении сложных технических проблем, но и в существующей практической задаче, которая должна решаться в рамках проекта, подобные сложности найти совсем не трудно. Каждый должен понять, что проект финансируется с целью решения определенной практической, а не только технологической задачи.
Запоминаемость
Запоминаемость предполагает наличие двух условий: во-первых, идеи должны иметь смысл, и во-вторых, они должны отложиться в сознании читателей и оставаться в нем на весь срок работы над проектом. Они могут запомниться не более чем несколькими характерными особенностями, но этого будет достаточно для уверенности исполнителей в правильной направленности их повседневной работы. (Если концептуальный документ слишком сложен для понимания, добиться желаемого эффекта невозможно. Люди редко запоминают то, в чем не могут разобраться.)
Запоминанию больше всего способствует прямое и простое изложение мыслей. Если вы сможете впечатлить сутью принятых решений и понятно их изложить, то даже не до конца согласные с ними люди будут помнить их намного дольше, чем решения концептуального документа, изложенные неубедительно и запутанно, но полные идей, в которые они безоглядно верят. Поэтому стремитесь к понятному и убедительному изложению концептуальных взглядов. Вооружите команду четкой концепцией и образом мышления в отношении предстоящей работы. Старайтесь избегать ярких идей, способных увлечь людей на короткое время, или увлечений вычурными и сиюминутными тенденциями, которые могут через пару недель «сойти на нет», полностью обесценивая ранее соответствовавшие им идеи.
Ключевые моменты
В основу концепции должны быть положены ответы на многие из приводимых далее вопросов. Обычно эти ответы становятся основными заголовками концептуального документа или перечисляются в конце, в разделе вопросов и ответов. (Даже если данные вопросы не нашли свое место в основном документе и отражены в приложении, предполагается, что инженерам свойственно переходить к последним страницам в надежде отыскать что-либо негативное в противовес всему изложенному ранее.)
Для ответа на многие из приводимых далее вопросов требуется привлечение специалистов по рыночным исследованиям, по изучению потребительских запросов, по проектированию изделий или других доступных вам экспертов, причем делать это нужно своевременно. Часть вопросов намеренно совпадает с вопросами из предыдущей главы, которая посвящалась планированию. Отличие состоит в том, что эти вопросы рассматриваются строго в ракурсе приоритетов и решений, а не содержимого и предположений. Хотя в ходе планирования отводится место и исследованиям, концепция должна быть преподнесена в утвердительной и убедительной форме.
Каким одним предложением можно определить конкретный выпуск изделия в рамках этого конкретного проекта? (Это часто называется концептуальным положением, или, как говорят штатные шутники команды разработчиков, «формулировкой заблуждения». Примеры подобных предложений будут вскоре предоставлены.)
• Как этот проект содействует целям организации? Почему он важнее других проектов, которые также могут содействовать достижению этих целей?
• Какие сценарии или потребительские свойства являются основными для данного проекта? (Приоритет – 1.)
• Какие сценарии или потребительские свойства, не являющиеся основными, желательно реализовать? (Приоритет – 2.)
• Что представляют собой потребители продукта? Какие проблемы решаются в их интересах реализацией данного проекта? Какими очевидными признаками или исследованиями (в противовес мнениям и предположениям) подкреплены эти утверждения? Как потребители справляются со своей работой без продукта, реализуемого данным проектом?
• Кто представляет в организации стороны, заинтересованные в данном проекте (люди, облеченные полномочиями по реализации данного проекта, которые не обязательно должны быть пользователями создаваемого в его рамках продукта)? Какая роль им отводится в проекте? (Заинтересованные стороны будут рассмотрены в главе 16.)
• Почему потенциальные потребители станут покупать изделие или подписываться на услугу? (Туманные фразы вроде «потому что это круто» или «потому что им не из чего выбирать» в качестве ответа не годятся. Тем не менее допустим краткий обзор того, на что эти потребители тратят средства в данный момент и как новый продукт впишется в их образ жизни, бюджет или устоявшиеся привычки. Разумеется, если имеется в виду продукт из сферы информационных технологий, может прозвучать и ответ «потому что им не из чего выбирать».)
• Кто является конкурентом в данной области и как продукт, создаваемый в рамках проекта, выдерживает сравнение с изделиями этого конкурента? (В число конкурирующих факторов должны включаться предыдущие реализации подобных проектов или всевозможные нетехнологичные альтернативы, такие как карандаш и бумага. Для наладонного органайзера Palm Pilot простейшей конструкции в качестве первичного конкурента должна рассматриваться обыкновенная бумага, а не другие электронные устройства.)
• Какие решения, направленные на удовлетворение потребительских нужд, были востребованы или предложены, но определенно не станут частью проекта?
• Какие существуют не связанные с технологией подходы к исследованию проблемы?
• Что не планируется выполнять в рамках проекта? (Перечислите без лишнего педантизма те идеи, которые могут кем-то рассматриваться в качестве части проекта, но в него не войдут. Включите в рассмотрение деловые и потребительские взгляды на проект, если очередь до них еще не доходила.)
• Каковы более-менее вероятные возможности провала данного проекта и как их можно исключить или свести к минимуму? (В ранних прикидках могут быть только оценки рисков без планов, как их избежать или справиться с ними.)
• Что в успехе данного проекта зависит от других компаний или групп? Зависит ли успех других компаний или групп от реализации данного проекта?
• Как в общем представлении будет распределена работа между командами? Кто возглавит каждое из основных направлений проекта, какими полномочиями будут наделены эти люди?
• Какие были выдвинуты предположения, от которых зависит успех проекта? В какой степени данный проект зависит от других проектов, компаний или организаций?
Каждый вопрос или положение первостепенной важности требует серьезного обдумывания. Руководитель проекта должен отыскать самых толковых и скептически настроенных специалистов команды и поручить им найти уязвимости в логике и обоснованиях, стоящих за ключевыми положениями. Поскольку эти положения лягут в основу всего остального, они должны быть неопровержимыми. Процесс оценки положений проекта лучше провести неформально, один на один или в очень маленькой группе, чтобы руководитель проекта смог объединить все критические замечания и учесть новые взгляды на проект после каждой дискуссии.
Умение четко излагать мысли
Даже тем из нас, кто обладает способностью неплохо излагать свои мысли, концептуальные и руководящие документы предоставляют потенциальное средство выделиться. Совершенно неожиданно появляется возможность продемонстрировать всей организации полет своей мысли – слишком трудно подавить в себе эгоистические искушения. Но претенциозность сама себя и губит, поскольку вместо передачи идей она их просто затмевает.
Простота дается не легко
Наиболее распространенной ошибкой при изложении концепции является приравнивание сложности мысли к сложности ее представления. Вопреки расхожим мнениям, изложение сложных идей простым и доступным языком требует значительно большего времени, чем наоборот (подобная взаимосвязь распространяется и на написание программного кода, и на сочинение статей). Основные идеи концепции могут запросто потеряться в десяти страницах выводов, пояснений, графиков и диаграмм. Включение большого количества вспомогательного материала может свидетельствовать лишь о ненадежности авторских выкладок и неумении кратко излагать свои мысли (почитайте любой академический или философский журнал, и вы найдете массу подобных примеров). К сожалению, эту манеру легко перенять. Ей свойственно зарождаться в верхушке организации и, просачиваясь вниз, становиться причиной трудно искоренимых уровней скверного стиля общения. В некоторых компаниях иногда сразу и не поймешь, что документ написан на родном языке.
