Пример.
Есть программа в банке.
Есть продакт менеджер данного софта и есть куча пользователей и их начальников.
Начальники часто просят о каких-то плюшках продакта.
Продакт некоторые принимает и дает в разработку, некоторые реджектит.
Но некоторые реджекты эскалируются на уровень топ-менеджмента и чаще всего топ-менеджмент апрувит эти задачи, аргументирую, что это же надо бизнесу.
Но проблемы такие:
1. 80% из этих хотелок после внедрения успешно забываются через месяца два использования и их никто не юзает
2. Начальники часто используют эти хотелки для повышения своих KPI, чтобы показать движуху.
То есть движуха больше для KPI создается.
так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
Здравствуйте, snaphold, Вы писали:
S>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
Если логические и технические обоснования отказа не действуют, то только одно может отрезвлять внутреннего заказчика — разработка должна вестись из его бюджета. Сразу умнеет.
Здравствуйте, ry, Вы писали:
ry>Здравствуйте, snaphold, Вы писали:
S>>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками? ry>Если логические и технические обоснования отказа не действуют, то только одно может отрезвлять внутреннего заказчика — разработка должна вестись из его бюджета. Сразу умнеет.
так ради своего kpi и отчета потом руководству, что внедрили фитчу А, заказчик может убедить финдира, что нам это надо, чтобы улучшить продажи
Здравствуйте, snaphold, Вы писали:
ry>>Если логические и технические обоснования отказа не действуют, то только одно может отрезвлять внутреннего заказчика — разработка должна вестись из его бюджета. Сразу умнеет.
S>так ради своего kpi и отчета потом руководству, что внедрили фитчу А, заказчик может убедить финдира, что нам это надо, чтобы улучшить продажи
А дальше он потратит свой бюджет на её разработку и внедрение и будет дальше его тратить на поддержку. В таком случае он будет главным драйвером того, чтобы данная фича не была заброшена, а перед этим хорошо думать, насколько она ему нужна. Повторюсь, что не финдир должен убеждаться в необходимости данной фичи, а сам заказчик. Видимо, в твоём случае это невозможно.
S>Но проблемы такие: S>1. 80% из этих хотелок после внедрения успешно забываются через месяца два использования и их никто не юзает
А ты сделай так, что-бы не забывали. Выскакивающие попапы с напоминаниями "вы уже 5 дней не использовали эту фичу" и кнопками "прочитать про фичу"\"напомнить через 1 день"
Да и вообще пользователей с хотелками можно просто в жопу посылать, особенно тех, у кого нет выбора чем пользоваться.
А если серьезно, в чем проблема делать эти фичи? Я так понимаю всё это оплачивается, так в чём проблема — сиди и работай?
Здравствуйте, _AND, Вы писали:
_AN>А если серьезно, в чем проблема делать эти фичи? Я так понимаю всё это оплачивается, так в чём проблема — сиди и работай?
создается постоянный дедлайн и постоянно работаешь в режиме сроков, которые по факту фикция. Если бы реально что-то срочное и важное.
сроки постоянно приходится раздувать искусственно на разработку, т.к. сделаешь быстро — накинут еще
Здравствуйте, snaphold, Вы писали:
S>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
Для начала я бы все-таки попытался понять настоящий мотив заказчика. Мне не совсем понятно, как включение хотелок увеличит ваши КПИ, т.к. делая хотелки вы не будете делать другие задачи, а значит средний объем работы останется тем же. С другой стороны, заказчик платит вам деньги за то, чтобы вы делали для него задачи, которые он считает нужными, поэтому просто отказываться что-либо делать тоже не правильно.
Поэтому я бы поступил примерно так:
1. Посмотрел бы на эти хотелки и оценил бы их с точки зрения насколько понятно, что нужно делать и сколько это займет времени/ресурсов.
2. Пошел бы к ПМ и поставил вопрос таким образом — "Смотрите, вот есть новая хотелка (назовем ее фича Х), мы ее оценили в 50 стори поинтов (или там 1 человеко/месяц). Мы сможем ее сделать, однако для это придется отложить реализацию фичи А, которую мы запланировали в начале года, и фикс критического бага Б, который обнаружили на прошлой неделе. Пожалуйста, примите решение, что мы действительно должны делать фичу Х, а не фичи А и Б". Здесь может очень пригодится статистика по старым задачам. Например, если у вас скрам, то средний велосити команды. Тогда, если ваш ПМ, будет говорить, что вы сможете сделать фичу Х в добавок к фичам А и Б. Вы сможете предметно возразить, что — нет, не сможете, т.к. в среднем команда делает только одну такую фичу за спринт, поэтому прийдется что-то удалить.
В общем, я думаю, что здесь важно говорить с фактами на руках, можно завысить время на выполнение хотелки, описать потенциальные негативные эффекты и предоставить право решения ПМ. Скорей всего, он просто не захочет брать на себя ответственность и спусит это дело на тормозах. Такой подход также должен защитить вас от того, чтобы ПМ накидывал вам вдвое больше задач за то же время.
Если же вам просто жалко тратить время на никому не нужный функционал, то можно действовать проактивно и предложить какую-нибудь хотелку, которая будет интересна вам и полезна для системы. Например, сделать рефакторинг части функионала (нужно вам), который ускорит работу системы на 10% (полезно для заказчика). Такое может пойти вам в КПИ как хотелка, будет интересно вам и в принципе полезно заказчику.
Здравствуйте, snaphold, Вы писали: S>создается постоянный дедлайн и постоянно работаешь в режиме сроков, которые по факту фикция. Если бы реально что-то срочное и важное. S>сроки постоянно приходится раздувать искусственно на разработку, т.к. сделаешь быстро — накинут еще
это просто сигнал искать другую работу
вообще, существует несколько методов отказа от дурацких хотелок
самый надежный — пообещать и не сделать
второй — сказать — отличная идея! делайте. работает в случае, если у вас и так полно дел
третий — просто делегировать ее кому-нибудь случайному и забить
я лично чаще всего пользуюсь вторым способом, но тут нужно понимающее начальство. ну а если его нет, то надо искать
Здравствуйте, Sealcon190, Вы писали: S>Больше хотелок — больше работы. S>Больше работы — больше денег.
обычно проблема вот в том. допустим, ты работаешь над портированием проекта под Linux, а тебя отвлекают на заведомо бредовые задачи, типа, а давайте добавим возможность из ворда звонить на скайп, потом год проходит, тебя спрашивают чего ты сделал и ты говоришь — вот, значит, теперь из ворда можно звонить на скайп, у нас в хелпе есть анимация собаки и есть функция бэкапа данных на e-mail. а кто-то этим пользуется? не, никто. а портирование на Линукс, которое ждут тыщи клиентов уже два года, готово? нет, не готово. вот тебе и оценка на ревью
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Sealcon190, Вы писали: S>>Больше хотелок — больше работы. S>>Больше работы — больше денег. __>обычно проблема вот в том. допустим, ты работаешь над портированием проекта под Linux, а тебя отвлекают на заведомо бредовые задачи, типа, а давайте добавим возможность из ворда звонить на скайп, потом год проходит, тебя спрашивают чего ты сделал и ты говоришь — вот, значит, теперь из ворда можно звонить на скайп, у нас в хелпе есть анимация собаки и есть функция бэкапа данных на e-mail. а кто-то этим пользуется? не, никто. а портирование на Линукс, которое ждут тыщи клиентов уже два года, готово? нет, не готово. вот тебе и оценка на ревью
1. Т.е. конечное решение что делать принимает простой разработчик?
2. Пошлешь пользователей с их хотелками и продолжишь пилить Линукс — получишь на ревью "Игнорит запросы пользователей"
Здравствуйте, Dziman, Вы писали: D>1. Т.е. конечное решение что делать принимает простой разработчик?
ну да
вообще васе менеджеры с кем я работал имели очень мало власти, как ни странно. правда, почти всегда это были очень хорошие люди, которые просто старались не мешать. они занимались только тем, что пытались уследить, чем занимается команда
был один менеджер, который пытался энфорсить хотя бы отчетность по тикетам, но его все просто проигнорили и сказали не мешать работать
сейчас, например, у нас нет ни одного менеджера.
у начальства итак проблем хватает — фин. отчетность, какая-то коллаборация на уровне компаний, начало больших проектов, поиск денег. у них просто нет никакой возможности следить за тем, что и как делается в проекте. если оно лезет под руку программиста и говорит что и когда ему делать, то это неправильная компания, которая делает неправильный мед
D>2. Пошлешь пользователей с их хотелками и продолжишь пилить Линукс — получишь на ревью "Игнорит запросы пользователей"
если ты нанимался в техсаппорт, то это, разумеется. большинство проектов имеет столько пользователей, что нет никаких возможностей даже читать их пожелания. бывают конечно "суперпользователи". типа, директрисса посмотрела слезливое кино и сказала "эхх, добавить бы в корпоративный сайт наш розового и котиков". какой-нить жополизный менеджер может сразу метнуться к дизайнерам и сказать "запилите мне быстро щас же на весь сайт розового кота и чтобы моргал глазами когда кликаешь на него". правильный ответ на это — "а ну иди отсюдова". если хочется тактично послать, то обычно предлагается просто создать тикет и что рассмотрим в рабочем порядке наряду с остальными тысячами навсегда забытых тикетов. если менеджер напирает, то всегда можно сказать — без проблем, давай, нанимай еще одного человека, он нам это сделает. остальные заняты. если даже желающий вызовется, то потом по правилам сначала нужно неспешно запилить АБ тестирование, получить гневные письма и части обрадованных пользователей, отчитаться менеджеру, что внедрять не будет и забить на него. но — менеджер должен найти сам ресурсы для своих хотелок. разумеется, по факту директрисса сама будет в шоке от этого кота и про него менеджер постараются забыть, придумав, что это не его идея была вообще и даже поверив в это. но от таких менеджеров надо либо валить, либо уметь игнорить возвращаясь к ответу "а ну иди отсюдова со своей хренью"
Здравствуйте, snaphold, Вы писали:
S>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
1. заткнуться и делать, что хотят заказчики, т.к. они вам по факту платят деньги.
2. уйти работать из банка в софтверную/аутсорсинговую компанию, где заказчики обычно более вменяемые.
Здравствуйте, snaphold, Вы писали:
S>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
В организациях, где подразделение разработки является частью самой организации это явление не редкое. Здесь приходится выстраивать процесс "защиты" от таких вещей на организационном уровне, подкрепляясь утвержденными документами (регламентами, порядкам и т.п. что принято в организации). Самое простое — требование физического обоснования запрашиваемого функционала. Т.е. в заявке на реализацию какого-то функционала должны быть приведены расчеты эффективности: временные (эта работа у нас выполняется каждый день занимает 2 часа; в новых условиях сократится до 5 минут) — если сокращение времени будет 10 минут в месяц — дави не дави на начальство, реализовывать никто не заставит; денежные или еще какие-то. Без четко выстроенной организации этого процесса, запросы чтобы показать бурную деятельность не прекратятся никогда и их придется реализовывать.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Dziman, Вы писали: D>>1. Т.е. конечное решение что делать принимает простой разработчик? __>... D>>2. Пошлешь пользователей с их хотелками и продолжишь пилить Линукс — получишь на ревью "Игнорит запросы пользователей" __>...
Ясно-понятно: вещается опыт в конторах в которых пока не отсо найдешь подход не продвинешься.
Здравствуйте, Dziman, Вы писали: D>Ясно-понятно: вещается опыт в конторах в которых пока не отсо найдешь подход не продвинешься.
это ответ самому себе, чтоли?
Здравствуйте, Dziman, Вы писали:
D>1. Т.е. конечное решение что делать принимает простой разработчик?
На самом деле я такое встречаю достаточно часто. Например сейчас задачи формально аппрувит менеджер, но он делает это только после того, как мы выразили согласие. И если мы даём рекомендацию "отказать", то он всегда умудряется найти какое-то обоснование, которое удовлетворяет вопрошающих.
Здравствуйте, snaphold, Вы писали:
S>так вот грамотно отказывать кастомерам не доводя вопрос до топ менеджмента? то есть даже не относительно данной ситуации, а вообще как грамотно отшивать юзеров с хотелками?
У нас сделана формальная система для таких хотелок, и для каждой хотелки требуется среди всего прочего указать её экономический эффект для компании в $$$. Это очень многих останавливает.
