Комментарии 16
А где системный анализ собственно?))То что описано это бизнес-анализ с элементами понимания архитектуры :)
Во-первых, это в целом популярная проблема наименования людей системными и бизнес-аналитиками. И тут вопрос, кто и как называется.
Во-вторых, не спорю, что в описании больше упора на бизнес-анализ, т.к. сделать тот или иной системный анализ у нас в ИТ-команде могут многие. А вот сопоставить системные процессы с бизнес-процессами почти никто не может и на моем опыте собеседований, делать такое упражнение могут далеко не все. По факту, чтобы разобраться в наших системных процессах требуется не просто анализ с элементом понимания архитектуры, а глубокое погружение в нее (модели данных, типы обменов, структура БД, причины выбора того или иного архитектурного решения). Просто мало разбираться только в системных процессах, нужно еще и понимать, а зачем мы это делаем.
В самом начале статьи правильно подмечено, что от компании к компании есть отличия как в распределении функций системного\бизнес анализа, так и названия конкретных должностей. С учетом диаграммы активности по этапам, расположением отдела в проектном офисе и описания рабочего процесса должности системный аналитик, то действительно этой должности в Lamoda в большей мере присущи функции бизнес анализа, чем системного. Тут я солидарен с мнением.
Это также заметно по контексту, в котором озвучена работа аналитиков: когда это проект с его стандартным жизненным циклом инициация-анализ-разработка-запуск, то аналитик фокусируется на целях проекта и его бизнес заказчиках (т.е. бизнес анализе), а за кадром участия в проекте остаются прочие аспекты уже системного анализа. Аспекты вовлечения в не проектные задачи, реального устройства "черного ящика" и деталей его работы, документирование "черного ящика", привлечение в L3 уровень поддержки, тесное взаимодействие с продактом в случае продуктовых команд. В эти аспекты просто невозможно погружаться в проектном подходе, вот и получается что это закрывает команда и техлид, кто на самом деле и будут выполнять большинство функций системного анализа.
Статья полезная, раскрывает чем придется заниматься и что делать в компании.
Да, статья построена на примере проектной деятельности. Но у нас сейчас аналитики отвечают привлекаются не только в проектную деятельность, но и во все перечисленные тобою активности, в рамках того или иного направления. И к выяснению устройства "черного ящика", саппорт в части бизнес-процессов (то есть мы не привлекаемся к саппорту, который как-то относится к кодингу или инфраструктуре), тесному взаимодействию с продактом и другими ролями команды привлекается системный аналитик. В текущих реалиях отделять системного аналитика от команды некорректно. Мы и есть команда. Нет такого разделения ни в одной команде и направлении.
В статье как раз описано отделение аналитика от команды. Да, его могут привлекать к задачам и к решению проблем команды, но он никогда не будет являться частью команды, так как тут разные линейные руководители. Команда на то и команда, что она объединена в одной иерархии под одним линейным руководителем, который имеет прямой доступ и контроль над своей командой.
Либо команда сама несет определенную функцию, либо привлекает ее на стороне, в том числе и других командах, в вашем случае в команде аналитики. В то, что разделения нигде нет не поверю, обычно в компаниях, начиная со средней, в дирекции\направлении\департаменте ERP есть отдельные люди с функциями системного анализа, часто называются консультантами.
Я не согласна, что определение к тому или иному линейному руководителю означает, является ли человек членом команды или нет. В первую очередь команда - это сотрудники, которые работают над одними задачами и объединены единой целью. Вокруг этого строятся процессы. И в команде есть сотрудники из разных "департаментов" и это правильно: продакты, PM-ы, QA, разработчики, системные аналитики, бизнес PM. Но говорить о том, что люди, которые работают бок-о-бок над одними задачами, которые поддерживают друг друга, проверяют друг друга и таким образом решают задачи эффективно, не команда - это обидно и не соответствует истине. Если так к этому относиться, то действительно не будет ни командного духа, ни команды и задачи будут решать отдельными людьми, без которых все ломается. Мы через это прошли и возвращаться обратно к такому подходу не хочется.
А линейный руководитель нужен для поддержки и развития сотрудника. И это может делать хорошо только тот человек, который разбирается в профессиональной области. Поэтому это нормально, что у каждой роли свой линейный руководитель.
Выше я говорил про команду разработки, которая отвечает за выпуск и работоспособность своих систем или продукта. Конечно, на уровне орг структуры можно собрать команду из разных департаментов, но тут о себе постоянно будет напоминать закон Конвея с числом Данбара и ставить палки в колеса.
Для поддержки и развития сотрудника можно выделить функционального руководителя. Т.е. нет серебряной пули.
Интересно и познавательно..
Но на протяжении чтения статьи не покидало ощущение, что вы: назвали бизнес-аналитика системным, а системного - техлидом 😆
Заголовок кажется кликбейтным. Статью кидают в разные чаты TG и ожидал увидеть какими методами аналитики вскрывают и описывают черный ящик, а в итоге про это пара предложение.
Тема о том кто такой бизнес-аналитик, а кто такой системный уже вроде как не холивар т.к. есть профстандарты на обоих.
Самое интересное, что решения вы разрабатываете вроде как по "водопаду" - этапы один за другим и в релиз. А почему такая же методика не применяется при принятии решения о найме 18 (!) аналитиков. т.е. вы пишите, что сначала их наняли, а потом начали думать - кто они и зачем мы их наняли. Плюс, ни разработка, ни QA не знали об этом т.е. потребности в аналитиках вроде как и не было. Ведь правильней сначала выявить требования, а потом закрыть их. Разве нет?
Подобную ситуацию, когда идет беспощадный найм аналитиков встречаю уже не первый раз и не могу понять в чем причина. Это, видимо, какой-то странный ответ на бурный рост компании и попытка освоить бюджет на ИТ, а после уже оправдать эти траты. Часто вижу непонимание разрабов, зачем им работать с аналитиком.
Еще про черный ящик - вся бизнес-логика ПО как правило, описана в коде. О том, что написано в коде, можно только догадываться смотря в БД или играясь с API. Я хочу сказать, что системный аналитик, как сотрудник, который должен разбираться в работе системы должен уметь читать код и знать технологический стек и, как мне кажется, не все, указанные для возможного перехода в аналитики, смежные специалисты обладают такими навыками.
Я уже чуть более 5 лет и бизнес-, и системный аналитик. Видимо, наступила какая-то стадия рефлексии о профессии и своем месте в ней:) И последнее время прихожу к выводу, что СА/БА это лишнее звено в профессиональном коллективе и затычка для дыр в коммуникациях и знаниях в непрофессиональном - где заказчики не могут внятно и грамотно изъясняться и составлять требования, а разрабам стало можно не погружаться в предметную область и проблемы бизнеса.
Если тема интересна, то мы ей поделимся.
Профстандарты, безусловно, есть (в обсуждении одного из них я даже принимала участие). Но в этих профстандартах есть довольно много пересечений. И все равно каждая компания, каждый бизнес-домен что-то определенное вкладывает в названия этих должностей. И это превращается в холивар. И я убеждена в том, что системный анализ без понимания бизнес-процессов будет неполным. Всегда надо понимать, что автоматизирует система и зачем.
Нет, разработка чаще всего не идет по "водопаду" эти этапы идут часто параллельно итерациями. e-comm в водопадном режиме не выживет. Тут скорее хотелось показать, что на разных этапах проекта системный аналитик решает разные задачи. Насчет того, почему не выясняли требования к системным аналитикам от команды. Во-первых, системные аналитики в компании существуют с 2013 года, просто их количество было небольшим. И понимание, кто такой системный аналитик у нас было всегда. Но это понимание было устным, не в описании роли (конечно, должностные обязанности есть, но они недоступны команде). Описание роли хотелось описать "на бумаге" и озвучить всем командам. И да, была проблема, что команды не всегда понимали, по каким вопросам к нам можно идти, а по каким - не стоит. И не потому что, системные аналитики в чем-то не разбирались. А как раз-таки наоборот, системные аналитики решали слишком много вопросов, которые должны были быть в другой зоне ответственности. Когда мы начали активно нанимать, роль прекрасно уже была определена, о чем рассказывалось на собеседованиях кандидатам. Но именно четкое описание в Confluence помогло делать найм эффективнее (одна из причин эффективного найма), т.к. "портрет" аналитика был всегда перед глазами.
Наши команды прекрасно понимают, зачем им нужны выделенные системные аналитики и как делится между нами ответственность. И мне кажется, отчасти вы ответили об этом в последнем абзаце. Я соглашусь, что СА/БА может быть лишним звеном и сама об этом люблю рассуждать с другими коллегами - системными и бизнес-аналитиками. И есть много критериев, когда нужен выделенный системный или бизнес-аналитик, а когда он бесполезен. Если в компании бурный рост, то процессы работать идеально не могут. Это нормально. И для такого роста системные аналитики полезны, т.к. могут навести порядок и структурировать информацию в компании. А еще очень сильно зависит от объема существующих бизнес-процессов. Когда их слишком много, то нужны выделенные роли для того, чтобы разбираться в них и в нужных изменениях.
Навыкам можно обучить - это мое убеждение. Со временем необходимые навыки меняются. Сложнее обучить логически рассуждать, быть любопытным и грамотным, не бояться неизвестности. А знать технологический стек, читать код, рисовать схемы в любых нотациях, работать с API или СУБД - это просто некоторое время, которое нужно потратить на обучение и опыт. А вот то, что в коде описана вся бизнес-логика, да и еще так, чтобы ее понять, это неправда. По крайней мере, далеко не во всех системах это так. А главное, что в коде редко пишут, зачем это нужно. На что это может повлиять. И если бизнес-процессы уже довольно обширные, то эту бизнес-логику в коде никогда не проследить.
Я убеждена за свои чуть больше 10 лет работы в системном анализе в разных компаниях, что довольно много есть случаев в профессиональном сообществе, когда системные аналитики нужны. И чем дальше, тем больше в этом будет проявляться необходимость, т.к. все больше процессов автоматизируется.
Про тему черного ящика было бы очень интересно прочитать - это не самая освещаемая тема, но по моему опыту довольно актуальная. Это, кстати, одна из причин появления аналитика в компании - разобрать и задокументировать работу продукта, который дорос до некоторой точки, когда команда, которая его разрабатывала начинает меняться и не знает как она работает и, главное, почему она работает именно так:)
Про профстандарт системного аналитика - в нем СА как раз вменяется работа с бизнес-процессами. Он там вообще довольно универсальным профессионалом получается.
А вот нужность аналитиков - это холиварная тема:) Мое непопулярное мнение и ваш двукратный опыт не оставляют мне шансов, поэтому оставлю его пока при себе:)
Да, полностью согласна. Аналитики часто появляются в этот момент. Мне кажется, в этом и есть признак взросления компании. Хотя есть компании, в которых нет аналитика. Но по отзывам знаю, что они бы там не помешали.
Мне этим и нравится наша профессия, что нужен универсал. Это разнообразно и заставляет погружаться в разные бизнес-домены. Приходится всегда думать.
Ваше мнение часто обсуждается на различных площадках, так что смело давайте рассуждать на эту тему вместе :-) Это же здорово иметь четкие критерии, когда мы полезны, а когда - нет. Это повышает эффективность и мотивацию аналитиков.
Соглашусь с предыдущим комментатором. Все это похоже на водопад. Или серию мини водопадов без user story и вот этого всего)
Взломщики «черного ящика»: чем занимаются системные аналитики в Lamoda