Обсуждение

В точку. Буду использовать.

Verification and Validation. А в конструкторском бюро те, кто не знает, кто их клиент, просто идиоты. Обычно есть свои люди, разбирающиеся в клиентской кухне не хуже клиента.

использующей или используемой?

Анатолий, я глубоко согласен с идейной частью этого императива! Вопрос следом -- как это эффективно переложить на сегодняшние практики контрактов и приемки? В качестве упрощенной иллюстрации несложно представить разорившегося парикмахера, которому [после стрижки] все говорят "что-то не цепляет". Ведь клиент действительно всегда имеет способ доказать, почему предложенное решение (произведенная конструкция) недостаточно хорошо решает его задачи; и как достаточно формально (для V&V в рамках контракта) определить needs, вопрос открытый. Для продуктов, видимо, ситуация проще, но что делать с услугами?

Using system -- использующая. Тут все термины по-русски (включая проверку и приёмку), но в учебнике я даю и английские эквиваленты (включая verification and validation).

Вопрос про услуги лёгкий: речь всегда идёт о системе, оказывающей услуги и системе, принимающей услуги. Вопрос про needs ставится как минимум так: если в договоре прописываются только requirements, то начинаются проблемы. Если в договоре также прописываются needs (хотя бы в виде преамбулы! "Я хочу заказать систему, чтобы тра-та-та-та" -- это ведь часто даже не упоминают), то дальше уже легче. Но серебряной пули тут, конечно, нет. "Что-то не цепляет" -- можно проверить, показав фото панели экспертов из потенциальной целевой аудитории (женихам и невестам, или потенциальным работодателям) и попросить поставить оценку, сделать это с "до стрижки" и "после стрижки". Договориться, какое повышение балла приемлемо. В технических проектах часто приходится делать испытательный стенд для валидации, иначе не получается. Главное это контролировать, чтобы валидация хоть какая-то в проекте была. А то ведь забывают про неё напрочь, а потом сильно удивляются "скандалу из ниоткуда".

Да, в КБ бывают и просто идиоты. "Обычно" -- это ведь у всех разные "обычно". А когда учишь студентов, то нужно им указать на этот аспект жизни, сделать его явным сразу, а не ждать, пока они поймут что-то через десять лет производственного опыта.

Про услуги я не совсем корректно описал, имел в виду следующие 2 варианта: -- продукт (система) готовый, клиент может взять попробовать, провести пилот, определиться с влиянием на свои needs -- система создается на заказ, попробовать сильно заранее невозможно, не произведя серьезной работы Со всеми оговорками про инкрементную поставку, прототипирование и пилоты, конечно. -------- Если заземлять это на практику инженерных проектов (разработка или сложная настройка/интеграция), у меня сложился следующий набор принципов: -- про валидацию надо думать и практиковать; этот вопрос существенно определяется качеством коммуникации с клиентом -- достаточно формальным для контракта способом описать требования к валидации удается в редких, исключительных случаях; обычно получается на уровне декларации намерений -- для организации-разработчика задача имеет смысл при портфеле проектов; тогда управление переходит в плоскость поддержания коммуникаций (и практики постоянного "думания" о валидации), ограничении рисков и определении margin call'ов; должен быть буквально механический ограничитель, не дающих закапывать косты бесконечно в режиме "добавьте красненького" - плюс, нужен screening проектов на входе; как ни сложно бывает отказываться от предложений -- обычно не заканчиваются хорошим результатом проекты, в которых на входе нет определенных stakeholders / needs Анатолий, буду признателен за комментарии, если я насрезал углов!

Классически тут рекомендуют больше времени и усилий тратить на стадию определения needs (нужно обычно делать какой-то reverse engineering для using system), чтобы по возможности убрать связанные с ошибками на этой стадии риски. Сколько это "больше"? Никто, конечно, не скажет - это высокоспецифично для каждого проекта. Плюс чем меньше определённость в needs, тем больше контракт должен быть agile-like, а не классическим водопадным. Если тебя посылают "туда не знаю куда принести то не знаю что", то и контракт должен быть не на это, а на "побродить, прикладывая разумные усилия и отчитываясь о промежуточных результатах". Так будет честно для обеих сторон контракта.

Такие вопросы задаете, неудобно становится, даже. Я как главный исполнитель партии напильника в нашем wedding & funeral orchestra считаю что правильная система массового обслуживания должна содержать оба функционала - и катафалка и лимузина.

Мы используем с недавнего времени Impact Mapping http://blog.byndyu.ru/2014/12/impact-mapping.html с частыми релизами и сбором обратной связи, чтобы снизить риск построить что-то не то

Да, хорошая техника. И совершенно правильно вы сказали "Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе" -- все всё понимают, но мало кто реально использует. Сразу режут свои догадки на юс кейсы или юзер стори, а о стейкхолдерах и using system даже не заморачиваются.