Проектируем умный дом с использованием методов бизнес-анализа

Умные гаджеты с нами давно: на руке — личный помощник в формате часов, на полу — автономный пылесос. Даже с колонками мы разговариваем, как с живыми. Наши квартиры тоже стараются стать умными, хотя это у них получается хуже, но не потому, что на рынке недостаточно качественных устройств. Напротив, каждый день появляются новые удобные способы автоматизации рутинных дел. Однако когда сталкиваешься с этим лично, теряешься в поиске подходящего решения. В результате — часто оказываешься с очередной игрушкой вместо полезного устройства. 

По сути, проектирование умного дома можно сравнить с проектированием ИТ-системы, а значит для получения нужного результата полезно использовать проверенные практики из ИТ-проектов. В этой статье рассмотрим алгоритм проектирования умного дома с использованием методов из практики бизнес-аналитика, сделав акцент на сборе и описании требований. Вы же хотите, чтобы умный дом делал то, что нужно именно вам?

Более того, предложенный алгоритм можно использовать при решении широкого спектра задач. Сначала он может показаться трудоемким, но результат вас точно порадует. 

Почему собрать умный дом или спроектировать любую другую систему не так просто

Почему продажи компонентов умных домов растут, а дома никак «не поумнеют»? Вероятно, потому что маркетинг важнее фактической пользы. Приобретение таких устройств — это спонтанная покупка из серии «какой крутой гаджет! Мне тоже нужен такой». Далее возникают обязательные дополнительные покупки — хаб к лампочке или многочисленные датчики для охранной системы, о которых в первый момент даже не задумывались. При успешном исходе возникает желание еще улучшить систему, но оказывается, что у выбранного бренда нет подходящих устройств или же они требуют доработки/нестандартного применения.

В этом случае, покупатели сталкиваются с тремя сценариями:

• кусают локти и покупают, что есть, часто со значительным превышением бюджета
• отказываются от расширения функциональных возможностей системы умного дома
• дополняют систему официально несовместимыми устройствами.

Все это не добавляет радости от приобретения.

Впрочем, есть еще один вариант. Он возможен, когда при выборе заранее описаны и учтены все возможные сценарии как для текущей конфигурации, так и для будущих расширений, или когда бренд выбран удачно, что там есть все необходимое.

Как я уже упоминал выше, проект умного дома можно сопоставить с процессом разработки IT-продукта. Тогда получается, что: 

• бренд = технологический стек (набор технологий) или вендор
• компоненты = конкретные функции системы
• ограничения на установку = нефункциональные требования к производительности, окружению, безопасности.

А значит для проектирования умного дома можно рассмотреть базовый алгоритм проектирования системы из практики бизнес-аналитика.

Забегая вперед скажу, что даже при использовании этого метода все может быть далеко не так однозначно, как кажется.

Алгоритм бизнес-анализа для выбора производителя и компонентов умного дома

Итак, попробуем рассказать об основных методах работы в бизнес- и системном анализе, которые не касаются напрямую технических вопросов, о сборе и формализации требований. Как и в любом другом проекте, на этом этапе происходит формирование границ проектируемой системы, ее качеств и ограничений, а также закладывается возможная этапность реализации. 

Прежде всего, стоит определиться с методологией разработки проекта и, собственно, самого этапа сбора требований. Если мы создаем проект дома с нуля — идеально подойдет Scrum, в котором мы поочередно детально прорабатываем каждую фичу. При капитальном ремонте лучше выглядит Waterfall: все спроектировали, провели, установили, проверили и готово. 

А как быть, если ремонт уже готов или ограничен временем/бюджетом/исполнителями? Конечно, выбирать итеративную или гибкую Agile-методологию. В этом случае придется неоднократно возвращаться к предыдущей работе и снова выполнять один и тот же набор действий, определяя наиболее важные моменты будущего умного дома. Если все получится с первого раза, советую перепроверить.

Обычно на проектах принято начинать с функциональных требований. Но опытный аналитик скажет, что нефункциональные требования и ограничения оказывают не меньшее, а иногда и большее влияние на проект, поскольку содержат критически важные для существования проекта параметры. Именно они могут заставить пересмотреть все требования, переписать ТЗ, сделать переоценку проекта и даже сменить команду, если потребуется менять вендора или стек.

Шаг 1. Описываем нефункциональные требования и ограничения — условия дома

Нефункциональным требованиям часто уделяется недостаточно внимания, нередко их собирают в последнюю очередь. Для модификации устоявшихся систем это может быть оправдано, ведь нет никаких причин что-то менять, если нет явной задачи. Но в новых проектах требования к безопасности, восстановлению или масштабированию вполне могут сделать проект на порядок дороже или сложнее, если не уделить им внимание в самом начале. 

