Сегодня вышел анонс стрима Игоря Апресова с Романом Даниловым. Если вкратце, обещают разобраться, без кого жить проще: без разработчика (Игоря) или без аналитика (Романа). Кстати, это уже второй стрим. Вчера был первый. Думаю, точно найдутся люди, которым будут полезны и первый, и второй. Мб даже последующие.

И тут мне вспомнилось, что несколько месяцев назад я уже походя делал заметки на эту тему и решил быстренько их переформатировать в один пост.

Итак, запомнили - это сырой и спонтанный материал, собранный на коленке из записок сумасшедшего, так что сильно не доёбывайтесь.

🔘Для упрощения говорим не о ролях, а о "сторонах"
👉сторона аналитика подразумевает роли бизнес и системного аналитика
👉сторона разработки подразумевает роли разработчика и архитектора

🔘Какие границы мы исследуем?
👉ответственность за требования
👉ответственность за решение

🔘Что влияет на ответственность?
👉вовлеченность в проект
👉масштабность разработки
👉достаточная квалификация
👉суть задачи

🔘Деформация стеком: парадигма разработки в 1С долгое время была такова, что не было аналитиков, да и сейчас подобная позиция вендора - аналитики не обязательны - сохраняется. Поэтому большая часть нынешних разработчиков S, S+ умеют работать с заказчиком, но мало кто умеет формализовать требования на уровне аналитиков. Сюда я включаю и корректную документацию, и трассировку требований, и вообще все, что придет Вам в голову. Лично я отношусь к аналитикам как, в первую очередь, коллегам, которые снимают с меня часть нагрузки. Это всегда приятно. А учитывая, что я в целом не очень люблю людей в сыром виде, то это еще и сохраняет моё душевное равновесие.

🔘Повышение грейда разработчика должно быть так или иначе связано с погружением в бизнес-процессы, особенно если речь про масштабирование системы (при масштабировании идет речь об внесении изменения в реализацию процесса, что потенциально сложнее реализации процесса с нуля). Более того, ведущие разработчики (S, S+, ТА) должны привлекаться на всех этапах составления требований, особенно БТ(собственно, анализ бизнес-процессов) и ФТ (описание поведения ПО), аналитики же в свою очередь должны иметь чёткое представление об осуществляемых архитектурных решениях (структура данных, вариант реализации интеграций), чтобы таковые не оставались "черными ящиками в голове разработчика" (с) Роман.

🔘Давайте рассмотрим некоторые типичные ситуации

👉Аналитик в контексте + недорогая фича = 100% нормально, если аналитик ставит конкретное решение
Пример: "добавить реквизит в справочник" - позволяет проще манипулировать занятостью разработчиков (как правило J, M-), быстрее накапливать знания.
Поправка на лету от Романа (да, мы с ними немного уже успели обсудить): в любом случае, хотелось бы иметь ревью решения от разработчика.

👉Аналитик в контексте + дорогая, но относительно простая фича = аналитик 100% должен ставить задачу, используя объекты метаданных
Пример: "сделать отчет, вывести данные, данные хранятся в таких-то таблицах в таких-то полях" - позволяет быстрее включаться в задачу разработчику, эффективно использовать время более дорогих разработчиков (от M), оптимально в командах матричной структуры с несколькими проектами и гибким управлением занятостью.

👉Дорогая, сложная разработка = 100% решение не должно формулироваться аналитиком в одну каску, насколько бы он не был в контексте, необходим разработчик (минимум M+, желательно S, ТА) для принятия экспертного решения.

Краткий итог: сила во взаимодействии. В какой-то момент вместо "отделов" появились "команды", и это хорошо. Отдел - это просто кого-то отделили по формальному признаку. Команда - это люди, работающие над общей целью. Но - индивидуальности. И при сохранении общих принципов, в каждой паре взаимодействия "аналитик-разработчик" возможны нюансы, основанные на личных предпочтениях. Поэтому залог успеха - понимание ролей и возможностей друг друга, плюсов, которые даёт наличие аналитиков разработчикам (я все таки смотрю со своей позиции). А подробнее, надеюсь, погрузятся ребята на стриме и мне не придется дописывать этот текст.

#медведьразмышляет