?

Log in

No account? Create an account

psilonsk


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


Previous Entry Share Next Entry
Задачка-водокачка № 12
psilonsk
Сегодняшняя задачка, как, впрочем, и все остальные задачки-водокачки, возникла на основе реальной ситуации в команде одного из моих приятелей.

Итак...

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

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

Для российской команды участие в поддержке было таким: каждый член команды должен был тратить на дежурство одну рабочую неделю раз в полтора-два месяца. Дежурство начиналось в 7 утра и продолжалось до 14:00. После этого сотрудник мог уйти домой, выполнение иных задач в период дежурства было необязательным. В офис тоже можно было не приходить - в компании были созданы условия для работы из дома, сотрудник, участвующий в поддержке, мог вообще не показываться неделю в офисе.

В дежурстве должны были участвовать все, кроме менеджера. Само дежурство могло протекать по-разному. Иногда система демонстрировала чудеса стабильности, и все дежурство человек курил бамбук. Иногда приходилось попотеть, из разных регионов мира непрерывным потоком шли заявки, которые нужно было быстро выполнять.
Замечу, что поддержка на 90% состояла в разрешении именно технических проблем, не было никаких "ой, у меня мышка красненьким горит!". Специфика системы была в том, что ее пользователями были, в основном, другие компьютерные системы. Оставшиеся 10% состояли из ответов на вопросы пользователей - либо таких же технарей, либо людей, ориентированных на узкие бизнес-задачи (и тоже не чуждых техническим проблемам).

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

Как победить этот конфликт? Что бы вы посоветовали менеджеру команды?


Ответы принимаются до пятницы. Комментарии к этой задачке открыты.


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

  • 1
поставить багтрекер, потратить пару недель на обучение и еще пару недель - на аккуратное заворачивание туда пользователей. распределить решение задач равномерно по всему миру и людям, а не выдирать человека на неделю из рабочего процесса. назначить SLA, метрики, ежемесячные/еженедельные ревью. Договориться о проценте времени, отдаваемом на поддержку и соответственно рапортовать. Сделать экспертную группу из нескольких человек, которая анализирует трекер и ведет патч-релизинг по условленному расписанию, раз в месяц, например. Через несколько месяцев станет ясна реальная загрузка и есть ли прогресс в поддержке.

Честно говоря, первый раз слышу о таком способе поддержки, если только не выезжают в поля - но в поля выезжают на месяцы обычно. хотя и сама работала follow the sun, разумеется.

неделю курить бамбук на поддержке если проблем не было, имхо им этот баг треккер вообще поперек горла стоять будет.

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

Нанять отдельного человека именно на поддержку. Удалённо.

Присоединяюсь про отдельного человека, но лучше в офис. Распоясается он на удаленке.

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

1. Жестко наказывать за нытье - штрафовать, увольнять и изгонять. В должностных обязанностях должен быть прописан функционал сотрудника. Этот способ подходит, когда все сотрудники заменимы;
2. Сам менеджер должен оставаться с сотрудниками. Звучит несколько бредово, но данный якорь в сплоченных коллективах позволяет чувствовать большую ответственность сотруднику:"Мой генерал копает окопы". Этот способ подходит для небольших компаний до 100 человек, где все знают друг друга в лицо или около того(из условий задачи не ясно, сколько сотрудников работают в компании). Альтернативный вариант назначать в смену двух сотрудников - сработает хуже, но идея с якорем аналогична;
3. Нанять и обучить специального человека. Студент, фрилансер, бомж - кто угодно, лишь бы сотрудники перестали делать это собственноручно. Идея простая - забыть о поддержке, как о страшном сне. Важно найти ответственного человека, обучить и контролировать. Проблема может быть в том, что система слишком сложная или конфиденциальная для обучения внешнего человека;
4. Делегировать подобную функцию частично или полностью на аутсорс. Кажется, что в ближайшее время можно будет отдать на аутсорс абсолютно всё. А ля двое из ларца, одинаковых с лица. Из минусов все знают, как работает аутсорс;
5. Распределить функции тех.поддержки среди сотрудников равномерно. Отказаться от дежурства, получать и обрабатывать запросы в фоновом режиме;
6. Оптимизировать работу программы. По-простому сделать так, чтобы технических запросов становилось меньше в каждый новый период времени. Для ноющих сотрудников это может быть отличный вызов. Не нравится сидеть? Сделайте так, чтобы не пришлось. Отлично связывается с пунктом 3. Упростите так, чтобы дебил мог справиться с поддержкой.