Общие нефункциональные требования, которые входят практически в каждое ТЗ, в приложении к умному дому несут ряд существенных ограничений:

1. Безопасность: «Система должна использовать только управление с устройств, требующих аутентификации, то есть со смартфона и/или планшета».
2. Производительность: «Система должна обслуживать трех пользователей и 17 компонентов, распределенных по площади в 65 кв.м. без снижения производительности». Это можно транслировать как требование к возможности одновременного доступа с нескольких устройств без значительных задержек, а также к передаче управления на другое устройство или другому человеку.
3. Доступность: «Система должна обеспечивать удаленный доступ по сети Интернет без использования VPN». Соответственно, пользователь не обязан обеспечивать ее работу, применяя дополнительные сетевые настройки, например, для подмены региональных ограничений.
4. Техническое обслуживание: «Система должна обеспечивать обслуживание неквалифицированным персоналом». Как ничто другое подходит для умного дома.
5. Восстановление после сбоев: «Система должна обеспечивать замену модулей, сменных батарей и автоматическое восстановление». 
6. Юзабилити: «Система должна быть простой в использовании» — требование, которое всегда нужно уточнять цифрами. Например, так: «система должна обеспечивать запуск основных функций по одному клику».
7. Совместимость: «Система должна быть совместима с компонентами других экосистем умного дома». Во многих случаях это практически невыполнимое требование, которое влечет за собой серьезные ограничения функциональности.
8. Юридические вопросы: «Система должна соответствовать всем применимым законам и правилам». Об этом обычно не вспоминают, но в частном случае это требование работает, поскольку китайские роутеры имеют большую мощность и не соответствуют законодательству РФ.

Более детальные требования позволяют резко сузить выбор компонентов и систем:

• «Система умного дома должна обеспечивать работоспособность в пределах дома без подключения к сети Интернет».
• «Система умного дома при работе должна поддерживать как местные, так и зарубежные стандарты подключения к сети 220В». Формат розеток умного дома может оказаться критическим для многих владельцев китайских гаджетов.
• «Система умного дома должна обеспечивать работоспособность компонентов не менее года без замены батареи».

Подобным образом можно описать много аспектов. В итоге они оказываются не менее важны, чем функциональные требования, так как зачастую могут полностью заблокировать тот или иной вариант.

Шаг 2. Определяем функциональные требования в виде UserStory

Основу любого ТЗ составляют именно функциональные требования. Проще всего описывать их в формате User Story — кратких предложений формата:

Я, как _____, хочу, чтобы _____делала _____, для того чтобы ____
 

User Stories могут быть практически любыми — в этой простоте и гибкости их огромное преимущество:

• Я, как владелец квартиры, хочу включать музыку из любой точки дома, чтобы создавать атмосферу.
• Я, как житель квартиры, хочу открывать/закрывать шторы голосовым управлением, чтобы не вставать из постели.
• Я, как владелец квартиры, хочу получать своевременные оповещения о протечках на свой смартфон, чтобы своевременно перекрыть подачу воды.

Можно немного усложнить работу и создать второй набор, который будет описывать функции от лица владельца компонентов. Например, 

• Я, как пользователь интегрированной в систему умного дома колонки, хочу иметь возможность отключать ее от прочих устройств, чтобы гарантировать отсутствие случайных срабатываний и трансляции голосовых сообщений.
• Я, как пользователь умного холодильника, хочу заказывать продукты в разных магазинах, чтобы не привязываться к единственному партнерскому.
• Я, как владелец умных штор, хочу закрывать их по расписанию, синхронизированному с закатами.

Безусловно, важно не забыть и про негативные сценарии, хотя они не всегда могут быть очевидны. Так, при выборе умного дома может стать критичным требование: «Я не хочу использовать умный дверной замок без физического ключа, чтобы всегда иметь возможность открыть дверь даже без Интернета и электричества».

Универсального рецепта в данном случае не найти. Каждый должен записать свои истории.

Шаг 3. Описываем пользовательские сценарии без привязки к дизайну компонентов и управляющих приложений

Чаще всего пользовательских историй недостаточно для детального описания работы системы. Дьявол прячется в деталях: если набор историй окажется коротким или неверно составленным, ряд ограничений при работе компонентов останется незамеченным. Именно для этого существует детальное описание взаимодействия в виде Use Case — «сценария использования». 

Формат предполагает много вариантов, но самый удобный для начинающего — простой текст, который включает:

1. Название.
2. Предусловие — начальное состояние системы.
3. Действующие лица — роли в системе, которые могут быть задействованы при реализации сценария. 
4. Триггер — событие в системе или действие ее пользователя, которое приводит к запуску описываемого сценария.
5. Основной сценарий — по пунктам, здесь заголовок говорит сам за себя.
6. Постусловие — конечное состояние системы.
7. Альтернативные сценарии. Если основной сценарий может выполняться по-разному в зависимости от условий, эти различия описываются здесь.

