Безнадежные проекты 2: переговоры

Эпиграф:

bash.im #417238

xxx: Когда менеджер проекта очень напуган своим начальником, его сроки сильно сжимаются

 

ГЛАВА 3. ПЕРЕГОВОРЫ

 

С места в карьер Йордан заявляет: «Если вы являетесь менеджером безнадёжного проекта, то очень легко предсказать результат переговоров относительно бюджета, срока и ресурсов: вы проиграете.» В самом начале проекта заказчик не слишком настроен выслушивать контрпредложения, а исполнитель заинтересован выделиться на фоне конкурентов низкими ценами и сроками. Для 1С подобная ситуация встречается сплошь и рядом — обилие игроков вынуждает сознательно занижать потребное количество ресурсов, ибо если не занизишь ты — занизит конкурент и перехватит выгодный заказ. Иногда, следует признать, сроки занижаются и в расчете на то, что, купившись на низкую цену и начав внедрение, заказчик уже не откажется от завершения и потери вложенных средств.

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

 

3.1 НОРМАЛЬНЫЕ ПЕРЕГОВОРЫ

 

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

Далее  следуют названия некоторых методов оценки проектов. Чтобы не отвлекаться от основной темы, приведу здесь только ссылки на маловразумительную статью на Инфостарте: Сравнение методов оценки создания ПО и на гораздо более информативную статью Разработка ПО: оценка результата.

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

1) Низкий входной порог, как следствие — низкую в массе своей квалификацию персонала.

2)  Возможность в работе опираться на типовые конфигурации, то есть разработка не «с нуля».

3) Особенности различных систем работы (франчи, фикси, фри, аутсорсеры).

4) Как правило, специалисты 1С гораздо лучше знают предметную область, в сравнении с разработчиками на других языках. Это подразумевает более быстрое осознание того, что необходимо конечному пользователю — а также более полное удовлетворение его потребностей.

 

3.2 ДОПУСТИМЫЕ КОМПРОМИССЫ

 

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

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

 

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

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

2) Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным. Так, предположим, что руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6. Вместо того, чтобы удваивать состав проектной команды, менеджеру следует увеличить егов 4 раза – или увеличить в 4 раза бюджет, чтобы нанять суперпрограммистов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной модели оценки невозможно определить, насколько эта грубая эвристика будет соответствовать конкретной ситуации, но во всяком случае это лучше, чем оказаться в ловушке или придерживаться линейной зависимости между временем и людьми. К сожалению, «квадратичный» вариант достаточно трудно отстоять, и, скорее всего, «наглые» требования менеджера проекта будут отвергнуты, однако в случае хотя бы минимальной удачи менеджер все равно может оказаться в лучшем положении, чем при «линейном» варианте.»

 

 

3.3 ПЕРЕГОВОРНЫЕ ИГРЫ

 

Следует сразу же оговориться, что автор данной классификации – не сам Эдвард Йордон, а консультант в области менеджмента Rob Thomsett (вот только давайте не будем вспоминать анекдот о перепеве Карузо Рабиновичем; впрочем, желающие приникнуть к первоисточнику могут прочитать англоязычный оригинал).

 

Далее приводятся приемы переговоров между некими двумя силами – назовем их, как в оригинале, Руководителем и Менеджером; хотя для случая 1С это могут быть и Менеджер и Программист, и Программист и Заказчик. Общее тут то, что один из них – в нашем случае Руководитель – заинтересован в скорейшем и наидешевейшем выполнении проекта, а второй  — Менеджер – желает выбить для проекта все наличные свободные ресурсы.

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

 

Удвой и добавь ещё – игра, направленная на увеличение ресурсов проекта. Менеджер прикидывает примерные сроки проекта, увеличивает их в два раза и дополнительно добавляет 15-25% от первоначальной цифры. Меры противодействия – см. следующий пункт.

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

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

«Угадай число, которое я задумал» – представим себе: менеджер называет свой вариант сроков проекта, руководитель качает головой и говорит «Нет»; но при этом он не называет свой вариант. Менеджер понимает это, как сигнал к пересмотру условий и предлагает уже новый вариант, после чего история повторяется. Наконец раза с n-го менеджер угадывает задуманный руководителем с самого начала вариант; однако теперь, раз вариант озвучил менеджер, он и несет за него ответственность.

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

Испанская инквизиция – тут действо групповое. Авторитетный консилиум руководителей подвергает менеджера допросу с пристрастием, выпытывая, почему его предполагаемые сроки расходятся с нужными.

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

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

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

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

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

 

3.4 СТРАТЕГИИ ПЕРЕГОВОРОВ

 

«Политические игры – это нечто такое, что следует принять как неизбежное зло, и мы должны уметь наилучшим образом справляться с ними.»

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

Конечно, руководство всегда предпочитает твердые оценки. Это позволяет им не волноваться больше о вопросах, связанных с проектом, поскольку козел отпущения уже найден. Йордон, ссылаясь на Jim McCarthy, советует менеджеру встретить подобные проблемы с открытым забралом, защищая свои интересы и интересы команды. Лучше всего, очевидно, делать это в самом начале работы, как только проблемы начинают приобретать реальные очертания. Если же вы являетесь младшим программистом в команде, подобные политические игры, скорее всего, являются признаками того, что ваш менеджер «(а) не уверен ни в одной из своих оценок, (б) у него не хватает твёрдости характера, чтобы постоять за себя и за свою команду и (в) он оказался в ситуации, когда почти все ключевые решения принимаются людьми, не имеющими непосредственного отношения к проекту. Это говорит о том, что проект скорее всего провалится, и пока вы ещё не слишком в него втянулись, может быть, лучше поискать себе пастбище позеленее.»

 

3.5 ЧТО ДЕЛАТЬ В СЛУЧАЕ ПРОВАЛА ПЕРЕГОВОРОВ

 

Речь пойдет о случае, когда менеджер на 146% уверен в том, что выделенных ресурсов недостаточно и сроки сдачи проекта будут провалены.

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

Альтернативой выступает вариант, когда менеджер просто плюет на все запреты и делает то, что считает нужным: «Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же.» При этом нужно учитывать два обстоятельства:

1) Вас будут провоцировать на увольнение. Нужно быть морально готовым к такому исходу событий.

2) Вы наживете врагов даже в случае успешного исхода проекта.

 

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