Есть такой принцип разработки продукта – через тестирование. Программист создает продукт с минимальным набором функции, отдает его заказчику для эксплуатации и ждет от заказчика замечаний. В процессе эксплуатации, программист продолжает добавлять новые функции и не забывает реагировать на замечания, которые теперь могут касаться ещё и новых ошибок, возникших в следствии добавления новых функции.
Теперь вопрос: можно ли аналогичным способом поступить при проектировании программного продукта? Взять, да и написать руководство пользователя до окончательного написания программного кода, реализующего функции описанные в руководстве? Пользователь сможет сравнить то, что написано в руководстве с собственными представлениями о правильном, красивом и удобном ПО.
Бред, или эту идею можно использовать?
6 комментариев:
Идея TDD не состоит в создании минимального функционала. Она заключается в разработке сначала тестов, а потом собственно конкретной реализации (точнее даже во время разработки тестов). Данный подход позволяет уменьшить количество ошибок в коде на порядок. Каждый функционал должен иметь набор тестов для проверки работоспособности. Хороший эффект получается в совмещение Scrum (Agile методики разработки) и TDD.
Идея неплохая. Но я что-то не припомню действительно хороших руководств пользователя. Может быть потому что написать его хорошо тоже довольно сложная задача?
Вы безусловно правы. Оба. Я имел ввиду распустяйский вариант разработки через тестирование, который принят в абсолютном большинстве организации. Правильная разработка, с всегда стабильными билдами - это мудрость, а мудрость приходит с опытом...
Касательно написания хорошего руководства: есть удачная аналогия с презентациями - максимум графики, минимум текста. Все должно быть понятно из значков, иконок, надписей кнопок. Если это не так - надо менять интерфейс.
Ну и кончено, все действия должны быть разжеваны до состояния диетической молочной кашки.
Если есть концептуальные проблемы с написанием РП, можно взять за основу FAQ, который будет постепенно обрастать мясом - все это и будет хорошим руководством пользователя, то есть бумажкой помогающей пользователю работать с программой.
в первом случае если юзеры уже используют продукт, то они ноют и жалуются что всё не правильно работает, раньше было лучше, сделайте как было, но это мотивирует. во втором случае руководство ляжет на стол и никто его читать не будет, у всех и так работы хватает
Немножко не по теме, но предлагаю такой вариант: особо странные и бесполезные функции делать в виде не работающих пунктов меню, при нажатии на которые пользователь может отправить запрос на разработчику и выразить желание обладать этой функцией :)
Да, это интересный вариант. Помнится, на одном из наших сайтов так поступили, чтоб не готовить весь контент к открытию. Там это было названо "запросом информации" :)
Отправить комментарий