скачать книгу бесплатно
Для подробного разговора о концептуальном документе необходимо дать определение нескольким терминам. Понятия концепции, общекомандной цели и просто цели часто смешивают. Я же собираюсь их использовать в следующем толковании:
Концепция определяет главные цели, относящиеся к проекту в целом. Может также включать концептуальные положения или сверхзадачу. (Главные цели, определяемые в концептуальном документе, иногда называют задачами, чтобы отличать их от целей более низкого уровня.)
Общекомандные цели. Подраздел концепции, относящийся к сфере ответственности конкретной команды, определяемый несколько глубже, чем общая концепция. (Например, команда А может отвечать за разработку базы данных и достижение связанных с этим целей, а команда Б – за разработку поисковой машины и решение сопутствующих задач, но обе эти команды работают в рамках общей концепции проекта.)
Индивидуальные цели. Подраздел общекомандных целей, являющийся сферой ответственности отдельного работника.
Для небольших проектов разница между общекомандными и индивидуальными целями может быть незначительной (рис. 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 - Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.]
1. Габариты. Устройство должно помещаться в карман рубашки, быть достаточно легким, чтобы не выглядеть громоздким.
2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).
3. Простота. Устройство должно быть в обращении не сложнее бумажного листка, готово к работе сразу после включения и иметь простые элементы управления.
4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.
Удачно сформулированные цели проекта, подобные перечисленным, отличаются простотой и ясностью и описывают порядок вещей, который должен сложиться по завершении работы. Следует помнить, что простота является обратной стороной сложности. Было весьма не просто конструктивно и технологически создать устройство, удовлетворяющее всем обозначенным целям. Представленные ранее примеры удачных концептуальных положений могут оказаться трудновыполнимыми для подобных проектов. В зависимости от того, что именно означают понятия «ведущий», «более простой в использовании» и «самые важные претензии», они могут обернуться немалыми трудностями в реализации проекта.
Обоснование концептуальных положений и целей
Требования, изложенные в концептуальных положениях или в целях проекта, должны быть раскрыты или объяснены в других разделах документа. Значение этих положений для пользовательских нужд, облегчения работы, надежности или учета наиболее распространенных претензий должно быть в достаточной степени разъяснено, чтобы можно было принять вполне обоснованные решения. Если важность данных положений позволяет им стать частью концепции, стало быть, их целесообразно сопроводить конкретными разъяснениями специалистов с такой же степенью детализации и определенности, с которой формулируются технологические цели. Если поставлена цель добиться «простоты использования», но по этому поводу никем не предоставлено никаких разъяснений, команда не будет настроена на достижение этой цели. При выработке концепции руководство должно оценивать потребности в ресурсах для успешной реализации проекта и определять способы заполнения пробелов, имеющихся в ресурсах и мастерстве разработчиков (можно выбрать обучение персонала, поднаем специалистов, корректировку самой концепции или скрещивание пальцев на удачу).
Концепции должны быть наглядными
Указывая пальцем на Луну, не перепутайте палец с Луной.
Дзен-буддистская притча
Концепции, или по-иному, системы взглядов, названы именно так потому, что они предполагают обращение к нашей способности сформировать визуальное представление какого-то конечного результата. Разглядывая какую-нибудь картину, мы одновременно воспринимаем несколько уровней заложенной в ней информации. Многим самым сложным концептуальным положениям и идеям изображения придают наглядность – изображения воспринимаются намного быстрее и понятнее, чем словесные описания. Я десятки раз в своем офисе вел переговоры с программистами или с разработчиками архитектуры компьютерных систем, которые настойчиво пытались докопаться до сути приводимых аргументов, и все заканчивалось лишь тогда, когда кто-нибудь из нас, в конце концов, подходил к доске, воплощал идею в эскизе и спрашивал: «Вы именно это имели в виду?» После чего обычно раздавался взрыв хохота, вызванный осознанием того факта, что мы затратили впустую уйму времени, пытаясь объяснить суть объектной модели или конструктивных особенностей на словах или на пальцах, в то время как сделать это с помощью доски и фломастера было намного проще и быстрее. Думаю, что в американской культуре основной упор делается на развитие навыков устной речи и умение производить математические выкладки, а не на развитие артистических и изобразительных способностей, поэтому многим профессионалам для приобретения соответствующих навыков требуется некоторая практика. Я убежден, что мы многое теряем, забывая об эффективности выражения идей изобразительными средствами.
Все лучшие образцы концептуальных документов включали элементы визуализации в виде набросков, макетов или прототипов конечного вида продукта, получаемого при условии следования предложенной концепции. Все они сопровождались пояснительными материалами и предварительными прикидками, которые позволяли получить достаточное представление о сути идеи и помогали целям, изложенным в концепции, укрепиться в сознании изучающих ее людей. Благодаря этому становилось понятным, что макеты далеки от конечной версии создаваемого продукта. Слишком далеки. Зато они являются ранней попыткой наполнить содержанием идеи, заложенные в концепцию, и являются своеобразным предположением, позволяющим обсуждать саму работу, а не только представление о ней, предложенное концепцией.
Макеты и прототипы зачастую воспринимаются консервативно настроенными инженерами и программистами намного лучше, чем любые диаграммы объектных моделей или примеры кода. В отличие от этих привычных форм абстрактного отображения информации визуальные прототипы показывают нечто пока не существующее, но вполне осуществимое в будущем. Архитекторы небоскребов и конструкторы автомобилей создают множество физических макетов и прототипов, помогающих им осмыслить идеи, над которыми они работают, и получить на них отзывы со стороны. Создатели кинофильмов для тех же целей используют доску с эскизами, изображающими сцены из фильма. В концептуальных документах, претендующих на качественное исполнение, не следует избегать подобных технологий. Демонстрация эскиза конечного вида продукта позволяет каждому осмыслить его вклад в общее дело. После этого входящие в команду разработчики нацеливаются не просто на создание того или иного компонента, у них возникает представление о том, где и в чем этот компонент найдет применение, когда разработка программного продукта будет завершена.
Наглядное представление неочевидных вещей
Если проект не имеет никакого отношения к пользовательскому интерфейсу или к интерактивному общению с пользователями, это еще не означает, что он не может быть наглядно представлен. Следует задаться вопросом, какие изменения произойдут в случае реализации проекта? Возможно, концепция касается устранения некоторых чисто человеческих проблем или неудовлетворенностей (медлительность серверов, склонность баз данных к частым сбоям и т. д.). Все это может быть наглядно показано путем демонстрации (или симуляции) одного и того же веб-сайта до начала и после окончания работ, или прототипа, позволяющего сравнивать последовательность необходимых действий пользователя до и после, выражая тем самым, насколько все может упроститься с применением новой архитектуры или новой структуры базы данных.
Существует множество способов визуализации идей, сколь бы абстрактными или технократическими они ни казались. Если проект позволит пользователям проводить меньше времени за рабочим столом, нарисуйте рядом с этим столом пустой стул. Если проект ускорит работу базы данных, покажите два демонстрационных ролика, отражающих ее работу до и после. Если отказоустойчивость встроенной системной API-функции повысится на 10 %, предоставьте показания тестовой программы, используемой для измерения данного параметра до и после реализации проекта. Как бы это ни было скучно для команды, но ей нужно дать наглядное представление о границах индивидуальной работы.
Если конечный результат работы не может быть наглядно представлен даже в виде эскиза, макета или схемы, я готов утверждать, что концепция вряд ли будет правильно истолкована. Если вы не в состоянии найти какое-нибудь визуальное представление того, что изменится в этом мире под влиянием проекта, стоит призадуматься, не направлен ли этот проект на создание совершенно бесполезных вещей или достаточно ли он понятен, чтобы быть успешно претворенным в жизнь.
Искусство представления вида будущего изделия и визуализации идей, особенно если к этому процессу привлекаются результаты изучения потребительского спроса, является прерогативой проектировщиков. Иногда их называют дизайнерами потребительских товаров, проектировщиками изделий или даже специалистами по художественному конструированию. Искусством визуализации идей и превращению абстрактных замыслов в детали того, что увидят потребители, можно овладеть только на профессиональной основе. Хотя подобный талант присущ некоторым разработчикам и руководителям проектов, немногим из них удается обратить его в истинное мастерство. Если ставятся цели добиться простоты использования продукта и удовлетворения потребительских запросов, то услуги дизайнеров должны быть востребованы на самых ранних стадиях проработки проектов, а привнесение этого аспекта в концепцию должно стать лишь одним из возможных естественных вкладов в проект со стороны этих специалистов. Если эти услуги дизайнеров привлечены на достаточно ранней стадии и руководство обеспечило реальное внедрение приложенных ими усилий в проект, то это приведет не только к чисто внешней привлекательности продукта, но и будет способствовать повышению его потребительских качеств.
Ежедневное поклонение концептуальным положениям
Один из оригинальных экземпляров Конституции США помещен в музейное хранилище в Вашингтоне, округ Колумбия, за толстыми листами из сверхпрочного стекла. Хотя этот экземпляр хранится в безопасном и надежном месте, я уверен, что в таком формате его читали немногие. Когда идеи недоступны или остаются в тени, они постепенно уходят в небытие (если только из-за особой ценности их не делают музейными экспонатами). Даже в краткосрочных проектах легко утратить ту общую для проекта канву, в которую должны вписываться ежедневные решения, и недостаток видения основных идей способствует возникновению этой разновидности энтропии. Люди могут быть загружены до предела и успешно работать над решением частных задач, но без частой сверки курса с общими ориентирами им будет довольно трудно понять, что все они движутся в правильном направлении. Концепция, или сборник основных идей и целей проекта, является частью общего процесса, и поэтому она должна постоянно присутствовать в коридорах и офисах людей, выполняющих свою работу.
Чтобы концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах. Их открытое обсуждение должно вестись на еженедельных или ежемесячных совещаниях после предварительной публичной зачитки. Если командой используется демонстрационный экран или другие вспомогательные средства визуализации, то ключевые моменты должны быть отображены на первом слайде или первой странице. Большинство сотрудников в любое время должны быть в состоянии назвать основные цели проекта, по крайней мере, те из них, к которым они имеют непосредственное отношение или за реализацию которых несут личную ответственность.
Но этих мер явно не достаточно для поддержания концепции в актуальном состоянии. Лишь то, что люди ее запомнили, еще не означает, что они ее используют в своей работе. Сохранение актуальности концепции требует усилий со стороны руководства команды. Оно должно постоянно обращаться к тем самым мотивам, которые и привели к созданию самой концепции.
