Post #313

Продолжу про чек-листы из Essence (из ГОСТ 57195). Я, когда не забываю, обязательно включаю формулировки из них в план проекта. Эти чек-листы "капитанские", но, как любой чек-лист, почти всегда выполняются, но если вдруг один пункт не выполняется — это окупает все предыдущие разы. Вот, например, чек-листы к "Требованиям": Состояние "Сформулированы": ✅ Первоначальная группа заинтересованных сторон согласна, что система должна быть произведена. ✅ Заинтересованные стороны, которые будут использовать новую систему, идентифицированы. ✅ Заинтересованные стороны, которые профинансируют начальную работу по созда­нию новой системы, идентифицированы. ✅ Существует очевидная возможность, которую реализует новая система. Тут вроде всё очевидно, нужно понять — что делаем, зачем, кто будет пользоваться и кто оплатит. Состояние "Требования ограничены": ✅ Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы. ✅ Заинтересованные стороны согласны с назначением новой системы. ✅ Определено, что будет считаться положительным эффектом от внедрения новой системы. ✅ Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения. ✅ Технология описания требований согласована. ✅ Механизмы управления требованиями есть в наличии. ✅Приоритезационная схема ясна. ✅Ограничения определены и приняты во внимание. ✅Допущения ясно сформулированы. Вот тут уже начинаются проблемы. Положительный эффект? Далеко не в каждом проекте удается зафиксировать. Пределы решения? (Можно ещё перевести, как границы). Не всегда фиксируют. Да ещё чтобы все их поняли? Технология описания. То есть, мы в каком виде требования формулируем? User story? JTBD? Классические ФТ? Механизмы управления требованиями? Это вообще что? и т.д. Конечно, можно прожить и без этого. Тут как с дефектами: само по себе наличие дефектов в системе ещё не означает, что это дефект проявится. То, что вы не поставили галочку в чек-листе, ещё не значит, что проект обязательно провалится. Но это риск. В стандарте этого нет, но к каждому пункту можно приписать набор рисков, которые могут сработать, если это состояние не достигнуто. Отсутствие приоритезационной схемы может повлечь впихивание в продукт функций по принципу "приоритет у того, кто громче кричит". Отсутствие механизмов управления приводит к проблемам с устаревшими требованиями и соотнесением релизов с набором требований. Про непроговоренные со стейкхолдерами пределы, допущения и ограничения даже не буду говорить, не люблю ужастики. В общем, всё это может не выстрелить, но в какой-то момент — особенно когда вы руководите системным анализом не одном проекте, а, скажем, в пяти-шести. Я так в один момент обнаружил, что у меня в проекте есть в каком-то виде все 30 процессов, описанных в ISO 12207, и за всеми нужно приглядывать, и хорошо бы их как-то разложить на людей, а не контролировать каждый самому. Первый признак инженерной деятельности — систематизация. Возвращаясь к чек-листам: замечательные пункты ✅ Происхождение требований ясно. ✅ Обоснование требований ясно. Вот тут, боюсь, 80% проектов и срежется. Откуда вообще эти требования взялись? Ну, это же "по умолчанию". Это "система так требует". "Эти требования мы всегда вписываем". "Нам на курсах сказали, что так надо". "Это было в примере". "Заказчик сказал, что это нужно обязательно". Нет, я понимаю, что никогда нет времени разбираться с этим, потому что и так часов мало. Но тогда какие риски мы принимаем и не учитываем?