Всем привет! Меня зовут Александра Камзеева, я руководитель направления системного анализа в IT PMO в Lamoda. За полтора года мы выросли с 3 до 22 человек.
Такой стремительный рост и подтолкнул нас на вопрос: «Кто такой системный аналитик и какую роль он выполняет именно в Lamoda?» Мы поняли, что четкий ответ позволил бы нам эффективнее расширять команду, проводить собеседования и онбординг. Благодаря объяснению, кто мы такие, наши коллеги из разработки, QA, бизнеса лучше понимают, с какими вопросами и задачами стоит или не стоит к нам приходить.
Функции аналитиков могут отличаться от компании к компании. Сегодня я хотела бы поделиться опытом работы системных аналитиков в Lamoda. Из статьи вы узнаете, как системные аналитики помогают делать кросс-функциональные проекты, о разграничении ответственности между техлидом и системными аналитиками, о ценности для команды разработки и кто может в целом прийти на эту роль.
О бизнес-направлениях в Lamoda
Чтобы объяснить роль системного аналитика в Lamoda, сначала расскажу немного о компании. В нее входит 8 крупных бизнес-направлений, которые тесно связаны друг с другом:
склад,
доставка,
фотостудия,
контакт-центр,
сайт и приложение,
b2b-направление,
маркетинг,
финансы.
Кажется, что, например, отображение фотографий и описаний товаров на сайте — простой процесс. Но даже в нем задействовано 7 сервисов:
сайт или мобильное приложение отображает фотографии и описание товаров из Catalogue;
в Catalogue эта информация приходит из Content (система, которая автоматизирует процессы фотостудии) через RnD и Event-bus;
Content взаимодействует с системой склада WMS (Warehouse Management System), чтобы заказать нужные товары со склада в фотостудию. Еще сюда приходит информация о новых товарах из ERP-системы или B2B/ Marketplace-систем в зависимости от типа контракта товара;
также Content взаимодействует с ERP-системой в рамках товародвижения.
Схема ниже упрощенно показывает, как устроено взаимодействие бизнеса и IT в Lamoda. Бизнес-направления владеют системами, которые автоматизируют их процессы, а поддерживают и развивают их определенные команды разработки:
Если нужно локально внести изменения в систему, то с этим обычно нет трудностей: бизнес и команды разработки научились взаимодействовать и понимать, что и как нужно разработать, чтобы бизнес-процесс работал.
Сложности возникают, когда нужно сделать кросс-функциональный проект, который требует доработок в разных бизнес-направлениях, системах, за которые отвечают разные команды разработки.
Такие проекты требуют понимания «вида сверху» на все бизнес- и системные процессы. Конечно, есть эксперты, которые видят картину чуть шире, но все равно нужно обладать навыками и временем, чтобы разобраться во всех деталях кросс-функционального проекта для снижения цены ошибки при запуске. И здесь приходят на помощь системные аналитики.
Как мы делаем кросс-функциональные проекты
Рассмотрим, что такое кросс-функциональный проект, на примере возврата товаров партнеров через пункты выдачи заказов Lamoda (далее — ПВЗ). Раньше клиенты могли вернуть партнерские товары только через «Почту России», что не очень удобно для городов, где возможностей больше.
Как это выглядит с точки зрения клиента:
клиент приносит товар в ПВЗ и заявление на возврат;
менеджер ПВЗ фиксирует приемку товара в системе ПВЗ, которая оповещает систему процессинга заказа и ERP-систему об этом факте;
система процессинга заказов передает информацию через B2B-платформу в систему партнера и в систему возврата денежных средств;
товары передают партнеру через склад, фиксируя эту информацию в системе склада;
группа возврата денежных средств возвращает клиенту деньги через соответствующую систему.
Схематично процесс возврата партнерского товара через ПВЗ Lamoda можно показать так:
А в переводе на системные процессы он выглядит так:
Рассмотрим, чем занимается системный аналитик на каждом этапе проекта.
Этап идеи
На этапе идеи бизнес хочет понимать, стоит ли сейчас тратить свои силы на ее реализацию или нет. Для этого системный аналитик консультирует и помогает определить верхнеуровневый список задействованных бизнес-процессов в рамках всех бизнес-направлений, связанные проекты и риски.
Мы разделили проект из примера на такие процессы:
возврат товара через ПВЗ,
сортировка и отправка на склад,
возврат денег клиенту,
уведомление партнера.
Дальше помогаем определить список рисков. Конечно, он получится неполным, но мы подсвечиваем бизнесу информацию, которой владеем. В нашем примере мы получили следующее:
в системе доставки нужен рефакторинг процесса возвратов;
увеличится количество коробов отказов в зоне доставки, что критично, так как место ограничено.
После этого разрабатываем план действий, чтобы проект был взят в разработку.
Этап бизнес-анализа
Здесь аналитик максимально вовлечен в проект, потому что бизнес редко может написать идеальные для системного анализа требования. Мы помогаем ответить на вопросы и сформировать BRD (бизнес-требования). В нашем шаблоне BRD ключевыми разделами являются:
цель проекта;
границы проекта;
процессы AS IS («как есть»);
процессы TO BE («как будет»);
связанные проекты;
требования к отчетам;
требования к запуску.
Из перечисленных разделов я бы хотела обратить внимание на два последних.
Требования к отчетам — важный пункт, на который не всегда обращают внимание. У нас были случаи, когда о требованиях к отчетам не думали, а потом приходилось откатывать релиз и переделывать модели данных обменов между системами, таблицы в базе данных из-за того, что не предусмотрели необходимые поля для подсчета конверсии проекта. Из-за этого запуски проектов откладывались до 3 месяцев.
Аналогично с требованиями к запуску. Происходили ситуации, когда слишком поздно задумывались о том, как запускать проект не на 100%. Приходилось выкатывать релиз спустя 2 месяца после окончания всей разработки и тестирования по проекту.
Поэтому теперь эти два пункта включены в каждый BRD для обязательного заполнения.
Этап системного анализа
Его результат — спецификация, состоящая из следующих разделов:
описание архитектуры;
функциональные требования — требования к логике работы сервиса, обменам, UI;
нефункциональные требования;
требования к тестированию.
Требования к тестированию — необязательный пункт. Мы его заполняем, когда системный аналитик понимает, что нужно проверить еще какую-то связанную функциональность, которую изменения могли косвенно затронуть.
Также хочу обратить внимание, что архитектура и функциональные требования продумываются совместно с техлидом, так как ответственность за проработку архитектурного решения несет он. Но об этом я расскажу дальше.
Этап разработки и тестирования
На этапе разработки и тестирования аналитик активно консультирует разработчиков и QA. Несмотря на то, что за проработку тест-кейсов у нас в компании отвечает тест-лид, аналитик все равно подключается для их валидации. Ему необходимо убедиться, что процессы, о которых договаривались с бизнесом, будут проверены в рамках интеграционного тестирования. Иначе невыявленные ошибки могут быть неприятным сюрпризом в продакшене.
Еще системный аналитик принимает участие в пользовательском тестировании в продакшене вместе с бизнес-операциями. Совместно с продактом он составляет план проверок каждого прописанного сценария в BRD для каждого бизнес-процесса в реальных боевых условиях. В этот план мы включаем всех ответственных за те или иные бизнес-процессы. По сути, это и есть приемка нашего проекта реальными пользователями. Мы можем поехать на склад, ПВЗ, фотостудию, чтобы убедиться в том, что все работает, как мы ожидаем. Результатом такого тестирования является решение раскатывать проект на большее количество пользователей.
Этап стабилизации
После запуска проекта могут возникать разные инциденты, часть из которых попадают к системным аналитикам. Например, когда нужно проверить ошибки в бизнес-процессах, чтобы определить, есть ли ошибка вообще, или просто необходимо объяснить, почему это работает именно так, а не иначе. Результатом нашего участия на этом этапе могут быть:
согласованный план бизнеса и IT;
понимание, что проблемы нет;
задача на разработку;
все вместе.
Вернемся к примеру проекта с партнерскими возвратами через ПВЗ Lamoda. Когда мы его запустили, финальный статус возвратных товаров изменился, что привело к их непопаданию в определенные отчеты для бухгалтерии и группы, отвечающей за возврат денежных средств. Поэтому бухгалтерия и группа возвратов не могли корректно сверять данные по денежным операциям. Они обратились в поддержку с просьбой убрать этот статус, так как посчитали это ошибкой. Системный аналитик, подключившись к задаче, помог разобраться и остановить изменение статусов товаров. А для решения проблемы бухгалтерия и группа возвратов поставили задачи на изменение отчетов.
Если бы к проблеме не подключился системный аналитик, то ситуация развивалась по двум сценариям: либо к результату пришли позже, либо задачу взяли бы в работу и просто убрали статус. Это привело бы к серьезным последствиям, потому что наши системы перестали бы извещать партнера о возврате товара на его склад. Все бы сломалось и пришлось заново разбираться в причинах.
Как разделена ответственность между техлидом и системным аналитиком
А что же тогда делает техлид? Рассмотрим подробно, как поделена ответственность между системными аналитиками и техлидом на всех этапах работы над проектом.
На этапе идеи. Техлид не участвует, потому что здесь его роли еще нет. Если на этом этапе нужна экспертиза с точки зрения разработки, то с этим помогают эксперты систем.
На этапе бизнес-анализа. Системный аналитик погружается в проект, помогает писать BRD, описывает процессы AS IS, TO BE и бизнес-требования. Здесь он вовлечен максимально. Если нужна консультация по какой-то системе, то все вопросы задаются соответствующему эксперту.
Техлид подключается на финальном этапе бизнес-анализа: он только начинает погружаться в проект и пока активно не консультирует.
На этапе системного и технического анализа. Здесь результатом этапа является спецификация. Системный аналитик в команде с техлидом прорабатывает различные варианты решений для поставленной задачи, описывает архитектуру изменений в системах для верхнеуровневой оценки разработки проекта в разных системах.
Однако именно техлид несет ответственность за выбор технологий и составление архитектурной схемы. Системный аналитик может вовлекаться и предлагать логическую модель данных, бизнес-модель, писать требования. Но именно за техлидом остается последнее слово в принятии решения, которое он согласовывает с архитектурным комитетом.
На этапе декомпозиции и оценки. Системный аналитик актуализирует спецификацию и консультирует команду разработки и техлида. Техлид декомпозирует задачи в Jira.
На этапе разработки и тестирования. Аналитик продолжает актуализировать спецификацию, консультировать команду разработки и QA, валидирует тест-кейсы, составляет и согласовывает план UAT (пользовательское тестирование). Техлид тоже консультирует команду разработки и QA, но в более технических деталях. Зачастую он сам пишет код, и он же ревьюит готовые задачи.
На этапе релиза. Системный аналитик продолжает консультировать команду разработки и бизнеса. Техлид составляет план релиза и откатов.
На этапе стабилизации. Аналитик исследует бизнес-инциденты. Техлид разбирает абсолютно все входящие инциденты, помогает их решать или распределяет по командам разработки.
Если посмотреть на активность техлида и системного аналитика по этапам, то она будет примерно такой:
Аналитик больше занят на этапе бизнес-анализа, затем ответственность плавно перетекает к техлиду. На следующих этапах уже нужна огромная вовлеченность техлида, а системный аналитик почти не вовлекается. Мы закладываем 15% общего времени аналитика на эти этапы и называем это саппортом.
Самое важное отличие этих двух ролей — в направленности их работы:
Системный аналитик |
Техлид |
отвечает за проект в контексте бизнес-процессов |
отвечает за проект в контексте системных процессов |
предлагает архитектурные решения и спецификации обменов |
отвечает за архитектуру и спецификацию обменов |
Это не означает, что им не нужно разбираться в процессах друг друга — просто они фокусируются на разном. Тандем системного аналитика и техлида очень эффективен. Такой подход позволяет посмотреть на проект под разными углами и уменьшить риск критичных ошибок благодаря двойной проверке.
Зачем нужен системный аналитик и за что его ценят в Lamoda
Экспертиза во всех бизнес-процессах и системных процессах от верхнего до детального уровня. В кросс-функциональных проектах системный аналитик видит всю картину сверху, но в том числе может опуститься до всех деталей. Это не значит, что он гуру и знает ответы на все вопросы. Скорее, он может быстро найти нужные контакты и источники данных, убедиться в их актуальности и правильности и передать эту информацию команде.
Возможность понять любой «черный ящик». То есть целые системы или часть их функционала, которые работают непонятно. Системный аналитик помогает разобраться с неизвестностью разными методами, структурировать полученную информацию. Это нужно, чтобы снова появилась экспертиза и стало понятно, что можно менять и какие последствия повлечет изменение той или иной функциональности.
Инициативная позиция и готовность разобраться в любой проблеме. К системному аналитику часто приходят с «просто проблемой»: непонятно, с кем связаться и где искать. Он помогает разобраться, найти контакты, посмотреть логи. Такого саппорта много у нас в команде и он ценится теми коллегами, которые его используют. Причем, речь идет не только о командах разработки, но и бизнеса.
Роль фасилитатора. Когда проекты пересекаются и очередность в работе непонятна, аналитики организовывают фасилитационные встречи. Мы собираем всех заинтересованных, говорим с ними о проблемах, фиксируем ключевые моменты в обсуждении. Результат — все довольны и понимают план действий каждый в своем проекте.
В заключении я хотела бы сказать, что в системный анализ могут приходить из смежных направлений: разработки, QA, продукта, технического писательства, а также других направлений анализа. Главное, чтобы человеку нравилось половину своего времени коммуницировать с коллегами, а другую половину — письменно структурировать информацию, одинаково интересно заниматься бизнес-анализом и системным анализом. Ну и, конечно, системный аналитик в Lamoda должен быть готов взламывать «черный ящик» каждый день.
Комментарии (16)
Exarv
29.09.2021 23:29Интересно и познавательно..
Но на протяжении чтения статьи не покидало ощущение, что вы: назвали бизнес-аналитика системным, а системного - техлидом ????
skgirl Автор
29.09.2021 23:44Похожий комментарий выше, на который я ответила. Могу только добавить, что это холиварная тема и сколько будет компаний, людей, столько будет и мнений.
meirinkun
30.09.2021 17:39Заголовок кажется кликбейтным. Статью кидают в разные чаты TG и ожидал увидеть какими методами аналитики вскрывают и описывают черный ящик, а в итоге про это пара предложение.
Тема о том кто такой бизнес-аналитик, а кто такой системный уже вроде как не холивар т.к. есть профстандарты на обоих.
Самое интересное, что решения вы разрабатываете вроде как по "водопаду" - этапы один за другим и в релиз. А почему такая же методика не применяется при принятии решения о найме 18 (!) аналитиков. т.е. вы пишите, что сначала их наняли, а потом начали думать - кто они и зачем мы их наняли. Плюс, ни разработка, ни QA не знали об этом т.е. потребности в аналитиках вроде как и не было. Ведь правильней сначала выявить требования, а потом закрыть их. Разве нет?
Подобную ситуацию, когда идет беспощадный найм аналитиков встречаю уже не первый раз и не могу понять в чем причина. Это, видимо, какой-то странный ответ на бурный рост компании и попытка освоить бюджет на ИТ, а после уже оправдать эти траты. Часто вижу непонимание разрабов, зачем им работать с аналитиком.
Еще про черный ящик - вся бизнес-логика ПО как правило, описана в коде. О том, что написано в коде, можно только догадываться смотря в БД или играясь с API. Я хочу сказать, что системный аналитик, как сотрудник, который должен разбираться в работе системы должен уметь читать код и знать технологический стек и, как мне кажется, не все, указанные для возможного перехода в аналитики, смежные специалисты обладают такими навыками.
Я уже чуть более 5 лет и бизнес-, и системный аналитик. Видимо, наступила какая-то стадия рефлексии о профессии и своем месте в ней:) И последнее время прихожу к выводу, что СА/БА это лишнее звено в профессиональном коллективе и затычка для дыр в коммуникациях и знаниях в непрофессиональном - где заказчики не могут внятно и грамотно изъясняться и составлять требования, а разрабам стало можно не погружаться в предметную область и проблемы бизнеса.
skgirl Автор
30.09.2021 21:59Если тема интересна, то мы ей поделимся.
Профстандарты, безусловно, есть (в обсуждении одного из них я даже принимала участие). Но в этих профстандартах есть довольно много пересечений. И все равно каждая компания, каждый бизнес-домен что-то определенное вкладывает в названия этих должностей. И это превращается в холивар. И я убеждена в том, что системный анализ без понимания бизнес-процессов будет неполным. Всегда надо понимать, что автоматизирует система и зачем.
Нет, разработка чаще всего не идет по "водопаду" эти этапы идут часто параллельно итерациями. e-comm в водопадном режиме не выживет. Тут скорее хотелось показать, что на разных этапах проекта системный аналитик решает разные задачи. Насчет того, почему не выясняли требования к системным аналитикам от команды. Во-первых, системные аналитики в компании существуют с 2013 года, просто их количество было небольшим. И понимание, кто такой системный аналитик у нас было всегда. Но это понимание было устным, не в описании роли (конечно, должностные обязанности есть, но они недоступны команде). Описание роли хотелось описать "на бумаге" и озвучить всем командам. И да, была проблема, что команды не всегда понимали, по каким вопросам к нам можно идти, а по каким - не стоит. И не потому что, системные аналитики в чем-то не разбирались. А как раз-таки наоборот, системные аналитики решали слишком много вопросов, которые должны были быть в другой зоне ответственности. Когда мы начали активно нанимать, роль прекрасно уже была определена, о чем рассказывалось на собеседованиях кандидатам. Но именно четкое описание в Confluence помогло делать найм эффективнее (одна из причин эффективного найма), т.к. "портрет" аналитика был всегда перед глазами.
Наши команды прекрасно понимают, зачем им нужны выделенные системные аналитики и как делится между нами ответственность. И мне кажется, отчасти вы ответили об этом в последнем абзаце. Я соглашусь, что СА/БА может быть лишним звеном и сама об этом люблю рассуждать с другими коллегами - системными и бизнес-аналитиками. И есть много критериев, когда нужен выделенный системный или бизнес-аналитик, а когда он бесполезен. Если в компании бурный рост, то процессы работать идеально не могут. Это нормально. И для такого роста системные аналитики полезны, т.к. могут навести порядок и структурировать информацию в компании. А еще очень сильно зависит от объема существующих бизнес-процессов. Когда их слишком много, то нужны выделенные роли для того, чтобы разбираться в них и в нужных изменениях.
Навыкам можно обучить - это мое убеждение. Со временем необходимые навыки меняются. Сложнее обучить логически рассуждать, быть любопытным и грамотным, не бояться неизвестности. А знать технологический стек, читать код, рисовать схемы в любых нотациях, работать с API или СУБД - это просто некоторое время, которое нужно потратить на обучение и опыт. А вот то, что в коде описана вся бизнес-логика, да и еще так, чтобы ее понять, это неправда. По крайней мере, далеко не во всех системах это так. А главное, что в коде редко пишут, зачем это нужно. На что это может повлиять. И если бизнес-процессы уже довольно обширные, то эту бизнес-логику в коде никогда не проследить.
Я убеждена за свои чуть больше 10 лет работы в системном анализе в разных компаниях, что довольно много есть случаев в профессиональном сообществе, когда системные аналитики нужны. И чем дальше, тем больше в этом будет проявляться необходимость, т.к. все больше процессов автоматизируется.
meirinkun
01.10.2021 07:50Про тему черного ящика было бы очень интересно прочитать - это не самая освещаемая тема, но по моему опыту довольно актуальная. Это, кстати, одна из причин появления аналитика в компании - разобрать и задокументировать работу продукта, который дорос до некоторой точки, когда команда, которая его разрабатывала начинает меняться и не знает как она работает и, главное, почему она работает именно так:)
Про профстандарт системного аналитика - в нем СА как раз вменяется работа с бизнес-процессами. Он там вообще довольно универсальным профессионалом получается.
А вот нужность аналитиков - это холиварная тема:) Мое непопулярное мнение и ваш двукратный опыт не оставляют мне шансов, поэтому оставлю его пока при себе:)
skgirl Автор
01.10.2021 18:38Да, полностью согласна. Аналитики часто появляются в этот момент. Мне кажется, в этом и есть признак взросления компании. Хотя есть компании, в которых нет аналитика. Но по отзывам знаю, что они бы там не помешали.
Мне этим и нравится наша профессия, что нужен универсал. Это разнообразно и заставляет погружаться в разные бизнес-домены. Приходится всегда думать.
Ваше мнение часто обсуждается на различных площадках, так что смело давайте рассуждать на эту тему вместе :-) Это же здорово иметь четкие критерии, когда мы полезны, а когда - нет. Это повышает эффективность и мотивацию аналитиков.
IgorNE
04.10.2021 21:54Соглашусь с предыдущим комментатором. Все это похоже на водопад. Или серию мини водопадов без user story и вот этого всего)
skgirl Автор
04.10.2021 21:56А как тметодология ведения проектов (хотя идеально методологии редко где бывают) зависит от техники анализа UsetStories?
IgorNE
05.10.2021 15:09Ну нельзя сказать, что совсем не зависит. Как там в Agile манифесте "Работающий продукт важнее исчерпывающей документации". Я так то не спорю. В статье описана, вполне, классическая роль системного аналитика. Приблизительно тем же занимаюсь, только в банковской сфере.
Cart00n
А где системный анализ собственно?))То что описано это бизнес-анализ с элементами понимания архитектуры :)
skgirl Автор
Во-первых, это в целом популярная проблема наименования людей системными и бизнес-аналитиками. И тут вопрос, кто и как называется.
Во-вторых, не спорю, что в описании больше упора на бизнес-анализ, т.к. сделать тот или иной системный анализ у нас в ИТ-команде могут многие. А вот сопоставить системные процессы с бизнес-процессами почти никто не может и на моем опыте собеседований, делать такое упражнение могут далеко не все. По факту, чтобы разобраться в наших системных процессах требуется не просто анализ с элементом понимания архитектуры, а глубокое погружение в нее (модели данных, типы обменов, структура БД, причины выбора того или иного архитектурного решения). Просто мало разбираться только в системных процессах, нужно еще и понимать, а зачем мы это делаем.
Tekill
В самом начале статьи правильно подмечено, что от компании к компании есть отличия как в распределении функций системного\бизнес анализа, так и названия конкретных должностей. С учетом диаграммы активности по этапам, расположением отдела в проектном офисе и описания рабочего процесса должности системный аналитик, то действительно этой должности в Lamoda в большей мере присущи функции бизнес анализа, чем системного. Тут я солидарен с мнением.
Это также заметно по контексту, в котором озвучена работа аналитиков: когда это проект с его стандартным жизненным циклом инициация-анализ-разработка-запуск, то аналитик фокусируется на целях проекта и его бизнес заказчиках (т.е. бизнес анализе), а за кадром участия в проекте остаются прочие аспекты уже системного анализа. Аспекты вовлечения в не проектные задачи, реального устройства "черного ящика" и деталей его работы, документирование "черного ящика", привлечение в L3 уровень поддержки, тесное взаимодействие с продактом в случае продуктовых команд. В эти аспекты просто невозможно погружаться в проектном подходе, вот и получается что это закрывает команда и техлид, кто на самом деле и будут выполнять большинство функций системного анализа.
Статья полезная, раскрывает чем придется заниматься и что делать в компании.
skgirl Автор
Да, статья построена на примере проектной деятельности. Но у нас сейчас аналитики отвечают привлекаются не только в проектную деятельность, но и во все перечисленные тобою активности, в рамках того или иного направления. И к выяснению устройства "черного ящика", саппорт в части бизнес-процессов (то есть мы не привлекаемся к саппорту, который как-то относится к кодингу или инфраструктуре), тесному взаимодействию с продактом и другими ролями команды привлекается системный аналитик. В текущих реалиях отделять системного аналитика от команды некорректно. Мы и есть команда. Нет такого разделения ни в одной команде и направлении.
Tekill
В статье как раз описано отделение аналитика от команды. Да, его могут привлекать к задачам и к решению проблем команды, но он никогда не будет являться частью команды, так как тут разные линейные руководители. Команда на то и команда, что она объединена в одной иерархии под одним линейным руководителем, который имеет прямой доступ и контроль над своей командой.
Либо команда сама несет определенную функцию, либо привлекает ее на стороне, в том числе и других командах, в вашем случае в команде аналитики. В то, что разделения нигде нет не поверю, обычно в компаниях, начиная со средней, в дирекции\направлении\департаменте ERP есть отдельные люди с функциями системного анализа, часто называются консультантами.
skgirl Автор
Я не согласна, что определение к тому или иному линейному руководителю означает, является ли человек членом команды или нет. В первую очередь команда - это сотрудники, которые работают над одними задачами и объединены единой целью. Вокруг этого строятся процессы. И в команде есть сотрудники из разных "департаментов" и это правильно: продакты, PM-ы, QA, разработчики, системные аналитики, бизнес PM. Но говорить о том, что люди, которые работают бок-о-бок над одними задачами, которые поддерживают друг друга, проверяют друг друга и таким образом решают задачи эффективно, не команда - это обидно и не соответствует истине. Если так к этому относиться, то действительно не будет ни командного духа, ни команды и задачи будут решать отдельными людьми, без которых все ломается. Мы через это прошли и возвращаться обратно к такому подходу не хочется.
А линейный руководитель нужен для поддержки и развития сотрудника. И это может делать хорошо только тот человек, который разбирается в профессиональной области. Поэтому это нормально, что у каждой роли свой линейный руководитель.
Tekill
Выше я говорил про команду разработки, которая отвечает за выпуск и работоспособность своих систем или продукта. Конечно, на уровне орг структуры можно собрать команду из разных департаментов, но тут о себе постоянно будет напоминать закон Конвея с числом Данбара и ставить палки в колеса.
Для поддержки и развития сотрудника можно выделить функционального руководителя. Т.е. нет серебряной пули.