Система обеспечения качества информационных систем. Формирование требований проекта. Оценка трудоемкости

1.

Формирование требований проекта.
Оценка трудоемкости проекта и
потребности в ресурсах.
Диаграммы Гантта. Методы CPM и
PERT. Сетевой график
Лекция 4 (2 часть)
Тема 1.2.
Система обеспечения качества
информационных систем

2.

Первое, что начинает делать менеджер, –
начинает работать с содержанием.

3.

• Содержание в уставе дано очень кратко, без
подробностей – только суть. Например, мы
строим 12-этажный дом определенной
площади. И больше никаких подробностей.
Но когда мы приступаем к реализации
проекта, этого описания из устава
оказывается недостаточно.

4.

Первый шаг алгоритма – работа с
содержанием
• Вопрос «Что делать?» первый, потому что
пока мы не понимаем, что именно делать, мы
не понимаем, сколько времени это займет, и
сколько это будет стоить.
• Этот этап состоит из трех шагов – собрать
требования; сформировать концепцию и
сделать иерархическую структуру.

5.

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

6.

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

7.

Третий шаг – формирование
иерархической структуры работ
• Третий шаг – грибы структурировать,
разобрать на кучки: одна для засолки, другая
для сушки, третья – на жарку. Когда вы
структурируете грибы – это аналог
формирования иерархической структуры
работ (ИСР).

8.

Сбор требований
• Откуда брать требования?
• В первую очередь, информацию вы получаете
от заказчика и от пользователей (если это
возможно). Кроме того, есть нормативные
документы – законы, ГОСТы, СНиПы, из
которых тоже можно брать требования.
Еще один источник – исполнители, ваша
команда.

9.

Как собирать требования?
• Совещание/интервью
• Интервью - лучший метод сбора требовани. Этот способ
предполагает, что вы придете и лично поговорите с
заказчиком. Этот способ, несомненно, лучший и наиболее
эффективный,
• но у него есть большой минус – он очень дорогой.
• Во-первых, потому что это очень долго.
• Во-вторых, пока сотрудник разговаривает с заказчиком,
исполнителями, другими заинтересованными сторонами,
ничего другого он делать не может.
• Кроме того, как показывает практика, не все могут
проводить интервью, не все могут в разговоре с
заказчиком или пользователем и задавать адекватные и
наводящие вопросы, точно услышать ответ, не затягивать
время, но при этом выяснить все необходимое.

10.

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

11.

Пример из жизни
• В рамках одного крупного проекта была
поставлена задача установить оборудование во
всех медицинских учреждениях г. СанктПетербурга. Надо было выяснить, если ли в
каждой клинике сеть – интернет или ЕМТС
(особая ведомственная сеть в СПб), есть ли там
компьютер, и прочие технические моменты.
Проблема в том, что в объектов было 500 штук.
Физически обойти всех невозможно, и интервью,
как техника сбора требований, не подходит.
Поэтому решили писать анкеты.

12.

• Приготовили, как сначала показалось, хорошую анкету с
5-6 вопросами типа: есть ли у вас сеть – интернет или
емтс, есть ли компьютер и т.д. И в конце указан
электронный адрес, на который надо ответить. Эту анкету
вместе с распоряжением городского комитета по
здравоохранению Ответить в определенный срок”
рассылают по клиникам.
• Полученные ответы команду расстроили. Главная ошибка
была в формулировках анкеты - люди отвечали именно
так, как их спросили. Нужно было выяснить "какая
именно сеть используется для подключения", а спросили
"подключен компьютер к Интернет или ЕМТС". Ответом
было, разумеется, "да".

13.

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

14.

• Другая проблема может возникнуть при
обработке анкет. Не всегда поступившие ответы
удается корректно обработать. Особенно, если вы
разрешаете писать развернутые ответы.
Готовьтесь: ответы могут быть настолько
пестрыми, что объединить их воедино и
сформулировать общие требования может не
получиться.
• Но, безусловно, плюс такого способа сбора
требований в том, что он бесплатный и
массовый.

15.

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

16.

Benchmarking (бенчмаркинг) –
заимствование чужого
Похожая на изучение аналогов техника, но со своими
особенностями. Допустим, мы хотим сделать
томограф. Требования к нему можно взять у
конкурентов. Например, томографы выпускает еще
фирма Siemens, и они хорошо продаются. Можно
подсмотреть, какое у этого оборудования
энергопотребление, какая масса, какая
функциональность. Для сбора требований
benchmarking очень хорош.
• Это не значит, что вы воруете что-то у конкурентов,
может быть, вы заимствуете какой-то опыт у
соседнего подразделения, где уже делали
похожий проект.

17.

Мозговой штурм (групповые методы
решения)
• Этот способ очень хороший, но и у него есть
сложности. Главная проблема – сложность
общения с группой.
• Представьте, я задаю вопрос, вы молчите, а ктото говорит и говорит. Более тихим людям не
представляется никакой возможности вставить
хоть слово, не перебивая говорливого коллегу.
Хорошо, что он говорит, но когда вы собираете
требования, вам очень важно выяснить правду, а
не просто поговорить.

