Задачи или функции?
#книжки #что_почитать

Продолжение предыдущего поста о книге Алана Купера «Психбольница в руках пациентов»…

📍Что получится, если скрестить компьютер с фотокамерой? Имеется в виду, что перегруженная функциями система перестает напрямую выполнять свои задачи, а превращается во что-то сложное. Будильник с кучей настроек для некоторых пользователей выглядит как компьютер, а не как удобный будильник. Может получиться, что не пользователь управляет будильником, а будильник пользователем...
От себя дополню. В работе аналитика это может проявляться, например, в виде запроса пользователя ”сделайте выгрузку этого в Excel”. Причины запроса могут быть разными и одна из вероятных — работа с записями в системе перегружена непонятными пользователю приемами управления данными, а он хочет сам управлять записями понятным ему способом. Нужно не только обучить пользователя, но и поискать функции, которые для него избыточны.

📍Кейс про функции и свойства продукта. В кейсе сначала перечислены функции продукта
• двигатель внутреннего сгорания
• четыре колеса с резиновыми покрышками
• трансмиссия, связывающая двигатель с ведущими колесами
• трансмиссия и двигатель смонтированы на ходовой части
• рулевое колесо.
Можно решить, что этот продукт — автомобиль, а после называются задачи продукта
• быстро и легко срезает траву
• на этом удобно сидеть.
Получается минитрактор-газонокосилка.
Я вспоминаю этот пример, когда думаю о документировании требований к функциональности. Не каждому разработчику понравится, если описание задачи перегружено описанием контекста. Разработчику удобнее видеть четкий перечень «что нужно сделать». Зато при изменении требований через пару месяцев, когда уже забыто зачем внедрялось изменение, вы сами будете рады найти информацию о целях и задачах заинтересованных сторон. Эта информация может помочь при тестировании запланировать тесты соответственно контексту. Поэтому при документировании приходится балансировать между описанием функций и задач.