Повтор текста
Давайте уже потратим время, чтобы раз и навсегда ответить на этот вопрос. Потом ссылку на пост (и следующий тоже) будете кидать каждому, кто скажет
«Я работаю сам без аналитика, отлично справляюсь и не понимаю, зачем он нужен»
Это очень распространенный тейк в среде разработчиков на 1С. Про остальных не знаю, общаюсь с людьми достаточного уровня и опыта, чтобы они не сомневались в полезности аналитика. Собственно, в вынесенном в цитату мнении и заложено непонимание сразу двух вещей: что разработчику даёт наличие аналитика и когда он появляется в команде.
Этот пост, как Вы догадались, про «зачем».
Что аналитик может делать за разработчика (не претендую на полноту, да и для части этих функций в идеальном мире есть другие люди, не аналитик и не разработчик, но мало кто живет в идеальном мире, хотя бы и в рамках работы)
1️⃣Сбор и структурирование внутренних требований
👉Общение с заказчиком
👉Формализация требований
👉Структурирование процессов
👉Проверка требований на соответствие текущим процессам
2️⃣Ведение документации
👉Описание пользовательских сценариев
👉Описание собственных API
👉Моделирование процессов в понятных заказчику нотациях
👉Описание архитектуры решения
👉Логирование изменений
3️⃣Проектирование
👉Интерфейсов
👉Логики
👉Данных
4️⃣Работа с внешними требованиями
👉Разбор сторонних API
👉Отслеживание изменений в законодательстве
5️⃣Подготовка решения к реализации
👉Отслеживание зависимостей с другими решениями (как в рамках одного продукта, так и в мультивселенной безумия – других связанных сервисов организации, в зависимости от их изолированности).
👉Отслеживание других реализаций на предмет использования в текущей задаче (кто-то уже делал похожее раньше, это логично использовать и сейчас)
👉Проектирование способа конкретной реализации
6️⃣Работа с инцидентами
👉Консультирование пользователей
👉Выявление проблем с помощью анализа данных
7️⃣Тестирование
👉Написание сценариев
👉Проверка функциональности
8️⃣Сопровождение разработки
👉Презентация функциональности
👉Отслеживание метрик оценки продукта
9️⃣Развитие
👉Отслеживание доступных улучшающих сценариев для интеграций. К примеру, вы получали данные из другой системы, в какой-то момент в организации появилась мастер-система и теперь данные правильно брать из неё.
👉Отслеживание рынка сторонних решений для внедрения (у вас есть какая-то функциональность в бэклоге, а тут на рынке появляется доступное решение для её реализации)
Сейчас будет бессмысленный и беспощадный байт
❓Аналитики, а что из этого делаете Вы у себя в команде?
❓Разработчики, а Вы прям во все это умеете? Все это делаете? Еще и с горящими глазами? Или чаще вам похуй на большую часть из этого и просто «тётя из бухгалтерии хочет колоночку в отчет»? К последнему мы вернемся еще и в следующем посте.
Основные цели появления аналитика в команде, команды аналитиков в организации.
👉Повышение эффективности за счет разделения труда. Сокращение времени реализации фичи. Все сконцентрированы на применении своих профильных навыков.
👉Оптимизация ФОТ. Фонд оплаты труда, если кто не в курсе. Я не очень прям слежу за рынком аналитиков, но на начальных грейдах вроде аналитик в среднем стоит дешевле разработчика. На сеньорном уровне разрыв сокращается или вообще нивелируется, как свидетельство того, что классный, зрелый аналитик привносит в процесс разработки не меньше программиста (не люблю использовать это слово, но тут чисто ради отсутствия тавтологии).
👉Снижение рисков. Всесторонний анализ позволяет на ранних этапах выявить «минусовые» решения как в плане бизнеса, так и в плане разработки.
👉Повышение качества сопроводительной документации. Как ни крути, в общем случае разработчики не очень любят нормально всё документировать, а для компаний, которые идут в сторону нормального проектного управления – это необходимый шаг.
Могу ли лично я обойтись без аналитика? Вполне. Но, поработав в командах с аналитиками, я очень не хочу возвращаться в мир без них.
#медведьразмышляет #рольаналитика