18.

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

19.

• Есть множество техник, которые позволяют
работать в группах.
• Одна из таких техник – facilitated workshop –
«семинар, которому оказывают содействие».
Такой семинар ведут 2 человека. Один –
писатель (scriber), а другой – тот, кто общается с
группой (facilitator). Во время работы в группе
facilitator смотрит только в группу и руководит
процессами в ней.
• Допустим, начали обсуждать требования к
высотности будущего дома. Один начинает
говорить, другой молчит, а надо, чтобы
участвовали все. И критиковать нельзя.

20.

• Поэтому facilitator предлагает человеку, который
говорит много, высказать еще 1 идею, а затем
помолчать 5 минут, чтобы дать возможность
высказаться другим участникам.
• Затем он выискивает тех, кто еще не озвучил ни
одной идеи и просит его высказаться. По сути,
всё общение контролирует facilitator. Его задача
– смотреть в группу, вовлекать в работу всех,
чтобы все что-то могли предложить.
• Второй человек – scriber. Он стоит в стороне, в
группу не смотрит, но все записывает. И его
задача – не упустить ни одну мысль.

21.

Фокус-группы
• Один из случаев, когда хорошо подходит этот
способ - когда на проекте нет заказчика, когда не
у кого спросить. Например, компания Гугл
делает обновление сервиса Гугл-карты. Ее никто
не просил, она сама решила сделать, чтобы люди
пользовались. Нет заказчика в явном виде.
Никто со стороны не заплатит за эту разработку.
Поэтому не у кого спросить о пожеланиях. В
таком случае подходит фокус-группа. Она будет
вместо заказчика.

22.

• Допустим, вы решили создать томограф. Фокусгрупп здесь несколько. Во-первых, главврачи.
Они хотят, чтобы томографы были
компактными и не тяжелыми, чтобы их можно
было перемещать с этажа на этаж. Также их
интересует энергопотребление: эксплуатация
томографов не должна обходиться слишком
дорого.
• Во-вторых, фокус-группа из врачей, которые
будут пользоваться томографами. Они просят
определенный интерфейс, наличие 3D
моделирования или поддержку системы
медицинских решений (системы подсказок).

23.

• Есть еще одна фокус-группа – пациенты. Не все
конечно, а те, кто уже видел и знает, что такое
томограф и как он работает. Для них главными
требованиями могут быть тихая работа, прозрачные
стенки, чтобы не было страшно, какие-то другие
требования. По сути все эти три группы заменяют
нам заказчика. У них и уточняем, что нужно. После
этого строим томограф.
• Но и у этого метода есть сложности. Бывает,
собираете требования, опрашиваете, но общую
картину создать не получается. Одни говорят одно,
другое – другое. Поэтому фокус-группы не всегда
могут заменить реального заказчика

24.

Наблюдения
• Есть проект – надо внедрить в поликлиниках для
взрослых аппаратные программы для
записи человека на прием в электронном
виде. Что надо сделать? Надо пойти в
поликлинику и собрать у пользователей системы
требования. Вы приходите в регистратуру,
объясняете, зачем пришли, рассказываете про
проект, интересуетесь, как строится работа.
• В регистратуре готовы сотрудничать, но
работники находятся на уровне неосознанного
знания.

25.

• Такая же проблема у работников регистратуры: они
пытаются рассказать про все этапы работы, но не
могут все объяснить. По их словам, всегда
происходит одно и то же: приходит пациент,
просовывает в окошко паспорт, полис и СНИЛС, ему
выдают карточку и все. И больше никогда ничего не
происходит.
• Тогда было решено воспользоваться методом
наблюдения. Надо просто посмотреть, как все
происходит, и, может быть, заметить что-то важное
для себя, чтобы потом система работала идеально. Во
время наблюдения выясняется, что многие
нюансы были упущены.

26.

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

27.

• Какие есть минусы у наблюдения? Это, конечно, дорого, как и
интервью, и не всякий человек может этим
заниматься. Во-первых, надо на весь процесс именно
смотреть, надо быть сфокусированным, чтобы заметить, что
что-то пошло не так. Например, работник регистратуры все
карточки складывает в ниши, а одну в тумбочку положил.
Почему он так сделал? Надо обязательно спросить. Может, это
делается для того, чтобы человек мог попасть завтра на
повторный прием. Но надо еще догадаться, что это важное
событие, и нужен опыт, чтобы это понять.
• Еще одна проблема: вам может не повезти с
наблюдением. Описанное наблюдение проводилось в
четверг. А потом выяснилось, что по средам в ней
проводится еще грудничковый день. И там все по-другому,
но команда об этом не знала.
• Кроме того, не везде такой вариант, как наблюдение, годится.
Ведь врачи тоже имеют возможность записать человека
на прием повторно – без участия регистратуры. Но мы не
можем зайти, например, в кабинет хирурга, посмотреть, как он
осматривает пациентов, чтобы понять, в каких случаях он сам
записывает на повторный прием, а когда отправляет на запись
в регистратуру.

