?

Log in

No account? Create an account

Пт, 8 мар, 2013, 16:49
Книги: февраль

Наталья Щерба, «Часодеи»

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

Построено все по классической схеме им. Дж. Р. Р. Т. и Дж. Р. Компания из N человек, среди которых есть и не вполне люди, собирается с целью спасти мир. Главный герой и сам не понимает, как попал в переплет, но обладает уникальными способностями, о которых, впрочем, не догадывается. За происходящим пристально наблюдают вселенское добро и мировое зло, но отдуваются в основном простые смертные, проявляя чудеса героизма и демонстрируя настоящую дружбу. В конце наши побеждают. Магия и насилие по вкусу.

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

Tom DeMarco, Timothy Lister, «Waltzing with Bears: Managing Risk on Software Projects»

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

— А. и Б. Стругацкие, «Жук в муравейнике»

Книга авторов Peopleware про управление рисками, и, насколько я могу судить, книга хорошая. Весь процесс описан очень внятно и с примерами.

Вкратце, авторы предлагают делать так:

  • Определить риски проекта. Это как минимум основные стандартные риски (ошибки планирования, разрастание требований, уход сотрудников, невозможность договориться о спецификации разработки, низкая продуктивность команды), а также все, что привело к проблемам в прошлых проектах и все, что удалось придумать еще. Из стандартных рисков наиболее «мощный» — ошибки планирования, он приводит к увеличению времени на треть с вероятностью 0,5.
  • Записать каждый риск.
  • Определить индикаторы реализации рисков (transition indicators, как можно более ранние признаки).
  • Оценить вероятность реализации рисков и их стоимость для проекта (в деньгах и сроках).
  • Вычислить ресурсы для принятия рисков (budget and schedule exposure, верятность × стоимость) — сумма по всем рискам покажет, сколько в среднем надо иметь в резерве.
  • Определить необходимые действия для уменьшения последствий реализации рисков (mitigation) и план действий в случае их реализации (contigency actions).
  • Добавить действия для уменьшения последствий реализации рисков в список задач проекта.
  • Обозначить риски, реализация которых приведет к прекращению проекта (showstoppers), как проектные предположения и передать управление ими вышестоящему руководству.
  • Первое приближение плана: оценить задачи, считая, что никакие риски не материализуются (эти оценки обычно достаточно точны).
  • Второе приближение: учесть вероятности и последствия рисков. Авторы рекомендую написанный ими инструмент, использующий метод Монте-Карло. Если вероятности неизвестны, то, несмотря на всю математику, мы не прогнозируем, а гадаем. Чем тогда метод «умножим на π-пополам» принципиально хуже?
  • Все обязательства давать с учетом рассчитанных вероятностей. То есть говорить не о дате готовности задачи, а о нескольких датах: к которой задача точно не будет готова; наиболее вероятной; с шансами 50/50; гарантированной готовности. Или же рисовать диаграмму риска (возможные исходы с их вероятностями); обычно это смещенное влево нормальное распределение.
  • Отслеживать индикаторы обозначенных рисков и продолжать искать новые риски.

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

Пт, 8 мар, 2013 22:13 (UTC)
autoench

Моя любимая цитата из Стругацких, да.

Сб, 9 мар, 2013 09:28 (UTC)
egorius

Стругацкие — вообще кладезь.