Я - ЗУПер! Часть 3. Ошибки работодателей и соискателей. Плюсы специализации на одной предметной области

19.04.23

Бизнес-анализ

В первой части рассмотрели компетенции специалиста в сфере ЗУП, во второй классификацию проектов и задач на проектах. В этой статье рассмотрим плюсы и минусы специализации. Для каких проектов нужна специализация в одной предметной области, а для каких, конечно, это невыгодно. Рассмотрим это в разрезе сложности выполняемых задач и прогнозируемого (ожидаемого) качества работы.

Если Вы не читали первые 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. Уважайте друг друга!
  2. Стремитесь делать качественно, а не в срок!
  3. Развивайте свои компетенции! 

Тогда любая работа будет приносить удовольствие и результаты!

 

Напомню ранее написанные статьи с общим названием "Ни в ЗУП ногой?!  А мне нравится!":

1. Главные сложности решения, что отталкивает?

Статьи под общим названием "Как читать чужой код?":

Часть 1. Общие вопросы. Доработка чужого кода. Code review.

Статья про роль и значимость архитектора на проекте:

1. Кто такой архитектор. Редакция 2!

Описываем ошибки правильно. Правило трех вопросов

 

Полезные обработки:

Пример работы с файлами odt в клиент-серверной модели работы

Помощник заполнения графиков при вахтовом методе работы

Пакетное создание ведомостей на выплату зарплаты

См. также

Зарплата Учет рабочего времени Программист Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Зарплата и кадры государственного учреждения 3 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Платные (руб)

Обработка предназначена для заполнения нецикличных графиков работы для вахтового метода работы и для работы в полевых условиях труда. Вводятся все виды времени вахтового цикла. Календарь вахтовика позволяет не заполнять индивидуальные графики работы на каждого сотрудника, что сильно снижает трудозатраты на ввод данных. Решение предназначено для ЗУП 3.х; ЕРП 2.х; КА 2.х; ЗКГУ 3.х. Благодаря использованию обычных графиков работы, норму времени можно указать по графику пятидневки.

5400 руб.

18.12.2019    26560    29    6    

28

Кейсы проектов Работа с заинтересованными сторонами Бесплатно (free)

Бывают ситуации, когда обновление изрядно измененной 1С с большой базой не составляет особых трудностей — до определенного момента. Таким моментом становится, например, переход на новую подредакцию. После чего приходит понимание, что обновлять, как раньше — уже не получается и нужно что-то менять.

12.07.2024    597    0    1c-izh    1    

3

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Большинство бухгалтеров привыкли вести учет в конфигурации 1С:Бухгалтерия. Но что бывает, если такого бухгалтера перевести с 1С:Бухгалтерии на ERP? Об основных ошибках бухгалтера после перехода и роли аналитика в том, чтобы помочь бухгалтеру преодолеть трудности и изменить привычные паттерны, пойдет речь в статье.

15.05.2024    4476    0    TanyaRi    69    

26

Внедрение изменений Бесплатно (free)

Эта статья о том, как за годы практики мы в компании выстроили систему проектных подходов по корпоративным внедрениям 1C, и зачем она вообще нужна. Выделю основные проблемы этого процесса, подскажу решения и раскрою внутреннюю кухню нашего подразделения.

15.05.2024    6268    0    cesar    15    

49

Проектирование Анализ предметной области Бесплатно (free)

В девятнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как и для чего применяют DDD, и почему аналитиком важно знать об этом подходе.

13.05.2024    562    0    Radio_Analyst    0    

3

Анализ предметной области Бесплатно (free)

В этой части статьи обсуждается идея о том, что бухгалтерская реальность (AR) строится как научная (математическая) модель хозяйственной реальности (ER), а также рассмотрены общие принципы построения научных моделей.

03.05.2024    885    0    Polav62    9    

4

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Статья об основных зонах внимания и часто допускаемых ошибках при внедрении современных ERP-систем – «1С:ERP Управление предприятием» и «1С:ERP.Управление холдингом».

