Очень трудно идет курс по Системному менеджменту, поэтому пока переключился на Прикладное системное мышление. Но «хвосты» по заданиям СМ остались. Один из них — прочтение книги «Configuration management for senior managers»
В очередной раз декларирую, что никогда на крупных производствах не работал, а наша отечественная космическая отрасль тем известна, что тут до серии, мне кажется ни одно изделие не доживает, сплошь и рядом только опытные образцы.
В книжке видно, что речь идёт о производствах, производствах серийных, а у меня перед глазами всегда были только в самом лучшем случае Опытная партия. Но с другой стороны, для многих вещей, которые выводятся в этой книге существует нормативная документация.
И при чтении были скорее моменты «Ах вот, зачем это нужно!», и перед глазами возникал то наш «нормоконтроль», то «ОТК». Так, например, извещения об изменениях КД — на это есть ГОСТ 2.503-2013.
Но что интересно, почти все проблемные ситуации в разработке приборов связаны были, именно, с конфликтом конфигураций. Возьмём те же самые извещения об изменении. В подавляющем большинстве случаев их оформляют постфактум, как «тебеотчёт». Работа между конструкторами идёт в рабочем режиме обменом трёхмерных моделей. Но вот, изделие попадает в цех для сборки, и там следуя всем инструкциям запрашивается КД из архива, и сборка осуществляется по КД, которая уже на порядок итераций отстаёт от 3D модели, который орудуют конструктора. Сборка встаёт, и все бегут оформлять извещения об изменении, чтобы привести в соответствие описание и реализацию системы.
Главенство формы над содержанием
В нашей нормативной документации очень большое внимание уделяется форме документации. На практике это иногда почти всегда приводит к абсурдной ситуации, когда есть поток работ «как надо»/для дела, и поток работ «как хотят видеть»/«По ГОСТ». Есть документация, с которой работают люди, в примере выше — это 3Д модель, и есть документация, которая лежит в архиве.
Вот их соответствие тоже должно попадать во внимание контроля версий и конфигурации. По моему мнению лучше всех в контроле конфигурации преуспели айтишники. На столько, что для контроля «тебе» и «себе» отчётности в КД мы тоже используем GitHub, где храним документацию в plain-тексте с MD. И это «точка истины», с текстом тогда очень удобно работать, видно кто что поменял, что добавил и т.д. А чтобы сформировать документ «по ГОСТ» используются домашние хаки на основе GOSTdown (https://gitlab.iaaras.ru/iaaras/gostdown).
За знакомство с этим проектом отдельное спасибо преподавателю кафедры технологического предпринимательства МФТИ Михаилу Бухарину.
Использование информационных систем
В распутывании конфигурационных коллизий очень помогает документирование. Частично затрагивал это в заметке «Лабораторный журнал». Если люди пишут заметки о своей работе, пользуются корпоративными хранилищами, электронной почтой, мессенджерами. То остаётся очень много «хвостов» по которым коллизию можно распутать. Microsoft Office пишет какой пользователь последним правил файл, даже если не включен режим рецензирования. Файл приложенный к сообщению в чате видно когда был создан и так далее.
Это всё если и не решает задачи управления конфигурацией, но точно делает легче «расследование». В тех случая, когда они требуется.
В противовес тому, что кто-то о чём то договорился и никаких следов этому договору нет. Это очень частый случай в маленьких командах, когда один и тот же человек играет разные роли. Нет у него никакой мотивации отчуждать от себя знания. С точки зрения здоровой психики люди редко задумываются, что они «Сами с собой сейчас договорились», хотя с точки зрения «Театральной метафоры» так оно и есть!
Выводы
Выводы у меня от прочтения книжки такие:
- Чем меньше ответственных за что-то, тем больше ответственности. Когда на изменении должны расписаться 12 человек, то ответственность размазывается тонким слоем по всем и не принадлежит никому. (Без шуток у меня в практике были случаи, когда получив подпись у нижнего в списке, верхние менялись)
- Изменения обязательно нужно учитывать. Любым способом, но всегда должен быть метод ответить что и как поменялось.
- «Паразитных» изменений категорически не должно быть. Под «паразитным» я понимаю изменение которое сделано без ведома ответственного, или неучтённого.
- Изменения внутри контура над которым есть контроль еще можно не учитывать подробно. Но всё что уходит за пределы организации должно быть зафиксировано самым тщательным образом.
Выводы, наверное, наивные. Но я пока что бесконечно далёк от серийного производства. А с коллизиями конфигураций сталкиваться приходилось. О том, к чему могут привести проблемы с управлением конфигурацией на предприятиях с тысячами человек могу только догадываться.