28.

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

29.

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

30.

• PMI, когда нет никаких других идей, предлагает все
требования собирать в табличку, реестр, матрицу. Такая
матрица требований может содержать несколько
столбцов, основные из которых описывают:
• наименование требования, например, требование к
строительным материалам;
• ФИО и контакты человека, который просил сделать это;
• информацию о человеке, который зафиксировал
требование (для уточнения);
• вспомогательная информация, например, дата выявления
требования, чтобы проверить, не устарело ли оно.
• Можно добавлять и другие поля на свой вкус.

31.

32.

«Ожидания»
• Есть такой термин «ожидание». Это близкое, но не
тождественное понятие с термином «требование».
Речь идет о невнятных требованиях. Например, вам
заказчик говорит, что хочет дом определенной
этажности из конкретных материалов. А потом
добавляет, что нужна хорошая детская
площадка. А хорошая – это какая? С песочницей? С
кустами и клумбами? Или какие-то другие
требования?
• Каждый раз, когда вы видите невнятное требование,
надо переводить его во внятное. Надо написать
3-4 внятных требования, чтобы команда могла
работать. Какая это, хорошая площадка, что в ней
есть? И заказчик рассказывает: например,
скамейки, клумба, песочница.

33.

Создание концепции проекта (project
scope statement)

34.

• Зачем нужна концепция проекта? Когда вы собрали
и описали требования - их много, и они
разнокалиберные.
• Порой, они даже друг другу противоречат.
• Предположим, вы строите многоквартирный жилой
дом. И зафиксировали в матрице требований
пожелания к входным дверям от архитектора и от
маркетолога. Первый просил, чтобы двери были
железными. Второй настаивает на деревянных. Как
поступить? Необходимо выбрать один из вариантов
(это называется "калибровкой требований").

35.

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

36.

37.

• В концепцию входит все то же самое, что и в
устав, только описывается очень подробно.
Принципиально указать, что исключено из
проекта: , что вы делаете в проекте, а что - не
делаете. Например, дом вы строите, но
придомовую территорию вы не оформляете,
или не проводите сдачу госкомиссии.

38.

• В айти сфере обычно совсем простые концепции. Если,
например, вы делаете небольшой сайт, то концепция
будет выглядеть как книжечка с картинками (в
методологии Agile это называется wireframe). Сначала
будет главная страница сайта, какие-то кнопки, надписи.
Картинка – окошко, опять картинка. Подобный формат
позволяет легко находить общий язык аналитикам,
разработчикам и пользователям. Разработчикам не
нужны дополнительные разъяснения, им по этим
картинкам все понятно, что предстоит делать на проекте.
• Важно помнить, что концепция может быть разного
размера, с картинками, схемами или другими
графическими элементами – все зависит от специфики
проекта.

39.

Следующий этап планирования
содержания – иерархическая структура
работ (ИСР).

40.

• В чем смысл иерархической структуры работ?
Мы помещаем главный результат работы
наверх, и потом задаем вопрос, что надо
сделать, чтобы к этому прийти. То есть
дробим на составные части. Это и называется
создать иерархическую структуру – разбить
главный результат на компоненты.

41.

• Первое правило: Наверху находится
главный результат проекта, то, чего вы
должны достичь. И это обязательно коррелирует
с целью проекта. Например, создать велосипед.
• Затем спускаемся на уровень ниже. Что надо
сделать, чтобы создать велосипед? Сделать
основные компоненты детали – раму, колеса,
руль, седло и т.д. Их мы описываем на втором
уровне, из них "состоит" наше создание
велосипеда.

42.

• Второе правило: все работы должны иметь
единообразные наименования. Вы можете
использовать существительные (это самое
лучшее) или фразы с глаголами, но
смешивать их нельзя.

43.

• Третье правило: второй уровень самый
важный в ИСР, и он должен давать
представление о проекте в целом, чтобы была
понятна цель.

44.

• Следующее правило – правило 100%. Если
вы что-то потеряли в ИСР на втором уровне,
значит, оно выпало из проекта совсем.
Например, если на втором уровне вы забыли
про педали, то у вас уже получится не
велосипед, а самокат.

45.

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

46.

• Еще одно правило - узлы не перекрываются по
содержанию. Это, в принципе, понятно. Спицы
не могут относиться и к рулю, и к колесу. Даже
если у руля есть спицы, они какие-то другие, не
такие как у колес. Тут трудно ошибиться. Хотя и
бывают общие работы. Например, покраска.
Может быть, покраска рамы, а может быть
покраска руля. Но в данном случае покраску
надо написать дважды и к одному, и к другому.
Иначе потеряется структура вообще.

47.

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

48.

•.

49.

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

50.

ИСР – основа для будущих планов, расписания, бюджета.
Нет ИСР – нет нормального управления. Многие вещи из
управления можно выкидывать, но устав и ИСР (планы) –
нельзя. Если вы их выкинете, контроля не будет.

