Моя работа непосредственно связана с созданием того, чем будут пользоваться люди. И пусть программное обеспечение они чаще всего воспринимают как нечто абстрактное, но его присутствие в их жизни более чем реально.
Так уж сложилось, что когда я участвовал в разработках, на моих глазах рождались новые идеи. Они развивались и превращались в реальный результат. Конечно, многолетний опыт работы неизбежно приводит к так называемой профессиональной деформации.
В повседневной жизни становятся очевидными многие вещи. Например, видно невооруженным взглядом, что полученный результат совершенно не соответствует нуждам пользователей. Такая ситуация наталкивает на мысль, что работники (не ИТ) в своей работе руководствовались какими-то другими критериями и уж явно не беспокоились о среднестатистическом клиенте.
Расскажу всего лишь пару историй, на основе собственных наблюдений. Назовем их притчами.
Притча первая: "Туалет в торговом центре"
Представьте себе свежепостроенный торговый центр. Казалось бы, как нынче говорят, “стильно, модно, современно”. Кругом чистота и красота.
Вот захожу я туда первый раз в места общественного пользования и вижу яркий пример того, что разработчики четко следовали поставленному техническому заданию. Они его выполнили.
В задании наверняка было указано так: “должно быть четыре умывальника, четыре мыльницы для них и большое зеркало”. Вот так — коротко и ясно.
Разработчики однозначно следовали инструкциям: установили умывальники и зеркало. Настала очередь мыльниц. Вероятно, решив что сверлить дырки в зеркале слишком хлопотно, разработчики повесили мыльницы там, где им было удобнее.
Результат получился такой:
Мне как пользователю, который хочет помыть руки, не нравится это решение. С какой стороны не посмотреть, а сделано плохо. Можно подойти в середину, но там нет мыльницы. Также можно стать сбоку, где мыльниц сразу две. Но тогда, если кто-то захочет ними воспользоваться, он будет вынужден тянуться через другого человека, стоящего в углу. Одним словом — не комфортно.
И вот, вроде бы все выполнено согласно техническому заданию, придраться не к чему, но с точки зрения любви к пользователям такая работа никуда не годится.
Притча вторая: “Номер для двоих в отеле”
Современный человек обязан быть мобильным. Поездки по разным городам Украины и за границу стали частью жизни почти каждого из нас.
Динамичный ритм жизни приводит к тому, что нам волей-неволей приходится останавливаться в гостинице. Но иногда мы ездим не одни, а например, с коллегой. Снять один номер на двоих — обычный выход, чтобы сэкономить и не заскучать. В этой ситуации начинаешь ценить некоторые аспекты дизайна интерьера. Попалась нам как-то одна гостиница, где действительно подумали о таких пользователях, как мы.
Природные потребности утром у каждого человека по сути одинаковые. Помочь пользователям их удовлетворить, не мешая друг другу можно, достаточно легко. Решение в гостинице меня просто поразило:
Кажется, что разделить душ и туалет на две комнаты — ничего особенного. Но как известно, все гениальное — просто. Так стандартное решение “как везде” превратили в другое, более удобное. И дизайнеры не испугались отойти от аксиомы “все так делают”. Пользователи оказались важнее.
Позже мне объяснили: на дизайн повлияло еще одно не-функциональное требование. В этой гостинице часто останавливаются паломники, религия которых предписывает, что заставлять ждать другого человека — это грех. Поэтому, если есть лишь одна комната, то человек, который находится в ней, автоматически грешит. Ведь он заставляет ждать того, кто снаружи. Но в любом случае, какими бы ни были причины для такого решения, результат превосходит ожидания потребителей.
К чему я это все?
Я уже писал о том, что "мне не нужно техзадание". Старый подход, который давно изжил себя. Описание будущего продукта в стиле “система должна” совершенно неуместно. Система никому и ничего не должна: она неживая и сама по себе ничего не хочет. В современном мире фокус уже давно сместился на пользователя. Любое решение (будь то ПО или что-то другое) создается в первую очередь для нужд людей, которые будут его применять на практике. Неудачное решение, причиняющее постоянные неудобства, обречено быть забыто. Оно так и умрет, не отыскав своих покупателей.
Важно думать в стиле “пользователю нужно” или “пользователь хочет”. Только так и никак иначе мы будем точно понимать, что мы делаем и зачем.
Большинство читателей уже знакомы с форматом записи требований, которые так и назвали “Истории Пользователя”. Суть идеи проста, пишем в стиле:
Как <КТО>, я хочу <ЧТО>, потому что <ЗАЧЕМ>
На первый взгляд, идея элементарная, но одновременно она очень мощная. Ведь мы сразу концентрируемся на (ЗАЧЕМ) — целях, которыми будет руководствоваться (КТО) — пользователь нашего решения. Таким образом, создавая свое решение, мы думаем о том, будет ли удобно пользоваться тем, что мы сделали.
Есть еще целый ряд Agile-методов анализа нужд и описания требований: Use Case, Story Mapping, Impact Mapping.
На мой взгляд, такая формула работает не только для разработки ПО, ее можно применять и в других сферах. Основная миссия — создать “продукт”, который будет отвечать желаниям пользователей.
Сразу скажу: не обманывайтесь простотой формата. Есть и у него свои подводные камни. Требуется навык и небольшая “домашняя работа”, чтобы начать предугадывать потребности своих пользователей во всем, что вы для них создаете. Пока просто постарайтесь думать о тех, для кого вы создаете продукт или оказываете сервис. Полюбите ваших пользователей 🙂
К этой теме я еще вернусь с более практическими советами. Оставайтесь с нами или задавайте вопросы в комментариях.
Эту книгу ждали очень долго и вот она вышла на русском языке в издательстве «Манн, Иванов и Фербер». Дочитав книгу, хочу поделиться своими впечатлениями.
Докладчики мирового уровня, новые взгляды и идеи, опыт зарубежных и местных компаний, мастер-классы и вдохновляющие неформальные беседы за кофе – все это вновь привлекает участников со всей Восточной Европы и не только.
