Заказчик – «вы меня совсем не поняли!»




Главная   Форумы   Общие вопросы по работе с требованиями   Заказчик – «вы меня совсем не поняли!»

В теме 23 ответа, и 5 участников, последнее обновление сделано пользователем Аватар (AndrewK) Андрей Курьян 6 г, 5 мес. назад.

Показано 15 ответов - от 1 до 15 (всего 24)
  • Автор
    Сообщения
  • 09.06.2011 в 10:15 # 5312
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    Вопрос перенесён от сюда.

    [quote="andre"]SRS готов. Согласован. Договор подписан. Заказчик требует как можно быстрее результатов. Через ~неделю-месяц показываем первую версию. Заказчик смотрит, глаза на лоб – «вы меня совсем не поняли!». Что далее? :)

    Как любят говорить аналитики.. it depends..
    1) у вас модель взаимодействия с заказчиком Тime & Material.
    Вы говорите заказчику, что, мол, да, наверное, во время согласования кто-то кого-то не так понял. Рассказываете ему, как вы исправитесь (и вся команда разработки) и приступаете к работе.

    2) вы аналитик и вопросами контрактинга и разрешения проблем на уровне проекта обычно занимаетесь не вы
    Доносите всю инфу как она была и как есть до начальства

    3) у вас есть право принимать решения и влиять на модель взаимодействия с заказчиком
    Подумайте, что вы хотите от этого клиента? Подумайте хорошо и припомните, что это за клиент, как он отнесется к тому, что вы его тыкнете носом в его подпись на SRS и т.д. Примите решение не в одиночку, посоветуйтесь с менеджером и другими заинтересованными в продолжении проекта людьми.

    Но вообще это тема не для этой ветки (;[/quote]

    Поделиться:

    Цитировать

    09.06.2011 в 10:22 # 5313
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    Я думаю, что для раннего предупреждения такой проблемы лучше как можно раньше представить предварительный результат заказчику, чтобы убедиться в правильном направлении.
    Предварительный результат может быть в виде урезанного приложения или динамического прототипа. Какие ещё есть варианты? Урезанное приложение будет от разработки, а динамический прототип от аналитика, да?
    Поделиться:

    Цитировать

    09.06.2011 в 11:01 # 5314
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    Написан SRS. Идёт разработка. К концу проекта выясняется, что создается велосипед, т.е. уже есть готовое решение. Но это готовое решение было пропущено. Что тогда? В этом виноват аналитик?
    Поделиться:

    Цитировать

    09.06.2011 в 11:25 # 5315
    Аватар (Belle Morte)
    Belle Morte
    Админ

    Предварительный результат может быть в виде урезанного приложения или динамического прототипа. Какие ещё есть варианты? Урезанное приложение будет от разработки, а динамический прототип от аналитика, да?

    Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.
    Предварительным результатом также является и спецификация, но откровенно говоря, не каждый заказчик может найти время вычитать большой по объему документ, так что здесь лучше переводить все, что можно в картинки и/или подтверждать требования у заказчика порциями (например, по фичам).

    Поделиться:

    Цитировать

    09.06.2011 в 12:35 # 5316
    Аватар (Андрей В.)
    Андрей В.
    Подписчик

    Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.

    Пошёл выяснять что есть «mockups и wireframes».

    Предварительным результатом также является и [b]спецификация[/b], но откровенно говоря, не каждый заказчик может найти время вычитать [b]большой по объему документ[/b], так что здесь лучше переводить все, что можно в картинки и/или подтверждать требования у заказчика порциями (например, по фичам).

    Про «большой по объему документ» относиться к теме О первой версии SRS для заказчика. Затронут вопрос:
    «- Стареетесь сразу описать все требования к системе? Вырабатываете все требования к системе до начала проектирования?«, но это лучше уже в той теме обсудить.

    Поделиться:

    Цитировать

    09.06.2011 в 14:18 # 5317
    Аватар (Belle Morte)
    Belle Morte
    Админ

    [quote="Belle Morte"]
    Я бы еще добавила такие варианты как mockups и wireframes: они статические, конечно, и не дают полного представления о процессе взаимодействия, но уже на этом этапе можно отфильтровать некоторые недопонимания.

    Пошёл выяснять что есть "mockups и wireframes".
    [/quote]
    Извините, что сразу не пояснила. Мне не очень нравится русскоязычное название — и то, и то у нас в принципе называют одинаково — макеты пользовательского интерфейса.
    Вот как я понимаю разницу между mockups и wireframes:
    Wireframes создают для того, чтобы обозначить структуру страницы. Как правило, это на них можно встретить "рыбу" и разметку вроде "Header", "Footer", "Place for logo". Вайер — это скелет, чаще всего — черно-белый. С его помощью можно выяснить, какие секции и элементы должны быть на странице/форме и как они должны быть расположены (ну и соответственно, какие страницы и формы должны быть).
    Mockup-ы более приближены к конечному виду системы . Как правило, их создают дизайнеры, а не аналитики. Это у нас так повелось называть практически любой эскиз графического интерфейса мокапом, но это не совсем правильно. По мокапам можно прояснить более подробные вопросы: информационное наполнение, например (вместо "рыбы" тут уже реальный текст), цвета и т.п.
    Надо понимать, правда, что граница условна.

    Поделиться:

    Цитировать

    09.06.2011 в 17:38 # 5318
    Аватар (AndrewK)
    Андрей Курьян
    Участник
    Для раннего предупреждения проблемы необходимо согласовать с заказчиком понимание бизнес-системы (если речь идет о бизнес-приложении), в общем системы заказчика. По ходу такого согласования будут определены бизнес-требования. Собственно, это и есть контекст проекта.

    А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.

    Поделиться:

    Цитировать

    09.06.2011 в 17:48 # 5319
    А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.

    Зависит от специфики проекта, заказчика и ключевых людей на проекте. При определенном сочетании это даже в плюс — проект по сути начинается заново, что несет дополнительный бабос компании.

    Поделиться:

    Цитировать

    09.06.2011 в 17:57 # 5320
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    [quote]А вот если произошло непонимание по контексту проекта, то… развод с заказчиком — это меньшее из зол.

    Зависит от специфики проекта, заказчика и ключевых людей на проекте. При определенном сочетании это даже в плюс — проект по сути начинается заново, что несет дополнительный бабос компании.[/quote]

    ИМХО, пустая трата времени…

    Поделиться:

    Цитировать

    09.06.2011 в 18:26 # 5321
    Что именно? Начинать проект заново, если заказчик готов платить за это?
    Поделиться:

    Цитировать

    09.06.2011 в 18:50 # 5322
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Что именно? Начинать проект заново, если заказчик готов платить за это?

    Обсуждать заказчика, который готов платить за то, что ему не надо, несколько раз. ИМХО, такая ситуация не имеет отношения к бизнесу.

    Поделиться:

    Цитировать

    09.06.2011 в 19:27 # 5323
    Не совсем понял коммент. У меня 2 варианта интерпретации :) :
    1. Ситауация имеет место быть, но это не задача аналитика.

    Отчасти согласен. Не есть прямая задача аналитика. Но если аналитик смотрит чуть глубже своих требований и может анализировать проектные аспекты и давать соответствующие советы, то это ему только в плюс и свидетельствует о его росте. Позиция "моя хата — с краю" вряд ли кем-то будет приветствоваться.

    2. Такого в реале не бывает.

    Бывает и нередко.
    1) Проект не очень большой
    2) Заказчик аппрувит документацию и последующие демонстрации, не читая.
    3) В итоге сделано не то, что нужно
    4) Заказчику это указано
    5) Заказчик признает, что это его вина, но понимает, что систему нужно переделать.
    6) Как итог, проект/часть проекта анализируются заново
    Ситуация, описанная выше, в моей практике встречалась не раз.

    Поделиться:

    Цитировать

    09.06.2011 в 19:49 # 5324
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Бывает и нередко.
    1) Проект не очень большой
    2) Заказчик аппрувит документацию и последующие демонстрации, не читая.
    3) В итоге сделано не то, что нужно
    4) Заказчику это указано
    5) Заказчик признает, что это его вина, но понимает, что систему нужно переделать.
    6) Как итог, проект/часть проекта анализируются заново
    Ситуация, описанная выше, в моей практике встречалась не раз.

    Вы смотрите на ситуацию узко…
    Такая ситуация является следствием бизнес-модели, когда подрядчик делает только часть проекта — проектирование и разработку софта. Проект в целом предполагает внедрение того, что нужно заказчику.
    между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно. Если этого не происходит, то ситуация сводится к бессмысленной.

    Поделиться:

    Цитировать

    09.06.2011 в 20:15 # 5325
    Согласен, я привел специфичный сценарий. В том то и дело, что сценариев таких может быть великое множество, что я и упомянул, говоря "при определенном сочетании".

    между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно.

    Далеко не всегда. Я прошу прощения, но узко смотрите как раз судя по всему вы. Ваш вариант бывает. Но он не является правилом. Еще раз повторюсь — в моей практике были варианты, упомянутые мной. А это говорит, как минимум, о том, что это не сферический конь. А значит позиция "развод с заказчиком" не всегда верна.

    Поделиться:

    Цитировать

    09.06.2011 в 20:18 # 5326
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Согласен, я привел специфичный сценарий. В том то и дело, что сценариев таких может быть великое множество, что я и упомянул, говоря "при определенном сочетании".

    [quote]между 4) и 5) происходит смена заказчика. Из проекта убираются люди, которым пофиг, и появляются люди, которые понимают что и зачем нужно.

    Далеко не всегда. Я прошу прощения, но узко смотрите как раз судя по всему вы. Ваш вариант бывает. Но он не является правилом. Еще раз повторюсь — в моей практике были варианты, упомянутые мной. А это говорит, как минимум, о том, что это не сферический конь. А значит позиция "развод с заказчиком" не всегда верна.[/quote]

    Тогда давайте рассмотрим общую ситуацию… Расскажите подробно, где можно заниматься херней, и за это получать деньги?

    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 24)

Вы должны авторизироваться для ответа в этой теме.