В теме 23 ответа, и 5 участников, последнее обновление сделано пользователем 
Андрей Курьян 13 г, 6 мес. назад.
-
Сообщения
-
Вопрос перенесён от сюда.
[quote="andre"]SRS готов. Согласован. Договор подписан. Заказчик требует как можно быстрее результатов. Через ~неделю-месяц показываем первую версию. Заказчик смотрит, глаза на лоб – «вы меня совсем не поняли!». Что далее?
Как любят говорить аналитики.. it depends..
1) у вас модель взаимодействия с заказчиком Тime & Material.
Вы говорите заказчику, что, мол, да, наверное, во время согласования кто-то кого-то не так понял. Рассказываете ему, как вы исправитесь (и вся команда разработки) и приступаете к работе.2) вы аналитик и вопросами контрактинга и разрешения проблем на уровне проекта обычно занимаетесь не вы
Доносите всю инфу как она была и как есть до начальства3) у вас есть право принимать решения и влиять на модель взаимодействия с заказчиком
Подумайте, что вы хотите от этого клиента? Подумайте хорошо и припомните, что это за клиент, как он отнесется к тому, что вы его тыкнете носом в его подпись на SRS и т.д. Примите решение не в одиночку, посоветуйтесь с менеджером и другими заинтересованными в продолжении проекта людьми.Но вообще это тема не для этой ветки (;[/quote]
Я думаю, что для раннего предупреждения такой проблемы лучше как можно раньше представить предварительный результат заказчику, чтобы убедиться в правильном направлении.
Предварительный результат может быть в виде урезанного приложения или динамического прототипа. Какие ещё есть варианты? Урезанное приложение будет от разработки, а динамический прототип от аналитика, да?Написан SRS. Идёт разработка. К концу проекта выясняется, что создается велосипед, т.е. уже есть готовое решение. Но это готовое решение было пропущено. Что тогда? В этом виноват аналитик?Предварительный результат может быть в виде урезанного приложения или динамического прототипа. Какие ещё есть варианты? Урезанное приложение будет от разработки, а динамический прототип от аналитика, да?
Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.
Предварительным результатом также является и спецификация, но откровенно говоря, не каждый заказчик может найти время вычитать большой по объему документ, так что здесь лучше переводить все, что можно в картинки и/или подтверждать требования у заказчика порциями (например, по фичам).Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.
Пошёл выяснять что есть «mockups и wireframes».
Предварительным результатом также является и [b]спецификация[/b], но откровенно говоря, не каждый заказчик может найти время вычитать [b]большой по объему документ[/b], так что здесь лучше переводить все, что можно в картинки и/или подтверждать требования у заказчика порциями (например, по фичам).
Про «большой по объему документ» относиться к теме О первой версии SRS для заказчика. Затронут вопрос:
«- Стареетесь сразу описать все требования к системе? Вырабатываете все требования к системе до начала проектирования?«, но это лучше уже в той теме обсудить.[quote="Belle Morte"]
Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.Пошёл выяснять что есть "mockups и wireframes".
[/quote]
Извините, что сразу не пояснила. Мне не очень нравится русскоязычное название — и то, и то у нас в принципе называют одинаково — макеты пользовательского интерфейса.
Вот как я понимаю разницу между mockups и wireframes:
Wireframes создают для того, чтобы обозначить структуру страницы. Как правило, это на них можно встретить "рыбу" и разметку вроде "Header", "Footer", "Place for logo". Вайер — это скелет, чаще всего — черно-белый. С его помощью можно выяснить, какие секции и элементы должны быть на странице/форме и как они должны быть расположены (ну и соответственно, какие страницы и формы должны быть).
Mockup-ы более приближены к конечному виду системы . Как правило, их создают дизайнеры, а не аналитики. Это у нас так повелось называть практически любой эскиз графического интерфейса мокапом, но это не совсем правильно. По мокапам можно прояснить более подробные вопросы: информационное наполнение, например (вместо "рыбы" тут уже реальный текст), цвета и т.п.
Надо понимать, правда, что граница условна.Для раннего предупреждения проблемы необходимо согласовать с заказчиком понимание бизнес-системы (если речь идет о бизнес-приложении), в общем системы заказчика. По ходу такого согласования будут определены бизнес-требования. Собственно, это и есть контекст проекта.А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.
А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.
Зависит от специфики проекта, заказчика и ключевых людей на проекте. При определенном сочетании это даже в плюс — проект по сути начинается заново, что несет дополнительный бабос компании.
[quote]А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.
Зависит от специфики проекта, заказчика и ключевых людей на проекте. При определенном сочетании это даже в плюс — проект по сути начинается заново, что несет дополнительный бабос компании.[/quote]
ИМХО, пустая трата времени…
Что именно? Начинать проект заново, если заказчик готов платить за это?Что именно? Начинать проект заново, если заказчик готов платить за это?
Обсуждать заказчика, который готов платить за то, что ему не надо, несколько раз. ИМХО, такая ситуация не имеет отношения к бизнесу.
Не совсем понял коммент. У меня 2 варианта интерпретации :
1. Ситауация имеет место быть, но это не задача аналитика.Отчасти согласен. Не есть прямая задача аналитика. Но если аналитик смотрит чуть глубже своих требований и может анализировать проектные аспекты и давать соответствующие советы, то это ему только в плюс и свидетельствует о его росте. Позиция "моя хата — с краю" вряд ли кем-то будет приветствоваться.
2. Такого в реале не бывает.
Бывает и нередко.
1) Проект не очень большой
2) Заказчик аппрувит документацию и последующие демонстрации, не читая.
3) В итоге сделано не то, что нужно
4) Заказчику это указано
5) Заказчик признает, что это его вина, но понимает, что систему нужно переделать.
6) Как итог, проект/часть проекта анализируются заново
Ситуация, описанная выше, в моей практике встречалась не раз.Бывает и нередко.
1) Проект не очень большой
2) Заказчик аппрувит документацию и последующие демонстрации, не читая.
3) В итоге сделано не то, что нужно
4) Заказчику это указано
5) Заказчик признает, что это его вина, но понимает, что систему нужно переделать.
6) Как итог, проект/часть проекта анализируются заново
Ситуация, описанная выше, в моей практике встречалась не раз.Вы смотрите на ситуацию узко…
Такая ситуация является следствием бизнес-модели, когда подрядчик делает только часть проекта — проектирование и разработку софта. Проект в целом предполагает внедрение того, что нужно заказчику.
между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно. Если этого не происходит, то ситуация сводится к бессмысленной.Согласен, я привел специфичный сценарий. В том то и дело, что сценариев таких может быть великое множество, что я и упомянул, говоря "при определенном сочетании".между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно.
Далеко не всегда. Я прошу прощения, но узко смотрите как раз судя по всему вы. Ваш вариант бывает. Но он не является правилом. Еще раз повторюсь — в моей практике были варианты, упомянутые мной. А это говорит, как минимум, о том, что это не сферический конь. А значит позиция "развод с заказчиком" не всегда верна.
Согласен, я привел специфичный сценарий. В том то и дело, что сценариев таких может быть великое множество, что я и упомянул, говоря "при определенном сочетании".
[quote]между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно.
Далеко не всегда. Я прошу прощения, но узко смотрите как раз судя по всему вы. Ваш вариант бывает. Но он не является правилом. Еще раз повторюсь — в моей практике были варианты, упомянутые мной. А это говорит, как минимум, о том, что это не сферический конь. А значит позиция "развод с заказчиком" не всегда верна.[/quote]
Тогда давайте рассмотрим общую ситуацию… Расскажите подробно, где можно заниматься херней, и за это получать деньги?
Вы должны авторизироваться для ответа в этой теме.
