Вальсируя с медведями краткое содержание

Обновлено: 17.06.2024

Войти

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

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

Я занимаюсь разработкой программного обеспечения (ПО) уже лет десять. За это время я участвовал в нескольких десятках проектов – от малюсеньких (семь-восемь человеко-дней) до весьма больших (тот, в котором я сейчас, длится уже почти два года, причем в нем работает человек сто). Прочитав книгу Тома Демарко и Тимоти Листера, я понял, почему многие из этих проектов окончились неудачей – ни в одном из них никто не занимался управлением рисками.

В книге есть две главные идеи:

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

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

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

Казалось бы, если в проекте мало рисков или они незначительны – это хорошо. Однако авторы утверждают обратное – как правило, там, где есть большие риски, есть и большие выгоды. Если рисков нет – проект вряд ли сможет принести большие прибыли.

Кроме массы здравых идей в книге описаны некоторые численные методы, формализующие подход к управлению рисками в проектах. Авторы даже создали небольшое приложение на MS Excel, в которое можно ввести параметры вашего проекта и оценить его риски.

Риски в моем следующем проекте будут управляться, начиная с самого начала. Посмотрим, что из этого получиться :)

Однозначный “mustread” для менеджеров проектов, руководителей групп, CIO и владельцев компаний, занимающихся разработкой программного обеспечения.

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

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

Кто же такие, авторы данной книги —

Том ДеМарко (родился 20 августа 1940 г.) — известный автор, преподаватель и спикер по темам программной инженерии.

Карьера Тома ДеМарко началась в Bell Telephone Laboratories, где он работал в рамках легендарным проектом ESS-1. В последующие годы он руководил проектами в реальном времени для La CEGOS Informatique во Франции и отвечал за распределенные онлайн-банковские системы, установленной в Швеции, Голландии, Франции и Финляндии. Он читал лекции и консультировал в Северной и Южной Америке, Европе, Африке, Австралии и на Дальнем Востоке.

Имеет степень бакалавра естественных наук Корнельского университета, степень магистра и диплом Колумбийского университета и диплом Парижского университета в Сорбонне. В свободное время он работает техником неотложной медицинской помощи, сертифицированным в своем родном штате.

Автор девяти книг по менеджменту, организационному дизайну и развитию информационных систем.

Тим Листер (родился в 1949 году) — американский инженер-программист и автор, специализирующийся в области проектирования, управления рисками программного обеспечения и человеческих аспектов технологической работы. Тим Листер в соавторстве с Томом ДеМарко разрабатывает теорию, — над не техническими факторами, влияющими на работу команды и отдельных лиц. Эта работа была предметом ретроспективной специальной сессии Международной конференции IEEE.

Риски и выгоды всегда ходят рука об руку.

Если мы рискуем по крупному, мы имеем шанс получить большую выгоду. Это касательно всего в бизнесе, — если мы хотим быть успешными, необходимо пойти на взвешенный риск, и тогда, есть шанс на большой выигрыш. Многие мои проекты в бизнесе, были рискованными, но в большинстве случаев они приводили к успеху, результатам которого были точки роста компании.

Обязанность верить только в то, во что у вас есть право верить, называется управлением риском.

Авторы книги вводят понятие — Эскалаторы риска по Шарету

Роберт Н. Шаретт

Роберт Н. Шаретт — всемирно признанный специалист в области управления рисками, информационных систем и технологий, системной инженерии, бережливой разработки и управления крупномасштабными программно-интенсивными системами, а также предпринимательства и инноваций в области рисков. С момента основания ITABHI Corp. в 1987 году он работал старшим советником широкого круга компаний из списка Fortune 100, консорциумов высоких технологий и государственных ведомств по вопросам эффективности, воздействия и вознаграждений / рисков их программ и политики в области высоких технологий. По образованию ученый-компьютерщик, Шаретт входил в состав комиссии Национального исследовательского совета по оценке эффективности программы обеспечения безопасности программного обеспечения космического шаттла НАСА. Шаретт много писал на темы управления рисками, управления проектами и программами, инноваций и предпринимательства. Он работает редактором журнала IEEE Spectrum, где ведет блог о факторах риска. Он также регулярно пишет статьи для Business Intelligence Review, правительственного журнала и журнала Cutter

