Хороший, плохой, злой 1С-ник

14.01.20

Функциональные - Управление персоналом (HRM)

В этой статье хотелось бы поднять проблему отношения к программистам 1С. Нечасто люди могут отличить хорошего программиста от плохого. Для людей важно исполнение их хотелок в кратчайшие сроки. Но является ли это показателем качества? Как отличить хорошего от плохого программиста? А еще есть отдельная каста - злые. Это вообще как? Давайте немного подробнее разберемся в этих вопросах

Исходная задача

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

Итак заказчик ставит задачу: Добавить галочку "Согласовано" в документ поступление товаров.

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

Акт 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с-ник плохой

См. также

1С:Зарплата и Управление Персоналом 8 (ЗУП) - ПРОФ, КОРП, купить, цена

Типовые Управление персоналом (HRM) Платформа 1С v8.3 Бухгалтерский учет Управленческий учет Платные (руб)

«1С:Зарплата и управление персоналом 8» – программа для полной автоматизация учета и управления сотрудниками на предприятии. Базовая, КОРП и ПРОФ версии. Возвращаем 15% кешбеком. Заказывайте 1С:ЗУП в Инфостарте!

8200 руб.

17.02.2016    151488    430    6    

323

Программы для ведения учёта мигрантов в 1С

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

Набор актуальных на 2023 год форм бланков для ведения миграционного учёта по иностранным работникам в «1С:Зарплата и Управление Персоналом 8», «1С:Бухгалтерия 8», «1С:ERP 8», «1С:УПП 8» и других конфигураций 1С.

86820 руб.

06.02.2012    123192    67    87    

133

Outstaff, outsource или все-таки штатные сотрудники — что выбрать в IT?

Управление персоналом (HRM) ИТ-компания Россия Бесплатно (free)

Иногда у компаний возникают большие потребности в сфере IT: появляются новые проекты, нужна техническая поддержка, разработка программ или приложений или закупка нового оборудования. Компании-разработчики могут предложить разные формы взаимодействия. Когда специалистов выгодно нанять в формате аутстаффинга, когда — аутсорсинга, а когда лучше принять в штат — разбираем вместе с Андреем Ильичевым, генеральным директором компании IS Group, членом экспертного совета при Минцифры, сертифицированным специалистом 1С, SAP, Microsoft, Атол, RetailCRM.

19.03.2024    364    user2056416    2    

4

HR-аналитика текучести кадров (Datalens для 1С)

Управление персоналом (HRM) Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Управленческий учет Абонемент ($m)

Текучесть кадров — это самый сильный сигнал, который получают руководители от своих сотрудников. Смена работы и увольнение работника — важные события в истории предприятия. Дашборд текучести кадров помогает руководителям следить за ходом работы кадровой службы, выявлять взаимовлияние различных показателей, определять тенденции и принимать на этой основе управленческие решения. В статье описан один из вариантов построения такого дашборда в сервисе datalens.yandex.ru.

2 стартмани

08.12.2023    754    0    Novomir    0    

2

Рефакторинг механизма учета причин увольнения в ЗУП КОРП 3.1

Кадровый учет Управление персоналом (HRM) Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Добрый день, коллеги! Хотим рассказать о проблеме, с которой мы столкнулись в типовом решении 1С: ЗУП КОРП 3.1 в части учёта статистики увольнений, и как мы её решили.

06.11.2023    963    OmegaFuture    1    

6

Как организовать удаленную работу в 1С

Управление персоналом (HRM) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Возможность удаленной работы в 1С базах появилась довольно давно. Но, пожалуй, самый пик потребности в ней был в связи с пандемией коронавируса и после нее. Если раньше работодатели, скрепя сердце, отпускали сотрудников на удаленку и требовали работать преимущественно в офисе, то на сегодняшний день – это обычная практика и образовавшийся тренд. Скоро наличие защищенного удаленного соединения перерастет в разряд обязательных требований к организации работы в базах 1С. Фирма 1С, идя в ногу со временем, разработала варианты на любой вкус и кошелек. Давайте разбираться – что же подойдет именно Вам и какой вариант выбрать? Какие есть возможности и сервисы под конкретные задачи предприятия?

