Зачем фиксировать зоны ответственности разработки
Мы обсудили, как фиксировать зоны ответственности. А теперь обсудим несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
Пользователь
В дата‑центре «Яндекса» в Сасово «произошёл инцидент», затронувший часть инфраструктуры, сообщили СМИ в компании. Сейчас ситуация на площадке находится под контролем, пострадавших нет. Команда устраняет последствия происшествия и восстанавливает работу затронутых сервисов, добавили в «Яндекса». Также в «Яндексе» официально обратились к пользователям и партнёрам по поводу инцидентов с дата‑центрами компании.
