Если Вы не читали первые 2 части, предлагаю это сделать! Т.к. третья статья является логическим продолжением. Вот ссылки на них:
Я - ЗУПер! Часть 1. Компетенции сотрудников.
Я - ЗУПер! Часть 2. Классификация проектов и задач.
Напомню цели статей:
1. Рассказать об объёме знаний в своей предметной области, который должен быть у сильного разработчика. (Часть первая)
2. Донести до потенциальных работодателей потенциальный риск набора универсальных солдат.
3. Для ответа на вопрос: "Для кого плохо?", составим классификацию проектов и решаемых задач. (Часть вторая)
4. Рассмотрим проблемы, возникающие при трудоустройстве. Какие ошибки делают работодатели и соискатели? Как их исправить? (Часть третья)
5. Рассказать аудитории читателей данного материала о плюсах специализации на одной предметной области.
6. Побудить коллег, прежде всего руководящий состав, при выполнении проектов думать не только о прибыли, но и о качестве!
Рассказ на основе реального опыта (Часть четвертая).
7. Рассмотреть разницу в уровне знаний разработчиков с "одинаковым" набором заявленных в резюме компетенций.
На данный момент мы уже подготовили фундамент для этой статьи и можем опереться на знания о необходимых компетенциях и на классификацию проектов и задач.
Пора озвучить практические проблемные кейсы, которые побудили меня написать этот цикл статей. Описанные ниже проблемы из моего реального опыта! Уверен, что и в Вашем опыте таких ситуаций множество. Т.к. на работу мы попадаем не из роддома, а проходим через собеседование, то опишу первую ступень на пути - собеседование.
Примеры проблем из описания вакансий:
Кейс №1. Крупная организация из состава Сбера.
Для вакансии ЗУПера, помимо ЗУПа написаны следующие требования:
Важные навыки:
- PostgreSQL;
- Подсистема БСП;
- Автотесты Vanessa;
- 1C:СППР;
- Желание разбираться в смежных технологиях (не указано в каких);
С одной стороны проблем никаких нет! Компания указала, что им интересно получить за определенную сумму. НО!
Попробуем эти же навыки описать другими словами, в виде компетенций (в том же порядке):
- Эксперт по технологическим вопросам, работа с СУБД, производительность. Подобное требование в вакансиях, где ищут разработчика, означает отсутствие на проекте технического архитектора! Это в свою очередь говорит о невероятном бардаке в коде. Вы станете неотделимой частью этого бардака!
- Нет такой компетенции, непонятны её рамки и какую пользу планирует получить работодатель;
- Тестировщик + аналитик (т.к. автотесты обычно аналитики создают на основе сценариев работы);
- Аналитик (т.к. описание различных моделей решения в разных нотациях делает именно он!);
- В последнем пункте есть ощущение, что работодатель сам не понимает, чего же он ожидает.
Получается, что придя на работу, помимо своих обязанностей, Вы будете выполнять работу ещё за троих + неопределенный круг обязанностей из последнего пункта!
Кейс №2. Крупная логистическая компания. В вакансии ищут просто ведущего разработчика. Профиль не указан, но указано вот что:
- Разработка (доработка) планов обмена данными;
- Знание конфигурации Бухгалтерия 3.0 и ЗУП 3.1;
- Знание конвертации данных 2.0;
- Необходимо руководить группой разработчиков;
- Конфигурации: УНФ, УКФ, Бухгалтерия 3.0, ЗУП 3.1, Инталев 8;
Рассмотрим в том же ключе компетенции, которые интересуют работодателя:
- Обмен данными.
- Знание конфигурации БП 3.0 - это выделенная компетенция. Исключение может быть только для мелкого бизнеса! Т.к. там всё просто.
- Обмен данными.
- Руководитель проекта/тимлид.
- В последнем пункте указаны минимум 3 разных компетенции: БПер, ЗУПер и знание управленческого учета в специфической конфигурации Инталев. Часто УНФ является отдельным направлением!
В данной организации Вы будете работать за пятерых!
Кейс №3. Аутсорсинговая компания. Название должности: "Разработчик ЗУП". Одна из самых интересных вакансий.
Обязанности:
- Доработка правил конвертации;
- Поддержка БП 3.0 и ЗУП 3.1;
- Консультации пользователей по методологии учета;
Требования:
- Знание платформы на уровне "1С:Профессионал";
- Знание конфигураций БП 3.0, ЗУП 3.1 и ЗУП 2.5;
- Опыт сопровождение систем клиент-банк и сдачи электронной отчетности;
- Опыт интеграции систем через API, WEB, COM;
- Опыт перехода с ЗУП 2.5 на ЗУП 3.1 и с БП 2.0 на БП 3.0;
- Опыт оказания методологических консультаций;
- Желание развиваться в роли программиста-консультанта.
Рассмотрим в том же ключе компетенции, которые интересуют работодателя:
Исходя из обязанностей:
- Обмен данными;
- Знание конфигурации БП 3.0 - это выделенная компетенция;
- Методолог!
Исходя из требований:
- Не дай Бог встретить такое чудо на своём проекте! Предположу, что имелось ввиду 1С:Специалист.
- Очередной раз упоминают двоих довольно опытных специалистов;
- Ни разу не встречал 1С-ников, владеющих сервисной компетенцией по стороннему ПО. Тем более непонятно, зачем она ЗУПеру!?
- Обмен данными;
- Очередной раз упоминают двоих довольно опытных специалистов; Т.е. это не опечатка, не шаблонная вакансия... Это концепция такая при подборе персонала - нужен универсальный солдат!
- Методолог;
- Что за программист-консультант? Что за новое направление? Опять два в одном. Программист + аналитик.
Кейс №4. ИТ-компания. Название должности: "Программист ЗУП".
Что примечательного в вакансии:
- Слово ЗУП встречается только в названии должности;
- Внизу вакансии указано: Знание ЗУП будет Вашим преимуществом!
К этой вакансии у меня только один вопрос: Вы готовы взять на позицию ЗУПера человека, который не знает ЗУП???
В первой части мы рассмотрели компетенции ЗУПера...
Возникает вопрос: Если кандидат/сотрудник не обладает описанными дополнительными компетенциями, то он не может быть ЗУПером?
Примеры проблемных собеседований:
Кейс №1. Собеседование с одной из структур Газпрома (сферу деятельности указывать не стану, чтоб не указать на конкретную организацию).
Дано:
Предлагаемая должность: Архитектор по направлению ЗУП.
Количество табельных номеров: 5-ти значное!
Регионы: почти все.
Предлагаемые обязанности:
1. Руководство небольшим коллективом
2. Построение бизнес-процесса от выдачи задачи до её решения
3. Проектирование по ключевым задачам
4. Приемка работ от разработчика
5. Сдача работ заказчику
6. Управление сроками (планирование, контроль)
Что можно сказать по этому собеседованию:
- Работодатель озвучил, что есть 4 критически важные задачи по направлению ЗУП, которые нужно выполнить.
- Т.к. есть коллектив, но нет никаких процессов, становится понятно, что либо мы процессы строим, либо задачи делаем. Совместить не получиться, т.к. задачи объёмные и сложные.
- Самое главное, что в этой вакансии предложили совместить несовместимое: Управление сроками и Управление качеством в лице одного человека. Как это возможно? С одной стороны руководитель группы должен стараться ускорить сроки, с другой стороны архитектор должен добиться качественного выполнения задачи. Одно противоречит другому!
- Сдачей работ заказчику должен заниматься аналитик. Подобное требование говорит о его отсутствии, либо нет понимания как его правильно использовать!
- Управление сроками - чистая менеджерская функция.
Это собеседование окончилось ничем, т.к. вынужден был открыто сказать, что не смогу решить управленческие задачи. Собственно и не должен!
В своей статье Кто такой архитектор приводил аргументы против совмещения управленческий и технических компетенций. В этой организации нужен был дополнительно управленец. Тогда все задачи работодателя стали бы решаемыми.
Кейс №2. Собеседование с одним из известных банков.
Дано:
Предлагаемая должность: Ведущий разработчик по направлению ЗУП.
Количество табельных номеров: 5-ти значное!
Регионы: почти все.
Предлагаемые обязанности:
1. Работа в небольшом коллективе под руководством руководителя разработки
2. Выполнение задач по ЗУП
3. Много интеграционных процессов
4. Часть задач по бухгалтерии
Это собеседование было очень близко к понятию "идеальное"! И вот почему:
- Собеседование было техническим (я не общался с HR, этот этап был полностью опущен). Его проводил руководитель группы. На момент проведения собеседования он понятия не имел на какую зарплату я претендую. И вот это настолько упрощает собеседование... Как только убрали деньги, сразу стало комфортно общаться!
- На удивление, вопросы были подобраны человеком с опытом! Никто не спрашивал: "Что такое оклад?" и "Чем отличается физ. лицо от сотрудника?")))
- Под конец собеседования обратил внимание, что много интеграционных процессов. Сообщил руководителю, чтоб интеграции - не мой конёк! И тут он сказал то, за что я сильно начал уважать этого человека: "Я лучше научу тебя делать web-сервисы, чем кому-то буду рассказывать всю предметную область!" Т.е. здесь реально нужны были правильные знания по предметной области, методологии, типовой конфигурации ЗУП, как она устроена внутри себя и т.д. Это была полная противоположность кейсу №4 из вакансий!
- В организации хорошо отлажен процесс разработки
- Много различных плюшек для сотрудников!
Возникает логичный вопрос: "А что не так-то???". Всё просто: пункт №4 оказался обязательным. Таково было решение вышестоящего руководителя.
Почему я решил, что именно вышестоящего!? Потому что с руководителем группы мы обсудили отсутствие у меня компетенций по БП 3.0, и что самое главное - его это полностью устроило! Он даже произнёс фразу: "Это вопрос распределения задач внутри команды. Есть кому заняться бухгалтерией!".
Кейс №3. Собеседование с крупным металлургическим холдингом.
Дано:
Предлагаемая должность: Архитектор по направлению ЗУП.
Количество табельных номеров: 5-ти значное! Первая цифра 5.
Регионы: около 5.
Трудоустраивались (пытались) небольшой командой из 3х человек. Архитектор (я), разработчик, консультант.
Предлагаемые обязанности:
1. Руководство небольшим коллективом
2. Построение иерархической структуры внутри направления ЗУП
3. Участие в создании центра разработки на Урале
4. Определение архитектуры решения, распределение работ между подчиненными
5. Приемка работ
6. Контроль сроков
В этом собеседовании 3 основные странности:
- После нескольких успешных собеседований, проведенных с каждым из нас по-отдельности, нам "предложили" пройти полиграф! Т.к. мы работаем напрямую с персональными данными и видим размер дохода, в т.ч. высшего звена - добро пожаловать на странную никчёмную процедуру.
Это треш какой-то... Из троих человек, его прошла только разработчик. И то только потому, что датчик считывающий дыхание давит девушке... И его сняли. Ни я ни консультант его не прошли! На чём мы погорели (наркота или воровство) нам не сказали! Консультант уже второй раз его не прошёл)
Вот честно не понимаю, как могли не пройти полиграф люди которые:
-- Не пьют
-- Не курят
-- Не врут! Даже когда выгодно соврать!!!
-- Ессно далёкие от наркотиков.
КАК???? И главное - ЗАЧЕМ???? Что получил работодатель от этого максимально бестолкового события?! НИЧЕГО! И даже навредил себе!
На будущее сделал для себя вывод: никогда в этом цирке больше не участвовать! Я всегда работаю на доверии! Если его нет, то и сотрудничества быть не может.
- Второй странностью было желание создать центр разработки на Урале.
Почему называю это странностью? В этой организации автоматизировалось сразу всё: ЗУП, производство, БП. Центр разработки должен был обсуживать потребности всех трёх проектов. По словам ИТ-директора разработчики должны были быть взаимозаменяемыми, чтоб не возникало дефицита разработчиков на проектах, в т.ч. в период отпусков.
По его словам:
-- Архитектор должен написать такое ТЗ, которое сможет сделать любой разработчик!
-- Хорошему разработчику всё равно в какой конфигурации программировать, ведь платформа и язык программирования один и тот же.
Послушал его... Посмотрел как на Иванушку... Решил, что если возьмут меня, подберу себе сам ЗУПеров, и на них буду кидать сложные задачи. А печатные формы и отчеты можно будет раскидывать без учета компетенций по ЗУП. Спорить с ним и объяснять, что он ерунду выдумал было бессмысленно. Особенно если понимать, что это проект федерального масштаба и простых задач на том проекте не было!
Также не совсем понял, почему "центром программирования" был выбран даже не Челябинск, не Екатеринбург, а провинциальный городок с населением в 100 тыс. Откуда такая концентрация хороших разработчиков по 1С? В моём родном городе такого же размера их практически ноль!
В общем хорошо что пронесло!
- Третья сложность состояла в том, что необходимо было делегировать большую часть полномочий как минимум троим! Т.е. выделять локальных архитекторов по направлениям - кадровый учет, расчет зарплаты и налоги/взносы/регл. отчеты/проводки.
В отличие от первых двух проблем, эта сложность привлекала! Было бы интересно... НО! Имея опыт Роснефти за плечами, где делегирование сразу же означало резкое снижение качества в пользу укладывания в сроки... Наверно тоже хорошо) Мой личный приоритет - качество! А в предметной области ЗУП пытаться уложиться в сроки - задача почти невыполнимая. Обычно на старте не видно всех прелестей. Даже многолетний опыт и наличие наработок не спасают от увеличения срока по задачам, иногда кратное!
Проанализировав всё это, у меня возник вопрос к работодателю:
Почему Вы так не уважаете кандидатов???
Вы на этом рынке не продаете вакансии, а покупаете компетенции!!!
В чём проявляется неуважение со стороны работодателя:
- Желание заставить кандидата работать за троих. Банальная жадность!
- В организациях, предлагающих длинные тестовые задания, не уважают чужое время. Стоит напомнить, что время хорошего разработчика стоит от 1500 до 2500!
- Прохождение полиграфа это вообще за гранью разумного в сфере ИТ! Вы за кого принимаете кандидатов???
- Любимая фраза HR-в и руководителей: в резюме можно написать всё что угодно...
- Торги по размеру заработной платы. Здесь надо понять, что у Вас как у работодателя свои потребности, а у кандидата - свои (семья, дети, ипотека, саморазвитие). Почему Вы решили, что можете какие-то его потребности не финансировать?! Вряд ли когда Вы дадите задачу, будете готовы услышать: "Извините, это я делать не буду!". Должен соблюдаться баланс интересов!
- Надо ли напомнить, что некоторые работодатели открыто предупреждают о наличии переработок, и о том, что оплачивать они их не собираются?!
В чём проявляется неуважение со стороны кандидата:
- Откровенное враньё в резюме! Реально кто-то думает, что это не вскроется? На первой же задаче!
- Заказывают на сайтах фриланса решить тестовое задание. Чем Вам это поможет? Ну решу я идеально задание, оформлю код по стандартам разработки... А повторить-то слабо!
- Неоправданно завышенные зарплатные ожидания. Т.е. опыта 2 года, сертификатов ноль, без ТЗ не работаю, про стандарты разработки не слышал, или не соблюдаю... А хочу 200 тыс.! Я ж программист 1С!
- Изучение текста вакансий "через строчку по диагонали". Ведь любой из нас, в первую очередь, смотрит на то, что он знает! И только раза с 3-го, при внимательном анализе текста вакансии, можно разглядеть в чём не силён. Но, обычно, отклик на вакансию возникает раньше, чем 3-е прочтение текста вакансии. Коллеги, если Вы не умеете анализировать элементарное, то и в работе будете пропускать много важного и ошибаться!
В чём проявляется отсутствие самоуважения у кандидата:
- Непонимание своих сильных компетенций.
- Самобичевание из-за отсутствия каких-то компетенций. Это не недостаток, это задел на будущее!
- Готовность работать ниже рынка, сверхурочно без положенной оплаты.
У меня опять к обоим есть вопрос: "Вы чё творите??? Вы ещё даже работать не начали!!!"
Как работодателям улучшить процесс поиска сотрудников:
1. Определить по статье 2 на какой проект подбирается сотрудник.
2. Определить какие задачи должен решать этот сотрудник.
3. Осознать, что рабочий день - это 8 часов! Не 24, не 16 и даже не 12! Поэтому стоит определиться, в какой конфигурации специалист будет работать.
4. Найти нормального админа. Если работы недостаточно - пусть это будет совместитель, скорей всего даже удалёнщик. Каждый должен заниматься своим делом!
5. Промониторить рынок труда, выяснить ценник сотрудника исходя из масштаба проекта и сложности задач. Если бюджет ограничен - есть возможность работать с ИП или самозанятыми. Это реальная экономия до 30% фонда оплаты труда (ФОТ).
6. Осознать, что никто не должен работать бесплатно и изучить статьи 153 и 99 ТК РФ.
7. Научитесь определять компетенции работника в процессе собеседования, поверьте никто не хочет выполнять тестовые задания!
Как кандидату повысить свои шансы трудоустроиться и не быть уволенным на испытательном сроке:
1. Перестать врать! Не важно как это проявляется, в резюме или просто в беседе. Завышать свои достижения - это тоже врать! Всё, что Вы выдумали легко выяснится на испытательном сроке.
2. Честно (объективно) оценить собственные компетенции. Какие профессиональные качества могут помочь Вам в работе.
3. Также объективно стоит составить список своих недостатков. Если Ваш недостаток описан в вакансии в графе "Требования", обязательно обратите внимание работодателя на это! Это не снизит Ваши шансы, это повысит доверие к Вам.
4. Составьте список компетенций, которыми Вы хотите овладеть. Это Ваш индивидуальный план развития. Нормальный работодатель Вам в этом поможет.
5. Изучите резюме коллег, посмотрите их набор компетенций, сравните со своими. Это поможет объективно оценить в рублях свои знания.
6. Внимательно изучайте текст вакансии. Каждая строчка имеет смысл! Старайтесь в работе столь же внимательно (после трудоустройства) изучать ТЗ, письма от заказчиков и коллег, документацию. Это позволит Вам меньше ошибаться!
7. Осознайте, что оклад + премия платится не за присутствие и не потому что есть трудовой договор. Ваша работа всегда измеряется результатом и ожиданиями работодателя! Рекомендую уточнить у работодателя, что он ожидает от Вас через месяц, квартал и год работы.
Плюсы специализации на одной предметной области:
1. Есть возможность сосредоточиться на одной предметной области. При выполнении разных проектов, из разных отраслей экономики, изучается большое количество бизнес-процессов, и различных вариаций каждого из бизнес-процессов. Если предметной областью назвать расчет премий... То в каждой организации этот бизнес-процесс:
-- Состоит из разных шагов.
-- В нём присутствуют разные премии (месячная, квартальная, годовая).
-- Используются разные подходы в определении размера премии (KPI или просто процент).
-- Используются разные подходы в подсчета базы для расчета премий (включать сверхурочку или нет, начислять годовую премию на месячную или нет и т.д.).
2. Изучается большое количество бизнес-процессов, связанны с предметной областью. Примеры редких бизнес-процессов:
-- Разъездной характер работы. В основном все работают в офисах/на заводах.
-- Работа в условиях МКС/РКС.
-- Вахтовый метод работы или полевые условия труда.
-- Сдельная оплата труда. Сейчас даже на многих производственных площадках заменяют сделку премиями.
3. При автоматизации бизнес-процессов разработчик/аналитик изучает большое количество объектов метаданных в используемой конфигурации.
Если постоянно переключаться с одного решения на другое возникают проблемы:
-- Вся информация изучается "по верхам", т.е. в минимально необходимом для выполнения задачи объёме. Из-за этого часто упускают важные сценарии.
-- Т.к. ни одно из решений не является "родным", уходит больше времени на разбор типового кода.
-- Из-за непонимания правильной концепции решения рождается много "костылей".
-- Разработчик более зависим от качества постановки задачи.
-- Задача решается только в рамках ТЗ. Редко возникают предложения по сопутствующим сценариям.
4. Если говорить о разработчиках, то шире и глубже изучается архитектура кода.
Например в ЗУП важно понимать следующие особенности:
-- Большинство отчетов написаны с использованием механизма представлений. Писать отчеты с нуля самому - так себе затея!
-- Большую часть данных, необходимых для разработки каких-либо механизмов, можно получить с помощью типового программного интерфейса.
Как разобрать программный интерфейс описывал ранее в статье Как читать чужой код? Часть 4. Программный интерфейс.
-- Большинство расчетных алгоритмов кроются в обработке "Менеджер расчета зарплаты". Если есть расчетные задачи - обязательно необходимо использовать эту обработку.
-- Почти все алгоритмы, связанные с отработанным временем, располагаются в обработке "Менеджер данных учета времени сотрудников".
Примеры использования последних 2-х обработок можно найти в типовой конфигурации.
Подходы к изучению типового кода описаны в статье Как читать чужой код? Часть 2. Доработка типовой конфигурации.
Приведу один из примеров из конфигурации ЕРП. В ЕРП принято управлять видимостью элементов формы документов через условное оформление формы.
Когда с этим довелось столкнуться, был просто в ступоре, т.к. искал Видимость/Доступность. Потом коллеги знающие подсказали.
Таких особенностей очень много в каждой конфигурации. Знать их все - сомнительное мероприятие.
Но понимать ключевые алгоритмы одного из решений - довольно не сложная, понятная и достижимая задача!
Подытожим сказанное, ответив на вопрос: "А для кого плохо быть универсальным солдатом и для кого хорошо концентрироваться на одном решении"?
Сначала о хорошем:
- Хорошо на крупных проектах, особенно федерального масштаба иметь узкую специализацию.
- Хорошо при решении масштабных и сложных задач выбирать правильный путь решения задач и не делать "костыли".
- Хорошо на проектах внедрения выбирать путь решения, продиктованный глубокими знаниями и многолетним опытом.
- Хорошо при обследовании и оптимизации бизнес-процессов иметь многоплановый опыт в разных сегментах экономики.
- Абсолютно нормально поручать разработку отчетов на любых проектах начинающим и универсальным солдатам. Необходимо лишь указать источники данных и помнить про механизм представлений если это ЗУП. Отчеты повышенной сложности стоит поручать более опытным коллегам.
- Абсолютно нормально поручать разработку интеграционных механизмов на любых проектах начинающим и универсальным солдатам. Необходимо лишь указать источники данных. В задачах повышенной сложности можно поручить опытному разработчику получение специфических данных.
- Допустимо на проектах сопровождения в мелком бизнесе и в обычных организациях, поручать не сложные задачи начинающим или универсальным сотрудникам.
- Допустимо на проектах внедрения поручать средние задачи универсальным солдатам, давая возможность глубже погрузиться в предметную область.
Чего делать не стоит, чтоб не было плохо:
- Не стоит давать ключевые и масштабные задачи на любых проектах универсальным солдатам.
- Не стоит рассчитывать, что на проектах федерального масштаба и на крупных проектах один человек закроет несколько позиций.
- Не стоит совмещать в одном человеке управленческие и технические компетенции. Невозможно одномоментно отвечать за качество и за срок!
- Не стоит думать, что 10 лет опыта по верхам в разных предметных областях помогут качественно выполнять сложные задачи.
- Не стоит думать, что сертификат "Специалист" (консультант) делает из соискателя профессионала в данной области.
Финальное напутствие коллегам:
- Уважайте друг друга!
- Стремитесь делать качественно, а не в срок!
- Развивайте свои компетенции!
Тогда любая работа будет приносить удовольствие и результаты!
Напомню ранее написанные статьи с общим названием "Ни в ЗУП ногой?! А мне нравится!":
1. Главные сложности решения, что отталкивает?
Статьи под общим названием "Как читать чужой код?":
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Статья про роль и значимость архитектора на проекте:
1. Кто такой архитектор. Редакция 2!
Описываем ошибки правильно. Правило трех вопросов
Полезные обработки:
Пример работы с файлами odt в клиент-серверной модели работы
