turkhale

Я вел своих детей в детский сад и школу, и младшая спросила меня - а почему когда мы идем, то фонари двигаются на нас, а Луна улетает от нас, двигается туда же, куда и мы? Я немного подумал, и понял, почему так кажется. Дело в том, что люди воспринимают скорость как изменение угла и размера, а тут ни угол ни размер не меняется, и значит, далекие объекты кажутся нам неподвижными, или, если мы идем или едем, "двигаются" вместе с нами. В тот момент я понял, что машинально сделал то же самое, что делаю по работе - я смоделировал рабочую практику, в данном случае практику измерения расстояний. Я взял набор базовых фактов, про то, что фонари двигаются на нас и увеличиваются, а Луна двигается с нами и не меняет размер. Я взял концептуальную схему из трех понятий - угловая скорость, угловой размер, скорость наблюдателя, которая объясняет базовые факты и может достоверно их предсказать (когда мы пошли задом, Луна стала на нас надвигаться, а фонари поползли назад и уменьшились).

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

И эту задачу - построение модели практики - надо уметь выполнять, потому что нам все время надо сдавать дела другим, учить студентов, автоматизировать деятельность, а для этого необходимо понимать, что же мы делаем и не попадать в ловушку бессознательного контрруления, когда картинка в голове по тому, как делать работу, противоположна тому, что вы делаете по факту.

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

Системная инженерия наработала конкретные приемы:

- сортировки базовых фактов

- выделения вещей и событий

- классификации типов вещей и событий

- создания моделей и метамоделей рабочих практик на основе этих сортировок и классификаций.

Что такое практика?

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

Практика направляет действия команды по уточнению специфики решаемой проблемы, определяет стратегию ее решения и инструкции по тому, как проверять, была ли решена проблема до конца или нет. Модель практики определяет какие свидетельства и факты подтвердят решение проблемы и дает рекомендации по привязке подхода к реальным ситуациям.

Что такое модель?

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

Другие определения

Область обсуждения (universe of discourse, domain): совокупность физических или абстрактных объектов, относящихся к области реального мира, которые выбраны в соответствии с интересом, который они представляют для системы, подлежащей моделированию, и ее окружением.

Метамодель - модель, которая описывает другую модель.

Шаги создания метамодели практики:

Проблема 1. "3 километра терминов и определений". Решение - структурирование области обсуждения (domain partitioning and contexts definition). В хранилище проекта должна появиться папка "Область обсуждения".

Проблема 2. "А что такое вещь?". Работы как вещи, процессы и проекты как типы работ. Решение - определение состояний вещей, выделение стадии использования. Необходимо пересмотреть описания процессов и планы проектов.

Проблема 3. "Как объединить каталоги?". Решение - PBS, WBS, SBS и другие разбиения. Универсальных решений нет, но подход единый.

Проблема 4. Измерение неизмеримого. "Что измеряет панель Google Analytics?".

Решение - концептуализация предметной области как заказчика так и разработчика плюс операционализация концептов.

Создание и применение (мета)модели практики для выявления и прохождения развилок проекта (project and design trade-offs). Научные статьи как метод рефлексии над ходом проекта и принятыми решениями.

На столе стоит шашлык, салат, лепешки и свежее сациви. Теперь берем большую миску, сваливаем все туда и хорошенько перемешиваем. Состав не изменился, изменилась структура. Ни за что спутаешь одно с другим.

Структура не равна составу.

Управление составом изделия - это PDM, product data management, управление данными по изделию.

Состав - это компоненты. Управление составом - это планирование и контроль перечня компонентов и указанием какой компонент входит в какую сборку.

Управление структурой изделия - это MBSA, model-based systems architecture, системная архитектура.

Структура - это связи между компонентами. Управление структурой изделия - это планирование и контроль проектных решений, которые позволяют реализовывать требования к изделию.

Составом ПО не управляют, это бессмысленно. У ПО есть конфигурация. Управление конфигурацией - это CM, configuration management.

http://rsdn.org/article/Methodologies/CM_basics_part1.xml

http://rsdn.org/article/Methodologies/CM_basics_part2.xml

У изделий тоже есть конфигурация и она не равна составу и структуре. Но в паре предложений о ней не расскажешь, как минимум надо читать книжку:

Идея фоновой музыки для человечества в целом оказалась более сложной, чем теория относительности.

Больше 50 лет люди безуспешно пытались научиться слушать фоновую музыку, ее изобретатель, Эрик Сати, спился от горя (но попутно помог вырасти ДеБюсси), а мы и сейчас слушаем его произведения.

Ровно сто лет назад в парижском театре в антракте заиграл эмбиент. Инструменты были необычные - кларнет, тромбон и рояль. Публика, которая до этого прогуливалась по вестибюлю, тут же бросилась занимать сидячие места и тщательно вслушиваться в тихую однообразную, "скучную", как выразился сам Сати, мелодию. Он кричал, упрашивал гостей: "Да разговаривайте же, гуляйте! Не слушайте!", все было зря, они слушали и молчали. Вечер был испорчен. Сати был в ярости, ведь в афише гостям четко объяснялось, что "внимания этой музыке надо придавать не больше, чем люстрам, которые освещают холл". Но объяснить эти революционную идею было невозможно, люди привыкли слушать музыку, и не могли относится к ней как к фону.

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

