(Часть 7 - Кто разрабатывает, тот и поддерживает)
Помимо всего вышесказанного отсутствие детальной документации вынуждает саму команду разработку заниматься её поддержкой, что в целом скорее хорошо.
Устаревающие подходы с жёстким разделением развития и поддержки* обычно приводили в обоснование "разгрузить развитие от решения инцидентов и запросов, чтобы сконцентрироваться на новых фичах". Но на практике обилие инцидентов является верным признаком хреново реализованного функционала, затыкание этой проблему бесконечным ростом численности поддержки - вовсе не решение, а подорожник.
*Здесь и далее речь про 2-ю линию с теническим уклоном. 1-ая линия, общаюящаясь с клиентом, конечно, никуда не денется.
"
If a human operator needs to touch your system during normal operations, you have a bug." - Carla Geisser, Google SRE.И сама процедура передачи на поддержку выглядит чаще как спихивание ответственности с одной стороны и желание прикрыть зад с другой. Этот цирк обычно сопровождается бесконечным запросом подробной документации, которую (читай выше) писать нерационально.
Когда команда сама поддерживает функционал, выработка более качественных решений неизбежна, иначе растущей технический долг и количество порождаемых им инцидентов однажды приведут к тому, что весь ресурс команды станет уходить на "выплату процентов”
Поэтому и в Яндексе, и в Сбере большинство команд поддерживают сами тот функционал, который разрабатывают. Соотношение ресурсов на решение инцидентов и разработку новых фичей определяется в диалоге продакта и Tech-Lead’а Сверху за этим приглядывают ребята из поддержки. Но их роль не в решении инцидентов, а в
✦ координации решения особенно крупных факапов
✦ разбор их причин и предотвращении их повторения
✦ развитии систем мониторинга
Баланс между развитие и поддержкой хорошо раскрывает концепция "error budget" из Google SRE. (Хотя, во всей книге речь скорее про отдельные развитие и поддержку.) Если коротко, то суть сводится к тому, что инцидент неизбежны, если продукт развивается. Отсутствие инцидентов = отсутствие изменений = проигрыш рынка конкуренту. Баланс между развитием (внесением возмущения в прод) и стабильностью сводится к бюджету даунтаймов. Например, 10 часов в квартал сервис может быть недоступен, и это нормально. Но, как только бюджет израсходован, новые фичи не выносятся в прод, а все ресурсы разработки до конца квартала переключаются на повышение стабильности. Размер бюджета отражает понимание бизнес владельцев систем об относительных приоритетах непрерывности сервиса и развития нового функционала.
Ещё одним преимуществом поддержки функционала самой командой является то, что инциденты попадают на глаза продакту. (По крайней мере, критичные.) Будучи погружённым в контент, он может понять реальный приоритет проблемы, чтобы бы ни было по этому поводу написано в тикете. Например, можно не чинить функционал, если мы уже запланировали его замену целиком. Или можно найти компромиссное решение, закрывающее конкретный проблемный кейс костыльно, но быстро. Такие "пируэты" невозможны, когда решением инцидентов занимается поддержка в силу несравнимо худшего понимания контекста.
Будьте в курсе инцидентов - помогает не терять связь с реальностью и не забывать о corner-кейсах, фантазируя невероятные новые фичи. 🙄
Кажется, я могу говорить про построение эффективных процессов в командах бесконечно. Но многое уже сказано до меня и лучше меня. Поэтому на этом закончим. Надеюсь, написанное выше было вам полезно. 😉
#product_teams #product_management #support