Продолжаю проходить онлайн-курс «Практическое системное мышление».

Пост по первому разделу курса.

Из задания ко второму разделу:

Убедитесь, что в вашем рабочем проекте в конечном итоге создаётся физическая система, а не просто какое-то описание. Что изменится в физическом мире, если ваш проект закрыть прямо сейчас, чего в физическом мире не будет существовать без результатов вашего проекта? Напишите об этом пост в порядке мышления письмом.

Про детали рабочих проектов тут рассказывать не могу, но попробую рассказать примеры подходов, которые использую при разработке чего-то нового в наших продуктах (занимаемся разработкой ИТ-систем для ИБ).

Так как в первую очередь надо понять, что изменится в реальном мире, то один из моих любимых вопросов: что будет если ничего не будем делать? Дальше, как правило, идет цикл из уточняющих вопросов, чтобы докопаться до «мяса» (конкретных примеров из жизни, из которых можно выявить решаемую в надсистеме проблему/неустроенность) — а после, либо собеседник сам замечает абсурдность своей идеи (часто из-за оторванности от физического мира), либо вскрывается что-то очень ценное.

Мои любимые ответы:

• «Недополучим прибыль», «проиграем в тендере» и пр. Так можно сказать про что угодно, но за счет чего мы эту прибыль получим или выиграем в тендере? Для понимания контекста помогут несколько конкретных примеров из «жизни заказчика», где возникает необходимость в этой функциональности (три конкретных примера, ТКП).
• «Нас обгонят конкуренты». А как мы поняли, что именно эта доработка — та самая, которая не даст им обогнать? И дальше — выяснять, какую проблему хотим решить в надсистеме у заказчика. Самое плохое — делать фичи ради фич, потому что они есть у конкурентов. Не факт, что эти фичи вообще используются и решают какую-то значимую проблему, за которые заказчик готов заплатить покупкой системы (с сопутствующими её «внедрениями»/интеграциями в свои рабочие процессы, плюс её последующее администрирование и поддержка).
• «Так сказал кто-то из топ-менеджеров». Часто там действительно что-то важное. Но нельзя принимать буквально, все равно надо копать до проблемы в надсистеме, потому, что в процессе будут возникать миллион вопросов по деталям, и без понимания надсистемы — не будет обо что опереться в выборе решения (тут упоминал идею, что процесс проектирования резко ускоряется, когда начинаешь правильно использовать функциональные модели, в том числе надсистемы).

Еще из любимых вопросов: «Вот допустим сделали, давай теперь представим как придем к заказчику и будем ему это „продавать“. Или представим (в идеале напишем) маркетинговую листовку/пресс-релиз/лендинг». Эффект такой же — либо понимаем абсурдность идеи, либо выявляется что-то ценное. Если после прочтения такой листовки/пресс-релиза/лендинга идея не покажется сильной — значит, что-то не так. Еще хорошо смотреть на него и спрашивать себя или собеседника: как думаешь, вот за это <список из выдуманного пресс-релиза> заказчик будет готов заплатить хоть сколько-то? Почему?

Про пресс-релиз подсмотрел у Amazon (подробнее про это в пятой главе книги Working Backwards: Insights, Stories, and Secrets from Inside Amazon) и вот первый пресс-релиз Amazon, построенный по этому принципу. А тут немного на русском.

Что еще показалось важным во втором разделе:

• Как думать о компьютерных программах (как о физических объектах, приносящих пользу в момент эксплуатации и что наши обязанности не заканчиваются написанием кода и его проверки на тестовом сервере) — это надо всем нам, айтишникам, вбивать в голову еще с универа. Очень советую почитать (доступ к тексту бесплатный, нужно просто зарегистрироваться)
• Про моделирование объектов в ИТ-системах (они должны адекватно отражать объекты физического мира) и как это потом кратно снижает сложность добавления новых функций и поддержку систем. Развернуто про это написано в книге Chris Partridge «Business Objects — Re-Engineering for Re-Use» (ссылка в сноске №100 на этой странице)
• «Аналитик» vs Инженер — один что-то описывает и делает документы-бумажки (рекомендации), а второй думает о том, как довести систему от задумки до эксплуатации в надсистеме (и вывода из эксплуатации) — то есть меняет мир. Речь не про должности, а роли! Тот, кто имеет в названии должности слово «аналитик» может вполне себе выполнять инженерную работу.
• Инженерный взгляд на обучение людей как на изготовление где-то у них в мозгу мастерства (которое возьмет на себя управление в нужной проектной ситуации)