22.09.2023    4358    Koder_Line    3    

3

Дополнительные колонки на форме кадровых журналов

Зарплата Управление персоналом (HRM) Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Управленческий учет Абонемент ($m)

Для удобства кадровику (расчетчику) добавлена возможность вывода колонок "Подразделение", "Должность" и "Полное ФИО" на форме 11 кадровых журналов. Это может пригодиться для вывода (печати) реестра по таким журналам. Колонки можно произвольно подключать (отключать).

3 стартмани

13.09.2023    659    2    DEG156    0    

2

EmplDocs - Расширение для 1С с личным кабинетом сотрудника

Управление персоналом (HRM) 1С:Зарплата и кадры 7.7 1С:Документооборот 1С:ERP Управление предприятием 2 Государственные, бюджетные структуры Платные (руб)

Решение для 1С с web-интерфейсом для сотрудников, в котором осуществляется кадровый электронный документооборот. Модуль для 1С:ЗУП и 1C:ERP. Поддерживает все виды электронных подписей. Возможность создания и редактирования всех полей, заявок и печатных форм. В модуле сотрудники управляют рабочим статусом, заказывают справки, получают расчетные листы. Поставляется в виде расширения. Интегрируется с 1С:Документооборот для сложных процессов согласования.

252000 руб.

13.06.2023    3809    0    0    

5
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
74. user611573_luta 15.01.20 01:45 Сейчас в теме
И все-таки, дьявол в мелочах. В данном случае - в контексте. Приведу конкретный пример. Есть компания, у которой 2 полностью самописные базы, которые мне вручили в готовом виде. И вот в одной из них как раз был такой объект, определенные изменения которого надо было фиксировать. В т. ч. - согласование. Так вот - согласовывал там ОДИН человек, который занимал определенную должность. Просто потому, что только эта должность подразумевала под собой квалификацию, позволяющую согласовывать. Обходились галочкой. Просто к объекту был дополнительно прикручен механизм записи действий в эдакую историю (там не только согласование, еще масса всего). Полистал историю и увидел, кто и когда что сделал. Потом согласователь ушел, согласовывать стал другой человек. И все точно так же логируется и всем все понятно. Все это работает уже 4 года, и будет работать дальше. Если контора большая и жирная, с бюрократией - да, там нужны большие и мощные решения. А если нет?
Кроме того, помним, что корреляция з/п и квалификации тоже имеет место быть. И если программист работает за еду, то как-то странно было бы требовать от него суперизящных и продуманных решений. Быстро, качественно, недорого - выбираем любые два. Правило без исключений.
И да, мне лично приходилось быть и программистом №1 и №2. Никто не рождается с готовыми знаниями и опытом.
user1293011; AlexandrN; VladimirMelnychenko; vladimirmatancev; opx; +5 Ответить
75. rudnitskij 15.01.20 03:34 Сейчас в теме
Довелось мне по требованию заказчика добавить галочку "Утверждено" в поступление товаров и услуг. Обсудили, дополнили ограничением доступа к постановке галочки и к её видимости. Добавил реквизит и вывел на форму. То есть поступил как "Программист 1"...
Па-ра-па-ра-пам, ВСЁ!!!
Люди три года используют эту доработку в первозданном виде. Без регистров и утверждения отдельным документом.
Не надо превращаться в "Программиста 2" без согласования с заказчиком, он может и сам не знать какие доработки понадобятся в будущем. И может вполне резонно отказаться платить за лишнюю работу
user1293011; zqzq; FesenkoA; mongolv; +4 Ответить
76. opx 794 15.01.20 08:08 Сейчас в теме
(75) А как ограничили доступ?
78. VmvLer 15.01.20 09:21 Сейчас в теме
(76) если не умничать с РЛС то можно так
Если НЕ РольДоступна("ТаСамаяРольНаДоступКФлагуСогласован") Тогда
   // Если тот самый флаг модифицирован, то ругаемся и избиваем пользователя, далее
   Отказ = Истина; 

Я так часто делаю в подобных случаях - главное это быстро и результативно,
просто добавил роль и пару строк кода в подписку и с "правами" на доп-реквизит.