51.

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

52.

53.

алгоритм управления сроками
состоит из 4 шагов
• Шаг 1. Составление сетевой диаграммы

54.

• На проекте иерархическая структура работ
(ИСР). В ИСР можно было увидеть все работы,
которые нужно сделать для получения
конечного результата. Но это только перечень
работ,
• там не указано, в какой последовательности надо
делать все работы. Поэтому первым делом надо
разобрать нижний уровень ИСР (самый верхний
- до того, как мы декомпозировали),
упорядочить все работы, чтобы было
понятно, что за чем надо делать.

55.

• На этом этапе из иерархической структуры работ мы
получаем сетевую диаграмму. Она отвечает на
вопрос, в каком порядке надо выполнять работы.
• 99% менеджеров пользуются одной нотацией,
поэтому сейчас она является повсеместной. Сетевую
диаграмму изображают как набор прямоугольников
– конкретных задач, которые соединяются между
собой стрелками, обозначающими связь или
последовательность. Правило нотации: если у
работы есть предшественник, то от него должна идти
одна стрелка. Из одного блока может идти несколько
стрелок, это значит, что следующие работы могут
выполняться параллельно.

56.

Шаг 2. Уточнение ресурсов
• В зависимости от того, кто будет работать,
меняется скорость реализации проекта.

57.

• Прежде чем мы полностью разберемся с
планированием времени, нам нужно решить
другой вопрос – определить, кто именно будет
работать на нашем проекте. Уточнение ресурсов
- важный вопрос. Потому что в зависимости от
того, кто будет работать, меняется скорость
реализации проекта.
• Например, в IT опытный программист напишет
софт быстрее, чем начинающий. И его скорость
может отличаться в десятки раз. Поэтому нам
важно распределить ресурсы до того, как мы
составляем расписание.

58.

Шаг 3. Определение
продолжительности работы
• Задача – получить конкретный срок – в часах, днях. Звучит
легко, но сделать это не так просто. В условиях
неопределенности (а любой проект обладает
уникальностью, и как следствие, связан с
неопределенностью) сложно понять, сколько времени
занимают работы.
• Но есть множество методов, которые можно использовать если мы не можем предсказать сроки точно, мы их
предсказываем приблизительно.

59.

Шаг 4, последний. Адаптация
графика под календарь
• Когда у вас есть сетевая диаграмма, вы
понимаете, какие работы надо делать и
сколько времени они займут. Но это еще не
значит, что вы четко знаете, сколько времени
будет длиться проект и в какие даты он
завершится. Потому что есть еще выходные
дни, потому что рабочий день длится не 24
часа в сутки

60.

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

61.

• На этом этапе заканчивается работа с
планированием сроков.

62.

MS Project
• В реальности менеджер проектов никогда не
занимается управлением сроками вручную,
на бумажке никто ничего не рисует.
Используется специальный софт, например,
MS Project. Это самый популярный софт для
проектного управления, но вариантов очень
много. Существует около 400 программальтернатив Project.
• MS Project – самая популярная программа,
по крайней мере, в России

63.

Управление сроками – определение
продолжительности
• Итак, какие методы можно использовать для
оценки продолжительности работ:

64.

65.

Методы для оценки
продолжительности работ:
• 1. Нормативы
• Например, бетон застывает 72 часа, ни
больше ни меньше.

66.

2. Оценка по аналогам
• Вы что-то подобное делали раньше и помните, как
это было. Тогда эту информацию можно
использовать. Но главная проблема такого способа
оценки – не всегда можно подобрать точно такой же
случай из прошлого. Одно дело, когда ты
оцениваешь по аналогу содержание (например,
предлагаешь заказчику такой же сайт, как у
конкурента, но с небольшими изменениями). Другое
дело – сроки, с ними сложнее, информация о том,
“как оно у других” не всегда может быть применима.
Какой нам прок от знания, что конкурент такую же
турбину смонтировал за полгода. Ведь у вас другой
коллектив, другой объект, могут быть другие
моменты, которые повлияют на ход работ.

67.

3. Экспертная оценка
• Можно использовать мнение специалиста в
конкретной области.
• Практика показывает, что адекватно
подобранные эксперты обычно сильно не
ошибаются. Хотя часто полезно вводить при
определении показателей технологические
поправки, чтобы оценить более точно.

68.

4. Параметрическая оценка
• Например, компания строит жилой дом. На один этаж уходит 2
недели. Значит, если дом из 10 этажей, то понадобится
примерно 20 недель.
• Параметрическая оценка подходит не для всех отраслей: где-то
ее удобно применять, где-то - не очень. Она удобна в стройке,
потому что там много работ, которые предсказуемы и зависят
от квалификации. В производстве, особенно сложном, ею
пользоваться не очень удобно ею пользоваться. А в IT такой
способ вообще очень сложно применять. Было одно время,
когда программистов «меряли» строчками кода. Якобы, чем
больше строчек, тем сложнее программа. Значит, надо больше
времени и больше денег. И многие этим пользовались. Но как
вы понимаете, при программировании используется какой-то
язык, и можно описать это лаконично, а можно не так
лаконично. Когда поняли это, отказались от параметрических
оценок в IT.

