"Заказчик хочет!"




В теме 7 ответов, и 5 участников, последнее обновление сделано пользователем Аватар (Igor Tkachenko) Igor Tkachenko 12 г, 11 мес. назад.

Показано 10 ответов - от 1 до 10 (всего 10)
  • Автор
    Сообщения
  • 30.08.2010 в 16:36 # 5110
    Всем доброго дня!
    заранее прошу прощения, если тема "не в тему" :)

    Вопрос в следующем. Есть проект, есть аналитик и заказчик.
    Заказчик настаивает на конкретном требовании. Требование не критичное (скорее даже не требование, а деталь его реализации), с другими требованиями в конфликт не вступает и не связана напрямую с рабочими бизнес-процессами (в том смысле что не конфликтует с ними).

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

    Ничего из упомянутого у аналитика не сработало. Возражения заказчика были не очень конструктивными, но настройчивыми, поэтом уделалось так, как хочет тот, кто платит.
    У кого такое было? Что делать ? и вообще нормально ли это и как к этому относится?

    ПС я как аналитик болею всей душой, чтобы получился отличный продукт и я бы им гордилась. Но 15-20 таких решений, которые были не теми, что аналитик рекомендовал и продукт уже немного другой на выходе.

    Поделиться:

    Цитировать

    30.08.2010 в 16:49 # 5111
    Вначале пару вопросов вам, чтобы разобраться в ситуации:

    1) Сколько аналитик работает на проекте?
    2) Сколько аналитик работает в этой бизнес области?
    3) Сколько заказчик работает в этой области?
    4) Что именно отвечает заказчик (как реагирует) на все потуги?
    5) Кто в команде аналитика и что думает по этому поводу?
    6) Сколько суммарно уже времени и сил (хоть примерно) было потрачено уже на поиск и приведение доказательств?

    Поделиться:

    Цитировать

    30.08.2010 в 17:09 # 5112
    Согласен с Юрой, что ответы на приведенные вопросы важны в данном случае.
    Еще немного философии в отсутствие ответов:
    Вопрос — а надо ли это вам (если учитывать то, сколько уже было впустую потрачено времени и сил на убеждение)? Требование не критичное, ни с чем не конфликтует и т.д. — таким образом, это просто мелкая прихоть заказчика, который является в данном случае лицом, принимающим решение. Есть такая мысль, что согласиться на его требование будет проще и в некоторых случаях полезнее. Я знаю случаи, когда упорное несогласие и попытка продвинуть свою точку зрения (надеюсь, вы хоть вежливо и деликатно это делаете? :wink: ) приводили к провалу проекта и разрыву отношений с клиентом.
    Поделиться:

    Цитировать

    30.08.2010 в 17:25 # 5113
    Сколько вопросов :)

    Собственно сам вопрос был не к конкретной ситуации, просто такое встречалось не один раз и годы работы и стало интересно — это нормально или я что-то делаю не так. Для упрощения рассмотрим один какой-нибудь случай.

    1. Проект — это разработка нового продукта, а не саппорт, поэтому аналитик на проекте сравнительно недолго (как и все остальные, допустим пол года)
    2. Аналитик "анализирует" более 4-х лет. Но не специализируется на конкретной доменной области, поэтому в этой сравнительный новичек. Однако конфликт затрагивает скорее не бизнес, а UX.
    3. См предыдущий пункт :) Еестественно в бизнесе заказчик более "прокачен", но в аналитике, проектировании и юзабилити менее. Иногда молодость заказчика имеет айтишные корни — это и усложняет и упрощяет :)
    4. Аргументы могут быть разными. начиная от "я хочу чтобы тут был чекбокс и он включал то-то" (а наалитик уже пытается мержить это с существующими требованиями и здравым смыслом) до "мне неудобно.. " и "не логично тут как-то…"
    5. Обычно мнения делятся — координаторы и иже с ними хотят, чтобы заказчик был доволен и платил деньги (значит не надо их нервировать и делать как он говорит). девелоперы за то, как проще для них с точки зрения реализации. Ну и без обид, средний программист — это обсолютно не средний пользователель, скорее даже наоборот, уж очень специфическое у них мышление. QA обычно не привлекается к таким активносям как проектирование. Остаются только аналитики, но если он один на проекте, то собрать мнение не с кого. Советы с колегами с др проектов дают основание полагать, что суждения аналитика вполне разумны и к ним можно прислушаться.
    6. Конечно все "без фанатизма". Дорогие часы такого ресурса как аналитик не тратятся впустую. Инвестигейшн был не с нуля, поэтому: разговор (30 мин), табличка (30 мин), ссылки + мокапы (час-два). Итого в сумме пара часов.

    Поделиться:

    Цитировать

    30.08.2010 в 17:28 # 5114
    Вопрос — а надо ли это вам (если учитывать то, сколько уже было впустую потрачено времени и сил на убеждение)? Требование не критичное, ни с чем не конфликтует и т.д. — таким образом, это просто мелкая прихоть заказчика, который является в данном случае лицом, принимающим решение. Есть такая мысль, что согласиться на его требование будет проще и в некоторых случаях полезнее.

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

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

    Само собой! тут даже никакх сомнений, все делается очень вежливо и аккуратно. Мне даже грамоту дали на позапрошлом проекте — за умение общаться с трудными заказчиками :)

    Поделиться:

    Цитировать

    30.08.2010 в 17:48 # 5115
    Аватар (Сара Гиршфельд)
    Сара Гиршфельд
    Подписчик
    Если требование некритичное, то не стоит тратить столько сил на то, чтобы убедить заказчика, что он не прав. Он платит и имеет право хотеть что угодно. И неважно, по какой причине заказчик хочет сделать вот так: из-за незнания и непонимания, бзика "хочу именно так" либо Вам в пику. Вы, как аналитик, можете вежливо его направить в верном направлении, указать, что вот это можно реализовать по-другому, но неболее того. Делайте уступки заказчику, позвольте ему чувствовать себя значимым в мелочах, чтобы он уступал Вам в более критичных вещах. Иначе Вы все равно сделаете так, как хочет он, и оставите о себе мнение, как о непрофессионале.
    Поделиться:

    Цитировать

    31.08.2010 в 10:05 # 5116
    Ясно)
    Я так всегда и рассуждала и в целом, так и поступала. Просто интересно было мнение коллег по вопросу.
    Поделиться:

    Цитировать

    22.04.2011 в 17:01 # 5117
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    И так появился "аджайл" %)
    Поделиться:

    Цитировать

    30.01.2014 в 23:06 # 17048

    У кого такое было? Что делать ? и вообще нормально ли это и как к этому относится?

    Из личного опыта могу поделится, сплошь и рядом такие ситуации на всех проектах без исключений.
    Решение есть и действенное — донести проблематику/альтернативы решений/последствия PM проекта и с чистой совестью и чувством выполненного долга заниматься следующей задачей.
    И вообще действовать по принципу: «Кажи, що знаєш, роби, що мусиш і нехай буде як буде»

    Поделиться:

    Цитировать

    01.02.2014 в 19:33 # 17050

    Решение есть и действенное — донести проблематику/альтернативы решений/последствия PM проекта и с чистой совестью и чувством выполненного долга заниматься следующей задачей

    Делегирование риска — это тоже управление риском =)

    Но ведь косвенно в низком качестве продукта окажется виноват аналитик, т.к. ему придется документировать «некорректные» требования, и по окончании проекта уже никто может не вспомнить, почему то или иное требование было реализовано. Система соответствует спецификации — следовательно, прокол на этапе анализа.

    Отсюда следует необходимость дополнительно отмечать решения, принятые заказчиком, сохранять письма, в которых он официально утверждает соответствующую часть спецификации.

    Но в целом согласен — музыку заказывает тот, кто платит деньги. Главное — убедиться, что этот человек понимает, какую проблему пытается решить (или какую возможность реализовать), и как она, эта проблема, связана с бизнес-целями.

    Поделиться:

    Цитировать

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

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