Все, пусть в него тыкает хоть 100500 раз - все равно получит по морде при любой попытке записи и больше не будет трогать этот флаг - это технология прав "потыкай мордой нашкодившего кота в угол куда он сходил"
yaguarrr; +1 Ответить
84. rudnitskij 15.01.20 12:19 Сейчас в теме
(78)на попытки записи тратится время, лучше уже этот флажок просто не показывать. Или показывать затененным - "ТолькоПросмотр = Истина". Я выбрал не показывать вообще. Тем, у кого нет права его менять
85. VmvLer 15.01.20 13:55 Сейчас в теме
(84) это детали уже и ясень пень можно рющечки прикрутить, главное что если кота пару раз ткнуть мордой в его продукты жизнедеятельности, то можно дальше не париться о его "понимании" своего места.
я предпочитаю тыкать - шобы знало.
86. rudnitskij 15.01.20 14:24 Сейчас в теме
(85) Из своего опыта вывел следующую максиму:
"Чем меньше юзер видит сообщений - тем меньше юзер генерирует обращений". Они сообщений об ошибках сильно пугаются и начинают звонить/писать/стучаться к разработчику. В лучшем случае.
В худшем - могут начать мозг руководству выполаскивать - "кого вы наняли? Они настроить 1с без ошибок не могут никак"
83. rudnitskij 15.01.20 12:17 Сейчас в теме
(76) поставил зависимость между видимостью флажка и принадлежностью к группе пользователей, имеющей права на редактирование.
Всем, кто права не имел, соответственно флажка не видел. Для них сделали выделение цветом на форме списка и выбора
80. AndrewUs 11 15.01.20 10:35 Сейчас в теме
Прочитал статью, в некоторых моментах узнал себя, в некоторых увидел к чему стоит стремиться, однако, как и большинство статей инфостарта, она субъективна. И это нормально, каждый делает вывод для себя. Лично для себя сделал вывод, что нужно уметь быть как программистом №1 и программистом №2, и программистом №3, т.д. В некоторых случаях нужно просто сделать, потому что лишние телодвижения, в некоторых случаях (70-80%) нужно хорошенько выслушать "хотелку", обдумать, задать наводящие вопросы и себе в том числе.
Ругать автора за субъективность не вижу никакого смысла, т.к. такая классификация программистов не панацея. Повторюсь, это взгляд автора не более того.
androv; mongolv; AlexandrN; opx; +4 Ответить
81. FesenkoA 57 15.01.20 10:44 Сейчас в теме
Очень спорно говорить что второй хороший. По моему опыту простые решения более изящные. Может это все близость рынка, но я максимально хорошо уяснил проблему автоматизации хаоса. Только поставив компанию в жесткие рамки (время согласования - до закрытия месяца, согласовуем все или ничего) - можно избежать еще 1000 проблем, например когда кто то меняет в начальном документе товарную часть, причем согласованную по согласованию с клиентом, или проблему обучения, или "а почему нельзя согласовать 10 штук, а остальные 5 -пока не согласовали" итд..

Но я бы сделал регистр с 1 измерением "документ" и 1 ресурсом/регистром "согласовано", в случае добавления номенклатуры, количества, фио - это допиливалось бы в процессе, соединять со списком просто, а для некоторых можно вывести список регистра чтобы они работали уже по да/не согласованным документам. Ну и проверка перед записью "отказ=НаборЗаписей.количество()>0 и НаборЗаписей[0].согласован"
82. MainUser1C 1 15.01.20 11:39 Сейчас в теме
Хороший программист 1С наверняка знает конфигурацию в которой пишет код, поэтому предложит воспользоваться документом заказ, в нем уже все что он написал за 10 часов есть. А раз все равно создавать два документа - зачем писать больше?
По опыту - если задача не специфическая, то решение уже есть оно сделано и обкатано на тысячах пользователях. А городить свой механизм - натыкаться на те же грабли, которые прошло куча народу. Разве что ради опыта и денег с клиента.
Исключения составляют реально специфические задачи, как, например, приемка сыпучих грузов. Которые вроде реализуются партнерами 1с в отдельных программах, но прикручивать этого монстра ради двух документов смысла нет.
check2; Vortigaunt; AlexandrN; +3 Ответить
87. Gureev 15.01.20 14:45 Сейчас в теме
С логикой в статье беда.
Уже во втором акте, программист №2 делает не "ничего", а делает другую задачу.
И заказчик про первую задачу даже не вспоминает.
Далее по тексту те же огрехи.