69.

5. Оценка по трем точкам
• Экспертная оценка является базой, но
менеджерам нужны были и конкретные
формулы. И математики дали их. Одна из таких
формул – оценка по трем точкам. Есть такая
формула, которая позволяет уточнить свои же
экспертные суждения. Она не заменяет их,
экспертное мнение все равно нужна. Но формула
позволяет его немного перерабатывать. При
применении этого метода мы не просто берем
экспертное мнение, а рассматриваем три
показателя: оптимистичный, пессимистичный и
наиболее вероятный. И на их основе делаем
более точный прогноз.

70.

6. Техники группового принятия
решения
• Чтобы решить проблему группового
обсуждения, и никто не забивал мнение
другого, есть 2 техники – покер
планирования и техника Делфи (Delphi).

71.

Покер планирования
• Технику покер планирования
любят айтишники. Этот способ
называется так, потому что
участники беседы используют
колоду, сильно напоминающую
колоду игральных карт. У каждого
участника есть своя колода и все
они между собой одинаковые: с
одной стороны «рубашка», с
другой – цифры, которые растут
от 1 до какого-то значения.
Принято использовать для покер
планирования числа из ряда
Фибоначчи – 1,3,5, 8 – и т.д.

72.

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

73.

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

74.

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

75.

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

76.

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

77.

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

78.

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

79.

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

80.

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

81.

7. Анализ резервов
• При планировании сроков работы у вас могут
быть резервы. Важный момент - информация
о необходимых резервах берется из сведений
о рисках.
• И это единственное место, откуда их можно
брать. То есть когда вы риски спланируете,
тогда будете анализировать и планировать
резервы.

82.

Пэддинг
• у меня небольшой список задач, которые я могу делать быстро и
здорово, но это мой конек. Представьте, что вы пришли ко мне,
спросили, сколько займет работа. Я понимаю, что за 5 дней справлюсь,
потому что я очень хорош именно в этом, но на всякий случай
называю 8-9 дней.
• Представим, что я справился за 5 дней. Что я сделаю? Могу пойти к
вам и сказать, что все сделал. Вы, узнав об этом в первый раз, может,
даже обрадуетесь, но со временем эта перестраховка будет вызывать у
вас раздражение. Потому что это будет выглядеть как издевательство:
ради меня планы подвинули, а я просто перестраховывался. И дальше
будет ситуация, как с чиновником и крокодилом Геной: вы будете
резать мои сроки пополам, а я буду их пытаться хитро удлинить.
• Я, конечно, все это понимаю, поэтому не пойду к вам через 6-7 дней,
буду еще несколько дней тянуть. Почему? Потому что на одной чаше
весов у меня амбиции какие-то, я хочу, чтобы вы меня замечали и
ценили. А на другой чаше весов у меня чувство безопасности, и оно
обычно перевешивает амбиции у большинства людей. Так что я приду
через 8 дней, сдам вам результат, и все обрадуются, что я молодец,
справился вовремя.

83.

• Пэддинг – это раздувание в тёмную. Например,
айтишники так часто делают – они, чтобы назвать
сроки, умножают продолжительность работы на
число П, то есть примерно на 3. А отказать от
пэддинга можно, если просить у людей не сроки, а
оценку плюс резерв. То есть спрашивать, за сколько
человек справится, и какой резерв заложить, если
что-то случится. Причем, резерв должен быть на
конкретную ситуацию, а не на все подряд. То есть вы
у человека спрашиваете его оценку, за сколько он
справится, узнаете, нужен ли ему резерв, и на что
именно он нужен. Это уже управление рисками.

84.

Кривая обучения
• Кривая обучения - это очень простое понятие.
Речь о том, что когда вы делаете однотипные
работы, вы со временем разгоняетесь.
• То есть, когда мы начинаем осваивать новую
деятельность, сперва скорость резко прирастает,
потом прирост становится медленнее. Когда мы
полностью освоим деятельность, скорость
больше не растёт. Нет прироста
производительности, и это нужно иметь в виду.

85.

Некоторые психологи говорят, что на
раскачку нужно 15 минут
• Представим задачу,
требующую концентрации,
такую, где надо мозг
включить, сосредоточиться.
Например, надо написать
концепцию, план,
инвестиционную программу.
• Вы садитесь за работу, и вам
нужно какое-то время, чтобы
раскачаться. Сели,
сфокусировались, сначала
ничего не получается, потом
раскачались, и пошло.

86.

• Сперва вы совсем тормозите, потом вы выходите на плато и
достигаете своей нормальной, боевой, скорости. Это называется
состояние потока, вы вошли в поток. И в этом потоке работаете.
• И тут забавно: если к вам в этот момент подойти и начать
разговаривать, вас может выбить из потока. Например, вы
работаете, подходит коллега и предлагает покурить. Вы ему
отвечаете, что пойдете позже, через полчасика примерно, он
просит, чтобы вы ему сказали, когда пойдете, чтобы пойти
вместе. После такой коротенькой беседы на 20-30 секунд вас
может выбить из потока, вы проваливаетесь, если не на самый
низ, то довольно низко.
• И вам нужно еще 15 минут, чтобы снова раскочегариться. Вот
такой эффект. И если к вам четыре раза за час подходить, то вы
никогда не войдете в поток, никогда не выйдете на свою боевую
мощь.

87.

dark rooms
• Забавно, как компании к этому эффекту адаптируются.
Например, в Microsoft есть термин, который в переводе
звучит так: «не давайте программистам растворяться в
темноте». Этот термин принадлежит Биллу Гейтсу. И
сначала все подумали, что это фигура речи какая-то, но
ничего подобного.
• В Microsoft раньше существовали «темные комнаты»
(dark rooms). Когда программисту нужно что-то очень
умное сделать, и ему важно, чтобы его не дергали, не
отвлекали, он уходил в темную комнату. Сами помещения
были устроены по типу душевых: ты зашел, за собой
закрыл дверь, на ней написано «занято». У тебя есть стол,
стул, компьютер, сеть. Но там не ловит телефон, и
непонятно, кто «в домике» сидит, кто там спрятался. А ты
можешь спокойно себе работать, тебя никто не будет
дергать.

88.

• И это, видимо, бесило Билла Гейтса, который кого-нибудь
искал, а этот человек был в одной из таких темных комнат.
Затем в компании эти тёмные комнаты отменили, но как идея в
целом это было хорошо. Зашел, поработал, сделал что-то
сложное, закончил, пошел к себе.
• В некоторых других компаниях тоже к этому эффекту забавно
приспособились. Они ввели простое правило: когда человек
работает и ему нужно, чтобы его не дергали, он надевает
наушники. Необязательно, чтобы человек музыку слушал,
просто есть правило: если человек в наушниках, то его трогать
нельзя. Он может спокойно войти в состояние потока. Когда
человек будет готов с вами пообщаться, например, он почту
проверяет или делает что-то рутинное, он наушники снимет, и
тогда с ним можно будет поговорить. Но если человек сидит в
наушниках, и в здании не пожар, не эвакуация, а вы просто с
ним хотите поболтать - этого делать не надо. Считается, что его
отвлекать - это неэтично. Человек наушники для того и надел,
чтобы всем дать понять, что он сейчас занят. В некоторых
компаниях это правило становится негласным, но очень
жестким.

89.

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

90.

• Сетевая диаграмма показывает, сколько
времени занимает работа, кто ее выполняет,
конкретные шаги, которые предстоит
выполнить.

91.

92.

• Как посчитать самостоятельно, сколько
времени займет проект? Надо суммировать
время по последовательным работам. Если
работы идут параллельно, то берется та часть,
которая занимает больше времени.
• Чем сложнее проект, тем сложнее
разобраться.

93.

Критический путь
• Появляется понятие критического пути.
• Представим проект по ремонту однокомнатной
квартиры, который будет состоять из 4-5 работ.
• Первое, что мы сделаем, – поменяем дверь.
• Дальше возьмем две параллельные работы –
закупка материалов и поклейка обоев
(предположим, что у нас уже есть обои и клей).
• После этого натягиваем потолок.
• И последнее – занимаемся выравниванием пола.

94.

95.

Оценка продолжительности работ
• Теперь нужно оценить продолжительность
всех этих работ. Сколько нужно времени,
чтобы поставить дверь? Допустим, 1 день. На
закупку сколько уйдет? Допустим 1 неделя (7
дней). На поклейку обоев уйдет 2 дня, на
потолок – 1 день, а на работы с полом мы
возьмем 3 дня. Если все сроки сложить,
получится, что мы должны выполнить
проект за 12 дней. Это проект простой, мы
легко можем посчитать его
продолжительность.

96.

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

97.

98.

Даты раннего начала и раннего
окончания работ
• В какой самый ранний момент времени можно начать закупку?
Поскольку закупка начинается в день, когда закончилась
предыдущая работа, то ее можно начинать в первый день. При
этом самое раннее, когда можно закончить закупку, – это
восьмой день.
• Когда можно начать поклейку обоев? Тоже на первый день. А
закончить эту работу самое раннее получится на третий день.
• Следующая работа – натяжные потолки. Когда ее можно
начать? В восьмой день, а закончить на девятый.
• К полу можно приступить на девятый день, а закончить на
двенадцатый.
• Мы посчитали с вами даты раннего начала и раннего
окончания работ.

99.