Известный автор и эксперт в области управления рисками Боб Шарет (Bob Charette, — но, думаю правильно Robert N. Charette) предложил полезный новый способ отношения к риску в нынешних условиях. Он предложил представить вашу компанию и ее конкурентов как несколько движущихся вниз эскалаторов. Вам необходимо вскарабкаться вверх по своему эскалатору, уносящему вас вниз. То же самое делают на своих эскалаторах и конкуренты. Чем быстрее движутся ступени, тем быстрее нужно карабкаться каждому, чтобы держаться на одном уровне. Если остановиться хоть на мгновение, немедленно отстанешь. И, разумеется, если остановиться надолго, то вылетишь вниз, будучи не в силах продолжать борьбу с соперниками .

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

Управление рисками — это управление проектами для взрослых.

Мы, специалисты по разработке программного обеспечения, приравниваем зрелость к профессиональной квалификации. У нас даже есть пятиуровневая модель для измерения такой зрелости — Модель зрелости процессов (Capability Maturity Model), или сокращенно СММ.

Модель зрелости процессов (Capability Maturity Model), или сокращенно СММ.

Модель зрелости процессов (Capability Maturity Model)

Интерпретация СММ

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

Стандартное управление проектами — организация внедрила стандартные процессы управления проектами и использует их во всех проектах.

Стандартные процессы организации — в организации достигнуты определенные элементы стандартизации в производственной деятельности организации. Общие технологии, инструментарии, процедуры, способы и прочее.

Управляемая обратная связь — собирается метрика о всех элементах процессов управления проектами и производства. Видеться библиотека метрик и познаний, полученных в завершенных проектах.

Оптимизация, непрерывное совершенствование — организация имеет замкнутый цикл исполнения процессов, измерений и непрерывного улучшения. Непрерывно используете измерения, обратную связь и творчество в целях оптимизации процессов.

Теперь нужна зрелость в ином, более традиционном смысле. Нам нужно повзрослеть, осознать существующие риски, чтобы планировать соответствующие действия. Именно этим и занимается управление рисками.

Риск — определение
1. Возможное в будущем событие, которое приведет к нежелательным результатам.
2. Сам нежелательный результат.

Риск — это проблема, которая еще не возникла, а проблема — это риск, который уже материализовался.

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

Пять основных составляющих управления риском:

  1. идентификация риска: первоначальный мозговой штурм по выявлению риска, последующая сортировка и определение какого-либо механизма для обеспечения постоянного действия данного процесса.
  2. анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
  3. планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.
  4. ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
  5. мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.

Международного аэропорта Денвера

Международного аэропорта Денвера

Справочно — Международный аэропорт Денвера (англ. Denver International Airport) — один из крупнейших международных аэропортов в США, расположен в 40 километрах к северо-востоку от центра Денвера. Изначально аэропорт должен был открыться 31 октября 1993 года, однако сроки несколько раз переносились: менялись требования к дизайну и возведению отдельных элементов комплекса. Каждая такая задержка сильно била по бюджету. В итоге 28 февраля 1995 года Международный аэропорт Денвера принял первый рейс.

Обсудим неопределенности в процессе разработки программного обеспечения

Среди наиболее важных источников неопределенности можно назвать:
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?
3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?
4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?

5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?
6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?
7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?

10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?

На основании вышесказанного авторы книги делают вывод

Небольшая ремарка в рассуждения авторы с отсылкой на немецкий источник, — не стоит удивляться, немецкие источники активно работали в СССР над ракетной и ядерной программой, но в СССР, не любят об этом вспоминать, в то время как США, немецкими источниками пользуются открыто, чего стоит фон Браун, со своей ракетной программой. И так, отсылка авторов на немецкий источник.

Ни один план не выдерживает боевого столкновения с противником, — фельдмаршал Гельмут фон Мольтке

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

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

Авторы утверждают, что — управление рисками обеспечивает самую дешевую защиту от непредвиденных неприятностей.

Неопределенность и необходимые резервы

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

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

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

Один из способов расширить перечень рисков — по крайней мере первоначально — состоит в методичном использовании анализа результатов после окончания проектов.

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

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

Далее, раскрывается понятие, подверженность риску — это ожидание затрат на сдерживание. Ожидание, в том смысле, в котором используется этот термин здесь — это комплексное понятие, заимствованное из теории вероятностей. Это некоторая комбинация вероятностей того, что риск наступит, и затрат, которые вы понесете в этом случае.

В простейшем случае:
Подверженность риску = затраты * вероятность

Авторы предлагают такой вариант защиты, в случаи наступления риска —

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

Риски-катастрофы

Это — риски-катастрофы: если они возникнут, то намертво застопорят дело. Они заставят вас либо найти полностью новый подход к продукту, либо аннулировать весь проект.

Управление рисками, основные шаги:

Совокупные и причинные риски

Совокупными (агрегированными) рисками, поскольку они относятся к проекту в целом;

Причинными (слагающими) рисками — относится к отдельным задач проекта.

Вот список главных рисков:

1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность

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

Три этапа обнаружения рисков обычно проходят одновременно на одном и том же совещании.

Этап 1: Мозговой штурм

мозговой штурм по выявлению катастроф

Мозговой штурм — это групповое творчество. Идея состоит в использовании групповой динамики для отыскания обходных путей преодоления привычного мышления и возникновения новых свежих мыслей.

Некоторые особенности, присущих мозговому штурму в поисках катастроф:

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

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

3. Опишите противоположные виды на будущее: Попросите людей описать свои самые радужные мечты относительно проекта, а затем обсудите прямо противоположную версию.

4. Спрашивайте о провале, в котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?

6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.

Мозговые штурмы стремительны и яростны, поэтому нужно заранее сделать некоторые приготовления, чтобы не пропустить ни одного предположения. Убедитесь, что обязанность следить за этим возложена не на фасилитатора.

Этап 2: построение сценария

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

Этап 3: анализ основных причин

Взаимовыгодная альтернатива

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

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

2. продолжение выявления рисков

3. сбор данных для наполнения хранилища рисков (базы данных для определения количественного влияния проблем, наблюдавшихся в прошлом)

4. ежедневное отслеживание показателей завершенности

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

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

Прибыль на инвестиции =(Ценность — Затраты) / Затраты

Затраты и выгоды следует определять с одинаковой точностью.

Ценность — это тоже неопределенность.

Первый этап предсказания ценности состоит в количественной оценке и выражении ее в денежном эквиваленте дохода или процентах дополнительной доли рынка.

1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.

2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды.

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

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

Что понимают под управлением рисками (уточненное и переработанное)

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

John Milton, Areopagirica. 1643.

Том ДеМарко - Вальсируя с медведями

fb2
epub
txt
doc
pdf

99 Пожалуйста дождитесь своей очереди, идёт подготовка вашей ссылки для скачивания.

Скачивание начинается. Если скачивание не началось автоматически, пожалуйста нажмите на эту ссылку.

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

Описание книги "Вальсируя с медведями"

Описание и краткое содержание "Вальсируя с медведями" читать бесплатно онлайн.

В этой книге Том ДеМарко и Тимоти Листер, авторы бестселлера Peopleware, рассказывают, как идентифицировать риски, управлять ими и извлекать выгоду из рисков.

"Избегать рисков — дело проигрышное. Раньше вы могли бы отнестись к проекту, свободному от рисков, как к неожиданному подарку судьбы и благодарили бы звезды за эту редкую удачу — легкий проект. Мы реагировали так же. Какими глупцами мы были! Проекты безриска — уделнеудачников.

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

Вальсируя с Медведями

Управление рисками в проектах по разработке программного обеспечения