27.04.2024    2199    0    user893825    0    

17

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    622    0    Radio_Analyst    0    

5
Отзывы
1. biimmap 1987 19.04.23 14:05 Сейчас в теме
Коллеги всем привет!

Эта статья, на мой взгляд, является наиболее интересной в данной серии. Каждый из Вас искал работу или сотрудников.
Статья направлена на улучшение взаимодействия между работодателем и кандидатом.

Если статьи данного цикла наберут много плюсов, напишу 4-ю часть, о проблемах, возникающих в процессе работы.
zemmoloko; PetrovAnton; orientir1C; user1632365; noodlich; cryingboy; AlbinaAAA; Ale-vyb; JohnConnor; гаврюша; forseil; +11 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. biimmap 1987 19.04.23 14:05 Сейчас в теме
Коллеги всем привет!

Эта статья, на мой взгляд, является наиболее интересной в данной серии. Каждый из Вас искал работу или сотрудников.
Статья направлена на улучшение взаимодействия между работодателем и кандидатом.

Если статьи данного цикла наберут много плюсов, напишу 4-ю часть, о проблемах, возникающих в процессе работы.
zemmoloko; PetrovAnton; orientir1C; user1632365; noodlich; cryingboy; AlbinaAAA; Ale-vyb; JohnConnor; гаврюша; forseil; +11 Ответить
6. tolyan_ekb 105 19.04.23 17:11 Сейчас в теме
(1) Мне не очень зашла. Тут как будто рассматриваются вакансии на проект, а не на долгосрок. Почти не раскрыто планирование дальнейшего развития сотрудника и оценка вакансии с этой точки зрения, а это один из весомых аргументов выбора вакансии.
8. biimmap 1987 19.04.23 17:17 Сейчас в теме
(6) На самом деле вакансии, которые использованы в статье долгосрочные!

Что касается не зашла... Может есть потребность посмотреть на вакансии под другим углом? Вы можете написать статью на эту тему и раскрыть другие проблемы вакансий!

Моя цель была раскрыть проблемы с точки зрения универсальности желаемых кандидатов. Собственно как и остальные 2 статьи.

Может для меня не так актуальна проблема развития сотрудника, потому что всегда сам развиваюсь в тех направлениях, которых не хватает в работе.
36. ASchekachev 201 16.07.23 21:19 Сейчас в теме
(1) Павел, приветствую!
Так в большинстве случаев на сайте работ работодатель ищет программистов на поддержку. А на поддержке в большинстве случаев требуются универсальные навыки. При этом они могут быть в каждой из областей средние, не обязательно крутые. Обмен подкрутить, проконсультировать пользователей и желательно по нескольким конфигурациям, что-то допилить и т.д. Когда кто-то уже внедрил методологию, поставил автоматизацию на рельсы (пусть и не на все 100% хорошо), то задачи поддержки они уже требуют другой компетенции. Брать на каждое направление нескольких сотрудников бывает не оправданно, но тут уже нужно исходить из нагрузки на специалиста.
Другое дело, когда компании ищут специалиста, который с нуля внедрит какой-то продукт или переделает за кем-то. Тут, конечно, и ожидания у Заказчика совсем другие, чем от специалиста поддержки и к ЗП как правило вопросов вообще нет, т.к. тут в ограниченный срок нужен конкретный результат. За проектными специалистами Заказчики как правило ходят по рекомендациям или по рейтингу с сайта 1С. Другой вопрос, что рейтинг не всегда показывает реальное положение дел, но Заказчику другого инструмента не дано.
Поэтому на сайтах работ примеры резюме, приведенные в статье вполне объяснимы.
Как итог: На поддержку и на проекты нужны реально разные специалисты и в вакансиях как правило нужны те кто будет поддерживать и развивать, а не с нуля ставить на рельсы.
barelpro; +1 Ответить
37. biimmap 1987 16.07.23 21:48 Сейчас в теме
(36)
Павел, приветствую


Взаимно! 100 лет не пересекались нигде)