По сути описаны два разных типажа программиста, скажем так "реформаторы" и "фундаменталисты".
Реформаторы принимают решение здесь и сейчас, делают необходимый минимум.
Фундаменталисты пишут все по канонам, долго, вдумчиво, расчетливо.

Кто из них хороший или плохой. Да никто.
Оба могут дать бизнесу требуемый продукт.
Главное чтобы спец понимал все что он делает, и отвечал за последствия.
Хорошие программист совмещает в себе оба этих подхода.
Я бы первые два акта сделал как первый программист, остальные как второй.
jour; manu; acanta; opx; +4 Ответить
88. artms 282 15.01.20 15:07 Сейчас в теме
(87) Да и в первом Акте, на самом дела не ясна задача:
Почему именно по товарам согласование, а не по документу (например через доп реквизит)?
Зачем нужно согласование (может для склада что то пилят)?
Почему сразу не сделан отчет по согласованным, поскольку сделав все в регистре 2й скрыл информацию (даже если есть перейти)?
А что делалось с дублирующимися позициями (например есть 2е строки с болтами согласовали одну) ?
И даже при всех этих реализациях не видна цель заказчика, которая быть может решается запуском приходного складского ордера, или заявок на закупку. Ведь заказчик не знает возможностей 1с. Поэтому подозреваю оба изобрели велосипед.
89. opx 794 15.01.20 19:34 Сейчас в теме
(88) Заказчику было разъяснено все. И про ордерную схему тоже. Таков бизнес-процесс - ответил заказчик. Доп. реквизитов для документов в УТ 10.3 нет.
Второй не скрывал информацию, а просто первый был выдуман (то как хотел заказчик в начале). И первый бы не стал ничего уточнять, потому что.... (придумайте сами)
Вы реально думаете, что было два исполнителя на одну задачу?
Первый - это то, как хотел заказчик.
Второй - то, как сделал я после долгих обсуждений.
Ну вот карты и раскрыты. Я - второй.
91. genayo 15.01.20 19:38 Сейчас в теме
(89) Денег хоть нормально заплатили? Тыщи 2 за час хотя-бы? А так, молодец, гни свою линию.
93. opx 794 15.01.20 19:43 Сейчас в теме
(91) Конкретную сумму не считаю правильным тут писать, но да. Оплата была достойной.
95. genayo 15.01.20 20:03 Сейчас в теме
(93)Ну, тогда и рефлексировать смысла не вижу. Лучшая похвала за работу - это её достойная оплата.
acanta; opx; +2 Ответить
105. gybson 16.01.20 15:36 Сейчас в теме
(89)"Таков бизнес-процесс - ответил заказчик" БП не описывают в терминах галочек в документах 1С. Есть еще третий тип, который прямо скажет заказчику, что он страдает херней, функционал уже есть и денег тратить не надо. Не особо бедтсвуют обычно.
140. VOA2009 27.01.20 13:59 Сейчас в теме
(105) и добавляет свойство в док )))
92. opx 794 15.01.20 19:39 Сейчас в теме
Ну и на вопрос - заплатил ли мне заказчик?
Сначала он уговаривал меня сделать галку. Но после долгих переговоров - понял, что надо отдельный документ.
Поблагодарил меня за то, что я с ним не согласился в начале и полностью оплатил работу
96. CheBurator 3119 16.01.20 01:20 Сейчас в теме
Ну, если программисту платят как богу - он и сделает как бог. Но просветлится ли юзер до замысла бога - сие неведомо.
.
а так - большинство контор (имхо) решают сиюминутные задачи. Получают сиюминутные ответы. Поэтому Программист1 - нормальный. Контора - не его бизнес, он не обязан думать на перспективу развития бизнес-процессов - на это есть отдельные люди и стоит это отдельных денег. а Программист2 - тоже нормальный, в другом ключе.
.
Мы смотрим на ситуацию с этими двумя П - сбоку. А по факту надо смотреть изнутри (изподвыпедверта может быть).
.
В ситуации П2 и П3 и П1 бывал неоднократно. И продолжаю бывать. Все зависит от контекста. Когда - как спец 9вы же пригласили меня как спеца?) говоришь "так делать не надо" - смотрят с подозрением - это что за умный такой, говорят ка надо сделать, а он "не надо!".
.
Проблема в том, что многие "куроводятелы" (разных уровней) подменяют "что надо сделать" и "как надо сделать" одно другим. Когда в неторопливой обстановке начинаешь разжевывать - приходит понимание. Но разжевывать нужно не для всех. Некоторым полезнее на форму вместо одного документа (П2), сделать 20 галочек (П1) - поверьте, иногда, это полезнее и выгоднее во всезх смыслах.
.
как-то так.. Имхо.. на истину - не претендую...
manu; wowik; AlexandrN; +3 Ответить
97. mgreat75 16.01.20 05:15 Сейчас в теме
Ну что ж, я тоже пофантазирую.

