В теме 7 ответов, и 5 участников, последнее обновление сделано пользователем 
Igor Tkachenko 13 г, 7 мес. назад.
-
Сообщения
-
Всем доброго дня!
заранее прошу прощения, если тема "не в тему"
Вопрос в следующем. Есть проект, есть аналитик и заказчик.
Заказчик настаивает на конкретном требовании. Требование не критичное (скорее даже не требование, а деталь его реализации), с другими требованиями в конфликт не вступает и не связана напрямую с рабочими бизнес-процессами (в том смысле что не конфликтует с ними).Заказчик естественно не специалист в аналитике и проектировании, но он заказчик (он платит за то, что хочет именно он, а не аналитик).
Проблема — как его убедить, что предлагаемое аналитиком решение лучше, в том числе и для него (заказчика). Например оно удобнее для будущего пользователя и таким образом он заработает больше денег.
Были испробованы:
- приведение разумных доводов
- расписание всех возможных вариантов с плюсами и минусыми оных (сведение их в таблицу)
- рисование статичных мокапов
- делание динамических мокапов, чтобы можно было "поиграть"
- ссылки на статьи/книги гуру в своей области, которые советовали делать так, а не иначе (так как требование не принципиальное, то и у гуру у каждого свое мнение часто, ну и плюс найти в статье точно такую же проблему нереально, есть просто похожие — а это уже не то..)Ничего из упомянутого у аналитика не сработало. Возражения заказчика были не очень конструктивными, но настройчивыми, поэтом уделалось так, как хочет тот, кто платит.
У кого такое было? Что делать ? и вообще нормально ли это и как к этому относится?ПС я как аналитик болею всей душой, чтобы получился отличный продукт и я бы им гордилась. Но 15-20 таких решений, которые были не теми, что аналитик рекомендовал и продукт уже немного другой на выходе.
Вначале пару вопросов вам, чтобы разобраться в ситуации:1) Сколько аналитик работает на проекте?
2) Сколько аналитик работает в этой бизнес области?
3) Сколько заказчик работает в этой области?
4) Что именно отвечает заказчик (как реагирует) на все потуги?
5) Кто в команде аналитика и что думает по этому поводу?
6) Сколько суммарно уже времени и сил (хоть примерно) было потрачено уже на поиск и приведение доказательств?Согласен с Юрой, что ответы на приведенные вопросы важны в данном случае.
Еще немного философии в отсутствие ответов:
Вопрос — а надо ли это вам (если учитывать то, сколько уже было впустую потрачено времени и сил на убеждение)? Требование не критичное, ни с чем не конфликтует и т.д. — таким образом, это просто мелкая прихоть заказчика, который является в данном случае лицом, принимающим решение. Есть такая мысль, что согласиться на его требование будет проще и в некоторых случаях полезнее. Я знаю случаи, когда упорное несогласие и попытка продвинуть свою точку зрения (надеюсь, вы хоть вежливо и деликатно это делаете?
) приводили к провалу проекта и разрыву отношений с клиентом.Сколько вопросов
Собственно сам вопрос был не к конкретной ситуации, просто такое встречалось не один раз и годы работы и стало интересно — это нормально или я что-то делаю не так. Для упрощения рассмотрим один какой-нибудь случай.
1. Проект — это разработка нового продукта, а не саппорт, поэтому аналитик на проекте сравнительно недолго (как и все остальные, допустим пол года)
2. Аналитик "анализирует" более 4-х лет. Но не специализируется на конкретной доменной области, поэтому в этой сравнительный новичек. Однако конфликт затрагивает скорее не бизнес, а UX.
3. См предыдущий пункт Еестественно в бизнесе заказчик более "прокачен", но в аналитике, проектировании и юзабилити менее. Иногда молодость заказчика имеет айтишные корни — это и усложняет и упрощяет
4. Аргументы могут быть разными. начиная от "я хочу чтобы тут был чекбокс и он включал то-то" (а наалитик уже пытается мержить это с существующими требованиями и здравым смыслом) до "мне неудобно.. " и "не логично тут как-то…"
5. Обычно мнения делятся — координаторы и иже с ними хотят, чтобы заказчик был доволен и платил деньги (значит не надо их нервировать и делать как он говорит). девелоперы за то, как проще для них с точки зрения реализации. Ну и без обид, средний программист — это обсолютно не средний пользователель, скорее даже наоборот, уж очень специфическое у них мышление. QA обычно не привлекается к таким активносям как проектирование. Остаются только аналитики, но если он один на проекте, то собрать мнение не с кого. Советы с колегами с др проектов дают основание полагать, что суждения аналитика вполне разумны и к ним можно прислушаться.
6. Конечно все "без фанатизма". Дорогие часы такого ресурса как аналитик не тратятся впустую. Инвестигейшн был не с нуля, поэтому: разговор (30 мин), табличка (30 мин), ссылки + мокапы (час-два). Итого в сумме пара часов.Вопрос — а надо ли это вам (если учитывать то, сколько уже было впустую потрачено времени и сил на убеждение)? Требование не критичное, ни с чем не конфликтует и т.д. — таким образом, это просто мелкая прихоть заказчика, который является в данном случае лицом, принимающим решение. Есть такая мысль, что согласиться на его требование будет проще и в некоторых случаях полезнее.
Именно так я всегда и рассуждала. Просто интересно у всех ли так?
Ну и я как аналитик несу ответственость за конечную систему — я ведь ее проектировала. Она как бы "в моем портфолио".
Заказчик может даже в конце, когда начнет пользоваться не осозновать, он может просто чувствовать что ему не очень удобно тут и тут, а на самом деле именно его решения привели к этому неудобству и нелогичности.Я знаю случаи, когда упорное несогласие и попытка продвинуть свою точку зрения (надеюсь, вы хоть вежливо и деликатно это делаете? ) приводили к провалу проекта и разрыву отношений с клиентом.
Само собой! тут даже никакх сомнений, все делается очень вежливо и аккуратно. Мне даже грамоту дали на позапрошлом проекте — за умение общаться с трудными заказчиками
Если требование некритичное, то не стоит тратить столько сил на то, чтобы убедить заказчика, что он не прав. Он платит и имеет право хотеть что угодно. И неважно, по какой причине заказчик хочет сделать вот так: из-за незнания и непонимания, бзика "хочу именно так" либо Вам в пику. Вы, как аналитик, можете вежливо его направить в верном направлении, указать, что вот это можно реализовать по-другому, но неболее того. Делайте уступки заказчику, позвольте ему чувствовать себя значимым в мелочах, чтобы он уступал Вам в более критичных вещах. Иначе Вы все равно сделаете так, как хочет он, и оставите о себе мнение, как о непрофессионале.Ясно)
Я так всегда и рассуждала и в целом, так и поступала. Просто интересно было мнение коллег по вопросу.И так появился "аджайл"
У кого такое было? Что делать ? и вообще нормально ли это и как к этому относится?
Из личного опыта могу поделится, сплошь и рядом такие ситуации на всех проектах без исключений.
Решение есть и действенное — донести проблематику/альтернативы решений/последствия PM проекта и с чистой совестью и чувством выполненного долга заниматься следующей задачей.
И вообще действовать по принципу: «Кажи, що знаєш, роби, що мусиш і нехай буде як буде»Решение есть и действенное — донести проблематику/альтернативы решений/последствия PM проекта и с чистой совестью и чувством выполненного долга заниматься следующей задачей
Делегирование риска — это тоже управление риском =)
Но ведь косвенно в низком качестве продукта окажется виноват аналитик, т.к. ему придется документировать «некорректные» требования, и по окончании проекта уже никто может не вспомнить, почему то или иное требование было реализовано. Система соответствует спецификации — следовательно, прокол на этапе анализа.
Отсюда следует необходимость дополнительно отмечать решения, принятые заказчиком, сохранять письма, в которых он официально утверждает соответствующую часть спецификации.
Но в целом согласен — музыку заказывает тот, кто платит деньги. Главное — убедиться, что этот человек понимает, какую проблему пытается решить (или какую возможность реализовать), и как она, эта проблема, связана с бизнес-целями.
Вы должны авторизироваться для ответа в этой теме.
