[Перевод] Системная инженерия, или за что мне платят деньги
Писать введения сложно, так что позвольте сразу перейти к делу. Я работаю консультантом. Обычно я работаю над проектами, в которых используется оборудование (электроника и механические детали), но преимущественно помогаю по части ПО: от кода микроконтроллеров до программ для десктопов, а иногда и для серверов.
Иногда меня приглашают для реализации чего-то конкретного, например, драйверов или proof of concept. Иногда меня приглашают, когда команда собирается переходить на Rust. Иногда меня приглашают, когда команда хочет превратить «прототип» в «продукт». По большей части я помогаю людям с основами системной инженерии.
Возможно, это тот случай, когда «у тебя есть молоток и все проблемы похожи на гвозди». Возможно, для меня системная инженерия стала ошибочным способом решения всех задач.
Тем не менее она работает и помогает, поэтому я хочу продолжить стучать этим молотком. Может быть, когда-нибудь я напишу об этом книгу, а пока написал статью с неупорядоченными мыслями.
Мне не нужно вам ничего продавать (пока), и я обещаю, что в статье нет «волшебных пуль». Это просто рассуждения, которые могут помочь вам в ваших проектах.
Кроме того, я НЕ являюсь пуристом процессов и не придерживаюсь с религиозным пылом концепции системной инженерии. Иногда для решения проблемы нужно совсем немного моей работы. Иногда (особенно когда вы делаете что-то критически важное с точки зрения безопасности) нужно делать всё в полном объёме. Поступайте так, как вам кажется правильным. Если это перестанет помогать, найдите что-то ещё. В идеале все описанные в статье концепции начнут приносить дивиденды практически сразу же.
Что такое системная инженерия?
Может быть, у НАСА есть определение и получше, но для меня она соответствует следующим принципам:
- Чётко проговаривай, что ты создаёшь.
- Чётко проговаривай, как ты это создаёшь.
Кажется простым, так ведь? Ну, иногда это так и есть.
Когда всё начинает портиться?
Когда в вашем проекте появляется множество разных людей, иногда имеющих совершенно различный опыт (например, «разработчики ПО», «железячники», «менеджеры», «управляющие продуктами» и так далее), концепции «что мы создаём» и «как мы это создаём» начинают ускользать от команд и организаций.
Или когда ваш проект становится чуть больше предыдущего, или когда вам нужно заняться какой-то новой областью знаний, с которой вы знакомы не очень хорошо. То, что поначалу казалось простым, очень быстро становится сложным и, несмотря на упорный труд, проект не близится к завершению.
Как и в случае со многими другими best practices, с небольшими проектами или небольшими командами можно работать, не сталкиваясь ни с какими проблемами.
Однако проблемы в этой сфере похожи на хитрую сложность O(n^2). Поначалу всё хорошо, однако однажды всё взлетает по экспоненте, а график растягивается ещё на месяц, или на три, или на двенадцать.
Почему системной инженерией не занимается больше людей?
Ваша ситуация может отличаться, однако лично я увидел, что разработчиков ПО очень мало специально обучают этим темам. Они могут рассуждать о разбиении задачи на части для отдельного разработчика, но не имеют особых инструментов для разбиения «задач размером с команду».
«Классические инженеры» в сферах электрики и механики обычно сталкивались с процессами и процедурами системной инженерии, но не всегда осознают, почему существуют конкретные подходы.
Если в вашей организации ещё нет «культуры» системной инженерии, то никто и не может внедрить её! И в таких ситуациях обычно приглашают меня.
Стоит заметить, что не обязательно доводить всё до аварийного состояния, чтобы вам помогло немного системной инженерии. Иногда приятно просто повысить предсказуемость процесса разработки и снизить количество сюрпризов.
«Джеймс, твоё определение системной инженерии всё равно предельно расплывчатое!».
Да, я пытался быть кратким. Давайте немного развернём определение.
▍ Чётко проговаривай, что ты создаёшь
Если говорить формально, обычно этот принцип относится к сферам требований, спецификаций, архитектуры и/или нормативов. Можно подробнее объяснить, что я подразумеваю под этими темами, но это уже я оставлю на будущее.
Если говорить обычным языком, это означает: каждый, кто работает наш вашим проектом, должен однозначно знать, что этот проект должен делать.
Примечание: я буду использовать термины «спецификация» и «требования» как взаимозаменяемые. В этом разделе они будут обозначать «что должна делать ваша система».
Я буду часто повторять, что если информация не записана, её не существует.
- Вы никогда не знаете, имеют ли два человека одну мысленную модель. Если людей больше, ситуация усугубляется ещё больше.
- Вы никогда не знаете, целостна ли ВАША мысленная модель. Иногда что-то в голове выглядит логичным, однако, если запишешь мысли на бумаге, оказывается, что они противоречат сами себе.
- Вы не можете гарантировать, что ваше понимание не изменится со временем или что вы не забудете части своей мысленной модели.
Решение заключается в том, что вы обязаны записывать то, что должен делать ваш проект (код, оборудование — что угодно). Написанное не обязательно должно быть каким-то очень строгим.
Используйте документ с markdown. Записывайте в документ Word. Фиксируйте информацию в таблице Excel. Пользуйтесь чем угодно, но записывайте всё. Всегда проще перейти с одного носителя текста на другой, чем собирать информацию по частям в одно место.
Но что бы вы ни использовали, это плавно переносит нас ко второму пункту: вся ваша команда должна знать, где находится источник истины, как его просмотреть, а также иметь к нему постоянный доступ.
Если вы храните определение в Git-репозитории, а у менеджеров проекта нет к нему доступа (или они не знают, как его просматривать), то для них ваша спецификация бесполезна. Если ваша компания использует продвинутый инструмент для разработки требований, но не имеет лицензий для доступа к нему, то ваша спецификация бесполезна для всех.
Эта спецификация полезна только тогда, когда кто-то может спросить «Постойте, а как это работает?» и найти информацию быстрее, чем требовалось бы на неверную догадку.
Эта спецификация полезна только тогда, когда у двух людей возникли разногласия о том, как что-то должно работать, и они могут посмотреть, вместо того чтобы спорить или назначать совещание, чтобы «ввести всех в курс дела».
Чтобы эта ставка выиграла, нужно ещё одно правило: ваша спецификация должна быть точной.
Иногда возникают странные различия между «требования гласят, что система будет делать» и «требования гласят, что система делает». Но это более обширная тема для отдельного изучения.
Но в целом требования/спецификации должны быть точными.
Если требования гласят «система делает X», инженеры-электрики могут использовать это допущение, не обсуждая его с разработчиками ПО. Люди из отдела продаж должны иметь возможность указать это в маркетинговых документах без необходимости гадать.
Если у двоих (или более) людей возникают разногласия о том, что должна делать система, разрешать споры должны требования.
Я не могу совершить плавный переход к следующему правилу, так что вот оно: ваша спецификация должна быть удобной для чтения, поиска и получения информации.
Кто-то фиксирует «то, что делает система» в JIRA или тикетах GitHub. Но часто они пишутся в течение продолжительного времени. Как мы будем понимать, какие из них релевантны? Как узнать, какие из них изменились позже? Если у вас есть вопрос «сколько таких-то единиц может моя система обрабатывать за раз», то как вы найдёте на него ответ?
Поэтому я крайне рекомендую иметь общий актуальный на текущий момент документ.
Если требования непонятны или попросту ошибочны, то все должны знать, как изменять требования.
Требования должны быть актуализирующимся документом. Даже если вы используете что-то типа «водопада», ваше понимание системы со временем будет меняться. Людям могут потребоваться новые функции. Вы можете осознать, что какие-то целевые характеристики недостижимы или необязательны.
О том, как менять требования, мы расскажем ниже, но какой бы способ вы ни выбрали, каждый должен знать, как при необходимости «исправлять» или «улучшать» требования.
Наконец, вы должны иметь возможность убедиться, что система соответствует своим требованиям/спецификации.
Это может быть тестирование или ревью, но по сути принцип такой: вы должны иметь возможность «проверить на вшивость» любую часть требований/спецификации, чтобы понять, точна ли она. Подробнее об этом ниже.
TL; DR: Чтобы чётко проговаривать, что ты создаёшь:
- Запиши, что должна делать твоя система.
- Это должен быть единый актуализирующийся документ, который постоянно обновляют.
Он должен быть максимально полным (этого можно добиваться инкрементно!), НО
он ВСЕГДА должен быть точным. - Каждый должен знать, где его найти, как его читать, и в нём должно быть легко находить ответы.
- Каждый должен знать, как его изменять, если/когда там что-то изложено неполно или неточно.
- Вы должны иметь возможность убедиться, что система делает то, что должна, в соответствии с документом.
▍ Чётко проговаривай, как ты это создаёшь
Этот принцип затрагивает такие темы, как планы разработки систем/ПО, планы верификации систем/ПО, стандарты проектирования/кодинга, стандарты анализа и контроль документов.
С точки зрения процесса, в этой области происходит многое. К ней относится то, как вы проектируете или верифицируете систему, как определяете требования, вплоть до мелких деталей наподобие правил форматирования кода. Это совокупный итог того, что понадобится, например, новичку, чтобы узнать, как быть продуктивным участником команды.
Тут я должен повторить: если информация не записана, то её не существует.
В идеальном мире у вас должна быть возможность:
- пригласить сотрудника в первый день его работы,
- узнать, что у него есть доступы, прежде чем он начал,
- показать ему один документ (который может содержать ссылки на другие),
- он должен иметь возможность прочитать этот документ,
- он должен знать в целом, как начинать работать с вашей командой.
Эту информацию вы тоже можете фиксировать как хотите. Отлично подходят документы в markdown. Страницы внутренней вики тоже вполне сгодятся. В конечном итоге эти документы будут чем-то похожи на «технологические требования»:
- они постоянно должны быть актуализирующимися документами,
- все должны знать, где их искать,
- в случае возникновения разногласий, в «технологических требованиях» должен быть ответ, а если его там нет, вам нужно прийти к решению и записать его,
- неполнота вполне приемлема (однако в процессе нужно совершенствовать документ!),
- НО неточность неприемлема никогда.
Не нужно стремиться зарегулировать процесс вусмерть. Большинству команд не требуются строгие определения уровня критически важных для безопасности процессов. Но если вы делаете что-то каждый день (например, вносите пулл-реквесты, или проводите ревью кода, или проектируете печатные платы), то, возможно, стоит зафиксировать это в «практических руководствах», чтобы онбординг новичков проходил проще.
Если у двоих людей возникли разногласия о том, «как делать X», усадите их за стол, примите решение и запишите его. И потом не спорьте об этом, если только в будущем не возникнет веская причина изменить решение.
В конечном итоге, наличие записанного процесса помогает поддерживать согласованность. Согласованность — это здорово, потому что благодаря ей люди меньше тратят времени на разбирательства, как что-то сделать, и больше занимаются решением реальной задачи.
TL; DR: записывайте, как вы выполняете задачи.
Когда-нибудь я запишу несколько способов выполнения задач, которые вам, возможно, захочется использовать в качестве «разумных способов по умолчанию», но, честно говоря, вы можете делать то, что походит вашей команде. И запишите это, чтобы все были в курсе.
Подведём итог
Системная инженерия помогает с «метой» решения задач. Если у вас большая команда или большая задача, то стоит усесться и «решить задачу того, как сформулировать и решить задачу».
По возможности потратьте какое-то время ПЕРЕД началом работы, чтобы убедиться, что все готовы к работе над одним и тем же проектом и знают, что они должны делать. Если вы уже начали, то ещё не поздно, вы всё равно можете отлавливать проблемы раньше, чем если бы не применяли этот подход.
Вам не нужно для этого формальное образование. Просто начните записывать всё и сделайте так, чтобы все были введены в курс дела.
Единственное отличие между валянием дурака и наукой в том, чтобы всё записывать.
Telegram-канал с полезностями и уютный чат