Акт 2 редакция 1

Несчастный пользователь, замотавшись вводить каждый раз дополнительный документы, призывает программиста №3, и тот пишет разгромную статью на инфостарт про ламера-программиста №2, который не знает типовые механизмы конфигурации и корячит свой новодел, ибо
- галочку можно было добавить через дополнительные реквизиты, а не корячить целый документ
- отдельным пользователям, которые продолжают согласовывать и править документы можно не закрывать период, а не корячить целый документ

Акт 2 редакция 2.

Никакого согласования по каждой строчке документа в конторе так и не потребовалось. Однако компания росла, в каждом документе получалось по 100-150 строк, а таких документов колотили по 2000 в день. Когда собственник устал покупать новые сервера под пухнущую базу и слушать жалобы пользователей и админов, что все тормозит, работать невозможно и отгрузки срываются, он пригласил программиста №3 для оптимизации. Увидев целый отдельный документ, который дублирует табличную часть исходного документа, программист №3 охренел и написал разгромную статью на инфостарте о программистах типа №2, которые понятия не имеют о нормальных формах в реляционных базах данных и лезут своими кривыми рученкам в конфу, даже не потрудившись получить нормальное образование, тем самым создавая технических долг для тех, кому потом приходится это оптимизировать.

Акт 6

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

Какая же тут мораль? Какое бы решение ты, программист 1С, не принял, всегда найдется другой программист (может, и не 1С, кстати), который его обосрет. Особенно это легко сделать, когда бизнес-процессы компании поменялись, и первоначальное решение уже перестало им соответствовать. А если кратко: "задним умом мы все крепки"
VOA2009; Ashandy; zqzq; ZOMI; manu; ProgrammistC; VladimirMelnychenko; anastasita_z; +8 Ответить
98. Aphanas 92 16.01.20 05:54 Сейчас в теме
Зачастую у программиста нет выбора, по какому пути идти. Ему дают 30 минут на галочку, а не 10 часов.
wowik; mgreat75; +2 Ответить
100. Painted 49 16.01.20 09:23 Сейчас в теме
Есть один жизненный момент в статье.
Был у меня на прежней работе программист, который писал код так, чтобы быть незаменимым. Каждый месяц его вызывали, чтобы закрыть месяц. Мы изучали новые вещи, а он закрывал месяц на древнем Фокспро.
Прошло 20 лет, он уже давно выпал из профессии и все довольно печально. А ведь неплохо начинал.
102. opx 794 16.01.20 15:13 Сейчас в теме
(100) Типичный злой программист был
101. Dragonim 139 16.01.20 10:23 Сейчас в теме
Если известен результат, то можно сказать стояли ли усилия его достижения.

Представьте, что в текущий момент времени происходит Акт №1. Ни кто ни про какие дальнейшие акты не говорил. Задач на развитие функционала не ставил. Сидите вы в момент событий акта №1 и думаете "Сделать то что сказали и продолжить выполнять другую работу, или начать креативить и решить следующих 10 возможных проблем которые может быть ни когда не случаться?"
mgreat75; +1 Ответить
103. gybson 16.01.20 15:25 Сейчас в теме
1. Согласование делается до момента поступления товара обычно, на стадии заказа, но допустим подразумевается приемка товара.
2. Какое может быть согласование в закрытом периоде?
3. Чем ордерная схема не подошла для приемки товара несколькими людьми?