Эти моменты надо учитывать при развитии продукта, если вы хотите, чтобы "он менял мир". Эрик Сати делал все, что делают современные стартапы - менял продукт, функциональность, сегменты, постоянно проводил демо-дни, продвигал-продвигал-продвигал, но успеха не добился. В тех сегментах, куда он заходил, не было практики использования музыки как фона. А как внедрять новые практики, в то время еще не знали, пропаганда и реклама только-только появлялись.

Ровно то же самое происходит со многими другими идеями - их просто продвигают не там и не так. Не этим ли должны заниматься менеджеры по продукту вместо того, чем они обычно заняты?

Представьте, что вы работаете в компании по разработке ПО и автоматизации и к вам приходит клиент. Она хочет автоматизировать какие-то бизнес-процессы. Вы высылаете к ней бизнес-аналитиков, они проводят интервью, пишут техническое задание на разработку. Иногда совместно с заказчиком вы строите модель предметной области, выясняете, какие штуки там есть, что с ними делают, как они между собой связаны, какие ключевые события происходят в ходе деятельности. Потом разрабатываете и внедряете ИТ-систему. Так вы автоматизируете деятельность заказчика. Но как вы автоматизируете свою деятельность?

Чем предметная область создания ИТ-систем отличается от предметной области клиента? Почему для автоматизации любой бизнес-функции нужны ТЗ, use case, user story, архитектура, настройки конфигурации, а для того, чтобы разрабатывать это никто даже ТЗ на Jira+Confluence не пишет? Ведь для каждого более-менее большого проекта будут свои процессы согласования, планирования, свой график встреч, свои технологии. Казалось бы, у вас как у разработчика ПО тоже есть процесс разработки, который должен быть нормально автоматизирован. Но я редко вижу, чтобы получив ТЗ заказчика и составив планы работ, команда принялась бы думать, как она автоматизирует свою деятельность, будет улучшать и поддерживать эту автоматизацию, пишет ТЗ на инфраструктуру разработки и описывает практики работы. Делает это все с использованием DDD, event storming и других штук, которые она применяет у клиента.

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

В любой деятельности есть два домена - предметная область заказчика и предметная область разработки и производства. Но если предметная область заказчика документируется и осмысливается, то предметная область разработки и производства формируется стихийно и развивается неуправляемо. Никто не пишет ТЗ на ее автоматизацию и не проводит тестирование того, насколько новая система документооборота решает проблемы организации. Это похоже на толстого тренера по фитнесу.

И это еще не все. Когда процесс разработки описан в Jira или системе управления документооборотом, он будет исполняться, потому что куда денешься. Но вот если разработка описана на флип-чартах, в картинках Visio или draw.io или в презентациях, то все гораздо хуже. Такие модели теряют связь с реальностью вот в каком аспекте. Мы рисуем квадратики, соединяем их стрелочками и под этим подразумевается наличие причинно-следственной связи между предыдущим квадратиком и последующими. Допустим, рисуют, что "Составили ТЗ" - "Сделали постановку задачи" - "Разбили задачи по исполнителям" - "Закодили" - "Протестировали" - "Сдали заказчику". Причинно-следственная связь подразумевает, что если убрать причину, то следствия тоже исчезнут "если бы мы не наняли Васю, то все было бы отлично". В случае простенькой модельки процесса наверху без ТЗ нельзя создать код и протестировать его. То есть создаваемый кусок кода должен отвечать на пункт ТЗ. В жизни сплошь и рядом происходит ровно наоборот - ТЗ живет своей жизнью, не связанной с кодом и техническими решениями. Модель попросту неверна, но слайды с ней гуляют по компании, светятся перед заказчиком и менеджментом, иногда по ней даже строятся планы и даются обещания. Которые, конечно, не исполняются, потому что модель не отражает реальность, в ней указаны несуществующие причинно-следственные связи.

Казалось бы, почти все видели-слышали в той или иной форме про цикл Деминга PDCA "запланируй - сделай по плану - сверься с планом - откорректируй план". План - это модель предметной области разработки и производства, развернутая во времени. Чтобы план был адекватным, модель предметной области разработки должна быть адекватной. Для этого надо постоянно ее тестировать, сверять веселые картинки с тем, что происходит в жизни. Я пользуюсь простым правилом - пока диаграмма или план не переписана хотя бы раз 10, а лучше 20, верить ей нельзя, это просто какой-то набор базовых предположений, далекий от того, что происходит на деле.

Выводы? Если пишите ТЗ для заказчика, то почему бы не написать его и для себя? Почему бы не описать предметную область разработки? Может обнаружиться куча нового, вы поймете, где есть разрывы процесса, где возникают недопонимания, где находятся риски. Станьте заказчиком на автоматизацию сами для себя.