dz (dz) wrote,
dz
dz

Риски

Риски. Все знают, что с ними как-то надо работать. Очень не все работают.

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

- вероятность. От 0 до 1.
- импакт - в долларах США или иной валюте проекта. хорошо оценивать в человеко-днях. Смысл: на сколько мы влетим, если ЭТО реально случится.
- предупреждающие действия: что мы сделаем ДО того, чтобы снизить вероятность (и сколько эти действия стоят, и насколько упадёт вероятность)
- исправляющее действие - что мы сделаем для решения проблемы, если ЭТО, паче чаяния, случилось.

Я попытаюсь сделать сводку видов рисков, которые встречаются в заказной разработке ПО достаточно часто. You're welcome to add, да и про эти если есть что сказать - не таите. :)
  • Отсутствие опыта в технологии
На удивление частый и недооцененный риск. Реально это не обязательно "клиенту нужно на питоне, а мы на нём ни разу не писали - но хрен с ним, разберёмся" - это уж совсем крайний случай. Реально это бывает куда в более банальном виде. Проект на яве, мы всю жизнь писали на яве, но ни разу не делали на яве генерацию вордовских документов. Взали библиотеку, вставили, но - она глючит, и ловля глюка (даже если есть исходники) - три дня. А запланировано - один день (подключить либу, отдать данные, получить файл - чего там морочиться-то?) - налицо превышение сроков в три раза.

Да что там - в моём опыте был случай, когда виноуз-разработчики с многолетним стажем нарвались на то, что чуть-чуть нетривиальное использование контрола привело к войне на полмесяца - ну, оказалось, именно этот вариант разработчики ос виндоуз не тестировали. Глючит он безбожно. (давно было, деталей не помню)

Вообще этот риск напоминает старый анекдот - "вы, когда в Советский Союз въезжали, красный флаг на границе видели?" - настолько он омнипрезент, не побоюсь этого (несуществующего?) слова... :)
  • Отсутствие у заказчика опыта в реализации таких (любых?) проектов.
Второе место в моём личном хит-параде - и первое по импакту. Если учесть, что таковых - большинство, то это просто беда. Ну да - мы про неё много говорили. Предупреждающие работы по этому риску потенциально очень объёмны и малополезны. Тем не менее - ощутимо помогает: устав проекта с зонами ответственности, управление изменениями, выделение компактного ядра проекта, итеративность работы и постоянный мониторинг за клиента его целей и движения к ним. Важно иметь чёткие критерии успеха - причём для всех этапов реализации, и явно проговаривать их достижение.
  • Неполнота данных для интеграции
"А ещё это всё надо интегрировать с одинэсом" - ужасно люблю эту фразу. Впрочем, это ещё ладно - действительно, есть типичные сценарии (хотя знаю я проекты, в которых интеграция с 1с - это забрать из одинэса список сотрудников, а вовсе не то, что вы подумали). Интеграция - часто - означает, что у клиента есть какая-то хрень, от которой потеряли исходники, и которая живёт только в силу того, что сисадмин знает, что именно надо удалять из базы раз в три дня, чтобы оно не сдохло. Важно: прописать юзкейзы по интеграции и получить письменный ответ на вопрос, кто делает ответную часть. В плане проекта добавить полгода на пункт "заказчик бегает за чуваками, которые напишут ему коннектор для интеграции с нами". Напечатать этот пунк 48-м кеглем и повесить его на монитор менеджеру проекта со стороны заказчика.
  • Недостаточное понимание заказчиком итогов проекта
Устав проекта - ваш друг. Но: устав не поможет вам донести до заказчика, что создание софтверной части проекта - это не весь проект. Что внедрение неизбежно и оно не будет простым. Что после окончания разработки софта он уже будет знать о проекте СИЛЬНО больше, чем на момент запуска разработки, и что это знание покажет ему, что изначальные посылы были не вполне верны и что проект надо дорабатывать. И что так бывает всегда.
  • Учёт требований не от всех стейкхолдеров.
Тут есть две типичные ветви - забыли того, кто в итоге платит (и он подключился на сдаче, сказал "всё херня, переделывайте" и отказался платить), и забыли тётю Машу в углу, которая никто, но которая каждую пятницу корректирует данные, которые вы внесли в бизнес-процесс как некорректируемые. Вписывает личные комиссии агентов, о которых дядя Петя лично же и договаривается. И всё это выясняется на введении в эксплуатацию.

--- на сём поставим это на паузу --




Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 23 comments