Бизнес-аналитик vs Системный аналитик. Продолжение Хочу несколько дополнить свой предыдущий пост и объяснить ход моих размышлений, может быть, тогда станет ясно, почему я против (для идеальной команды) деления аналитиков на бизнес и системных. Во-первых, могло показаться, что я против самой роли аналитика. Это не так, роль, безусловно, нужная и важная — как раз для выяснения потребности / задачи и проектирования бизнесового / процессного решения задачи — то, что в SDLC называется «Сбор требований и анализ». Эту работу отлично сделает аналитик, и для нее нужны определенные компетенции и склад характера (круг по психогеометрическому тесту отлично зайдет), которые редко встречаются у разработчиков. Но в том же SDLC следующая фаза — это «Проектирование архитектуры», что как бы намекает, что для этого нужен senior специалист с глубокими знаниями решения (а таким, на мой взгляд, может быть только senior разработчик). И тут возникает диссонанс: почему-то проектирование архитектуры поручают тому, кто сам код не пишет. А далее возникают два нежелательных последствия для команды (помимо риска получить слабое решение): * Плохие разработчики (которые просто пишут код по ТЗ и не вникают в те задачи, которые нужно решить — я их условно называю кодерами) реализуют то, что написано, не пытаясь найти более умное / красивое решение. Интересоваться бизнесом такой сотрудник не будет. * Хорошие разработчики (которые хотят вникать в проблемы бизнеса и разрабатывать решения для этих проблем) видят, что все уже решено до них, на документах сотни печатей и подписей, и нужно не предлагать что-то умное, а просто сделать так, как написано в документе. И со временем из разработчиков становятся кодерами. Очень похоже на эффект Тома Сойера но наоборот. Нашел два видео на тему (правда, с участием и того же человека), там в том числе и рекомендации, как ситуацию можно улучшить: Почему системный аналитик в компании - это bad smell? Почему вам не нужен системный аналитик?