(36)
в большинстве случаев на сайте работ работодатель ищет программистов на поддержку


Видать нам звонят разные работодатели))) Самый частый запрос в мой адрес - переделать за кем-то, кто как ты описал, со средними навыками.

Второй по популярности у меня запрос - это реализация сложного функционала.

Третий - проект с нуля.


(36)
Обмен подкрутить, проконсультировать пользователей и желательно по нескольким конфигурациям, что-то допилить


Сопровождение сопровождению рознь! Если говорить о крупных проектах (классификация во второй статье), то там уже побывало много разных команд, все нацелены были на то, чтоб заработать денег, а не на результат. И там такой зоопарк, что середнячку там не разобраться. Один пример проекта сопровождения из моего опыта привёл во второй статье. На старте всё выглядело очень просто, а оказалось...


(36)
Как итог


Какой специалист куда нужен зависит от размера проекта и сложности задачи. Для этого и привёл специально классификацию проектов и задач. С чем точно соглашусь, так это с тем, что специфика внедрения и сопровождения она абсолютно разная.

Себя считаю именно внедренцем, т.к. терпеть не могу мелкие задачи.
40. пользователь 15.07.24 21:05
Сообщение было скрыто модератором.
...
2. sapervodichka 6865 19.04.23 14:42 Сейчас в теме
Бо диа, Павел! А где обещанная визуализация? (схемы, таблички и ментальные карты - ведь сейчас люди не читают, а просматривают, а взгляду не за что зацепиться)
3. biimmap 1987 19.04.23 14:59 Сейчас в теме
(2) Эта статья написана ещё в январе. И честно тебе скажу, что вот в третьей части совсем не вижу способа визуализации информации.

У меня даже в презентации на конференцию только пару смешных картинок было вставлено и всё.
Вот вторая статья, там да можно сделать схемы для классификации проектов и задач. Но прям сейчас занят сильно.

Так что это на будущее!
4. gybson 19.04.23 16:42 Сейчас в теме
За 15-20 лет стажа можно всяким фокусам обучиться. Вообще некоторые вакансии больше на мою специализацию похожи - интеграцию, а там надо знать кроме обменов и продукты, которые обмениваются. Может не до тонкостей, но и не поверхностно.
9. biimmap 1987 19.04.23 17:20 Сейчас в теме
(4)
Может не до тонкостей, но и не поверхностно


в том и дело, что компетенция обмена данными должна поддерживаться компетенцией по конкретному продукту. А не по принципу, раз ты с ЗУПом работаешь, то все интеграции - это тоже твоя работа.

На мой взгляд максимально правильно, когда набор данных выдает разработчик со знаниями конкретного решения, а обмен пишет разработчик, который специализируется на разных форматах передачи данных.
5. tolyan_ekb 105 19.04.23 16:51 Сейчас в теме
Зачем проходить полиграф, чтобы понять его бесполезность? Я сразу, еще у hr, спрашиваю есть он или нет. Если есть - до свидания, сразу понятна атмосфера "взаимопонимания и доверия" в организации, а также ее "чистоты" процессов в самой организации.
user1706724; user_2010; PetrovAnton; d4rkmesa; salbey; biimmap; ubnkfl; +7 Ответить
7. biimmap 1987 19.04.23 17:12 Сейчас в теме
(5) Классный комментарий!

На тот момент отсутствовал такой опыт. Ну и в моей то голове "я ж честный!". Теперь у меня точно такое же табу на всякую чушь.
user1706724; PetrovAnton; NikieMSE; +3 Ответить
10. Dmitry77 83 19.04.23 17:59 Сейчас в теме
Банки это вещь в себе, если там нет опыта работы с зупом, то открытий много.

По остальному - большая часть верно.

Полиграф и тестове более чем на 2 часа не беру.
На самом деле тестовое, оно и для работодателя тоже, ибо неадекватное тестовое = неадекватный работодатель.
d4rkmesa; biimmap; +2 Ответить
13. mikl79 119 20.04.23 13:45 Сейчас в теме
(10), В одном собеседовании про полиграф тоже спрашивали - согласился, чисто из интереса.
Но потом они пропали, не знаю почему - полиграфа нет в моем городе.
Теперь понял - если его проходить, то с обратной связью - в случае отказа пусть пояснят, что не так.
Хотя конечно - работа должна строиться на доверии!!!
Опять же есть испытательный срок.
Недавно было тех.собеседование - технические вопросы нормальные, но и куча логических задачек (зачем я не понял).
Около часа это все.
А потом еще тестовое задание делал - 3 функции написать + 3 процедуры разобрать на ошибки.
Больше часа вышло.
Наверное действительно нужно отказывать - больше 1-2 часов не готов тратить на тех.собеседование + тех.задание.
Выбирайте что-то одно.
maksa2005; d4rkmesa; biimmap; +3 Ответить
11. John_d 5764 20.04.23 09:30 Сейчас в теме
По факту работодателю нужны "универсальные солдаты". Один ушел в отпуск, другой заболел, третий уволился, но работа не стоит все их обязанности ложатся на плечи коллег "универсальных солдат".
maksa2005; +1 Ответить
12. biimmap 1987 20.04.23 09:44 Сейчас в теме
(11) Смотря о каком размере проекта Вы говорите...

Моя цель показать, что такие коллеги не обладают нужными компетенциями для решения некоторых задач.
14. mikl79 119 20.04.23 13:55 Сейчас в теме
еще хотел бы добавить - уважаемые работодатели находите время на обратную связь (даже если отказ) - как говорится "ваше мнение очень важно для нас"
15. CheBurator 3126 20.04.23 14:38 Сейчас в теме
в далеком 1999г я сдал экзамен по ЗиК. спецтиализировался по этому направлению года полтора-два, потому что объяснять бухгалтерам тонкости ТК, НК, ГК - задолбало (в той части что сам наблатыкался), полная некомпетентность встречалась (бо компании в основном маленькие). Часа два колупаешься - "итог: у вас не идет потому что вы матпомощь не учли как необлагаемую" (условно), с вас 30$" - "А с чего это 30$ выже ничего не сделали" - Проблема была? Была! Проблема снята? Снята! а как я ее снял - делал я что-то или не делал - околоптиц! Так что в итоге заколебался я и перестал по ЗиКе работать... Сертификат до сих пор дома лежит ;-) Продам, может, как раритет ;-)
user1706724; graphbuh; +2 Ответить
16. biimmap 1987 20.04.23 15:13 Сейчас в теме
(15) Я с ЗиКом работал только с точки зрения перенос данных в ЗУП 2.5. Для меня это также непонятный монстр с его глобальными процедурами.

В ЗУПе то такие вопросы проще решаются. И решаются они уже не программистами, а аналитиками/консультантами.
18. graphbuh 260 25.04.23 10:33 Сейчас в теме
(15)
сдал

Да к этому надо иметь склонность. Вот один мой коллега с хорошей памятью ставил бухгалтеров в тупик вопросом,"... а вы налоговый кодекс читали...?" Цитировал им наизусть пару - тройку параграфов и дальше они подписывали любые счета...
user1706724; biimmap; +2 Ответить
17. пользователь 21.04.23 10:16
Сообщение было скрыто модератором.
...
19. tamepjlah 3 26.04.23 12:26 Сейчас в теме
До прочтения ваших статей я считал себя неплохим ЗУПером...
user1706724; MoiseevSN; biimmap; +3 Ответить
20. biimmap 1987 26.04.23 13:30 Сейчас в теме
(19) Укатился под стол от этого коммента)

Если всерьёз то статьи и написаны, чтоб был понятен вектор развития, и собственно что надо развиваться. Благодарю за комментарий.
21. sevushka 303 27.04.23 07:46 Сейчас в теме
Не увидел главного, где границы применимости всех этих пожеланий?
Для примера. Берем фирму, где для ЗУПера нет загрузки 8/5, а есть задач - ну пусть на 2 недели в месяц. А остальное время они хотят что-то другое (из ваших же примеров - БП, отраслевое, интеграции и пр). ИМХО - вполне логично, пусть это делает ЗУПер, пусть хуже, чем специализированные программисты, но лучше, чем просто так сидеть.
Соответственно, что должен знать/делать ЗУПер в фирме до 1 тыс сотрудников, до 5 тыс, до 15 тыс? (ну либо - любая другая градация).
Соглашусь, что для холдингов в десятки тысяч сотрудников, выделенный ЗУПер нужен, и даже не один.
22. biimmap 1987 27.04.23 10:40 Сейчас в теме
(21) Вы пишете про мелкий бизнес (во второй части статьи есть классификация проектов и задач). Там и задачи попроще и да их меньше!

Статьи же больше про серьёзные проекты. Там и возникают основные проблемы из-за отсутствия выделенной компетенции у сотрудника.
23. karpik666 3802 27.04.23 19:18 Сейчас в теме
Я так и не понял в конце, у тебя получилось найти работу или нет?
user1706724; +1 Ответить
25. biimmap 1987 27.04.23 19:39 Сейчас в теме
(23) Вроде бы не безработный))) пока...
26. karpik666 3802 27.04.23 20:02 Сейчас в теме
(25) это хорошо, когда компания соответствует всем нужным требованиям, главное еще, чтобы и уровень дохода был соответствующий.
28. biimmap 1987 27.04.23 20:06 Сейчас в теме
(26)
чтобы и уровень дохода был соответствующий


здесь 2 простых принципа:
1. не торгуюсь)
2. бесплатно не работаю.
karpik666; +1 Ответить
24. karpik666 3802 27.04.23 19:32 Сейчас в теме
В частности по поводу того, что работодатель ищет обычно коктейль из компетенций, и на этом еще пытается сэкономить - соглашусь, однако такого сферического работодателя, который предложит тебе именно вакансию мечты (когда нужны только компетенции по ЗУП или твои технические скилы, и нужно работать только над технической проработкой проекта ) - нет или они настолько редки, что их по пальцам одной руки фрезеровщика можно пересчитать
По поводу того, что программист можно писать на любой конфигурации - отчасти соглашусь, чем ниже компетенция программиста, тем больше ложится ответственность на аналитика и проработку технического задания, и дальнейшее его тестирование. Конечно ЗУП, и в особенности его 3-я версия имеют особые требования к скилам (механизм представлений, понимание как работают менеджеры расчета и т.д.), однако если запустить хорошего программиста в незнакомую конфигурацию, то вначале он будет изучать типовой код, а только потом писать свой, это будет дольше, но так и появляются навыки работы в новой конфигурации, не только из теории.
Из указанной работы "мечты" - больше складывается ощущение, что нужно идти в какую-нибудь большую контору, обслуживающую 1С, типо того же Первого Бит, где уже есть большой спектр компетенций разделенных на специалистов, и когда вот такие вакансии, что должны совмещать в себе несколько профессий легко переходят в оценку часов на проект, часы которого уже делятся между компетентными сотрудниками "Аналитик", "Архитектор", "Программист", и при этом не нужно быть человеком-оркестром, применяешь только свои скилы, но они будут разделены между проектами.
27. biimmap 1987 27.04.23 20:04 Сейчас в теме
(24) Знаешь, вот только сегодня (27.04) прилетало предложение побыть одновременно РП, архитектором и разработчиком. Надо ж сочетать сочетаемое! А не селёдку молоком запивать)


(24)
чем ниже компетенция программиста, тем больше ложится ответственность на аналитика и проработку технического задания, и дальнейшее его тестирование.


