Пользовательский поиск

Книга Вальсируя с медведями. Содержание - Глава 11 Возвращение к основам

Кол-во голосов: 0

Обязательства и цели

Предположим, что диаграмма риска для вашего проекта показывает N в марте, а готовность с вероятностью 75% – в сентябре. На этой основе вы можете предпочесть убедить участников проекта получить продукт в сентябре. Сентябрь – разумный срок для обязательств, но совсем не идеальная цель для вдохновения членов команды проекта. Никто не хочет работать ради цели, имеющей 75%-ную вероятность, то есть с очень низкой эластичностью. Аналогично, N – также неудачная цель для проекта, поскольку никто не хочет работать ради цели, имеющей вероятность 0%, все мы слишком большую часть жизни тратим на бесплодные усилия. Наилучшим решением является установление в качестве цели эластичной даты сдачи проекта где-то между N и установленным сроком сдачи.

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

График = Цель = N действительно дурацкое уравнение

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

График > Цель > N более разумно

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

ТРЛ: Мой отец – математик, профессор на пенсии. Однажды он разворчался на меня по поводу всех проектов по разработке программного обеспечения, которые выполнялись с тем или иным опозданием, что относится почти к 100% проектов. «Почему так?» – вопрошал он.

Я ответил: «Видишь ли, у проекта есть всего два возможных варианта: своевременное выполнение и запаздывание. Полагаю, что перевес в пользу запаздывания, за исключением нескольких весьма примечательных случаев».

«Вариантов не два, Тим, – ответил он. – Есть и третий – досрочная готовность».

Это заставило меня задуматься. Я все время бывал в компаниях, для которых опережение графика совершенно немыслимо. Менеджера, который завершил бы проект раньше срока, обвинили бы в недобросовестном манипулировании графиком и, возможно, изгнали бы с позором.

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

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

Компромиссы неопределенности

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

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

Вальсируя с медведями - pic_13a.jpg

Дата теперь фиксирована, и неопределенность полностью относится к тому, что именно будут сдавать в этот день. Если ни один риск не наступит, могут быть сданы все версии от 1 до 24 (представленные как В24). Поскольку шансы избежать все риски крайне малы, это нанопроцентная функциональность – не то, чтобы невозможно, но исключительно неправдоподобно. Если судить по площади под кривой слева от В21, вероятность сдать все версии от 1 до 21 становится примерно 50%-ной к этой дате. Если участники проекта непреклонны в том, что для них не подойдет ничего, что будет меньше, чем В22, то диаграмма показывает, что вероятность предоставить им то, что они хотят, едва достигает 30%. Опять же, хотя это может оказаться неприятной новостью, скрывать ее – лишь отложить (и усугубить) день окончательной расплаты.

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

Во-вторых, берегитесь проекта, который представлен как имеющий фиксированный срок сдачи, но на самом деле его не имеет:

ТДМ: Я консультировал в штате Нью-Йорк проект с «жестким, фиксированным сроком сдачи». Продукт должен был быть во что бы то ни стало поставлен к концу второго квартала, никакие извинительные причины не принимались. Но он не был сдан в срок. На самом деле его сдали с опозданием больше чем на 18 месяцев. Оглядываясь назад, я не могу не удивляться, к чему были все эти песни и пляски по поводу «жесткого, фиксированного срока сдачи», поскольку срок с очевидностью не был ни жестким, ни фиксированным.

Это был тот редкий случай, когда у меня были столь близкие отношения с заказчиками, что я мог просто задать этот неудобный вопрос и получить на него прямой ответ. Так я и сделал. И мне рассказали за пивом, что больше всего их беспокоило, чтобы затраты не вышли из-под контроля. Назначенный изначально срок не имел принципиального значения, просто они рассчитывали, что за это время на проект будет потрачено ограниченное количество денег. Когда время вышло, они смогли убедиться, что команда разработчиков оправдывает затраты, поэтому и было дано согласие на пересмотр графика.

Некоторые проекты с фиксированным сроком действительно необходимо выполнить вовремя (например, ваша компания выиграла контракт на поставку программного обеспечения для CNN, чтобы использовать его в день выборов). В других проектах с фиксированным сроком, вроде описанного выше, дата сдачи назначена произвольно и не имеет ничего общего с реальными потребностями. В любом из этих случаев вам разумно ответить строго пошаговой разработкой проекта. Такая разработка требует определенных затрат, причем во втором случае они будут в основном напрасными.

Пошаговая разработка не принесет вам особой пользы, если весьма вероятно, что даже первая версия не будет готова к фиксированной дате:

Вальсируя с медведями - pic_13b.jpg

Здесь изображен проект, который с вероятностью не менее 60% не сможет предъявить к обещанному сроку даже первую работающую версию.

Замечание по поводу обнародования перечня рисков

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

17
© 2012-2016 Электронная библиотека booklot.ru