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