Ссылки на остальные части:
Я - ЗУПер! Часть 2. Классификация проектов и задач.
Для лучшего понимания данной статьи хочу описать причины появления данной статьи:
1. За последний месяц мною было пройдено 2 собеседования с очень крупными компаниями. Оба собеседования закончились отказом. В одном случае требуется работа с Бухгалтерией, в другом случае нужно быть ещё и руководителем.
2. Изучая вакансии, всё чаще натыкаюсь на вакансии, где требуется то Бухгалтерия, то Документооборот, то вообще пишут: "Требуются навыки администрирования". Т.е. без навыков администрирования Вы - так себе ЗУПер!
3. Среди IT директоров укоренилась невероятно ужасная фраза: "Программисту всё равно где кодировать, язык программирования от этого не меняется. Главное - хорошо написанное ТЗ". Эту фразу разберу ниже отдельно на составляющие.
4. За 20 лет своего опыта хорошо насмотрелся на акушеров-сантехников широкого профиля, чётко знаю, какой результат от их работы. Это касается даже опытных коллег, которые в своём основном решении задачи выполняют на отлично.
В дальнейшем вместо "акушер-сантехник широкого профиля" будем использовать понятие "универсальный солдат". Это понятие хорошо иллюстрирует картинка к данной статье)
Разобравшись с причинами, стоит наметить цели, которых можно достичь:
1. Рассказать об объёме знаний в своей предметной области, который должен быть у сильного разработчика. (Часть первая)
2. Донести до потенциальных работодателей потенциальный риск набора универсальных солдат.
3. Для ответа на вопрос: "Для кого плохо?", составим классификацию проектов и решаемых задач. (Часть вторая)
4. Рассмотрим проблемы, возникающие при трудоустройстве. Какие ошибки делают работодатели и соискатели? Как их исправить? (Часть третья)
5. Рассказать аудитории читателей данного материала о плюсах специализации на одной предметной области.
6. Побудить коллег, прежде всего руководящий состав, при выполнении проектов думать не только о прибыли, но и о качестве!
Рассказ на основе реального опыта (Часть четвертая).
7. Рассмотреть разницу в уровне знаний разработчиков с "одинаковым" набором заявленных в резюме компетенций.
Что должен знать программист в своей предметной области?
Рассмотрим сначала этот вопрос без привязки к какой-то конфигурации:
1. Понимание бизнес-процессов, происходящих на предприятии
Рассмотрим в качестве примера металлургический завод, на котором мне довелось начать работу ровно 10 лет назад.
Посмотрим на работу одного кузнечного цеха, но с разных сторон. Оценим процесс получения готовой продукции со стороны 4-х предметных областей:
а. Производственный учет
б. Складской учет
в. Расчет сдельной оплаты труда.
г. Финансовый учет
Как делается одна деталь? Процесс выглядит так:
- На предприятие поступает заказ от покупателя. Иногда поступает готовый чертёж, иногда его требуется разработать.
- Конечно же без договора с покупателем никакой заказ поступить не может.
- Т.к. ничего так не сближает как предоплата - возникает авансовый платёж.
- После готовности чертежей, готовится спецификация. Это огромная технологическая карта, в которой учтены все мельчайшие подробности процесса производства
- В производстве любых металлических изделий, процесс начинается с плавки. Напомню, то мы смотрим только кузнечный цех. Значит у нас появляется на входе либо полуфабрикат, сделанный в другом цеху, либо давальческое сырье.
- Сколько процессов нужно сделать, чтоб получить полуфабрикат - одному Богу известно! Это десятки процессов!!!
- Приняли заготовку на склад цеха.
- Теперь нужно спланировать процесс её превращения в готовое изделие согласно технологической карте. Т.е. планируем людские ресурсы, и на каком оборудовании и в какую смену будет выполняться работа.
- Формируется сменное задание. В нём нужная нам деталь - лишь одна из строк).
- Мастер в цеху назначает бригаду исполнителей.
- Бригада исполнителей устанавливает нужную пресс-форму на определенный молот.
- Бригада исполнителей выполняет указанный в сменном задании объём.
- Контролируется качество работ, фиксируется брак в производстве (исправимый и не исправимый!).
- Фактические результаты заносятся в сменное задание.
- На основе фактических результатов полученная готовая продукция (или очередной полуфабрикат) поступают на склад цеха.
- Готовая продукция отгружается на склад готовой продукции.
- По фактическим результатам работы рассчитывается сдельная оплата труда (здесь стоит умолчать о наличии 15 вариантов расчета сделки!).
- Продукция отгружается покупателю.
- Поступает оплата за отгруженную продукцию.
Наверняка возникает вопрос: зачем всё это описано? ведь среди нас нет металлургов!?))) А вот зачем...
Задайте себе вопрос: "А может ли всё это знать один человек??? Может ли он сам автоматизировать описанный процесс???"
В описанном процессе на предприятии реальном участвует примерно 50 человек реальных исполнителей. Т.е. чтобы их работу автоматизировать, необходимо понимать работу каждого из этих 50 человек. Это реально???
Я, как узкоспециализированный человек (ЗУПер), выберу из этих бизнес-процессов свои:
- На этапе подготовки спецификации используется информация:
- С составе бригады по операциям
- О стоимости часа работы каждого из специалистов
- О норме времени для обработки определенного объёма (веса) полуфабриката
- На основе этой информации рассчитывается вклад зарплатной составляющей в себестоимость продукции.
- При планировании людских ресурсов необходимо учесть требования к квалификации работников бригады, т.е. эти данные должны быть в ЗУПе!
- При выборе смены и формировании бригад, должна быть информация о графиках работы и отсутствующих сотрудниках.
- При контроле качества определяется, по какой стоимости будет рассчитана сделка: готовая продукция - одна цена, исправимый брак - немного ниже, неисправимый брак не оплачивается! Конечно это делает не контролёр качества) Эти данные учитываются при расчете
- В момент расчета сдельной оплаты труда нужна следующая информация:
- Фактическая выработка
- Расценки
- Фактически затраченное время
- КТУ по работникам
Для чего написан этот абзац? Он написан для того, чтоб было понятно, что мне как ЗУПеру остальные процессы вообще не интересны!!! Мне всё равно, откуда берутся полуфабрикаты, оплатили их или нет, откуда взялось оборудование, на котором всё это делается, отгрузили готовую продукцию или выкинули её... МЕНЯ ЭТО НЕ ИНТЕРЕСУЕТ!
А раз все эти процессы вне сферы моих интересов, то невозможно качественно выполнять задачи, направленные на автоматизацию этих процессов!!!!
2. Знание законодательства
Возьмём для примера задачу по расчету налогов. Ничего ж необычного? Ну и укажем налоги которые надо рассчитать: НДС и НДФЛ. У них даже 2 первые буквы совпадают!
Надо ли пояснять, насколько разные знания, вообще никак не пересекающиеся, нужны для расчета этих налогов?
Это как называть одним словом "врач" окулиста и стоматолога! Ведь и один и другой учились в медицинском... Все ж понимают, что на должность стоматолога окулистов не ищут?
Окулист-то врач безобидный, ну выпишет Вам капельки от кариеса, и всё! А вот если стоматолог катаракту с кариесом спутает и депульпирует глаз - будет не очень весело)
Так почему возникает желание найти программиста со знанием ЗУП и БП?!
Это абсолютно разные предметные области, которые пересекаются только в одной фразе: "Проводки по зарплате и налогам". И больше нигде они не пересекаются! И это пересечение совсем не говорит о том, что программист должен знать тонкости по учету основных средств, или уметь правильно писать запросы к регистрам бухгалтерии.
На остальные вопросы посмотрим с другой стороны забора, когда на задачи по ЗУП кидают людей из БП, УТ, УХ, ЕРП.
3. Понимание печатных форм и отчетов, сопровождающих каждый бизнес-процесс
Что может быть проще, чем доработка печатных форм?! Верно? НЕТ! Для ЗУПа даже задача по печатным формам сложная.
Все ж привыкли, что печатная форма либо в документе, либо в общих макетах.
Разработчики ЗУПа - люди с фантазией! Поэтому они собрали все печатные формы в несколько обработок) И искать их в документах - это пустая трата времени!
И вот откуда может знать об этом человек, который работает с другими конфигурациями? Аналогичные приколы есть в каждой конфигурации!
И только опыт работы с одним решением позволяет быстрее ориентироваться в коде конкретной конфигурации.
В доработке отчетов ведь тоже ничего сложного!? Если Вы так думаете - посмотрите отчет штатная расстановка или среднесписочная численность. Или попробуйте сделать новый отчет, используя механизм представлений! Да, есть целый специальный механизм для формирования отчетов на компоновке. И писать запросы напрямую к регистрам считается неверным подходом. Как Вам такая информация? Уверен, когда столкнётесь на практике с описанными механизмами - Вам обязательно понравится, особенно если с ЗУПом Вы не так часто работаете!
4. Понимание архитектуры решения, вариантов настройки системы
Чтобы было всем понятно, на сколько важен данный пункт, расскажу про свой опыт работы в отделе разработки ЕРП в фирме 1С.
В 2017 году мне довелось там работать. Продержался недолго - 4 месяца. Сразу скажу, что с позиции работодателя этот опыт не является успешным.
С моей позиции опыт был невероятно полезен. В процессе рассказа не стану описывать плюсы и минусы работы в 1С. Опишу только почему у меня не зашло, какие факторы повлияли.
Для начала стоит написать, почему ЗУПер оказался в отделе ЕРП!? Изначально меня рассматривали в отдел ЗУП. Но я ж не мог не рассказать об успешном опыте автоматизации расчета сдельной оплаты труда на металлургическом предприятии! Руководитель отдела (ЗУП) предложил провести собеседование с ещё одним руководителем отдела (ЕРП).
Пока мы общались, выяснилось, что мой опыт интересен. Договорились попробовать. В отдел ЕРП нужен был сотрудник, который решает задачи на стыке двух подсистем: БЗКР (Библиотека Зарплата Кадры Расширенная) и Управление Предприятием. Это связано с наличием в ЕРП бухгалтерских документов и момент регистрации некоторых событий не совпадал с ЗУПом.
Самое интересное в этом опыте было полное отсутствие опыта работы с ЕРП! Со своей стороны предупредил руководителя, что ни разу не запускал ЕРП!
И вот пришёл я на работу и дали мне задачу на испытательный срок. Для человека, знающего ЕРП задача не такая уж и сложная. Нужно было в платежных документах изменить принцип заполнения некоторых реквизитов. Ранее заполнялись в шапке, необходимо сделать в табличной части. А где же тут нужны знания зарплаты?! Изменения должны произойти для зарплатных видов операций, и должны измениться некоторые движения по налогам.
Получается, что вся задача должна решаться в подсистеме КАЗНАЧЕЙСТВО! И вот моя первая отмазка: я не знаком лично ни с одним казначеем! Расчетчиков знал человек 30, кадровиков далеко за сотню, а казначеев НОЛЬ!
Вспоминаем, что ранее говорил: ни разу не запускал ЕРП. Добавляем к этому отсутствие знаний в предметной области казначейства... Как думаете, реально решить такую задачу!? Реально! НО за 3 месяца, вместо одного положенного)))
Итого мне пришлось разобраться в:
-- Предметной области Казначейство с нуля. Разбирать пришлось целую подсистему, т.к. моя доработка затрагивала очень много сценариев.
-- В реализации примерно 5 типовых документах
-- Изучил примерно 20 регистров, связанных с этими документами
-- Подходы к разработке типовой конфигурации. Было много особенных подходов, которые не связаны со стандартами разработки. Например, управление видимостью реквизитов документов указанной подсистемы. Это делалось через условное оформление) Необычно, правда? Я то искал Видимость = Истина...
-- СППР. Для людей, работающих с ЕРП это обычное дело...
-- Нотацию IDEF0 и её реализацию в СППР. Это было прям очень забавно) Потратить почти неделю на что-то можно сказать элементарное.
-- Ещё одна фишка - обрамление кода специальными комментариями НЕ УТ, НЕ КА, НЕ УТКА. По ним определяется, в состав каких конфигураций должен попадать твой код.
В итоге задачу, я конечно же решил, причём довольно качественно, замечания как по коду, так и по сценариям были незначительными. Но оказался не эффективным сотрудником! С этой формулировкой я и не прошёл испытательный срок.
Поэтому, если Вы надумаете решать сложные задачи в другой конфигурации - будьте готовы изучить огромный пласт новой информации. Главное в этом - найти источник информации) Поверьте опыту - это не просто!
Если Вы - работодатель, стоит прям хорошенько заложиться на выполнение этой задачи по сути новичком с опытом программирования.
Ещё раз повторюсь: для меня это был суперский опыт! За 4 месяца получил опыта лет на 5! + выучил стандарты и научился их применять, что немаловажно! Увидел изнутри, как устроен процесс разработки типового решения. Здесь сразу прошу не просить в комментах что-либо рассказать, т.к. это коммерческая тайна, у меня подписан документ, который действует бессрочно. Описанные ранее особенности известны всем.
5. Знание подходов к автоматизации учета конкретной предметной области
В целом то о чём расскажу можно пояснить одним предложением: "Как решить задачу так, чтоб сдать экзамен "Специалист" или "Специалист-консультант" по какому-то решению".
Многие рассуждают о том, а надо ли сдавать этот экзамен, какая от него практическая польза... Говорят, что в зарплате от этого не прибавится и т.д.
Так вот: точно ОБЯЗАТЕЛЬНО надо его сдать. Ведь это один раз отмучиться и всё. Но цель-то моя - не реклама экзамена...
Сдать его нужно, чтоб понять следующие моменты:
- Какие задачи (типовые) встречаются в той конфигурации, к которой идёт подготовка.
- Как вендор видит правильный путь решения по типовым задачам.
- Как вендор рекомендует использовать объекты метаданных для выстраивания пути решения задачи.
- Сценарии, заложенные вендором в типовые механизмы.
Из написанного напрашивается простой вывод: подготовка к экзамену позволяет быстрее изучить возможности типовой конфигурации!
НО! Многие, почему-то, сдав экзамен, считают, что дальше развиваться не надо! Я ж теперь специалист(-консультант)!?
Это главная проблема всего мира 1С!!! Наличие сертификата не делает Вам специалистом!!!
Только опыт работы на проектах позволит Вам им стать!
Как только Вы сдали экзамен, у Вас появился всего лишь допуск к работе. Вас так сказать отправили дальше стажироваться у работодателя.
Продолжительность Вашей стажировки примерно 5-7 лет! Во время стажировки Вам нужно постоянно грызть гранит науки!!!
И только через 5-7 Вас можно назвать специалистом, если на работу Вы ходили работать, а не за окладом!
Можно сравнить это со сдачей экзамен на права. Никто ж из Вас не считает себя супер водителем после экзамена в ГАИ!?
В лучшем случае - ты чайник, а скорее всего водятел! (тут уж без обид, я тоже таким был 20 лет назад).
Сдав экзамен и получив права Вы всё равно не знаете как ездить по трассе. А всё почему?! Потому что учебная езда по трассе раньше была запрещена)))
Точно также и с 1С: подготовился к экзамену, успешно его сдал, а всё равно ещё много чего не видел/не слышал.
Поэтому обязательно продолжайте своё обучение. Чек-лист того, что нужно изучить описан и в этой статье и в серии статей под общим названием "Ни в ЗУП ногой!?..."
Приведу несколько примеров, какие подходы к решению задач есть в области ЗУП:
- Идут вечные споры о том, можно ли в ЗУП 3 не использовать Штатное расписание и Табель учета рабочего времени.
Моё мнение в этом вопросе однозначное, без всяких "но" и "если"! Оба механизма нужно использовать! Почему у меня такое мнение:
-- Хорошее знание бизнес-процессов советует вести штатное расписание (ШР), т.к. это упрощает заполнение кадровых приказов. В ШР можно заранее указать оплату труда, условия труда, отпуска... на одну позицию принимают обычно несколько человек. Отсюда вытекает один из главных моих принципов работы:
Один раз ввести информацию и много раз использовать! Главное, не делать наоборот)
-- С точки зрения ведения табеля методом отклонений... Так сложился мой опыт, что много раз приходилось дорабатывать алгоритмы, связанные с отработанным временем. Изучая код этих алгоритмов, становилось понятно - если не ввести табель, половина сценариев не отработает. На аттестации ничего об этом не говорят. Только опыт даёт такое понимание. Все ж в курсе, что печатный табель учета рабочего времени по форме Т-13 хранят минимум 5 лет. Для вредных условий труда это 50 или даже 75 лет! Получается, что табель надо набить в Excel!? Анализируя эту информацию я сформулировал ещё один принцип своей работы:
Весь учет должен вестись в рамках ОДНОЙ информационной системы! Т.е. не нужно делать что-то в Excel или Word, как многие это любят. Нужно всё автоматизировать.
Не нужно для ведения кадрового учета и расчета заработной платы использовать разные системы! Нужно уволить главбуха и директора по персоналу, а новых заставить работать в единой системе! В таких ситуациях сложно объединять такие данные. На текущем проекте (на 2022 год) мне приходится собирать данные из Access, и нескольких баз УПП. Приводить в нормальное состояние организационную структуру и кадровые приказы, и только потом переходить на ЗУП 3.1.
Но это не значит, что я не признаю наличия дополнительных информационных систем.
На одном из проектов выносил табельный учет в отдельную самописную базу. Это позволило убрать из рабочей базы ЗУП примерно 1000 пользователей! А с ЗУПом был настроен двусторонний обмен. Главное, что пользователи не вносили одни и те же данные в несколько информационных систем.
Если организация использует СКУД, то неизбежно наличие стороннего ПО. Также необходимо обязательно настроить интеграцию с 1С.
- Часто сталкиваюсь с ситуацией, когда печатные формы приказов, трудовых договоров и дополнительных соглашений отдел кадров печатает вне 1С. Здесь всё просто:
Все печатные формы должны быть автоматизированы. Исключение можно делать либо редким печатным формам, либо тем, которые в системе не имеют документа, на основании которого их можно напечатать. В качестве примера можно привести приказ об отмене командировки, или о смене ФИО. Они и редки и в системе нет таких документов. Отмена командировки в ЗУП - это просто отмена проведения документа командировка. Смена ФИО - ручной ввод данных через карточку физического лица в регистр сведений.
Подобных примеров можно привести ещё очень много... И все эти примеры, подходы и принципы к работе появляются только с годами.
6. Знание сценариев работы выбранного программного обеспечения (даже если это не 1С)
Особо расписывать данный пункт нет смысла. Описанный опыт работы в 1С даёт представление о чём идёт речь.
Многие сценарии связаны с предметной областью или законодательством. Такие знания сильно упрощают работу в любой предметной области/конфигурации.
Но есть такие сценарии, о которых мало где говорят или пишут. К примеру при переходе с ЗУП 2.5 на ЗУП 3.1 коллеги зачем-то пишут правила/обработку для переноса штатного расписания. Одновременно с этим нужно ещё созданные позиции штатного расписания внести в кадровые приказы.
Но ведь переносить кадровые приказы нужно с выключенной функциональной опцией "Использовать штатное расписание". А уже когда кадровые приказы и сотрудники перенесены и проведены, тогда опцию надо включить. В момент включения опции автоматически создаются позиции штатного расписания (элементы справочника "Штатное расписание") и ссылки на них заполняются во всех кадровых приказах. Механизм работает довольно стабильно!
У него конечно есть недостаток: не переносятся вакансии! Но давайте объективно смотреть на вещи... Сколько вакансий на предприятии с численностью пусть 5000 человек? Примерно 100. Но из этих ста для 70 вакансий есть уже созданные позиции. Получается остаётся создать 30 позиций штатного расписания и для 70 позиций увеличить количество ставок. Это работа на 1 день! Написать перенос штатного расписания с вакансиями займёт не меньше недели! И кто сказал, что это пройдёт без ошибок?!
Когда концентрируешь своё внимание на одной предметной области, появляются вот такие знания, которые позволяют серьёзно экономить время.
7. Понимание специфических алгоритмов конкретной конфигурации
Рассмотрим этот пункт, исходя из заблуждения: "Программисту всё равно где кодировать, язык программирования от этого не меняется. Главное - хорошо написанное ТЗ".
Приведу примеры из разных предметных областей, но, конечно же с упором на ЗУП.
- Рассмотрим процесс закрытия месяца в бухгалтерии. Страшно!? Для многих разработчиков ответ утвердительный! Я вот понятия не имею как это работает. Если вдруг прилетит задача по закрытию месяца в бухгалтерии, у меня уйдёт целая вечность на первичный разбор этого механизма. А вот знающие люди потратят на это несколько часов, иногда дней. Зависит от сложности задачи.
- Закрытие месяца в ЕРП ещё более сложная задача. Просто для того, чтоб ввести контрольный пример, нужно знать последовательность действий в крупную и на каждом шаге знать сценарии работы. Далёкий от этого процесса разработчик наверняка не справится.
- Рассмотрим более простые задачи: какие-то обработки, которые каким-то образом преобразовывают данные. Абстрагируемся от предметной области. Вам пишут в ТЗ: Получить список элементов справочника/записей регистра. С полученным набором данных произвести такие-то действия... Это практически повседневная задача. НО! Как понять, что полученный набор данных является полноценным? Явно здесь не хватит одного описания. Уже нужен опыт и знания сценариев по конкретным объектам метаданных! Как убедиться, что действия, которые выполняет обработка не навредили информационной системе в целом? Опять нужны специальные знания!
Сейчас очень популярно вести разработку на основе ТЗ от аналитиков. Надо ли напомнить, что аналитик - это не программирующая боевая единица! У него есть ценные знания: предметная область и знание пользовательского инструмента. Но знания об архитектуре решения, о подходах к разработке и прочим прелестям типовых конфигураций отсутствуют.
Именно поэтому разработчик должен тоже иметь знания о предметной области и сценариях работы. Чтоб наложив на ТЗ от аналитика свои скилы сделать разработку по всем канонам, подсказать аналитику упущенные сценарии. Ведь многие сценарии работы видно только в коде!
Получается, что не всегда ТЗ помогает прийти к качественному результату!
Вернёмся к всеми нелюбимому ЗУПу:
- Поможет ли УТшнику хорошо написанное ТЗ на разработку отчета на основе механизма представлений!?
- Или может ЕРПшник может взять и доработать Менеджер данных учета времени сотрудников?
- Или БПшник сможет исправить ошибки в расчете НДФЛ и страховых взносов!?
- Много ли разработчиков хорошо знают назначение виртуальной таблицы регистра расчета "Фактический период действия"? Есть те кто занимается бухгалтерией и может объяснить на примерах как она формируется?
- Как насчет использования программного интерфейса ЗУП для получения кадровых данных, расчетной базы, отработанного времени и прочих данных. В ЗУП нельзя напрямую писать запросы к регистрам! Зачем!? Ведь уже есть отлаженные запросы выдающие корректный результат.
Невозможно по многим задачам в моей предметной области написать задание, которое сможет выполнить любой разработчик! Нужно знать особенности и назначение этих алгоритмов!
Я вообще считаю, что любая задача в ЗУП - это творческая задача. Нужно найти способ ничего не сломать, внося свои доработки в специфичные объекты метаданных. Сам почти половину времени трачу именно на поиски такого волшебного способа. Конечно, с опытом формируются какие-то подходы/лайфхаки при решении задач.
Уверен в том, что в остальных предметных областях также есть специфичные алгоритмы, при доработке которых требуется специфичный опыт и знания. Конечно, есть исключения из правил! Их рассмотрим далее. Также рассмотрим какой пласт задач могут выполнять универсальные солдаты.
Применительно к конфигурации ЗУП, этот вопрос более подробно описан в статье:
Ни в ЗУП ногой!? А мне нравится! Часть 1. Главные сложности решения, что отталкивает
В первой статье получилось раскрыть только первую цель. А значит, скоро будет продолжение! В нём раскроем остальные цели.
Напомню ранее написанные статьи с общим названием "Ни в ЗУП ногой?! А мне нравится!":
1. Главные сложности решения, что отталкивает?
Статьи под общим названием "Как читать чужой код?":
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Статья про роль и значимость архитектора на проекте:
1. Кто такой архитектор. Редакция 2!
Описываем ошибки правильно. Правило трех вопросов
Полезные обработки:
Пример работы с файлами odt в клиент-серверной модели работы