Даты позднего начала и позднего
окончания
• Потом начинаем считать обратно. Спрашиваем себя про последнюю
работу: в какой самый поздний момент времени нужно закончить
работу с полом, чтобы не сдвигалась дата окончания проекта. Если
проект длится 12 дней, то самый поздний момент времени, когда
нужно закончить с полом, – это двенадцатый день.
• А когда самое позднее надо начать, чтобы не сдвигалось окончание?
На 9 день.
• А самое позднее, когда надо делать потолок, чтобы не сдвигались
сроки? Закончить не позже девятого дня, а начать – не позже
восьмого.
• А когда надо делать закупки материалов, чтобы не изменились сроки?
Закончить надо не позже восьмого дня, а начать не позже первого дня.
• Этап с обоями. Когда его надо закончить и начать, чтобы
продолжительность проекта не увеличивалась? В данном случае робот
высчитывает, что закончить с поклейкой нужно не позже восьмого
дня, а начать надо не позже шестого.
• Остается замена дверей. В какие дни ее надо сделать? Закончить
установку надо в первый день, а начать надо не позже нулевого дня.
• Мы посчитали даты позднего начала и позднего окончания.

100.

101.

Floats - «плавучесть»
• Если у нас получилось, что все работы должны стартовать в
нулевой день, значит, мы нигде не ошиблись, вернулись на
исходную точку.
• Цифры совпадают почти везде, кроме одной работы – поклейка
обоев. Но они отличаются на одну и ту же величину – на 5. Это
ровно столько, на сколько отличается продолжительность двух
параллельных работ – закупки материалов (7 дней) и поклейки
обоев (2 дня).
• Эта величина на языке менеджеров проектов называется floats,
что в переводе означает «плавучесть», то есть настолько работа
подвижна, насколько ее можно двигать. Поскольку закупка –
это длинный этап, а поклейка обоев – короткий, то можно
поклейку можно начать одновременно с закупкой, а можно чуть
позже. Насколько позже? Максимум ее можно задержать на
пять дней.

102.

• Понятие критического пути – это работы с нулевым
float, которые нельзя задерживать. В нашем
примере, почти все работы на критическом пути,
кроме поклейки обоев. Эту работу можно
задерживать на величину float, а остальные – нельзя.
• К критическому пути должно быть приковано
повышенное внимание менеджера, здесь не поле для
экспериментов. Если у вас есть стажеры или новые
технологии, лучше не обкатывать их на этих этапах.
Экспериментировать лучше с теми работами, по
которым есть float - то есть запас по времени.

103.

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

104.

Методы сжатия расписания и вехи в
проекте
• Посмотрев на нарисованное расписание, вы понимаете,
что вы не укладываетесь в сроки. У вас в уставе рамки
жестче чем сроки, которые у вас получились в графике. И
надо как-то впихнуть, как-то утрамбовать расписание,
уложиться в временные границы, которые обозначены в
уставе. Необходимость сжатия расписания иногда
возникает уже в ходе планирования, а иногда и позже.
Потому что зачастую вас из расписания вышибают какието события: заболел человек, подвел поставщик, заказчик
пришел с какой-то гениальной идеей, обязательной для
включения в план.
• Как вернуться в расписание? Что надо сделать, чтобы
уложиться в срок, если вы начинаете из него выпадать?

105.

Есть следующие варианты:
• - Урезать какие-то работы, содержание.
Вполне хороший метод, хоть и не бесплатный. Мы
не можем урезать то, что в уставе было указано
явно. Например, мы строим 9-тиэтажный
кирпичный дом. Это нельзя менять, это
неприкосновенно.
• Но в уставе не написано, будем мы стеклить
балконы или нет. Поэтому как вариант – можно
отказаться от остекления балконов. Это сделает
немного более несчастным лицо заказчика, ему это
не очень понравится. Но если мы правильно
выбрали работу для урезания, это не сильно
сделает его несчастным - ведь благодаря этому
сокращению, мы уложимся в сроки (если нам это
необходимо).

106.

• - Снизить качество.
• Урезать качество можно, иногда это может
сделать заказчика более довольным. Но надо
понимать, что риски повышаются.
• - Привлечь еще людей в команду. У
этого варианта даже есть название – crashing
– когда вы, грубо говоря, нагнали людей.
• Работа дорожает. У вас больше народа
трудится, значит, работа станет дороже.

107.

• crashing не всегда работает. Некоторые работы не
поддаются линейному ускорению. Это относится к любым
интеллектуальным работам – например, проектированию
и программированию.
• Допустим, у вас было 5 программистов, у вас была одна
скорость. Вы взяли еще двоих, скорость чуть повысилась.
• Вы увеличили количество программистов до 12, но
скорость упала до первоначальной, когда у вас было 5
специалистов. Почему так может быть?
• Потому что интеллектуальные задачи, и не только в
программировании, требуют обильных коммуникаций.
Люди общаются, кто что делает, кто как делает. Но чем
больше людей, тем ниже уровень коммуникации. И
скорость работы падает.
• Но на простых работах crashing работает, хотя и делает
сами работы дороже.

108.

