Плохая оценка — одна из причин неуправляемости проекта

Неуправляемые проекты — это проекты, которые выходят из-под контроля. Слишком часто их не удается завершить выдачей хоть какого-то продукта. А если все же удается, то с большим отставанием от бюджета. Их выполнение сопровождается массой потерь, как корпоративных, так и людских. Некоторые проекты известны как «путь камекадзе». Другие проходят в «авральном режиме». Как бы они не назывались, какими бы ни были результаты, неуправляемые проекты — это невеселое зрелище.

Вопрос о том, почему проекты становятся неуправляемыми, часто возникает в программистской среде. Те, кто на него отвечают, часто опираются на личные пристрастия.

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

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

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

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

Затем мы  проверили алгоритмические подходы.  Компьютерные специалисты тяготеют душой  к математике, и, очевидно, стоило попытаться вывести тщательно продуманные параметризованные уравнения (обычно на основе  предыдущих проектов), которые могли бы дать ответы  в виде оценок. Подайте  на вход данные, специфичные для данного проекта, как сказали бы разработчики алгоритмов, поверните алгоритмический рычаг, и на свет появятся надежные оценки. Ничего не получилось. Исследователи один за другим (например, Моханти [Mohanty, 1981] показали, что, если взять гипотетический проект и заложить его данные в совокупность предложенных алгоритмических приемов,  эти  алгоритмы генерируют радикально отличные (с коэффициентом от двух до восьми) результаты. Алгоритмы давали не более согласованные оценки, чем до них это делали эксперты. Последующие исследования с новой силой  подтвердили это неутешительное открытие.

Если задачу нельзя решить  с помощью сложных алгоритмов, размышляли некоторые, то, может  быть, помогут более простые алгоритмические приемы. Многие специалисты отрасли отталкиваются от оценки, основанной  на одной из нескольких ключевых единиц информации, например на строчках кода (lines of code, LOC). Они  говорят, что, если можно предсказать ожидаемое количество строчек кода, который надо написать для создания системы, то можно преобразовать «строчки кода» в сроки и трудозатраты. (Над этой идеей можно было бы от души посмеяться – в том смысле, что, пожалуй,  труднее  узнать,  сколько строчек кода  будет содержать  система, чем каким будет срок  выполнения и сколько она будет стоить, если бы ею не оперировало такое количество ярких во всем остальном компьютерных специалистов.) Согласно методике функциональных точек (function points, FP), оценка дается на основе анализа ключевых параметров, таких как количество входов и выходов  в системе. Не все гладко и с этим подходом, здесь целых  две неувязки.  Во-первых,  эксперты  расходятся во мнениях, что именно и как  следует подсчитывать.  Во-вторых,  для одних приложений «функциональные точки» могут иметь смысл, а для других, где, например, количество входов и выходов намного меньше, чем сложность логики внутри программы, они  не имеют никакого смысла. (Некоторые эксперты дополняют «функциональные точки» характерными (feature points) – для тех применений, когда «функций» очевидно не хватает. Однако без ответа остается вопрос,  на который, похоже, к настоящему времени не ответил  никто «А сколько же всего видов приложений, требующих неизвестно какого количества схем подсчета, основанных на типах «точек»?»)

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

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

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

Данный факт посвящен выбору времени оценки. Обычно мы оцениваем все в самом начале. Звучит неплохо, правда? А когда же еще и оценивать? Все хорошо, кроме одного. Чтобы сделать осмысленную оценку, необходимо знать о рассматриваемом проекте достаточно много. Как минимум надо знать, какую задачу предстоит решить. Но первая фаза жизненного цикла, в самом начале проекта, заключается в определении требований. То есть в первой фазе мы устанавливаем требования, которым должно удовлетворять решение. Иначе говоря, чтобы определить требования к решению задачи, надо осознать, какая это задача. Можно ли оценить время и затраты на решение задачи, не имея о ней представления?
Ситуация настолько абсурдна, что я, рассказывая на различных компьютерных форумах об этом факте, спрашиваю аудиторию, может ли кто-нибудь опровергнуть только что сказанное. Все-таки этот парадокс скорее всего относится к разряду софизмов. Тем не менее до сих пор никто этого
не сделал. Наоборот, все кивают, демонстрируя понимание и согласие.

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

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

Оценки в проектах ПО редко уточняются впоследствии. Другими словами, оценки, сделанные не теми людьми и не в то время, как правило, не корректируются.

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

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

Наш последний шанс – здравый смысл. Можно подумать, что раз оценки настолько плохи – и время не то, и люди не те, и (о чем мы только что говорили) никто оценки не пересматривает, – то и относиться к оценкам будут как сравнительно маловажным? Правильно? Нет! Управление программными проектами практически всегда ведется в соответствии с планом. Из-за этого план рассматривается (по крайней мере, высшим руководством) как самый важный фактор в индустрии ПО.
Сделаем некоторые уточнения. Для того чтобы управлять по плану, надо установить оперативные и долгосрочные контрольные точки (в MS Project они называются вехами) и определять успешность выполнения проекта по тому, что происходит в этих контрольных точках. Вы отстали
от графика в точке 26? Плохо дело.
А как иначе руководить программными проектами? Приведу несколько примеров, чтобы показать, что управление по плану – это не единственный способ.
• Можно ориентироваться на продукт. Об успешности или не успешности проекта можно судить по тому, какая часть конечного продукта создана и работоспособна.
• В управлении проектом можно ориентироваться на возникающие проблемы. Успех или неудача определяются в зависимости от того,  как хорошо и как быстро разрешаются проблемные моменты, которые всегда возникают в ходе выполнения проекта.
• Можно руководить, ориентируясь на риск. Критерием успеха или неудачи могла бы стать демонстрация того, как преодолеваются риски, определенные в начале проекта.

Анализ осуществимости проекта почти всегда дает ответ «да».

Индустрия ПО испытывает на себе весьма разнообразные проявления действия «феномена новичка». Одно из проявлений заключается в том, что  «нас не уважают». Люди, привыкшие работать по старинке в отраслях, для которых мы решаем прикладные задачи, считают, что раз они обходились
без программных продуктов десятилетиями, то – большое спасибо – они прекрасно обойдутся без них и сейчас.
Эта сцена была поставлена в «театре абсурда» несколько лет назад, когда такую точку зрения принял технический менеджер проекта беспилотного самолета. Беспилотный самолет просто не может функционировать без компьютеров и программ, но это было неважно. Малый хотел продолжать проект, выбросив к чертям всю эту хлопотную технологию.
Феномен новичка наносит нам удар и еще с одной стороны, – дело в том, что мы, кажется, слишком часто страдаем неисправимым оптимизмом. Выглядит это примерно так: раз мы можем сделать то, что до нас не удавалось сделать никому, то мы уверены, что такой задачи, которую мы не могли бы решить, нет вообще. И что самое удивительное, часто это так и есть. Бывает, однако, что оптимизм приводит нас в западню. Когда мы полагаем, что закончим проект завтра или, по крайней мере, не позже чем через день. Когда мы думаем, что в продукте не будет ошибок, а потом обнаруживаем, что для их устранения надо потратить больше времени, чем на системный анализ, проектирование и кодирование вместе взятые.

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

(с) Роберт Гласс. Факты и заблуждения профессионального программирования.

1 комментарий

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *