Домашнее задание седьмой недели «Системного саморазвития»
Мне понравился 11 пункт из вопросов на повторение и дальнейшее изучение. Полностью он звучит так: «Почему стадии замысливания и проектирования становятся всё более важными, чем стадии производства и эксплуатации? Какие описания и каких систем создаете вы? Какие системы описывают документы вашего предприятия, с которыми вы имеете дело?»
Начну с конца, а потом вернусь к самому первому вопросу, который вынес в заголовок. И за одно расскажу про то, что у меня есть в Картотеке на тему гибких методологий разработки для «железных» систем.
Какие системы описывают документы вашего предприятия, с которыми вы имеете дело?
Я аэрокосмический предпринематель, основатель небольшого стартапа, который разрабатывает космическую систему пико-класса. Маленькие спутнички, которые помещаются в руку.
Так как это стартап, да еще на ранней стадии, то в основном наше предприятие генерирует описания того, как оно будет выглядить в будущем. Упор делается на предпринемательские практики: выявление потенциальных заказчиков и инвесторов — внешние проектные роли. И на возможности, которые позволяют, вообще, вести диалог о том, что такая система нужна.
Какие описания и каких систем создаете вы?
Ну, а лично мне приходится делать очень большое количество описаний, во всех трёх крупных ролях: предпринемательсткой, инженерной и менеджерской. От всё тех же презентаций (питчей) для внешних проектных ролей, до описания архитектуры будущей системы и отслеживанием её претворения в жизнь через таск-трекеры.
Почему стадии замысливания и проектирования становятся всё более важными, чем стадии производства и эксплуатации?
Теперь возвращаемся к самому первому вопросу. Системная инженерия, как мы её сейчас знаем, во многом берет своё начало из аэрокосмической отрасли. И есть классический пример, показывающий стоимость ошибки, в зависимости от того, на какой стадии жизненого цикла он найден.
Если за единицу принять стоимость устранения ошибки на этапе выявления требований к системе, то на этапе проектирования стоимость утроится. На этапе рабочей конструкторской документации увеличится на порядок. К моменту верификации и валидации уже увеличится на два порядка. Ну а на этапе эксплуатации исправление ошибки может стоить в 1000 раз больше.
Поэтому даже в такой консервативной отрасли как космос перешли от линейной (водопадной) модели к итеративным. На верхнем уровне, это всё та же stage-gate модель, но каждый этап, это очередная итерация.
Основная мысль этой части моего доклада — чем сложнее система, тем дороже её менять на этапе эксплуатации.
Agile
По моим наблюдениям среди слушателей ШСМ очень много программистов. Для них гибкие (Agile) методологии разработки не в новинку: Scrum, Kanban, Lean startup, RUP (Который много упомниается с системном мышлении). Действительно, для систем, которые состоят из битов информации, такие методологии драматически увеличивают скорость разработки.
Причем это не обязательно должны быть программные продукты. Анатолий в соём бортовом журнале часто повторяет «Release early, release often». И в случае с ШСМ имеются в виду образовательные продукты Школы.
Для релиза программного продукта накладные расходы настолько малы, что частая ошибка программистов — вообще про них забыть. Биты перемещаются по оптическим кабелям, медным проводам, по воздуху со скоростью света и их доставка стоит копейки. «Изготовление» системы происходит буквально параллельно её описанию (DevOps).
Но что делать, если вы имеете дело с «железной» системой. Не из битов, а из атомов? Да еще и из атомов дорогих композитных материалов?
Agile Hardware
Это тоже своеобразный ответ на первый вопрос. Почему стадии замысливания и проектирования становятся всё более важными? Потому что сейчас современное программное обеспечение позволяет смоделировать очень сложные физические системы. А битами ворочать сильно дешевле, чем атомами.
Поэтому чем больше мы работаем с описаниями и моделями, прежде чем воплотить систему в железе, тем вероятнее мы всё сделаем правильно с первого раза.
Однако, каким бы могущественным не было ПО и модели, они не отвечают на предпинемательские вопросы. А нужна ли разрабатываемая система? Процитирую Илона Маска: «Частая ошибка инженера — оптимизировать то, что не должно было быть создано».
Вспомнил я, конечно основателя SpaceX не просто так, потому что когда мы говорим про гибкие методологии в отношении «железа» то Tesla, SpaceX и Starlink, это наверное первое же, что приходит в голову.
Вот тут можно послушать интервью с Joe Justice руководителем направления Agile@Tesla, который занимался становлением этих практик на предприятии.
Но Tesla и SpaceX не единственные компании, которые придерживаются такого подхода. Yandex в своих командах по переоборудованию автомобилей в беспилотные тоже придерживается методологии Scrum (Глава «Про процессы»).
Что любопытно, если посмотреть на на настоящее, а в прошлое. То и Илон Маск не придумал «гибкий» подход. Еще в начале 50-х в американской компании Lockheed Martin было создано специальное подразделение SkunkWorks. Именно это подразделение создало такие легендарные летательные аппараты, как U-2 и SR-71. История захватывающая по своему содержанию, но в контексте моего доклада интересна тем, что в этом подразделении было сформулировано 14 принципов. Знатоки Agile-манифеста оценят.
Release early, release often
В заключении хотелось бы сказать, что принцип, конечно, применим и к системам из атомов. К сожалению, не всегда это возможно экономически, поэтому всё что может быть проверено на битах, должно быть проверено на битах.
Но ответить на предпринемательский вопрос — «а нужна ли замыслеваемая система?» иногда возможно только вопротив её в железе. Чтобы и этот процесс сделать дешевле, тоже появилось множество подходов, один из общеупотребимых — MVP, minimal viable product. Когда воплощение системы удовлетворяет только самую главную потребность надсистемы.
Но основной мотив — release early, это фальсифицировать всю идею тоже early. Лучше потратить деньги и провалиться быстро, закрыв дальнейшую трату ресурсов. Чем годами тратить бюджеты, на создание того, что не нужно.
