Мышление письмом по пятой главе.
Так или иначе вопрос о ролях преследует нас в ИТ постоянно. Специализация труда наступает, появляются новые профессии. Почти забыты уже fullstack программисты. В вакансиях пишут ищем devops-инженера, в чатиках на эту тему смеются “таких инженеров не бывает, это практика, а не роль”. Аналитики размножаются спорами, как грибы. Были бизнес-аналитики как прослойка (переводчик) между бизнесом и программистами. Появились к ним в комплект системные аналитики. Т.е. раньше думали, что программисты не могут с бизнесом на одном языке разговаривать. Нужен кто-то кто сможет у бизнеса на его “бизнесовом” потребности выяснить. А как сделать программисты сами придумают. Теперь системный аналитик должен потребности взять у бизнес аналитика и перевести их с естественного языка на технический. Но ещё и решения о том, как делать вроде как тоже принимает системный анализ. Разработчики только по инструкции/спецификации кодируют принятое другими людьми решение. Кто они после этого? Кодеры видимо.
Вот вся эта каша, кто что должен делать, а кто что умеет. И что от тебя хотят в конкретной фирме довольно сильно волнует людей, работающих в ИТ. И меня в частности.
Давайте разбираться.
Роль — функциональный объект, часть проекта (а не агента, как было бы интуитивно думать).
Все более-менее понимают, что должность и роль это не одно и то же. Должность, записанная в трудовой, может указывать на роль, а может и нет. У меня сейчас в трудовой должность - эксперт. И все: системный архитектор, бизнес архитектор, бизнес аналитик, системный аналитик, backend программист на одном ЯП, frontend программист, backend программист на другом ЯП, QA инженер, релизный менеджер и т.п. Всё это многообразие запаковано в должность эксперт. Единственное, что там ещё может быть приставка “старший” и “ведущий”. Младших пока не видела. Значит на должность не смотрим. Смотрим на то, что пишут в вакансии. Кого ищут? Руководителя разработки, или директора центра. Или может всё-таки кого-то из аналитиков или разработчиков.
Берём вариант попроще. Вот я линейный сотрудник, аналитик или программист. По идее менеджерских ролей у меня нет. Но мы уже запомнили: ищут человека, который встанет в роль в проекте. В конкретном проекте. От одной и той же роли в разных проектах могут требовать разный набор компетенций и выполняемых работ. Проблема в вакансий в том, что довольно часто хорошо описаны технологии, которые ожидают. А вот что предстоит делать описано похуже. Там могут быть общие фразы. А может быть как в статье про аналитиков: будь ты и архитектор, и аналитик, и проектотировщик баз данных, и спец по интеграциям и ещё кто-нибудь. С такими грандиозными обязанностями за неочень грандиозную оплату понятно, что делать. Что делать с общими фразами и похожими на правду описаниями?
Я разработчик. Технологии указанные знаю, их список прирастает каждый год. Но обычно останавливаешься на том, что есть курс “kafka для разработчиков”, а есть “kafka для devops”. И понятно, что мне не нужно знать как разворачивать кластер и строить платформу на основе технологии. Мне нужно, как я этой технологией пользуюсь, решая свои технические задачи. А дальше начинаются интересные истории с вынужденной постановкой в соседние роли.
Вот бизнес-аналитик описал фичу. Если в этот момент свободного системного аналитика не было, то ещё и попытался накидать схему, как оно должно технически работать. Какие данные откуда взять, что в них поменять, чтобы было то, что они хотят. Принесли это в разработку. Разработчик “верит” аналитику. Реализовали решение, не работает. Оказывается нельзя просто взять и соединить данные, когда они в разных базах лежат. Бизнес аналитик зря залез в чужую роль? Разработчик зря не залез в чужую роль, не пошёл проверять системный анализ?
Другая история. Нашёлся системный аналик, сделал свою часть работы после бизнес анализа. Опять принесли, разработчики сделали. Точнее переделали три раза, потому что аналитики разбирались и меняли описание задачи. Сделали финальную версию, не работает. Системный аналитик не умеет в свою роль? Разработчику надо за обеими ролями аналитиков проверять? При этом например, то что я негласно становлюсь в роль QA, когда не только тесты пишу на свой код, но и на стенде его проверяю сначала сама, сопротивления не вызывает. Или когда devops инженер наш CI поправил, но сломал, я спокойно исправляю. Потому что считаю, что у инженеров по инфре широкие знания, но в некоторых местах неглубокие.
Из всего этого вытекает вопрос: какие роли мои и насколько сильно мне нужно разбираться в соседских? И главное в каких учебниках написано, как отличить хорошего архитектора/любую-другую-роль от плохого? Про архитектора книжка найдена. Остальных ждём в районе второго-третьего семестра.
Сейчас ещё адаптируюсь к новому ярлыку. Нас пересобрали по командам. Команда из продуктой стала технической. И при этом в ней backend программистов из моего стэка два человека, включая меня. Но внутри технической команды нас побили на подкоманды размеров до 5 человек. И вот мы вдвоём образуем одну из них. Но формально в таких командах должен быть лид(ер). Назначать лида в паре разработчиков примерно одинакового уровня мне кажется достаточно абсурдной операцией. Но архитектор сказал “номинально надо кому-то из вас поставить букву Л”. И мы недолго думая, решили вопрос старым вариантом генератора случайных чисел - монеткой. Л досталась мне.
А теперь по традиции плохих описаний, реальность отличается от “номинальности”. И в новой роли я помимо буквы получаю: роль скрам-мастера в усеченном варианте (ведущего дейликов), роль аналитика (задачу опиши, список работ нарежь), роль плохого менеджера(ходящего по бесполезным созвонам) и пока неизвестно какие ещё.
Это была первая неделя “нового формата” работы. И в первые дня три это выглядело как стресс-тест для собранности. Старый порядок исчез. А новый никто не подготовил. Т.е. просто всё развалилось, кто что должен делать никто не понимает. WIP - работы ведутся, ожидайте.
Очнулась я в раздражении от новых обязанностей, о которых мы не договаривались, дня через два. И села думать письменно, а что происходит. Сразу стало получше. Роль справочного бюро, отброшена, как ненужная. Бесполезные созвоны на ближашую неделю отбиты. С ролью ведущего дейликов смиряюсь. Всё-таки они два раза в неделю, против 4 в прошлом формате. И вдвоём есть шансы уложиться в 10 минут.
Есть непонятный момент. С одной стороны, можно сходить к архитектору (он глава нашей большой технической команды) и уточнить ожидания по поводу моей новой роли. С другой стороны, у нас вполне может быть конфликт интересов. У него же есть право делегировать (всё что он посчитает нужным), а у меня нет ни малейшего желания нахапать себе ещё неинтересных мне ролей. Ведь роль разработчика (который половина команды в нашем случае) с меня никто не снимал. Да я и не хочу её снимать. Отсюда вывод, стоило бы сначала прояснить свои интересы в данной ситуации. А потом предположить его интересы и подумать как это можно уторговывать. И только тогда идти разговаривать.