Вывод - гоните в шею БА.
104. _OLEG 16.01.20 15:27 Сейчас в теме
ой большой вопрос какой хороший 1-й, или 2-й, 2-й делал кучу работы которая в 99% заказчикам и не понадобиться в дальнейшем, а куча ненужного для пользователя функционала увеличивает размер баз, а соответственно и стоимость железа и квалификацию пользователей и программистов для дальнейшего сопровождения программы и как итог, 2-й программист единственный который на этом заработает, а все остальные потеряют, т.к. программа и железо в конечном потребует столько бабла, что предприятие с 2-им программистом разорится и все останутся без работы))))). НЕ ДЕЛАЙТЕ ТАКОГО ЧЕГО ПОЛЬЗОВАТЕЛИ НЕ ЗАКАЗЫВАЮТ 2-й ПРОГРАММИСТ НЕ ВАНГА И НЕ МОЖЕТ ЗНАТЬ, ЧТО ПОНАДОБИТСЯ, А ЧТО НЕТ И ВЕДЕТ К НЕ ОПРАВДАННЫМ ЗАТРАТАМ.
109. UnderCIL 16.01.20 20:55 Сейчас в теме
Вижу нужен программист 4. Который заказчику разжует на пальцах, чем чреваты галочки в документах и их изменение. Немые программисты 1 и 2, конечно не обсудили с заказчиком видимые горизонты изменений. Возможно, все закончится на акте 1 и смысл в 10 часах работы отсутствует. Кроме того, программист №2 явно усложнил логику системы, теперь надо учить пользователя пользоваться логикой тратить часы и др., а если пьеса из одного акта без антракта - то смыл?
Опытный, выжмет из заказчика планы развития объяснит ему, что надо, и надо ли вообще, и только на основании полученных данных примет решение солидарно с заказчиком. Возможно между первым и третьим актом.
Тогда флажок "Согласовано" будет автоматом записываться в регистр с данными о пользователе, сделавшем запись и времени этой записи, а для каждого следующего пользователя, открывшего документ система будет выводить только флаг его согласования на основании регистра. Тратим 4 часа и кроем двух первых программистов, минимизируем участие пользователя (нет надобности вводить документ "Согласование") и расширяем функционал, хоть для тыщи согласующих.
110. check2 354 16.01.20 21:52 Сейчас в теме
Автор переложил смысл пословицы: Не всё хорошо, что дорого, но то что дёшево - точно дерьмо. И за это ему спасибо и уважуха. А ещё бы статью бы этого автора да в уши моему руководству...
114. Bassgood 1425 17.01.20 00:36 Сейчас в теме
Не существует "хороших" и "плохих" программистом, также как "хороших" и "плохих" людей - это все субъективная оценка, которая зависит от множества факторов, касательно программиста - его квалификации и опыта, срочности и сложности решаемой задачи, его профессиональной и материальной мотивации, отношений с заказчиком и т.д., нельзя что-либо делить на "черное" и "белое" - в одной ситуации и с одной точки зрения это будет "белым", а в другой ситуации и с другой точки зрения будет "черным" - все зависит с какой колокольни смотреть на все это дело, в этом мире все относительно и небинарно.
120. vadim1011985 99 17.01.20 09:45 Сейчас в теме
Итак заказчик ставит задачу: Добавить галочку "Согласовано" в документ поступление товаров.


Программист 2 Создает документ "Согласование" + табличную часть "Товары", делает регистр накоплений "Согласование" и описывает логику заполнения табличной части
.

А ничего что задание не выполнено -галочки в документе нет

И дальше происходит такой диалог между Заказчиком (З) и Программистом(П)

П: «задачу выполнил . я добавил документ согласование» время 10 часов

