Том ДеМарко и Тимоти Листер «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»

Том ДеМарко и Тимоти Листер «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»

  • Обязанность верить только в то, во что у вас есть право верить, называется управлением риском.
  • Обязанность верить только в то, во что у вас есть право верить, называется управлением риском.
  • Проекты без риска – удел неудачников. В них почти всегда и выгоды никакой нет, потому-то их и не осуществили давным-давно.
  • Управление рисками – это процесс продумывания корректирующих действий прежде, чем возникнет проблема, пока она еще остается всего лишь абстракцией.
  • Управление рисками – то, чем большинство из нас занимается постоянно, причем везде, кроме своего рабочего места.
  • В самых скверных организациях наказывают за неприятные прогнозы, но не за неприятные результаты. Когда проект проваливается, рассуждают так: «Ну, парень не успел в срок, но он, по крайней мере, очень старался».
  • Когда проект отклоняется от графика, это редко происходит из-за того, что запланированная работа просто заняла больше времени, чем все думали; гораздо чаще это объясняется тем, что проект застрял из-за выполнения работ, которые вообще не были запланированы.
  • Вчерашняя проблема – это сегодняшний риск.
  • Мы определили четыре возможности, которые вам доступны в отношении риска; Вы можете его избежать. Вы можете его сдерживать. Вы можете его ослабить. Вам удастся от него увернуться.
  • Я все время бывал в компаниях, для которых опережение графика совершенно немыслимо. Менеджера, который завершил бы проект раньше срока, обвинили бы в недобросовестном манипулировании графиком и, возможно, изгнали бы с позором. Делая третий вариант – досрочную готовность – по сути незаконным, мы сокращаем шансы на выполнение проекта в срок почти до нуля.
  • На все эти вопросы есть общий честный ответ: «я не знаю». Конечно, вы не знаете. Тот, кто задает вам эти вопросы, знает, что вы не знаете. Вопросы о будущих результатах и сама концепция знания – несовместимы друг с другом. Можно предварять любой свой ответ словами: «Я не знаю, но…»
  • Мы предлагаем вам продолжать использовать ваш нынешний инструмент оценивания, каким бы он ни был (даже если это мокрый палец на ветру), и объединить его с моделью риска.
  • Риски, общие для всех проектов разработки программного обеспечения: 1. внутренние изъяны календарного планирования 2. раздувание требований (изменение требований) 3. текучесть кадров 4. нарушение спецификаций 5. низкая производительность.
  • Когда семимесячный проект в конце концов занимает 12 месяцев, разъяренные топ-менеджеры редко винят график, вместо этого они ругают тех, кто должен был воплотить этот график (каким бы смехотворным он ни был) и жизнь.
  • Культура наших организаций иногда не позволяет говорить о самых тревожащих рисках. Мы ведем себя, как самые дикие племена, которые пытаются не подпустить к себе дьявола тем, что отказываются произносить его имя. Хранить молчание о риске – это не способ избавиться от него.
  • Когда проекты проваливаются, то часто это происходит примерно на середине, поэтому именно в это период управление рисками нужно проводить особенно активно.
  • Осознающий риски руководитель захочет заставить включить в ранние версии те функции продукта, с которыми связан наиболее серьезный технический риск. Это очень разумно, но у многих руководителей не лежит к этому душа, поскольку это в самом начале игры подвергает их риску выявить наиболее уязвимые точки проекта.
  • Инкрементный метод в процессе разработки продукта – главный источник показателей завершения, а показатели завершения – пульс проекта.
  • Инкрементный метод хорош для всех проектов… и является обязательным, когда риски высоки.
  • В проектах, где критичен срок сдачи, реальным ослаблением риска является раннее начало. Это, пожалуй, единственный эффективный способ сдерживания риска опоздания для большинства проектов.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *