Образование для образованных. 2020. Анатолий Левенчук

требований как главной практики в инженерии требований.

      То же самое обнаруживается с управлением буферами проектов: пока не понял про управление работами в целом (где рассматривается не только тридцатилетней давности голдраттовский вариант управления проектами, но и какой-нибудь кейс менеджмент) работа с управлением буферами проекта будет по принципу «пошли дурака богу молиться, он и лоб расшибёт». В результате на хорошей прикладной практике будет поставлен крест (виновата же она, а не недообразованность её применяющего!). Вывод после неудачи с управлением по буферам проекта будет – «давайте попробуем что-нибудь ещё». Вузовского семестра-то по state-of-the-art (сегодняшней, а не, например, конца 20 века!) трансдисциплине управления работами/операционного менеджмента почти ни у кого в мозгах нет, нет даже у «проходивших мимо» этот предмет в вузах. Но именно это «теоретическое» знание оживляет прикладную живую и практичную дисциплину, не даёт делать новичковых ошибок.

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

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

      В системной инженерии будет говориться, что требования получаются во многом из результатов дальнейшей работы над концепцией использования (requirements engineering логически следует за практикой concept development), а потом используются в архитектурной работе, а ещё дальше в проверках и приёмках (verification and validation). Огромное число ляпов и проблем проекта возникает из того, что в головах прошедших трёхдневные курсы по крошечному кусочку системной инженерии (JTBD) или системного менеджмента (управление буферами проекта) нет вот этого многоуровневого понимания, как эти работы вписываются в общие работы по проекту в длинных цепочках этих работ.

      У менеджеров тоже оказывается, что кроме управления