Открыть список
Как стать автором
Обновить

Комментарии 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 были проблемы. Перетасовывал без конца три варианта — дизайн, архитектура, требования — и остановился не на самом удачном. Возможно, стоит поправить текст перевода, пока не поздно.


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

Формализацию требований заказчика делают люди, и им свойственно ошибаться.

>А для внесения изменений есть свой формальный процесс.
Вот я лично для себя именно так и понял посыл данного текста — не нужно путать настоящие и формализованные цели. Если вы видите, что записанные на бумаге формальные требования противоречат в чем-то цели (которая обычно может сама быть записана в паре абзацев) — то самое время остановить реализацию этой формальной чепухи и запустить процесс внесения изменений.

Вот что никогда не следует делать — так это молча отступать от требований, просто потому что они видятся вам неполными.
В статье обращаются к программисту, хотя обращение к стартап-холдеру было бы уместнее.
Точно так же, в командной работе мы крайне легко опускаемся до деталей и перестаём обращать внимание на то, почему мы создаём программы и системы так же, как это делали изначально.

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

Простите, но это маркетинговый булшит.
Последние пол года у меня была цель 100 000$ оборот, на 2016 год. Командой 3 человека.

Недавно я убрал эту цель, осознал, что она только мешает

Зарабатывание денег это само собой разумеющиеся для нас приматов

Нельзя забыть про то, что надо зарабатывать
Мне одному кажется, что здесь больше воды, чем смысла? Чем то напоминает рассказы Пабло Коэльо о поисках истины и гармонии в жизни. Я предпочитаю более прагматичный подход — использовать ограничения, как вехи на своем пути. К примеру, три дня ты бьешься головой об стенку. Максимум три. Это ограничение. На четвертый осматриваешься по сторонам и находишь обходной путь. Идешь вперед. Но если ты продолжишь неограниченно биться об стенку, то это может отнять у тебя много времени впустую. С этой точки зрения ограничения помогают. А если же человек боится выходить за рамки своего кругозора и восприятия — это другое. Возможно, ему так проще жить. А если проще — зачем усложнять?

Я думаю, это стиль такой у англичан и американцев — всё по три раза разжевать. Выглядит порой как вода, но кому-то, может быть, так более понятно. Мои собственные тексты страдают обратной тенденцией: максимально кратко изложить самую суть, не вдаваясь в подробности, мотивацию и т.п. В итоге порой потом ещё дополнительно объяснять приходится, что же имел в виду...

так это классикa — сначала в результате везения||хорошей команды||гениального руководителя организация вырабатывает политику, которая вписывается в рынок, идет прибыль, мерещатся радужные перспективы, но вдруг условия начинают изменятся и «мы все время так делаем» перестает работать, не полностью, но эффективность все меньше и меньше и да — политика организации становится главным ограничением, происходит «ритуaлизaция» методов работы и в точности как у жрецов пустыни Нaскa — рисунки богам все больше, a дождя все меньше. Эта тема хорошо рассмотренa в Теории ограничений Голдрaттa, я даже думал, что статья про нее.

Статья оторвана от контекста. В Долине есть куча аспектов, которые вместе и порождают эту невероятную гонку за прибылью. Есть ощущение, что там уже давно забыли, что существуют конечные пользователи, которые вообще-то и используют продукт. Если даже один из стартапщиков на момент остановится и подумает: "А что же действительно создаёт моя компания?", его в миг накроет лавина раздутых зарплат, раздутых рент, десятка конкурентов, желающих занять его нишу (ибо идея его стартапа нисколько не уникальна) и угасающего интереса инвесторов. А остальной мир просто пытается копировать с Долины. Кстати, "Фриско" уже давно "Сан-Фран" =)

примечание переводчика в контексте статьи интереснее самого перевода…
Напомнило о книге «Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь».
Там тоже часто предлагают не зацикливаться и пересмотреть свои действия.
Можно добавить лишь то, что описанное представление о бизнесе идёт вовсе не из XIX века, а из религии под названием «протестантизм». Она намного старше. Протестантская трудовая этика предписывает человеку заниматься таким бизнесом, который наиболее угоден богу. А как определить, какой бизнес богу более угоден? Очень просто: это тот бизнес, который приносит больше денег.

В примере с торговлей лимонадом истинный протестант вместо того, чтобы расстраиваться по поводу того, что так и не побывал во Фриско, должен быть бесконечно счастлив от того, что ему удалось так хорошо реализовать божий замысел.

В целом верно. Единственная проблема в том, что "истинный протестант" — это абстракция, а статья обращена к реальным людям.

Обидно, что в России статья настолько актуальна и вызывает живой отклик. По идее, поскольку протестантизм в нашей стране не имеет распространения, ценности у людей должны быть совсем иные. И такое представление о бизнесе, что будто бы его смысл в том, чтобы заработать денег, должно бы вызывать у людей лишь недоумение.
Так ведь мы воспитаны дикими телевизорами.
А дикие телевизоры предлагают две версии успеха:
* Известность + деньги;
* просто деньги.
Есть же давным-давно S.M.A.R.T. Эту методику постановки целей придумали именно из тех размышлений, что у вас в статье.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.