Политика, переговоры и решение проблем

Политика, переговоры и решение проблем

Область применения методов этой главы
Принципиальные переговоры
Что оценивается
Размер, объем работы, срок, функциональность
Размер проекта
М С Б
Стадия разработки
Ранняя-поздняя
Итеративный или последовательный стиль
Оба
Возможная точность
Филип Метцгер (Philip Metzger) много лет назад заметил, что технические специалисты хорошо составляют оценки, но плохо их защищают (Metzger 1981). У меня нет оснований полагать, что за прошедшие годы технические специалисты научились лучше защищать свои оценки. В этой главе описаны причины, по которым возникают трудности с принятием оценок, и методика, помогающая успешно вести переговоры по поводу оценок.
23.1. Особенности руководства.
Первая проблема в переговорах по оценкам обусловлена спецификой личности людей, участвующих в переговорах. Технические специалисты обычно склонны к интроверсии. Около 3/4 технических работников являются интровертами, в отличие от 1/3 всего населения (McConnell 2004b). Многие технические специалисты нормально ладят с другими людьми, но в области конфликтных социальных взаимодействий они не сильны.
В переговорах по поводу программных проектов обычно участвует технический персонал и администраторы или технический персонал и маркетологи. Джеральд Вайнберг (Gerald Weinberg) указывает, что маркетологи и администраторы обычно по крайней мере на 10 лет старше и занимают более высокие должности, чем технические специалисты. Кроме того, переговоры являются одним из основных аспектов их работы (Weinberg 1994). Другими словами, переговоры по поводу оценок ведутся между интровертами-«технарями» и опытными профессиональными переговорщиками.
С учетом этого обстоятельства становится понятно, почему технические специалисты относятся к переговорам примерно так же, как к удалению зубов без наркоза. Факторы, затрудняющие переговоры с руководящими работниками, вряд ли изменятся в обозримом времени. В табл. 23.1 перечислены некоторые из этих факторов.
1.
Администраторы всегда требуют то, что хотят получить.
2.
Администраторы всегда пытаются получить то, что хотят, если не вышло с первого раза.
3.
Администраторы склонны прощупывать почву до тех пор, пока не обнаружат ваше слабое место.
4.
Администраторы не всегда знают, что невозможно, но всегда знают, что было бы полезно для бизнеса, если бы было возможно.
5.
Администраторы настойчивы. Собственно, без этого они бы не стали администраторами.
6.
Администраторы будут уважать вас, если вы будете настойчивы. На самом деле они считают, что вы будете настойчивы только при крайней необходимости.
7.
Администраторы хотят, чтобы вы в своей работе руководствовались интересами организации.
8.
Администраторы стремятся исследовать как можно больше вариантов, чтобы добиться максимальной коммерческой эффективности.
9.
Администраторам известно о бизнесе, рынке и о компании много такого, что неизвестно вам. Их приоритеты проекта могут отличаться от ваших.
10. Администраторы всегда стремятся получить четкие прогнозы и обязательства на ранней стадии (действительно, это было бы крайне полезно для дела — если бы было возможно).
Таблица 23.1. Десять основных характеристик администраторов
1.
Администраторы всегда требуют то, что хотят получить.
2.
Администраторы всегда пытаются получить то, что хотят, если не вышло с первого раза.
3.
Администраторы склонны прощупывать почву до тех пор, пока не обнаружат ваше слабое место.
4.
Администраторы не всегда знают, что невозможно, но всегда знают, что было бы полезно для бизнеса, если бы было возможно.
5.
Администраторы настойчивы. Собственно, без этого они бы не стали администраторами.
6.
Администраторы будут уважать вас, если вы будете настойчивы. На самом деле они считают, что вы будете настойчивы только при крайней необходимости.
7.
Администраторы хотят, чтобы вы в своей работе руководствовались интересами организации.
8.
Администраторы стремятся исследовать как можно больше вариантов, чтобы добиться максимальной коммерческой эффективности.
9.
Администраторам известно о бизнесе, рынке и о компании много такого, что неизвестно вам. Их приоритеты проекта могут отличаться от ваших.
10.
Администраторы всегда стремятся получить четкие прогнозы и обязательства на ранней стадии (действительно, это было бы крайне полезно для дела — если бы было возможно).
Как правило, администраторы обладают этими характеристиками, потому что это полезно для организации. Не рассчитывайте, что эти характеристики когда-нибудь изменятся!.
СОВЕТ № 110 -.
Поймите, что администраторы настойчивы по своей природе и по должности, и планируйте обсуждение оценок соответствующим образом.
Возможно, переговоры по поводу оценок — одна из составляющих вашей работы, которая вам не нравится, но никто не обещал, что ваша работа будет на 100 % приятной. Я обнаружил, что простое осознание того факта, что я не люблю переговоры, помогает мне вести их более конструктивно.
23.2. Влияние политических факторов на оценки.
Реакция руководства на оценки программных проектов зависит от ряда факторов, не относящихся к технической стороне дела.
Внешние ограничения.
Довольно часто руководство беспокоится о важных внешних факторах, требующих выдать программный продукт к заданной дате или в пределах заданной стоимости. Может действовать внешний, жестко фиксированный предельный срок (например, сезон рождественских продаж, выставка и т. д.). Аналогично, стоимость проекта может ограничиваться условиями тендера; руководство считает, что компания не получит заказ, если выставленные требования будут достаточно высокими для покрытия издержек.
Факт существования внешних требований еще не означает, что эти требования могут быть выполнены. Тем не менее вы должны дать понять руководству, с которым имеете дело, что все требования поняты и вы относитесь к ним серьезно.
СОВЕТ № 111 -.
Учитывайте воздействие внешних факторов. Ваши собеседники должны видеть, что вы понимаете коммерческие требования и их важность.
Бюджет и даты.
Во многих компаниях даты выдачи проектов также зависят от квартального деления. Компании сообщают о своих затратах и доходах ежеквартально. Иногда бывает проще перенести проект на более позднюю дату, чем переносить более раннюю дату на предыдущий квартал. Если вы предложите назначить срок выдачи проекта на 15 июля, возможно, на вас будут давить с предложениями перенести его на 30 июня (то есть на второй квартал вместо третьего). Но если предложить в качестве даты выдачи 15 сентября, ближе к концу третьего квартала, может оказаться, что на эту дату руководство согласится скорее, чем на 15 июля, потому что у него будет меньше стимулов сдвигать выдачу на предыдущий квартал. Этот фактор действует еще сильнее на границах отчетных годов.
Переговоры по поводу оценок и обязательств.
В одних обстоятельствах переговоры уместны, в других — нет. Мы не ведем переговоры по поводу непреложных фактов (скажем, температуры поверхности Солнца или объема Великих Озер), а просто принимаем их как данность. Аналогично, оценка программного проекта является результатом аналитической деятельности и обсуждать ее нерационально. Однако рационально обсудить обязательства, связанные с оценкой. Обсуждение может выглядеть примерно так:.
Технический руководитель: По нашей оценке
проект займет от 5 до 7 месяцев. Впрочем, сейчас мы еще находимся в ранней части конуса неопределенности, поэтому оценка будет уточняться в ходе работы.
Администратор: От 5 до 7месяцев — слишком большой разброс. Нельзя ли просто использовать оценку в 5 месяцев?.
Технический руководитель: Мы должны различать оценки и обязательства. Оценку я изменить не могу, потому что она была получена в результате серьезных вычислений. Тем не менее моя группа может согласиться на срок в 5 месяцев, если мы все согласимся на подобный уровень риска.
Администратор: Ничего не понял. А в чем разница?.
Технический руководитель: Наш диапазон от 5 до 7 месяцев включает одно стандартное отклонение в каждую сторону от медианной оценки в 6 месяца. Это означает, что вероятность завершения за 7 месяцев равна 84 %. Наши оценки показывают, что вероятность соблюдения 5-месячных обязательств составляет всего 16 %.
Администратор: Нам нужна более чем 50 % уверенность в сроке, по которому заключаются обязательства, но 84 % — более консервативная оценка, чем нужно. Какой срок можно считать достоверным на 75 % ?.
Технический руководитель: Согласно нашим вычислениям, около 6,5 месяца.
Администратор: На нем и остановимся.
Технический руководитель: Договорились.
Многие технические специалисты считают, что подобный диалог вредит карьерному росту. По собственному опыту могу сказать, что все совсем наоборот. Если вы готовы пережить неприятные разговоры (и если при этом руководствуетесь интересами своей организации), в действительности это лишь способствует вашей карьере. Настоящий вред карьере приносит другое — принятие необоснованных, нереалистичных обязательств, которые не удается выполнить.
СОВЕТ № 112 -
-.
Обсуждайте обязательства, но не оценки.
Что делать, если ваша оценка не принята.
Разработчики и менеджеры иногда беспокоятся, что слишком высокая оценка приведет к отклонению проекта. Это нормально. Высшее руководство обладает и ответственностью, и правом решить, что проект экономически не оправдан. Когда технический персонал занижает оценку проекта, он скрывает от руководства важную информацию, необходимую для принятия эффективных решений, и фактически мешает ему принимать решения. В результате ресурсы компании отвлекаются с экономически оправданных проектов на экономически неоправданные. Хорошие проекты поддерживаются недостаточно, а плохие проекты получают излишнюю поддержку. Этот сценарий чрезвычайно вреден для дела и обычно плохо кончается для людей, добившихся принятия проектов, которые изначально принимать не следовало.
Ответственность технического персонала за обучение.
Если вы хотите гарантировать успех своих программных проектов, расскажите ответственным участникам, не связанным с технической стороной, об опасностях произвольного урезания оценок сроков и стоимости без соответствующего сокращения объема работы. Расскажите о конусе неопределенности, о различиях между оценками, целями и обязательствами. По собственному опыту могу сказать, что эти идеи отлично воспринимаются в контексте попыток действовать в интересах организации.
Расскажите ответственным участникам, не связанным с технической стороной проекта, о принципах эффективной оценки программных проектов.
Помимо обучения нетехнических участников проекта займитесь изучением основных принципов, приоритетов и слабых мест вашей отрасли — это поможет вести дискуссии по поводу оценок на конструктивном уровне.
23.3. Решение проблем и принципиальные переговоры.
В своей книге «Rapid Development» от 1996 года я охарактеризовал обсуждение оценок термином «переговоры». С течением времени я все меньше и меньше уверен в том, что переговоры являются наиболее конструктивным подходом к дискуссиям, возникающим вокруг оценок стоимости, срока и функциональности.
В переговорах участвуют стороны с конфликтующими интересами, а их целью является распределейие «пирога» между двумя и более сторонами. При антагонистических переговорах каждая сторона пытается захватить как можно большую часть, и любые приобретения одной стороны автоматически оборачиваются потерями для другой стороны. При совместных переговорах каждая сторона ищет способы увеличения «пирога», но в конечном счете «пирог» все равно делится.
В переговорах по поводу программного обеспечения делить нечего. В переговорах со специалистами по продажам, маркетингу или администрацией мы сидим за одним столом. Вопрос вовсе не ставится в виде «Мы выиграем, а они проиграли» — скорее, «мы все проигрываем» или «мы все выигрываем». Наши интересы совпадают. Мы либо закладываем основу для успеха программного проекта, который оборачивается успехом для всех, либо создаем условия для его неудачи, также всеобщей. Следовательно, обсуждения по поводу оценок программных проектов нельзя назвать переговорами в традиционном понимании.
Более правильной моделью для дискуссий между техническим персоналом, отделами продаж, маркетинга, администрацией и другими ответственными сторонами является совместное решение проблемы. Мы все работаем на общую цель, делимся своим опытом в разных областях и создаем решение, которое в конечном счете отвечает интересам бизнеса.
СОВЕТ № 114 -.
Относитесь к обсуждению оценок как к решению проблемы, а не как к переговорам. Поймите, что все ответственные участники проекта находятся на одной стороне. Либо все вместе проигрывают, либо все вместе выигрывают.
Осознав, что речь идет не о конфликте интересов, а о совместном решении проблем, мы, технические специалисты, конструктивно подходим к обсуждению целей, оценок и обязательств. Остается только направить других участников обсуждения на такой же конструктивный путь.
Переговоры как совместное решение проблем.
Даже если мы знаем, что речь идет о совместном решении проблем, те люди, с которыми мы обсуждаем оценку, могут решить, что они участвуют в традиционных переговорах. Существует много разных стратегий ведения переговоров. Одни стратегии основаны на силе переговорных позиций, устрашении, дружелюбии, стремлении добиться похвалы или заслужить расположение. Другие стратегии базируются на обмане и искусных психологических маневрах.
Поскольку процесс обсуждения оценок переходит между оценками, целями, обязательствами и планами, обсуждение невозможно четко разделить на «чистые» переговоры и «чистое» решение проблем. Обычно вам придется иметь дело с обоими элементами.
В числе хороших стратегий, заполняющих разрыв между переговорами и решением проблем, можно назвать метод принципиальных переговоров, описанный в книге «Getting to Yes» (Fisher and Ury 1991). Метод называется «переговорами», но его участники рассматриваются как лица, занимающиеся решением задач. Метод не зависит от переговорных приемов; кроме того, он объясняет, как реагировать на их применение другими сторонами. Метод основан на идее создания беспроигрышных альтернатив. Он достаточно хорошо работает, когда используется только вами, и еще лучше — если он используется также и другой стороной.
Стратегия состоит из четырех составляющих:.
• отделение людей от проблемы;.
• сосредоточение на интересах, а не позициях;.
• разработка вариантов, обеспечивающих взаимный выигрыш;.
• применение объективных критериев.
Все составляющие метода описываются в следующих секциях.
Отделение людей от проблемы.
В обсуждениях оценок задействованы, во-первых, люди, а во-вторых, интересы и позиции. Там, где возникает конфликт личных качеств (например, личных качеств технических работников и специалистов по маркетингу), дискуссия нередко заходит в тупик.
Прежде всего постарайтесь понять позицию другой стороны. Менеджеры часто становятся заложниками устарелой политики своей организации. В некоторых организациях принципы финансирования программных проектов оказываются несовместимыми с методами разработки программного обеспечения. Такие организации не разрешают менеджерам запрашивать финансирование только на то, чтобы разработать требования и планы и выработать хорошую оценку. Чтобы получить средства на осмысленную оценку, менеджер должен сначала добиться финансирования всего проекта. К моменту получения осмысленной оценки ему становится неудобно (и даже небезопасно для карьеры) возвращаться и запрашивать финансирование в реальном объеме. Люди, занимающие самые высокие посты в таких организациях, должны лучше понять принципы оценки программного обеспечения, чтобы ввести в действие практику финансирования, поддерживающую эффективную разработку программного обеспечения.
В дискуссиях такого рода считайте себя советником по оценкам программных проектов; это поможет избежать вхождения в роль противника. Старайтесь своевременно возвращать дискуссию к достижению целей, полезных для компании.
Также полезно убрать эмоции из предмета обсуждения. Иногда для этого проще всего дать собеседникам «выпустить пар». Не реагируйте эмоционально на эмоции собеседников; дайте им возможность высказаться. Скажите что-нибудь вроде: «Я вижу, что мы столкнулись с серьезными проблемами, и хочу убедиться в том, что я в полной мере понимаю позицию нашей компании. Что еще вы можете сказать о нашей ситуации?» Когда собеседники завершать объяснения, согласитесь со всем услышанным и снова выразите свое желание найти решение, подходящее для организации. Другие составляющие процесса принципиальных переговоров помогут вам сформулировать это решение.
СОВЕТ № 115 —-.
Нападайте на проблему, а не на людей.
Сосредоточение на интересах, а не позициях.
Предположим, вы продаете свою машину, чтобы купить новую лодку. Вы рассчитали, что для покупки нужной вам лодки потребуется $10 ООО. Потенциальный покупатель обращается к вам и предлагает $9000. Вы говорите: «Я ни при каких условиях не расстанусь с машиной менее чем за $10 000». Покупатель отвечает: «Я могу заплатить $9000, но это мой максимум».
Переговоры такого рода сосредоточены на позициях, а не на интересах. Позицией называются переговорные утверждения настолько узкие, что выигрыш одной стороны означает проигрыш другой.
Теперь, допустим, покупатель говорит: «Я действительно не могу заплатить выше $9000, но я слышал, что вы хотите купить новую лодку. По случайности я являюсь региональным дистрибьютором крупной компании, торгующей лодками. Я могу продать вам лодку на $2000 дешевле, чем любой другой продавец. Что вы теперь скажете на мое предложение?» На этот раз предложение выглядит весьма заманчиво — вы получите на $1000 больше, чем если бы покупатель просто согласился на исходную цену.
Интересы шире переговорных позиций; если вы направите свое внимание на них, перед вами откроется целый мир новых возможностей. Рассмотрим следующий сценарий:.
Администратор: Версия Giga-Blat 4.0 нам нужна через 6 месяцев.
Технический руководитель: Мы тщательно оценили проект. К сожалению, оценки показывают, что мы не сможем выдать его менее чем за 8 месяцев.
Администратор: Этого недостаточно. Программа действительно пужгса через 6 месяцев.
Технический руководитель: Нам действительно нужна вся заявленная функциональность? Если урезать достаточное количество функций, мы сможем завершить работу за 6 месяцев.
Администратор: Урезать функциональность нельзя. В этой версии мы и так сократили ее до минимума. Нам нужны все функции, и не позже чем через 6 месяцев.
Технический руководитель: Какой главный фактор определяет 6-месячный срок? Возмоэто, нам удастся найти взаимоприемлемое решение.
Администратор: Через 6 месяцев состоится ежегодная торговая выставка. Пропустив ее, мы лишимся возможности продемонстрировать программу многим важным клиентам. Фактически это задержит цикл продаж на целый год.
Технический руководитель: Я действительно не могу обещать выдать окончательную версию к торговой выставке. Но я могу поручиться, что бета-версия будет готова к выставке, а предоставленный мной специалист будет знать основные проблемы и сможет управлять программой так, что она не «упадет» во время выставки. Что вы на это скажете?.
Администратор: Если вы обещаете, что программа будет работать без сбоев, меня это устроит.
Технический руководитель: Договорились.
Важнейшее различие между типичными переговорами и решением проблем посредством обсуждения интересов состоит в том, что переговоры обычно «замораживаются» на позициях. Поворотным моментом в этом диалоге стал вопрос технического руководителя о главном факторе, определяющем 6-месячный срок. Диалог переключился со спора о позициях на попытки понять интересы компании и решить базовую проблему. Сосредоточившись на интересах, вы с большей вероятностью найдете взаимоприемлемое решение.
Разработка вариантов, обеспечивающих взаимный выигрыш.
Ваш сильнейший союзник при обсуждении оценок — не оценка, а ваше умение предлагать варианты планирования, о которых ничего не известно нетехническим участникам. Вы держите ключ от сейфа с техническими знаниями, и по этой причине ответственность за выдачу творческих решений ложится в большей степени па ваши плечи. Именно вы должны предложить полный спектр возможностей и компромиссов.
В табл. 23.2 перечислены некоторые варианты планирования, которые часто помогают выйти из тупика.
Таблица 23.2. Варианты планирования, которые часто помогают выйти из тупиковой ситуации
Варианты, относящиеся к функциональности
Перемещение части желательных функций в версию 2. Мало кому действительно необходимо получить сразу все, что они просили
Применение итеративного подхода. Выдавайте программу в версиях 0.2, 0.4, 0.6, 0.8 и 1.0, начиная с реализации важнейшей функциональности
Полное исключение некоторых возможностей. В первую очередь исключаются возможности, связанные с максимальными затратами
Использование «метода футболки» для первоочередной реализации функций, обладающих наибольшей коммерческой ценностью
Упрощенная реализация некоторых функций. Такие функции реализуются до определенной степени, но делаются менее изощренными
Ослабление подробных требований по каждой функции. Определите свою задачу как максимальное приближение к требованиям с использованием существующих компонентов
Построение конуса неопределенности, ориентированного на функциональность. Определите одни функции как «абсолютно обязательные», другие как «абсолютно лишние» и третьи как «возможные». Предложите план сужения функционального конуса неопределенности по мере продвижения проекта
Варианты, относящиеся к ресурсам
Увеличение численности разработчиков или тестеров, если проект еще находится на ранней стадии
Наем внештатного персонала, если проект еще находится на ранней стадии
Введение высокопроизводительного технического персонала (например, экспертов по предметной области или дополнительных ведущих разработчиков)
Увеличение административной поддержки
Повышение уровня поддержки разработчиков
Расширение участия конечных пользователей или клиентов. Включите в проект на полный рабочий день пользователя с правом принятия обязывающих решений по поводу функциональности продукта
Расширение участия руководства, позволяющее ускорить принятие решений.
Передача части работы другой группе (но помните о проблемах интеграции, которые при этом возникнут)
Выделение 100 % ресурсов на проект. Участники проекта не должны делить свое рабочее время между новым и старым проектом, или несколькими новыми проектами
Варианты, относящиеся к срокам
Составление «дорожной карты оценок» с изложением плана пересмотра и уточнения оценок
Использование диапазонных или грубых оценок, уточняемых по мере продвижения проекта
Поиск способов планирования для достижения определенных целей по срокам, стоимости или функциональности, по мере уточнения требований и планов
Задержка некоторых обязательств до завершения следующей фазы проекта (то есть работы, необходимой для сужения конуса неопределенности)
Выполнение одной-двух коротких итераций для калибровки производительности и последующее принятие обязательств на основании полученных данных
Главное — предотвратить перепалки типа «Я не могу это сделать» — «Можете».— «Нет, не могу». — «Можете!» — «Не могу!!!» Представьте набор вариантов и сосредоточьте обсуждение на них. Не включайте заведомо невозможные варианты в свой набор. Старайтесь не говорить «Нет, это невозможно»; вместо этого направьте дискуссию на то, что возможно. Чем больше вы представите вариантов, работающих на благо организации, тем проще вам будет показать, что вы находитесь на одной стороне с человеком, с которым решается проблема.
СОВЕТ № 116 -.
Выдайте как можно больше вариантов планирования, поддерживающих цели вашей организации.
И одно предупреждение: в атмосфере «мозгового штурма», возникающей в ходе свободной дискуссии при решении проблем, легко согласиться на решение, которое вам в тот момент кажется удачным. Однако на следующее утро идея выглядит уже не столь привлекательно. В этой ситуации действуют предупреждения, приведенные в разделе 4.8. Не принимайте жестких обязательств, пока у вас не будет достаточно времени для спокойного анализа их последствий.
СОВЕТ № 117 -.
В процессе совместного решения проблем не принимайте поспешных обязательств, основанных на импровизированных оценках.
Применение объективных критериев.
В нашем деле есть одна странность: если тщательно выверенная оценка значительно превышает желаемую, клиент или начальник часто попросту игнорирует ее (Jones 1994). Такое возможно даже в том случае, если оценка была получена в оценочной программе, или представлена внешним экспертом, или организация известна частыми превышениями своих оценок в прошлом. Подвергать сомнению оценку — абсолютно допустимо и даже полезно. Проигнорировать оценку и заменить ее своими домыслами — нет.
Когда принципиальные переговоры переходят в решение проблем, вы ищете «разумное соглашение, оцениваемое по каким-либо объективным стандартам». Вы можете спорить с собеседниками относительно того, какие объективные стандарты являются наиболее подходящими, но относитесь без предвзятости к предлагаемым им стандартам. Что еще важнее, не поддавайтесь давлению — только принципам. Чтобы поддержать дискуссию, основанную на принципах, необходимо определить, кто является компетентной стороной в каждом аспекте дискуссии.
Технический персонал и техническое руководство формирует оценку.
Вы лучше других понимаете техническую часть работы и создание оценок для нее. Следовательно, вы должны быть основным авторитетом в оценке.
Нетехнические ответственные стороны формирует цели.
Администраторы, специалисты по продажам и маркетингу вследствие своей позиции обычно лучше понимают потребности и приоритеты бизнеса. По этой причине они являются основными авторитетами по бизнес-целям.
Технический и нетехнический персонал совместно формируют обязательства.
Цели и оценки в конечном итоге сходятся в обязательствах. Если вам удастся достичь соглашения относительно того, что вы авторитетны в оценке, а другие стороны — в целях, большая часть дискуссии естественным образом сосредоточится на обязательствах. Определяющим принципом должно стать достижение соглашения относительно того, какие обязательства будут лучшими для организации. В этих дискуссиях необходимо учитывать следующие рекомендации.
• Не обсуждайте саму оценку. Объясните собеседникам, чем оценка отличается от обязательств. Постоянно направляйте дискуссию на достижение обязательств, отвечающих интересам организации.
• Настаивайте на том, что оценка должна быть подготовлена компетентной стороной. Самым компетентным оценщиком нередко оказываетесь вы;.
в других случаях им может быть независимая группа оценки. Такие группы эффективны, прежде всего, потому, что они не имеют субъективной заинтересованности ни в выдаче программы за кратчайшее возможное время, ни в том, чтобы избежать тяжелой работы. Если дискуссия зациклится на теме самой оценки, предложите передать оценку третьей стороне и согласитесь принять результат. Попросите другие стороны сделать то же самое.
• Вариация на эту тему — привлечение консультанта или внешнего эксперта для анализа сроков. Посторонний эксперт иногда вызывает больше доверия, чем знакомый. Некоторые организации также добивались успеха, используя оценочные программы. После того как технический персонал откалибрует программу для конкретного проекта, они могли легко и объективно проанализировать последствия различных решений.
• Ссылайтесь на стандартизированную процедуру оценки вашей организации. Предварительное принятие стандартизированной процедуры оценки часто позволяет избежать дискуссий по поводу того, кто должен создавать оценку. Вы можете просто сказать: «Наша процедура не позволяет обсуждать саму оценку. Давайте лучше поговорим об основных предположениях оценки (таких, как размер проекта) и о том уровне риска, при котором для организации будет оправдано принятие обязательств по данному проекту».
• Не поддавайтесь эмоциям. Люди обладают разной восприимчивостью к давлению, но если ваши клиенты, менеджеры, специалисты по маркетингу и другие стороны хотят, чтобы вы приняли на себя невыполнимые обязательства, на мой взгляд, лучше всего вежливо и твердо отстаивать свои убеждения. Лучше задраить люки и пережить бурю, связанную с неприятными оценками, на ранней стадии проекта, чем ураган нарушений сроков и перерасхода бюджета.
В действительности никто не выигрывает от принятия заведомо невыполнимых целей, хотя некоторым людям кажется иначе. Отстаивая решения, соответствующие реальным деловым потребностям вашего начальства и клиентов, вы лишь повышаете свою репутацию. Обеспечьте предсказуемость и помогите вашей организации соблюдать принятые обязательства.
СОВЕТ № 118 -.
Чтобы выйти из тупика, возникшего в дискуссии, почаще возвращайтесь к вопросу: «Что будет.
лучше для нашей организации?»

Популярные статьи

Свежие статьи