Комментарии 6
Time-bound (своевременные)
Time-bound = ограниченные по времени
Нет не должны быть, зачем нужна вся эта толпа в современной разработке? Куча типов аналитиков, менеджеров итд и все равно с заказчика требуют знать что именно он хочет. И, что самое страшное, потом еще ведут себя как тот врач: "у меня такая же нога и не болит".
Заказчик знать не знает что вы можете создать и что вообще возможно, он хочет кнопку "сделать хорошо", масштаб этой кнопки зависит от того уровня на котором вы работаете. Но именно разработчики с той стороны что делают эту кнопку.
Вы были когда нибудь у портного? Заказывали костюм? Я вот был, у портного с понтами и сбором требований, ад нереальный, миллиард вопросов о ткани, покрое итд итп и результат был омерзителен. А еще я был там, где тебе предлагают бокал и варианты которые подходят мне. Но если с костюмами тут обычно вопрос бюджета, то с разработкой первый вариант часто обходится дороже.
Увы, формирование и формулирование требований — это совместный процесс заказчика и исполнителя, да еще и итеративный
Готов аплодировать стоя за это. Но в примере про транзакции, имхо заказчик выглядит идиотом, хотя уточнение должно было звучать чуть иначе: "ок, мы готовы сделать вот так и так, зачисление в течении 5 минут, устраивает?"
PS извините, накипело. Из каждого утюга я стал слышать про требования
Согласен. И дело даже не только в том, что "зачем нужна вся эта толпа в современной разработке". Дело в том, что например, ответ на вопрос, реализуемо ли требование, может выясниться именно в процессе разработки. И никак не раньше. И в моей практике достаточно типичным результатом разработки является скажем такой: "Мы это сделаем, вам это будет стоить столько-то, заказывайте сервера, столько-то штук, такой-то конфигурации. После чего заказчик отвечает: "Ну ок, я подумаю" - и как правило не возвращается. Или возвращается с еще одним потребителем той же фичи и двумя чемоданами денег.
Ну т.е. не только он не знает, можем ли мы создать - мы точно так же не знаем ответа на такой вопрос.
В итоге, SMART применительно к требованиям я бы назвал желательным свойством. Если они не такие, с ними зачастую тоже можно работать, и часть заказчиков готова оплачивать доработку требований до такого состояния.
@Kwisatz, на такой комплексный комментарий хочется ответить просто "да!" :)
"А что такое «любой»? any of или one of?"
Наверное тут имелось ввиду "all of" вместо "any of"?
Ваши требования … не SMART