egorius

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

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

Построено все по классической схеме им. Дж. Р. Р. Т. и Дж. Р. Компания из 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; гарантированной готовности. Или же рисовать диаграмму риска (возможные исходы с их вероятностями); обычно это смещенное влево нормальное распределение.
• Отслеживать индикаторы обозначенных рисков и продолжать искать новые риски.

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

Собирался посвятить этот пост тому, что Lotus Notes — дерьмо.

Что мне мешало в нём больше всего? Убогий уродский интерфейс не столько мешает, сколько просто противен. А вот что реально мешает, так это окошко, вылезающее каждый раз, когда приходит почта.

Тут уместно привести цитату из Тома и Тима:

Можно также впомнить Джоэля Спольски, про то, как легко выпасть из потока (он, кстати, ссылается в этой статье на Тома и Тима, и вообще они сходятся по целому ряду вопросов).

Так вот, почему я пишу в прошедшем времени… Когда я осознал, что именно мне мешает, я полез в дебри настроек и, не прошло и пяти минут, как дурацкое окошко было отключено! По-моему, поучительная история. Мне понадобилось каких-то полгода, а большинство, похоже, вообще просто смирилось.