Кто такой аналитик 1с на практике
В небольших компаниях под "аналитиком 1с" понимается некий "Человек-передающий"(чтобы помягче звучало. Есть еще 1 короткое русское матерное слово, ну вы сами догадаетесь) , который передает или пересказывает ТЗ от бизнеса программисту.
Часто это мешает. Аналитики в таких компаниях мало понимают в программировании. А чтобы составить адекватное ТЗ, эти знания не просто нужны, а необходимы.
Аналитики в таких компаниях или сознательно себя ограничивают функциями связанными с бизнесом, или им забивают голову утверждениями типа "вы не должны программировать, это не ваше занятие...".
Такие утверждения удивляют. Кто им вбивает такую чушь в голову? Зачем это делается?
Примеры из жизни кругом и рядом. Возьмите геодезиста, который работает с измерениями земляных участков. Он измеряет точные границы участков. Станут ли ему в голову вбивать утверждения типа "ты СУПЕР геодезист, ты НЕ должен касаться грязной вонючей земли, ты высшее существо! У тебя высшее образование!". На практике, все Вузы направляют будущих спецов на практику, где они делают земляные работы, чтобы не боялись грязи, имели опыт работы с землей, понимали рабочих.
Или пример с архитектором зданий. Все они проходят через практику строительства, начиная с простого рабочего на стройке, прораба и другие специальности нижнего и среднего звена. Через 5 лет архитектор становится СПЕЦИАЛИСТОМ который прошел все уровни развития и знает, как работает строительство, начиная от рядового строителя.
В 1с сейчас искусственно разделяют программистов и аналитиков. Это выглядит очень странно.
А еще есть вакансии типа "программист-аналитик". Это 2в1. На самом деле все программисты лет 10-15 назад назывались просто программистами, совмещали в себе несколько функций.
Вы попробуйте готовить архитекторов зданий, которые умеют только чертить на бумаге, и никогда не занимались строительством (на уровне рабочего).
Построенные здания по таким проектам развалятся и разрушатся, потому что проектировщики не знают мелочей, которые влияют на множество процессов.
Аналогично с аналитиками, которые никогда не программировали.
Читаю ТЗ. "сделать обработку, которая изменяет количество в табличной части документа реализация.". Товарищ аналитик, а ты в кусе, что документ имеет множество зависимостей, цепочку других документов, и менять количество нельзя (в проведенном документе)? Забыл детали? Да за такие ТЗ увольнять надо.
Но аналитиков (особенно девушек, родственниц начальников), снисходительно оставляют, всю работу по "доработке ТЗ" вешают на программиста.
Это выглядит смешно.
Это примерно как, если бы Архитектор составил план здания. А рядовой прораб сказал ему - эта колонна очень слабая, все верхние этажи обрушатся, когда начнется производство в здании. Окей, говорит Архитектор, я в этом ничего не понимаю, товарищ прораб, перерисуйте план здания и начинайте строительство сразу.
Прораб думает "а нахрена ты мне тут нужен, товарищ Архитектор. А почему тебя не увольняют за такое? ты же нарушил нормы строительство, могли пострадать люди, за такое не просто увольняют а садят в тюрьму"
-----
На Аналитика в небольших IT компаниях часто падают обязанности других коллег. Молодому аналитику популярно объяснят что ЕЩЕ он должен, если хочет больше зарплату или продвижения по карьерной лестнице.
Есть еще большая разница между Аналитиками мужского рода и женского. Извините дамы. Но я много раз видел на практике, девушки-аналитики позволяет себе множество пробелов в знаниях, а когда они раскрываются во время сложных и ответственных проектов, сваливают ответственность на то что они из женщины, у них дети и вообще все вопросы к мужьям. Я в своей практике программиста 1с это встречал много десятков раз.
АНАЛИТИК мужского рода. Таких я встречал не часто. Такие люди или преклонных лет с гигантским опытом, которые любую ситуацию и любой проект могут спокойно сделать (запроектировать и если надо запрограммировать). Либо же это сверхответственные люди с большим опытом по части общения с людьми и бизнесом, у которых удовольствие от самого общения и того, как это превращается в выигрыши по проектам.
Очень часто во многих проектах, мне, как программисту с приличным опытом (в виду скромности сильно занизил), приходится объяснять аналитикам как я вижу изменения в проекте. Приходится учить аналитиков, показывать на их ошибки.
Частая проблема у аналитиков (без учета их пола и ответственности) - им замылили мозги тем "... что они еще ДОЛЖНЫ". Они не сосредоточились на ПРАКТИЧЕСКОМ ОПЫТЕ. Они подменяют НАВЫКИ ЗНАНИЯМИ. Считают, что если они прочитали статью про регистры, значит уже все умеют и знаний достаточно. Но практика показывает, что они лишь в начале пути и им еще очень много чего учить. А лучше получить спец знания по программированию, смежной профессии. Эти знания помогут им вытащить себя, как Барон Мюнхаузен из Ж..пы в которую сами себя загнали по проектам