21 ошибка программиста PHP. Часть 3
Страница 6. Исключение конечного пользователя из процесса разработки


3. Исключение конечного пользователя из процесса разработки

Ситуация: вы получили задание по разработке корпоративного приложения специально для вашей компании. Вы потратили часы на поиск и документирование тонны требований, определили стоимость проекта, поставили задачи и выполнили их. Через три месяца вы приносите законченный проект только чтобы услышать в ответ:
  • "Это не то, чего бы мы хотели".
  • "Наши требования изменились".
  • "Да, но...".
  • "Ммм, какая программа?" (Ваш изначальный заказчик уже давно уволился из компании!!!!).

Случалось ли подобное с вами?

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

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

  • непрерывная обратная связь
  • создание макетов
  • бета-тестирование

Непрерывная обратная связь

Бенджамин Франклин в своём "Альманахе Бедного Ричарда" писал: "Один стежок вовремя девяти стоит". То же правило применимо и в разработке приложений. Если вы действительно хотите завершить проект как можно раньше, очень важно поддерживать связь с пользователем и интересоваться его мнением о вашей программе. Что им нравится? Что им не нравится? Как можно улучшить приложение?

Создание макетов

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

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

Есть способ избавить себя от этой головной боли: разбить весь процесс разработки приложения на несколько этапов. По завершении каждого этапа обдумайте следующее:

  • Работа, которую вы проделали на данном этапе, приносит ли она какой-либо полезный для пользователя результат?
  • Остались ли какие-нибудь вещи, которые пользователь хотел бы увидеть в вашем приложении, но до сих пор в проекте не представленные?
  • Будет ли задействована дополнительная функциональность, которая была добавлена на данном этапе?
  • Какова "чистая прибыль" в функциональности вашего приложения?
  • Проделанная вами работа улучшила или ухудшила приложение?

Как разбивать работу на этапы?

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

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

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

Бета-тестирование

Это самая распространённая форма тестирования, чем-то напоминающая макетирование, но обычно бета-тестирование проводится, когда проект находится на последней стадии разработки. Проект высылается определённой группе бета-пользователей; они тестируют приложение и направляют разработчику свои отзывы, комментарии и сообщения об ошибках. Бета-тестирование не так интерактивно как создание макетов и проводить его стоит как можно раньше. Однако провести бета-тестирование просто необходимо и только потом выпускать приложение в свет.

 
« Предыдущая статья   Следующая статья »