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

16.07.12

Управление проектом

Статья является продолжением публикации "Безнадежные проекты: виды и причины" и посвящена переговорам во время ведения безнадежного проекта, как они описаны в книге Эдварда Йордана «Путь камикадзе: смертельный марш».

Эпиграф:

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) Вы наживете врагов даже в случае успешного исхода проекта.

 

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3050    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4149    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3462    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3344    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15092    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6190    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5265    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5823    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. pro-rok 296 16.09.13 13:34 Сейчас в теме
Спасибо за статью. Теперь я знаю как называются игры в которые меня втягивали заказчики :). Не очень понравилось когда автор описывает спихивание ответственности на другого, считаю это не очень хорошим жестом, что бы не случилось виноваты обоя и менеджер и руководитель, и надо это озвучивать с самого начала.
Оставьте свое сообщение