• - Запараллелить работы. У этого способа тоже
есть название – fast track. По-русски звучит ужасно –
«быстрый проход». Допустим, у нас были работы,
которые шли последовательно, а мы их
запараллелили. В чем проблема этого способа? У
всего есть своя цена, и fast track всегда повышает
риски. Представьте себе, что вы строите дом, сначала
фундамент, потом стены и крышу, потом обои
клеите. Но вы не успеваете. И решаете, ладно,
фундамент и стены есть, хорошо, а обои и крышу
будем делать одновременно. Может быть, у вас это
получится. Но если пойдет дождь, обои просто
отклеятся, и вы потеряете и деньги, и время. То есть
этот метод повышает риски.

109.

• - Перепланировать, скорректировать планы. Это
единственный бесплатный способ. Но вы должны хорошо
подумать и найти какое-то новое решение. Сначала у вас были
одни планы, но потом в ходе проекта обнаружилось, что можно
перепланировать.
• Например, можно одних людей поменять на других. Или вы
заложили какие-то риски, но они не сработали, и у вас остался
резерв, который можно использовать на другие работы. Это
единственный бесплатный способ, который ничего не стоит.
Может быть, когда вы столкнетесь с проблемами, у вас уже
будут идеи, что можно изменить, и это не сделает проект
дороже, но может немного ускорить его реализацию. Так чаще
всего и бывает. Поэтому устав у нас «отлит в бронзе», а планы и
все остальное у нас гибкое. Так что если вы видите, что не
укладываетесь в сроки, сначала подумайте, нельзя ли внести
изменения в план и сэкономить время за счет этого.

110.

• - Отказаться от изменений. Этот способ
работает, если причина нарушения сроков связана с
какими-то изменениями, о которых вас попросили, и
от них можно отказаться. К примеру, заказчик
предложил поставить в доме лифты ОТИС, а не
Могилевского завода. Но вы смотрите, что это, вопервых, дороже, а во-вторых, надо лифтовую шахту
расширять, на это понадобится время. Поэтому вы
отказываетесь от таких изменений. Или предлагаете
заказчику выбрать, от чего ему нужно отказаться,
чтобы изменения сохранить. Например, мы не
стеклим балконы, но поставим лифты ОТИС. Хотя,
конечно, корректировать изменения не всегда
возможно.

111.

• - Переработки. Этот метод сжатия расписания самый
простой, но у него есть и минусы. Что плохого в
переработках? Качество страдает. Люди выматываются. У
меня есть глубокая убежденность, я это проверил на
проектах в двух отраслях – в IT и производстве: если у вас
серьезные переработки, то есть вы работаете раза в
полтора больше, вместо 8 – 12 часов и больше, то в таком
режиме люди без потери бдительности и потери качества
могут работать не дольше двух-трех недель. Дальше люди
очень сильно выгорают. И потери от выгорания будут
сильнее, чем выигрыш от переработок. То есть если вы
работаете в таком режиме не 3 недели, а 6, то у вас к этому
сроку и даже раньше падает производительность
настолько, что вы в итоге теряете спустя еще 3 недели все
ускорения, которые отыграли за предыдущие недели.

112.

• Люди, действительно выгорают, они устают, теряют
концентрацию. И самое страшное – они просто увольняются.
Кроме того, от работы в авральном режиме страдает качество,
поэтому еще неизвестно, что вам дороже выйдет: отстать от
сроков или в качестве потерять. За те 2-3 недели, в которые вы
можете выжимать соки из людей, на мой взгляд, можно
отыграть около недели примерно. То есть за счет того, что
человек работает сверхурочно, вы сможете компенсировать
максимум неделю отставания. После этого у него начнет падать
производительность, ему потребуется длительное время, чтобы
вернуться в норму. Есть еще один минус в переработках (кроме
повышения рисков из-за усталости и ошибок), тоже очевидный.
Особенно актуален для тех менеджеров, которых не волнует,
что люди выгорают, что им тяжело. Это еще и дорого, потому
что переработки в приличном обществе принято оплачивать.
Так что у переработок две проблемы - деньги и качество.

113.

Вехи в расписании проекта
• Вехи или ключевые точки.
• В уставе заложен срок проекта, когда надо закончить.
Например, дом надо построить не позднее чем через год. И
спонсор вам говорит: слушай, у меня есть еще одно важное
ограничение – у меня заканчивается аренда земли через 9
месяцев. И поскольку продлевать разрешение очень дорого,
мне надо, чтобы через 9 месяцев вся техника с площадки ушла.
Поэтому через 9 месяцев надо закончить стройку, а отделка
может еще продолжаться. В итоге в уставе зафиксировано две
вещи – срок окончания проекта (12 месяцев), и уход техники с
площадки через 9 месяцев. И это как раз веха.
• Вы согласились, подписали устав, и дальше вы, как менеджер, у
себя спрашиваете, что нужно сделать, чтобы техника ушла с
площадки? Выясняется, что надо сделать массу всего.
Расписываете все работы (колбаски Ганта), ставите засечку в
тот момент, когда техника должна уйти. А когда мы сделаем
отделку, поставим сантехнику, подведем сети, проведем сдачуприемку, тогда мы скажем, что дом построен. И это будет
вторая засечка.

114.

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