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

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

В повседневной жизни становятся очевидными многие вещи. Например, видно невооруженным взглядом, что полученный результат совершенно не соответствует нуждам пользователей. Такая ситуация наталкивает на мысль, что работники (не ИТ) в своей работе руководствовались какими-то другими критериями и уж явно не беспокоились о среднестатистическом клиенте.

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

Притча первая: "Туалет в торговом центре"

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

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

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

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

Результат получился такой:

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

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

Притча вторая: «Номер для двоих в отеле»

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

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

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

Кажется, что разделить душ и туалет на две комнаты — ничего особенного. Но как известно, все гениальное — просто.  Так стандартное решение «как везде» превратили в другое, более удобное. И дизайнеры не испугались отойти от аксиомы «все так делают». Пользователи оказались важнее.

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

К чему я это все?

Я уже писал о том, что "мне не нужно техзадание". Старый подход, который давно изжил себя. Описание будущего продукта в стиле «система должна» совершенно неуместно. Система никому и ничего не должна: она неживая и сама по себе ничего не хочет. В современном мире фокус уже давно сместился на пользователя. Любое решение (будь то ПО или что-то другое) создается в первую очередь для нужд людей, которые будут его применять на практике. Неудачное решение, причиняющее постоянные неудобства, обречено быть забыто. Оно так и умрет, не отыскав своих покупателей.

Важно думать в стиле «пользователю нужно» или «пользователь хочет». Только так и никак иначе мы будем точно понимать, что мы делаем и зачем.

Большинство читателей уже знакомы с форматом записи требований, которые так и назвали «Истории Пользователя». Суть идеи проста, пишем в стиле:
Как <КТО>, я хочу <ЧТО>, потому что <ЗАЧЕМ> 

На первый взгляд, идея элементарная, но одновременно она очень мощная. Ведь мы сразу концентрируемся на (ЗАЧЕМ) — целях, которыми будет руководствоваться (КТО) — пользователь нашего решения. Таким образом, создавая свое решение, мы думаем о том, будет ли удобно пользоваться тем, что мы сделали.

Есть еще целый ряд Agile-методов анализа нужд и описания требований: Use Case, Story Mapping, Impact Mapping.

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

Сразу скажу: не обманывайтесь простотой формата. Есть и у него свои подводные камни. Требуется навык и небольшая «домашняя работа», чтобы начать предугадывать потребности своих пользователей во всем, что вы для них создаете. Пока просто постарайтесь думать о тех, для кого вы создаете продукт или оказываете сервис. Полюбите ваших пользователей 🙂

К этой теме я еще вернусь с более практическими советами. Оставайтесь с нами или задавайте вопросы в комментариях.