Развитие системы
Неформальные работы по замыслу новой системы обычно начинаются задолго до формального старта первого проекта в работах по созданию и развитию системы (первого жизненного цикла проекта в полном жизненном цикле системы, если придерживаться старой терминологии создания одиночной системы без её развития). Замысел системы появляется постепенно, его точное начало обычно трудно определить. По факту, проект начинается в тот момент, когда визионер и бизнесмен договорились: визионер считает, что предложенное инженерами решение можно будет выгодно продать, а бизнесмен считает, что это будет полезно фирме --- соответствует стратегии, не отвлечёт ресурсы от других дел, не принесёт каких-то репутационных убытков, не испугает инвесторов и т.д. (визионер смотрит на товар и клиентуру, а бизнесмен --- на фирму и инвестуру).
В последней версии ISO 15288:2015 даже появилась новая практика «6.4.1. Business or mission analysis process». Суть этой практики --- понять, какую целевую систему берётся делать команда, и определить, стоит ли её вообще делать, соответствует ли это стратегии компании, чья команда будет выполнять проект. Хотя ISO 15288 и содержит в себе отражение «водопада» в части стадий и V-диаграммы в части практик, но даже однократное прохождение жизненного цикла (без развития системы) как-то надо начинать! На старте проекта готовится концепция использования (OpCon или ConOps, concept of operations), но чтобы разобраться, не утопично ли создание системы, проводятся оценки и концепции системы (ибо можно написать отличную концепцию использования скатерти-самобранки, но потом обнаружить, что её не из чего сделать, система утопична).
Окончание жизненного цикла системы на сегодня обычно не планируется, хотя вполне могут обсуждаться ожидания по выпуску первой версии продукта (обычно это MVP --- minimal viable product, минимальный жизнеспособный продукт, который и будет потом развиваться).
Дальше система может модернизироваться так, что в её воплощении не останется уже ничего от предыдущей. Берём швабру, через некоторое время ломается ручка, меняем ручку, потом меняем перекладину --- это та же швабра? Да, это та же швабра-система (функциональный объект тот же!), только поменялись какие-то модули, конструктивные части. Швабра определяется по её функциональному описанию, если заменить наполнение конкретными модулями или даже поменять размещение, ничего страшного с системой не произойдёт --- она останется существовать. Телефон остался телефоном, хотя там уже давно нет проводов, трубки, кнопок номеронабирателя, ни одного элемента классического телефона, просуществовавшего больше сотни лет. Но осталась функция передачи звука на расстояние: теле (далёкий) фон (звук). Хотя и это уже не главная функция, телефоны перестали звонить и используются как терминалы доступа к интернету --- а звонки массово заменяются чатами.
Microsoft объявила, что Windows 10 будет её последней операционной системой, при этом непрерывно производит в ней изменения (выпуск Windows 11 широко обсуждался как имеющий чисто маркетинговое значение, смена названия не привела к тому, что сам продукт существенно изменился, более того, изменения в Windows 11 проходят примерно так же, как в Windows 10 --- программы и функциональность потихоньку меняется, но не меняется имя продукта. Просто одни программы в составе Windows потихоньку меняются на другие, это происходит уже много лет). Срок службы атомных электростанций сначала делали 60 лет, но сейчас продляют его до 80 лет, проводя частичные модернизации --- при этом часть стран хотят избавиться от атомных станций, а часть стран как раз хочет развивать атомную энергетику. Тесла придумала софтверные изменения для автомобиля, поддерживающие его ценность путём модернизации по ходу эксплуатации, электромобили Tesla не нужно вовремя продавать, они перестают морально устаревать: это изменение бизнес-модели автомобильной промышленности[1].
Жизненный цикл системы оказывается не содержащим чёткое заранее определённое число проектов перед выводом из эксплуатации/уничтожением после использования, и может не иметь чёткого срока окончания. И тем самым понятие «жизненного цикла» перестаёт быть важным. Можно говорить о жизненном цикле организма динозавра, но труднее говорить о «жизненном цикле» вида динозавра, который потихоньку за десяток миллионов лет, или чуточку подольше превратился в птичку. Это уже «ход эволюции» (развития системы, изменения в геноме, ведущие к изменению фенома), а не «жизненный цикл» создания одной системы (геном воплощается в свой феном, феном «прокачивается» и используется --- и конец истории).
В атомной промышленности даже случилась терминологическая коллизия: управлением жизненным циклом (lifecycle management) там называют не практики управления жизненным циклом из системного подхода, а практики продления срока эксплуатации атомных станций[2]! К счастью, по мере распространения знаний системного мышления среди работников атомной промышленности, значение термина меняется на общепринятое.
С вот этой «неоканчивающейся/open-ended разработкой» связан ещё один вариант показа жизненного цикла --- как развёртки во времени выпуска версий какой-то системы, roadmap/дорожная карта. Этот термин пришёл из проектного управления[3], но всё чаще используется для показа ориентировочных сроков выпуска версий системы. Вот пример жизненного цикла с упором на практики не столько инженерии или менеджмента, сколько на практики предпринимательства[4] --- с совмещением с дорожной картой (показаны три продукта разной степени готовности):
https://cleantechnica.com/2020/08/29/tesla-introduced-a-business-model-the-world-has-not-seen-before/ ↩︎
Например, https://www.iaea.org/newscenter/statements/nuclear-power-life-cycle-management-managing-nuclear-knowledge-and-nuclear-security --- тут «управление жизненным циклом» чётко связывается не со способом назначения практик на работы, а с удлинением срока службы энергоблоков АЭС. ↩︎
В проектном управлении это диаграмма основных контрольных точек проекта, https://www.productplan.com/roadmap-basics/ ↩︎
https://hackernoon.com/crafting-your-perfect-product-roadmap-7b42b1033c4e ↩︎