Вследствие эффекта «обратной связи», возникающего в результате многих решений руководства, изменение одной переменной (например, увеличение штата) повлияет со временем не только на другие переменные (такие, как продуктивность), но и на собственное первоначальное значение — например, увеличение штата может отрицательно повлиять на моральное состояние команды, что, в свою очередь, может увеличить текучесть рабочей силы в проекте и в конечном счёте снизить численность персонала.
Упомянутые выше динамические модели систем как раз отражают сущность этих нелинейных и нестационарных зависимостей; их характер является, к тому же, причиной использования различных коммерческих средств оценки, описанных выше. Следует отметить, что математической основой этих динамических моделей являются, как правило, нелинейные дифференциальные уравнения, в которых большинство из нас не слишком хорошо разбирается. Аналогично, коммерческие средства оценки выполняют сложные расчёты с учётом множества параметров; попытка сделать такую работу на интуитивном уровне, основываясь только на своём замечательном чутьё, приведёт, скорее всего, к грубым ошибкам.
К сожалению, именно в таком положении оказывается большинство менеджеров безнадёжных проектов. Отчасти это объясняется самой природой переговорного процесса (напоминающего игру под названием «Испанская инквизиция», которая будет обсуждаться ниже) ; однако, причиной может быть отсутствие адекватных средств оценки и соответствующего опыта во многих организациях. Если этой проблемой ранее не занимались, то тем более бесполезно пытаться решать её во время безнадёжного проекта. Если в организации привыкли к торопливости и небрежности в количественной оценке проектов, то менеджеру безнадёжного проекта вряд ли удастся выбить 10.000$ на приобретение достаточно сложного средства оценки.
Итак, что же делать в такой ситуации менеджеру? В крайнем случае, менеджеру остаётся осознать тщетность усилий и отреагировать соответственно; такая ситуация будет детально обсуждаться ниже в подразд. 3.5. Однако, в менее сложной ситуации существуют два возможных варианта действий:
18) Если требования пользователей или высшего руководства включают изменение одной из переменных проекта в пределах 10%, его можно компенсировать пропорциональным изменением одной из остальных переменных. Так, например, если руководство хочет сократить срок разработки на 10%, следует увеличить на 10% состав проектной команды. Вряд ли это будет точной компенсацией, но достаточно хорошо в первом приближении, и, как правило, это все, что вам удастся сделать в процессе переговоров.
19) Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным. Так, предположим, что руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6. Вместо того, чтобы удваивать состав проектной команды, менеджеру следует увеличить его в 4 раза — или увеличить в 4 раза бюджет, чтобы нанять суперпрограммистов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной модели оценки невозможно определить, насколько эта грубая эвристика будет соответствовать конкретной ситуации, но во всяком случае это лучше, чем оказаться в ловушке или придерживаться линейной зависимости между временем и людьми. К сожалению, «квадратичный» вариант достаточно трудно отстоять, и, скорее всего, «наглые» требования менеджера проекта будут отвергнуты, однако в случае хотя бы минимальной удачи менеджер все равно может оказаться в лучшем положении, чем при «линейном» варианте.
3.3 Переговорные игры
Переговоры — это игра , она имеет место во всех софтверных проектах. Переговоры в безнадёжных проектах характерны тем, что ставки гораздо выше, эмоции перехлёстывают через край, а запросы противоположной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой «запас прочности». В обычном проекте, например, самый очевидный запас прочности — это сверхурочное время. Даже если менеджер проекта оказался вынужден принять под давлением жёсткий график и урезанный бюджет, успеха все равно можно будет добиться, уговорив проектную команду работать сверхурочно от 10 до 20 часов в неделю в течение нескольких заключительных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, поскольку программисты ничего не получают за сверхурочную работу, поэтому менеджер в конце проекта выглядит героем.
Однако, в безнадёжном проекте небольшого количества сверхурочного времени обычно явно недостаточно, чтобы достичь тех впечатляющих результатов, которые требует руководство. Кроме того, пользователи и высшее руководство не столь наивны — они знают , что может потребоваться сверхурочная работа, и учитывают её в своих собственных оценках графика выполнения проекта — лишая таким образом менеджера возможности использовать этот свободный ресурс. Правда, менеджеры-ветераны подобных переговоров должны иметь запасные карты в рукаве, которые могут пойти в ход в начале переговоров.
В самом плохом положении находится неопытный менеджер; в худшем случае он даже не представляет, что его последний успех мог быть достигнут только благодаря тому, что проектная команда добровольно согласилась на большую сверхурочную работу, чтобы уложиться в сжатые до безобразия сроки. В свою очередь, такой смехотворный план мог быть навязан проектной команде именно из-за неопытности менеджера в области проектных оценок и переговоров.
Консультант в области менеджмента Rob Thomsett в своей замечательной статье [8] определил наиболее общие варианты переговорных игр; наиболее распространённые из них приведены ниже:
20) Удвой и добавь ещё — эта уловка используется в проектах, начиная с египетских пирамид, если не раньше. Используйте любые методы оценки, оказавшиеся под рукой, затем полученную «разумную» оценку удвойте и для большей надёжности добавьте ещё три месяца (или три недели, или три года, в зависимости от масштаба проекта). Главная проблема такой стратегии заключается в том, что она прямиком ведёт к самому жёсткому ограничению, связанному с безнадёжными проектами: сжатым срокам.
21) Обратное удвоение — как было отмечено ранее, руководство может быть вполне осведомлено о попытках менеджеров проектов «раздуть» свои оценки, используя предыдущую стратегию. Одна из причин такой проницательности заключается в том, что высшее руководство во многих организациях — это бывшие менеджеры проектов в области информационных технологий, поэтому они хорошо разбираются в таких играх. В результате они берут те начальные оценки, которые им дают менеджеры проектов, и автоматически урезают их наполовину. Беда несчастному неопытному менеджеру, который даже не знает, что его подозревают в удвоении своих начальных оценок!
22) «Угадай число, которое я задумал» — такую игру я освоил в одном из моих первых проектов, когда был ещё молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются чётко её сформулировать . Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много — попробуй угадать ещё раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придётся отвечать за неё.
23) Двойной плевок пустышкой — «пустышкой» (dummy) на австралийском сленге называется детская соска, и «выплюнуть пустышку» означает, что ребёнок настолько расстроен и рассержен, что выплёвывает свою соску. Thomsett использует это как метафору, чтобы описать такую ситуацию в процессе переговоров, когда руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предложения по плану и бюджету. Дисциплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику — получается в точности «двойной плевок пустышкой». Идея заключается в том, чтобы запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать ещё одной вспышки раздражительности.
24) Испанская инквизиция — такое случается, когда менеджер проекта приходит на совещание руководителей высшего уровня, совершенно не представляя, что от него потребуют дать «немедленную оценку» безнадёжному проекту. Представьте себе комнату, полную ворчливых вице-президентов, которые пристально смотрят на вас, в то время как директор грозным тоном спрашивает: «Итак, Смит, когда же, по вашему мнению, мы получим эту систему? Я уже доложил всему руководству, что она будет готова к середине марта — вы же не собираетесь подвести меня, не так ли?» Если у вас хватит смелости возразить, что более реальный срок — середина ноября, тогда дюжина инквизиторов обрушится на вас с вопросами относительно вашего интеллекта, полномочий, лояльности и, возможно, даже религиозных убеждений.
25) Игра на понижение — по мере роста тенденции к использованию аутсорсинга во многих организациях такая игра становится все более распространённой; она также часто имеет место в ситуации, когда организация-разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организации-клиента. Эта игра достаточно очевидна: заказчик (или, в некоторых случаях, представитель службы маркетинга организации-разработчика) говорит менеджеру проекта, что один из других претендентов на проект предложил более короткий срок разработки и/или более скромный бюджет. Это вынуждает менеджера проекта не только ответить на вызов конкурента (который может быть вполне реальным, а может и нет), но и превзойти его, чтобы повысить свои шансы на заключение контракта. Одним из вариантов такой игры является случай, когда клиент даёт понять, что он не исключает возможность, что проект вообще не состоится; при этом организация-разработчик, которая во что бы то ни стало стремится заполучить этот проект (возможно, потому, что он служит карьерным целям вице-президента по информационным технологиям), постарается выдвинуть такие заманчивые для клиента предложения, чтобы наверняка гарантировать их принятие. Разумеется, это означает, что, как правило, один или более членов IT-иерархии знают , что эти предложения чрезмерно оптимистичны или просто явно лживы. Такие действия, в свою очередь, ведут к описанным ниже играм «Месть» и «Китайская пытка водой».
26) Месть — эту игру иногда затевает против своего руководства менеджер проекта: хотя он с самого начала знает, что предложения по срокам и бюджету нереалистичны, он нарочно соглашается с ними, полагая, что к тому моменту времени, когда их нереалистичность станет, наконец, очевидной для всех (например, за неделю до окончания проекта), клиент уже не сможет ничего изменить. Однако эта игра достаточно опасна, поскольку клиент может задуматься, стоит ли ему так рисковать своими деньгами. Если организация-разработчик уже заработала не слишком хорошую репутацию предыдущими аналогичными проектами, клиент может вообще отказаться от проекта и списать свои расходы в убыток. Но все же имеется вероятность, что отказаться от безнадёжного проекта сразу же не удастся, поскольку он обычно связан с целями бизнеса и политическими реалиями, которые невозможно обойти. Тем не менее, это не помешает заказчику найти способ отомстить за ту игру, которую с ним сыграли, и наиболее очевидной формой такой мести будет увольнение менеджера проекта. Точно так же его может подставить собственное руководство (которое в первую очередь виновато в нереальных условиях безнадёжного проекта), чтобы списать на него свою вину. Все могут подумать, что виной всему является некомпетентность менеджера проекта; наймут другого менеджера, примут (или нет) более реалистичные сроки и бюджет, и проект продолжится. Тем временем, разумеется, никто и не подумает ослабить пресс сверхурочной работы, который давит на участников проектной команды.
27) Китайская пытка водой — в отличие от предыдущей игры ва-банк, связанной с высоким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству маленькими порциями. Вообразите, например, такую ситуацию, когда разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев; по его мнению, при помощи сверхурочной работы и разного рода чудес проект можно попытаться закончить за 6 месяцев, однако руководство настаивает на 4-х месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек» — например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда — 5 или 7) ; отсюда, по его мнению, следует, что срок разработки заключительной версии системы также может быть отодвинут на 14-20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точка также окажется сдвинута на день (что означает общую задержку в два дня в течение двух недель), менеджер вновь повторит свои аргументы. Кап, кап, кап; это похоже на китайскую пытку водой — одной единственной плохой новости недостаточно, чтобы сразить вас, но все вместе могут оказаться роковыми.
28) Туманы и миражи — горе тому несчастному менеджеру проекта, вице-президент которого нанял консультанта по метрикам с моделью оценки, в которой никто ничего не понимает. Метрики ПО в конечном счёте представляют собой статистику, а модели оценки основываются, как правило, на сложных математических зависимостях. Когда они попадают в руки человека неопытного, наивного или преследующего определённые политические цели, эти средства могут быть использованы для «доказательства» корректности любой произвольной оценки. Все это вдвойне опасно, если источником этих метрик является поставщик, пытающийся доказать, что безнадёжный проект преуспеет благодаря фантастической производительности его CASE-средств, средств визуального программирования или новейшей методологии разработки ПО.
29) Спрятанное качество — это одна из наиболее хитрых игр, в ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. На самом деле все очень просто: как менеджер проекта, я могу предоставить пользователю бесконечно большое количество программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий, однако, суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) — это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчёт длительную перспективу: «Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кардинально измениться, да и я сам, в любом случае, буду другим. Что меня действительно беспокоит — это чтобы система была готова через три месяца и работала после этого 12 месяцев». Если политика оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнаружить IT-менеджеров и менеджера проекта, готовых согласиться с такой позицией; гораздо менее вероятно, чтобы с ней могли соглашаться технические специалисты. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которую я описал в [9]; в худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.
3.4 Стратегии переговоров
Что следует предпринять, если вы оказались втянуты в одну из описанных выше политических игр? Это в равной степени важно, даже если вы не являетесь их непосредственным участником, а наблюдаете со стороны — например, в качестве технического специалиста-участника проектной команды —
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Упомянутые выше динамические модели систем как раз отражают сущность этих нелинейных и нестационарных зависимостей; их характер является, к тому же, причиной использования различных коммерческих средств оценки, описанных выше. Следует отметить, что математической основой этих динамических моделей являются, как правило, нелинейные дифференциальные уравнения, в которых большинство из нас не слишком хорошо разбирается. Аналогично, коммерческие средства оценки выполняют сложные расчёты с учётом множества параметров; попытка сделать такую работу на интуитивном уровне, основываясь только на своём замечательном чутьё, приведёт, скорее всего, к грубым ошибкам.
К сожалению, именно в таком положении оказывается большинство менеджеров безнадёжных проектов. Отчасти это объясняется самой природой переговорного процесса (напоминающего игру под названием «Испанская инквизиция», которая будет обсуждаться ниже) ; однако, причиной может быть отсутствие адекватных средств оценки и соответствующего опыта во многих организациях. Если этой проблемой ранее не занимались, то тем более бесполезно пытаться решать её во время безнадёжного проекта. Если в организации привыкли к торопливости и небрежности в количественной оценке проектов, то менеджеру безнадёжного проекта вряд ли удастся выбить 10.000$ на приобретение достаточно сложного средства оценки.
Итак, что же делать в такой ситуации менеджеру? В крайнем случае, менеджеру остаётся осознать тщетность усилий и отреагировать соответственно; такая ситуация будет детально обсуждаться ниже в подразд. 3.5. Однако, в менее сложной ситуации существуют два возможных варианта действий:
18) Если требования пользователей или высшего руководства включают изменение одной из переменных проекта в пределах 10%, его можно компенсировать пропорциональным изменением одной из остальных переменных. Так, например, если руководство хочет сократить срок разработки на 10%, следует увеличить на 10% состав проектной команды. Вряд ли это будет точной компенсацией, но достаточно хорошо в первом приближении, и, как правило, это все, что вам удастся сделать в процессе переговоров.
19) Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным. Так, предположим, что руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6. Вместо того, чтобы удваивать состав проектной команды, менеджеру следует увеличить его в 4 раза — или увеличить в 4 раза бюджет, чтобы нанять суперпрограммистов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной модели оценки невозможно определить, насколько эта грубая эвристика будет соответствовать конкретной ситуации, но во всяком случае это лучше, чем оказаться в ловушке или придерживаться линейной зависимости между временем и людьми. К сожалению, «квадратичный» вариант достаточно трудно отстоять, и, скорее всего, «наглые» требования менеджера проекта будут отвергнуты, однако в случае хотя бы минимальной удачи менеджер все равно может оказаться в лучшем положении, чем при «линейном» варианте.
3.3 Переговорные игры
Переговоры — это игра , она имеет место во всех софтверных проектах. Переговоры в безнадёжных проектах характерны тем, что ставки гораздо выше, эмоции перехлёстывают через край, а запросы противоположной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой «запас прочности». В обычном проекте, например, самый очевидный запас прочности — это сверхурочное время. Даже если менеджер проекта оказался вынужден принять под давлением жёсткий график и урезанный бюджет, успеха все равно можно будет добиться, уговорив проектную команду работать сверхурочно от 10 до 20 часов в неделю в течение нескольких заключительных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, поскольку программисты ничего не получают за сверхурочную работу, поэтому менеджер в конце проекта выглядит героем.
Однако, в безнадёжном проекте небольшого количества сверхурочного времени обычно явно недостаточно, чтобы достичь тех впечатляющих результатов, которые требует руководство. Кроме того, пользователи и высшее руководство не столь наивны — они знают , что может потребоваться сверхурочная работа, и учитывают её в своих собственных оценках графика выполнения проекта — лишая таким образом менеджера возможности использовать этот свободный ресурс. Правда, менеджеры-ветераны подобных переговоров должны иметь запасные карты в рукаве, которые могут пойти в ход в начале переговоров.
В самом плохом положении находится неопытный менеджер; в худшем случае он даже не представляет, что его последний успех мог быть достигнут только благодаря тому, что проектная команда добровольно согласилась на большую сверхурочную работу, чтобы уложиться в сжатые до безобразия сроки. В свою очередь, такой смехотворный план мог быть навязан проектной команде именно из-за неопытности менеджера в области проектных оценок и переговоров.
Консультант в области менеджмента Rob Thomsett в своей замечательной статье [8] определил наиболее общие варианты переговорных игр; наиболее распространённые из них приведены ниже:
20) Удвой и добавь ещё — эта уловка используется в проектах, начиная с египетских пирамид, если не раньше. Используйте любые методы оценки, оказавшиеся под рукой, затем полученную «разумную» оценку удвойте и для большей надёжности добавьте ещё три месяца (или три недели, или три года, в зависимости от масштаба проекта). Главная проблема такой стратегии заключается в том, что она прямиком ведёт к самому жёсткому ограничению, связанному с безнадёжными проектами: сжатым срокам.
21) Обратное удвоение — как было отмечено ранее, руководство может быть вполне осведомлено о попытках менеджеров проектов «раздуть» свои оценки, используя предыдущую стратегию. Одна из причин такой проницательности заключается в том, что высшее руководство во многих организациях — это бывшие менеджеры проектов в области информационных технологий, поэтому они хорошо разбираются в таких играх. В результате они берут те начальные оценки, которые им дают менеджеры проектов, и автоматически урезают их наполовину. Беда несчастному неопытному менеджеру, который даже не знает, что его подозревают в удвоении своих начальных оценок!
22) «Угадай число, которое я задумал» — такую игру я освоил в одном из моих первых проектов, когда был ещё молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются чётко её сформулировать . Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много — попробуй угадать ещё раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придётся отвечать за неё.
23) Двойной плевок пустышкой — «пустышкой» (dummy) на австралийском сленге называется детская соска, и «выплюнуть пустышку» означает, что ребёнок настолько расстроен и рассержен, что выплёвывает свою соску. Thomsett использует это как метафору, чтобы описать такую ситуацию в процессе переговоров, когда руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предложения по плану и бюджету. Дисциплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику — получается в точности «двойной плевок пустышкой». Идея заключается в том, чтобы запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать ещё одной вспышки раздражительности.
24) Испанская инквизиция — такое случается, когда менеджер проекта приходит на совещание руководителей высшего уровня, совершенно не представляя, что от него потребуют дать «немедленную оценку» безнадёжному проекту. Представьте себе комнату, полную ворчливых вице-президентов, которые пристально смотрят на вас, в то время как директор грозным тоном спрашивает: «Итак, Смит, когда же, по вашему мнению, мы получим эту систему? Я уже доложил всему руководству, что она будет готова к середине марта — вы же не собираетесь подвести меня, не так ли?» Если у вас хватит смелости возразить, что более реальный срок — середина ноября, тогда дюжина инквизиторов обрушится на вас с вопросами относительно вашего интеллекта, полномочий, лояльности и, возможно, даже религиозных убеждений.
25) Игра на понижение — по мере роста тенденции к использованию аутсорсинга во многих организациях такая игра становится все более распространённой; она также часто имеет место в ситуации, когда организация-разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организации-клиента. Эта игра достаточно очевидна: заказчик (или, в некоторых случаях, представитель службы маркетинга организации-разработчика) говорит менеджеру проекта, что один из других претендентов на проект предложил более короткий срок разработки и/или более скромный бюджет. Это вынуждает менеджера проекта не только ответить на вызов конкурента (который может быть вполне реальным, а может и нет), но и превзойти его, чтобы повысить свои шансы на заключение контракта. Одним из вариантов такой игры является случай, когда клиент даёт понять, что он не исключает возможность, что проект вообще не состоится; при этом организация-разработчик, которая во что бы то ни стало стремится заполучить этот проект (возможно, потому, что он служит карьерным целям вице-президента по информационным технологиям), постарается выдвинуть такие заманчивые для клиента предложения, чтобы наверняка гарантировать их принятие. Разумеется, это означает, что, как правило, один или более членов IT-иерархии знают , что эти предложения чрезмерно оптимистичны или просто явно лживы. Такие действия, в свою очередь, ведут к описанным ниже играм «Месть» и «Китайская пытка водой».
26) Месть — эту игру иногда затевает против своего руководства менеджер проекта: хотя он с самого начала знает, что предложения по срокам и бюджету нереалистичны, он нарочно соглашается с ними, полагая, что к тому моменту времени, когда их нереалистичность станет, наконец, очевидной для всех (например, за неделю до окончания проекта), клиент уже не сможет ничего изменить. Однако эта игра достаточно опасна, поскольку клиент может задуматься, стоит ли ему так рисковать своими деньгами. Если организация-разработчик уже заработала не слишком хорошую репутацию предыдущими аналогичными проектами, клиент может вообще отказаться от проекта и списать свои расходы в убыток. Но все же имеется вероятность, что отказаться от безнадёжного проекта сразу же не удастся, поскольку он обычно связан с целями бизнеса и политическими реалиями, которые невозможно обойти. Тем не менее, это не помешает заказчику найти способ отомстить за ту игру, которую с ним сыграли, и наиболее очевидной формой такой мести будет увольнение менеджера проекта. Точно так же его может подставить собственное руководство (которое в первую очередь виновато в нереальных условиях безнадёжного проекта), чтобы списать на него свою вину. Все могут подумать, что виной всему является некомпетентность менеджера проекта; наймут другого менеджера, примут (или нет) более реалистичные сроки и бюджет, и проект продолжится. Тем временем, разумеется, никто и не подумает ослабить пресс сверхурочной работы, который давит на участников проектной команды.
27) Китайская пытка водой — в отличие от предыдущей игры ва-банк, связанной с высоким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству маленькими порциями. Вообразите, например, такую ситуацию, когда разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев; по его мнению, при помощи сверхурочной работы и разного рода чудес проект можно попытаться закончить за 6 месяцев, однако руководство настаивает на 4-х месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек» — например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда — 5 или 7) ; отсюда, по его мнению, следует, что срок разработки заключительной версии системы также может быть отодвинут на 14-20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точка также окажется сдвинута на день (что означает общую задержку в два дня в течение двух недель), менеджер вновь повторит свои аргументы. Кап, кап, кап; это похоже на китайскую пытку водой — одной единственной плохой новости недостаточно, чтобы сразить вас, но все вместе могут оказаться роковыми.
28) Туманы и миражи — горе тому несчастному менеджеру проекта, вице-президент которого нанял консультанта по метрикам с моделью оценки, в которой никто ничего не понимает. Метрики ПО в конечном счёте представляют собой статистику, а модели оценки основываются, как правило, на сложных математических зависимостях. Когда они попадают в руки человека неопытного, наивного или преследующего определённые политические цели, эти средства могут быть использованы для «доказательства» корректности любой произвольной оценки. Все это вдвойне опасно, если источником этих метрик является поставщик, пытающийся доказать, что безнадёжный проект преуспеет благодаря фантастической производительности его CASE-средств, средств визуального программирования или новейшей методологии разработки ПО.
29) Спрятанное качество — это одна из наиболее хитрых игр, в ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. На самом деле все очень просто: как менеджер проекта, я могу предоставить пользователю бесконечно большое количество программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий, однако, суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) — это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчёт длительную перспективу: «Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кардинально измениться, да и я сам, в любом случае, буду другим. Что меня действительно беспокоит — это чтобы система была готова через три месяца и работала после этого 12 месяцев». Если политика оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнаружить IT-менеджеров и менеджера проекта, готовых согласиться с такой позицией; гораздо менее вероятно, чтобы с ней могли соглашаться технические специалисты. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которую я описал в [9]; в худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.
3.4 Стратегии переговоров
Что следует предпринять, если вы оказались втянуты в одну из описанных выше политических игр? Это в равной степени важно, даже если вы не являетесь их непосредственным участником, а наблюдаете со стороны — например, в качестве технического специалиста-участника проектной команды —
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24