З: «Стоп , какой документ Согласование , мы же просили добавить просто галочку в документ поступление товаров. Мы не будем оплачивать вашу работу так как она не соответствует поставленной задаче)
mgreat75; +1 Ответить
121. BruSeV 17.01.20 09:46 Сейчас в теме
Несомненно, описанные в статье типы программистов присутствуют в жизни, все их встречали. А многие даже были в этой роли (и даже во всех в разное время). Спор вызывает, видимо, затронутая тема справедливости: программист 1 получает хороший бонус при малых затратах, программист 2 наоборот (при этом зачастую отрабатывая "технический долг"). Программисту 2 обидно! Но в жизни все происходит наилучшим возможным образом, для всех участников события сообразно их этике и нравственности.
Программисту 2 можно утешать себя тем, что без него все эти системы, где он не приложил руку, давно бы рухнули. А осознание, что ты делаешь хорошее дело для всего общества, оно дороже сиюминутной выгоды!
125. alexnikolas 63 17.01.20 11:24 Сейчас в теме
прикольная статья. комментов много. я бы добавил:
- а еще есть вариант когда заказчику действительно хватило галки и он нифига более не попросил за 5 лет работы - программист 1 победил.

https://translate.google.com.ua/?hl=uk&tab=iT1&authuser=0
Bassgood; opx; +2 Ответить
126. qwinter 671 17.01.20 11:26 Сейчас в теме
Программист 4.
Акт 1: Делает регистр "Документ, Согласован, Ответственный", выводит галки на формы документов и списков - тратит 30 минут.
Акт 2: Ничего не делает.
Акт 3: Ничего не делает.
Акт 4: Ничего не делает (галочка то на форме списка уже есть)
Акт 5: Добавляет регистр "Документ, КодСтроки, Согласован, Ответственный", выводит на формы, изменяет логику записи в первый регистр - тратит 30 минут.
user797130; mgreat75; +2 Ответить
141. пользователь 30.01.20 16:43
Сообщение было скрыто модератором.
...
129. Воль 17.01.20 13:29 Сейчас в теме
Мне очень понравилась статья, тема. Правда с выводами автора по поводу того, кто хороший, кто плохой, не соглашусь.
Как раз главная ценность статьи - вывод, что "как оно по уму" - предсказать почти невозможно! ( Даже в конкретном случае, не говоря о "в принципе".
Можно сказать, что для фрилансеров (разовые задачи) - однозначно вариант №1 лучше, конкурентнее, как минимум. Для кадрового программера... тоже не однозначно. Если только по удобству для пользователя варианты окажутся равны, тогда - да, №2.
И это, в общем-то, не парадокс. Просто - пересечение идеального мира булевой алгебры и реального мира людей )).
130. shard 279 17.01.20 16:17 Сейчас в теме
Классический выбор заказчиком двух пунктов из "1) быстро 2) качественно 3) недорого".
Не рассмотрен вариант разграничения прав на галку. И есть еще вариант реализовать галку "согласовано" через доп.реквизиты - это похоже уже "ленивый" программист (хотя программирования тут нет абсолютно). В случае УТ 10.3 - доп.реквизитов нет, но есть свойства и категории.

Случай из жизни: заказчику необходим контроль за наличием бумажного документа к реализации. Варианты реализации (оставляю суть):
1) РС с полями "документ" и флажок "документы в порядке". Когда документ проверен - создается запись регистра.
2) РС с полями "документ", флажок "документы отсутствуют"и подписка на событие проведения документа с созданием записи регистра. Когда документ проверен - запись регистра удаляется.
РС обусловлен дополнительными требованиями. По времени реализации оба варианта примерно одинаковы, результат для заказчика одинаков. Но первый вариант пришлось переделывать на второй.
131. meskalin 18.01.20 17:14 Сейчас в теме
Хороший и плохой - оценочные суждения. Хороший для кого? Как специалист, для представителя клиента, для бизнеса клиента?
Да и критерии "хорошести" и "плоховости" в разных системах оценки даже в одних ролях могут быть разные.
132. opx 794 18.01.20 17:41 Сейчас в теме
(131) Очень философски. По мне хороший тот, кто после себя меньше технического долга оставляет
135. paramedic2 21.01.20 10:57 Сейчас в теме
Весьма спорная статья.
Добавим теперь Акт 6 (или 4.1) Вносятся изменения в первичный документ.
Программист 1 дописывает снятие галочек согласования при изменении строки. Тратит 30 мин.
Программист 2 пишет логику отслеживания изменений в исходном документе, пишет логику внесения изменений в свой документ согласования, изменения в регистр согласований. Тратит 10+ часов и получает монстра.
Что касается Акта 4 - Программист 1 ничего бы не писал. Он просто настроил бы условный формат списка документов с подсветкой несогласованных.
136. black_wizard 21.01.20 13:36 Сейчас в теме
137. jour 16 22.01.20 15:55 Сейчас в теме
Программист №2 видимо не все возможности платформы знает.
По хорошему нужно было настроить согласование через бизнес-процессы, добавить ответственных, сделать механизм оповещения, написать мобильное приложение (вдруг согласующий в отпуск уйдет)
Любую задачу одной галочки можно превратить в большую и хорошо оплачиваемую.

