Как стать автором
Обновить

Как мы решили проблему дискоммуникации между разработкой и сопровождением и создали единую продуктовую команду

Время на прочтение13 мин
Количество просмотров3.8K
Всего голосов 4: ↑3 и ↓1+2
Комментарии6

Комментарии 6

что-то не понял, есть ли у вас 1-я линия и 2-я линия саппорта? т.е. есть ли сапорт могущий сам менять код? Если нет, то получается все задачи и поддержки и развития девелопит одна команда?

Смотри:

В Фактуре существует две линии саппорта.

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

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

альтернативный варинт - 2-я линия может и даже должна фиксить код, комитить и отправлять патчи. В таком варианте у задач саппорта свой беклог и они не зависят от ресурсов разработки.

У любой задачи всегда есть несколько вариантов решения, которые зависят от наших целей и ограничений. Тут не поспоришь.

Но давай посмотрим, что даст нам такой альтернативный вариант помимо плюсов:

1. У нас поменяются критерии найма. Добавление новых функций отразится и на необходимых навыках специалистов. Из-за их расширения мы сужаем возможный кадровый резерв на данную должность. Обучение текущих сотрудников под данный уровень так же влечёт за собой денежные расходы (время на обучение).

2. Размытие зон ответственности. В какой то момент мы можем получить ситуацию, когда граница между фиксом от сопровождения и фичей от разработки может быть не однозначна. Полномочия, как и ответственность, в такой ситуации будут сливаться. А мы в своей задаче как раз работали над тем, чтобы было понятно «кто что делает» и «что от кого зависит»

  1. На навыках ничего не отразится т.к. 2-я линия состоит из разработчиков. С такими же критериями найма и обучения. И вообще с нуля она формируется как разделение отдела разработки на 2 новых: чисто разработки и багфикса, аля 2-я линия

  2. Эта граница действительно не однозначна, но она 100% необходима в ситуации когда фичи фиксятся бесплатно, а доработки делаются за деньги. (Как у нас) тогда такая граница присутствует всегда и соответственно и ответственность.

Работал с обоими подходами: и когда 2-я линия могла сама фиксить баги, и когда 2-я линия не разработчики, поэтому категоричное утверждение, что "2-я линия состоит из разработчиков" это откуда? Зависит от конкретной организации.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий