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

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

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

В соответствии с правилом, на каждый день, отводимый на разработку программного кода, выделяется день на планирование и проектирование и день на проверку и доводку сделанного (рис. 2.1). Вряд ли что-нибудь еще может быть проще – перед вами простой механизм проверки любых существующих календарных планов или создания календарного плана «с нуля». Если все отведенное на реализацию проекта время не разделено приблизительно на три равных этапа работы, должны быть вполне объяснимые причины, почему проекту требуется неравномерное распределение усилий. Если позволяют сроки, правило трех частей допускает некоторый дисбаланс, при котором считается нормальным отводить на тестирование на двадцать и более процентов времени больше, чем на разработку.

Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей

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

Разработка по частям (беспроектный проект)

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

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

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

Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.

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

Гибкий и традиционный методы

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

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

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

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

Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов

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

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

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

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

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

Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов[11]11
  «Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).


[Закрыть] писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.

Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма «Software Engineering Economics»)

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

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

Когда мы обсуждали, в чем состоит разница между этим главным планом и календарным планом, созданным моей командой на основе списка работ,[12]12
  Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, – нисходящими. Обычно разногласия между ними согласовываются.


[Закрыть] главный план казался нам высосанным из пальца. Он был спущен сверху, аккуратно отформатирован, разбит на красивые столбцы из дат и чисел, но при этом казался чем-то искусственным, украденным из будущего.

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

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

Итак, если все в команде согласны, что календарный план – это набор возможных значений, значит, проблема не в самом плане, а в том, как он используется. Если когда-либо календарный план доводится на совещании команды или рассылается по электронной почте, возникает резонный вопрос: какова вероятность соблюдения приведенного в нем графика работ? Если вероятностные оценки не предлагаются (например, что существуют пять наиболее вероятных рисков и предполагается такая-то вероятность их возникновения) и кто-либо из создателей плана не может предложить каких-либо объяснений относительно сделанных допущений, то остается предположить, что выполнение календарного плана возможно, но маловероятно[13]13
  В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т. д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.


[Закрыть] План должен быть открытым для высказываемых командой предложений, чтобы предлагаемые соображения или информация могли дополнить или скорректировать план в целях повышения вероятности его выполнения.

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

В процессе проектирования (обсуждаемого в главах 5 и 6) одной из задач проектировщиков, программистов и тестировщиков является разбиение проекта на небольшие части работы, которая имеет некие завершенные формы. Эти части, часто называемые элементами структурной декомпозиции работ (Work Breakdown Structure, WBS[14]14
  Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).


[Закрыть]), или просто работами, становятся строками в главном календарном плане проекта. Работы разумно (скрестите пальцы) распределяются[15]15
  В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.


[Закрыть] среди программистов команды и в соответствии с ними строится календарный план. Каждая из этих работ должна иметь предполагаемый срок завершения, назначенный программистом, и на основе этих предположений создается календарный план.

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

Весь мир держится на расчетах

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

По моему опыту, даже если программист разбирается в расчетах и верит в их состоятельность, он все равно берется за них с неохотой. Частично это вызвано несоответствием воображения («при столь скудной информации я не могу представить, как это все должно работать») с требованием точно рассчитать время («скажите мне точно, сколько часов вам понадобится на разработку»). Но не стоит проявлять излишнее сочувствие: подобные сложности возникают у всех, кто занимается разработкой и строительством, строят ли они небоскреб, занимаются перепланировкой кухни или запускают космический зонд для посадки на другие планеты. Я много читал о том, как эти ребята проводят расчеты, и мне вовсе не показалось, что их сомнения и применяемые технологии в корне отличаются от тех, с которыми приходится сталкиваться разработчикам веб-сайтов и программ. Основное отличие состоит во времени, отводимом ими на расчеты, и в рациональности его использования (более детально этот вопрос рассматривается в главах 5 и 6).

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

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

Я выработал очень удобный прием на случай, когда программист задерживается с расчетами. Я его спрашиваю: «О чем нужно спросить, чтобы придать вам уверенности в расчетах?» Заставив его сосредоточиться, я даю возможность побороть те чувства страха и неуверенности, которые могли им овладеть. Конечно, я должен был бы помочь найти ответы на его вопросы и, возможно, обсудить проблемы, которые, как я считал, он должен был решить самостоятельно, но, по крайней мере, мы поговорим о повышении качества расчетов.

Вот несколько дополнительных советов, позволяющих добиться качественных расчетов:

 Установите базовые показатели доверия расчетам. Предположение – 40 % доверия, качественный расчет – 70 %, подробный и полный анализ – 90 %. Руководители команд должны прийти к соглашению, насколько точными должны быть расчеты, сколько времени отвести программистам для их проведения и как управлять риском неверных расчетов. Не заостряйте внимание на цифрах: пользуйтесь ими лишь для конкретизации качества расчетов. Расчет с 90-процентным доверием должен означать, что сроки выдерживаются в 9 случаях из 10. Если вы решите обратиться к команде с просьбой поднять качество расчетов, то должны подкрепить свою просьбу выделением дополнительного времени.

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

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

 Расчеты зависят от понимания программистами целей проекта. Расчеты основываются на программистской интерпретации не только проектировочных спецификаций (если таковые имеются), но также целей и параметров, заложенных в проект. Джеральд Вейнберг (Gerald Weinberg) в книге «The Psychology of Computer Programming» (Dorset House, 1971) отмечал прямое влияние недостаточно четко поставленных целей высокого уровня на низкоуровневые предположения, допускаемые программистами. Какой бы понятной ни была бы технологическая проблема, подходы программистов к ее решению могут в корне меняться в зависимости от общего замысла всего проекта.

 Расчеты должны основываться на опыте предыдущих работ. Хорошо, если в привычку программистов войдет сохранение преемственности расчетов от проекта к проекту. Эта тема должна стать частью их дискуссии с руководителем проекта; в интересах руководителя выяснить, кто из команды преуспел в тех или иных расчетах. В экстремальном программировании в отношении возможной производительности программиста (или команды), основанной на предыдущих показателях производительности, используется понятие скорость.[16]16
  См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.


[Закрыть]

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

 Существуют известные методы улучшения качества расчетов. Наиболее известным является метод PERT (Program Evaluation and Review Technique – метод оценки и пересмотра планов), в котором предпринимается попытка минимизировать риски путем вычисления усредненной величины из результатов лучшего, среднего и худшего расчетов.[17]17
  Стандартная формула для метода PERT: лучший расчет + (4 × наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.


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