Хороший, плохой, злой 1С-ник
Функциональные - Управление персоналом (HRM)
Исходная задача
Чтобы не водить вилами по воде - начнем сразу с конкретной задачи, которая имела место быть в моем личном опыте.
Итак заказчик ставит задачу: Добавить галочку "Согласовано" в документ поступление товаров.
Конечно же, перед выполнением задачи все надо обсуждать и говорить заказчику, какие есть подводные камни и хочет ли он их избежать, но я специально пропускаю это, чтобы контраст был более очевиден.
Акт 1
Программист №1: Добавляет реквизит в документ и выносит эту галочку на форму. Тратит на это 30 мин.
Программист №2: Создает документ "Согласование" + табличную часть "Товары", делает регистр накоплений "Согласование" и описывает логику заполнения табличной части. Тратит на это 10 часов.
Заказчик: Думает, что №1 - очень хороший и очень быстрый и готов ему уже сейчас платить в 2-3 раза больше, чем №2. А этот долгий №2 еще и денег просит больше.
Акт №2
Бухгалтерия закрывает период редактирования.
Программист №1: Находит тот код, который запрещает изменять документы в закрытом периоде, и переделает его так, чтобы можно было согласовать. Тут придется ему повозиться. Задача-то нетривиальная. И потратит 4 часа.
Программист №2: Ничего не делает
Заказчик: Думает, что №1 работает и хочет ему помочь, а №2 не желает помогать.
Акт №3
Проблема: Двое согласующих не хотят признавать, что это они согласовали, и валят друг на друга.
Программист №1: Добавляет реквизит "Согласовал" с типом "Справочник.Пользователи", который заполняется в его хитром алгоритме обхода закрытого периода. Тратит еще 1 час.
Программист №2: Еще а первом акте добавил реквизит "Ответственный" в свой документ и опять ничего не делает.
Заказчик: Думает, что №1 делает как удобно заказчику. Все просто и понятно и даже в списке документов можно видеть, согласовано или нет. А №2 сделал какого-то монстра и озадачивает понапрасну людей создавать еще документов.
Акт №4
Заказчик говорит: Хочу, чтобы люди, которые согласовывают, видели новые документы, которые им надо согласовать.
Программист №1: Делает обработку, форма которой раз в n секунд делает запрос по документам, у которых нет галки. Ну или ко всем документам, а потом в цикле сравнивает ТекущийПользователь и Согласовал. И обработка эта открывается ПриНачалеРаботыСистемы. Тратит на это 3 часа.
Программист №2: Делает отчет, который показывает остатки регистра накоплений из первого акта. Тратит на это 30 мин.
Заказчик: Думает, что №2 совсем не понимает, что нужно делать. А №1 молодец. Все просто и понятно.
Акт №5. Заключительный
Проблема: Часть товаров может быть согласована, а часть нет.
Программист №1: Переносит реквизиты "Согласовано" и "Согласовал" в табличную часть, в списке документов обрабатывает событие "ПриВыводеСтроки", чтобы определить согласован документ целиком или нет, переделывает алгоритм обхода даты запрета, переделывает обработку, которая открывается "ПриНачалеРаботыСистемы". Тратит на это 6 часов.
Программист №2: Ничего не делает, потому что все готово было в первом акте.
Заказчик: Начинает понимать, что №2 все предусмотрел заранее. Но реальную работу он видит у №1. Поэтому со счетом 4:1 побеждает №1
Итого
Программист №1 тратит 14,5 часов.
Программист №2 тратит 10,5 часов
Заказчик получает, казалось бы, одинаковый результат, но с №1 ему работать выгоднее, т.к. он делает "красивее" и ставка у него ниже. И заказчик еще не знает, что доработки №1 будут добавлять 15 мин. к каждому следующему обновлению конфигурации. Заказчик еще не знает, что эти доработки приведут к серьезным проблемам производительности в будущем и к блокировкам, с которыми не сможет разобраться программист №1 и опять напишет кучу подобного. И вот после всей этой кучи доработанного заказчик начнет получать ответы от программиста №1 по типу "Мы не можем вести учет в разрезе двух складов, а если доработаем - вся компания может встать, т.к. предусмотреть все места, где написано
Если Склад.Наименование = "Склад №1" Тогда
....
НЕВОЗМОЖНО!"
Вот и получается, что в глазах заказчика программист №1 - хороший, а программист №2 - плохой, а по факту получается совсем иначе.
Технический долг
Это еще один интересный момент, который не видят заказчики/работодатели.
Если коротко - технический долг это непродуманное решение, которое может приводить к негативным последствиям (как в примере выше - галочка "Согласовано")
Программисты меняют работу по разным причинам. И на их место приходят другие. У всех разная квалификация, разный опыт. И все оставляют после себя технический долг. Кто-то меньше, кто-то больше, но все. Конечно же плохие оставляют больше.
Представим ситуацию: Работало 2 программиста с низкой квалификацией, но им досталась типовая конфигурация, которую они дорабатывали на протяжении нескольких лет.
Потом на их место пришли программисты с высокой квалификацией и з/п им нужна в 2 раза больше.
50% своего времени напрямую или косвенно новые специалисты тратят на закрытие технического долга.
И тут работодатель опять попадает в эту ситуацию: Плачу больше, делают дольше.
Может получиться еще одно интересное развитие событий: с этими двумя расстанутся и возьмут опять с меньшими зарплатными ожиданиями и более низкой квалификации. Технического долга будет естественно меньше, да и не факт, что он их будет волновать. Сказали галочку - вот вам галочка. И руководство опять радо - опять видно работу программистов. А то, что в штате через несколько лет уже 10 плохих программистов, а не 2 хороших, работодателя не особо тревожит. Ведь люди работают, ставят галочки в отчетах. Все хорошо.
Злой программист
Какой он? Хороший или плохой? На самом деле он может быть как хорошим, так и плохим.
Это именно тот, который ставит галочки в отчетах и работает только в том случае, если можно галочку поставить в отчете и получить премию за это. Что происходит в коде его не волнует.
Увидел такой код:
Если ТекущаяДата() > Дата("20200101") Тогда
.....
Поменял на Дата("20210101") и знает, что в следующем году он будет востребован.
Зачастую такие программисты знают, где и что нужно поправить при возникновении какой-либо ошибки. И они за это ценятся. Ведь если они уйдут - вся компания встанет.
Но писать хороший код они не хотят, потому что боятся падения своей ценности.
Конечно его можно заменить на хорошего программиста, но процесс этот долгий и проще оставить как есть.
Выводы
Определить, хороший программист, плохой или злой, очень сложно людям, которые далеки от программирования. Если программист быстро делает Ваши хотелки и при этом стоит недорого - еще не означает, что он хороший.
И даже то, что он делает долго и стоит дорого - не означает, что он хороший.
В целом опыт конечно является показателем, но я встречал и плохих программистов с большим опытом и наоборот. Тут больше от человека зависит и от его желания делать что-то, что приносит пользу.
Как максимально точно определить, кто перед Вами на собеседовании? Попробуйте составить задачу из нескольких актов (как я описал выше) и обсудите с кандидатом каждый акт отдельно, не говоря ему о том, что впереди еще задачи. Будет ли он задавать вопросы или тупо делать - вот что важно! Хотя и это не панацея.
Вступайте в нашу телеграмм-группу Инфостарт
Хороший программист 1с-ник плохой
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Управление персоналом (HRM) Бухгалтер Пользователь 1С:Предприятие 8 Бухгалтерский учет Управленческий учет Платные (руб)
1С:Зарплата и управление персоналом 8 – программа для полной автоматизация учета и управления сотрудниками на предприятии. Базовая, КОРП и ПРОФ версии. Покупайте в Инфостарт и получайте 15% бонусов на наши услуги, сервисы и мероприятия!
11100 руб.
17.02.2016 178947 802 6
Управление персоналом (HRM) Бухгалтер 1С:Предприятие 8 1С:Зарплата и кадры бюджетного учреждения 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)
Решение дает набор актуальных на текущий год форм бланков для ведения миграционного учёта по иностранным работникам в «1С:Зарплата и Управление Персоналом 8», «1С:Бухгалтерия 8», «1С:ERP 8», «1С:Комплексная Автоматизация 8» и других конфигураций 1С. Интеграция с Госуслугами. Дополнительная опция – автоматическая проверка по Реестру контролируемых лиц (РКЛ).
7950 руб.
06.02.2012 136968 104 88
Управление персоналом (HRM) Россия Платные (руб)
Сервис автоматической массовой проверки иностранных сотрудников в реестре контролируемых лиц и отправки уведомлений в МВД. Защитите свой бизнес от штрафов до 2 млн руб, автоматизировав контроль за нарушениями иностранных сотрудников и взаимодействие с МВД. Снижение рисков на 95%
05.05.2026 934 2 user2197699 0
Управление персоналом (HRM) Комплексное управление ресурсами (ERP) Бизнес-аналитика (BI) Пользователь 1С:Предприятие 8 Россия Управленческий учет Платные (руб)
Решение предназначено для управления результативностью организации с использованием ключевых показателей деятельности (KPI) и сбалансированной системы показателей (BSC)
57800 руб.
17.02.2016 42000 2 1
Управление персоналом (HRM) Учет рабочего времени 1С 8.3 1С:Бухгалтерия 3.0 Россия Платные (руб)
Расширение «Отпуска» добавляет в конфигурацию 1С:Бухгалтерия предприятия возможность формировать печатную унифицированную форму № Т-7 "График отпусков". Также реализован лёгкий процесс подачи и согласования заявлений на отпуск: сотрудник или бухгалтер создаёт заявление, указывает период и замещающих; руководитель утверждает или отклоняет. При желании сотрудники, руководитель и замещающие получают уведомления о событиях в Битрикс24. Вся работа ведётся прямо в 1С:Бухгалтерия предприятия, без установки тяжёлых кадровых контуров либо сложных интеграций.
18300 руб.
13.10.2026 189 0 0
Управление персоналом (HRM) Бесплатно (free)
В статье разбираем, как DISC-модель помогает понять, почему сотрудники по-разному реагируют на задачи, изменения и взаимодействие в команде. Кратко объясняем основы подхода и поведенческие типажи без сложной теории, показываем, какие сочетания чаще встречаются в IT-среде. Рассказываем, как особенности разных типов влияют на коммуникацию, распределение ролей и рабочие процессы. Показываем, как учитывать эти различия на практике – при постановке задач, управлении и формировании эффективных команд.
17.09.2026 1065 user2086401 1
Управление персоналом (HRM) 1С 8.3 1С:Зарплата и Управление Персоналом 3.x Россия Абонемент ($m)
В ЗУП 3.1.38.92 при ручной загрузке запросов СФР старого формата СЭДО 100 может возникать ошибка «Метод объекта не обнаружен (ЗагрузитьСообщение100)». В результате XML-файл запроса недостающих сведений не загружается, хотя сам файл сформирован корректно. Публикация содержит временное расширение для ЗУП 3.1.38.92, возвращающее обработку сообщений СЭДО 100 без изменения типовой конфигурации. Решение предназначено для использования до выхода официального исправления 1С и особенно актуально в переходный период на новые типы сообщений СЭДО. Расширение минимально вмешивается в типовой механизм и устраняет ошибку загрузки старых запросов СФР.
1 стартмани
16.09.2026 949 5 e_lenochka 2
Управление персоналом (HRM) 1С:Зарплата и Управление Персоналом 3.x Россия Абонемент ($m)
Обработка подсчитывает количество оформленных отпусков сделанных исполнителем за период. Включены отпуска без оплаты на часы отсутствия.
1 стартмани
16.09.2026 400 0 AlenaBelousova 0
Как уже писал - крик души.
Тоже крик души ))
Как там в Гарри Поттере? не надо поощрять прогресс ради прогресса))
Тоже крик души ))
Наше законодательство не оставит прогеров без работы. Ни первых, ни вторых
А теперь представьте ситуацию (90% вероятности), что кроме Акта №1 никаких других актов не было и не будет.
Итого.
Программист №1 потратил 30 минут. Всё удобно пользователям и работает.
Программист №2 потратил 10 часов 30 минут, сделал "монстра", из-за которого пользователям приходится тратить лишнее время, которое за годы выльется в приличные потери.
Ну и кто из них Дед Мороз? (с) :)
Вероятность, что так все будет усложняться, довольно низкая.
Опять же "золотой" программист №2 в 95% случаев просто развел клиента на деньги за лишние 9,5 часов.
Второй программист - инвестировал в будущее компании.
С учетом наших реалий и модели малого и среднего бизнеса - первый программист предпочтительнее.
Для корп структур - второй.
Но создавать новый документ "Согласование", все же не самое изящное решение.
Подобные доработки превращают конфигурацию в франкенштейна, один программист прикрутил одно другой другое
у каждого свое видение свои амбиции
Строитель заказал лестницу с одной очень высокой ступенькой в конце и одной очень маленькой вначале. Поэтому когда
Как выше сказали все это рождает механизмы мало пригодные в реальной жизни. В стиле закрытия заказов отдельным документом или продажу подарочного сертификата. Или вот недавний пример. Номера ГТД испокон веков они были в карточке, пользователи их меняли, вывести в печ.форму особых проблем нет, против родного партионного монстра, и потом бац, убирают эти реквизиты с карточки.
А уж про то как второй тип переименовывают Поступление в Приобритение можно легенды складывать
Быстрее всех эволюционируют сантехники. Каждый приходящий сантехник на порядок умнее предыдущего.
Всегда звучит фраза: "Что за тупица вам это делал?!"
В начале года какая то всеобщая истерия и самокопание среди программистов.
На Хабре два дня рубятся, что разработчики уже не те, теперь на Инфостарт это перекинулось.
Может это вирусы ?)
Все люди бывают плохие и хорошие, ленивые и не очень и мир в несправедлив, это в школе проходят
Русская литература состоит из страдания. Страдает или персонаж, или автор, или читатель.
А если все трое - то это шедевр.
Программисты в этом плане ничуть не отличаются от Родиона Раскольникова или Сонечки Мармеладовой
Не поймите меня правильно
Если, предположим, что я делаю вывод, что Программист 2 хорошо поговорил и расспросил заказчика, и выяснил у него все нюансы заранее, то КАК заказчик может быть недоволен? Ведь он в этом случае тоже понимает что схема сложная и данная доработка решает его задачи.
Недовольство заказчика в этом случае НЕПОНЯТНО
Программист №2, как обычно, роли не сделал для добавленных документа и регистра.
Поэтому должен быть еще и третий.
Даже видя откровенный трэш в коде никогда не говорю что до меня работал "рукожоп". Можно всегда сказать "он здесь немного ошибся, сейчас попробую поправить".
Но это только когда заказчика перестанет устраивать работа этого ужасного кода. Когда это случится и случится ли вообще вопрос на самом деле открытый. Ни в коем случае не призываю говнокодить. Но не надо забывать, что:
Работающий Инстурмент <> Хороший Код.
Платят, как правило, за первое, но коллеги оценивают по второму. Что хуже сам себя оцениваешь по второму.
В ступать в диступ с руководством а ля "да тут до меня такого навояли" - это в глазах руководства "гнать порожняк".
Или вы спокойно и тихо исправляете ситуацию к лучшему или выход там >...
Минута руководителя стоит очень дорого и если он будет вынужден слушать
нытье "гения 1С", то терпение будет не долгим.
Вот исходя из этого и принимает решения как писать, а как нет.
А программист №1 знает как угодить прям сейчас и не думает о том, что будет с базой завтра. Он работает - получает денежки - прощайте.
1. Первоначальный рассказ о подходах к программированию.
2. Вы говорите - неважно какой подход - руководству плевать
3. Я говорю - важно, потому что... И обосновываю свою позицию.
Вы следите за ходом дискуссии?
А у второго программиста архитектура как то не очень. ДЛя чего создавать дубли таблиц? Для того, чтобы программист мог в запросе написать ИЗ РегистрНакопления.Скгласования.Остатки(&,&...) ?
А еще ему надо придумать, чем закрывать тогда этот регистр. Если тем же документом согласование, то зачем вообще регистр?
И кстати, у второго программиста удастся протолкнуть идею с документом только в том случае, если в компании не разведено бюрократии, и то, там давно внедрен документооборот. В противном случае второй программист просто будет на каждый документ красть минут по 10 времени другого специалиста. Я не говорю, что у первого программиста идеальный механизм, но на первом этапе задача стояла именно про согласование документа. И, если бизнес не успевает отверять доки в разрешенный период, значит надо а) помочь ему ускорить это б) предложить изменения в бизнес-процессе.
Дублей нет. Приход делаем поступлением, расход согласованием. Остаток - то, что не согласовано. Кстати да. Программист №1 любит работать с таблицами документов в запросе. Конечно он слышал про остатки, но заказчик же не просит регистр - значит надо без регистра все делать ))
Красть 10 минут не придется. Тут вариантов много, но все сводятся к тому, что заполнять надо остатками.
Программист 2 обычно пишет в коде что с 3 марта 11 часов 34 минут и 47 секунд появляется регистр и все что до него берет по таблицам документов, а после по регистру.
(119)
Посекундно очень плохой подход. И не завидую программисту, который будет это поддерживать после.
Если уж и делается революция, то приурочивается какой то крупной дате начала. Месяца, квартала, а лучше года.
В данном случае ТС описал два подхода, первый быстрый и, в принципе правильный с точки зрения спринтов - быстро сделать и внедрить, допиливать после.
Второй программист делает с учетом избыточности, а вдруг пригодится. Но все могло закончится на галке. И бизнес получил в работу механизм уже вчера и начал получать прибыль, а во втором варианте эдакий зануда гундит, что надо правильно все, по канонам, с регистрами обязательно, чтоб раздуть базу.
Приведу пример. Пусть таблица табличной части прирастает по 10Гб в месяц. Программист номер два говорит, что теперь 7 из них будут кочевать в новый документ, и эти же 7 Гб еще и в регистр и столько же в таблицу итогов, пока они не рассчитаются. Верно посчитал? В итоге прирост базы на одной мелочевке составил 10Гб документ + 21Гб против 10Гб. В три раза раздул. Может я ошибаюсь? Вроде нет, каждую строку документа надо перенести в док согласование, в регистр и рассчитать остатки.
Дубли есть. Смотрите:
Док ПостаплениеТЧ
Номенклтаура...
ТЧ ДокСогласование
Номенклатура Согласован Ответственный Количество(?)
ТЧ РНСОгласование
Номенклатура Согласован Ответственный Количество(?)
Вам не кажется, что колонки одинаковые?
И в принципе, бизнес-процесс очень кривой, что за согласование построчно?
Чем работа с таблицами документа принципиально отличается от работы с таблицами регистра? Ну, если не имеется ввиду сдача на специалиста по платформе.
И что делать, если строку документа никто не согласует? Ее надо удалить? Почему тогда весь документ нельзя таким образом согласовать, а не городить?
Или что делать, если из 10 штук согласовали только 8. Тогда что? И почему согласуется поступление, а не заказ? А если для бухгалтерии, то логичнее было бы сделать ТЧ расхождений. Если для ордерной схемы документ ордер.
Просто ТС предлагает вместо такого простого и прозрачного механизма использовать еще один документ с регистром, который полностью повторит этот документ. И даже какие то блокировки указал, которые хоть убей, но не могу придумать, какие будут при этом.
Идеальный программист - это тот, кто появляется один раз, сразу все делает и больше вы его никогда не видите и дополнительных денег не платите.
(Безупречный программист - не появляется вовсе.)
Беда только в том, что так мы экономику не поднимем, а только опустим )))
Одни поняли, что я Дартаньян, другие - что я их обманул, третьи - что можно кодить как хочешь, если умеешь быстро бегать ))
А я хотел вот что донести:
Бывают разные подходы к решению задач. И если заказчик считает что кто-то сделал хорошо - просто прошло слишком мало времени для качественной оценки.
А если считает, что кто-то делает плохо и/или медленно - может стоит ещё раз подумать.
Но факт остается фактом, на примере 1С можно проследить, как 1С сожрала всех конкурентов на рынке СНГ, SAP, Ax, Парус, Галактика остались не у дел и не могут похвастаться таким ростом. А тем временем с момента моего старта в профессии(2013 8.2.14) до текущего времени изменений в платформе столько, что это два абсолютно разных по возможностям продукта.
Примеры с элементами "притянутости", в целом - попытка затронуть очень обширный дискуссионный вопрос.
Так что за суть минус, за создание темы с бурным обсуждением - плюс
как и этот сайт на мобиле с полем камента посреди большой вертикальной прокруткой, да и еще с лагами.
и даже, если принять на веру, что решение второго лучше со всех сторон, то эту статью прочтут программеры , которые хотят быть "хорошими", но их , как непризнанных гениев не понимают. они отсылают главбуха(или иного принимающего решение) прочесть какую-то статью на инфостарте. ха) да после такого эти лучшие и придут писать не код, а подобные крики души, что опять "не оценили очевидную крутость решение"
Кроме того, помним, что корреляция з/п и квалификации тоже имеет место быть. И если программист работает за еду, то как-то странно было бы требовать от него суперизящных и продуманных решений. Быстро, качественно, недорого - выбираем любые два. Правило без исключений.
И да, мне лично приходилось быть и программистом №1 и №2. Никто не рождается с готовыми знаниями и опытом.
Па-ра-па-ра-пам, ВСЁ!!!
Люди три года используют эту доработку в первозданном виде. Без регистров и утверждения отдельным документом.
Не надо превращаться в "Программиста 2" без согласования с заказчиком, он может и сам не знать какие доработки понадобятся в будущем. И может вполне резонно отказаться платить за лишнюю работу
Если НЕ РольДоступна("ТаСамаяРольНаДоступКФлагуСогласован") Тогда
// Если тот самый флаг модифицирован, то ругаемся и избиваем пользователя, далее
Отказ = Истина;
Я так часто делаю в подобных случаях - главное это быстро и результативно,
просто добавил роль и пару строк кода в подписку и с "правами" на доп-реквизит.
Все, пусть в него тыкает хоть 100500 раз - все равно получит по морде при любой попытке записи и больше не будет трогать этот флаг - это технология прав "потыкай мордой нашкодившего кота в угол куда он сходил"
я предпочитаю тыкать - шобы знало.
"Чем меньше юзер видит сообщений - тем меньше юзер генерирует обращений". Они сообщений об ошибках сильно пугаются и начинают звонить/писать/стучаться к разработчику. В лучшем случае.
В худшем - могут начать мозг руководству выполаскивать - "кого вы наняли? Они настроить 1с без ошибок не могут никак"
Всем, кто права не имел, соответственно флажка не видел. Для них сделали выделение цветом на форме списка и выбора
Ругать автора за субъективность не вижу никакого смысла, т.к. такая классификация программистов не панацея. Повторюсь, это взгляд автора не более того.
Но я бы сделал регистр с 1 измерением "документ" и 1 ресурсом/регистром "согласовано", в случае добавления номенклатуры, количества, фио - это допиливалось бы в процессе, соединять со списком просто, а для некоторых можно вывести список регистра чтобы они работали уже по да/не согласованным документам. Ну и проверка перед записью "отказ=НаборЗаписей.количество()>0 и НаборЗаписей[0].согласован"
По опыту - если задача не специфическая, то решение уже есть оно сделано и обкатано на тысячах пользователях. А городить свой механизм - натыкаться на те же грабли, которые прошло куча народу. Разве что ради опыта и денег с клиента.
Исключения составляют реально специфические задачи, как, например, приемка сыпучих грузов. Которые вроде реализуются партнерами 1с в отдельных программах, но прикручивать этого монстра ради двух документов смысла нет.
Уже во втором акте, программист №2 делает не "ничего", а делает другую задачу.
И заказчик про первую задачу даже не вспоминает.
Далее по тексту те же огрехи.
По сути описаны два разных типажа программиста, скажем так "реформаторы" и "фундаменталисты".
Реформаторы принимают решение здесь и сейчас, делают необходимый минимум.
Фундаменталисты пишут все по канонам, долго, вдумчиво, расчетливо.
Кто из них хороший или плохой. Да никто.
Оба могут дать бизнесу требуемый продукт.
Главное чтобы спец понимал все что он делает, и отвечал за последствия.
Хорошие программист совмещает в себе оба этих подхода.
Я бы первые два акта сделал как первый программист, остальные как второй.
Почему именно по товарам согласование, а не по документу (например через доп реквизит)?
Зачем нужно согласование (может для склада что то пилят)?
Почему сразу не сделан отчет по согласованным, поскольку сделав все в регистре 2й скрыл информацию (даже если есть перейти)?
А что делалось с дублирующимися позициями (например есть 2е строки с болтами согласовали одну) ?
И даже при всех этих реализациях не видна цель заказчика, которая быть может решается запуском приходного складского ордера, или заявок на закупку. Ведь заказчик не знает возможностей 1с. Поэтому подозреваю оба изобрели велосипед.
Второй не скрывал информацию, а просто первый был выдуман (то как хотел заказчик в начале). И первый бы не стал ничего уточнять, потому что.... (придумайте сами)
Вы реально думаете, что было два исполнителя на одну задачу?
Первый - это то, как хотел заказчик.
Второй - то, как сделал я после долгих обсуждений.
Ну вот карты и раскрыты. Я - второй.
Сначала он уговаривал меня сделать галку. Но после долгих переговоров - понял, что надо отдельный документ.
Поблагодарил меня за то, что я с ним не согласился в начале и полностью оплатил работу
.
а так - большинство контор (имхо) решают сиюминутные задачи. Получают сиюминутные ответы. Поэтому Программист1 - нормальный. Контора - не его бизнес, он не обязан думать на перспективу развития бизнес-процессов - на это есть отдельные люди и стоит это отдельных денег. а Программист2 - тоже нормальный, в другом ключе.
.
Мы смотрим на ситуацию с этими двумя П - сбоку. А по факту надо смотреть изнутри (изподвыпедверта может быть).
.
В ситуации П2 и П3 и П1 бывал неоднократно. И продолжаю бывать. Все зависит от контекста. Когда - как спец 9вы же пригласили меня как спеца?) говоришь "так делать не надо" - смотрят с подозрением - это что за умный такой, говорят ка надо сделать, а он "не надо!".
.
Проблема в том, что многие "куроводятелы" (разных уровней) подменяют "что надо сделать" и "как надо сделать" одно другим. Когда в неторопливой обстановке начинаешь разжевывать - приходит понимание. Но разжевывать нужно не для всех. Некоторым полезнее на форму вместо одного документа (П2), сделать 20 галочек (П1) - поверьте, иногда, это полезнее и выгоднее во всезх смыслах.
.
как-то так.. Имхо.. на истину - не претендую...
Акт 2 редакция 1
Несчастный пользователь, замотавшись вводить каждый раз дополнительный документы, призывает программиста №3, и тот пишет разгромную статью на инфостарт про ламера-программиста №2, который не знает типовые механизмы конфигурации и корячит свой новодел, ибо
- галочку можно было добавить через дополнительные реквизиты, а не корячить целый документ
- отдельным пользователям, которые продолжают согласовывать и править документы можно не закрывать период, а не корячить целый документ
Акт 2 редакция 2.
Никакого согласования по каждой строчке документа в конторе так и не потребовалось. Однако компания росла, в каждом документе получалось по 100-150 строк, а таких документов колотили по 2000 в день. Когда собственник устал покупать новые сервера под пухнущую базу и слушать жалобы пользователей и админов, что все тормозит, работать невозможно и отгрузки срываются, он пригласил программиста №3 для оптимизации. Увидев целый отдельный документ, который дублирует табличную часть исходного документа, программист №3 охренел и написал разгромную статью на инфостарте о программистах типа №2, которые понятия не имеют о нормальных формах в реляционных базах данных и лезут своими кривыми рученкам в конфу, даже не потрудившись получить нормальное образование, тем самым создавая технических долг для тех, кому потом приходится это оптимизировать.
Акт 6
Бизнес-процессы компании в очередной раз поменялись, и теперь в согласовании должны принимать участие 5 человек, причем двое из них должны согласовывать параллельно. Программист №2, так же как и программист №1 сидит и допиливает бизнес-процесс, который он почему-то не смог предусмотреть заранее.
Какая же тут мораль? Какое бы решение ты, программист 1С, не принял, всегда найдется другой программист (может, и не 1С, кстати), который его обосрет. Особенно это легко сделать, когда бизнес-процессы компании поменялись, и первоначальное решение уже перестало им соответствовать. А если кратко: "задним умом мы все крепки"
Был у меня на прежней работе программист, который писал код так, чтобы быть незаменимым. Каждый месяц его вызывали, чтобы закрыть месяц. Мы изучали новые вещи, а он закрывал месяц на древнем Фокспро.
Прошло 20 лет, он уже давно выпал из профессии и все довольно печально. А ведь неплохо начинал.
Представьте, что в текущий момент времени происходит Акт №1. Ни кто ни про какие дальнейшие акты не говорил. Задач на развитие функционала не ставил. Сидите вы в момент событий акта №1 и думаете "Сделать то что сказали и продолжить выполнять другую работу, или начать креативить и решить следующих 10 возможных проблем которые может быть ни когда не случаться?"
2. Какое может быть согласование в закрытом периоде?
3. Чем ордерная схема не подошла для приемки товара несколькими людьми?
Вывод - гоните в шею БА.
Опытный, выжмет из заказчика планы развития объяснит ему, что надо, и надо ли вообще, и только на основании полученных данных примет решение солидарно с заказчиком. Возможно между первым и третьим актом.
Тогда флажок "Согласовано" будет автоматом записываться в регистр с данными о пользователе, сделавшем запись и времени этой записи, а для каждого следующего пользователя, открывшего документ система будет выводить только флаг его согласования на основании регистра. Тратим 4 часа и кроем двух первых программистов, минимизируем участие пользователя (нет надобности вводить документ "Согласование") и расширяем функционал, хоть для тыщи согласующих.
А ничего что задание не выполнено -галочки в документе нет
И дальше происходит такой диалог между Заказчиком (З) и Программистом(П)
П: «задачу выполнил . я добавил документ согласование» время 10 часов
З: «Стоп , какой документ Согласование , мы же просили добавить просто галочку в документ поступление товаров. Мы не будем оплачивать вашу работу так как она не соответствует поставленной задаче)
Программисту 2 можно утешать себя тем, что без него все эти системы, где он не приложил руку, давно бы рухнули. А осознание, что ты делаешь хорошее дело для всего общества, оно дороже сиюминутной выгоды!
- а еще есть вариант когда заказчику действительно хватило галки и он нифига более не попросил за 5 лет работы - программист 1 победил.
Акт 1: Делает регистр "Документ, Согласован, Ответственный", выводит галки на формы документов и списков - тратит 30 минут.
Акт 2: Ничего не делает.
Акт 3: Ничего не делает.
Акт 4: Ничего не делает (галочка то на форме списка уже есть)
Акт 5: Добавляет регистр "Документ, КодСтроки, Согласован, Ответственный", выводит на формы, изменяет логику записи в первый регистр - тратит 30 минут.
Как раз главная ценность статьи - вывод, что "как оно по уму" - предсказать почти невозможно! ( Даже в конкретном случае, не говоря о "в принципе".
Можно сказать, что для фрилансеров (разовые задачи) - однозначно вариант №1 лучше, конкурентнее, как минимум. Для кадрового программера... тоже не однозначно. Если только по удобству для пользователя варианты окажутся равны, тогда - да, №2.
И это, в общем-то, не парадокс. Просто - пересечение идеального мира булевой алгебры и реального мира людей )).
Не рассмотрен вариант разграничения прав на галку. И есть еще вариант реализовать галку "согласовано" через доп.реквизиты - это похоже уже "ленивый" программист (хотя программирования тут нет абсолютно). В случае УТ 10.3 - доп.реквизитов нет, но есть свойства и категории.
Случай из жизни: заказчику необходим контроль за наличием бумажного документа к реализации. Варианты реализации (оставляю суть):
1) РС с полями "документ" и флажок "документы в порядке". Когда документ проверен - создается запись регистра.
2) РС с полями "документ", флажок "документы отсутствуют"и подписка на событие проведения документа с созданием записи регистра. Когда документ проверен - запись регистра удаляется.
РС обусловлен дополнительными требованиями. По времени реализации оба варианта примерно одинаковы, результат для заказчика одинаков. Но первый вариант пришлось переделывать на второй.
Добавим теперь Акт 6 (или 4.1) Вносятся изменения в первичный документ.
Программист 1 дописывает снятие галочек согласования при изменении строки. Тратит 30 мин.
Программист 2 пишет логику отслеживания изменений в исходном документе, пишет логику внесения изменений в свой документ согласования, изменения в регистр согласований. Тратит 10+ часов и получает монстра.
Что касается Акта 4 - Программист 1 ничего бы не писал. Он просто настроил бы условный формат списка документов с подсветкой несогласованных.
По хорошему нужно было настроить согласование через бизнес-процессы, добавить ответственных, сделать механизм оповещения, написать мобильное приложение (вдруг согласующий в отпуск уйдет)
Любую задачу одной галочки можно превратить в большую и хорошо оплачиваемую.
В итоге: критерий плохой/хороший программист определяется по способности генерировать объем.
Так что программист №2 на верном пути.
Если у него с этим (с объяснением) проблема, то пусть за него это делает консультант или другой "специально обученный человек"
Как говорится: "Без внятного ТЗ результат - ХЗ".
1) От простого к сложному, в порядке возрастания:
- Используем те объекты прикладного решения, что есть (даже если они называются "не так как хочется видить заказчику"), но в итоге позволяют сформировать нужный отчёт без необходимости тратить +100500 рабочего времени
- Внешняя обработка/отчёт и т.д.
- Расширение
- Вмешательство в конфигурацию + расширение
2) Аккуратно выпытывая, "а зачем это вам?" т.к. есть категория заказчиков которые "сами решили", что им нужна эта галочка (хотя, вполне возможно, это уже реализовано, но выключено функиональной опцией; или для какого-то элемента "контроля" который можно проявить свосем в другом месте и иным способом)
3) Прикидывать по времени и цене для клиента, предлагаая несколько вариантов "попроще" и "подороже" (не забывая про пункт 1 - минимум вмешательств)
В сожалению, часто сталкиваюсь с жалобами клиентов, что их развели как нуба на СТОшке купившего первую машину...
Из последнего: переход с БП 2.0 на БП 3.0 (типовая конфа, небольшая база - бух на аутсосрсе) - 4 часа работы. Просто за то, чтобы скачать обновления для перехода с 2-ки на 3-ку, сделать бэкап и, возможно накатить новую платформу.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1178624
Создание 14.01.20 09:30
Обновление 14.01.20 09:30
Просмотры 26154
Загрузки 0
Рейтинг
29
Комментарии 146
Код открыт Да
Рубрики Управление персоналом (HRM)
Кому Для всех
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
