Home

Автор: Руколь Наталья

Пролог, или история разработки новейшего продукта ХХХ

Январь, Стадия проектирования:

Бизнес-аналитик: нам обязательно нужны и GUI и веб-интерфейс, потому что это атрибуты всех современных серьёзных приложений
Архитектор: Так же нам обязательно нужна командная строка с возможностью удалённого доступа – это признак профессионализма

Март, Разработка

Архитектор: мы будем писать наше приложение на Java и ActiveX, потому что они scalable.
Руководитель разработки: нет, мы будем писать на C# потому что он более secure и очень reliable

Сентябрь, Тестирование

Тестировщик: я настаиваю на том, что это критикал, потому что программа падает при нажатии на эту кнопку всего шестнадцать раз подряд!
Разработчик: сейчас это нельзя исправить потому что класс MegaPuperClass библиотеки Refactored_on_May не поддерживает обработки исключений

Декабрь, Эксплуатация

Пользователь: очень симпатичный калькулятор, но я не понимаю, как им пользоваться?

Если ничто из вышеперечисленного диалога Вам не знакомо – видимо, Вы не участвовали в разработке софта .

Создавая программный продукт, каждый участник проектной команды подходит к нему со своей стороны. Бизнес-аналитик сверяет функционал с конкурентами и увлечённо ставит галочки напротив уникальных на рынке «фич». Разработчики создают масштабируемую систему, используя максимально современные средства разработки. Тестировщики,  прочитав о граничных значениях, тестируют продукт на корректность работы с паролем длиной 254 символа.

И только после выхода программного продукта «в свет» становится известна реакция пользователя. Вероятность выпуска успешного продукта в таком случае – ровно 50%.

«- Какова вероятность встретить крокодила днём на Красной площади?
- 50%
- ???
- Либо встретите, либо не встретите»

О чём же так часто забывают разработчики ПО? О Пользователе!

Насколько важен для пользователя функционал, ради добавления галочки о котором был на 2 недели задержан релиз? Оценит ли пользователь использованную среду разработки, увеличившую размер дистрибутива в 3 раза? Использует ли пользователь пароль длиной 254 символа?

Возможно, эти вопросы в данном контексте покажутся чисто риторическими, однако это не совсем так. Не задав эти вопросы, узнать ответы невозможно. Догадки – самый короткий путь к ошибке.

2 года назад я участвовала в релизе крупного продукта в одной небезызвестной компании. Мы на 3 недели задержали релиз, внося новый и, как казалось нашему бизнес-аналитику, необходимый функционал. После релиза выяснилось, что его никто не стал использовать, а наибольшее число обращений в техподдержку вызвала проблема, выявленная нами задолго до выпуска продукта. В баг-трекере она имела критичность 2 по 5-балльной шкале. Именно тогда я поняла, почему у Microsoft 25(ДВАДЦАТЬ ПЯТЬ) лабораторий Usability.

Пользователи – это Целевая Аудитория Вашего продукта. Именно они определяют «что такое хорошо и что такое плохо». И только зная их предпочтения, можно гарантированно выпустить продукт, имеющий успех на рынке и пользующийся спросом.

Когда я говорю о знании пользовательских предпочтений, я имею в виду ментальную модель пользователя, формирование которой детально разбирается на тренинге «От тестирования к качеству». Что же такое ментальная модель пользователя?

Это Портрет Вашей целевой аудитории. Изначально этот термин зародился в области удобства использования интерфейсов (UI Usability), но играет не меньшую роль и в разработке функционала Вашего продукта. Не вдаваясь в детали, ментальную модель пользователя можно разбить на 3 области ответов:

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

Ответы на эти три, казалось бы, элементарных вопроса, получить не так-то просто, потому что:

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

Но игра стоит свеч!

Создание ментальной модели пользователя окупится сполна. Ниже – далеко не полный список бенефитов  от создания модели:

• Приоритезация тестирования. Зная важность функционала для Ваших пользователей, Вы знаете, чему уделять большее внимание.
• Открытие новых областей для тестирования. Не хочу обижать тестировщиков, но правда остаётся правдой: пользователь – лучший тестировщик, использующий продукт ТАК, как Вы и придумать не могли
• Определение дефектов. Пользователь – это тот самый судья, который всегда может рассудить спор «баг или фича?»
• Определение критичности дефектов. Только зная своего пользователя, Вы можете определить, насколько серьёзна для него та или иная проблема.
• Экономия ресурсов на неприоритетных участках продукта. Согласитесь, что регулярно тестировать функционал, который никому не нужен, не просто неэффективно, но и по-человечески обидно тратить на это своё время

Не попробуешь – не узнаешь
Максвелл Мольц

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

Поэтому - но пасаран!

Обсудить в форуме