?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Упражнение для менеджера: суровая кнопочка
psilonsk


Представьте, что вы - менеджер проекта развития популярного онлайн-сервиса. Пусть, например, это будет ЖЖ (просто чтобы вопрос был понятен).

От одного из пользователей вы получаете такое письмо: "В интерфейсе ЖЖ всегда был баг - если ответить на заскриненный комментарий, то он контринтуитивно расскринивался. Все попытки починить этот баг, видимо, провалились, поэтому решили просто переименовать для таких случаев кнопку "Reply" в "Unscreen to reply".

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

Какие действия менеджера проекта в этом случае, на ваш взгляд, будут верными?

А. Запланировать анализ и исправление ошибки. Если пользователь видит проблему, она должна быть решена.

В. Ничего не делать. Нам лучше знать, как должна работать наша система.

С. Дать задание аналитику проверить требования к продукту - правда ли это ошибка? По результатам проверки принять решение - исправляем или нет.

D. Поговорить со спонсором проекта о проблеме. На основании разговора принять решение об исправлении.

E. Попросить менеджера продукта принять решение по поводу этого функционала. Как он скажет - так и сделаем.

F. Собрать управляющий комитет проекта и одним из вопросов обсуждения сделать это исправление. По результатам принять решение - исправляем или нет.

G. Моего варианта нет, отвечу в комментарии.
 



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Мой вариант - А+.
Т.е. ошибку, конечно исправить. Но и предоставить кнопку "Unscreen to reply": возможно, кто-то из пользователей уже привык к такому поведению продукта. Зачем лишать их привычного поведения?

Вариант B - конечно, глупость, совковый подход.
Вариант С - тоже глупость. Если в требованиях заложено ошибочное поведение - это не повод ссылаться на требования, это повод их исправить.
Вариант D - вопрос явно слишком мелок для Спонсора.
Варианты E, F - разные способы переложить решение очевидного вопроса на других.

Однозначно Е. Как менеджер продукта говорю)))

Как аналитик,могу сказать что чаще всего С+. Проанализировать не только требования, но и статистику обращений и затраты на исправление.

Е. Функционал - парафия продукта. И это НЕ перенос ответственности. Менеджер продукта - единственно ответственный за функционал и интерпретацию функционала.

А - не дает подтвержденного понимания что данную проблему надо решать именно так
В - Нам лучше знать как работает наша система, но задача в том, что делать с обозначенной проблемой, этот вариант задачу не решает.
С - немного не понятно какой конкретно функционал у аналитика и почему именно требования проверять. Если в требованиях так и написано - а клиенты жалуются, то получается ничего менять не надо? Опять, получается, что задача не решена.
D - слишком высоко для такой проблемы.
Е - единственный ответ который не вызывает никаких НО. Менеджер продукта - именно тот человек который отвечает за подобные вещи. Если вникать в каждое жалобное письмо, свой функционал я буду выполнять ужасно, а вот Менеджеор продукта должен быть в курсе на сколько его продукт актуален и востребован у клиентов. Возможно, стоит потратить время и проверить как в итоге была решена проблема, зависит от конкретного менеджера продукта.
F - слишком высоко для такой проблемы.


ни один вариант не подходит как всегда :)

где вы их берете?


Даже вариант G не подходит?


конечно нет

он подходит только в том случае, если вы будете писать ваш вариант в комментарии

только не говорите что вы программист :)


нет, не программист

Я мечусь между E и F.

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

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

Если же это банальный баг, то я бы просто попросил бы исправить.

Первым делом спросить аналитика. Мало ли - в ТЗ написано другое.
Если в ТЗ в явной форме данный вопрос не решен, задать вопрос менеджеру продукта.

И кстати - а какова роль менеджера проекта развития? Какова зона ответственности?
Славословить продукт? Внедрять фичи? Перемещение в выдаче поисковика?