В итоге: критерий плохой/хороший программист определяется по способности генерировать объем.
Так что программист №2 на верном пути.
mgreat75; +1 Ответить
138. Ashandy 23.01.20 15:25 Сейчас в теме
Проблема программиста №2 в том, что он не смог или не захотел объяснить заказчику. Это не говорит, что он плохой. Можно быть гением, но аутистом или социофобом.
Если у него с этим (с объяснением) проблема, то пусть за него это делает консультант или другой "специально обученный человек"
139. acanta 23.01.20 16:02 Сейчас в теме
Мы все стараемся быть незаменимыми.
142. user797130 30.01.20 16:45 Сейчас в теме
ИМХО, а все беды от хреновой постановки задачи.

Как говорится: "Без внятного ТЗ результат - ХЗ".
146. Vidz 05.11.21 15:34 Сейчас в теме
Обычно стараюсь делать доработки:
1) От простого к сложному, в порядке возрастания:
- Используем те объекты прикладного решения, что есть (даже если они называются "не так как хочется видить заказчику"), но в итоге позволяют сформировать нужный отчёт без необходимости тратить +100500 рабочего времени
- Внешняя обработка/отчёт и т.д.
- Расширение
- Вмешательство в конфигурацию + расширение
2) Аккуратно выпытывая, "а зачем это вам?" т.к. есть категория заказчиков которые "сами решили", что им нужна эта галочка (хотя, вполне возможно, это уже реализовано, но выключено функиональной опцией; или для какого-то элемента "контроля" который можно проявить свосем в другом месте и иным способом)
3) Прикидывать по времени и цене для клиента, предлагаая несколько вариантов "попроще" и "подороже" (не забывая про пункт 1 - минимум вмешательств)

В сожалению, часто сталкиваюсь с жалобами клиентов, что их развели как нуба на СТОшке купившего первую машину...
Из последнего: переход с БП 2.0 на БП 3.0 (типовая конфа, небольшая база - бух на аутсосрсе) - 4 часа работы. Просто за то, чтобы скачать обновления для перехода с 2-ки на 3-ку, сделать бэкап и, возможно накатить новую платформу.
147. user1654599 07.10.23 14:43 Сейчас в теме
Вообще я бы сделал бы по другому. Создал бы справочник, согласованный товар, в сам же справочник товар ввел бы галку согласновано и фамилии согласующих поступление, затем бы создал бы документ накладная, создал бы независимый регистр сведений, с измерением товар и ресурсами, количество, цена, согласновано элемент булево, ФИО согласующих дата согласования, затем документ акт согласования, которая бы включала в себя следующие реквизиты в табличной части "товар"; тип-ссылка на справочник согласованные товары, "количество"; тип-число, "цена", тип- число, "сумма", тип-число, "дата согласования"; тип-дата; "ФИО, согласующих"; тип-строка; "наша "сторона"- тип справочник ссылка "уполномоченные работники" либо в иерархическом справочнике работники создать группу работники уполномоченные на согласование; "сторона контрагента"- тип ссылка справочник уполномоченные представители контрагента". Затем создаются процедуры заполнения в табличной части документа акт согласования сведений при выборе товара, после этого создаётся соответствующий регистры накопления и регистры сведений и лвижения по ним акта согласования в конструкторе движений, а затем отчёты по к указанным регистрам накопления и регистрам сведений. Да это очень сложно, может показаться на первый взгляд, но по другому никак.
Оставьте свое сообщение