Вступительное замечание авторов

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

Часть I: Зачем нужно утруждать себя управлением рисками?

Часть II: Почему нам этого не следует делать? (Здесь авторы говорят начистоту о некоторых потенциальных недостатках, которые влечет внедрение управления рисками в организации, не вполне готовой к этому).

Часть IV: Каковы размеры рисков, приемлемые для нашей организации?

Часть V: Как убедиться, работает ли наш подход к управлению рисками?

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

ТРЛ: Это я (Тим) говорю от своего собственного имени.

Крадется вниз по лестнице
(не встретиться б с соседями!),
чтобы родной покинув дом,
вальсировать с медведями

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

Лондон, 11 апреля 1876 года: действие происходит на площади Гросвенор, вот-вот пробьет 10 вечера. По тротуарам спешат викторианские джентльмены, многие из них — в цилиндрах и вечерних костюмах, они устремляются к изысканно украшенному входу в гостиницу Гросвенор. Последуем за ними — и нас проведут наверх, где скоро начнется ежемесячное собрание лондонского элитного Метафизического общества.

В этот вечер обстановка в зале несколько напряжена, что объясняется выбором докладчика. Это — только что принятый в Общество Вильям Кингдон Клиффорд. Клиффорд — профессор логики и математики Лондонского университета Его считают борцом с предрассудками, возможно, даже атеистом, к тому же он известен как пламенный полемист. С его избранием Общество обрело самого юного члена из всех когда-либо допущенных в него.

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

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

Корабль выходит в море и гибнет со всеми пассажирами.

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

Затем Клиффорд возвращается к тому же примеру, слегка изменив его. Пусть теперь кораблю удалось все-таки завершить рейс и никто не погиб. Будет ли хозяин менее виновен?

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

Дилемма такова: вам доверяют работу, для вас это — вызов, вопрос престижа… но вам придется поверить в этот график. Это — цена, которую вы платите. Вы, сглотнув с трудом, говорите, что справитесь. Позднее вы укрепляете свою веру. Конечно. А почему бы и не к Рождеству? Другие проекты удавалось ведь выполнить в такие же сжатые сроки, не так ли? Вскоре вы можете почувствовать себя на самом деле уверенным. Время может доказать обратное, но на данный момент вы практически уверены, что сумеете выполнить работу.

Хороший учебник по управлению рисками и не только. Отлично показана связь управления рисками с управлением проектами в целом. Много спецификаций, а также достаточно популярное изложение. В общем и целом - 5.

Книга очень понравилась. Рассказано о рисках со всех сторон: что это такое, яркие примеры, как они помогают/мешают работать. Отдельное спасибо за список типичных рисков которые происходят в проектах по разработке ПО. Это действительно вещи, которые регулярно происходят, но почему-то каждый релиз хочется думать, что ну в этот раз ничего подобного не. Читать полностью

Купил книгу, руководствуясь, в первую очередь, положительным впечатлением от других книг ДеМарко и Листера и, во-вторых, из-за оригинального названия. В очередной раз убедился, что чем оригинальнее называется книга, тем подозрительнее надо к ней относиться. Да, про риски неплохо написано, есть очень ценные замечания и цитаты, но воды недопустимо много. Читать полностью

Рекомендую прочесть книгу тем, кто только знакомится с управлением рисками. На мой взгляд, в книге подробно и красочно рассмотрены аспекты управления рисками. Начиная от понятия риска, заканчивая методами их оценки. Конечно, методы оценки кажутся немного поверхностными. Видимо, авторы и не ставили цель - подробно описать математическую модель. Для этого. Читать полностью

Бесспорно, книга интересная. Но до сих пор вспоминаю, какое испытал удивление и разочарование, когда мне пришла эта тонюсенькая "брошюрка", за которую я отвалил немало денег. Прочесть ее можно за пару вечеров. Толк от чтения конечно же останется.. Но у меня остался и осадок. Потом перепродал знакомому менеджеру, чтобы частично компенсировать убытки. Читать полностью

Читайте также: