Comments 19
Команда получает от бизнеса задачи, которые отвечают на вопрос: “Что нужно сделать”. А системный аналитик решает “Как команда это реализует”. Детально прорабатывая задачу, системный аналитик может обсудить промежуточный вариант с разработчиком или обсудить что-то с архитектором. Но именно он решает, какие веб-сервисы будем вызывать, как обрабатывать полученные данные и какие для этого нужны доработки. Организует обсуждение со сторонними командами, если требуется. Фактически, здесь роль системного аналитика близка к канонической.
Не дочитал до конца, но уже начало заставляет меня полыхать. И ещё больше должно заставлять полыхать разработчиков, которые таким образом работают.
Вот эта мысль про разделение труда для большей специализации/эффективности порочна, она уродует людей, вызывает отчуждение в трудовой деятельности. Разработчики просто втыкают в код, их интерес смещается в то чтобы быстрее выполнять постановки. Из-за этого качество кода будет снижаться, вам обязательно понадобится армия тестировщиков, лидов и архитекторов, т.е. отрастить себе целую субъектность с выстроенной иерархией. Тем самым разработчики становятся рабочей силой, которая устремиться туда где платят больше, а не проект интереснее.
Когда человек что-то утверждает, чаще всего он за своим отношением скрывает собственные интересы. Вам просто удобно что такой человек есть. В реальности же, если вы делаете современный и востребованный продукт, у вас и менеджмент не палочный будет, и структура команды другая.
На больших проектах по agile такой подход достаточно высокоэффективен и на мой взгляд вообще единственный.
А ваша мысль про «разработчики-рабочая сила» это скорее про людей, а не про подход.
Когда человек что-то утверждает, чаще всего он за своим отношением скрывает собственные интересы. Вам просто удобно что такой человек есть.
Я с вами не согласен.
MishaTheSlayer Системный аналитик
Это ваш хлеб — конечно вы не согласны. А я нахожусь с другой стороны, не согласен с вами. В какой-то мере, это вопрос к разработчикам. Или они ведут себя как инженеры и сами драйвят разработку, или как специалисты по кодингу без каких-либо претензий, в т.ч. зарплатных. Но как бы там ни было, в большинстве проектов аналитик выдуманная профессия, нужная настолько же, насколько нужен продавец на кассе крупного ретейлера. Код пишут программисты — это реальный труд, а 10 менеджеров над двумя программистами — это трэш.
Отчасти я с вами соглашусь. Лично я ещё не встречал тех, у кого был бы неискажённый scrum. Если вы по должности аналитик, а по роли доменный эксперт и владелец продукта, но не менеджер, т.е. вы не форсите побольше задач в спринт, не пытаетесь команду заставить спинт закончить на выходных, то у вас интересный случай) завидую вашим коллегам в таком случае!
По рассказам у всех всё правильно, но чаще всего желание получить квартальные/годовые бонусы делает аналитиков немного манагерами)
Отсюда у меня вопрос: а код писать все же будете? И если будете, не будете ли отвлекаться на указанное выше? А если будете отвлекаться, не повлияет ли это на качество кода, снижение качества которого потребует армию тестировщиков? А Если не будете, то кто должен выполнять указанный выше анализ?
если вы считаете что аналитик не нужен... тогда логично предположить, что вы как универсальный программист будете тратить время не только на сбор требований и их формальное описание, проектирование и описание решения для реализации продукта, но и будете описывать тестовые кейсы, а так же всю прочую документацию по проекту (которая должна быть написана!) и также вы будете проводить демо, отвечать за опытную эксплуатацию и за первичное обучение?
не все из мной перечисленного должен делать аналитик. но обычно - делает. все это.
почему? потому что "пламенных инженеров" не заставить сделать все вышеперечисленное и делать правильно, да и ЭТО НЕ НАДО все сваливать в кучку!
от программиста требуется понимать инженерию программирования. он должен любую задачу поставленную формально - уметь быстро и КАЧЕСТВЕННО кодить. не отвлекаясь на второстепенные задачи.
но если вы привыкли работать в одиночку, как фулл-стек разработчик на небольших задачах, наверно вы и не поймете для чего в командах делает разделение ролей и почему чтобы сделать продукт быстро и качественно - нужные не только "пламенные инженеры".
Я могу сделать всё! Если проект мне нравится, берусь за все роли, чтобы всё взлетело.
А вы рассказываете как должен работать программист, но можете ли взять его работу на себя? Или вам выгодно такое представление, что программист должен свою работу "быстро делать" и "не отвлекаясь"? Услышать бы мнение ваших коллег))
Наверное, у вас в команде не было хорошего системного аналитика или не было его вообще. Он решает много проблем, начиная от интеграции стороннего человека на проект, путем написания всей технической документации до проектирования wsdl/openApi или запросов graphQL, как минимум на этих двух пунктах вы уже экономите кучу денег, когда программист на вход получает "Хочу красиво" он не понимает что нужно делать, а когда написано реализуй сервис по CQRS + EventSourcing c такими-то требованиями и так далее, совсем другое. Вы не понимаете чем занимается этот человек, от этого вы эту специальность игнорируете.
реализуй сервис по CQRS + EventSourcing c такими-то требованиями
Если наступить себе на горло (потому что будет лукавство сказать что я просто разработчик), то я вам могу ответить что
Вы крадёте инженерную составляющую у разрабов, говоря как делать. Большинство разрабов с высшим образованием. Уже давно нет профессии кодера из бурсы и т.п. Это их работа и компетенции выбирать будут они делать CQRS или нет.
Вы так рассуждаете, потому что хотите на галере занять место не на вёслах, а указвая как грести. Я может открою тайну, но везде всё одинаковое! Мы повторяем одну и туже работу для разных собственников, чтобы они имели конкурентное приемущество. Но все мы живём в одном одинаковом мире, с одинаковыми технологиями, с похожими ограничениями. Ничего уникального, как правило, аналитик не изыщит.
Есть блестящая книга "Фабрики разработки программ". Там есть ужасающая мысль - авторы замечают, что ещё с 80х индустрия проходит стадию ремесленичества и отчаяно нуждается в "индустриализации". Т.е. нужно не плодить людей "нужных", а использовать CI/CD, DDD, микросервисы, Agile и прочее.
Не мало таких людей, которые как и я не испытывают церебрального самоудовлетворения (как говорят физики) от кодинга. Не мало людей кому интересна предметка и её автоматизация/улучшение/автоматизация. Для нас не зазорно сделать всю работу самому, ещё и других научить/документацию оставить.
Не подумайте что я считаю только аналитиков бесполезными. Мой опыт работы и общения говорит о том что мы все бесполезны по большому счёту, т.к. не делаем чаще всего ничего (!) полезного, кроме как делаем кого-то более конкурентно способным....Правильнее будет даже сказать, что аналитики не бесполезны, в аспекте антагонизма работников/собственников, аналитик будет относится к прослойке надсмотрщиков, а поэтому просто не товарищи, когда вторгаются на чужую территорию без просьбы о помощи.
Дополню о своём опыте, потому что намёков сверху было много.
У меня был опыт работы в организации по разработке мед.систем. Я аналитиков не видел, не слышал о них! Тогда мне эта работа не нравилась, но я точно знаю, что продукт был великолепен, конкурентноспособен.
А потому была работа где на 2 прогера 1 аналитик, и менеджмент говорил что ещё нужно. Мол не продукт нужно делать, а понять что делать. Мешками вертеть энто не аналитику делать! Продукт годы топчется на месте, и ещё будет. Потому что чтобы там не придумали аналитики, всё поменяется в силу внешних факторов - конкуренции, где то явно, а где-то опосредовано. Задача стоит так, что нужно не сделать что-то для бизнеса, а как сделать то, что не будет выкинуто в корзину после изменений.
А помимо своего опыта, я ещё и с коллегами общаюсь, на митапы/конфы хожу, книги читаю, ведь нет ничего хуже, чем судить по себе и для себя, а не критически ;)
Вы не диалог ведете, а навязываете мне свою точку зрения. Я вашу точку зрения понял с самого начала.
Я вам еще раз говорю, что в больших проектах, аналитик необходим из-за большого количества итераций, бизнес-требований и необходимости тестирования(tdd выносим за скоуп).
Мне просто интересно как разработчики будут работать с бт, писать документацию, выяснять требования, говорить как должно работать тестировщику, взаимодействовать с заказчиком и кодить))
Да и разработчики есть разного уровня, если вы про инженерную составляющую, как и аналитики. А ваш хлеб оставьте себе, он не нужен аналитику, есть разные уровни абстракции.
Специальность молодая и набирающая обороты, так что 5 стадий принятия неизбежного
Да, разделение труда ведёт к увеличению эффективности. Если мы будем как сапожники в Средние Века сами всё делать: и шить и кроить и продавать - большой эффективности не будет. Да, вы будете получать удовольствие от процесса, но промышленной разработки не случится.
Опять же, если системный аналитик что-то за вас придумал, никто не мешает вам предложить какой-то свой вариант, который может оказаться даже внезапно лучше.
И вообще, у вас в коде целое поле для творчества - стопитцот книг и языков программирования. Бояться, что какой-то системный аналитик отнимет у вас всё творчество - глупо.
Кажется есть небольшая путаница с тем — может быть аналитик лидом или нет. Настоящего лида не могут назначить, он вырастает изнутри команды, за счет небезразличного отношения к коллективу и работе берет на себя некоторые организационные моменты, несет в разных случаях экспертизу о процессах развития продукта, общения с контрагентами и т.д., и т.п. Это получается "само собой". Ну поставят РО лидом, а оно ему нафиг не надо… И кому от этого легче?
Что значит вырастает? Лид не гриб, это должность, на которую точно так же подают резюме и собеседуются… Ну по крайней мере на фирмах, где более десяти человек персонала.
И естественно, что если человек лидом быть не хочет, он и резюме не подаст. Ну разве что в очень редких случаях, если надо денег, и никаких других предложений… Но тогда это ад для всех, как правило.
А если встать на сторону команды? Представьте ситуацию, когда компания на проект набрала команду, ребята работают, пилят софт. В этой среде естественным образом появится человек, который возьмет на себя роль неофициального лидера, потому что ему, первое, не все равно, второе, не сложно выполнять какие-то организационные обязанности, он драйвит команду, а команда отвечает взаимностью — приходит за помощью и советом. Это и есть неформальный лидер. Такое происходит в любой организации — от дворовой компашки до спортивных команд и ИТ.
А потом руководство решает внедрить что-то новое. Приводит человека со стороны и говорит: вот, он теперь будет вашим лидом.
Он может стать лидом или нет. Все зависит от его поведения и того, как примет его команда.
А первый, который уже по сути лид, действительно вырос из команды и правильнее назначить его на эту роль, если руководство вдруг решило выделить эту позицию официально.
А уж кто это будет — аналитик, разработчик, РО или еще кто-то не так важно.
В коммерческой фирме «сам по себе» софт пилиться не будет, задачи приходят от бизнеса, проходят через аналитиков и «спускаются» в команду на реализацию уже как раз через лидов.
Лид — это прежде всего менеджер, его задачи — это не написание кода, а администрирование команды (в т.ч. собеседование и увольнение сотрудников), наблюдение и управление прогрессом разработки, создание отчётов для вышестоящего начальства, техническое обеспечение и т.д. И естественно, что в интересах компании будет поставить руководителем ответственное лицо, которое будет заинтересовано в прогрессе проекта, а не местного тамаду.
Тем более зачастую компания набирает на проект людей, которые, как правило, друг друга в первый-второй раз в жизни видят (а если это удалённая команда, то вообще ни разу не видели). Общая цель у наёмной команды одна — это коммерческая успешность (ибо тогда и бонусы, и плюшки для всех). И именно лид призван обеспечивать эту успешность, и тут не особо важно, знал он членов команды до этого лично или так же видит в их первый раз, как и они его. Прежде всего это должен быть компетентный специалист, который сможет определить слабые и сильные стороны команды, подтянуть её, где этого требуется,
Должен ли системный аналитик вторгаться на чужую территорию?