Важно учесть, что сценарий может быть как строго пользовательским для описания действий пользователей, так и системным или смешанным с участием взаимодействующих между собой систем. Хорошим тоном в аналитике считается разделение системных и пользовательских сценариев. Тем не менее, смешанные сценарии также имеют право на жизнь, особенно при сложных взаимодействиях между пользователем и системой.

Создание сценария позволяет детализировать требования и выяснить на первый взгляд неочевидные вещи. В данном случае — настроить синхронизацию с календарем восходов/ закатов или дополнить сценарий действующим лицом в виде датчика освещенности, который позволит учитывать фактическое количество света за окном. Вдруг без этой функции целесообразность покупки резко падает до нуля?!

Шаг 4. Задача со звездочкой: как должен работать умный дом на схеме

Кроме уже упомянутых функциональных и нефункциональных требований, в данной задаче играют большую роль системные требования. Часто их выносят в разряд нефункциональных на первом этапе проектирования системы, но для домашней системы автоматизации имеет смысл рассмотреть их отдельно. 

Среди них могут быть критические «блокеры» — требования, которые делают создание системы невозможной. Например, необходимость общения каждого компонента с удаленным сервером, что используют некоторые бюджетные бренды. Камеры некоторых многоквартирных домов имеют удаленный сервер в Китае, подключение к размещенному в подъезде файловому серверу осуществляется через облако, что не соответствует здравому смыслу.

В перечень системных требований стоит включить:

• Совместимые операционные системы.
• Используемые протоколы связи компонентов умного дома.
• Используемые протоколы связи для выхода в Интернет.
• Используемые стандарты питания компонентов.
• Используемый формат корпусов компонентов.
• Используемые каналы распространения обновлений.
• Наличие/отсутствие механических дублеров для электронных цепей в составе компонентов.
• Наличие возможности перехода на ручное управление с компонента или отдельного управляющего устройства.

Шаг 5. Описываем критические параметры — критерии успеха, границы системы и важные значения для тестировщика

Хотя в ряде случаев критерии успеха остаются за пределами ТЗ, пренебрегать ими не стоит. Именно здесь важна стоимость по отношению к функциональным возможностям системы. 

Да, на этом этапе обязательно нужно определить границы предполагаемых затрат и сформировать дорожную карту по созданию системы. Это можно проделать и с требованиями, которые в системе будут критически важны. Зачем вам умный дом с избытком компонентов, если другой вендор предлагает тоже самое, но в меньшем количестве корпусов и за меньшую стоимость? Но нельзя пренебрегать и общим, итоговым представлением функционирования системы: одно дело записать требования, другое — представить себе ее работу и попытаться описать базовый тестовый сценарий, выход за пределы которого будет критичен.

Выбираем важное с помощью табличных методов анализа

Когда будут выявлены основные сценарии, необходимо свести самые важные требования и параметры в одну таблицу. В нее же внести названия компонентов и/или систем и проставить напротив каждого, что поддерживается, а что — нет:

После такого сравнительного анализа можно разделить параметры на блоки важных и критических, представить в виде матрицы приоритетности требований (Requirement Prioritization Matrix):

Далее достаточно просто оценить каждую систему, выделив наиболее важные требования. При этом у каждого владельца системы может получиться свой результат, поэтому советуем опросить всех членов семьи, вдруг какие-то вещи станут для них неприемлемыми.

После всей проделанной работы ваш умный дом обязательно будет делать то, что нужно.

Где и как можно применить этот алгоритм еще раз

На самом деле, реализовать User Story и Use Case с табличным анализом можно практически в любой сфере. Особенно удобны эти методы там, где явные цифры для сравнения разных предложений отсутствуют или требуют сложной параметризации. Как правило, это любой выбор, когда нет исходных данных, начиная от удобного маршрута и заканчивая выбором квартиры, или «гуманитарные» процессы. Яркими примерами такого «процесса» может быть движение автомобилей по городу, оценка качества или удобства жизни в микрорайоне, а также любой социокультурный процесс, поддающийся хоть какой-то математической оценке.

Точность описанного метода мы закладываем сами: чем больше важных для себя историй и сценариев мы опишем, чем скрупулезнее проведем оценку их важности, тем лучше будет результат.

Хотя представленный механизм кажется громоздким и трудоемким, после того, как все стадии будут пройдены несколько раз, любая возникающая аналитическая задача автоматически становится на рельсы этого алгоритма. Мозг научится предлагать UserStory для всего и через десяток решенных таким способом задач вы перестанете задумываться о ходе решения.