Ошибка первая
Первая и, наверное, самая частая ошибка — это то, что программисты забывают использовать регистры накопления. Заключается это в том, что, написав новый документ или доработав старый и произведя довольно сложные обсчеты, результат не пишется в регистр накопления, а остается храниться в документе. За такое на сертификационных экзаменах бьют по шапке. И вот почему: для того, чтобы потом сформировать отчет по необходимой информации, приходится лезть в документ пускать заново все механизмы обсчета, чтобы получить результат, который по замыслу разработчика можно увидеть только зайдя в документ. То есть запросом такую информацию нельзя получить никаким образом. А информация требуется самая разнообразная: это и сумма товаров со скидками, и зарплата сотрудников, и различные итоги. Решается это довольно просто: берем, записываем результаты обсчета в регистр накопления, или регистр сведений, смотря по типу информации, и потом легко достаем ее запросом.
Ошибка вторая
Вторая ошибка: курочить типовые механизмы. Или я программист и все могу запрограммировать. Бывает, что даже лень искать, проще написать. Но ошибка заключается в том, что дорабатывают то, что дорабатывать не надо. Философский анекдот в тему. Сын приходит к отцу программисту и спрашивает
Сын — Папа, а почему солнце каждое утро встает на востоке и заходит на западе?
Папа — Ты уверен?
Сын — Да.
Папа — Ты проверял?
Сын — Да.
Папа — И каждое утро встает на востоке и заходит на западе и никогда не бывает по-другому?
Сын — Да.
Папа — Сынок ничего не трогай, работает и ладно.
Наиболее щадящим способом внесения изменений является добавление новых объектов в виде обработок или документов, которые в автоматическом режиме формируют типовые документы и справочники. Например, необходимо разработать удобную форму для работы менеджера для заказов на натяжной потолок, необходимо учесть и комнаты, и варианты, и выписку счетов на разные комнаты отдельно, и на разные варианты и заказ материалов. Неправильно будет раскурочить документ «Заказ покупателя» и, вывернув его наизнанку, таки добиться результата. Последствия будут в виде трудностей при обновлении и непредсказуемых последствий, когда надо будет учесть все обращения к документу «Заказ покупателя» по всей конфигурации. Правильнее создать отдельный документ «Заявка на потолок», в который будет вводиться информация по комнатам и вариантам с расчетом сумм, а из него формировать типовые документы «Заказ покупателя». Кстати смотри выше ошибку №1: результат обсчета документа «Заявка на потолок» надо сохранить в регистр накопления, например «Заявки на потолок». Измерения будут Заявка, Комната, Номенклатура. Ресурсы: Количество, Сумма. То, что заявлено новым документом, плюсуется, а документом «Заказ покупателя» списывается как ушедшее в работу. При этом всегда можно будет легко добыть информацию о том, что мы уже сделали по заявке на потолок, а что еще нет. Подобные задачи могут быть и при продаже кухонных гарнитуров, и сантехники, и при работе на производстве. И, возвращаясь к ошибке №2, не надо курочить конфигурацию, думая, что все можно запрограммировать. Верный признак того, что вам требуется пересадка рук на плечи, это то, что в конфигурации перестали работать типовые отчеты.
Ошибка третья
Третья ошибка: попытка автоматизировать бардак. Догма программиста: Бардак не автоматизируется. Результатом будет автоматизированный бардак. Если раскрыть философский смысл, то если вас просят автоматизировать склад, то надо настоять на том, чтобы там навели порядок. Зачастую ленивые сотрудники обманывают свое начальство, заявляя, что они не могут быстро найти что надо, потому что нет автоматизации, и поэтому инвентаризацию толком выполнить невозможно. Все это связанно со сложными отношениями между работниками и работодателями: нет четких договоренностей о том, как взыскиваются пропажи с материально ответственных лиц. Поэтому работники боятся, что на них повесят все, в чем они виновны и не виновны, и саботируют любую попытку провести инвентаризацию. И вот вы стоите, и обстановка такая:
1. Заказчик, который хочет автоматизацию, потому что думает, что она поможет устранить бардак,
2. Сотрудники, которые не хотят порядка, потому что не знают, как им аукнется, и сколько с их зарплаты будут снимать.
3. Вы, понимающий, что сама по себе автоматизация им не поможет, потому что сотрудники ее будут саботировать и говорить, что программа плохо работает.
Выход в такой ситуации это варить кашу из топора. Напомню содержание сказки: солдат пришел в избу на ночь и хотел бы поесть, а хозяйка кормить его не хочет и делает вид, что ничего у нее нет. Солдат предлагает ей сварить кашу из топора и потихоньку начинает просить ингредиенты: сначала соль, потом маслица чуть, потом молока, ну и крупы надо добавить. Вынул солдат из каши топор и поужинал. Как это реализуется на практике: вы говорите, что нужно вносить первоначальные данные и, чтобы не перетрудиться, надо все товары расставить аккуратно по полкам (сотрудники, слыша, как им говорят о том, как меньше работать, с радостью соглашаются). Далее нужно внести структуру по группам, а как ее вносить? Нужно выбрать способ систематизации: это либо по поставщикам (актуально для одежды и обуви), либо по типам товаров (соки, крупы, консервы). Что же это значит? Опять же для удобства надо расставить товары по полкам, так, чтобы они были так же, как в справочнике. Тут надо напирать на то, что это для того, чтобы меньше делать, и не давать всплывать мысли о том, что это для наведения порядка. Далее надо осторожно, потому что работники могут пронюхать, что вы затеяли. Лучше дать им провести этот первоначальный внос данных и даже дать им поработать, но с условием, что они должны провести инвентаризацию через месяц. Как это сделать? Надо поговорить с заказчиком, вскрыть ему все карты и сказать, что так и так, через месяц инвентаризация. Это экзамен по тому, как ведется учет, потому что можно поставить компьютер, а бардак останется. И это чревато тем, что вы будете продолжать терять товары. На это фразе заказчики становятся очень серьезны и, если надо, они стену головой пробьют, но инвентаризацию сделают. Потом можно позвонить ему и спросить, как дела и порекомендовать ему, чтобы он заставил работников вынуть из пыльных углов все, что там запрятано. И тогда можете считать, что заказчик будет вам благодарен, потому что он получит и порядок, и автоматизацию, и порекомендует своим знакомым. Это требует затрат нервов и времени, но это куда честнее и правильнее, нежели денег срубить и убежать, а вы сами решайте, как с этим жить.
Ошибка четвертая
Четвертая ошибка — неконтролируемый доступ к складу для лиц, не несущих материальную ответственность. Это чаще актуально для производства. Например, это любой общепит, рекламное агентство (они делают вывески и световые короба и много чего всего), торговля мебелью под заказ. Серьезные проблемы ожидают того, кто позволит работникам таскать со склада все, что им заблагорассудится, потому что они заранее не могут сказать, что им понадобится: они там не учли, что им надо, сям не учли. Найти потом, что куда пропало, дело невозможное, люди будут хлопать честными глазами и делать вид, что все ушло в производство. Поэтому для производства организуется отдельный склад, для общих остатков отдельный склад. И по мере надобности со склада общих остатков на склад производства делается перемещение. Причем нужен отдельный кладовщик для склада общих остатков. А на складе производства проводить еженедельные инвентаризации. Пример реальный из жизни: в супермаркете жарили курицы гриль, и из-за неверных данных в технологической карте шло неверное списание остатков тушек курицы. За 3-4 недели накопили на остатках 105 кг курицы, провели инвентаризацию и не обнаружили эти 105 кг. Со всего персонала списали ровным слоем. Я их спросил, вы хоть одну курицу съели? Ну, раз уж высчитывают. Отношения были доверительными, они сказали, что не прикоснулись. Я им склонен верить. Так что инвентаризации надо делать каждую неделю и не пренебрегать, а то потом никакое расследование правды не найдет. Так как склад производства небольшой, то и бардак там за неделю большой образоваться не может, все быстро подсчитывается и горы товаров переворачивать не нужно. Если есть возможность внедрить учет заказов, надо это делать. В рекламе и мебели это возможно через организацию штрих-кодирования документа «Заказ», кладовщик отпускает материалы только на заказ, считывая штрих-код с документа, и всегда видно, что куда употребили. В «общепите» нет возможности подсчитать, сколько мяса ушло на пирожок, который купил покупатель. Расчет ведется на заказ в производство на, например, 200 пирожков, и на этот заказ выписываются ингредиенты. Учтите, не все так радужно: масло, приправы и прочее всегда есть на кухне и идут скопом, поэтому сложности в учете все равно будут.
Итого: а как с этим бороться? А бороться просто: надо идти и сдавать сертификационные экзамены, там и будет понятно, кто из чего сделан. Там будет сторонняя оценка качества по стандарту, а не просто свое мнение о том, что я крутой программист, давайте мне королевские почести. Обычно после экзамена человек перестает творить уж совсем несусветные вещи и делает качественную работу.
тут не столько про ошибки программистов, сколько про подтирание соплей кладовщикам 🙂
(1) vano-ekt, согласен, но всё равно было полезно познакомиться с материалом статьи
(1) vano-ekt,
Поскольку я уже имею сертификаты 1С, теперь могу заявить: Наличие сертификатов ничего не значит, а их выдача (как и аттестация у пожарников, у МЧС, у экологистов) это просто «чёс» денег.
Про организацию склада обычно надо решить следующие задачи:
1. Конкурентное, хронологическое резервирование товаров — резервирование товаров конкурентных отделов (даже в минус) при этом свободно отпускается в порядке хронологии резервирования (включая такие решения, когда клиент позвонил сначала зарезервировал 2 штуки…потом отказался от одной…потом попросил добавить 3 и все потом выписать одним документом (счетом на оплату или фактурой)… а между изменениями резерва другой клиент/отдел так же зарезервировал этот товар)
2. Запрет на изменения документа/изменения остатка после подтверждения отгрузки/получения кладовщиком. Тут главная парадигма: «изменения остатков в на складе должно осуществляется только с разрешения кладовщика-МОЛ, иначе доверие к учетной системе не может быть.»
3. Ячеистое хранение (любая методика: по факту или справочное).
4. Поиск документов по штрих коду.
5. Система разбора недостач и пересорта при перемещений товаров между складами (когда со склада на склад отправлено одно количество, а пришло другое). Тут надо учитывать, что остатки должны уменьшиться у отправителя на то количество, сколько он считает что отправил, а у получателя — на то, сколько он по факту получил. Разбор излишек или недостачи при перемещении уже производится «постфактум», другими службами (например ревизионным отделом по данным камер наблюдений при погрузке и разгрузки).
6. При наличии филиалов организация склада комплектации, а так же организация хранения малых ежедневно пополняемых остатков товаров для склада комплектации, а при ячеичной системы хранения ее ротация/изменения размеров с учетом частоты использования товаров из ячеек или распределения нагрузки (зависит от организации).
7. Расчет количества позиций, ассортимента, веса и объема в накладных для статистики или транспортной логистики, как следствие — учет рабочих показателей кладовщиков и грузчиков по перемещенным товарам.
Вроде все задачи которые приходилось реализовывать.
Давеча код наблюдал в правленной бухгалтерии.
Суть такая: в момент списания ТМЦ в бухии, товарищ запрашивает себестоимость из УТ 10.3 FIFO там.
Т.е. товарища совсем не колышит, что он забрал себестоимость по какой-то одной партии. Я в шоке был.
Про ошибки программистов 1С:
Все ошибки происходят из того- что системы учета, это я про типовые решения 1с, стали в угоду универсальности (всеобъемлимости) настолько сложными… что в качестве решения нам предлагают «добавление новых объектов в виде обработок или документов, которые в автоматическом режиме формируют типовые документы и справочники». И это понятно почему… практически нет специалистов, которые осознают все внутренние механизмы работы 1с (как это было возможно с 1с 7.7 комплексная). Никто не может сказать точно («на лету»)- какие регистры в каких ситуациях должны производиться изменения. Каждый раз изменяя типовую 1с приходится разбираться. Сами сотрудники фирмы 1С, разрабатывающие типовые платформы 1с не видят всей картины в целом, а используют модульный подход, что порождает нагромождения и переделки из-за ограничений модулей. Это же уму не постижимо… то добавляют регистры, то спустя время удаляют их же с необходимостью перепроведения/дозаполнения всего. Программисты превратились в обычных кодеров, а не методистов и лепят заплатки.
Извините …крик души.
ps
На нашем предприятии, найдены программисты-методисты-бухгалтера в одном лице и на базе хорошего движка 8.3 разрабатываются более простые системы учета полностью соответствующие нашим потребностям. Работает в сотни раз быстрее, занимает в десятки раз меньше объёма — при этом выполняется весь необходимый нам функционал и даже больше.
(6) Так и не надо воспринимать коробки, как законченные решения от фирмы 1С. Это примеры и все.
Есть платформа и примеры написания на ней.
Берешь платформу и вперед. Тогда «…Работает в сотни раз быстрее, занимает в десятки раз меньше объёма» и функционал более реальный.
(1) vano-ekt, полностью согласен.
(3) dima_home, блин… а я думал за 12 лет что-то поменялось :0
Хотя по отзывам некоторых коллег, которые все таки получали сертификаты, за них хотя-бы спрашивать начали серьезнее. Сам в профессии 16 лет и, например при приеме на работу, для меня наличие сертификата у программиста не дает преференций. Т.е. это как получить права на управление автомобиля, не значит научится водить.
Статья взята на заметку. Хотя не соответствует заголовку, т.к. вообще не про детские ошибки. Но факты изложенные вполне актуальны и про них нельзя забывать.
Статья интересная. Но заголовок, конечно, не по теме
Если результат обсчёта хранится в документе, то никаких проблем нет в том, чтобы вытащить этот расчёт запросом из реквизита документа.
Ну, вот мы и пришли к сути статьи. И не стоило так много писать.
(9) kiros, то есть водителя на Камаз можно брать без прав? Чревато…
(3) dima_home,
Эксперта уже сдали? )
(3) dima_home, смотря каких сертификатов, если профессионал, то мож и не, но вот спеца по платформе, уже наскоком не сдашь, нужно знать какие объекты когда и как методологически правильно использовать, не подготовленный человек такой экзамен не сдаст принципе, а именно в процессе этой подготовки человек и приобретает необходимые базовые навыки, на которых уже можно дальше развиваться в данной области
Позволю себе не согласиться с Автором статьи, в плане заголовка и ее сути.
Проблема первая: Не все рассчитываемые данные нужно записывать в регистр, некоторые можно и нужно оставлять в документах. Основным критерием является где и когда будут использоваться эти данные: вывод (журнал документа, его форма), будут ли эти данные выводится в отчеты, отбор. Вывож: Семь раз отмерь, один раз отрежь.
Проблема вторая: Здесь все зависит не только от программиста, но и от того как будет поставлена задача. например придет Иван Иванович и скажет а можно мне тут галочку, очень надо…. потом Маша Петрова а мне чтоб вот тут вот кнопочку нажать и все увидеть… а спустя какое то время документ превращается в монстра. И по хорошему данный функционал давно просится в отдельный документ, но заказчик уже за это платить не готов.
Проблема третья и четвертая: организационная и к программированию не имеет ни какого значения(прошу не путать программистов и внедренцев все в одном).
Последние два пункта никак не вяжутся с работой программиста.
У вас программист за доступ к складу отвечает?
И как
поможет исправить четвертую ошибку программиста?
Ерунда какая-то написана, на целую статью!
Вообще со статьей не согласен!!!
Я наемный программист или директор по вызову. Все проблемы на складе в плане организации труда должен решать уполномоченный на то человек. Я был в подобных ситуациях много раз.
Я: Ок, вот вам новые сущности, поля для ввода заполняйте (показал хозяину, обучил кладовщика, закрыл часы, срубил денег, ушел)
… прошел месяц..
Хозяин: Овно полное твоя система, она нам не подходит
Я: Так вы ничего не заполнили в справочнике, в документах складски не проставляете ничего
Хозяин: Потому что не удобно, кладовщики отказались заполнять, у них времени на это не хватает.
Я: Ну не заполняйте, но без этого адресного склада не бывает.
Хозяин: Да… ну пусть оно само тогда заполняется.
Я: Но это тогда не адресный склад, ведь адрес в прграмме может не совпасть с фактическим стелажом
Хозяин: Ну давай так сначала попробуем
Я: ОК (показал хозяину, закрыл часы, срубил денег, ушел)
ну и кто в моей истории муд@к?
По логике автора — Я, т.к. не пошел убеждать склад, что им надо работать разными хитростями
По моей логике — хозяин. Не можешь мотивировать людей — сам виноват. Хочешь, чтобы я это делал так и скажи «мне надо построить людей на складе, вот тебе полномочия, можешь их премировать и штрафовать», а не «я хочу адресный склад… спрограммируй»
Вообще, ощущение, что автор идеалист, оторванный от реальной работы в «поле» по часам. Может на «жирных» клиентах сидит, которые платят за то, чтобы он по складу ходил с умным видом и строил бы там всех.
Может от него как от программиста толку 0 и он только обсирает труд других.
Либо вообще из офиса не выходит, обложился сертификатами и книжками и носу не кажет на улицу.
….
я не знаю, но от реальности чувак оторван сильно. А те кто ему звездочку поставили, либо не читали, либо сами такие же оторванные от жизни «правильные» программисты.
(10) kiros, согласна. В принципе мы все в курсе изложенного, а автор систематизировал. Надеюсь на продолжение списка ,ведь тут далеко не все
(20) monkbest, поьлзователь не знает чего он хочет, пока не увидит то что получилось. В данном случае, за то что хозяин склада не умеет правильно мотивировать сотрудников он и платит программисту за очередные хотелки. Многие с таким положением не соглашаются (примеры знаю) и уходят от таких заказчиков. А вот те кто реализуют такие хоелки каждый раз — наживаясь — долго то тоже не задерживаются, а пришедшим на их место потом долго разгребать приходится…
На мой взгляд, как программиста, работающего с клиентами, к тому же разными, капризными и не очень, но зачастую очень «жадными», могу сказать, что третья и четвертая — это не ошибки, а некие утопии вырванные из контекста менеджера-управленца но никак не рядового одинэсника у рядового клиента.
Я могу сказать клиенту в ответ на ТЗ, что так нельзя потому-то и потому-то, а можно вот-так в соответствии с тем-то. И то не всегда. Пример — войсковая часть, где действуют не законы физики и инструкция 157н, а приказы, письма и записки руководства МО. Есть письмо — делаем так, а не иначе, значит я должен сделать автоматизацию именно так и в тех условиях, как диктует заказчик, а не идти и обучать службу РАВ правильно (с моей точки зрения) хранить боеприпасы.
(24) anthonyv, хорошо когда есть ТЗ, а многие и такого то не предоставляют. И военные — это другое дело.
А для того, чтобы программа работала хорошо, должно быть четко сформулированное ТЗ, куда потом можно ткнуть носиком заказчика, который говорит: вот ты мне тут сделал документ, но он неправильно работает, здесь вместо А должно быть Б. Берем ТЗ (пусть даже схемка с каракулями на листе бумаги, но ее видел, а еще лучше оставил автограф заказчик) и показываем — здесь должно быть А, хотите Б — будет стоить столько-то… Делов-то. Надо беречь нервы и поменьше напрягать себя явно чужими проблемами.
(26) anthonyv, эх.. всем бы так. Бывает быстрее быстрее сделать надо… и вот тут то и происходит наколка — ТЗ так и не появляется… ну да это дургой вопрос…
(25) Tiger86, Военные здесь для более яркой иллюстрации. Среди рядовых складов, магазинов и просто фирм очень часто наш бардак это их порядок, в котором они как рыбы в воде. А попытаешься привести их к общепризнанному порядку — кранты работе фирмы на пару дней и программист в районе муладхары.
(3) dima_home, «Экзамен 1С Профессионал — Приколы»
(28) anthonyv,
Логистическая система KANBAN
ЗЫ
(6) dima_home,
«Это же уму не постижимо… то добавляют регистры, то спустя время удаляют их же с необходимостью перепроведения/дозаполнения всего. Программисты превратились в обычных кодеров, а не методистов и лепят заплатки. » —
полностью с Вами согласна, превратили 1с в огромную не оптимизированную, не прозрачную махину…
Ошибка №1 может проявиться когда действительно надо обращаться к ОСТАТКАМ! Для того, чтобы получить сальдо нач. на определенную дату без использования регистра остатков надо перелопачивать все документы «с начала времен» до этой даты! Если нужны просто обороты — их и по документам можно получить (если умеете грамотно писать запросы). Особенно если не требуется сложных пересчетов с обращением к периодическим реквизитам справочников или константам. Например «Курс валюты» — но если его записать в реквизит документа, то избавите себя от проблем.
Адресный склад делается и быстрее и проще с RFID. Даже маршруты прокладываются для оптимальных телодвижений. Вопрос в стоимости решения.
Ещё одна жж-заметка, которая не пойми почему выдаётся за статью. Я такие могу каждую неделю кропать, по итогам работы своей фирмы. Почему это не в Life, загадка. Почему за эдакий огрызок личных впечатлений и махрового субъектива пополам с очевидностями ещё и плюсят — вдвойне загадка.
(34) Yashazz, потому-что стали теперь видеть все эти проблемы. Вообще верно заметили — статья больше про выяснение отношений с руководством (вернее как нужно строить рабочие отношения. И нужно это в первую очередь тему, кто хочет двигаться дальше по карьерной лестнице. Всю жизнь программистом не будешь, если хорошо знаешь учет.
Дальше первой ошибки (вернее даже начала описания первой ошибки) не читал. Сразу видно что «ниочем».
(3) dima_home,
На самом деле вы не совсем правы. Абсолютно то же самое можно сказать про получение высшего образования — вы можете ничего не изучать, купить диплом и быть ничего не знающим специалистом с высшим образованием.
Но если вы реально получали знания, готовились к экзаменам и самостоятельно их сдавали — польза будет несомненной. Лично я готовился сам, прорешал большую часть задач по платформе, сдавал честно. После этого пришел на предприятие, где сидели люди со стажем работы программистом 1С по 5-10 лет и могу сказать следующее: конечно опыта решения всяческих разнообразных задач у них больше, но вот за то, как они их решают реально иногда хочется оторвать руки :). Но опыт дело наживное :).
(37) MorningStalker,
Вчера исправлял косяк в обработке, для сдачи отчетности в Росалкогольрегулирование. Обработка куплена за хорошие деньги, но никто не помнит где и как. Видно что делал трудолюбивый человек, но который совершенно незнает как работает регистр ОстаткииОбороты. Стараниями автора, его труд упорно увеличивал остатки на начало квартала в рандомное число раз. Я потратил 3 часа на исправление его ошибки. Рад бы указать на баги (получив таки свой небольшой гешефт), но он не оставил координат для связи в коде.
Вот ещё одна детская ошибка. Он лишился обратной связи.
(3) dima_home, отчасти согласен. На специалиста по платформе сдать достаточно сложно, это стимулирует коллег учиться.
Но порой сертификаты такие бараны получают, диву даюсь.
(6) dima_home, а я не для одного предприятия серъезно доработал типовую. Один. Это менее ресурсоёмко. Типовые содержат очень хорошие механизмы и даже методологию местами, недальновидно это выкидывать.
Пока нашел только один пример из RL, где имело смысл писать свою конфу с нуля — логистический бизнес на ЖД.
(23) Tiger86, что за ярлык «наживаясь — долго то тоже не задерживаются»?
во-первых никто не наживается, а делают свою работу, делают её хорошо и не дорого. Любой труд должен быть оплачен, ведь по сути Вы же платите в магазине за молоток, не зависимо от того сумели Вы им забить гвоздь или нет.
Во-вторых, почему долго то тоже не задерживаются, конечно, после фиаско «хозяин» попробует сменить программиста, все мы люди, мы всегда ищем проблему в других. Еще я уверен, что как и автор топика, как и Вы, скорее всего, когда к Вам придет «хозяин» со словами «мне вот тут нахерачили неудобного», Вы скажите «да он рукожоп, а я про, я вам все ща по всем стандартам сделаю ISOхуесо…». Хозяин развесит уши, в душе засияет надежда, на красивый склад… но все придет к тому же самому, что склад придется заставить работать, и что люди «грамотно составляющие ТЗ» будут стоить дороже в разы, и что длиться это долго, пафосно, и что результат получается тот же самый… Если «хозяин» поймет это до заключения договора с новым программистом, то он позовёт старого на новую попытку, ведь со старым они уже не одни грабли съели и понимает он его с полуслова.
Поймите главное, не от рукожопости и жадности программиста рождаются системы монстры. Как правило от отсутсвия бюджета у заказчика. Мелкий бизнес свои деньги просто так не отдаст.
(26) anthonyv, системы монстры как раз появляются из-за отсутствия ТЗ. Но винить программиста тут нельзя.
1. Разработка по ТЗ всегда много дороже, ведь мы не будем бесплатно сидеть и писать ТЗ, а потом согласовывать его неделями, все потраченное время будет включено в счет. Особенно разница ощутима на мелких доработках. Трудно обвинить заказчика в желании сэкономить.
2. ТЗ чаще всего пишет исполнитель, и заказчик (особенно в мелком бизнесе) ничего в нем не понимает. Тыкать заказчика потом носом в пункты ТЗ в этом случае — некрасиво. Но и работать бесконечно исполнитель тоже не согласен.
Отсюда и рождается вариант обслуживания на почасовке, при котором разработка приобретает итерационный стиль, где нет четких постановок, сплошные пробы и ошибки и как-только заказчик становится довольным, работы тут же прекращаются. Хотя часто работы надо продолжить, потому что еще не все учтено, не все дописано и оптимизировано. Но заказчик уже доволен и финансовый краник на время закрыт, пока не аукнется это самая «недоработка»
(28) anthonyv, это точно, у всех разное представление о порядке.
(1) vano-ekt, Если не «подтирать сопли» пользователям, иногда и кулаком и периодически не втирать им «шейную мазь», то зачастую они со своим «профессионализмом» такую хрень создают в базе, что порой очень долго приходится работать «веником».
(0) + в целом статья понравилась. Заголовок не к месту, ибо под него подпадают только первые два пункта. Но пункты три и четыре называть ДЕТСКИМИ (!!!) ошибками ПРОГРАММИСТА(!!!) — это полная жесть, что и вызвало доставивший мне холивар в комментах. Так что подозреваю, что заголовок был подобран специально, чтобы обострить обсуждение=)
Пункты 3-4 переплюнули все виданные мной требования к Ты_жПрограммист-ам. Раньше от них хотели починки микроволновки и прочих знаний, присущих техническим специальностям, но в этой статье Ты_жПрограммист предстаёт ещё и успешным дипломированным управленцем=)
Т.е. знания эти конечно не помешают, в том числе и для зарабатывания денег (как и умение чинить микроволновки, озвученное выше), но лично я, как суровый технарь =), не считаю их обязательными и тем более не назову их программистскими.
кстати да, согласен с (34) Yashazz, такие статьи в раздел лайф надо кидать
а в характеристике «кому» вместо программист выбрать Ты_жПрограммист =)))
Как бы занимаюсь этим периодически уже лет 10 лет , а тут глаза раскрыли — оказывается это невозможно
Ну и примеры из жизни
1. Бардак с остатками в оптовой фирме. Решение — строгая система прав, отмена проведения задним числом
2.Против пример. Бардак с остаткам в фирме учитыв посерийники. Анализ — невозможность в рамках текущего склада вести строгую отгрузку по серийникам
Решение — строгий учет по остаткам , отмена строгого учета по серийникам, но учет всех входящих и исходящих серийников на предмет совпадения в списках
3. Бардак с себестоимостью.
Решение отмена поскладского учета себестоимости, отмена проведения задним числом. Учет себестоимости по МОЛ отвеч за группу складов, перемещение между которыми строго ограниченно
4. Бардак с финансами. Решение : внедрена система согласования, внедрена эл подпись
и мнго других
Уверен , что у народа есть гораздо больше интересных случаев
По поводу бардака на складе: абсолютно верно. Привожу всем в пример одну фирму, которую я автоматизировал. Это была пивная оптовая база. так вот, там до внедрения автоматизации даже пустые бутылки сходились 1 в 1. А всё почему? Потому что директор один раз вгрел кладовщиков на ползарплаты за недостачу пары бутылок пива и вроде ящика пустых бутылок. С тех пор… Даже когда приезжали мы, хорошие друзья шефа и заходили с ним на склад — никто не давал ни бутылки, пока не принесем чек об оплате.
Статья полезна разве что для того, чтобы вспомнить, что еще встречалось в твоей уже прошедшей жизни, и возможно пригодится в дальнейшей.
Этакий катализатор, призывающий к действию остановиться и подумать, а вдруг ты где накосячил, и надо бы исправить.
У меня случаются темы с автоматизированным бардаком.
Про сертификат… из личного опыта: Рядом со мной сидела девушка (нет претензий к полу), сдававшая на эксперта…пришла с кучей шпор… при том сидела и все время спрашивала у окружающих как правильно… ведущие уходили с экзамена отставляя зал без наблюдения… по окончанию было видно что она не сдала, и осталась в зале разбираться. Уж не знаю как, но когда пришли бумажные экземпляры сертификатов, я приехав получать встретил ее-шедшая довольно с таким же сертификато… с тех пор я не верю ни одному сертификату…даже своему )), а принимая к себе в отдел на работу проверяю на практических задачах (запрещая при проверке пользования контрукторами).
Про ТЗ и прочие средства контрацепции для франчайзинговых компаний.
Из личной практики считаю (мое мнение), что при внесении изменений в по основными трудозатратами являются как-раз разработка ТЗ, а точнее трудозатраты на анализ сложившийся ситуации и выбора способов решения, и исполнить такое основательное ТЗ не составляет потом никакого труда.
По этому, предприятие заказчик, которая сама смогла глубинно изучить проблему изнутри и найти способ ее решения (дать грамотное ТЗ), как правило имеет в штате соответствующих специалистов и сама может решить вопросы по изменением ПО без привлечения внешних программистов.
Компания, где в кадрах отсутствуют такие специалисты — не может самостоятельно написать качественное ТЗ и учесть все нюансы, обречена на контакты с
распространителями товаров, сетевыми агентамифрилансерами и франчайзинговыми компаниями, где главная задача: «за наибольшие деньги произвести минимальные трудозатраты». А поскольку основные расходы — это невидимые заказчику трудозатраты на анализ его проблем и путей его решений, то такой анализ перекладывается на плечи некомпитентного заказчика, а изменения выполняются под прикрытием ТЗ. Очень часто программисты — исполнители, которые изменяют ПО, ничего не понимают в тех бизнес процессах, над изменением которых они работают.Отсюда и появляются такие решения, как:
РКО(сдача денег в банк), делает движения сразу и по кассе и по банку одновременно, тоже и при передачи из кассы в кассу,
ИНН и КПП в одном поле (для ранних конфигураций)
Как часто встречали вы такие переделки, как указание в печатной форме фамилии руководителя или товароведа (для ранних конфигураций) чтоб каждый раз не писать ручками…мало кто решался на радикальные изменения и создание справочника уполномоченных лиц для подписи документов с автопостановкой.
Недозаполнение полей документов, поскольку заказчик не знал, что эти поля можно расчитать автоматом (например Вес в ТОРГ-12)
Печать кодов товаров в виде кода справочника, вместо кода «вида товара» утвержденного статистикой в той же торг-12
Ввод доверенности в комментарии или в тектовые поля в ТОРГ-12, вместо справочника действующих доверенностей клиента.
и т.п.
ЗЫ: При приеме на работу, «долгий» фрилансер (франчайзер) сразу выдает себя в пробный период: любит клепать заплатки не разобравшись с первопричиной (максимум погуглить в инете) и работая по принципу «как скажешь, так и сделаю». Эти специалисты как правило быстро пишут код, но являются полными «импотентами», когда ставится общая задача типа: добавить учет лизинговых операция для сублизингодателя или учет договоров и судебных процессов по ним.
Не хочу никого обить…зарание извените, ВСЕГДА ЕСТЬ ИСКЛЮЧЕНИЯ.
(51) dima_home, я как-раз бывший франчайзи ставший фрилансером)В общем-то вещи вы правильные озвучили. Расставался с клиентам ибо «-долго решаются задачи, что там думать то?». Они возращались. Я переделывал за «скорострелами».
Вопрос возник. Как велся учет в 160 филиалах, пока вы конфу с нуля писали? Мне слабо представляется что все ждут. У меня на написание относительно простенькой (только управленческий учет) конфы для сети автомоек (VoIp, очередь, планшетики, скидки, расход материалов etc) ушло месяца полтора на постановку ТЗ и месяца два-три до опытной эксплуатации. Я где-то по пол дня работал над ней, бо оплата по факту сдачи-приемки была.
Да и второй вопрос, вот у вас там отдел. Как увеличивается скорость разработки от количества специалистов в вашем случае? Если постараться исключить тот факт, что сотрудники помогают не отвлекаться «по мелочам». Мне думается (я далеко не всегда 1Ской занимался), что 5 программистов + постановщик ТЗ = некий идеальный вариант.
Реузультат: У нас хорошо получилось, потому что я знал что нужно работодателю лучше, чем он сам. А руководитель проекта это понимал и пробивал наши решения наверх меняя всю архаичную систему работы на новый лад. Сколько недовольных воплей слышали от филиалов… но теперь ни одного палкой не загонишь обратно на старую 1с.
Хотел привести цитату:… как-то мне заявляет старожил из отдела закупа «сынок..поверь мне…я тут проработал 10 лет и знаю как у нас оформляются заказы»… на что я ему ответил: «что, мне хватило и месяца, чтобы понять, что вы за 10 лет так и не научились правильно оформлять заказы».
Вот не всегда получается соответствовать высокому уровню, особенно когда с тебя требуют сделать все уже вчера или в очень сжаты срок. Споры и выяснения отношений не помогают, разъяснения что так правильно, а так неправильно просто бесполезны. Вот с таким я столкнулся на новом месте работы. В результате делаю все на скорую руку, собирая все известные ошибки программистов 1С в одну кучу. Молюсь не столкнуться с этим кодом вновь….
Но не это является самым наболевшим у меня, а следующее:
1) Презираю, еще раз презираю код перенесенный с 1С 7.7 в 8.х. Т.е. берем обработку или отчет 7.7 копируем в 8.х, немного подправляем синтаксис, чтоб работал, и пользуемся этим чудовищем, которое трещит по швам и жрет всю свободную память. Наша конфа на 80% состоит из такого уродства, что стало для меня большим удивлением и трагедией.
2) Каждый встречается с некомпетентностью пользователей 1С, это не проблема, ведь пользователя можно научить, объяснить где что, куда нажимать, куда не стоит, что ему за это будет. В нашем случае это не работает. А не работает из-за начальников отделов, которым похрен что понажимают их подчиненные, а виноваты всегда программисты 1С. Приходится тратить 90% рабочего времени на КОЛЛ поддержку и расставление ловушек для негодников.
Вот что вспомнил, то описал. А вы говорите сертификаты и регистры 🙂
(55) ya.Avoronov,
1. Отчасти согласен.
2. Полностью подписываюсь под этим. По этому очень сильно помогло, что руководитель проекта оказался не «мямлей», а защищал и продвигал…
Поставил +
на мой взгляд ошибки не детские, а скорее специфические.
Детской, это назначить форматирование в макете только на одном языке, когда программа имеет несколько локализаций, не дать прав никому кроме полных прав по умолчанию и т.д.
К сожалению наличие сертифицированных специалистов и громкого имени франчайзи не является гарантией избежания данных ошибок.
Столкнулась на практике. Грустно наблюдать процесс.
У меня приятель пришёл работать директором фирмы (Оптовая торговля). Я сначала думал он охрану или заведующих складами сменит. А он также, наладил учёт до Одной штуки. И всё под роспись. А когда люди стали подавать заявления на увольнения, стал анализировать работу каждого из них, и двух-трёх отдал даже под суд. Продержался он около двух лет, потом нашёл себе более спокойную работу.
А у другого несколько магазинов, так он говорит, что тащить будут всегда, главное. чтобы много не тащили.
Автор! Респект
тебеВам! 🙂 Написав своюхрень, Вы вызвали бурю своемнениевыразительства, да и плюсов навалило! Молодец!ну такое почитал и забыл, в коментах даже больше полезного можно прочитать)
Не вижу сути в статье и причины стольких плюсов.
1. Вся информация берется только из регистров, это самый базис. На экзаменах за информацию не из регистров сразу ставят незачет и выгоняют.
2. Ломать работающее не нужно, но если ради каждой прихоти плодить новые документы, то я боюсь представить то, чем станет база.
3-4 Это вообще больше проблемы не программистов, а того, как идет организована работа предприятия.
Как автор статьи хочу согласиться кое с какими замечаниями. Конечно многие пункты которые я указал не связанны на прямую с работой программиста и конечно их должны делать ответственные на то люди. Но как сказал ВВП «жизнь сложна и многообразна» и на практике программиста могут сделать козлом отпущения. Написать программу еще далеко не все. Даже если программа будет идеальной, то нужно ее еще уметь доказать ее состоятельность и разработать план перехода и даже на идеальной программе можно все организовать так что будет худо.
Со многими есть расхождение о том в чем роль программиста. Просто код написать это кодер, обследовал подумал что надо написать и написал это программист. Обследовал подумал что надо написать, написал, накидал план перехода, обучил, перевел на новую программу сопроводил до того как кончились все ошибки то назовем так скажем менеджер внедрения. Когда начинаются комментарии нифига программист этого делать не обязан значит человек считает себя программистом который не обязан это делать. Но жизнь и опыт внедрений показывает что если хочется сделать хорошо, то все таки хоть и не боги горшки обжигают, но иногда нехило бы и сесть на место оператора и поделать его работу эдак с часик что бы понять все ли хорошо в программе.
К тому же я не ставил перед собой задачу покрыть весь спектр проблем на внедрении. Я просто обозначил те участки на которых чаще всего видел как спотыкались мои коллеги и я в том числе.
И по комментарию что на экзаменах за не использование регистров не гоняют. Меня гоняли, может мне особо противный экзаменатор попался, но меня настойчиво вразумили на этот счет.
(12) wolfsoft, И к тому же лишний регистр — это все таки дополнительный объект, который раздувает базу и усложняют структуру метаданных конфигурации. Поэтому если и «пихать» расчеты из документов в регистры, то не все подряд, а осмысленно.
(12) wolfsoft, Обходить в запросах документы и регистры все таки совершенно разные вещи.
почитал … посмеялсО.
1.не пишется в регистр накопления, а остается храниться в документе. -То есть запросом такую информацию нельзя получить никаким образом.
кому то явно пора проходить обучение)) у кого то явные проблемы с запросами и компоновкой.
2.Ошибка вторая — по большему счету связана с неопытностью прогеров которые думают что клиенту нужно то что он ему сказал. А это бывает только в 5% в остальных случаях клиенту нужно совсем другое и проблема заключается как раз в том, что он не может правильно объяснить что ему нужно сделать.
3.слишком много мусорного текста. Суть проста объяснить заказчику «что есть» автоматизация и к чему приведут те или иные изменения. Выработать совместно с ним концепцию автоматизации, продумать варианты её «обхода»(узкие места) и порядок работы, составить регламент работы и нарушающих нещадно «ругать». Схемы бизнес процессов также никто не отменял, автоматизировать со слов «сделай мне так…» ни к чему хорошему не приводит в силу текста во втором пункте.
4. Четвертая ошибка — неконтролируемый доступ к складу для лиц, не несущих материальную ответственность. — действительно это самая большая ошибка программистов 1с… 😀
удалено
Автор как то явно не в тему. Я думал статья про ошибки программирования, там про то, что нельзя допускать переменные с значением null или там не проверять результат запроса на пустоту, а тут про каких то кладовщиков. Оно мне надо.
в 2-х местах опыт внедрения штрихкодирования — в обоих свои конфигурации по ТЗ, после ТЗ еще тонны кода для оптимизации/усовершенстовования, но все разбивается о безраличие/безалаберность рабочих =), так что автоматизация это конечно хорошо, но только если и люди ей занимающиеся или роботы или очень-очень ответственные.
(69) succub1_5,
Нет . Это означает что программист неправильно оценил «ответственность» кладовщиков и готовность руководства эту ответственность стимулировать.
Я писал — что в похожем случае делали «нечеткий» контроль — исходя из реалий, а не из виртуального представления «каким склад должен быть»
Тут надо добавить, что если и приходиться дорабатывать скажем типовой документ, то хотя бы нужно писать комментарий.
(71)Это вообще в обязаловку! Трындец полный когда приходишь к клиенту, а там до тебя «Вася» упражнялся после Радченко. Я один раз на такого погромиста нарвался. Правда оказалось что это был мой код трех летней давности и именно после Радченко, а комменты я тогда еще не ставил. Зато сейчас пишу страницы целые прям в модуле)))
(72) Был у меня один клиент, говорит предыдущий программист чуть-чуть доработал УТ. Смотрю, там он даже свои созданные общие модули не подписал, и в коде не оставил комментариев. (((
(72)
И это хорошо 🙂
Тоже всегда пишу комменты
«Бардак не автоматизируется.» Сцуко, в золотой фонд цитат.