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