1 - нет, не годится, технология уникальна, подготовка 1 человека была около 6-7 месяцев (не студента, опытного программера).

2 - менеджер должен забить на работу и сидеть рядом с дежурным каждый день с 7 до 14?

3 - см. пункт 1

5 - прощай, развитие продукта

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

Первая мысль была - "уволить хлюпиков", но ваше предложение намного более рационально )

т.е. про бюджет ничего не сказано, то первое решение:
сделать дежурство более высокооплачиваемым нежели обычная работа и объявить конкурс на дежурство.

Бюджет фиксирован. Точнее, мы просто платим всем фикс.

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

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

2. Мотивация сотрудников. Если на обучение тратится 6-8 месяцев, то еще на старте сотруднику озвучивается будущий объем работ, включая поддержку, чтобы правильно формировать ожидания с самого начала сотрудничества. Пиарить поддержку, как это здорово и удобно - работать из дома и в 14.00 уже быть свободным. Внедрить мотивационную программу (идеально - привязать ее к SLA), связанную с поддержкой - бонусы, премия за каждый решенный инцидент.

Вот любят у нас премиями людей пугать. ) К сожалению, все знают, что выделить бюджет на премии в середине года невозможно. )

Геймификация?

Сделать финт и превратить эту работу из "дежурства" в "награду".
Не назначать, а выбирать из желающих.

Варианты как это сделать:
1. Подговорить одного из новичков подыграть, чтобы он говорил что это круто. Сначала говорит один, другие сначала посмеются, потом поверят, потом сами начнут это транслировать.
2. Пообещать (и выполнить) международное "собрание сотрудников поддержки" (Например, туда едет тот, кто больше всех отдежурил).
3. Больше платить за эту работу .
4. Говорить "спасибо" (Как можно больше морально удовлетворять) за дежурство. Причем "спасибо" должно звучать от всех - от ПМ, от начальства, от иностранных коллег при передачи смены.

И еще уточняющие вопросы к заданию:
1. Откуда финансируются затраты на поддержку?
2. Какой механизм расчета з/п сотрудников?



Re: Геймификация?

1. Оплата по ТМ.
2. Фикс у всех сотрудников.

Разработать систему мотивации привязанную к дежурствам и кол-во талонов закрытых во время смены.
Что-нибудь типа +100 баллов за смены + 10 за каждый закрытый талон.

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

А спокойный день (неделя), типа, и сама по себе праздник? )

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

Как определить размер этой дополнительной компенсации?

сегодня с утра читаю и все равно не могу понять - что такого негативного сотрудники находят в таком дежурство. Ну разве что рано вставать.
Сижу, чешу репу дальше.
Мне кажется, лупить надо именно в эту точку.

***

Зная менталитет наших айтишников, я предложил бы менеджеру любыми правдами и неправдами поменять смену 7-14 по местному времени на 16-23. Но, полагаю, это не представляется возможным, тем более на эту смену уже стоят европейцы, а они как раз не любят работать вечерами. Это ен решение, просто к слову пришлось

Это не круто )). Я срезаю пару углов, конечно, но смысл такой -- надо не штурмовать неизведанные вершины, а занудно и аккуратно.. ну не знаю -- картошку сортировать.

Очень разные типы людей делают эти вещи хорошо, похоже.

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

Увы, еще как можно...

Странные они. Радоваться надо)))
Встал в 6:50. И через десять минут уже работаешь. Из дома выходить не надо. Зато потом полдня свободно)))

Подавать надо не как повинность, а как награду.

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

  • 1