Искусство управления IT-проектами Беркун Скотт
Календарный план – это оценка вероятности
Когда я выпустился из университета и работал над своими первыми крупными проектами (Windows и Internet Explorer), то общий календарный план моей команде должен был представлять кто-то поважнее меня. Поскольку я был слишком молод, чтобы в достаточной степени быть причастным к процессу, в мои обязанности после получения календарного плана входило применение этого главного расписания к деятельности небольшого коллектива программистов и тестировщиков, с которыми я работал.
Когда мы обсуждали, в чем состоит разница между этим главным планом и календарным планом, созданным моей командой на основе списка работ,[12] главный план казался нам высосанным из пальца. Он был спущен сверху, аккуратно отформатирован, разбит на красивые столбцы из дат и чисел, но при этом казался чем-то искусственным, украденным из будущего.
При всей своей циничности, мы в основном точно придерживались этих календарных планов. Несмотря на тайну их происхождения, у нас было достаточно оснований доверять своим начальникам, и мы были настолько загружены собственной работой, что особо не переживали за то, что делали они. (В действительности они довольно часто предоставляли элементарные разъяснения для этих первичных спускаемых вниз календарных планов, но мы были настолько заняты и настолько им доверяли, что особого внимания на эти разъяснения не обращали.)
Позже, когда планирование стало частью моих обязанностей, я понял, в чем состоит невысказанная правда об этих планах. Они не были подарком из будущего. Для составления совершенных календарных планов не существует ни магических формул, ни особой науки. Вопреки моему юношескому восприятию, планирование не было изолированной задачей: оно всегда представляло и охватывало множество различных аспектов настоящего и будущего проекта. Планы являются простой формой предсказания. И неважно, насколько пунктуально они составлены или насколько убедительно выглядят – по сути, это всего лишь сборник множества мелких расчетов, каждый из которых невозможно избавить от различных непредвиденных упущений и неточностей. Хорошие планы получаются только у тех руководителей или команд, которые неуклонно ищут и достигают разумных оценок различных аспектов разработки программных продуктов. Нельзя быть узким специалистом и ожидать при этом, что когда-либо вам удастся создать хороший календарный план.
Итак, если все в команде согласны, что календарный план – это набор возможных значений, значит, проблема не в самом плане, а в том, как он используется. Если когда-либо календарный план доводится на совещании команды или рассылается по электронной почте, возникает резонный вопрос: какова вероятность соблюдения приведенного в нем графика работ? Если вероятностные оценки не предлагаются (например, что существуют пять наиболее вероятных рисков и предполагается такая-то вероятность их возникновения) и кто-либо из создателей плана не может предложить каких-либо объяснений относительно сделанных допущений, то остается предположить, что выполнение календарного плана возможно, но маловероятно[13] План должен быть открытым для высказываемых командой предложений, чтобы предлагаемые соображения или информация могли дополнить или скорректировать план в целях повышения вероятности его выполнения.
Весь секрет кроется в том, что календарный план не должен быть совершенным (что, конечно же, радует, поскольку совершенных планов вообще не существует). Планы должны быть приемлемыми для команды и руководства, предоставлять возможность для контроля и внесения корректив, а также иметь вероятность успешного выполнения, удовлетворяющего заказчика, бизнес-интересы или общего спонсора проекта.
Расчет – дело тонкое
В процессе проектирования (обсуждаемого в главах 5 и 6) одной из задач проектировщиков, программистов и тестировщиков является разбиение проекта на небольшие части работы, которая имеет некие завершенные формы. Эти части, часто называемые элементами структурной декомпозиции работ (Work Breakdown Structure, WBS[14]), или просто работами, становятся строками в главном календарном плане проекта. Работы разумно (скрестите пальцы) распределяются[15] среди программистов команды и в соответствии с ними строится календарный план. Каждая из этих работ должна иметь предполагаемый срок завершения, назначенный программистом, и на основе этих предположений создается календарный план.
По самому простому определению качественные оценки работ имеют высокую вероятность оправдаться, у поверхностных оценок такая вероятность крайне низка. Я не ожидаю наград за подобное определение, но в нем имеется, по крайней мере, одно рациональное зерно: определять планку каждого проекта – прерогатива его руководителей. Этот процесс требует активного пересмотра оценок, а также нажима на подчиненных, руководства ими и принуждения их к работе с целью добиться соответствующей отдачи. Я думаю, что вполне разумно широко привлекать к расчетам команду тестировщиков и контролеров качества продукции, позволяя им участвовать в обсуждении проекта, задавать вопросы или отпускать комментарии. Как минимум, это поможет им в собственных оценках работ по тестированию, которые могут никак не соотноситься с расчетами на работы программистов. Зачастую тестировщики обладают лучшим видением недостатков проекта и потенциальных причин сбоев, которые другими специалистами могут быть упущены.
Трудности планирования заключаются в том, что далеко не всем нравится вести сложные расчеты, за которые потом придется отвечать. Всегда хочется прихвастнуть и козырнуть мастерством («эта книга, фильм или веб-сайт никуда не годится, я бы смог все сделать намного лучше»), но стоит только заставить нас подойти и поставить подпись рядом со своим именем в контракте, в котором детализируется возлагаемая на нас ответственность, взгляд на вещи резко изменяется. Мы знаем, насколько вероятна ситуация, при которой сегодняшние обещания, когда придет время заняться делом, завтра могут обернуться полной несостоятельностью. Может статься, что все окажется намного сложнее, чем мы думали. Программисты – такие же люди, как все, и имеют серьезные основания побаиваться расчетов. Говоря о том, что смогут справиться с задачей в определенные сроки, они рискуют сильно ошибиться.
По моему опыту, даже если программист разбирается в расчетах и верит в их состоятельность, он все равно берется за них с неохотой. Частично это вызвано несоответствием воображения («при столь скудной информации я не могу представить, как это все должно работать») с требованием точно рассчитать время («скажите мне точно, сколько часов вам понадобится на разработку»). Но не стоит проявлять излишнее сочувствие: подобные сложности возникают у всех, кто занимается разработкой и строительством, строят ли они небоскреб, занимаются перепланировкой кухни или запускают космический зонд для посадки на другие планеты. Я много читал о том, как эти ребята проводят расчеты, и мне вовсе не показалось, что их сомнения и применяемые технологии в корне отличаются от тех, с которыми приходится сталкиваться разработчикам веб-сайтов и программ. Основное отличие состоит во времени, отводимом ими на расчеты, и в рациональности его использования (более детально этот вопрос рассматривается в главах 5 и 6).
Качественное проектирование – залог хороших расчетов
К чести программистов, самое важное, что я усвоил в отношении качественных расчетов, это то, что они возможны лишь при качественном проектировании и четкой выработке технических требований. Хорошие инженерные расчеты возможны лишь при наличии двух вещей: достоверной информации и хороших специалистов. Если технические требования не выдерживают критики, а программистов просят вообразить что-то конкретное из малопонятных каракулей, нарисованных мелом на доске, все должны четко понять, что в результате будут получены крайне приблизительные и малопонятные расчеты. Из этого следует, что качественные расчеты – дело всех и каждого, коллективные усилия всей команды, всех руководителей и проектировщиков, направленные на то, чтобы сделать все возможное в помощь специалистам при производстве расчетов. Если расчеты воспринимаются рутинной работой или если руководители команд игнорируют процесс, не стоит ожидать надежных или правдоподобных расчетов.
Если руководители считают слабость расчетов календарного плана допустимой и рост рисков их устраивает, значит, им вполне подойдут и весьма поверхностные расчеты. В небольших и краткосрочных проектах примерные расчеты – именно то, что нужно. Требования могут часто меняться, а характер бизнеса может потребовать большей гибкости. В этом случае весьма приблизительные расчеты вполне допустимы, если только их не путать с высококачественными.
Я выработал очень удобный прием на случай, когда программист задерживается с расчетами. Я его спрашиваю: «О чем нужно спросить, чтобы придать вам уверенности в расчетах?» Заставив его сосредоточиться, я даю возможность побороть те чувства страха и неуверенности, которые могли им овладеть. Конечно, я должен был бы помочь найти ответы на его вопросы и, возможно, обсудить проблемы, которые, как я считал, он должен был решить самостоятельно, но, по крайней мере, мы поговорим о повышении качества расчетов.
Вот несколько дополнительных советов, позволяющих добиться качественных расчетов:
Установите базовые показатели доверия расчетам. Предположение – 40 % доверия, качественный расчет – 70 %, подробный и полный анализ – 90 %. Руководители команд должны прийти к соглашению, насколько точными должны быть расчеты, сколько времени отвести программистам для их проведения и как управлять риском неверных расчетов. Не заостряйте внимание на цифрах: пользуйтесь ими лишь для конкретизации качества расчетов. Расчет с 90-процентным доверием должен означать, что сроки выдерживаются в 9 случаях из 10. Если вы решите обратиться к команде с просьбой поднять качество расчетов, то должны подкрепить свою просьбу выделением дополнительного времени.
Ведущие программисты должны установить планку качества расчетов за счет постановки квалифицированных вопросов и применения разумных подходов, которые должна перенять вся команда. Сделайте все возможное, чтобы исключить любые предлоги для ехидных замечаний и торможения процесса (например, «не настаивайте на этом», «это всего лишь предположение» и т. д.). Определите разумные потребности для получения качественных расчетов и удовлетворите их наряду с предоставлением достаточного времени на достижение качественных показателей.
Программистам нужно доверять. Если нейрохирург скажет, что на вашу операцию ему понадобится пять часов, станете ли вы давить на него, требуя сделать ее за три часа? Я сильно в этом сомневаюсь. Иногда давление должно применяться, чтобы заставить людей проявить честность, но только как мера весьма сбалансированная (обычно необходимость в этом возникает по отношению к программистам, завышающим расчеты на нелюбимые работы и занижающим их на любимые). При случае, получение нескольких оценок (от двух разных разработчиков) может стать одним из способов проверки.
Расчеты зависят от понимания программистами целей проекта. Расчеты основываются на программистской интерпретации не только проектировочных спецификаций (если таковые имеются), но также целей и параметров, заложенных в проект. Джеральд Вейнберг (Gerald Weinberg) в книге «The Psychology of Computer Programming» (Dorset House, 1971) отмечал прямое влияние недостаточно четко поставленных целей высокого уровня на низкоуровневые предположения, допускаемые программистами. Какой бы понятной ни была бы технологическая проблема, подходы программистов к ее решению могут в корне меняться в зависимости от общего замысла всего проекта.
Расчеты должны основываться на опыте предыдущих работ. Хорошо, если в привычку программистов войдет сохранение преемственности расчетов от проекта к проекту. Эта тема должна стать частью их дискуссии с руководителем проекта; в интересах руководителя выяснить, кто из команды преуспел в тех или иных расчетах. В экстремальном программировании в отношении возможной производительности программиста (или команды), основанной на предыдущих показателях производительности, используется понятие скорость.[16]
Качество технических условий или проектирования должно быть доведено до уровня, приемлемого для проведения качественных расчетов. Качество выработки технических условий должно стать темой для обсуждения между руководителем проекта и программистами. Чем выше требуемое качество расчетов, тем выше должно быть качество выработки технических условий. Более подробный разговор о качестве выработки технических условий будет вестись в главе 7.
Существуют известные методы улучшения качества расчетов. Наиболее известным является метод PERT (Program Evaluation and Review Technique – метод оценки и пересмотра планов), в котором предпринимается попытка минимизировать риски путем вычисления усредненной величины из результатов лучшего, среднего и худшего расчетов.[17] Этот метод хорош по двум причинам. Во-первых, всем дается понять, что расчеты сродни прогнозам, отражающим диапазон возможных результатов. Во-вторых, руководителям проектов дается возможность отрегулировать агрессивность или консервативность календарных планов (больший вес может придаваться низким или высоким оценкам).
Элементарные просчеты
Хотя качественные расчеты оказывают большое влияние на улучшение календарных планов, множество факторов, влияющих на эти планы, буквально перечеркивают их отдельные элементы. Беда в том, что независимо от качества всех расчетов для отдельных работ, реальные риски срыва календарного плана на бумагу не попадают. Хотя шансы подвергнуться эпидемии в большинстве стран мира крайне незначительны, вероятность подхватить грипп или уйти в вынужденный отпуск ведущему инженеру довольно высока. Существует общий перечень подобных элементарных просчетов календарного плана, о которых должны знать все руководители проектов. Жаль только, что желание их остерегаться возникает только после того, как придется обжечься на одном из них. Поэтому руководителям проектов и особенно руководителям плановых отделов для становления нужен опыт работы. Существует множество различных путей развития неблагоприятных ситуаций, но опыт их предвидения приобретается только в том случае, если руководитель несет ответственность за их последствия.
Я могу предложить вам свой любимый список вопросов, которые помогали мне замечать на ранних стадиях развития потенциальные проблемы составления календарных планов. Большинство из них родилось из вопросов о том, какие были допущены просчеты, заданных по окончании проекта, и из попыток отыскать вопросы, заданные кем-то на ранней стадии, позволившие избежать ту или иную проблему. (Что было упущено? Что не было принято во внимание? Как внести изменения? Что нужно сделать для исправления ситуации?)
• Существует ли в календарном плане отдельная форма учета дней болезни и отпусков всех сотрудников?
• Были ли учтены периоды праздников или другие времена года с большими нерабочими периодами (например, от Дня благодарения до Рождества в США или летние отпуска в Европе)? В эти периоды добиться соблюдения намеченных сроков крайне трудно.
• Допущены ли сотрудники к календарному плану и вменялось ли им (в мягкой форме) в обязанность регулярно отчитываться за проделанную работу?
• Проводит ли кто-нибудь ежедневный или еженедельный анализ выполнения календарного плана в целом? Обладает ли этот человек достаточными полномочиями, чтобы задавать резонные вопросы и вносить поправки?
• Чувствует ли команда причастность к календарному плану и ответственность за его выполнение? Если нет, то почему? Внесла ли команда свой вклад в составление календарного плана и в определение объема работ или все это было спущено им сверху?
• Чего больше было в действиях руководства командой, добавления требований по характеристикам продукта или помощи в их исключении? Говорили ли когда-нибудь руководители команды решительное нет новым объемам работ и предоставляли ли они своей команде разумную философию реагирования на новые (запоздавшие) требования?
• Находили ли сотрудники поощрение и поддержку, если говорили нет новым требованиям, если те шли вразрез с их целями и представлениями?
• Какая вероятность была заложена в расчеты? 90 %? 70 %? 50 %? Нашла ли она отражение в главном календарном плане высокого уровня? Был ли клиент, вице-президент или заказчик уведомлен об этом? Обсуждалось ли другое предложение, более затратное по времени, но имеющее более высокую вероятность соблюдения сроков?
• Имели ли место периодические согласования и пересмотры календарного плана со стороны руководителей команд и руководителей проекта?
• Учтено ли в календарном плане сокращенное рабочее время в период праздников. (Обычно череда праздников снижает продуктивность работы.) Учтены ли в плане наиболее вероятные разрушительные погодные явления (например, снежные заносы в Чикаго, торнадо в Канзасе или жара в Сиетле)?
• Был ли достаточно качественным уровень разработки технических требований и проектирования для получения качественных расчетов времени, отводимого на работы?
• Была ли у расчетчиков достаточная практика или опыт в производстве расчетов времени, отводимого на работы?
Эффект снежного кома
Даже при правильной реакции на большинство вопросов предыдущего списка вы, к великому сожалению, не гарантированы от провала, поскольку слишком велика степень взаимозависимости всех усилий, прикладываемых к составлению календарного плана. Все принимаемые командой решения, от выбора замысла до оценок, являются основой многих будущих решений. Чем позднее обнаруживается просчет, допущенный на начальной стадии проекта, тем выше степень его влияния на реализацию проекта. Сложность процесса реализации календарных планов легко недооценить, поскольку причинно-следственная связь зачастую не просматривается (последствия становятся заметными только в случае проявления их причин). В худших вариантах, при обнаружении нескольких крупных упущений, шансы на то, что план не рассыплется, стремятся к нулю (рис. 2.4).
На самом деле все еще хуже. Вероятность наступления ряда независимых событий равна произведению вероятностей наступления каждого отдельного события (так называемая совместная вероятность). Отсюда следует, что если вероятность прочтения вами этой главы до конца равняется девяти шансам из десяти (9/10), а вероятность того, что вы осилите и следующую главу, также равна 9/10, то суммарная вероятность, что вы дочитаете до конца обе главы, равняется уже не 9/10, а 81/100. Это означает, что если у вашей команды 90-процентная вероятность точного следования еженедельному графику работ, с течением времени шансы срыва сроков возрастают. Вероятность – вещь холодная и беспощадная, напоминающая нам, что энтропия существует повсеместно и не благосклонна ни к проектам, ни к их руководителям.
Рис. 2.4. Эффект снежного кома
Что должно произойти, чтобы календарные планы заработали
Теперь, когда стало понятно, почему так трудно придерживаться календарных планов, я хочу дать совет, как снизить риски и увеличить полезную отдачу от любого календарного плана. Предлагаемые подходы и поступки идут вразрез с традиционными устоями или привычками, в чем, я думаю, и кроется реальная природа планирования. Поскольку календарный план охватывает весь проект, единственный способ его эффективного использования состоит в том, чтобы приобрести какие-то понятия о природе всего, что требуется для успешной реализации проекта. Это многоплановая задача, относящаяся не только к разработке и управлению.
Выбирайте продолжительность этапов в соответствии со степенью изменчивости проекта. Чем больше ожидаемых изменений, тем короче должны быть этапы. Небольшие этапы настраивают команду на менее болезненные поправки в ходе реализации проекта. Управленцы получают более короткие контролируемые интервалы, что сокращает риски внесения изменений. Команда должна быть готова к поправкам на стыке этапов, чтобы все ожидали перемен, а не противились им.
Будьте оптимистом во взглядах и скептиком в планировании. Главное психологическое испытание в планировании – придерживаться надлежащей степени скептицизма, без подавления энтузиазма и устремлений команды. В отличие от принципов создания концептуального документа, в котором должен преобладать оптимистический взгляд на будущее, календарный план должен исходить из противоположных перспектив. Числа, положенные в расчеты продолжительности работ, без каких бы то ни было поблажек должны соответствовать закону Мэрфи («все, что может пойти не так, пойдет не так»). В планах не должно отражаться то, что может произойти при оптимальных условиях. Вместо этого в хорошем плане отображается то, что должно случиться, несмотря на то что несколько существенных положений не оправдали своих ожиданий. Важно привлечь к планированию команду тестировщиков и контролеров качества, поскольку они внесут в разработку свойственный им скептицизм и критический взгляд на вещи.
Делайте ставку на проектирование. В процессе проектирования закладываются лучшие гарантии от неизвестных и неожиданных осложнений. Качественное проектирование – это единственный способ сделать более гладким преодоление командой фазы разработки и других фаз реализации проекта. Навыки проектирования отличаются от навыков разработки, поэтому самый сильный или самый продуктивный специалист по составлению программного кода не обязательно будет лучшим проектировщиком или специалистом по решению проблем. Качественному проектированию не учат на курсах информатики, несмотря на всю его важность в поиске путей и решений по разработке и управлению проектами. Эта тематика подробнее рассматривается в главах 5 и 6.
Планируйте контрольные точки для обсуждения исключений и добавлений. В календарные планы должны включаться короткие периоды для его пересмотра, позволяющие руководству критически оценить текущий процесс и учесть новую информацию и отзывы заказчика. Все это должно быть включено в главный календарный план и стать частью любого контракта на разработку проекта. В процессе пересмотра существующие работы могут урезаться или к ним могут добавляться новые, если это будет продиктовано результатами анализа текущей обстановки, проведенного руководством. Естественным временем для таких пересмотров являются промежутки между фазами или, в сокращенном варианте, моменты окончания каждой фазы проектирования или разработки, но они могут проводиться и в любое другое время, если возникнут серьезные опасения или явные расхождения между планом и реальным положением дел. Целью подобных пересмотров должно стать оздоровление проекта, освежение плана, уточнение приоритетов и инициирование следующего этапа выполнения календарного плана при ясном видении обстановки и с верой в будущее (см. главы 14 и 15).
Посвящайте команду в философию планирования. Какие бы технологии и подходы к планированию не использовались, их нужно доводить до команды. Если каждый программист и тестировщик сможет в общих чертах разобраться в принципах работы календарных планов и конкретной стратегии управления, применяемой в данном проекте, у него появится возможность задавать продуманные вопросы, понять общий замысел и поверить во все то, что планируется сделать.
Оцените опыт команды в сфере решаемых проблем. Одной из «волшебных» переменных величин в планировании является опытность команды в сфере тех проблем, которые ей предстоит решать. Если команда создает веб-сайт, управляемый базой данных, и пять или шесть программистов ранее уже не раз занимались такого рода работой, есть основания предполагать, что они лучше справятся с проектированием и расчетом графика работ, чем команда, ранее не делавшая ничего подобного. Этот фактор должен стать решающим в определении степени агрессивности или консервативности календарного плана.
Оцените уверенность и опыт команды в совместной работе. Несмотря на то что расчеты выполняют отдельные программисты, созданием чего-нибудь действительно сложного программисты занимаются вместе, как единое целое. Даже команда, составленная из опытных суперзвезд программирования, не достигнет ожидаемой результативности, если входящие в нее программисты ранее никогда вместе не работали (или не сталкивались все вместе со сложными задачами). Нельзя допускать, чтобы только что сформированной команде поручалась работа над сложным и рискованным проектом или предлагался агрессивный календарный план.
Беритесь за риски как можно раньше. Если известно, что Салли поручена наиболее сложная работа, учтите это в самом начале календарного плана. Чем выше риск, тем больше времени нужно зарезервировать для того, чтобы с ним справиться. Если вы откладываете учет рисков в календарном плане на более поздний срок, у вас останется меньше степеней свободы, чтобы справиться с этими рисками. То же самое относится к политическим, организационным или ресурсозависимым рискам. Мы поговорим об управлении работами при рассмотрении производственного конвейера в главе 14.
Выводы
• Календарные планы выполняют три функции: позволяют зафиксировать обязательства, помогают каждому увидеть свою роль в общей работе и дают возможность отслеживать процесс реализации проекта. Даже если календарные планы срываются, польза от них все равно остается.
• Большие календарные планы должны разбиваться на более мелкие с целью минимизации рисков и увеличения частоты внесения поправок.
• Все расчеты имеют вероятностный характер. Поскольку календарные планы опираются на множество оценок, они также носят вероятностный характер. Это обстоятельство отрицательно влияет на их точность, поскольку вероятности накапливаются (80 % 80 % = 64 %).
• Чем раньше сделаны оценки, тем менее они точны. Но несмотря на это, приблизительные расчеты – единственный способ создания фундамента для более точных расчетов.
• Календарные планы должны составляться не с оптимистических, а со скептических позиций. Чтобы пролить свет на предположения и приобрести уверенность в успехе, нужно вложить достаточные силы и средства в проектирование.
Упражнения
1. Если вы пользуетесь ежедневным планированием, взгляните на вчерашний распорядок. Много ли событий произошло в срок? Из тех, которые произошли с опозданием, сколько было связано с вашими ошибками?
2. Кто из известных вам людей постоянно опаздывает? Меняется ли из-за этого отношение к нему со стороны других сотрудников? Станете ли вы проявлять меньше оптимизма относительно сроков, отводимых ему на какую-нибудь работу? Переживает ли он из-за своих опозданий? Какие существуют мотивации для того, чтобы он изменил своим привычкам?
3. Найдите оригинал календарного плана предыдущего проекта. Сравните его с реальными событиями. Чтобы вы сделали по-другому, если бы знали все, что знаете теперь? Как воспользоваться этой информацией в интересах следующего проекта?
4. Проведите день, начиная и заканчивая все дела точно в срок. После задайтесь вопросом, стоило ли ради этого стараться? Почему да или почему нет?
5. Найдите друга, который работает в какой-нибудь другой сфере. Как он составляет календарное планирование своих проектов? Какими инструментами пользуется для подсчета времени, затрачиваемого на ту или иную работу? Какие в его сфере деятельности наиболее типичные ошибки и чему можно научиться из того, как он с ними справляется? (Если у вас нет таких друзей, то интересно будет поучиться, сравнивая свою деятельность со строительством, кинопроизводством, устроительством свадебных торжеств.)
6. Правило трех частей – это примерная норма, для которой есть исключения. Какие разновидности проектов требуют другого распределения времени? Могут ли быть проекты, в которых доминирует только одна из этих трех разновидностей работ?
7. Многие проекты существенно зависят от неподконтрольных вам работ. Какие методы можно применить при составлении календарного плана, чтобы сократить риск подобных зависимостей? Как можно наладить контакт с людьми, ответственными за составление календарного плана, чтобы они создали план, который бы привел к успеху обе команды?
8. Ваш руководитель настаивает на определенной дате, а ваш опыт подсказывает, что это нереально. Как можно воспользоваться календарным планом, чтобы объяснить вашу обеспокоенность руководителю?
9. Если элементарные просчеты, рассмотренные в этой главе, касаются большинства проектов, то как должен поступить толковый руководитель проектов: а) поставить в известность команду об их существовании, или б) поощрять людей за стремление уменьшить их влияние на проект? Um delis num velese dip exero eum velenibh ex et, susting exer si.
Глава 3. Как определить, что делать
По поводу планирования проектов редко кто приходит к единому мнению. Зачастую уйма времени в ходе планирования уходит лишь на то, чтобы прийти к согласию, как именно вести этот процесс. Я думаю, что в любой организации люди оказываются втянутыми в дискуссию о планировании из-за столкновения интересов работающих в ней специалистов разного профиля. Когда на карту поставлены главные решения, которые будут влиять на деятельность людей в течение многих месяцев или лет, всем хочется поучаствовать в их принятии. Здесь бушуют эмоции, кипит энергия, и все опасаются, что их недостаточная активность обернется упущенными возможностями. Подобное состояние легко приводит людей к убеждению, что именно у них самый правильный взгляд на вещи. Или, хуже того, что это единственная точка зрения, заслуживающая внимания.
Самым трудным при создании программной системы является решение о том, что именно создавать. Никакой другой раздел концептуальной проработки проекта не сравнится по сложности определения подробных технических требований, включая пользовательский, программный и аппаратный интерфейсы. Никакая другая неверно проделанная часть работы не способна так испортить общие результаты. Именно ее труднее всего впоследствии исправить. Поэтому наиболее важной функцией, выполняемой создателем программного продукта в интересах потребителя, является постоянное добывание и обработка требований, предъявляемых к продукту.
Фред Брукс (Fred Brooks)
Стоит ли после этого удивляться, что книги по планированию, сложенные в углу моего офиса, содержат весьма противоречивые положения. Часть из них сфокусирована на стратегии, другая часть – на процессах разработки, а некоторые – на уяснении запросов потребителей. Но больше всего тревожат не разногласия, а то, что в этих книгах не признается право даже на само существование других подходов. Весьма странное обстоятельство, учитывая, что ни одна из теорий развития бизнеса, совершенствования технологий, работы с клиентами не может существовать без других. Более того, я убежден, что успех в планировании проектов достигается на пересечении различных точек зрения. Любой руководитель, способный понять эту мысль, будет иметь неоспоримое преимущество над тем, кто этого не понял.
Итак, данная глава посвящена подходам к процессу планирования и выработке взгляда на планирование, предоставляющего наибольшие шансы на успех. Сначала мне следует пояснить некоторые термины и понятия, используемые в различных стратегиях планирования (материал суховат, но необходим для усвоения следующих глав). Если встретятся малоизвестные понятия, я дам определения и объединю разные точки зрения, проведу исследование вопросов, на которые даются ответы при хорошо организованном процессе планирования, и представлю пути организации ежедневной работы, направленной на успешное планирование. В следующих главах процесс создания конкретных разработок, в частности концептуальных документов (глава 4) и технических условий (глава 7), рассматривается более подробно.
Снятие покрова таинственности с вопросов планирования программных продуктов
Для небольшого индивидуального проекта корпоративного веб-сайта вряд ли стоит затевать столь же сложный процесс планирования, как для проекта отказоустойчивой операционной системы, в реализацию которого вовлечено триста человек и 10 миллионов долларов. Обычно, чем больше людей и сложнее проект, тем больше потребностей в серьезном планировании. Тем не менее планы приносят пользу даже самым простым индивидуальным проектам. Они дают возможность пересмотреть решения, выдвинуть предположения и прояснить соглашения между людьми и организациями. ланы действуют в качестве функции принуждения в борьбе со всеми видами глупости, поскольку требуют, чтобы в процессе рассмотрения других вариантов были решены все основные проблемы. Как сказал Авраам Линкольн: «Если бы у меня было шесть часов на то, чтобы срубить дерево, я бы потратил четыре часа на заточку топора». Я привел эту цитату, чтобы показать, что продуманная подготовка сокращает время работы.
При планировании проекта нужно найти ответы на два вопроса. Ответ на первый вопрос, «Что делать?», обычно называется выработкой требований. Ответ на второй вопрос, «Как делать?», называется проектированием или выработкой технических условий (рис. 3.1). Требование должно заключаться в тщательном описании критерия, которому работа призвана соответствовать. (Например, требование к приготовлению пищи может состоять в приготовлении недорого, вкусного и питательного блюда.) Хорошо продуманные требования легко понять и трудно неверно истолковать. Для выполнения требований могут быть выбраны различные варианты проектирования, но определить, насколько они соблюдены, можно только глядя на завершенную часть работы. Технические условия представляют собой простой план создания продукта, удовлетворяющего указанным требованиям.
Рис. 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.
Постановка правильных вопросов
Уточнение набора вопросов, на которые необходимо ответить при планировании – простейший вариант организации работы. Вопросы должны быть извлечены из перечней, составленных на основе трех взглядов на проект, с намерением собрать их в единый план.
Эти вопросы (часто называемые вопросами планирования проекта) должны быть извлечены из трех ранее рассмотренных перечней. Если проект новый (а не разработка очередной версии продукта), то для определения его основных положений понадобятся исходные вопросы. Если суть проекта заключается в незначительном обновлении существующей системы, то вопросов о бизнесе и потребительских интересах может быть совсем немного. Но независимо от характера проекта нужно просмотреть все вопросы. Тогда на поверхность всплывут не выявленные ранее предположения и дадут всем равноценные исходные точки для обсуждения.
Перечень вопросов планирования проекта не должен иметь разграничения по основным взглядам на проект. Лучше иметь целостный взгляд на проект, который при необходимости можно разделить на соображения, соответствующие позициям разработчика, бизнесмена или потребителя. Рассмотрим, например, следующий перечень, состоящий из более сложных версий ранее представленных вопросов:
• Почему появился этот проект? Почему именно мы подходим для его осуществления? Почему его следует реализовать именно сейчас?
• Что собой представляют три или четыре категории людей, которых можно рассматривать в качестве различных типов потребителей? (Например, для текстового процессора это могут быть студенты, профессионалы и обыкновенные пользователи, для информационной базы данных – продавцы, секретари и руководители.) Как отличаются их потребности и привычки?
• Какая демографическая информация может помочь разобраться в типаже потребителей? (Возраст, заработок, вид компании, профессия, образование, пользование другими программными продуктами или веб-сайтами и т. д.)
• Для каких целей каждой из групп используется программный продукт? В какой степени это соответствует целям покупки? Как это соответствует организации продаж продукта? С какими проблемами они столкнулись при использовании продукта для удовлетворения своих потребностей?
• Кто потенциально может стать новым покупателем и какие характеристики, сценарии работы или типы продукции нам нужно предоставить, чтобы превратить их в реальных покупателей? (Каковы демографические данные этих новых покупателей?)
• Обладаем ли мы достаточными технологиями и производственным опытом для создания продукта, удовлетворяющего этим запросам или решающего эти проблемы? (По крайней мере, при первой прикидке для каждой выявленной потребности достаточным будет один из следующих вариантов ответа: да, может быть, нет.)
• Можем ли мы создать технологию или набраться опыта для создания продукта, удовлетворяющего этим запросам или решающего эти проблемы? (Да, может быть, нет.)
• Присутствуют ли эти значимые возможности в новом продукте или линейке продуктов? Или связаны ли непосредственно с продуктом (линейкой продуктов) выявленные запросы?
• Существуют ли действенные бизнес-модели для использования нашего делового опыта и технологии в решении выявленных проблем или в удовлетворении запросов? (Смогут ли доходы превысить затраты в обозримом будущем?)
• Какими должны быть сроки выпуска на рынок следующей версии или следующего продукта? В какие благоприятные моменты лучше всего выпустить продукт?
• Чем в этой рыночной нише заняты конкуренты? В чем по нашему мнению заключается их рыночная стратегия и как мы можем с ними конкурировать?
Ответы на правильные вопросы
Ответы на эти вопросы в зависимости глубины и качества, в которых они нуждаются, можно искать на протяжении нескольких часов или нескольких недель, что, в свою очередь, определяется руководителем проекта или группы. На практике, чем более стратегической ожидается направленность проекта, тем более важным становится качество этого вида определений и исследований в интересах планирования. Проектам тактического значения, направленным на решение второстепенных вопросов или краткосрочных потребностей, такая глубина не нужна. Для них, возможно, понадобится проработать лишь некоторые из вопросов, и во многом в основу ответов можно положить ответы на такие же вопросы, которые были даны при планировании предыдущего проекта. Но для серьезных проектов данная информация приобретет особую ценность не только на стадии планирования, но и в промежуточных фазах проекта, при внесении поправок и изменений.
Наилучшие ответы на некоторые из этих вопросов можно получить от бизнес-аналитиков, на другие – от ведущих программистов или инженеров по потребительским свойствам изделий. Хорошие ответы часто являются результатом дискуссий с участием всех этих специалистов и обмена пояснительными записками, источниками информации и мнениями. На такую работу может быть потрачено много времени и средств, но для планирования это вполне естественно. Чтобы достичь успеха при покупке дома или машины, при переезде в другую страну или при написании книги, требуется потратить немало сил на планирование своих действий. При правильном проведении планирования появится возможность принимать выверенные и быстрые решения в процессе реализации проекта. (Более полно этот вопрос изложен в главе 14.)
Что делать при дефиците времени?
В худшем случае, даже если нет никаких результатов исследований или на соответствующие исследование нет времени, все равно задавайте эти вопросы. Постановка правильных вопросов в любом случае приведет к двум положительным последствиям. Во-первых, разумные предположения в ответ на правильные вопросы лучше, чем ничего. Даже если у вас есть время лишь на выстраивание предположений, обдумывание правильных вопросов принесет больше пользы, чем обдумывание неправильных. Во-вторых, отсутствие исследований по основным вопросам может стать тревожным сигналом для руководителей и управленческого аппарата. Долговременное благополучие организации зависит от способности строить действенные планы, и даже если инвестиции (привлечение новых специалистов или выделение средств) к данному проекту запоздают, они смогут помочь разработке следующего проекта.
Перечень типичных просчетов при определении конечной цели проекта
Когда что-нибудь делаешь, то всегда больше плохих способов, чем хороших, и планирование проекта здесь не исключение. В качестве пособия, позволяющего отличить хорошее от плохого, можно воспользоваться табл. 3.1, в которой приводятся несколько неверных подходов, с которыми мне приходилось сталкиваться на практике. Я привожу ее в надежде, что она поможет вам распознать подобные ситуации и понять, почему подобные подходы становятся источником проблем.
Таблица 3.1. Наиболее распространенные просчеты в определении конечной цели проекта
Процесс планирования
За время, отведенное для определения параметров проекта, нужно ответить на вопросы планирования. По возможности каждый из взглядов (бизнесмена, разработчика и потребителя) должен иметь, как минимум, по одному стороннику, располагающему результатами исследований, проведенных в его области. Этот человек будет выдвигать идеи и предложения и пересматривать свои соображения вместе со сторонниками других взглядов. Вся суть в том, чтобы экспертная группа была немногочисленной, чтобы работать продуктивно, но в то же время и не слишком маленькой, чтобы каждая точка зрения была представлена достаточным количеством экспертов для широкой и всесторонней оценки. Групповые решения и обсуждение проблем могут даваться группе из десяти человек куда труднее, чем группе из пяти человек (см. главу 9).
По собственному опыту знаю, что лучше иметь дело с ущемленным самолюбием тех, кто не вносит основной вклад в планирование, чем привлечь к процессу массу людей и возиться с неважно спланированным и сотканным из компромиссов проектом. Состоявшиеся специалисты, которых вы не включите в группу, поймут ваши мотивы, если вы потрудитесь их объяснить, а несостоявшиеся получат возможность для развития или поиска занятия, более подходящего для их самовыражения.
Если вы используете те документы по планированию, о которых я упоминал в начале главы, то целью группы планирования должна быть выработка и доведение этих документов до всей команды. Как только документы (или, что еще важнее, содержащиеся в них решения) будут готовы, фаза планирования завершается (рис. 3.3).
Рис. 3.3. Взаимосвязь между уровнями планирования
Черновой вариант каждого входящего в планирование документа должен быть готов как можно раньше, чтобы до выработки окончательной версии включить в него все обратные связи, выработанные командой. Это могут быть простые циклы обратной связи между документами плана, изображенные на рис. 3.3. После создания чернового варианта анализа потребностей рынка – MRD, появится возможность приступить к работе над концептуальным документом, во время которой будут возникать новые вопросы, касающиеся этого анализа, улучшающие документ до его завершения. Эта же схема работы повторяется при разработке всех документов. Таким образом, даже если сроки окончания разработки документов плана поджимают, некоторые перекрытия по времени разработки каждого из них пойдут только на пользу и повысят качество всего процесса. Как показано на рис. 3.4, когда разработка проекта достигает середины (стадии выполнения), распространение вверх по структуре планирования подобных обратных связей дается все труднее, хотя и не исключается. (Можно считать, что рис. 3.4 иллюстрирует работу нанятой по контракту команды, сфера влияния которой ограничена выработкой технических условий и определением характера и объема работ.)
Рис. 3.4. Со временем становится все труднее вносить коррективы в верхние элементы структуры планирования, хотя такая возможность не исключается
Повседневная работа
Рассматривая порядок повседневной работы над документами плана, нужно заметить, что какого-либо волшебного метода выполнения этих совместных задач не существует. Люди есть люди, поэтому невозможно перескочить через время, необходимое для того, чтобы люди с различным складом ума объединились, научились чему-то друг у друга и пришли к компромиссам, необходимым для продвижения вперед. Тут не обойтись без проведения встреч, дискуссий и, возможно, создания рассылок или веб-сайтов, но секретных рецептов радикального изменения такого порядка вещей не существует. Ведите себя как можно проще и непосредственнее. Именно лидер задает тон началу разговора, нацеливает на постановку важных вопросов и обеспечивает присутствие в аудитории нужных людей в нужное время. Тем не менее есть три вещи, которые обязательно следует учесть:
Наиболее важная часть процесса – распределение ролей. Кто получит полномочия на выдвижение требований? На проектирование? Если к процессу привлекается много людей, как будут приниматься решения? Как быть при равенстве голосов? Если подобные вопросы взаимоотношений решить на ранней стадии, то удастся избежать многих проблем или, что более вероятно, справиться с ними хладнокровно и своевременно. (Наиболее полно проблемы взаимоотношений и распределения ролей рассмотрены в главе 10.)
О промежуточных пунктах должны знать все. Какие этапы нужно пройти от начала до конца планирования? Непосредственные исполнители сначала должны составить календарный перечень мероприятий, таких как доклады, презентации, совещания или обсуждения документов. Когда конкретно будет завершено планирование как таковое и начнется проектирование или разработка? На все это должны быть даны четкие и доведенные до всех ответы.
Нужно почаще проводить обсуждения каждого из взглядов на проект. Должна доводиться новая информация или замыслы, подниматься новые вопросы или делаться выводы. На эти обсуждения должны привлекаться специалисты из других подразделений вашей организации или команды, если у них имеется полезный опыт работы или их мнение представляет ценность для группы.
Читать бесплатно другие книги:
