Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард

Упомянутые выше динамические модели систем как раз отражают сущность этих нелинейных и нестационарных зависимостей; их характер является, к тому же, причиной использования различных коммерческих средств оценки, описанных выше. Следует отметить, что математической основой этих динамических моделей являются, как правило, нелинейные дифференциальные уравнения, в которых большинство из нас не слишком хорошо разбирается. Аналогично, коммерческие средства оценки выполняют сложные расчёты с учётом множества параметров; попытка сделать такую работу на интуитивном уровне, основываясь только на своём замечательном чутьё, приведёт, скорее всего, к грубым ошибкам.

К сожалению, именно в таком положении оказывается большинство менеджеров безнадёжных проектов. Отчасти это объясняется самой природой переговорного процесса (напоминающего игру под названием «Испанская инквизиция», которая будет обсуждаться ниже) ; однако, причиной может быть отсутствие адекватных средств оценки и соответствующего опыта во многих организациях. Если этой проблемой ранее не занимались, то тем более бесполезно пытаться решать её во время безнадёжного проекта. Если в организации привыкли к торопливости и небрежности в количественной оценке проектов, то менеджеру безнадёжного проекта вряд ли удастся выбить 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 использует это как метафору, чтобы описать такую ситуацию в процессе переговоров, когда руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предложения по плану и бюджету. Дисциплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику – получается в точности «двойной плевок пустышкой». Идея заключается в том, чтобы запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать ещё одной вспышки раздражительности.