Помоги проекту - поделись книгой:
Рис. 3.1. Самый простой, но весьма удобный взгляд на планирование. Если неизвестно, что делать, значит, не настало время определять, как делать
Представленные три действия, выработка требований, проектирование (или выработка технических условий) и реализация, настолько объемны, что каждое из них достойно отдельной книги (см. библиографию). Первые два действия рассматриваются с точки зрения перспективы проектного уровня в нескольких последующих главах, а реализации внимание уделено чуть позже (в главах 14 и 15).
Типы проектов
Сущность процесса выработки требований и проектирования меняется в зависимости от ряда критериев. Для их иллюстрации я воспользуюсь тремя простыми, отличающимися друг от друга примерами проектов.[18]
Супермен-одиночка. В простейшем проекте участвует один человек, который делает все сам, от написания кода, проведения рыночных исследований, планирования выпуска и сбыта программного продукта до приготовления собственного завтрака. При этом он использует собственные источники финансирования.
Небольшая команда, работающая по контракту. Фирма, состоящая из пяти—десяти программистов и одного руководителя, нанятая заказчиком для создания веб-сайта или программы. С ними заключается контракт, оговаривающий взаимные обязательства. По окончании контракта все связи обрываются до заключения следующего контракта или начала следующего проекта.
Многочисленная команда штатных сотрудников. Группа из ста человек, работающая в корпорации по найму и начинающая работу над новой версией какого-нибудь программного продукта. Это может быть продукт, предназначенный для продажи (так называемый коробочный продукт), или что-нибудь для внутрикорпоративного потребления.
Представленные три разновидности проектов отличаются по численности команды, организационной структуре и подчиненности, и эти отличия определяют важные различия в подходах к управлению проектом. Итак, даже если ваш проект в чем-то отличается от этих примеров, они могут использоваться в качестве отправных точек при чтении следующих разделов.
Как на планирование влияет его организация
На примере трех упомянутых типов проектов мы можем рассмотреть основные критерии, применяющиеся при планировании проектов. В проекте всегда есть вопросы, на которые каждый должен знать ответы. Эти ответы не всегда и не всем могут нравиться, но знать их вам и вашей команде все же следует. Большинство неудач в планировании происходят из-за того, что указанные проблемы игнорируются или после их рассмотрения остаются разногласия.
Кто выдвигает требования? Кто-то должен выдвигать требования и выставлять их на утверждение заинтересованных сторон (заказчика или вице-президента). В варианте супермена-одиночки все очень просто: все полномочия принадлежат самому супермену. У команды, работающей по контракту, должен быть заказчик, желающий строго контролировать выработку требований и, по возможности, процесс проектирования. Наконец, многочисленная группа разработчиков может иметь в корпорации комиссию или иную структурную единицу, предназначенную для выполнения этой работы (и утверждающую выдвинутые требования). Она может состоять из разных людей, имеющих право выдвигать требования высокого («Это будет спортивный грузовик») и низкого («Он будет проезжать 20 миль на одном галлоне топлива и иметь привод на четыре колеса») уровней.
Кому поручено проектирование? Аналогично процессу выдвижения требований, кто-то должен осуществлять проектирование самой работы. Проектирование отличается от выдвижения требований, поскольку всегда существует множество возможных проектов, ведущих к удовлетворению конкретного набора требований. Проектирование, как и выдвижение требований, зачастую является договорным процессом между двумя и более заинтересованными сторонами. Один человек или команда может отвечать за ход процесса проектирования и выработку идей (проектировщик), а другой человек (вице-президент) или команда – обеспечивать руководство и оценивать работу первой команды. Учтите, поскольку проектирование – искусство глобальное и от политической власти независимое, люди, которым предоставлено право проектировать, могут не иметь на это особого таланта.
Кому поручена выработка технических условий? Технические полномочия определяются возможностью выбирать используемые технологические подходы, включая языки программирования, средства разработки программ и техническую архитектуру. Многие из этих решений могут влиять на набор требований, проектирование и бюджет. Разница между техническими и проектировочными решениями едва различима: то, как что-то ведет себя и как оно выглядит, часто имеет много общего с тем, как оно сконструировано. В одних организациях технические полномочия совмещаются с полномочиями по выработке требований и проектированию, в других технические полномочия носят подчиненный характер. И все же лучше, если в организации существуют отношения сотрудничества между различными видами полномочий.
Кому поручено составление бюджета? Компетенция выделять на реализацию проекта дополнительные финансовые ресурсы или сокращать их может не зависеть от других видов полномочий. К примеру, в ситуации с командой, работающей по контракту, ей могут быть предоставлены полномочия на выработку требований и проектирование, но при каждой потребности увеличения времени или денег, скорее всего, нужно будет обращаться к заказчику.
Как часто могут пересматриваться требования и проектные решения и как должны приниматься решения о внесении поправок? Ответ во многом зависит от ответов на предыдущие вопросы. Чем больше сторон вовлечено в выработку требований, проектирование и составление бюджета, тем больше усилий понадобится для сохранения баланса интересов в процессе реализации проекта. Есть одно практическое правило: чем меньше у вас полномочий, тем больше настойчивости надо проявлять при пересмотре и утверждении решений и тем больше бойцовских качеств проявлять при их корректировке.
Хотя я разграничил виды полномочий, вполне возможно, что всеми ими или какой-то их частью будет обладать один и тот же человек. Но чаще всего полномочия распределяются между руководителями групп. Чем сложнее система распределения полномочий, тем больше сил должно быть отдано планированию для достижения эффективности. В главе 16 показано, как справиться с ситуацией, когда требуется более высокий уровень полномочий. На данный момент достаточно знать, что в процессе планирования задействованы все перечисленные виды властных полномочий.
Документы, разрабатываемые при обычном планировании
Чтобы иметь возможность доводить требования до заинтересованных сторон, их надо кому-то документировать. Для этого существует множество способов, ни один из которых я особо не выделяю. Главное, чтобы был правильно схвачен смысл требований, чтобы эти требования были доступны для обсуждения всеми заинтересованными сторонами, в результате чего могут быть приняты конкретные обязательства, соответствующие объему выполняемых работ. Если избранный вами способ документального оформления требований может это обеспечить, значит, все в порядке. Если нет, подыщите другой способ, отвечающий данным критериям.
В справочных целях я упомяну некоторые из распространенных способов документального оформления требований и информации, относящейся к планированию. Владея обычной профессиональной фразеологией, совсем нетрудно перенимать различные методы, используемые в разных организациях. Вы можете столкнуться с тем, что некоторые группы документируют требования в свободной форме «а, требования… это вам нужно обратиться к Фрэду». Другие же имеют для этих целей детально проработанные формализованные документы и процедуры их пересмотра, при которых эти документы разбиваются на немыслимо мелкие (возможно, перекрывающиеся) элементы, за которые отвечают разные люди.
Анализ потребностей рынка (Marketing Requirements Document, MRD). Имеется в виду документ, обобщающий анализ мировой конъюнктуры, проведенный маркетинговой или бизнес-группой. Он предназначен для объяснения благоприятных деловых возможностей и того, как ими можно будет воспользоваться в данном проекте. В одних организациях этот документ носит справочный характер, помогающий обдумывать принимаемые решения. В других он является основой формулировки проекта, используемой в качестве производной для всего остального. Анализ потребностей рынка помогает определить, что собой должен представлять проект.
Концепция и рамки проекта. Концептуальный документ, вбирающий в себя всевозможные представления о том, каким должен быть проект. Если используется анализ потребностей рынка, то этот документ должен с ним тесно перекликаться. В концептуальном документе определяются цели проекта, смысл их достижения, а также видение в целом характеристик, требований или сроков реализации проекта (см. главу 4). Этот документ непосредственно определяет для проекта ответ на вопрос «что?», то есть в чем его суть.
Технические условия. В них формулируется конечный результат работ для определенной части проекта. Обоснованные технические условия вырабатываются на основе набора требований. Затем они многократно прорабатываются в процессе проектирования (см. главы 5 и 6), в ходе которого изменениям и уточнениям могут подвергаться и исходные требования. Выработка технических условий завершается, когда они обеспечивают работоспособный план, который в процессе разработки и управления проектом может быть использован для удовлетворения требований (степень их детализации должна быть полностью обговорена с разработчиками и управленцами). Технические условия должны унаследовать как можно больше идей, выдвинутых в концептуальных документах. Они определяют для проекта ответ на вопрос «как?», то есть как его реализовать с конструкторской и технической точек зрения. (Сценарии использования и карточки историй, применяемые в большинстве гибких методов, становятся чем-то вроде технических требований и условий.)
Структурная декомпозиция работ (Work Breakdown Structure, WBS). Технические условия детализируют объем выполняемых работ, а документы структурной декомпозиции работ определяют, как группа разработчиков должна справляться с их выполнением. Что должно быть сделано в первую очередь? Кто этим займется? Что из себя будут представлять все индивидуальные рабочие задания и как можно отслеживать их выполнение? В зависимости от потребностей проекта эти документы могут быть оформлены предельно просто (в виде электронной таблицы) или довольно сложно (в виде диаграмм и средств выполнения). К разработке документов структурной декомпозиции работ относятся главы 7 и 13. Эти документы определяют для проекта ответ на вопрос «как?» с точки зрения группы разработчиков. (В некоторых методах гибкой разработки все задействованные карточки историй показываются на досках заданий, которые становятся чем-то вроде структурной декомпозиции работ.)
Подходы к планированию – три взгляда на проект
Можно было заметить, что каждый из ранее упомянутых документов представляет одну из двух точек зрения на проект, деловую или техническую. Во многих проектах эти две точки зрения соперничают друг с другом. В этом заключается главная ошибка планирования. Оно не должно быть двояким, отвечать одним или другим интересам. Здесь нужен синтез всего, в чем выражаются интересы каждого направления.
Чтобы добиться такого результата, руководитель проекта должен осознать, что каждая точка зрения вносит в проект нечто уникальное, что не может компенсироваться большим количеством чего-нибудь другого (например, какой бы ни была глубина проработки рыночной стратегии, ею не улучшишь технический уровень, и наоборот). Лучшие результаты достигаются в том случае, когда все участники планирования проекта понимают в общих чертах суть каждой точки зрения.
ВНИМАНИЕ
При планировании должны быть также учтены и производственные мощности. Если попадаются вопросы или ситуации, не применимые в данном случае в силу иной численности команды или масштабности проекта, то их можно просто пропустить. Я и не рассчитываю, что все охватываемые здесь вопросы применимы к какому-то конкретному проекту. Тем не менее я предоставляю объем информации, применимый не только к текущему, но и к возможным последующим проектам. Здесь представлено множество вопросов с дальним прицелом, и ничего страшного, если некоторые из них не подходят к тому, над чем вы сегодня работаете.
Взгляд бизнесмена
Деловой взгляд фокусируется на понятиях, влияющих на прибыли и убытки (Profit and Loss, P&L), учитываемые организацией. В эти понятия включаются продажи, прибыль, расходы, конкуренция и издержки. Каждый должен разбираться в своей прибыли и убытках – из прибыли выплачиваются зарплаты или оплачиваются контракты. Когда команда разработчиков не знает, как работает бизнес, многие решения, принимаемые руководством, им кажутся нелогичными или неинтересными. Поэтому в интересах тех, кто отвечает за бизнес-планирование, помочь понять всем другим, почему проект имеет право на существование с деловой точки зрения. В технической сфере деловую точку зрения представляют все, чьи должности именуются бизнес-аналитик, специалист по маркетингу, специалист по развитию бизнеса, планировщик номенклатуры изделий или старший менеджер.
Некоторые проекты имеют несколько деловых точек зрения. Если вы работаете на фирме, заключившей контракт на создание сервера баз данных, вы должны считаться с деловыми интересами фирмы наряду с деловыми интересами заказчика, чей заказ вы выполняете (в надежде, что эти интересы совпадают). Найти пересечение этих интересов может оказаться не простой задачей. Я не хочу здесь ничего усложнять и буду вести речь о проектах, разрабатываемых в организации с большим штатом сотрудников. Тем не менее перечисленные далее вопросы нетрудно экстраполировать и на более сложные ситуации.
Хороший деловой взгляд означает, что у команды есть ответы на следующие вопросы:
• Почему этот проект необходим для нашего бизнеса?
• Какие неудовлетворенные потребности или желания имеются у наших клиентов?
• Какие характеристики или услуги мы можем предложить для удовлетворения этих желаний или потребностей?
• Что сможет побудить клиентов приобрести этот продукт или воспользоваться этими услугами? Что станет причиной такого поступка?
• Во что это обойдется (с точки зрения затрат людских и материальных ресурсов)? Сколько на это уйдет времени?
• Каков уровень возможных доходов (или снижения организационных и производственных затрат)? За какой период времени?
• От производства каких изделий нужно отказаться, чтобы справиться с производством данного продукта?
• Сможет ли проект внести вклад в нашу долгосрочную деловую стратегию или защитить другие доходные активы? (Даже некоммерческие или IT-организации придерживаются бизнес-стратегии: они всегда выставляют счета на оплату, стремятся получить доход или имеют для поддержки своей деятельности команды, работающие на извлечение дохода.)
• Как проект поможет нам идти в ногу с конкурентами, обойти или превзойти их?
• На какие рыночные интервалы времени можно нацелить данный проект?
Специалисты, ответственные за бизнес-интересы, уделяют этим вопросам самое пристальное внимание, полагая, что ответы на них должны лечь в основу деятельности организации и оказать большое влияние на все решения, связанные с проектом. Конечно же, деловой подход не означает, что все проекты должны быть направлены на извлечение выгоды. Проекты могут также оцениваться на основе их вклада в стратегию бизнеса. Например, стратегический проект может быть необходим организации, но не принести никакой прибыли.
Самой несправедливой критике бизнесмены подвергаются в среде «технарей», где их обзывают «торгашами». Я думаю, что маркетинг в данном случае получает удар ниже пояса. В терминологии образовательной программы MBA (Master of Business Administration – магистр делового администрирования) маркетинг можно определить четырьмя «P»: Product (продукция), Price (цена), Placement (распространение продукта) и Promotion (продвижение продукта на рынке). Определение вида продукции и цены – процесс творческий. Его цель состоит в том, чтобы проработать идею продукции, продаваемой с прибылью и отвечающей потребностям определенного покупателя. Чтобы добиться в этом деле успеха, необходимы исследования, анализ и творческая работа. Распространение продукта (третья буква «P») подразумевает способы получения продукта покупателем. (Через веб-сайт? Через супермаркет? Из багажника автомобиля?)
И наконец, продвижение продукта на рынке, что по сложившемуся стереотипу и принимают за маркетинг, – означает распространение положительных отзывов о продукте среди влиятельных людей и потенциальных покупателей. Как ни странно, но продвижение продукта занимает весьма скромную часть рабочего времени бизнес-аналитика или менеджера по продажам (возможно, 10–20 %). Получается, что маркетинговые планы определяются куда больше вопросов, чем внешний вид рекламы или приемы продвижения товара на рынке, которые будут предприняты. К тому же следует заметить, что четыре «P» маркетинга применимы практически ко всему. Всегда есть продукт (защищенный веб-сайт), цена (бесплатный), размещение (интранет) и продвижение (сообщения по электронной почте).
Но когда деловые перспективы рассматриваются однобоко, проявляется только треть потребностей. На объем продаж влияет качество продукции, но оно не зависит от маркетинга. Качество[19] является производной удачного проектирования и разработки продукта, удовлетворяющего реальные потребности покупателя. Для успешного ведения бизнеса должен быть предложен бизнес-план, сконцентрированный на технологических возможностях (а не на догадках).
Руководитель проекта, имеющий однобокий взгляд на бизнес и терпящий из-за этого неудачу, может так никогда и не понять, что именно пошло не так, как надо. В результате он будет стремиться работать еще интенсивнее, вместо того чтобы попытаться расширить свой кругозор.
Взгляд разработчика
Когда я изучал компьютерную науку в университете Карнеги Меллон, разговоры о новых программных продуктах со студентами и профессорами были обычным делом. Мы всегда концентрировали свое внимание на компонентах, использовавшихся в новых программных продуктах, сравнивая их с теми, которые могли бы в них использоваться. Особой ценностью безоговорочно считалось качество разработки: сколько технологических новинок в них использовалось. Вообще-то мы думали, что кругом царит сплошное надувательство. Нашу критику выдерживали далеко не все продукты. Мы удивлялись, почему рынок завален посредственной продукцией. Для объяснения вредных решений, которые, как мы думали, принимались вразрез с понятиями технического совершенства и вопреки здравому смыслу, мы даже изобрели теорию тайного заговора. Зачастую мы во всем обвиняли отделы маркетинга[20] (совсем немногие из нас понимали, чем на самом деле занимаются специалисты по маркетингу). Даже в мои первые годы на производстве разговоры на эту тему велись практически постоянно. Только тогда мы еще больше ко всему присматривались, поскольку конкурировали со многими программными продуктами или веб-сайтами, о которых шли разговоры.
Наш взгляд на окружающий мир был технократическим, мы замечали лишь технические достоинства. Мы никак не могли понять, почему слабые в техническом отношении продукты иногда очень хорошо продавались, а технически совершенные продукты вовсе не пользовались успехом. Мы также замечали, что качеству разработки не всегда соответствует положительная реакция покупателя. На эти странности у нас было два ответа. Первый состоял в том, что всему причиной колдовство вредителей от маркетинга, а второй – в том, что нам не хватает умных покупателей. Однако мы особо не развивали наши умозаключения и возвращались к созданию программного кода или к розыску чужих программных продуктов, чтобы не оставить от них камня на камне. Я получил возможность произвести переоценку своих взглядов только после того, как прислушался к некоторым толковым специалистам по маркетингу и талантливым разработчикам программных продуктов.
Во взгляде разработчика на проект основное внимание уделяется тому, как все должно быть создано с точки зрения конструкции и материалов. Вся эстетика в данном вопросе строится исходя из технологических, а не потребительских ценностей. Уклон делается на то, как все будет создаваться, а не на понимание, как созданные вещи окажут пользу развитию бизнеса или потребителю. В стереотипном техническом представлении достаточно создать базу данных, отвечающую эстетическим представлениям разработчика, даже если ни один из покупателей не сможет понять, что с ней делать, или она не будет отвечать коммерческим планам.
Не менее важными, чем вопросы о разработчиках, затронутые в этом последнем абзаце, являются вопросы, основанные исключительно на технологическом взгляде на проект:
• Что именно в соответствии с ним (проектом) требуется сделать?
• Как это будет работать? Как будет работать каждый компонент?
• Как это будет создаваться? Как мы будем проверять, что это работает в соответствии с нашими предположениями?
• Насколько надежны, эффективны, расширяемы и производительны существующие и нами создаваемые системы? Существуют ли пробелы между всем этим и требованиями проекта?
• Какие технологии или архитектуры на данный момент нам полностью доступны? Будем ли мы делать ставку на какую-нибудь новую технологию, которая еще недоступна, но будет вскоре готова к использованию?
• Какие технологические процессы и подходы соответствуют данной команде и данному проекту?
• Какими знаниями и деловым опытом обладают наши специалисты? Работу над чем они приостановят, чтобы заняться данным проектом?
• Чем мы восполним недостаток делового опыта? (Методом проб и ошибок, наймом на работу других специалистов, обучением своих специалистов? Или проигнорируем эти пробелы в надежде, что они волшебным образом исчезнут сами по себе?)
• Сколько времени займет создание продукта и каков при этом будет его уровень качества?
Взгляд потребителя
Взгляд потребителя – пожалуй, самый важный из всех трех взглядов на проект. Поскольку сам проект реализуется в расчете на потребителя (и, наверное, в расчете на успешный бизнес, но только при условии удовлетворения запросов потребителя), следовательно, надо приложить все силы на то, чтобы осознать, кем же является этот самый потребитель. Сюда включается изучение того, чем потребители заняты в течение дня, как они это все делают в настоящее время, какие изменения или улучшения смогли бы оказать им ценную помощь в том, чем они заняты. Без этой информации техника и бизнес выстрелят впустую.
К сожалению, взгляд на проект с точки зрения потребителя является наиболее слабым звеном в работе многих организаций. Обычно на данную оценку проекта сил и средств выделяется меньше всего. В большинстве организаций сотрудников, специализирующихся на изучении потребительских интересов и проектировании изделий с их учетом, намного меньше, чем их коллег по бизнесу и технологиям. Даже если подобные специалисты и принимаются на работу (проектировщики пользовательского интерфейса или инженеры по потребительским свойствам изделий), им в процессе принятия проектных решений зачастую отводятся ограниченные роли и предоставляется возможность выдвижения лишь незначительных требований, а также выделяются весьма скромные полномочия при проектировании.
В любом случае источников, по которым оценивают потребительские интересы, два – это опросы и исследования. Результатами опросов являются конкретные просьбы и жалобы потребителей. Этот вид информации ценен тем, что потребитель кровно заинтересован в выявлении проблемы («Да, мой компьютер взрывается, стоит мне только нажать пробел»), но он и проблематичен сам по себе, поскольку во многих случаях потребители не имеют конструкторского взгляда на вещи. Они зачастую не видят разницы между проблемами, которые нужно решать, и конкретными способами их решения. Они могут явно требовать реализацию какой-нибудь характеристики, вроде предварительного просмотра вывода на печать, не описав суть проблемы (слишком много бумаги выбрасывается впустую). Если команда проектировщиков начинает работу с изучения проблемы, то может быть найдено множество путей ее решения, которые окажутся дешевле или лучше, чем просто реализация востребованной характеристики. Даже квалифицированные проектировщики часто отстаивают при проектировании собственные интересы.[21]
Существует два типа экспертов, разбирающихся в потребительском взгляде на вещи и в проектировании в интересах потребителей: инженеры по потребительским свойствам изделий и проектировщики изделий. Инженеры по потребительским свойствам изделий разбираются в том, как люди работают, и предоставляют свои выкладки и результаты исследований в распоряжение команды проектировщиков, помогая тем самым принимать взвешенные решения с первого же дня планирования. Проектировщики изделий или проектировщики взаимодействия с продуктом являются людьми, знающими, как воспользоваться этими данными и преобразовать их в качественное проектирование веб-сайтов или программных продуктов. Если вашей организации повезло иметь в своем штате таких великолепных специалистов, привлеките их к процессу планирования как можно раньше. Попросите их отстаивать свою точку зрения. Если вы работаете без их участия, ваши конкуренты получат явное преимущество. Подумайте над тем, чтобы нанять кого-нибудь, кто мог бы вас проконсультировать и дать совет, где его усилия могут использоваться с наибольшей отдачей.
Не получая помощи экспертов, руководитель проекта должен уметь обойтись собственными силами. Такой вариант, конечно, возможен, но поскольку потребительский взгляд зачастую не интересен специалистам с технократическим уклоном и малопонятен высшему руководству, он, в отличие от других точек зрения, пользуется существенно меньшей поддержкой. Для сбалансированности со взглядами разработчика и бизнесмена взгляд потребителя должен иметь приоритет, а на его изучение и учет должно быть выделено достаточно ресурсов. В противном случае не удивляйтесь, если его вообще не примут во внимание или данные о нем не будут отличаться достоверностью.
Потребительский взгляд на проект подразумевает ответы на следующие важные вопросы:
• Чем обычно заняты люди? (Не наши домыслы и не то, что они об этом рассказывают.)
• Какие проблемы они испытывают, стараясь заниматься своим делом? Что их ставит в тупик, смущает или расстраивает?
• Что им нужно или хотелось бы делать, но не представляется возможным?
• Есть ли конкретные возможности сделать продукт проще, безопаснее, быстрее или надежнее для потребителей?
• Какие конструкторские идеи по улучшению потребительских свойств продукта, с точки зрения обычных людских занятий, имеют наибольшие перспективы произвести впечатление на потребителя?
• Как можно исследовать подобные идеи? Какие прототипы прикидки или варианты нуждаются в исследовании, чтобы помочь нам осмыслить потенциал проекта?
• Какие основные идеи и концепции должны быть представлены в проекте, чтобы донести информацию до пользователей?
Магия единой точки зрения
Все три взгляда на проект всегда имеют некоторые совпадения. На каждое деловое соображение оказывают влияние технические и потребительские стороны (данная фраза сохраняет смысл при любых перестановках). Поэтому, чтобы лучше справиться с планированием, нужно каждый из взглядов рассматривать на равных основаниях, чтобы видеть все их совпадения и различия. Некоторые решения придется принимать, отдавая предпочтение одним взглядам в ущерб другим, но эти решения не должны приниматься случайным образом. Нужно придерживаться разумной стратегии извлечения наибольшей выгоды из каждого взгляда на проект.
Затратив время на исследование всех трех взглядов на проект, мы получим возможность принимать разумные стратегические решения. В результате мы сможем решить некоторые наиболее острые проблемы или достичь цели, преследуемые каждым из трех взглядов, определив общую направленность проекта на области их совпадений. Эти области имеют для организации самое существенное потенциальное значение, поскольку одним усилием можно одновременно учесть интересы бизнесмена, разработчика и потребителя.
Использование диаграммы Венна (подобной той, что изображена на рис. 3.2), которая помогает выправить нездоровый уклон во взглядах, допускаемый инженерами и специалистами по маркетингу, имеет почти такое же по важности значение, как и стратегическое планирование. Она помогает команде увидеть не только те места, где соперничают различные точки зрения, но и те, где они совпадают. На ранней стадии, чаще всего при дискуссиях, ведущихся в процессе планирования проекта, эта диаграмма или что-либо ей подобное (например, диаграмма, включающая перечень потенциальных задач, относящихся к каждому из взглядов на проект) может быть использована для сдерживания в рамках дозволенного предложений, выдвигаемых приверженцами того или иного взгляда на проект. Предлагаемые идеи должны быть спроецированы на эту диаграмму, чтобы стало понятно, в какой степени они отвечают интересам всех трех взглядов. Руководитель проекта играет ключевую роль в проведении такой политики, эффективно используя свои качества универсального специалиста для сведения всех трех взглядов в один.
Рис. 3.2. Три взгляда на проект
В частности, этого можно достичь, если с самого начала дать понять, что всегда будут появляться грандиозные технологические идеи, не отвечающие интересам ни бизнеса, ни потребителей, наряду с великолепными идеями в интересах потребителей, безжизненными с точки зрения бизнеса или не имеющими шансов на воплощение средствами используемой технологии. Тогда каждый получит право обличить однобокие идеи и указать на них всем остальным. К тому же это вызовет взаимоуважение различных взглядов, поскольку все будут вынуждены осознать, что в целях достижения успеха необходимо сотрудничать с людьми, компетентными в своих областях.
Но если к сближению точек зрения не прикладывать никаких усилий, то возникающие конфликты вряд ли будут способствовать поддержанию правильного курса. Тогда совещания по планированию проекта превратятся в поле битвы для критики и защиты мнений, базирующихся на трех разных взглядах (а не на истинных достоинствах идей как таковых). Нередко, когда мне приходилось консультировать команды проектировщиков, меня просили помочь в разрешении проблемы, не имевшей ничего общего с их профессиональными способностями. Имел место неразрешимый или даже невыраженный конфликт мнений о том, к примеру, какой из отделов, разработки или маркетинга, важнее другого. Подобная уверенность в своей исключительности была не только источником проблемы, но и не давала возможности найти причину ее возникновения.
В прежние годы я и сам порой оказывался втянутым в эти бессмысленные войны. Я был руководителем проекта создания поисковых функций в Internet Explorer 4.0. К нам были назначены два специалиста по развитию бизнеса, которые вели переговоры об использовании основных поисковых машин того времени (Excite, Yahoo! Lycos, AltaVista и т. д.). Мы вели споры с этими экспертами по бизнесу вокруг конструкторских решений, постоянно дебатируя о том, что важнее, интересы клиента или бизнеса. Каждый из нас верил в свою правоту (я выступал за коллектив проектировщиков и разработчиков, а они отстаивали точку зрения бизнесменов). Мы неделями спорили об одном и том же, всегда касаясь конкретных решений и никогда не отступая назад, что позволило бы разглядеть нашу общую скрытую философию, направленную на выпуск качественной продукции. Дела приобрели настолько плохой оборот, что для достижения компромисса пришлось привлечь нашего общего руководителя.
Я убежден, что более широкий взгляд на окружающий мир поможет каждому участнику процесса. Мы все были настолько эгоистичны и самоуверенны, что не жалели тратить время на битву по мелочам, вместо того чтобы попытаться учесть все точки зрения на то, что мы, собственно, создавали. Нам мог бы помочь более образный концептуальный документ, но в ту пору (примерно в 1997 году) это было невозможно, поскольку задачи бизнеса в Интернете были слишком новыми для производства. Тем не менее, не затевай мы тогда войну, а поделись знаниями друг с другом, возможно, нам удалось бы достичь успеха в поисках взаимовыгодного компромисса.
Внедрение в проект обобщенного взгляда позволит вам перечеркивать те самые границы, которые сдерживают возможности ваших конкурентов. Вы также сможете вооружиться весомыми аргументами по каждому избранному решению. Вместо пустых утверждений о том, что определенную конструкцию будет легче воплотить в жизнь, вы сможете объяснить, каким образом, с точки зрения маркетинга, будет больше возможностей ее продать (если, конечно, вы все это не выдумаете). Порой такой подход может потребовать чем-то пожертвовать. При поиске лучших решений их не всегда удается увязать с тем, в чем вы сильны, или с теми идеями, которым лично вы отдаете предпочтение. Но если вы будете способны на такие жертвы, то своей убежденностью и искренностью сможете побудить коллег к таким же действиям. Тогда можно будет призвать других специалистов к одобрению своих идей на том основании, что они отвечают интересам проекта. Люди не станут затевать дискуссий по поводу решений, с которыми они не вполне согласны, если поймут, что решения принимаются в условиях объективности и в интересах проекта.
Баланс сил
При работе в крупной организации следует учитывать распределение сил по всем точкам зрения. Например, если инженеры превосходят по численности бизнес-аналитиков в соотношении три к одному, в принимаемых решениях будет уклон на доминирование технологического взгляда. Соотношение сил – это простое соотношение количества приверженцев того или иного взгляда. Для баланса взглядов соотношение должно быть 1:1:1 (с позиций разработчика, бизнесмена и потребителя). Чем больше несбалансированность, тем больше усилий требуется от руководителей, чтобы ее скомпенсировать.
Разумеется, примерное количество людей не определяет объем имеющихся у них полномочий. В армии Наполеона были тысячи солдат, но Наполеон был только один. В команде может быть 10 программистов и 1 специалист по маркетингу (10:1:0), но последний может иметь больше полномочий в рамках проекта, определяющих его роль или старшинство. Это означает, что руководитель в состоянии компенсировать натуральное соотношение, наделяя полномочиями тех, кто должен иметь больше влияние на проект. А поскольку сущность проекта со временем меняется, представители различных взглядов должны в разное время получать различный уровень полномочий. О том, как можно поручать принятие решений для достижения нужного баланса в нужное время, рассказывается в главе 12.
Постановка правильных вопросов
Уточнение набора вопросов, на которые необходимо ответить при планировании – простейший вариант организации работы. Вопросы должны быть извлечены из перечней, составленных на основе трех взглядов на проект, с намерением собрать их в единый план.
Эти вопросы (часто называемые вопросами планирования проекта) должны быть извлечены из трех ранее рассмотренных перечней. Если проект новый (а не разработка очередной версии продукта), то для определения его основных положений понадобятся исходные вопросы. Если суть проекта заключается в незначительном обновлении существующей системы, то вопросов о бизнесе и потребительских интересах может быть совсем немного. Но независимо от характера проекта нужно просмотреть все вопросы. Тогда на поверхность всплывут не выявленные ранее предположения и дадут всем равноценные исходные точки для обсуждения.
Перечень вопросов планирования проекта не должен иметь разграничения по основным взглядам на проект. Лучше иметь целостный взгляд на проект, который при необходимости можно разделить на соображения, соответствующие позициям разработчика, бизнесмена или потребителя. Рассмотрим, например, следующий перечень, состоящий из более сложных версий ранее представленных вопросов:
• Почему появился этот проект? Почему именно мы подходим для его осуществления? Почему его следует реализовать именно сейчас?
• Что собой представляют три или четыре категории людей, которых можно рассматривать в качестве различных типов потребителей? (Например, для текстового процессора это могут быть студенты, профессионалы и обыкновенные пользователи, для информационной базы данных – продавцы, секретари и руководители.) Как отличаются их потребности и привычки?
• Какая демографическая информация может помочь разобраться в типаже потребителей? (Возраст, заработок, вид компании, профессия, образование, пользование другими программными продуктами или веб-сайтами и т. д.)
Поделиться книгой: