Comments 3
Все эти наукообразные статьи об управлении требованиями - сами по себе прекрасны. Проблема в том, что картина мира авторов этих статей имеет мало отношения к реальности. Они исходят из того, что где-то в прекрасном мире идей уже известно какой продукт с какими свойствами нужно построить, и это знание доступно по крайней мере некоторым из людей. И, соотвественно, наша задача - найти этих людей, и пряником-ли, пыткой-ли - но достать из них сокровенное знание (и еще подписаться кровью что оно "вот прямо то самое!").
Может быть где-то в отдельных отраслях и проектах (особенно где сроков нет, и денег дают сколько хочешь, а когда израсходуешь - еще столько же!) - это работает. В реальности - никакого мира идей с требованиями к ПО не существует, и эти требования людям недоступны. Соответственно, когда вы приходите к смертным за "требованиями" - они в лучшем случае честно говорят что не знают, а в худшем - врут как сивые мерины, и сами не знают, почему (полагаю, большинство сами верят в тот бред, который несут).
Чтобы освоить эту мысль на практике - представьте что вы пришли к сапожнику шить сапог, а он вам предлагает составить список требований по которым он будет его шить: длина голенища, полнота свода стопы, и т.д., и т.п. А вы почем это знаете ?! С другой стороны - если вам дать образец и вы его натянете - то скорее всего взвоете, и тут же объясните где вам жмет, а где - натирает...
Поэтому в 99% случаев, сбор требований можно опустить (достаточно удостовериться что большинство стейкхолдеров хотя бы сходятся на том, что шить будем сапог, а не кеды и не балетные пуанты). А сэкономленное время - пустить на изготовление MVP и сбор обратной связи. Так больше шансов сделать что-то такое, за что заказчик будет хотеть заплатить деньги.
И нет, я не видел практически ни одной ситуации когда вы сделали не то что заказчик хочет, а когда он высказывает претензии - вы такие достаете список требований, и заказчик: "А, ну да - это мы лоханулись... Двойную оплату этому господину!". :-) Заказчик будет вам выклевывать мозг до тех пор, пока вы не переделаете. Кроме, пожалуй, госухи - там вам будут выклевывать мозг в любом случае (но там требования нужны и важны для другого - чтобы потом не посадили!)...
В вашем примере про сапожника:
снятие мерок с клиента, вопросы про желаемый цвет, форму, к какому случаю сапоги (сезон, событие и т.п.) и прочие вопросы - как раз и есть выявление и анализ требований
прием заказа с указанием в соответствующем документе (договор, спецификация и т.п.) выявленных требований (с условием, что мы говорим о заказной работе) - документирование и утверждение требований
Идея сделать что-то, чтобы оно потом взлетело - это больше про стартапы, но даже в стартапах прежде чем создать продукт исследуется рынок на будущий спрос. При этом необходимо учитывать, что в любой момент рынок может измениться, поэтому он нуждается в постоянном анализе для актуализации и управления требованиями.
Также, не стоит забывать о внутренней разработке, в данном случае заказчиками являются ваши же коллеги, и, возможно, в том числе и вы сами. Для понимания ожидаемого продукта необходимо собрать и задокументировать мнение каждого заинтересованного лица, чтобы по итогу реализации не сидеть и не вспоминать зачем была реализована та или иная функциональность.
По итогу могу лишь ещё раз подчеркнуть, что этапы работы с требованиями должны присутствовать в любом проекте с учетом адаптации под конкретную методологию разработки продукта.
Вопрос не в том, чтобы в режиме стартапа - сделать хтоническую хтонь, а потом пытаться заставить это продаваться. Я говорю из области промышленной автоматизации и внутрикорпоративных разработок:
К вам будут приходить люди, и просить сделать "X", при том что им не только не надо "X", а они даже не разобрались в том, что это такое. Просто услышали слово или на конференции узнали что "X" в каком-то виде есть у конкурента. Где тут требования ?! Тут нужна психотерапия... Или генная терапия - если глупость наследственная...
Если вам смогли хотя бы сформулировать что болит - это уже прорыв. Если же вам сумели сформулировать еще и ограничения: "не успеваем лить молоко, есть место в углу цеха 3x5 метров" - это золотые люди!
А в целом, конечно - это ведет к казуистике о том "что есть требования". И на моей памяти - если решение какой-то задачи зависит от терминологии - значит это фикция. Я понимаю классическое управление требованиями - это сбор и детализация до той степени, когда вы можете список требований дать разработчику (любому - нужной минимальной квалификации) - и каждый из них вам по этим требованиям сделает a) примерно одно и то же; и б) что-то за что вы будете согласны заплатить.
Так вот - я утверждаю что требований в таком смысле (и управления ими) - в 99% случаев не существует в природе. Про исключение в виде госухи, где вы это будете предъявлять прокурору и следователю чтобы не сесть (или хотя бы не сесть реально), и не возвращать в поиздержавшийся бюджет все полученные платежи - я тоже честно написал!...
Разработка и управление требованиями