Именно против этого и выступаю! Я сам уже разработчик 20 лет, а ТЗ до сих пор не видел ни одного) Имею ввиду для меня написанного. Всегда всё приходится изучать, проектировать и разрабатывать. ЕКШ я делал с такой постановкой: "Павел нам нужно внедрить Единый Корпоративный Шаблон". И всё!
29. karpik666 3802 27.04.23 20:07 Сейчас в теме
(27) мне кажется с годами работа должна быть для души, у самого в какой-то момент пропала желание кому-то что-то доказывать, не хочется бороться с ветряными мельницами, нужны только единомышленники
30. biimmap 1987 27.04.23 20:41 Сейчас в теме
(29) Поэтому и начал писать статьи и выступать на конференциях. Хочется познакомиться с бОльшим количеством единомышленников и избавиться наконец-то от токсичных проектов. Хотя до сих пор в таком участвую (но тут есть свой плюс подогревающий интерес).
39. пользователь 15.07.24 20:57
Сообщение было скрыто модератором.
...
41. biimmap 1987 15.07.24 21:18 Сейчас в теме
(39) вот в комментариях мне ещё ни разу не предлагали работу. Стоит стереть номер телефона из комментария.
42. YA_20290385 15.07.24 21:29 Сейчас в теме
(41) к сожалению изменение уже закрыто - не могу стереть номер телефона
31. Сисой 87 04.05.23 12:21 Сейчас в теме
Отличная статья!
Полиграф тоже проходил один раз, после чего дал себе слово посылать таких ипанутых на голову работодателей сразу далеко и надолго (если это не ФСБ, конечно, этим можно).
От тестов более чем на 15 минут тоже отказываюсь. Мое время стоит дорого.
А вот где засада - в очень многих неплохих по зарплате и соцпакету конторах нынче ненормированный рабочий день в ТД.
И при необходимости тебя припашут так, что про 8 часов забудешь на месяцы.
Напомню, что действующий ТК НИКАК не ограничивает в этом работодателя, есть постановление ВС РФ.
Перед СВО хотели внести в ТК поправки, лимитирующие объем работ за пределами нормы, но потом по понятным причинам их выбросили в мусорную корзину.
32. biimmap 1987 04.05.23 15:24 Сейчас в теме
(31)
Отличная статья!


благодарю


(31)
ненормированный рабочий день в ТД


там не всё так просто! Для начала, должен быть доп. отпуск дополнительный. Его дают 3 дня, но можно поторговаться!
Никто не отменял правило, что для привлечения к работе сверх нормы должен быть приказ! Может ты с лестницы свалишься, и инвалидом станешь! А какого чёрта ты после 18.00 делал на работе на той самой лестнице?! Чем внимательней в этот вопрос вникаешь, тем интересней становится!

и, как минимум должны предоставить время отдыха в любое удобное для тебя время! Надо просто уверенней говорить с работодателем, тогда и условия будут лучше.
33. Сисой 87 04.05.23 19:30 Сейчас в теме
(32) да, у нас 5 дней доп.отпуска
Есть разъяснение ТИ, что приказы не нужны, достаточно устного распоряжения, но нужно вести журнал учёта.
34. biimmap 1987 04.05.23 23:16 Сейчас в теме
(33) Много журналов извели?)))
35. MoiseevSN 100 23.05.23 13:40 Сейчас в теме
про 8 часов забудешь на месяцы.

да но это не более 120 часов в год, и 3 и более дней к отпуску...
Иначе. это уже рабство называется)
38. Torin57 7 26.07.23 17:23 Сейчас в теме
Павел, доброго дня.

Абсолютно нормально поручать разработку интеграционных механизмов на любых проектах начинающим и универсальным солдатам. Необходимо лишь указать источники данных. В задачах повышенной сложности можно поручить опытному разработчику получение специфических данных.

Необходима расшифровка о чем речь. Если нужно взять обработку-шаблон загрузки из эксель и допилить ее под загрузку подразделений в документ "Начальная штатная расстановка", то тогда понятно.
А если нужно написать подсистему обмена данными на основе http-сервиса, то универсальный солдат не справится. Чтобы там был план обмена и удобный журнал в котором можно посмотреть подробно, например, какие данные пришли в ЗУП и отправлены в битрикс.
Оставьте свое сообщение