Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Это все понятно.
Расскажите лучше, как вы удерживаете сотрудников от увольнения?
Умные люди долго не выдерживают работать на саппорте. Нужны какие-то мотиваторы, например зп значительно выше, чем в местах куда они могут уйти. Или вариант умных не брать.
Расскажите лучше, как вы удерживаете сотрудников от увольнения?
Умные люди долго не выдерживают работать на саппорте. Нужны какие-то мотиваторы, например зп значительно выше, чем в местах куда они могут уйти. Или вариант умных не брать.
Очень хороший вопрос!
Обязательно нужны мотиваторы (и не только для саппортов)!
Зп, к сожалению, может сработать только до определенной черты, после которой работодателю дешевле будет отказаться от сотрудника. А значит нужно придумать что-то еще.
Я думаю, во-первых, очень важно правильно сформировать у людей мнение о роли саппорта и направить мысли по правильному вектору. Донести идею, что саппорт — это не наказание (хоть многие так и считают), а сложная и важная работа, которая сопровождается не только починкой багов, но и разработкой нового функционала, основная масса которого, пусть и со временем, но идет именно после релиза продукта. Часто такая разработка может идти как основа для аналогичных задач на стадии программирования нового продукта, а значит саппорт уже не зря постарался и об этом можно и нужно сообщать специалисту. Тут стоит сказать, что я описываю ситуацию и процессы именно в нашей команде.
Так же мотиватором не обязательно должно быть что-то материальное. Лояльная политика в отношении графика работы, корп. отдых, компенсация на спорт, обучение — все то, что вроде и не относится к зп, но вполне способно с ней конкурировать и удержать сотрудника на любой позиции.
Хочется так же поделиться недавним опытом проведения мини-евента внутри отдела Разработки, который одновременно, как мне кажется, дает определенную мотивацию/заряд и спасает от проф.выгорания. Но первоначальный мой комментарий был раза в 3 длиннее, поэтому для пользы делу я напишу еще одну статью по теме, раз уж вопрос оказался таким интересным! За что Вам отдельное спасибо.
Обязательно нужны мотиваторы (и не только для саппортов)!
Зп, к сожалению, может сработать только до определенной черты, после которой работодателю дешевле будет отказаться от сотрудника. А значит нужно придумать что-то еще.
Я думаю, во-первых, очень важно правильно сформировать у людей мнение о роли саппорта и направить мысли по правильному вектору. Донести идею, что саппорт — это не наказание (хоть многие так и считают), а сложная и важная работа, которая сопровождается не только починкой багов, но и разработкой нового функционала, основная масса которого, пусть и со временем, но идет именно после релиза продукта. Часто такая разработка может идти как основа для аналогичных задач на стадии программирования нового продукта, а значит саппорт уже не зря постарался и об этом можно и нужно сообщать специалисту. Тут стоит сказать, что я описываю ситуацию и процессы именно в нашей команде.
Так же мотиватором не обязательно должно быть что-то материальное. Лояльная политика в отношении графика работы, корп. отдых, компенсация на спорт, обучение — все то, что вроде и не относится к зп, но вполне способно с ней конкурировать и удержать сотрудника на любой позиции.
Хочется так же поделиться недавним опытом проведения мини-евента внутри отдела Разработки, который одновременно, как мне кажется, дает определенную мотивацию/заряд и спасает от проф.выгорания. Но первоначальный мой комментарий был раза в 3 длиннее, поэтому для пользы делу я напишу еще одну статью по теме, раз уж вопрос оказался таким интересным! За что Вам отдельное спасибо.
Интересно, но можно просьбу по оформлению?
У вас на последней схеме есть ПЛАН и ОЧЕРЕДЬ, а в тексте вы говорите про Бэклог (который ОЧЕРЕДЬ) и Текущую очередь (которая ПЛАН), и это вносит путаницу.
У вас на последней схеме есть ПЛАН и ОЧЕРЕДЬ, а в тексте вы говорите про Бэклог (который ОЧЕРЕДЬ) и Текущую очередь (которая ПЛАН), и это вносит путаницу.
Расскажу примерно то же самое но с точки зрения обычного сотрудника техподдержки)
Не имею никакого отношения к ТС, обычная ситуация в обычной конторе.
Контора растет, задач становится больше и задачи становятся сложнее, новых сотрудников не нанимают, старым зарплату не повышают.
1. Начальство вводит различные KPI и SLA, пытаясь таким образом стимулировать сотрудников работать лучше.
2. Сотрудники самоорганизуются и выделяют отдельного сотрудника, чтобы оптимизировал очередь задач и следил за выполнением KPI. KPI теперь выполняется на 100%, но по факту сотрудников стало еще меньше, и один из них занимается по сути бесполезной работой.
3. Т.к. цель «выполнения задач» преобразовалась в цель «соблюдения KPI», все таски начинают делаться строго по ТЗ. Эффективность работы повышается.
4. Сотрудник, который оптимизировал очередь, приобретает скилл отклонения неправильно оформленных задач, бесконечного откладывания неважных задач, обоснованного сдвига сроков важных задач.
5. Пользователи и начальники, которые раньше не понимали куда тратят свое время суппортеры, теперь видят что суппорт занят 24/7
6. Количество новых задач естественным образом сокращается, старые задачи или доделываются или срок годности истекает
7. Рядовые сотрудники как пахали так и пашут, ЗП повысили только начальнику
8. PROFIT!!!111
Не имею никакого отношения к ТС, обычная ситуация в обычной конторе.
Контора растет, задач становится больше и задачи становятся сложнее, новых сотрудников не нанимают, старым зарплату не повышают.
1. Начальство вводит различные KPI и SLA, пытаясь таким образом стимулировать сотрудников работать лучше.
2. Сотрудники самоорганизуются и выделяют отдельного сотрудника, чтобы оптимизировал очередь задач и следил за выполнением KPI. KPI теперь выполняется на 100%, но по факту сотрудников стало еще меньше, и один из них занимается по сути бесполезной работой.
3. Т.к. цель «выполнения задач» преобразовалась в цель «соблюдения KPI», все таски начинают делаться строго по ТЗ. Эффективность работы повышается.
4. Сотрудник, который оптимизировал очередь, приобретает скилл отклонения неправильно оформленных задач, бесконечного откладывания неважных задач, обоснованного сдвига сроков важных задач.
5. Пользователи и начальники, которые раньше не понимали куда тратят свое время суппортеры, теперь видят что суппорт занят 24/7
6. Количество новых задач естественным образом сокращается, старые задачи или доделываются или срок годности истекает
7. Рядовые сотрудники как пахали так и пашут, ЗП повысили только начальнику
8. PROFIT!!!111
Страшную ситуацию Вы описали, хоть и типичную, наверное.
Мое субъективное мнение как project manager из отдела Разработки. KPI для разработчика равносильно удавке на шее. Никакой мотивации, одни лишь нервы от страха совершить ошибку. Что только замедляет темп и ухудшает качество. Поэтому, начиная с ситуации «задач становится больше и задачи становятся сложнее» и «Начальство вводит различные KPI и SLA», я бы о многом задумался. По крайне мере сейчас, хотя и не исключаю того, что когда-нибудь посмотрю на это под другим углом.
В здоровой компании должны быть иные методы мотивации сотрудников, частично о которых я планирую рассказать в статье по теме к комментарию grinCo.
Мое субъективное мнение как project manager из отдела Разработки. KPI для разработчика равносильно удавке на шее. Никакой мотивации, одни лишь нервы от страха совершить ошибку. Что только замедляет темп и ухудшает качество. Поэтому, начиная с ситуации «задач становится больше и задачи становятся сложнее» и «Начальство вводит различные KPI и SLA», я бы о многом задумался. По крайне мере сейчас, хотя и не исключаю того, что когда-нибудь посмотрю на это под другим углом.
В здоровой компании должны быть иные методы мотивации сотрудников, частично о которых я планирую рассказать в статье по теме к комментарию grinCo.
Простите, из вашей статьи не понятно чем именно занимается ваша техподдержка? И как именно?
Вы не описали ничего про уровни техподдержки. Вы написали про разработку. Вопросы разработки не совсем относятся к компетенции техподдержки.
Не увидел конкретики по вопросам как вы решили обработку типичных проблем и вопросов, предположительно, на 1-й линии поддержки.
Самое главное я не увидел в статье информации о том, что вы сделали для того чтобы устранять первопричины возникших инцидентов.
Спасибо за статью, есть несколько вопросов:
- На основании чего вырабатывали лиммиты по плану?
- Как происходит обработка задачи которую, после выполнения, клиент повторно вернул по причине не 100% готовности, но закрытой разработчиком?
Рад, что есть такой интерес. Значит все не зря.
1. Сначала я установил лимит на основе интуиции. После 1-2 недель уже была обратная связь и стало ясно в какую сторону требуется корректировка лимита (в нашем случае я сперва переоценил возможности и сделал его равным 8 — пришлось уменьшать). Главное найти тот самый баланс, когда задач в Плане достаточно для того, чтобы разработчики не простаивали. При этом сам План не раздувался до уровня Очереди.
Если не знаете с чего начать, то вот простая формула {кол-во разработчиков}*2={лимит}
Дальше вы уже сами поймете требуется ли изменить лимит или нет.
2. У меня для подобных задач есть 2 сценария:
а) если в задаче что-то пошло не так по нашей вине — она попадает в План в самую верхнюю строчку
б) если по задаче появились доп. доработки, которые не были ранее обозначены в описании (при этом функционал соответствует mvp и может обойтись без этих допов) — она идет в общую Очередь, либо, по-хорошему, ставится новая задача и так же попадает в общую Очередь.
Тут еще стоит сказать, что цель наших действий — уменьшить время существования задачи, т.е. нам нужно ее выполнять так, чтобы клиент смог пользоваться функционалом как можно скорее. Поэтому, если позволяют ресурсы, то я всегда для возвращаемых задач стараюсь пойти по первому варианту. Главное подходить к этому здраво.
В свое время мне очень помогла статья в виде pdf на 90 листов — «Scrum и Kanban. Выжимаем максимум». Так же подойдет книга «Канбан. Альтернативный путь в Agile»
1. Сначала я установил лимит на основе интуиции. После 1-2 недель уже была обратная связь и стало ясно в какую сторону требуется корректировка лимита (в нашем случае я сперва переоценил возможности и сделал его равным 8 — пришлось уменьшать). Главное найти тот самый баланс, когда задач в Плане достаточно для того, чтобы разработчики не простаивали. При этом сам План не раздувался до уровня Очереди.
Если не знаете с чего начать, то вот простая формула {кол-во разработчиков}*2={лимит}
Дальше вы уже сами поймете требуется ли изменить лимит или нет.
2. У меня для подобных задач есть 2 сценария:
а) если в задаче что-то пошло не так по нашей вине — она попадает в План в самую верхнюю строчку
б) если по задаче появились доп. доработки, которые не были ранее обозначены в описании (при этом функционал соответствует mvp и может обойтись без этих допов) — она идет в общую Очередь, либо, по-хорошему, ставится новая задача и так же попадает в общую Очередь.
Тут еще стоит сказать, что цель наших действий — уменьшить время существования задачи, т.е. нам нужно ее выполнять так, чтобы клиент смог пользоваться функционалом как можно скорее. Поэтому, если позволяют ресурсы, то я всегда для возвращаемых задач стараюсь пойти по первому варианту. Главное подходить к этому здраво.
В свое время мне очень помогла статья в виде pdf на 90 листов — «Scrum и Kanban. Выжимаем максимум». Так же подойдет книга «Канбан. Альтернативный путь в Agile»
Всё-таки, не очень понятна идея про канбан.
Есть Текущий План — это понятно, но вдруг прилетает срочная задача, и тех.менеджер куда её ставит? В Текущий План? На какое место? Или в общий список задач, но с высшим приоритетом?
Есть Текущий План — это понятно, но вдруг прилетает срочная задача, и тех.менеджер куда её ставит? В Текущий План? На какое место? Или в общий список задач, но с высшим приоритетом?
Считаем, что в текущем Плане все задачи с обычным приоритетом, их 4, что соответствует лимиту
Конечно, есть задачи из разряда «мы каждые 5 мин теряем млн» — тут ничего не поделать, бросаем все и делаем то, что нужно для решения, но это бывает крайне редко.
- прилетает срочная задача, которую просят взять как можно скорее в работу
- тех.менеджер ставит ее в План
- на основе приоритета она попадает в верхнюю строку — она сама ближайшая на выполнение
- т.к в этот момент у нас в Плане задач становит 5 (а лимит у нас 4), то вы либо убираете из списка самую нижнюю, либо оставляете все, если у вас предусмотрен слот под «пожар» — лучше убрать и соблюдать лимиты, так больше порядка
- закончив свою текущую задачу, первый из освободившихся разработчиков берет срочную
- вы спокойно дальше дополняете План, не позволяя ему пустовать
Конечно, есть задачи из разряда «мы каждые 5 мин теряем млн» — тут ничего не поделать, бросаем все и делаем то, что нужно для решения, но это бывает крайне редко.
По сути, раньше было несколько исполнителей которые брали себе задачи из пула задач без приоритетов. Вы сделали параллелизацию выполнения задач, которые берутся из одной очереди с приоритетами.
Это канбан ?
Немного опишу как было раньше.
Все задачи попадают в один огромный список на Разработку. В этом списке разработчики выбирают себе в работу задачи. Приоритет зачастую устанавливает не тех.менеджер, а продакт, который работает с клиентом (с одной стороны это правильно, но с другой, если лень разбираться, то продакт все задачи делает с высоким приоритетом и ничего хорошего от этого не выходит). Так у нас в нашем огромном списке появляются задачи с приоритетом всех мастей. НО! Оказывается есть еще более срочные задачи, которые ставятся непосредственно на специалиста. Таким образом, у каждого специалиста кроме общего списка появляется еще и персональный, который не имеет ограничений.
В итоге получаем (даже не буду считать сколько) кучу списков из задач, с размытыми сроками и сомнительными приоритетами.
И, конечно же, в этом хаосе любой разработчик абсолютно точно игнорирует приоритет и берет ту задачу, которая сходу ему наиболее понятна. Все. Любая задача имеет хорошие шансы быть забытой и находиться в работе непростительно долгое время.
Теперь как стало.
Все входящие задачи попадают к тех.менеджеру. Дальше либо задаются уточняющие вопросы, либо переводятся в общую Очередь, до которой доступа у разработчиков нет. На основе текущей ситуации (приоритетов) тех.менеджер набирает План и управляет им.
Тут разработчики уже видят не 100 задач, а 4. Теперь они знают в каком порядке нужно их вытягивать в работу. Соответственно, нет шансов «улизнуть» от какой-либо задачи.
Где тут Канбан?
1. Канбан в доске (мы пользуемся redmine, но сути это не меняет)
2. Канбан в вытягивающей схеме работы
3. Канбан в попытках непрерывного улучшения процессов (ведь в этом его суть)
Это как минимум. Однако, я не говорю, что мы полностью работаем по «чистому» Канбану. Нет. Мы взяли часть принципов и методик, и провели адаптацию под собственные процессы. Впрочем, даже это уже приносит свои плоды с момента внедрения до текущего момента
Все задачи попадают в один огромный список на Разработку. В этом списке разработчики выбирают себе в работу задачи. Приоритет зачастую устанавливает не тех.менеджер, а продакт, который работает с клиентом (с одной стороны это правильно, но с другой, если лень разбираться, то продакт все задачи делает с высоким приоритетом и ничего хорошего от этого не выходит). Так у нас в нашем огромном списке появляются задачи с приоритетом всех мастей. НО! Оказывается есть еще более срочные задачи, которые ставятся непосредственно на специалиста. Таким образом, у каждого специалиста кроме общего списка появляется еще и персональный, который не имеет ограничений.
В итоге получаем (даже не буду считать сколько) кучу списков из задач, с размытыми сроками и сомнительными приоритетами.
И, конечно же, в этом хаосе любой разработчик абсолютно точно игнорирует приоритет и берет ту задачу, которая сходу ему наиболее понятна. Все. Любая задача имеет хорошие шансы быть забытой и находиться в работе непростительно долгое время.
Теперь как стало.
Все входящие задачи попадают к тех.менеджеру. Дальше либо задаются уточняющие вопросы, либо переводятся в общую Очередь, до которой доступа у разработчиков нет. На основе текущей ситуации (приоритетов) тех.менеджер набирает План и управляет им.
Тут разработчики уже видят не 100 задач, а 4. Теперь они знают в каком порядке нужно их вытягивать в работу. Соответственно, нет шансов «улизнуть» от какой-либо задачи.
Где тут Канбан?
1. Канбан в доске (мы пользуемся redmine, но сути это не меняет)
2. Канбан в вытягивающей схеме работы
3. Канбан в попытках непрерывного улучшения процессов (ведь в этом его суть)
Это как минимум. Однако, я не говорю, что мы полностью работаем по «чистому» Канбану. Нет. Мы взяли часть принципов и методик, и провели адаптацию под собственные процессы. Впрочем, даже это уже приносит свои плоды с момента внедрения до текущего момента
Могу предположить, что все сотрудники поддержки объединены в редмайне в группу на которую обычно у вас и ставятся задачи. С введением Канбана, также как и с Agile просто нельзя перевести в статус в работе больше чем задано в настройках. С этим все понятно. Это идеально для работы в одном проекте в котором Канбан и настроен. Но что делать если работать приходится с несколькими проектами в который входят все те же сотрудники? Как стоит организовать работу в таком случае?
Предположу, что вы описываете работу плагина Agile для redmine.
Так как у нас в поддержке приходится работать не с одним проектам, то я столкнулся ровно с теми же проблемами в работе с данным плагином. Хоть, на сколько я помню, можно перейти на общий урл плагина, который показывает задачи по всем проектам в рамках выбранного фильтра, для меня интерфейс все равно был не слишком удобен (версию использовали бесплатную, до платной дело не дошло).
Поэтому ситуацию я решил через создание фильтров для соответствующих очередей и введения переменной, на основании которой и строил нужный фильтр.
Таким образом, мы видим все задачи по всем нужным проектам.
Не буду раздувать комментарий полным описанием, так как это понятен на целую статью, но если есть интерес по данному вопросу, то могу предложить перейти в лс
Так как у нас в поддержке приходится работать не с одним проектам, то я столкнулся ровно с теми же проблемами в работе с данным плагином. Хоть, на сколько я помню, можно перейти на общий урл плагина, который показывает задачи по всем проектам в рамках выбранного фильтра, для меня интерфейс все равно был не слишком удобен (версию использовали бесплатную, до платной дело не дошло).
Поэтому ситуацию я решил через создание фильтров для соответствующих очередей и введения переменной, на основании которой и строил нужный фильтр.
Таким образом, мы видим все задачи по всем нужным проектам.
Не буду раздувать комментарий полным описанием, так как это понятен на целую статью, но если есть интерес по данному вопросу, то могу предложить перейти в лс
У нас очередь — бэклог, чем выше таск, тем выше у него проиритет. Начинаешь просматривать таски сверху вниз, по уменьшению проиритета и берешь себе первый понравившийся.
По моему опыту работы в техподдержке, в таком подходе есть две проблемы:
- Не все разработчики могут работать ровно 7 часов в день. Бывают дни, когда голова совсем не соображает, и вместо положенных семи-восьми часов на кодинг уходит часа два-три, а в остальное время
залипаешь на хабрезанимаешься непродуктивной деятельностью. Зато в другие дни прет так, что выполняешь 16-часовой объем работы за восемь часов. Преимущество двухнедельного спринта в том, что он позволяет сгладить эти пики и провалы и в среднем проиводительность каждые две недели получается одинаковой. Если же стоять с кнутом рядом с разработчиком, чтобы он, не дай бог, не тратил свое время на комментирование всяких статей на Хабре и каждый день выдавал 7-8 кодо-часов, то большинство разработчиков впадают в депрессию и увольняются. Справедливости ради, надо сказать, что я встречал и других разработчиков, которые способны работать 8 часов с перерывом только на обед и туалет, но, обычно, их производительность на двухнедельном интервале оказывалась либо такой же, либо даже ниже, а качество их работы, зачастую, было довольно посредственным. Если бы вот они хотели уволиться, то было бы, наверное, даже не особо-то и жалко, но увольняться хотели только те, кто писал хороший и качественный код, но не желал работать ровно по восемь часов в день. Но я, конечно, допускаю, что это, возможно, мне так не повезло и мне попались «избалованные разработчики», которые не могут работать без роликов с котятами на ютубе и ежедневного Хабра. (Сам я, если что, тоже такой.) - В зависимости от качества поддерживаемого продукта, бывает так, что приходит жалоба на какую-то проблему, начинаешь разбираться и оказывается, что это отдел разработки
наговнокодилнаделал костылейреализовал не совсем удачное решение. Или что это проблема архитектуры, которая привела к тому, что абстракции нижележащего слоя в проекте стали протекать. Или что это бизнес-аналитик не предусмотрел такой сценарий и проблема на самом деле в требованиях. Или что бизнес-аналитиков на проекте вообще не нет, а разработчики не до конца понимали предметную область. Но ты — сотрудник техподдержки, вот у тебя задача, на которой стоит значок «XL», а значит она оценена в четыре часа или в два дня, или сколько там означает XL. И ты сидишь и думаешь, либо зарыться в 20 тысяч страниц спецификации предметной области, написанной инопланетянами для инопланетян (если она вообще есть), и потратить неделю только на локализацию проблемы, либо приделать еще пару костылей и скрестить пальцы наудачу. В общем, суть здесь в том, что проблемы здесь создают одни люди (говнокодеры из отдела разработки, тестировщики, которые это проморгали, бизнес-аналитики или менеджмент, который пожалел денег на бизнес-аналитиков), а разгребать все это приходится сотрудникам техподдержки. Это очень благодатная почва для возникновения межличностных конфликтов и если не предусмотреть возможность переадресации задачи, например, в отдел разработки после ее первоначального анализа сотрудником техподдержки, то у него может сложиться ощущение, что он целыми днями решает проблемы, созданные другими людьми, и что это не совсем честно, и что проходит время и ничего не меняется, и все навязчивее звучат в голове мысли о том, чтобы бросить все это и уволиться. У нас было не все так печально, как я здесь обрисовал, но все же была возможность приостановить задачу после первоначального анализа (который спокойно может занять полдня), отодвинуть ее ниже в списке приоритетных задач или вообще переадресовать в другой отдел.
Все написано справедливо.
Уточню, что вариант с размерами задач «L,XL и тд» мы пробовали, но в итоге отказались. Как раз из-за возникновения ситуаций, когда задача оказывается не такой простой и требовала больше времени, что влекло за собой изменение очереди на разработчике.
Сейчас мы работаем по 3 описанному варианту из статьи. Фактически я не ограничиваю разработчика по времени выполнения задачи, даже если она была недооценена. Задача разработчика сделать качественный функционал, а прочие вопросы оставляем на менеджеров.
Периодически встречаются задачи, в которых без причастного программиста не разобраться. Тут вы верно написали. Мы либо у него консультируемся, либо передаем задачу, но такое бывает не часто.
Уточню, что вариант с размерами задач «L,XL и тд» мы пробовали, но в итоге отказались. Как раз из-за возникновения ситуаций, когда задача оказывается не такой простой и требовала больше времени, что влекло за собой изменение очереди на разработчике.
Сейчас мы работаем по 3 описанному варианту из статьи. Фактически я не ограничиваю разработчика по времени выполнения задачи, даже если она была недооценена. Задача разработчика сделать качественный функционал, а прочие вопросы оставляем на менеджеров.
Периодически встречаются задачи, в которых без причастного программиста не разобраться. Тут вы верно написали. Мы либо у него консультируемся, либо передаем задачу, но такое бывает не часто.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тушили велосипед техподдержки