by Для большинства программистов или системных администраторов, ответственных за создание программного обеспечения, код – утилитарное дело, задача которого решить проблему. Очевидно, что при создании производственного кода важно позаботиться о правильном синтаксисе, использовать правильные шаблоны проектирования, обработать ошибки и т.д. Все это, однако, вписывается в рамки мастерства и профессионализма.
Такой код может быть полностью создан человеком, иногда в его возникновении могут помочь автоматические генераторы и библиотеки, но результатом всегда должно быть то, что реализует спрос.
Десяток лет назад не было обсуждений и проблем, связанных с ожиданиями пользователя относительно того, как использовать программное обеспечение. Компьютеры были устройствами с ограниченным доступом, и по идее любой, кто садился за них, должен был обладать определенными техническими навыками. Таким образом, программа и ее интерфейс, имели определенную степень сложности, потому что разработчики создавали для других разработчиков.
Аналогичная ситуация была и с системами связи для государственных служб. Решение должно было быть надежным в повседневной эксплуатации. Кроме того, радиостанции, хотя и просты в использовании, имели одну цель: обеспечить голосовую связь. Сложности процесса настройки или изменения версии системы были в фоновом режиме и принадлежали специализированному персоналу.
Почему интуитивно понятный интерфейс – это крайне важно?
Сейчас ситуация совершенно иная. Программное обеспечение окружает нас на каждом шагу, и среднестатистический человек не только пользуется компьютером, но и окружен умными устройствами (телевизоры, телефоны, часы, полуавтономные автомобили, устройства IoT и, наконец, сервисы, доступные в облаке). Сейчас практически все знают, что в каждом смартфоне есть секундомер или таймер, каждый знает, где узнать рецепт того или иного блюда, а есть сервисы такие как калькулятор кальция позволяющие довольно быстро понять насколько сбалансирован Ваш рацион.
Такое разнообразие платформ, сценариев использования и сред, на которых будут работать приложения, для кого они созданы и кем будут использоваться, вносит еще одно, но очень важное требование – контекст. Уже недостаточно написать правильный, безошибочный код. Сегодня при проектировании и разработке программного обеспечения не менее важно, как конечный потребитель хотел бы использовать такую программу.
Как пользователь, мы ожидаем чего-то нового. Это еще более заметно в случае программного обеспечения, созданного для определенной цели и для ограниченной группы пользователей.
В случае мобильных приложений важны простота и интуитивность использования, бесперебойная работа или доступность новых функций и версий за одно нажатие, а также оптимизация потребления батареи и разумные объемы передаваемых данных, в то время как для облачных сервисов не менее важны надежность решения и множество программных опций и возможностей.
Повышение стандартов
Это означает, что недостаточно быть мастером в своей профессии, и при написании кода нужно учитывать не только критерии, касающиеся его формальной правильности, но и точку зрения потенциального пользователя. Это, в свою очередь, приводит к появлению дополнительных параметров, которые влияют на то, на чем создается программное обеспечение (язык, технология), каковы его основные KPI, но, прежде всего, они определяют общий дизайн такого программного обеспечения. Параметры программы декодирования музыки могут быть полностью удовлетворительными, но тот же алгоритм может вообще не работать при обработке разговора между двумя пользователями.
Чтобы проиллюстрировать это, рассмотрим рынок приложений для мобильных устройств. По данным на май 2020 года, Google Play содержит 2,65 миллиона приложений, а магазин приложений Apple – 1,85 миллиона. Неудивительно, что всякий раз, когда нам нужно, мы можем найти хотя бы несколько программ, соответствующих запросу. В то же время лишь небольшой процент из них достигает более широкой группы пользователей и становится незаменимым элементом гаджета. В данном случае интересно то, что можно найти в комментариях к менее популярным приложениям. Присмотревшись к простому компасу, видно, что сложность интерфейса, избыток рекламы или недостаточное тестирование болезненно воспринимаются потребителем.
Это пример простого мобильного приложения, но пользователь, который привык к такому опыту, переносит его в мир более сложных и продвинутых решений и систем, ожидая того же в большем масштабе.
Особые задачи
Сегодня полицейский, взяв в руки радиоприемник Motorola, ожидает от него тех же функций, что и в течение многих лет, но также простоты и интуитивности использования, присущих сегодняшним мобильным устройствам, и по крайней мере некоторых их функций.
Это вызов для дизайнеров и разработчиков, потому что помимо надежности и хорошо известных параметров, связанных с поддержкой голосовой связи, существует совершенно новый уровень для данных, местоположения, карт, видео или обработки вызовов в мобильной сети. Все это должно быть создано таким образом, чтобы предоставить необходимую информацию прямо в руки и глаза полицейского, будучи дополнительной помощью, а не отвлечением. Это особенно важно в «экстренных» ситуациях, когда предполагается, что система связи поможет, но ни в коем случае не может быть ненужным балластом в такой ситуации.
Это контекст, который позволяет определить потребности, способ работы и выполнение повседневных задач. Например, довольно легко сделать вывод, наблюдая за работой полицейского, что его руки должны оставаться максимально свободными во время вмешательства, но труднее ответить на вопрос: «каким действиям система может помочь?».
Аналогичным образом наблюдение оператора в штаб-квартире приведет к выводу, что ключом в чрезвычайной ситуации является поиск информации, организация помощи и предоставление необходимой информации в руки служб, выезжающих на место происшествия. Система должна помочь найти то, что важно в данный момент, и обеспечить эффективную передачу.
Возвращаясь к перспективе разработчика, информация в этом отношении редко доступна для более сложных решений. Поэтому он часто имеет ограниченные знания о том, как его код будет позже вписан в систему. Таким образом, ему не хватает того, что имеет решающее значение, так что заголовок пяти новых строк кода, созданных одним человеком, мог бы максимально помочь в спасении чьего-либо здоровья или заботе о безопасности пользователя.
Контекст при создании тестовых сценариев не менее важен. Там новый код проверяется вместе с уже существующим и проверяются требования системы критической связи (mission critical communication). Именно в тестах единая функциональность становится частью системы, состоящей из радиостанций, инфраструктуры, базовых станций и т.д., поэтому знание возможных (и неожиданных) случаев использования целых экосистем здесь так же важно, как и при написании самих приложений.
Конечно, окончательная проверка будет достигнута только путем внедрения в реальный мир, но все предыдущие этапы предназначены для получения максимальной уверенности в том, что будет получен полнофункциональный инструмент, отвечающий потребностям пользователя.
