Интересные обсуждения
темы заинтересовавшие velkin
Професси аналы
19.12.2025
|
Hоmunculus
 |
Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
| 19.12.2025 40 комментариев |
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Видимо в рамках "моих предложений в разработке программы" ты залез на чужое поле
Аналитеги, в идеале, должны быть сведущи в предметной области и иметь представление, что творится под капотом проекта (ну т.е. в коде).
Т.е. что нужно реализовать и как это можно реализовать.
Они и составляют ТЗ.
Ну т.е. в идеальном случае эта должность близка к архитектору.
В реале же там часто работают девочки, которые могут оформить документацию по феншую и худо-бедно могут собрать требования. А потом программисты начинают "причёсывать" и перепроверять фантазии аналитиков
А в госконторах это просто теплые места для блатных девочек.
Так я не понял — мне соглашаться или нет? По рынку программист-аналитик лучше просто программиста? Или это идет в минус?
Параллельная ветка. Я б не соглашался.
H>Так я не понял — мне соглашаться или нет? По рынку программист-аналитик лучше просто программиста? Или это идет в минус?
Код писать не будешь — кому-то это в плюс, для меня — несомненный минус.
По деньгам надо выяснять. ИМХО платят там меньше, чем разработчику. Но может зависеть от предметной области/компании/фазы луны...
SVZ>Код писать не будешь — кому-то это в плюс, для меня — несомненный минус.
Ну нее. Для меня это огромный минус. Нафиг тогда. Могу тогда мои предложения как-то им оформлять, пусть переосмысляют и преподносят, как будто они это придумали. Пофиг. Мне интереснее реализовывать свои придумки
Если платят больше, соглашайся. Если меньше, нет.
H>Так я не понял — мне соглашаться или нет? По рынку программист-аналитик лучше просто программиста? Или это идет в минус?
А это уже зависит исключительно от твоих хотелок.
И да, обратно в программисты после лет 7 в аналитиках будет очень сложно.
H>>Так я не понял — мне соглашаться или нет? По рынку программист-аналитик лучше просто программиста? Или это идет в минус?
V>А это уже зависит исключительно от твоих хотелок.
V>И да, обратно в программисты после лет 7 в аналитиках будет очень сложно.
Можно совмещать аналитику и разработку, например, если по аналитике рисовать исполняемые BPMN-схемы, то это одновременно и аналитика, и проектирование архитектуры, и разработка.
Это бизнес-аналитики.
SVZ>А потом программисты начинают "причёсывать" и перепроверять фантазии аналитиков
А вот это уже системные аналитики. Они почти всегда программисты, просто уже не успеваю код писать.
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Я по юниорству мечтал в архитекторы выбиться, все пытался крутые архитектуры проектировать, а меня все время в какие-то программисты-исследователи записывали.
А потом в итоге сам пришел к выводу, что архитектура вторична, она имеет смысл только для хорошо проработанной теории. А пока ее нет, ты чистый исследователь, который как ученый, двигает науку вперед. А архитектор, скорее как инженер-технолог, просто доводит до ума, то, что исследователь наисследовал.
Вобщем, мораль в том, что нет единой иерархии, есть разные ниши для развития. И аналитик, я так понимаю, это тот же исследователь, только с упором на формализацию теории со стороны заказчика. В то время, как у меня теория формируется в результате программных экспериментов.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
А тестировщик он в твоей иерархии где? Выше или ниже программиста?
У аналитиков, как у программистов (и тестировщиков и девопсов и остальных) есть свои градации сеньёристости. Это просто другая профессия.
У нас в каждой команде есть архитектор, аналитик, ui\ux дизайнер и несколько программистов в тестировщиков. Аналитик грубо говоря собирает, составляет требования к продукту, фиче и тп. Хороший аналитик очень помогает команде — составляет ТЗ и подобные документы, со всеми коммуницирует, изучает конкурирующие продукты, участвует в декомпозиции задач и тп. Плохой аналитик — это как правило просто девочка, которая сидит в уголке и пишет какие-то доки которые никто не читает.
Аналитик это не архитектор. Архитектор должен быть гораздо больше погружен в технологии, в техническую часть.
Для меня «иерархия» — это не в смысле карьерной лестницы (эти крысиные бега никогда не были интересны), а скорее иерархия сложности задач и погруженности в продукт. Доки писать мне нафиг не упало
Тогда не соглашайся, аналитики — это про "доки писть" (точнее, 40% "доки читать и говорить", 20% "код читать", и 40% доки писать)
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Аналитик никак не пересекается с языками программирования, библиотеками и технологиями.
Слушает байки заказчика и обличает в текстовую форму.
Тестирует продукт, демонстрирует заказчику.
Разраб пишет программу на ЯП для компа, а аналитик пишет программу на канцелярите для разраба и тестера.
>Аналитики в иерархии программо-строения вообще где?
Иерархия определяется степенью любимости начальством (кого под кого заставят подстраиваться и больше работать со своей стороны за свой счёт: ленивый аналитик написал неполную противоречивую спецификацию, или тупой программист сам догадаться не может как правильно сделать).
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
намного сложнее. ты написал бред какой от тебя требуют, а тут просят чтобы ты был экспертом в этой области. побереги нервы. ты и так нервный
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Аналитика — это мучительный процесс, если делать эту работу как придётся, без ряда фундаментальных практик.
А с этими практиками — становится достаточно простой и приятной работой, как непосредственное участие в первой фазе жизненного цикла ПО.
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Нигде. Это часть пищевой цепочки: аналитик собирает требования заказчика, архитектор их переводит в технический вид, программисты занимаются реализацией, тестировщики следят за качеством, а руководитель проекта -- за трудоднями.
Но это в теории. На практике же руководитель проекта -- кореш директора, тестировщики "чатятся", программисты срут в репозиторий, архитектор надрачивает на модные технологии, а аналитик -- от слова "анал": это входит в требования заказчика.
"Предложения в разработке программы" -- это про архитектора. Сдаётся мне, что вас хотят не понизить, а опустить (не в иерархии, а морально).
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
у нас пара человек ушло в аналитики — это действительно уход от программирования. Они общаются с заказчиками и составляют спецификации, как уже выше правильно написали.
Две вещи, которые лично я терпеть не могу — постоянное общение с разными посторонними людьми, и составление документов
wl.>у нас пара человек ушло в аналитики — это действительно уход от программирования. Они общаются с заказчиками и составляют спецификации, как уже выше правильно написали.
Во-первых, это не всегда уход от программирования. Во-вторых, это просто отличный повод расширить свой кругозор и понять профессию разработки не только со стороны кодера, но и со стороны бизнеса.
Аналитик с програмерским бекграундом — весьма ценный кадр, потому что он не только является связующим звеном двух миров: бизнеса и технологии, а еще и понимает ограничения обоих миров. Выступает адвокатом разрабов перед заказчиком и дьяволом от заказчика, напрягая разрабов двигаться вперед. Должен быть в курсе технологического стека компании, продвижения новых технологий и развития разрабов. А для этого нужно и самому не забрасывать разработку.
А еще это огромный шаг в сторону своего бизнеса.
pva>А еще это огромный шаг в сторону своего бизнеса.
Это точно, если освоить все этапы ЖЦ ПО (организация процесса/аналитика/разработка/тестирование/ИБ/девопс/инфра/эксплуатация), то потом можно под ключ делать заказчику продукт со своей ИПшки без привлечения сторонних сотрудников (а сотрудники — это всегда гемор, тяжело их организовать, они постоянно уходят/приходят, унося экспертизу; если трудоустроены по ТК, то требуется платить ЗП независимо от текущего дохода компании, в общем, одному всё делать гораздо проще).
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Я бы не переходил. Но зависит от конкретных должностных обязанностей.
Аналитик в софтверной конторе — это не архитектор точно, он, скорее, про то, куда можно и выгодно развивать продукт, где у него проблемы, какие технологии можно и стоит попробовать. Например, надо последовать новую модную технологию, стоит ли её использовать. Или автоматизировать что-то, какие практики у конкурентов, куда движется отрасль и т.д. и и.п. Не обязательно придётся быть прослойкой между командой и заказчиком — это роль проекта. У аналитика перекос в технологии, а не в общение.
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Я бы соглашался, все равно код писать скоро никто не будет, а вот понимание задач заказчика и постановка задач для разработки останется. Т.е. это именно про живое общение с людьми.
Тексты уже тоже по сути писать не надо, за тебя их ИИ напишет. Останется только общение с заказчиком по сути и интерпретация его "хотелок" в то что может быть сделано.
Вот презентации все еще делать скорее всего придется.
В идеале для этого надо понимать как работает бизнес заказчика, т.е. что они делают и чего "на самом деле" хотят (или, точнее, чего могут захотеть завтра)
Ну и границы возможного понятно, т.е. чтобы то чего они хотят можно было реализовать теми силами что у вас есть, ну или как-то урезать запросы.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Процесс разработки программного обеспечения
Одна из методологий RUP.
[img=large]https://upload.wikimedia.org/wikipedia/ru/d/da/RUP_process.png[/img]
Есть ещё такая штука как SWEBOK.
В общем же и целом всё это относится к программной инженерии. На крупном проекте как правило множество сотрудников. Цель создать конвейер из сотрудников имеющих разные роли, что можешь увидеть на одной из конкретных методологий RUP. Это так же как конвейер на производстве или даже вычислительный конвейер в процессоре.
Цель очевидно увеличить скорость разработки с помощью параллельных операций разной направленности. Если бы операции были параллельными, но примерно одной и той же направленности, то это очевидно была бы векторизация или что-то похожее, то есть это как если нанять несколько примерно одинаковых кодеров вместо одного.
Вообще говоря аналитиков несколько, на изображении RUP они вверху. Например
1. Бизнес-аналитик
2. Системный аналитик
и так далее.
Самое главное, если ты не знаешь как работать кем-то, то почему это должны знать другие. Я иногда задумываюсь как развивались крупные компании. Не может же быть, что там прямо сразу появились готовые специалисты. Некоторые бизнесы пришли к нам из 80-ых и 90-ых.
Напрашивается вывод, что программа растёт вместе со специалистами. И лишь потом она разрастается до такой степени, что требует разделения ролей. А если роли разделяются, то должны быть и ключевые сотрудники, которые в этом понимают.
А как происходит сейчас? Какие-то условные лошки с деньгами хотят получить всё и сразу. Или раз с деньгами, то явно не лошки, ведь так? Они говорят нам нужно то и это. Требования у них от балды. Ты анал итик, значит должен заниматься анал изом. Я читал умную книжку, статью, видел что другие подали такое то объявления.
Я то вообще теоретик. Но мои размышления приводят меня к тому, что нет здесь никакой методологии приводящей к успеху. То есть если проект успешен, то это потому что там где-то на низовой позиции специалисты с достаточным профессионализмом компенсирующим общий дебилизм и лошковость начальства.
И возможно 90% провалов это не обязательно успех или провал руководства, а просто достаток или недостаток компетенции непосредственных программистов. То есть смотри, если ты создавал когда-нибудь программу полного цикла в одиночку, то ты сто процентов был всеми видами аналитиков для этой программы.
Можно забить на тесты, но нельзя забить на аналитику. Аналитика переводится на русский как разбор. По идее нужно разобрать на части то, что требуется сделать. Здесь люди опять же поделили бизнес потребности и непосредственную дисциплину сбора требований. А ещё они это отделили от создания архитектуры программы, которую в свою очередь отделили от кодирования программы.
И я что хочу сказать. Если ты ввязываешься в это просто слёту без постепенного наращивания кода, то что? Я не знаю что. В конце концов цель не заниматься анал изом, а сделать работающую программу. Хоть через пень колоду её делай, сделал её по мнению начальника с деньгами, молодец, не сделал, ну тогда всё.
Вообще заниматься программированием это то ещё занятие. Может быть не стоит такое писать людям, которые пишут программы. Но если посторонний человек, но с деньгами хочет сделать программу просто так, потому что потому, то стоит задуматься о том, чтобы этого не делать.
Я просто не понимаю подобные идеи тех, кто ни в чём не разбирается и вдруг хоба, я хочу создать программу. Понятно почему 90% таких проектов приходит крышка.
Недавно же здесь на форуме была тема, как какой-то торговец чужими устройствами раззорился. Там новый сотрудник читал на работе тему как быть кем он уже должен был быть. Торговать и развивать технологии не одно и тоже.
Ну то есть если есть деньги, то очевидно тут же должны найтись компетентные специалисты, так что-ли? Я думаю в идеале надо чаще увольнять людей, текучка, ротация, чтобы никто случайно не накопил компетенцию в бизнесе. Это очень важно и полезно.
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Ну это такие типы, которым кажется, что они знают предметную область и могут преобразовать бизнес-хотелки в технические требования к програмному обеспению.
R>Ну это такие типы, которым кажется, что они знают предметную область и могут преобразовать бизнес-хотелки в технические требования к програмному обеспению.
Я это называю работой в стиле IBM — когда для программы, которая могла бы полностью написана за год втроём, коллектив авторов пишет архитектурную документацию, которая занимает 10 томов и на написание которой уходит 5 лет. А потом 30 программистов её год читают и переругиваются с архитекторами, а потом еще 5 лет реализуют, и еще 5 лет согласовывают нареализованное с архитектурной документацией.
Хорошо иметь неограниченные ресурсы и никуда не торопиться...
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Я привык к программированию в стиле старой школы. Когда одни и те же люди и архитектурные решения принимают, и алгоритмы изобретают и сами код пишут. Примерно, как Ричи и Томпсон (авторы UNIX)
При таком подходе становятся возможными интересные вещи. Например, понадобились ребятам регулярные выражения, ну, они взяли и написали штучку, которая перекомпилирует регулярное выражение в недетерминиванный конечный автомат. Сейчас так редко кто способен делать, такой уровень алгоритмики мало, кто тянет.
Или вот, например, Роб Пайк, из той же шайки, но помоложе, автор Go. Ранние версии компилятора Go были написаны на Си. Когда было принято решение перенести его с Си на Go, чтобы он был self-hosted, Пайк в одни руки написал перекомпилятор с Си на Go и добился 1:1 бинарного совпадения сгенерированного кода на больших проектах. А потом уже этот перекомпилированный компилятор постепенно руками доводили до ума, потому, что на Go можно, конечно, писать, как на Си, но удобнее — идеоматично.
Кто сейчас в состоянии в одни руки написать перекомпилятор из Си в Go?
Это нынешнее разделение труда на аналитиков, архитекторов, алгоритмистов и кодировщиков мне лично совершенно непонятно. Я не понимаю, как можно делать архитектуру, если ты код руками не трогаешь? Это — как композитор, который музыку сочинает, а сам ни на чём играть не умеет. По-моему, так невозможно.
Но в конторе, конечно, название должностей может по-разному ложиться на реальные должностные обязанности. Где-то архитектор с совещаний не вылазит и "программирует" в ворде, а где-то руками хидеры пишет, а местами и код. Надо уточнять в своей конторе, что конкретно они имеют ввиду, и каковы границы твоей свободы.
представь себе проект, который один человек объять не может. теоретически может, но в сутках 24 часа, а в неделе семь дней — такая засада. поэтому не может. ну и вот всё это почти органически вырастает из того, что проект перестал помещаться в одну голову, а тем более в одни руки.
Pzz>>Это нынешнее разделение труда на аналитиков, архитекторов, алгоритмистов и кодировщиков мне лично совершенно непонятно. Я не понимаю, как можно делать архитектуру, если ты код руками не трогаешь? Это — как композитор, который музыку сочинает, а сам ни на чём играть не умеет. По-моему, так невозможно.
K>представь себе проект, который один человек объять не может. теоретически может, но в сутках 24 часа, а в неделе семь дней — такая засада. поэтому не может. ну и вот всё это почти органически вырастает из того, что проект перестал помещаться в одну голову, а тем более в одни руки.
Так он ничего и не говорил про "один человек". Его высказывание вообще не о количестве людей. Его высказывание о нездоровой специализации и разделении функций. Типа как клизму ставят две медсестры — одна знает КАК, а другая знает КУДА.
разделение труда же. кто хочет контролировать всё — потратит жизнь на совещания о цвете кнопок.
K>представь себе проект, который один человек объять не может. теоретически может, но в сутках 24 часа, а в неделе семь дней — такая засада. поэтому не может. ну и вот всё это почти органически вырастает из того, что проект перестал помещаться в одну голову, а тем более в одни руки.
Ядро линукса — достаточно большой проект? Оно разбито по подсистемам, есть майнтейнеры подсистем, но большинство из них не только командуют, но и сами код пишут.
Pzz>Ядро линукса — достаточно большой проект? Оно разбито по подсистемам, есть майнтейнеры подсистем, но большинство из них не только командуют, но и сами код пишут.
любая софтверная контора была бы счастлива, если бы у них аналитиками работали полноценные программеры. и техписами, кстати, тоже. только вот не у всех получается. в большинстве контор закрыть эти позиции могут только людьми, которые с кодом — на вы
Pzz>>Ядро линукса — достаточно большой проект? Оно разбито по подсистемам, есть майнтейнеры подсистем, но большинство из них не только командуют, но и сами код пишут.
K>любая софтверная контора была бы счастлива, если бы у них аналитиками работали полноценные программеры. и техписами, кстати, тоже. только вот не у всех получается. в большинстве контор закрыть эти позиции могут только людьми, которые с кодом — на вы
Но казалось бы, аналитик — довольно квалифицированная должность...
K>>любая софтверная контора была бы счастлива, если бы у них аналитиками работали полноценные программеры. и техписами, кстати, тоже. только вот не у всех получается. в большинстве контор закрыть эти позиции могут только людьми, которые с кодом — на вы
Pzz>Но казалось бы, аналитик — довольно квалифицированная должность...
все занимает время. и квалификация в предметной области, и в программизме. хорошо, когда как в линуксе это более-менее одно и то же. но чаще предметная область определяется законадательством, сложившейся практикой в индустрии (которая, зачастую, предшествует внедрению компьютеров) и т.п.
нужно отдельное время на изучение всего этого.
Так и программист тоже, казалось бы...
H>Аналитики — это чо вообще за зверь?
Посредник между заказчиком и разработчиком. Основная задача — коммуникация и с тем и с другим. Программированием не занимается, даже может и не уметь программировать, но должен знать предметную область заказчика.
Излагает письменно хотелки заказчика — бизнес требования, далее преобразует в функциональные требования, техническое задание(совместно с архитектором/разработчиком).
H>Хотят тут меня из-за моих предложений в разработке программы перетянуть в аналитики. А я как бы программист.
H>Аналитики — это чо вообще за зверь? То есть я понимаю, что надо делать, но это ж вроде проще программинга? Видится как какое-то понижение сложности работы. Аналитики в иерархии программо-строения вообще где?
Думаю все зависит от компании, ее ресурсов и понимании организации процесса.
Например по моим работам:
В прошлом проекте у нас были
— бизнес аналитик
— фанкшанал аналитик
— систем аналитик
— полтора разработчика
— деливери менеджер (совмешает однин аналитик)
— код овнер
— пипл менеджер
В текушем
— аналитик == архитектор, так же ставит задачи разработчику
— разработчик один на сервис
— обший менеджер на несколько сервисов, который преймушественно дрючит аналитика, за то что разработчик что то не сделал или не так сделал.
В позопрошлом
— разработчик, он же кодовнер сервиса
— пипл менеджер на несколько сервисов
— бизнес аналитик вне команды, по особому запросу разработчика, когда что-то не ясно в бизнес логике
Если у компании есть ресурсы,
то у нее еще делят на бизнес аналитики, который может вобше жить на теретории заказчика, узнавать что заказчик хочет и передавать систем аналитику.
У нас в одном проекте бизнес аналитик с пт по ср вобше на самолете летал к заказчику, собирал инфу, показывал наши наработки и прилетал назад. А в чт и пт нам рассказывал результаты.
А вот фанкшанал аналитик уже пишет разработчику что нужно делать.
Опять же в зависимости от проекта, где та в обязаности фанкшанал аналитика входит составить модель базы данных и написать yaml для OpenApi с описанием всех типов данных и ограничений на них.
А где то они таких слов в жизне не слышали и нужно обяснять чем поле типа строка отличается от числа и зачем это.
Y>В прошлом проекте у нас были
Y>- бизнес аналитик
Y>- фанкшанал аналитик
Y>- систем аналитик
Y>- полтора разработчика
Y>- деливери менеджер (совмешает однин аналитик)
Y>- код овнер
Y>- пипл менеджер