Попробую рассуждать:
A) То, что один пользователь видит проблему, не значит, что ее видят остальные. Возможно, всем кроме него удобно именно так.
B) Мне нравится этот вариант, но только его первое предложение. Если ничего не делать, то со временем станет понятно является ли этот инцидент багом или нет.
С) Фигня какая-то.... Разве такую мелочь в требованиях к продукту можно прописать? Навернякак про нее никто не знал даже.
D) "Поговорить со спонсором проекта о проблеме. Спонсор должен участвовать в решении таких вопросов? Да он нас нафиг пошлет.
E) " Попросить менеджера продукта принять решение по поводу этого функционала". Я люблю
перевешивать ответственность на других, поэтому мне нравится этот вариант.
F) "Собрать управляющий комитет проекта и одним из вопросов обсуждения сделать это исправление." Мелковат вопрос для управляющего комитета.

Мало условий для моего варианта. Если пользователей прав и это действительно ошибка, которую нельзя победить, то объясняем пользователю, что это не баг, а фича и поступаем как и всегда поступают с такими запросами.
Если это не ошибка, а действительно все так и задумывалось, то тут нужно определять насколько данный функционал востребован и на основе этого принимаем решения по доработке.
Сама задача -- вполне себе рутина со стандартным бизнес-процессом управления требованиями миллион раз всеми обсосаная

В жежешечке выбрали вариант Б.
Тут даже ещё круче был случай: http://livelight.livejournal.com/449171.html

А. Запланировать анализ и исправление ошибки. Если пользователь видит проблему, она должна быть решена.
//Считаю, что в одобного рода проектах этот вопрос находится вне компетенций управляющего проектом.

В. Ничего не делать. Нам лучше знать, как должна работать наша система.
//Вообще не вариант. Интересно, есть ли еще динозавры не обращающие фнимание на фидбак пользователей

С. Дать задание аналитику проверить требования к продукту - правда ли это ошибка? По результатам проверки принять решение - исправляем или нет.
//1. Так как попытки починить баг уже были, то аналитик наверняка уже изучил требования в этом направлении. Ничего нового не узнаем.
2. Вероятно, что такой мелочи может не быть в требованиях.

D. Поговорить со спонсором проекта о проблеме. На основании разговора принять решение об исправлении.
//Не тот уровень и не тот вопрос. Даже если спонсор имеет интерес к участию в развитие продукта, с этим вопросом к нему должен идти продакт менеджер.

E. Попросить менеджера продукта принять решение по поводу этого функционала. Как он скажет - так и сделаем.
//По моему этот вопрос на 146% в компетенции продакт менеджера. Иначе зачем он нужен вообще?

F. Собрать управляющий комитет проекта и одним из вопросов обсуждения сделать это исправление. По результатам принять решение - исправляем или нет.
//По вопросам к изменению или детализации требований к продукту комитет стоит собирать опять же продакт менеджеру. Если такая роль присутствует.

E. Есть один ответственный за функционал или процесс, он должен решать. Может называться по-другому.

Получить комментарии продукт-менеджера по ситуации и в зависимости от их содержания или оставить этот вопрос на нём, либо запустить обсуждение по этому вопросу (если вопрос действительно острый, а продукт-менеджер отвергает проблему, то должен найтись оппонент со своими аргументами).

Не уверен, что этим должен заниматься менеджер по развитию, но если проблема встала на нём, то наверное проблема является острой и всё же касается развития продукта.

Никакого бага нет, всё нормально назвали.

Поставить фильтр на письма со словами "контринтуитивно" и "unscreen", чтоб не ебали мозги всякой хернёй.


вот он единственно правильный вариант


G. Задамся вопросом, а почему в проекте не определен процесс обработки пользовательского фидбэка и займусь его определением. Это вообще важнее судьбы одного конкретного фидбека, но все-таки пока этот фидбек пойдет либо в C либо в E в зависимости от распределения ролей в проекте, бывает такие решения делегируются аналитику, бывает продукт менеджеру.

A, B, D, F - совсем неправильно.

  • 1