Коллеги, добрый день! Пообщались намедни с коллегами у кофемашины относительно того, кто нужнее на проекте: нишевый эксперт-специалист или профессионал-многостаночник? Напомню, работаю руководителем проектов внедрения в IT-компании Lad, то есть публика собралась заинтересованная и знающая. Делюсь в статье основными выводами, к которым пришли.

Консультант 1С + Программист 1С = «человек-оркестр»

Кто же этот homo universalis, сочетающий в себе несочетаемые, на первый взгляд, скиллы: может работать и с технической составляющей проекта, и способен объяснить пользователю (кладовщику, логисту или бухгалтеру), как все устроено, научить работать в системе.

Программист-консультант может сам проинтервьюировать клиента, написать ТЗ и работать по нему, то есть ведет проект практически на 360 градусов: от изучения специфики бизнес-процессов заказчика до собственноручной реализации требуемого функционала и его дальнейшего развития и сопровождения. 

Это профессионал, который знает систему до «последнего винтика», может объяснить клиенту, как внедряемая конфигурация выполнит его задачи, способен сам осуществить доработки и разрешить сложную ситуацию. Как правило, когда система стабилизирована — передает эстафету коллегам, которые систему поддерживают.

Программист-консультант на проекте: взболтать, но не смешивать?

Кто эффективнее в проектной команде — специалист или универсал? Высказались коллеги, которые в своей ежедневной работе бок о бок работают и с теми, и с другими (среди моих собеседников тоже есть люди с непростой 1С-судьбой) — в целом, они сошлись во мнениях:

• чем крупнее проект (много блоков и пользователей) — тем более выделенные, точечные и сложные задачи у специалиста: нужно хорошо понимать и предметную область, и специфику бизнеса, и нюансы кода — в этом случае лучше привлекать узкопрофильных специалистов. 

  На крупных проектах невозможно охватить все. Руководитель проекта знает концепцию и какие-то ключевые вещи, но в тонкости всех процессов может быть и не погружен. 

  Если, например, работает команда из 30 человек, то в ней обязательно есть выделенные аналитики и пишущие красивый код программисты. Могут быть и универсалы «аналитик+программист», но такие специалисты будут решать небольшие, локальные задачи. В больших командах в любом случае есть разделение ролей, и даже если для работы над задачей соберутся три универсальных специалиста, то кто-то будет больше отвечать за программирование, а кто-то — за аналитику. 

• Если команда из 5-7 человек работает на проекте автоматизации для компании небольшого или среднего размера, то обычно задачи не требуют такой специализации, поэтому имеет смысл привлекать универсальных спецов, чтобы не тратить время на длинные цепочки передачи информации между участниками проекта. В такой команде может быть один профильный программист, 2-3 консультанта, а остальные могут совмещать. Так, например, консультант-аналитик может программировать, реализовывать точечные доработки. 

Что касается пост-проектного сопровождения, то здесь чаще всего бывает разделение: программист сопровождение оказывает редко, так как его ключевая задача — реализация функционала. Роль консультанта-аналитика — работать с данными, писать инструкции, рисовать модели, отвечать на вопросы пользователей. Задача от клиента приходит консультанту, если вопрос чисто аналитический, то он решает сам, если вопрос к программисту, то универсал может и сам сделать, а чистый консультант-аналитик передаст программисту.

Вот тут-то наша беседа и свернула к вопросу: кем лучше быть?

Кем быть в 1С

Коллеги перечислили условные "плюсы и минусы":

• когда ты только консультант: случается, что внутри команды высокая конкуренция за занятость на проектах. Если у консультанта-аналитика нет обширной области знаний: например, он специализируется только на торговле, то в какой-то момент в пуле клиентов может не оказаться торгового предприятия. Или, например, на определенном этапе проекта в дело вступает программист, а для аналитика занятости нет. Если консультант-аналитик компетентен в отдельных блоках, но недостаточно квалифицирован, чтобы принимать участие в любых проектах, то рано или поздно приходится ждать. 

• когда ты только программист: тебе нужна большая проектная команда. В ней должны быть аналитики, которые смогут написать четкое техническое задание: вплоть до того, что берется справочник, в него добавляются пять реквизитов, каждый реквизит — эта дата, либо число, либо строка, а оставшиеся два ссылаются на что-то другое. Если такого технического задания не будет, то чистый программист сможет, наверное, составить задание, но с большим количеством уточнений. Программист может написать обмены с разными информационными системами, сайтами, но при этом ему нужен их перечень, то есть программист силен при условии, что ему предоставили все исходные данные. 

Программист и консультант начинают постигать азы профессий друг друга, чтобы:

• избежать вынужденного простоя и быть более востребованными;

• быть более автономными в условиях борьбы за ресурсы при работе на проекте. 

Если человек понимает, как работают компании, зная при этом программирование, то он сам построит функциональную модель, затратив меньше времени. Если программисту не хватает вводных, то он сам может созвониться с клиентом, проинтервьюировать и составить четкий перечень задач. Или консультант-аналитик в какой-то момент начинает постигать азы программирования, чтобы иметь технический фундамент и разбираться, как построена система и по какой логике работает. 

Наши кейсы

У нас в команде есть разные специалисты. Если говорить об универсалах и о том, как они к этому пришли, истории разные. Так наш коллега Вячеслав закончил профильный курс по программированию, пришел в компанию с небольшим опытом в написании кода, учился на практике — прокачивался и как программист, и начинал разбираться в предметной области. Сейчас он — опытный, «универсальный боец», который решает бизнес-задачи заказчика через автоматизацию от постановки до ввода учетной системы в эксплуатацию.

Есть и аналитики, которые прокачались в программировании. Другой наш коллега Владимир начинал свой путь с консультанта по бухгалтерскому учету, бюджетированию. Он работал на масштабных проектах и занимался также и постпроектным сопровождением. Часто слышал от клиентов: «Надо вот здесь поправить» или «А как это будет работать?». Вместо того, чтобы «дергать» программистов, он стал задумываться сам, изучал код, пробовал и делал. 

Советы бывалых: к чему стремиться «одинэсникам»

Стоит ли распыляться между разными областями или же фокусироваться на одном направлении? Мои бывалые коллеги говорят:

• 1С — это прикладная сфера. Если мы что-то делаем, значит это необходимо для бизнеса. Даже если работаем с государственными организациями, то все равно те или иные функции они выполняют посредством бизнес-процессов. У нас нет абстрактных задач, поэтому программисты все равно должны вникать в контекст, может быть, не так глубоко, как аналитики, но какие-то вещи они должны осознавать и понимать.

• Для того, чтобы программиста взяли в крупный проект, он должен изучать базовые вещи и начинать ориентироваться в предметной области.

• Универсал может компенсировать слабые стороны сильными сторонами.

Работодатели редко размещают запрос на универсала. Чаще компании ищут программиста, подразумевая специалиста, который знает и умеет все: и прособеседует, и напишет ТЗ, и все реализует. Можно смело сказать одно: всем нужны знания. Нужны программисты, которые знают свою предметную область: бухгалтерский учет, зарплата, либо ERP. 

Коллеги, делитесь в комментариях вашим опытом: как складывается профессиональный путь? Готовы ли быть универсалом или топите за специализацию? Может быть, сотрудничали на проектах и с теми, и с другими — кто оказался результативнее?