К заданию из курса Системной инженерии, расскажу об опыте разработки концепции разработки продукта - системы сбора территориально распределенных данных.
Ситуация: мы, как компания - системный интегратор, довольно часто сталкиваемся в своих проектах с требованиями собирать данные "в полях", где нет никакой инфраструктуры. Например, температуру, или состояние люка: открыт/закрыт, или данные промышленной телеметрии. Каждый раз убеждались, что идеально подходящего под наши запросы готового продукта на рынке нет. В один (прекрасный) момент мы оценили свои силы и потенциальные выгоды, и решили разработать свой продукт.
То есть, с точки зрения курса, задача не совсем “честная”: определенного, известного конечного заказчика у нас в тот момент не существовало и отсутствие требований было естественным следствием из этого факта. Мы сами описывали для себя концепцию системы. Передовые практики, но не от хорошей жизни.
Сценарий использования был такой (мы еще не доросли до использования у себя user stories): пользователю, контролирующему состояние надсистемы, необходимо периодически, несколько раз в сутки, получать состояние с датчиков на удаленных объектах, не оснащенных системами электропитания и связи. К чему стремимся, пожелания, nice-to-have:
- Хорошо бы было, если бы система была необслуживаемой выживала в поле 365/24/7.
- Хорошо бы было, если бы система была масштабируемой и совместима с большой номенклатурой датчиков.
- Хорошо бы было, если бы система самостоятельно определяла периодичность сеансов связи с центральным постом, исходя из своего состояния и показания датчиков.
Сформировали команду из опытных инженеров с набором требуемых компетенций. Так как со сработанностью и компетенциями все было хорошо, а общее направление движения известно (те самые взаимное доверие, интуиция на кончиках пальцев и фокус на общей цели из описания идеальной команды в OODA), то мы просто дали команде работать, регулярно обсуждая с ней результаты. Естественным образом получилось, что каждый в команде играл, в зависимости от ситуации, и роли и архитектора, и разработчика.
Первое модульное разбиение было очевидным - центральный пост управления и сбора данных, и непосредственно система в поле. После первых прикидок требований к автономной системе энергетики, особенно с учетом спутниковых каналов связи, стало понятно что модуль коммуникации и непосредственно модули сбора данных с подключенными проводными датчиками лучше разделять - ведь в этом случае у нас появляется возможность собирать и отправлять на центральный пост данные с нескольких точек сбора данных.
Есть разбиение на три модуля, есть требования к надежности и масштабируемости - далее приняли важные решения по реализации системы. Самым важным был выбор протокола взаимодействия между модулем коммуникации и модулями сбора данных. Здесь селали ставку на стандарт Lora, на Хабре вышла недавно хорошая статья про его преимущества.
На следующем этапе (функциональном, по времени эта активность размазана) команда делала ключевые сравнительные решения по развилкам, балансировала пожелания к системе. Чаще всего рамки ставили энергетический баланс системы и стоимость его компонентов. Стоимостная составляющая была важна, потому что мы делали продукт для рынка со своей добавленной стоимостью. Энергопотребление ограничено количеством энергии, которое мы можем получить от солнечных панелей и сохранить в аккумуляторах. Жалели, что нет возможности использовать РИТЭГ. По практикам разработки мы находимся в середине, если не в конце пелотона. Команда не использовала жестко описанных процессов работы с требованиями, равно как и не было программных инструментов для отслеживания требований. Артефактами были несколько документов на общем сетевом ресурсе. Основными были: текстовая пояснительная записка с описанием системы, табличный расчет энергетического баланса системы и ведомость материалов со стоимостным описанием. Команда редактировала их, постоянно уточняя содержание. В моменты развилок сохраняли версию документов, чтобы контролировать конфигурацию и иметь возможность сравнения и возврата в случае провального выбора.
Также, делали прикидки компоновки полевых модулей в 3D редакторе.
Уроки полученные:
Во-первых, отсутствие обратной связи от клиентов - это боль. Да, решение о разработке продукта "в стол" было принято осознанно, но в следующий раз хотелось бы иметь больше информации о нуждах заказчиков.
Во-вторых, надо иметь описание концепции системы в одном документе и структурированном, хотя бы табличном, виде - чтобы сразу проверять поступающие пожелания на конфликты и противоречия с существующими, делать осознанные и описанные согласования.
В-третьих, убедиться, что при приеме ключевых решений в разработке продукта нам не надо ожидать информации от внешних стейкхолдеров. Были ситуации, когда команда "подвисала" в состоянии развилки на несколько недель, потому что ждала информации от подрядчика - разработчика ПО. Возможно, стоит попробовать концепцию MOVE из практик TameFlow, не начинать задачу, если нет условий, для ее завершения.
