Люди говорят, что у меня талант к систематизации. Может быть, не талант, но некоторая предрасположенность и правда есть. Люблю это дело. И даже создание курсов, которое сложно и муторно по определению, мне доставляет удовольствие. Думал я давеча, вспоминал, откуда ж мне такое счастье привалило. Благоприобретенное оно или наследственное? И, знаете, все же приобретенное. Все же рукотворное 👌

Дело тут вот в чем: долгие годы я занимался разработкой информационных систем. Или автоматизированных систем, уж не помню, в чем отличия. Дело это происходило в те суровые времена, когда неисполнение ГОСТ преследовалось по закону. Особенно в той сфере, где я эти системы разрабатывал. И были такие прекрасные документы, как ГОСТ 34. Они определяли требования к процессу создания таких вот систем.

🏁 С чего все начиналось? Разумеется, с технического задания. Которое, по идее, должен писать пользователь, но это всегда утопия. Чтобы возникло хорошее ТЗ, его надо писать самим, то есть писать его будет тот, кто будет его исполнять. А для этого надо въехать в деятельность пользователя.

Хорошо, когда эта деятельность связанна с работой с железками. Скажем, с функционированием какого-то оборудования, технологической установки. Тогда проще, так как сия установка имеет спецификацию, и количество вариантов ее использования ограниченно отсутствием фантазии непосредственно объекта.

А вот если речь идет о системах «человек-человек» — все плохо. Ибо фантазия человека безгранична, и имеет тенденцию как к расширению, так и к поглощению энтропией. Иными словами — люди плодят бардак. А если автоматизировать бардак, что будет? Правильно: автоматизированный бардак.

Поэтому берем в руки IDEF и рисуем модели бизнес-процессов. Все по классике: сначала «as is», потом — «to be». То есть описываем, как сейчас люди работают и как хотят работать в будущем с учетом внедрения нашей системы. Из этой модели, из результатов изучения грустного настоящего и проектирования блестящего будущего начинают вырисовываться контуры ТЗ. Я видел их много, делал их много в разных ролях. От десятка страниц до трех томов.

📌Но суть всегда одна: замысел определяет будущее. Чем качественнее подумал, тем лучше, быстрее, дешевле, спокойнее реализация. Я никогда не видел исключений. Чем больше синтезировал смыслов, чем больше учел интересов, тем лучше проект. Попытки упростить сложность за счет декомпозиции в сложных системах всегда терпели провал. Должен быть консистентный замысел, вот в чем дело.

Ну а дальше, строго по ГОСТ, пояснительная записка технического проекта. Плюс, техническая и эксплуатационная документация. Плюс, программа и методики испытаний. И еще тележка разных полезных вещей, необходимых для описания сложного нематериального объекта. И для отбивания от ретивых пользователей, которые хотят «одну кнопку, чтобы на нее нажать и получить все». Последнее — цитата из реальной служебной записки.

В общем, поверьте, пять-шесть лет практики работы по ГОСТ или отечественным военным стандартам сделают из вас эксперта в систематизации. А если вы еще пройдете все стадии этой деятельности, от разработки моделей процессов до создания нефункциональных тестов, то, видимо, можете систематизировать даже Большой взрыв. В этом большая польза информационных технологий. Одна из немногих польз ✅

К чему это я? Бизнес тоже можно отнести к сложным системам типа «человек-человек». Который тоже нуждается в некотором описании, причем на многих уровнях, причем логически связанных между собой. Стратегия должна сочетаться с планами, планы — с процессами и показателями. Хуже всего, что процессы должны определять требования к людям, и тем эффективнее компания, чем более комплиментарных процессам людей она умеет находить и адаптировать.

Все это должно быть увязано общей логикой и ответом на вопрос «зачем?». И еще уметь изменяться во времени при устаревании или существенном изменении внешних обстоятельств. Видите, как сложно? Это вам не визуализировать желания. Тут просто не получится. Тут работать головой надо. Собственно, об этом и хотел сказать.