Комментарии 32
Ответ на вопрос:
Я так делаю, потому что это работает. Удивлюсь, если кто-то ответит иначе.
Удивлюсь, если кто-то ответит иначе.
Вы правда удивитесь, если кто-то вам ответит "я так делаю, потому что это требование заказчика"?
Представление заказчика о том, что нужно для того, чтобы работало, не обязательно совпадает с представлением разработчика о том, что нужно, чтобы это работало. Иногда дело может доходить до того, что приходится сделать proof of concept точно по требованиям, чтобы доказать, что это не будет работать.
Если заказчик лезет в технические детали, то просто игнорируйте такие советы.
А никто не говорит о советах, речь идет именно о требованиях.
Эмм, то есть если в требованиях написана совместимость с MS SQL, а вы принесли пропиетарное решение на Oracle — никто не будет возмущаться?
Вот статья как раз о том, что если в требованиях написано MS SQL, то это не догма, а можно попытаться договориться на Oracle.
Другое дело, что договориться можно не всегда. И тогда в ответ на "зачем ты используешь здесь MS SQL, это же типичная задача для редиса" приходиться говорить "потому что это требования заказчика".
Звучит как какая-то тухлая отмазка. Мол, я не я и база данных не моя. Если MS SQL работает, и это хорошее решение, то зачем нужно говорить что это требование заказчика? А если он не работает, и редис решил бы эту проблему, то тогда нужно взять редис и говорить всем, что это хорошее решение, потому что так и есть.
Ну так вроде как это очевидно и без статьи, нет?
Не всем.
Если MS SQL работает, и это хорошее решение, то зачем нужно говорить что это требование заказчика? А если он не работает, и редис решил бы эту проблему, то тогда нужно взять редис и говорить всем, что это хорошее решение, потому что так и есть.
Кроме "работает" и "не работает" есть еще куча градаций, описывающих, грубо говоря, оптимальность выбора. Так вот, не всегда можно убедить заказчика, что ваш выбор оптимальнее, чем его выбор.
По делу: Поставленную заказчиком (пользователем) задачу надо:
а) внимательно рассмотреть,
б) пометить в бумажке непонятные вопросы,
в) пойти к пользователю ногами (не письмом в электропочте, а, хотя бы, видеозвонком через Skype),
г) выяснить непонятки, или, ежели их много, выспросить у пользователя чего же он на самом деле хочет,
д) записать окончательное ТЗ на бумажку (лучше — с автографами обеих высоких договаривающихся сторон =)
е) Сделать точно по бумажке;
ж) протестировать;
з) Написать документацию;
и) отдать пользователю.
Вот при таком процессе вы полностью увидите картину: какие у нас на самом деле ограничения, какие у нас есть возможности, как мы можем сделать это быстро.
Если же сразу броситься кодить, принятые наспех решения и вложенные в эти решения усилия к концу задачи станут дополнительными ограничениями в задаче / проекте.
Типичнейший пример: команда принимает требования к продукту за свою цель
Реализация системы по требованиям к продукту, утвержденным заказчиком, и есть цель для исполнителя (разработчика). Если исполнителю кажется неуместной часть требований, то он может попытаться инициировать их пересмотр.
В оригинале более уместная формулировка:
A common example is when teams treat a design specification as a goal.Обратите внимение, что речь идет не о functional (system requirements) specification, а о design specification.
Требования, архитектура, дизайн приложения — это ограничение.В общем неверно, т.к. обычно только малая часть требований и деталей дизайна является ограничениями. В оригинале более правильно:
A software design is a constraint.Хотя и это не всегда так: обычно есть какие-то design constraints, но дизайн в целом не является ограничением. Он даже может меняться в процессе реализации без участия заказчика при неизменных исходных требованиях и ограничениях.
В целом, в зависимости от контекста, совет автора оригинальной статьи может быть как полезным, так и вредным советом: вы можете не только завалить многомиллинный проект, но и понести за это полную ответственность («Вы ограничения на дизайн в утвержденной спецификации видели? А что наваяли?!!! :-\»).
старый спор с коллегой о том, как программисту следует относиться к требованиям к продукту. Коллега утверждал, что требование нужно реализовывать дословно, даже если оно неполное или не оптимальное. Я же пытался доказать ошибочность такого формального подхода.Ваш коллега был прав. Все эти спецификации — не что иное как формализация требований заказчика, потому и относиться к готовой спецификации следует формально. Свой творческий подход вы можете использовать на этапе анализа задач и сбора требований заказчика, но после утверждения просто выполнять его. А для внесения изменений есть свой формальный процесс.
Спасибо за замечание. Действительно, с выбором перевода для слова design были проблемы. Перетасовывал без конца три варианта — дизайн, архитектура, требования — и остановился не на самом удачном. Возможно, стоит поправить текст перевода, пока не поздно.
В нашем споре с коллегой заказчиком, который создаёт спецификацию, являлся наш внутренний аналитик, поэтому, как Вы и добавляете ниже, смена требований в процессе разработки не вызывала никаких формальных сложностей. Вспоминая этот случай сейчас, я вообще склонен назвать его "итальянской забастовкой". Возможно, мой коллега тогда просто устал от самого процесса согласований и переговоров.
>А для внесения изменений есть свой формальный процесс.
Вот я лично для себя именно так и понял посыл данного текста — не нужно путать настоящие и формализованные цели. Если вы видите, что записанные на бумаге формальные требования противоречат в чем-то цели (которая обычно может сама быть записана в паре абзацев) — то самое время остановить реализацию этой формальной чепухи и запустить процесс внесения изменений.
Вот что никогда не следует делать — так это молча отступать от требований, просто потому что они видятся вам неполными.
Точно так же, в командной работе мы крайне легко опускаемся до деталей и перестаём обращать внимание на то, почему мы создаём программы и системы так же, как это делали изначально.
С точки зрения программиста — для опыта и денег. А еще это весело.
В своём лучшем проявлении, компания может создавать смысл и цель для своих сотрудников, обогащать их жизни и жизнь сообщества, и добавлять привлекательности окружающему ландшафту.
Простите, но это маркетинговый булшит.
Недавно я убрал эту цель, осознал, что она только мешает
Зарабатывание денег это само собой разумеющиеся для нас приматов
Нельзя забыть про то, что надо зарабатывать
Я думаю, это стиль такой у англичан и американцев — всё по три раза разжевать. Выглядит порой как вода, но кому-то, может быть, так более понятно. Мои собственные тексты страдают обратной тенденцией: максимально кратко изложить самую суть, не вдаваясь в подробности, мотивацию и т.п. В итоге порой потом ещё дополнительно объяснять приходится, что же имел в виду...
Статья оторвана от контекста. В Долине есть куча аспектов, которые вместе и порождают эту невероятную гонку за прибылью. Есть ощущение, что там уже давно забыли, что существуют конечные пользователи, которые вообще-то и используют продукт. Если даже один из стартапщиков на момент остановится и подумает: "А что же действительно создаёт моя компания?", его в миг накроет лавина раздутых зарплат, раздутых рент, десятка конкурентов, желающих занять его нишу (ибо идея его стартапа нисколько не уникальна) и угасающего интереса инвесторов. А остальной мир просто пытается копировать с Долины. Кстати, "Фриско" уже давно "Сан-Фран" =)
Там тоже часто предлагают не зацикливаться и пересмотреть свои действия.
В примере с торговлей лимонадом истинный протестант вместо того, чтобы расстраиваться по поводу того, что так и не побывал во Фриско, должен быть бесконечно счастлив от того, что ему удалось так хорошо реализовать божий замысел.
В целом верно. Единственная проблема в том, что "истинный протестант" — это абстракция, а статья обращена к реальным людям.
Цели против ограничений