Как вы можете показать своим клиентам/работодателям, что вы понимаете их требования?Как показать, что вы понимаете требования проекта
Что вы рекомендуете использовать? Примеры использования диаграмм? Блок-схема? Поток данные-схема? Деревья принятия решений?
Я не очень прошу дать очень подробный ответ. Просто что-то простое, чтобы помочь мне связаться с человеком, который написал требования и посмотреть, находятся ли вы оба на одной странице.
Я обычно собираю колоду PowerPoint довольно рано в проекте, предоставляя обзор на высоком уровне проекта, а также некоторые архитектурные схемы (чем проще, тем лучше) и макеты/каркасы на экране. Затем у меня есть «стартовое» собрание для рассмотрения требований, а также обсуждение бизнес-проблемы и предлагаемого решения.
Блок-схемы, как правило, путают некоторых нетехнических людей (т.е. клиентов), а также диаграммы потоков данных. Случаи использования являются хорошими и понятными, а также документация о бизнес-требованиях и технических требованиях, возможно, какие-то приблизительные эскизы каркасных каркасов.
Я просто объясняю требования на своем родном языке, предоставляя свои предположения и добавляя ограничения.
Требование может быть «Кнопка загорается зеленым при нажатии на»
Я хотел бы спросить «Хорошо, таким образом, когда пользователь нажимает на кнопку, цвет фона кнопки становится зеленым, но текст остается тот же цвет ?»
В основном побуждает человека, дающего требования, объяснить, как ОНИ считают его работой.
Это действительно зависит от требований, о которых вы говорите.
Но, во всяком случае, имейте в виду и объясните клиенту, что это требование изменится на этапе разработки и что это всегда будет обсуждение и компромисс между стоимостью и функциональностью. Быть honnest дать больше доверия к вашему клиенту.
Я думаю, что лучший способ показать, что вы действительно понимаете идею клиента, - это создание прототипов.
Кстати, я присутствовал в последнем выпуске конференции по техническим требованиям и в одном из семинаров (MERE), Siemens показывал и представлял интересное программное обеспечение, основанное на составлении видео идеи клиента (это было для проектов, а не ограниченное программным обеспечением), чтобы обеспечить полное понимание всех требований.
В любом случае, дело в том, что несколько раз творческий способ показать их лучше. Не ограничивайте себя стандартными диаграммами.
В моей роли очень много требований. Лучший способ, который я нахожу, - это двухсторонний подход, поговорить через презентацию PowerPoint, сохраняя ее простым и высоким, и демонстрируя доказательство концепции или макет. Прогуливаясь и разговаривая с клиентом, вы увидите, как они реагируют на многие «что если», например «Могу ли я получить цвет?». это дает каждому широкое представление о том, что они получают. Если вы можете получить что-то, что пользователи могут прикоснуться и играть с ним, это очень хорошо работает, если вы обнаружите скрытое, что если.
Затем верните этот высокий уровень с действительно подробными требованиями к низкому уровню. Выделите пунктир «i» и скрестите «t». Попросите пользователей прочитать и подписать их перед чем-то большим, чем POC. Обычно слово с большим количеством скриншотов работает хорошо.
Если пользователи не могут принести вам диаграммы UML и потоков данных, не используйте их ни в чем, что видит клиент или не подписывает. Если он подписан клиентом, и вам пришлось зарегистрироваться на заднем плане, чтобы встретить «что, если», вы должны полностью уйти с поста.
Последнее, что нужно, чтобы клиенты могли говорить с вами своими словами об их требованиях и разъяснять, что они получают. Один из способов сделать это - сидеть на любом средстве управления, продавая более высокому руководству.
Не пытайтесь обмануть клиента, если они хотят, чтобы что-то изменилось в последнюю минуту, объясните, какова будет стоимость, вовремя и деньги, и спросите их, если это полностью требуется. Выполняя это, часто останавливают людей, делающих тривиальные изменения, и заставляют их думать о том, почему они хотят изменения.
Требования получают то, что требуется клиенту, из того, что они говорят.
Редактировать- К вопросу о показе скриншотов рано - это иногда требует хорошего PM, чтобы клиент знал временные масштабы и где все находится. Если PM помогает установить некоторые приличные временные рамки и ожидания, клиенты не будут взволнованы. Хорошо, что POC и скриншоты - это люди, которые получают изображение того, чем он может быть похожим, и часто могут работать в своих умах.
Если вы хотите избежать скриншотов, сделайте обратную связь или используйте доску и 20 минут чертежа. Просто не забудьте сохранить доску как фотографию, прежде чем вы ее уничтожаете.
Whiteboarding (и старый добрый OHP) может стать находкой для сбора требований - разработка четкого стиля рисования концепции может сэкономить часы в мастерских.
У меня были хорошие впечатления от создания простой лексики, с условиями из области и их значениями и отношениями, а затем пройти через нее и убедиться, что все согласны на все.
Написание и обсуждение словаря заставляет вас думать, а не просто думать, что «мы это выясним позже».
Это, конечно же, не серебряная пуля и должна использоваться вместе с другими средствами, такими как спецификация функциональных требований и, возможно, прототип.
Если вы покажете им снимки экрана на раннем этапе, вы обнаружите, что клиент считает, что большая часть работы выполнена, и получает нетерпение, пока вы создаете фактическую функциональность? – 2008-09-22 21:41:45