Путь камикадзе [Смертельный марш]
Шрифт:
27) Китайская пытка водой – в отличие от предыдущей игры ва-банк, связанной с высоким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству маленькими порциями. Вообразите, например, такую ситуацию, когда разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев; по его мнению, при помощи сверхурочной работы и разного рода чудес проект можно попытаться закончить за 6 месяцев, однако руководство настаивает на 4-х месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек» – например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда – 5 или 7) ; отсюда, по его мнению, следует, что срок разработки заключительной
28) Туманы и миражи – горе тому несчастному менеджеру проекта, вице-президент которого нанял консультанта по метрикам с моделью оценки, в которой никто ничего не понимает. Метрики ПО в конечном счёте представляют собой статистику, а модели оценки основываются, как правило, на сложных математических зависимостях. Когда они попадают в руки человека неопытного, наивного или преследующего определённые политические цели, эти средства могут быть использованы для «доказательства» корректности любой произвольной оценки. Все это вдвойне опасно, если источником этих метрик является поставщик, пытающийся доказать, что безнадёжный проект преуспеет благодаря фантастической производительности его CASE-средств, средств визуального программирования или новейшей методологии разработки ПО.
29) Спрятанное качество – это одна из наиболее хитрых игр, в ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. На самом деле все очень просто: как менеджер проекта, я могу предоставить пользователю бесконечно большое количество программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий, однако, суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) – это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчёт длительную перспективу: «Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кардинально измениться, да и я сам, в любом случае, буду другим. Что меня действительно беспокоит – это чтобы система была готова через три месяца и работала после этого 12 месяцев». Если политика оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнаружить IT-менеджеров и менеджера проекта, готовых согласиться с такой позицией; гораздо менее вероятно, чтобы с ней могли соглашаться технические специалисты. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которую я описал в [9]; в худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.
3.4 Стратегии переговоров
Что следует предпринять, если вы оказались втянуты в одну из описанных выше политических игр? Это в равной степени важно, даже если вы не являетесь их непосредственным участником, а наблюдаете со стороны – например, в качестве технического специалиста-участника проектной команды – все происходящие вокруг вас игры по поводу сроков, функциональности и бюджета. Thomsett высказывает интересную мысль, что все мы обучаемся этим политическим играм от наших наставников, менеджеров и «старейшин» политической культуры своей организации; поэтому, даже если мы сами не можем избежать этих игр, возможно, нам удастся уберечь от них своих подчинённых в надежде, что все эти политические игры сами по себе отомрут через поколение или два.
Это, конечно, было бы просто замечательно, но, к сожалению, я не столь оптимистичен. Иногда мне кажется, что политика заложена в нас на генетическом уровне, в коде ДНК. Даже если положение и не такое удручающее, реалии таковы, что политические игры, подобные описанным в этой главе, всегда вокруг нас; софтверные проекты вовсе не являются в этом смысле чем-то уникальным, и каждый из нас в течение своей жизни оказывался втянутым в те или иные игры. Даже если предположить, что такие игры нетипичны для софтверных проектов, все равно наша профессия достаточно мобильна для того, чтобы любая организация почти наверняка в какой-либо период времени оказалась «инфицирована» чересчур политизированными менеджерами, поставщиками и специалистами по маркетингу. Политические игры – это нечто такое, что следует принять как неизбежное зло, и мы должны уметь наилучшим образом справляться с ними.
Одна вещь, которую мы действительно можем
В такой же степени не всегда возможно избежать требования дать немедленную оценку. Представьте, что во время презентации ваш клиент поворачивается к вам и спрашивает: «О’кей, Гарри, допустим, мы исключим из системы интерактивный Web-броузер и добавим десять наших людей в твою команду. Сколько времени тебе потребуется на всю работу?» Все поворачиваются и смотрят на вас, и вы видите, что менеджер по маркетингу чувствует себя явно не в своей тарелке; из всех предыдущих дискуссий по этому вопросу вы, вероятно, знаете, что политически приемлемый ответ – «Три месяца – и никаких проблем!» Хватит ли у вас духа ответить: «Джо, я в самом деле не знаю; нам следует вернуться в офис и проиграть то, что ты сказал, на нашей оценочной модели. Кроме того, мне необходимо поговорить с твоими людьми и выяснить их квалификацию…»
В подобной ситуации – и во многих других ситуациях, когда у вас действительно имеется некоторое время на выполнение формальной оценки – очень важно выразить ваши оценки в терминах «уровней достоверности» или в некотором диапазоне «плюс-минус». Если у вас абсолютно отсутствуют данные для детальной оценки, и если в безнадёжном проекте будет использоваться совершенно новая технология и будет участвовать персонал неизвестной квалификации, то будет благоразумным сказать: «Проект, вероятно, потребует от трех до шести месяцев» или «Я думаю, что мы закончим проект через шесть месяцев плюс-минус 50%».
Конечно, большинство менеджеров проектов знают о таком подходе, и они уже могут его использовать (либо нет). Определение размера диапазона «плюс-минус» является составной часть науки проектных оценок, и я адресую интересующихся к тем источникам, которые перечислены в конце главы. Что касается безнадёжных проектов, важно не забывать о вмешательстве политики в те оценки, которые даются во время переговоров. Наиболее распространённой, например, является такая ситуация, когда все, что вы говорите по поводу диапазона «плюс-минус», напрочь игнорируется вашими партнёрами по переговорам. Так, если вы, находясь на совещании по вопросам планирования, говорите заказчику и другим руководителям: «Мы могли бы завершить этот проект за шесть месяцев±25%», каждый запишет в свой блокнот «шесть месяцев». (Конечно, те, кто поднаторел в политике, возьмут наихудшую оценку, данную вами, и добавят к ней ещё для «надёжности» перед тем, как докладывать своему высокому начальству. К сожалению, политически неопытные или амбициозные поступят как раз наоборот. В результате директор может сделать окончательный вывод, что проект будет закончен через четыре месяца или раньше.) Неважно, сколько раз вы это повторили, все равно никто не обратит внимания, и когда информация вернётся обратно от вашего босса, вы обнаружите, что срок разработки составляет шесть месяцев. Все, что вы в состоянии сделать – это никогда не отказываться от знака «±» в любых устных или письменных утверждениях, обещаниях, соглашениях или оценках, которые вы даёте. Это не устранит проблему, но, по крайней мере, послужит для вас оправданием, если срок разработки окажется максимальным в соответствии с вашей оценкой.
К сожалению, есть один довольно неприятный момент, связанный с использованием приближённой оценки: вас могут обвинить в неуверенности, слабости или даже в некомпетентности. Это особенно характерно для безнадёжных проектов с синдромом «Морского Корпуса», который обсуждался ранее. Чего на самом деле хочет от вас высшее руководство – это твёрдого обещания и обязательств, что проект будет закончен к точно определённой дате, его бюджет будет составлять определённое количество долларов, и персонал будет включать определённое количество людей. Им доставляет огромное удовольствие (а) не заботиться больше о проблемах, связанных с продолжительностью проекта, и (б) иметь козла отпущения, на котором можно отыграться, если обещания будут нарушены. Оценки, имеющие вид «Х месяцев ± 50%», «500.000$ ± 100%» и «10 человек ± 25%», никак не могут их удовлетворить.