Я в сфере 1С более 10 лет. Работал в качестве разработчика, руководителя проекта. Также являюсь сертифицированным преподавателем и автором сертифицированного курса от фирмы 1С. Последние 4 года активно занимаюсь обучением и подбором персонала.
Сегодня я расскажу о подборе персонала, вариантах собеседования и классификации программистов 1С. Покажу таблицу квалификации 1С-разработчиков и приведу пару вариантов теоретического собеседования и задач на практику.
Технический долг
Перед тем, как начать, хотел бы акцентировать внимание на таком термине, как «технический долг».
Технический долг – метафора, которая служит единицей измерения. Технический долг измеряет стоимость дальнейшего сопровождения после внедрения или разработки. Мы пытаемся оценить, сколько будет стоить исправление ошибок после разработки.
Если говорить о термине технического долга, то это касается не только программистов, но и всей команды, участвующей в разработке или внедрении: руководителя проекта, консультантов, аналитиков, не стоит исключать и самих заказчиков. Но я акцентирую внимание только на программистах.
Вот несколько примеров, когда возникает технический долг, который может привести к потере нескольких миллионов и более.
-
Самый простой пример, который я встретил недавно: нашему клиенту нужно было внедрить отраслевое решение и разработать подсистему производственного учета. Клиент привлек консалтинговую компанию с очень хорошим опытом внедрения именно этого отраслевого решения и разработки производственного учета. У этой компании были успешные проекты, положительные отзывы, но после внедрения отраслевого решения и разработки подсистемы компании-клиенту пришлось использовать свой штат программистов и привлекать нас как ресурсный центр, чтобы исправить ошибки, допущенные при внедрении и разработке. Ошибки были допущены из-за того, что сама эта консалтинговая компания привлекала команду, состоящую из разработчиков уровня middle. Чуть позже я расскажу об этой классификации. Из-за такого уровня у разработчиков были пробелы в знаниях, они принимали неправильные решения, допускали ошибки в алгоритмах, оптимизации и в самой архитектуре. Нам понадобилось полгода, чтобы все это исправить. В итоге технический долг составил 50% от стоимости внедрения. Само внедрение стоило порядка 10-12 млн и около 5 млн компании потребовалось, чтобы все исправить.
-
Но технический долг возникает не только при внедрении, но и при сопровождении. У другого нашего клиента был штат программистов, состоящий из разработчиков уровней junior и senior. Junior – разработчики начинающие, из-за пробелов в знаниях они тоже совершают ошибки: в оптимизации, алгоритмах, изначально неправильно выстраивают архитектуру. Ошибки возникают, а бизнес все время развивается и ставит новые задачи, поэтому разработчики использовали метод «костыльного программирования». То есть быстренько вставляли какое-то исправление, но в дальнейшем этим «костылем» здесь правили, а в другом месте ломали. Все это набиралось, как снежный ком, технический долг рос, в итоге компания за три года привлекла дополнительно себе в штат еще три программиста. Им приходилось ежегодно принимать по одному программисту дополнительно, потому что штат не справлялся с техническим долгом, команда не успевала масштабировать программу и исправлять ошибки. ФОТ каждого разработчика в год составлял порядка 1 млн. В итоге за три года компания себе нагенерировала 3 млн убытков.
Чтобы исключить возникновение технического долга, в первую очередь стоит акцентировать внимание на подборе персонала. Именно в этот момент мы определяем, какой будет стоимость технического долга, каким будет ее процентное соотношение к полной стоимости разработки.
Сам технический долг, конечно, будет всегда. Всегда будут ошибки, которые нужно исправлять. Все, что мы можем сделать – привести технический долг к минимальному проценту, чтобы свести к минимуму необходимость исправления ошибки.
Итак, мы определились: для уменьшения технического долга нужно правильно, более качественно подбирать персонал. Давайте попробуем рассмотреть, какие у нас бывают варианты собеседования. Их много, но я выбрал порядка шести.
Первый вид собеседования – «Чем ты занимался на прошлой работе»
Мне такой вид собеседования, когда мы спрашиваем человека, чем он может гордиться, больше всего нравится. Здесь есть плюсы.
-
От кандидата мы можем получить информацию о том, чем он занимался, в каких проектах участвовал, какие механизмы знает, какие достижения у него есть.
-
Мы получаем картину о самом человеке.
На этом плюсы заканчиваются, и начинаются минусы.
-
Первый минус – все врут. Вам может попасться кандидат, который с три короба наврет о своих достижениях и знаниях. В принципе, он может даже присвоить себе достижения другого разработчика и исказить информацию о своих навыках.
-
Второй вариант – вы можете столкнуться с «партизаном». У человека при работе может быть хорошая коммуникация, он хороший разработчик, но на собеседовании он скукоживается и не может выдать информацию о своих навыках и достижениях. Частенько разработчики почему-то стесняются рассказать, какими знаниями обладают.
Все в целом приводит к тому, что мы не получаем подлинную и полную информацию о навыках разработчика.
Следующий вариант – закрытый тест
Закрытый тест включает в себя следующее: дается вопрос и несколько вариантов ответа. Разработчику нужно выбрать правильный вариант.
Этот вид мне тоже нравится, он дает хороший плюс для работодателя.
-
Он очень удобен: когда мы даем разработчику тест, мы не тратим время на собеседование. Время тратится только на то, чтобы проверить результаты. Тем более, если тест автоматизирован, мы можем в два клика посмотреть, что он знает, что не знает.
На этом плюсы заканчиваются. И есть минусы.
-
Этот тест удобен самому кандидату. Если он не знает ответа на вопрос, у него есть вариант воспользоваться методом «научного тыка». Вполне возможно, что он просто угадает правильный ответ. Тогда у нас тоже искажается информация.
-
Следующее: частенько видел такое, что когда задавали вопросы, в самом же вопросе был и ответ. Нужно очень грамотно подходить к составлению вопросов и ответов, потому что мы можем сами подсказать кандидату.
-
Также есть примеры, когда разработчик ошибся – перенервничал или засомневался. В случае закрытого теста мы не сможем задать ему дополнительные вопросы, чтобы удостовериться, знает ли он ответ.
-
Ни в коем случае не стоит использовать вопросы из экзамена на сертификат «1С:Профессионал». По той причине, что «1С:Профессионал» уже умудряются сдавать специалисты на уровне junior, которые прошли какой-то курс или прочли книжку Радченко для начинающих программистов. В дальнейшем они просто зазубривают вопросы экзамена и их ответы: все это есть в открытом доступе, даже на сайте самой фирмы «1С». Я сам сдал экзамен «1С:Профессионал» по платформе меньше чем за минуту со 100% правильными ответами, так что судите сами.
Следующий вариант – практическая задача
Вариант проверить разработчика на решении практической задачи мне очень нравится, я сам его использую.
-
Мы можем проверить разработчика по определенным навыкам программирования, может ли он выполнять подобные задачи. Например, если нас интересует, умеет ли программист выполнять алгоритм метода списания по ФИФО, мы можем в этом удостовериться.
-
Плюс ко всему мы можем посмотреть его синтаксис, насколько грамотно он пишет.
На этом плюсы заканчиваются и начинаются минусы.
-
Невозможно создать практическое задание, которое будет охватывать все возможности платформы 1С. То есть, создать можно, но тогда кандидату понадобится минимум 3-4 дня, чтобы решить все эти задачи. Ни один кандидат под этим не подпишется.
-
Второй момент – если разработчику дали на дом выполнение задачи, мы уже не можем гарантировать, что это сделал именно он, не используя дополнительные ресурсы. Частенько бывает, что когда я спрашиваю у кандидата: «А ты вообще как программируешь?», он отвечает: «Да я просто на Инфостарт лезу». Очень много примеров, готовых решений и так далее. Есть такие программисты, которые по четыре года могут программировать за счет Инфостарта и уже, наверное, должны процент откидывать.
Получается, что использовать в собеседовании практическую задачу мы можем только для того, чтобы закрепить свое решение. Но чтобы проверить знания по платформе, мы должны использовать больше теоретические вопросы, это происходит быстрее – больше вопросов можно задать.
Следующий вариант – показать пример программного кода
Когда мы просим разработчика показать пример программного кода, есть плюсы:
-
мы не заморачиваемся на вопросах, какое бы задание дать, и мы в принципе можем не уметь программировать, а отдать результат на проверку программисту;
-
мы можем посмотреть чистоту программного кода, качество написания, мышления, синтаксис.
На этом плюсы заканчиваются и начинаются минусы.
-
Есть так называемая «помощь зала». В моей практике было такое, что 3-4 разработчика чтобы пройти собеседование использовали мою обработку.
-
И не надо думать, что он потом, когда ему придется работать самому, как-то включит мозг. Программисту на самом деле глубоко плевать, его главная задача – устроиться к вам на работу. Слабые и средние специалисты, как правило, не идут в компанию, где будут единственными программистами: на этой позиции все сразу будет видно. Они идут к работодателям, у которых уже есть команда разработчиков, среди которых можно затеряться.
В целом, вариант «Показать программный код» – сомнительный вариант, не люблю его использовать, потому что мы не получим точной информации о навыках разработчика.
Открытый тест – задается вопрос, надо ответить «своими словами»
При собеседовании методом «Открытого теста» разработчику приходится отвечать в открытой форме: устно или письменно.
Плюсы этого варианта в том, что:
-
мы можем анализировать ответы кандидата, при необходимости уточнять какие-то задачи, дополнительно задавать вопросы – в принципе, 50-60 вопросов хватает, чтобы проверить программиста полностью, получить полную информацию;
-
когда у кандидата нет вариантов ответа, он не может угадать ответ, если не знает вопроса;
-
поэтому по сравнению с другими вариантами собеседования мы получаем подлинную информацию о знаниях и навыках кандидата именно по платформе 1С.
Минусы:
-
Чтобы составить вопросы, а тем более – проверять, необходимо самому иметь очень хорошие навыки программирования.
-
При таком собеседовании приходится затрачивать очень большое количество времени на каждого кандидата. До того, как я начал использовать собственный сервис, я тратил на каждого кандидата около часа. Но когда вам очень нужны разработчики, приходится собеседовать по 5-6 человек в день – на это уходит весь рабочий день.
Выявим самое полезное с возможностью проверки знаний
Итак, выведем основные методы проверки знаний из тех вариантов, которые я назвал.
-
Закрытый тест я выбираю в первую очередь за быстроту проверки – на него затрачивается минимальное количество времени, а для руководителя это очень важно.
-
Второе – практическая задача, потому что мы можем проверить синтаксис разработчика, грамотность программирования и качество программного кода.
-
Третье – открытый тест. Я его выбираю, потому что мы можем полностью проверить всю карту знаний разработчика, получить более полную информацию.
Лично у меня получилось совместить закрытый тест с открытым. Сначала я использую открытый тест – проверяю разработчика через теорию. Если здесь все хорошо, то следующей идет практическая задача, просто уже для закрепления и окончательного решения о том, что я беру специалиста на работу.
Квалификация программистов
Итак, мы рассмотрели варианты собеседования, и я употреблял такие термины как middle, senior. Это такие уровни квалификации программистов 1С, давайте немножко поговорим о них.
Такие понятия как junior, middle, senior в 1С особо не использовались, это обычное явление для программистов Java, C#, PHP, C++. В 1С это только начало входить в обиход, сам я такие понятия начал использовать года два назад. И у самой фирмы «1С» появился экзамен 1С:Junior.
Если говорить о классификации. Junior – начинающий программист, который максимум изучил какой-то курс или прочел книгу для начинающих. У него нет опыта программирования и 1С он в глаза пару раз видел, по сути. Программист такого уровня в принципе подойдет для обновления типовых конфигураций, несильно доработанных конфигураций, может вносить незначительные изменения в печатные формы, внешние обработки создавать. В принципе, может администрировать пользователей, права давать, но не более того.
Далее идет уровень junior-middle. Это уже разработчик получше, чем junior. Он обладает навыками в оперативном учете, умеет уже немного сам создавать отчеты, используя СКД – это будут самые простые отчеты – управляемые формы немножко знает и немного знаком с отладчиком, но на самом деле не умеет как следует им пользоваться, как показывает опыт. Тем не менее, он уже молодец.
Далее middle-разработчики, среднячки. Эти программисты уже точно знают, что такое отладчик, и умеют им пользоваться. Они уже умеют работать в оперативном учете, могут решать бухгалтерские задачи, умеют с обменами что-то делать, например, уже знают конфигурацию конвертации данных, но максимум могут 1 к 1 выгружать данные. Какие-то более сложные алгоритмы – например, из одного объекта выгрузить в другой – они уже не смогут осилить.
Middle-разработчиков на самом деле можно нанимать, нужно. Но нужно еще и качественно делать отбор, потому что у всех знания разнятся: кто-то силен в одном, кто-то – в другом. Надо очень много времени потратить, чтобы понять, подходит вам этот разработчик или нет. Даже если вы немножко ошибетесь, стоимость технического долга может составить все 100%, а то и более.
Большое количество разработчиков на рынке – уровня middle, около 40%. У них куча пробелов, это приводит к возникновению технического долга. Например, он изучил оперативные запросы: настолько, насколько столкнулся с этой задачей, настолько и изучил. Из-за этого скорость разработки у них то быстрее, то медленнее, ведь при решении задачи им приходится изучать сам механизм. Из-за сжатых сроков и необходимости изучать новые механизмы они не смотрят на качество кода, на оптимальность и не программируют по стилистике типовых конфигураций 1С.
Далее идет уровень middle-senior, это разработчик поинтереснее. Если такого разработчика увидите, я его рекомендую уже брать. Потому что они уже имеют хорошие навыки в оперативном учете, пишут хорошие запросы, отслеживают оптимальность программного кода, за качеством следят, стилистику типовых конфигураций повторяют, очень хорошо знают обмены, бухгалтерские, оперативные задачи могут решать хорошо. В целом они уже могут претендовать на должность ведущего разработчика, и их можно оставлять как полноценную единицу. Даешь ему задачу – он сам ее решит, не надо особо помогать и присматривать за ним.
Остаются senior’ы. Это уже ведущие разработчики, пробелов в знаниях у них уже практически нет. Единственное, там есть расчетные задачи и XDTO-пакеты – те объекты, которые очень редко используются. Даже если у вас есть, к примеру, «Зарплата», очень мала вероятность, что вы там будете регистры расчетов или планы видов расчета дорабатывать – обычно этим никто не занимается уже.
Если senior сталкивается с новым механизмом – он его быстро изучает, благодаря своим знаниям, навыкам, и опыту, на работе это не отражается. Им принципиально важно, чтобы их код был качественным, оптимальным, они программируют только по стилистике программного кода 1С. Какие у них минусы? На рынке их реально очень мало. Они стоят хороших денег: например, в Москве разработчик такого уровня зарабатывает от 200 тыс. рублей и более – это на руки. Главный «косяк» в том, что они знают: их мало, и они действительно дорого стоят. Пытаться сбивать ценник бесполезно, уйдут сразу.
Шкала квалификации кандидатов
Теперь давайте посмотрим саму таблицу квалификации. Статистику я собирал, собеседуя программистов 1С с января по февраль. Собеседовал где-то 1233 кандидата. Таблица разбита по квалификациям, категориям вопросов. У меня здесь есть цифры – средний балл от 1 до 10 по каждой категории вопросов и классификации программистов 1С, которых набирали. И еще здесь вот такая «детская раскраска».
Слева внизу указано общее количество разработчиков и процентное соотношение программистов на рынке. Junior’ов у нас 46,72%, junior-middle – 12,41%, middle – 23,36%, middle-senior – 13,87%, senior – всего 3,65%.
Чтобы не портить статистику и привлечь всех кандидатов, я не ограничиваю зарплаты, предлагаю сразу «максималку». Учитывайте период исследования – зиму – здесь немножко коэффициенты меняются. Зима – это мертвый период для набора программистов. Потому что те же самые senior’ы заняты на проектах и пока работу не ищут. Если осенью или весной их собирать, происходит целый парад резюме, и нужно только успеть забрать специалиста, прежде чем кто-то другой его наймет.
Осенняя статистика немного приятнее. Там middl’ы составляют действительно 40%, senior’ы – 5-6%, но это максимально то, что есть на рынке. Есть еще теория математики, которая подтверждает, что сильных специалистов на рынке всегда 5-6%. Название теории не помню, извините.
Теперь по шкале квалификации. Если мы посмотрим junior’ов, у них все «красное». Они только познакомились с механизмами, где-то что-то прочли, у них нет знаний, либо они поверхностные. Упаси Господь подключать их на какую-то сложную разработку. Когда я был на уровне junior, меня работодатель отправил доработать какую-то конфигурацию: три недели потом ходил исправлял.
Junior-middle – мы видим, что они поизучали книжки и четко знают, что такое функциональные опции. Они знают какие-то общие объекты, чуть-чуть умеют пользоваться запросами СКД, знакомы с управляемыми формами и набирают по этому показателю средний балл, знают сами оперативные учеты.
У уровня middl’ов уже все поинтереснее, баллов собирается побольше. Они уже знают бухгалтерские задачи, наконец-то понимают, что такое модуль менеджера. На самом деле, многие разработчики понятия не имеют, что это за модуль, и что в нем есть хорошего. Они знают уже о «Конвертации данных» и начинают решать самые простые задачи. Но, например, выгрузить регистр сведений, чтобы он загрузился как справочник, большинство из них уже не сможет.
Дальше идет middle-senior, здесь у него уже все прекрасно по оперативному учету, по общим объектам. Он уже хорошо разбирается в клиент-серверном взаимодействии, например, общие модули те же самые: многие разработчики не знают, зачем эти галочки нужны и как их правильно проставить. Это, конечно, громко сказано, но, тем не менее, это один из механизмов. Хорошо знают управляемые формы, уже работали с RLS’ом, в СКД’шке хорошо отчеты пишут – это значит, что более сложные отчеты уже могут делать.
И, наконец, senior’ы – практически все «зеленое». Единственные пробелы – планы обмена, расчетные задачи, XDTO-пакеты. Планы обмена и XDTO-пакеты действительно редко встречаются, и только 20% senior’ов имели очень хороший опыт разработки обмена между конфигурациями, используя планы обмена и понимали, как это работает. Большинство останавливается на том, что есть некая БСП’шка, которая в принципе помогает, а как именно это работает – они понятия не имеют. Если дать им задачу, например, обмена с сайтом, где БСП уже не помогает, нужно использовать планы обмена – они уже начинают проседать.
Тем не менее, программисты уровня senior все это быстро изучают. Например, те же самые XDTO-пакеты. Скажем так, если я знал «КД 2.0» и XDTO-пакеты, а мне дают задачу по «КД 3.0»: это совсем другая конфигурация, и там для того, чтобы делать обмены, нужно знать XDTO-пакеты. Мне понадобилось 2-3 часа, чтобы изучить и приступить к выполнению задачи. По срокам я уложился вовремя.
Примеры вопросов для собеседования программистов 1С
Как я и сказал, задаю 50-60 вопросов, у меня их несколько пакетов. Но выделю несколько вариантов.
Например, по регистрам расчетов – бухгалтерская задача.
Задача 1. Есть два счета, у обоих есть субконто: «Склад» и «Номенклатура». Но у одного субконто1 – это склад, а другого – «Номенклатура». Как сделать, чтобы при получении данных из виртуальной таблицы «Остатки» у нас субконто1 = склад, а субконто2 = номенклатура в независимости от счета.
Интересно, что многие даже на уровне senior не могут решить эту задачу. На самом деле, все просто. В виртуальной таблице есть параметр – «Вид субконто». Там передается массив или список значений, с типом плана значений передается план видов характеристик.
Задача 2. Мы обратились к физической таблице регистра накопления. У него есть регистратор, регистратор составного типа. Надо отобрать записи, у которых регистратор является документом «Поступление товаров», далее из отобранных записей необходимо из регистратора вытащить реквизит «Склад». Так, чтобы было оптимально. Как это сделать?
Большинство разработчиков говорят: «Слушай, а почему это не измерение? Это неоптимально, ты вообще неправильную задачу дал». Бывает такое. На самом деле, и тут все просто. В условие «Где» ставим конструкцию «Ссылка», «Поступление товаров и услуг». И второе, используем метод «Выразить», приводим к определенному типу «Поступление товаров» и потом вытаскиваем реквизит «Склад».
Частенько к этой задаче даю дополнительный вопрос. Если человек сказал, что использует метод «Выразить», я спрашиваю: «А почему?».
Следующее и последнее – практическая задача. Обожаю ее, потому что она быстренько выявляет, кто перед нами: middle или senior. Разработчики уровня middle эту задачу 100% решат. Но решат не с первого раза, и потратят на это от 40 до 60 минут.
Senior решит эту задачу за 5-15 минут максимум, с первого раза. Я даю эту задачу и прошу написать текст запроса, не используя отладчик. Проверяю, человек действительно писал хорошо запросы или нет. Формирует ли он в голове, что происходит с таблицей, когда мы группируем, связь делаем и так далее.
Суть задачи следующая: дается старая таблица и новая таблица значений.
Вариантов решения много: 3-4, и один из них наиболее оптимальный. Ни один middle не решил мне эту задачу за 10-15 минут.
На этом у меня все, всем огромное спасибо!
*************
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.
