Комментарии 18
Десятая ловушка: Решения, представленные в виде требований
Очень часто - это часть процесса.
Часто заказчик хочет, чтобы UI в новой программе был как в другой программе, которую уже используют 15 000 человек много лет. Обосновывают это минимизацией ошибок и ускорением обучения. Тогда еще до реализации приходится рисовать экранные формы, которые становятся частью требований.
Чтобы не колоться, достаточно вовлечь в процесс системного аналитика или лида разработки.
Перекладывать вину за провал проекта на то, что заказчик недостаточно вовлечён идеально научился скрам. Ну мы вот с такой скоростью работаем, а это вы нам в стек задачи такие поставили, вот так и получилось. В реальности же это огромный и невероятный пласт работ: pr, продвижение и вовлечение в проект самих заказчиков. В таком случае проект должен иметь лидера внутри который будет мотивировать заказчика, делать так, чтобы ему было понятно и интересно, и притормаживать излишне рвущихся. А в сложной системе заказчиков всегда еа самом деле сотни. Заказчик профи и заинтересован в своём бизнесе,и у него есть проблема, он хочет решение про лемы а не решать её сам, отсюда растёт нежелание погружаться, и с этим нужно работать и работать очень много, но такую карточку на доске никто никогда не заведёт.
Гайз, если вы там в ОТУСе такие молодцы эксперты-учителя, почему не пишете свои статьи, а переводите чужие?
Это же не ваша экспертиза.
Пишем, когда есть такая возможность. Увы не всегда хватает времени на подготовку авторских статей, так как наши эксперты активно заняты курсом
Подождите, эксперты, которые могут РАЗРАБОТАТЬ курс — разрабатывают его один раз. После чего могут заниматься статьями.
Специалисты, которые могут ВЕСТИ разработанный курс — это совсем другие люди с другой квалификацией, которые могут хорошо вести курс, но не могут написать статью. Это они постоянно заняты.
Самая частая проблема - когда пользователи понимают, что у них есть проблема и даже пытаются, как могут, её описать. А способа решения проблемы пользователи не знают.
И если аналитики не могут придумать способ решения проблемы - начинают обвинять пользователей. :)
Каким образом фраза
"Users sometimes believe BAs or developers should already know what they need"
превратилась в
"Пользователи иногда считают, что BA по техническому анализу или разработчики должны знать, что им нужно." ?
кто такой "BA по техническому анализу"?
"Изучите их все во время разработки, чтобы не упустить что-то важное."
в оригинале было
"Explore all of these during elicitation to avoid missing something important."
elicitation – это выявление, устойчивое понятие в инженерии требований и БА
"Поэтому бизнес-аналитик (BA) должен вывести конкретные функциональные требования к программному обеспечению из примеров использования. "
use cases обычно переводят как варианты использования, сценарии использования, способы применения.
вы ошибочно переводите ключевые термины профессии
не стоит переводить "incremental releases" как "постепенным релизам", т.к. постепенными релизами могут быть разные очереди, независимые друг от друга
нет такого понятия в ИТ
entity-relationship diagrams
обычно не переводят как
диаграммы взаимосвязей сущностей
а переводят как диаграмма сущностей и связей или диаграмма "сущность и связь"
“rapid descoping phase”
это не "фазы быстрого анализа"
это скорее "фаза быстрого пересмотра и сокращения рамок проекта"
фраза
"Остерегайтесь разработчиков, которые добавляют ненужную функциональность, которая может быть не нужна пользователям."
звучит очень тавтологично
Watch out for developer gold plating, which adds unnecessary functionality that users might not care about.
можно скорее перевести как
"следите, чтобы разработчики не увлекались "золочением", что привносит избыточные возможности, до которым пользователям нет дела"
он остерегает от деятельности, а не от людей. ваш текст выглядит как токсичная рекомендация, которой у Карла не было
"базовой линии требований"
к сожалению даже в стандартах requirements baseline скорее переводится так, но это странно, так как в русском языке никаких базовых линий не существует
по сути это скорее опорные, фундаментальные, основные требования — если они существуют в единственном виде на проект
или "срез требований", "версионный комплект требований" — если их множество в проекте
Another indication of inadequate impact analysis is that developers keep encountering more affected system components as they implement the change.
more affected components — это не "более уязвимые" компоненты)
тут скорее речь о том, что разработчики встречают всё больше задействованных или "задетых" компонентов по мере реализации изменений
requirements practices
это не практические требования
а практики работы с требованиями
application domain
это не "область применения" (хотя формально да), а скорее
предметной области продукта/программы
vision and scope это не концепция и объём, а концепция и рамки
в общем к концу статьи совсем расслабились и слили работу
10 ловушек, связанных с требованиями, которых следует избегать