Как избежать программистского беспредела? Советы интегратора

    В предыдущей статье о проблемах внедрения ERP на промышленных предприятиях в качестве кейса к одному из пунктов был приведён «Программистский беспредел».

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

    image

    Тема это актуальная, и я решил написать о ней отдельную статью.

    Что же это такое?


    Какие картины рисует ваше воображение, когда вы слышите фразу «программистский беспредел»?
    Бородатый мужчина с задумчивым умным взглядом бьёт заплаканного главбуха томиком Кнута, приговаривая: «Копейка, говоришь, у тебя в счёт-фактуре не сошлась? Грузополучатель в ячейке не умещается? Сейчас мы его утрамбуем книжкой и всё влезет!»
    В производственном цехе стоит ряд стульев, к ним патч-кордами привязаны мастера. Усталая девушка прохаживается перед ними, обводит их ненавидящим взглядом и задает вопросы: «Кто ещё не может найти 10 минут в день, чтобы зафиксировать выполнение работ в системе и списание материалов? Кому перекуры важнее правильного учёта? И кто после этого на каждом совещании орет, что система не работает?» — а потом бьёт током каждого мастера, который посмеет что-то промямлить в ответ… А рядом бегает её коллега и ноет: «Давай оптимизируем процесс – правильнее будет соединить всех мастеров проводами и просто замыкать цепь: так ты одним движением бьёшь током всех, минимум движений. Вот и код ты так пишешь: вместо одного общего класса создаешь десяток… Да и электроды лучше к соскам крепить…»
    Явление это менее красочное, чем можно нафантазировать, но более ужасное. В конце концов, главбуха можно успокоить, утереть слёзы и отправить к психологу, мастеров можно отвязать от стула и отправить работать. А вот кривые проводки в InventTrans и неработающее из-за просчетов в архитектуре решения и ненужных доработок сводное планирование психолог не исправит.

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

    Приведу пару примеров:

    • Бухгалтер попросил программиста быстренько поправить ошибку с неправильной датой в нескольких документах, тот оперативно написал скрипт, который всё исправил прямо на рабочем приложении. В итоге перестала корректно отрабатывать какая-то проверка и вся отгрузка товаров клиентам встала, потому что не получается формировать отгрузочные документы.
    • Предприятие решило внедрять учёт готовой продукции по серийным номерам. Программист подумал, что стандартная функциональность серийных номеров не очень подходит в их случае, и «запилил» свои нестандартные серийные номера. В итоге уже лет пять на предприятии реализация любых изменений втыкается в необходимость дополнительной доработки нестандартных серийных номеров. Уже года четыре ведётся обсуждение того, как перейти от нестандартных серийников к стандартным, но это слишком трудоёмко и откладывается.

    Я хотел назвать статью «Программистский беспредел. Плач интегратора», но понял, что никого не волнуют наши слезы. А вот советы, как избежать таких ситуаций, могут пригодиться.

    Попробую заранее очертить границы своих рекомендаций – речь идёт о:

    • программистах, которые участвуют во внедрении или сопровождении ERP-систем. Считаю, что к ним немного иные требования, чем, например, к разработчикам нового продукта или технологии;
    • программистах, которые работают у клиента. Разработчики интеграторов в меньшей степени склонны к «беспределу».

    Так каковы причины этого явления и что с этим можно сделать?

    Нежелание или неумение взглянуть в суть процесса


    Я часто вижу это у начинающих аналитиков и программистов. Они просто отвечают на вопрос, который им задал заказчик. При этом не думают – почему он об этом спросил, действительно ли ему это необходимо? Со временем это проходит, но на первых порах приходится ловить и объяснять.
    «А можно увеличить количество знаков после запятой для этого коэффициента до 4?» — «Конечно». А ничего, что этот коэффициент используется для индексации параметра, у которого точность в 1 знак после запятой, а значения не превышают 50? Вся точность коэффициента уйдёт в округление. Так может лучше этого не делать?

    «Добавьте новое поле такого типа в справочник номенклатур» — «Хорошо. Трудоемкость 15 минут». Так, а для чего вам это поле в номенклатурах? Это же характеристика, которая меняется от партии к партии. Может лучше это поле добавить в справочник партий?
    Разработчик в ERP не должен быть просто реализатором изменений, которые озвучивают пользователи. Ему необходимо понимать логику системы и выступать её защитником от всякого бреда. Для этого неплохо бы разбираться в бизнес-процессах хотя бы на уровне здравого смысла и уметь задавать неудобные вопросы пользователям.

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

    Недостаточная стойкость в борьбе с желанием оставить все по-старому


    Это тот случай, когда программистский беспредел творится не разработчиками, но при их попустительстве.

    Любой серьезный продукт несёт в себе не только набор определённых функций, но и идеологию, лучшие практики. А люди хотят работать по-старому. И давят на программиста, чтобы он им эту возможность обеспечил. И если он не смог доказать, что так делать нельзя, то всё может закончиться грустно.

    Предприятие потратило много миллионов рублей, внедряет новую систему, были договоренности о внесении правок в учетную политику, в подходы к работе. Все радостно декларируют приверженность к новым подходам и новым ценностям. Но при этом сотрудник экономической службы приходит к программисту и говорит: «Вот этот отчет у нас на предприятии формируется ежемесячно с 1974 года, мне надо, чтобы он формировался из новой системы». И бесполезно объяснять, что в системе данные не ведутся в этом разрезе, что этот отчет устарел и есть другие, в которых можно пусть немного иначе, но посмотреть ту же информацию. «Мне надо, я генеральному этот отчет показываю, остальное – твои проблемы». И вот программист, униженный и оскорбленный экономическими службами, делает документ, для формирования которого надо в системе дополнительно заполнять десяток справочников и при обработке каждого производственного заказа ставить несколько дополнительных галочек. И если забыть поставить хотя бы одну галочку, то данные в отчете будут кривые. А ставят эти галочки не сотрудники экономической службы, а те самые мастера, которые чудом избежали ударов током. И вот мы обеспечили себя развлечениями на долгие годы: каждый месяц искать причины, почему этот отчет формируется неправильно, разборки экономистов с производством из-за галочек, куча негатива по отношению к новой системе. Хотя надо было просто один раз сказать: «Нет».
    Что с этим можно сделать? Для начала – не ставить программиста в подчинение экономическим службам. Он должен работать в другом подразделении и иметь определённую независимость от руководства отделов, чья работа автоматизируется.

    Неплохо бы ещё добавить одно звено в эту цепочку: любые серьёзные доработки должны получить согласование не только у исполнителя, но и у кого-то, кто понимает бизнес предприятия в целом, и имеет власть. Такой человек точно сможет сказать: «Нет».

    Привычка решать все проблемы программированием


    Любовь к автоматизации ведёт к прогрессу, но иногда вредит. Я бывал свидетелем того, как вместо того, чтобы поручить людям вручную вводить данные в систему, этот ввод автоматизировали. Автоматизировали, забыв какие-то детали или особенности, которые при ручном вводе обязательно были бы замечены, обсуждены и, скорее всего, исправлены. А так – все уверены, что ошибок нет, но через некоторое время массово вылезают последствия, исправить которые уже намного сложнее, чем первопричину.

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

    Поэтому, когда программиста просят написать скрипт, чтобы исправить 200 ошибок, которые возникли из-за того, что пользователи работали не по инструкции, то он не должен сломя голову бросаться за клавиатуру. Надо оценить, сколько времени занимает исправление одной ошибки вручную, и, если время на ручное исправление всех ошибок не превышает трудоёмкости написания скрипта на порядок, заставить пользователей исправить эти ошибки самостоятельно: так больше шансов, что в будущем они будут работать по инструкции. Это надо ввести в качестве правила, повесить на стене около программиста, чтобы он мог в эту бумажку тыкать всех посетителей.

    К тому же, мы почему-то думаем, что если освободить людей от рутинной работы за счет автоматизации, то они займутся чем-то полезным: начнут предлагать идеи по улучшению бизнес-процессов, оптимизируют отчётность, обучат менее опытных коллег. Но скорее всего у них просто станет больше времени на чай, перекуры и интернет на работе. Так стоит ли это того?

    Самоуверенность


    Есть функционал, который не стоит дорабатывать. В Аксапте это, например, сводное планирование. На моей памяти мы его трогали всего 2 раза. И каждый раз это было не встраивание в код, а своего рода «нашлепки» — функции, которые выполнялись перед или после сводного планирования. И даже так я вспоминаю эти доработки с тоской.

    Есть и менее очевидные места, куда лезть не стоит. И отличный способ отличить опытного программиста от начинающего – предложить доработать такую функциональность: опытный будет удивлён и откажется, может посоветует оптимизировать бизнес-процесс, а начинающий скажет: «Давай».

    Тут можно посоветовать одно: брать на работу людей с опытом, которые уже у других заказчиков или на других проектах набили все шишки, которые в принципе можно было набить.

    Отсутствие регламента разработки


    Когда мы берём проект на сопровождение, один из первых документов, который просим у заказчика – это регламент разработки, описывающий среду разработки, правила именования объектов, запреты и ограничения. Самое странное, что иногда его не бывает. И это верный признак – в коде будет трэш: начиная от классического отсутствия комментариев и заканчивая ситуациями, когда прямо в тексте были прописаны конкретные значения из справочников для разных веток алгоритма. А трэш в коде – первый шаг к проблемам с бизнесом.

    Поэтому не надо рассказывать о том, что «программирование — это искусство. Его не регламентировать», «а как же agile?» и вот это всё. Если у вас ведется разработка, то должен быть регламент. И это не 3 пункта:

    1. разработка ведётся на приложении dev;
    2. тестирование ведётся на приложении test;
    3. в коде должны быть комментарии.

    Это должен быть полноценный документ на десяток страниц с разделами:

    1. Требования к приложениям для разработки.
    2. Требования к написанию постановки задачи.
    3. Требования к написанию кода.
    4. Требования к тестированию.
    5. Требования к переносу между приложениями.

    Как правило, весь хардкод делается по принципу «Сделаем по-быстрому, а потом сделаем нормально». Делается по-быстрому, а потом забывается… А когда есть подписанный документ, в котором указано, что так делать нельзя, то всегда можно ткнуть в него и сказать пользователю: «Быстро не получится, мне запрещено так работать. Извини, Алевтина Светозаровна, я бы рад тебе прямо на рабочей все проверки закомментировать, но меня потом уволят».

    Одиночество и бесконтрольность


    Одинокий программист – это зло. Всегда должен быть рядом тот, кто скажет: «Ну и что ты, дурак, накодил?» – иначе разработчик расслабляется, подзабивает на правила, забывает об ответственности. Отсюда начинается хардкод, сомнительные архитектурные решения, ошибки, влияющие на бизнес.

    По-умному это называется «ревью кода» и это то, что должно всегда идти вместе с регламентом разработки. После каждой доработки перед её тестированием должна быть проверка на соответствие кода регламенту разработки и лучшим практикам. Ревью кода позволит:

    • контролировать качество разработки;
    • обучать менее опытных программистов.

    Поэтому разработчиков должно быть минимум 3 штуки (двое всегда договорятся о том, что можно ничего не делать, третий участник системы вероятность сговора существенно уменьшит). И они должны работать по внутреннему регламенту, одним из ключевых пунктов которого является обязательное ревью кода.
    image


    Заключение


    Таким образом, чтобы уменьшить вероятность «программистского беспредела» надо формировать свой отдел внутренней разработки по следующим правилам:

    • Это должна быть команда хотя бы из 3 человек.
    • Хотя бы один из этой команды должен иметь опыт внедрения или сопровождения ERP-системы, это должен быть его n-й по счету проект, где n > 3.
    • Отдел разработки должен подчиняться в идеале непосредственно генеральному директору.
    • Конечные пользователи должны иногда жаловаться на то, что программисты отказываются реализовывать некоторые их требования.
    • Даже для такого маленького отдела обязательно должны быть разработаны регламенты, за нарушение которых надо наказывать.

    Естественно, это мое видение. Его можно оспорить, на каждый из этих пунктов даже я могу из своего опыта привести контрпримеры, когда требование не соблюдалось, но всё было прекрасно. Но эти рекомендации можно использовать в качестве отправной точки для формирования своих принципов борьбы с программистским беспределом.
    ICL Services
    Цифровые технологии для бизнеса

    Комментарии 52

      +2
      Отдел разработки должен подчиняться в идеале непосредственно генеральному директору

      Не ясно, какую функцию у вас исполняет генеральный директор, если
      Бухгалтер попросил программиста


        +2
        Не стреляйте в пианиста — он играет, как умеет (с)

        Это не «программистский беспредел» — это ошибки построения коммуникации.
        Не правильно обращаться непосредственно к программисту (исполнителю)!
        Отдел, регламент — тут полный консенсус, но…
        у продукта должны быть хозяин (контролирует и несет ответственность), аналитик (умеет разговаривать с Алевтиной Светозаровной на ее языке) и архитектор (видит всю картину и принимает решения как ее менять, чтобы было единообразно и эффективно) — это точки входа.
        С увеличением только программистов проблемы остануться и придут новые, но это совсем другая история )
          –1
          у продукта должны быть хозяин (контролирует и несет ответственность), аналитик (умеет разговаривать с Алевтиной Светозаровной на ее языке) и архитектор (видит всю картину и принимает решения как ее менять, чтобы было единообразно и эффективно) — это точки входа.

          Полностью с вами согласен. То, что вы описали, — идеальный вариант. Но держать столько IT специалистов, тем более довольно дорогих и квалифицированных, — не каждое предприятие такое потянет. Я видел предприятия, где ERP сопровождали 1-2 разработчика, это довольно рапространенное явление.
          В условиях ограниченного бюджета каждый программист вынужден с Алевтиной Светозаровной общий язык находить, а самый опытный из разрабов выполняет роль архитектора. Вот с хозяином продукта, конечно, сложнее…
            0

            Когда в результате очередного бага предприятие попадет на пару штрафов в пару лямов — тогда моментом деньги найдутся. Все эти сказки про "не каждое предприятие такое потянет" кому-нибудь другому ...

            0
            Вы прям скрам команду описали. Надо только тестера добавить и девопса.
            0
            А жизнь она ведь не только черное и белое…
            Не судите программистов по результатам, особенно которые работают на предприятии долго, а спросите «почему они это так сделали?». Узнаете много интересного, почему было так сделано.
            Я работал как со стороны интегратора так и со стороны разработчика предприятия и на мой взгляд интеграторы гораздо более заинтересованы в том, чтобы «допилить» 1С. А штатные программисты — они ведь оклад получают.
              –1
              К программистам особых претензий нет: я понимаю, что разные ситуации бывают.
              Тут больше о том, как создавать условия, в которых программисты не будут вынуждены делать странные вещи.
                0
                нам помогает здравый уровень бюрократии — заявки на выполнение работ. Большинство «левых» задач отваливаются на уровне постановки. А те, что остаются, если совсем «бредовые» — отодвигаются по срокам на «прекрасное далеко», реально нужных и важных задач всегда хватает.
                  0
                  Надо было добавить пункт «Наличие реально нужных и важных задач» как один из способов профилактики «программистского беспредела»)
              0
              Тут больше о том, как создавать условия, в которых программисты не будут вынуждены делать странные вещи.

              Баксанул столько, сколько сказали это стоит, выполнил рекомендации и нет проблем, обычно так подобную проблему решают, ну а если сам себе голова и никакие рекомендации не нужны, да и еще в инете нашёл чертовски выгодную цену, то случиться может всякое.
                0
                речь идёт о[...] программистах, которые работают у клиента. Разработчики интеграторов в меньшей степени склонны к «беспределу».

                Боюсь, мнение с другой стороны баррикад будет существенно отличаться от вашего.

                  –1
                  «Беспредел» есть и по ту, и по эту сторону баррикад. Просто причины этих беспределов разные. Вполне возможно, что я предвзято смотрю на этот вопрос — по ту сторону баррикад я не был, хотя и много общался с программистами клиента.
                    0

                    Я не знаю как сегодня, но в 2007-м "программистский беспредел" выглядел примерно так:
                    Действующие лица — Глав.бух (далее ГБ) Вася-п0гр0мист, по совместительству студент, далее Вася, Владлен Петрович, начальник отдела автоматизации торговой сети, далее ВП, Давид Аронович (ДА) ген дир торговой сети. И интегратор, ФИО не важно ибо все они на одно лицо, далее И́.
                    Акт первый:
                    ГБ, тихо входит в комнату и кокетливым голосом говорит: — пора сдавать квартальный отчёт в налоговую и данные в пен.фонд. Там вроде бы они что то поменяли…
                    ВП: — Что именно?
                    ГБ: — ну я точно не знаю, там пару месяцев назад приходило какое то письмо…
                    ВП (шепотом про себя) "где ж ты была коза ты Брянская ?" В слух: — Ну так надо узнать и желательно быстрее. Осталось то всего две недели…
                    ГБ (зевая): — ну я там в почте у себя поищу...


                    Акт 2, прошло два дня:
                    ВП: — ну так письмо то нашлось? Чо вчера не зашла?
                    ГБ: — ну да нашлось, вчера времени не было. Ой с этой новой версией программы (далее П) ничего не понятно, все так сложно. Короче, там ерунда, добавилось пара полей. Только вот проблема — пункт меню для выгрузки не можем найти. Раньше он был, а сейчас его нет…
                    ВП: хм, странно. И́ ничего не говорил после обновления. Посмотрю в доках.


                    Акт 3, на следующий день с помощью молитв, ударов в бубен и ритуальных танцев вокруг клавиатуры вчетвером, включая ВП, ГБ, Васю и случайно оказавшегося рядом сисадмина, отдел автоматизации делает выгрузку данных из тестовой базы по инструкции, данной Й. Процедура занимает 16 часов времени. В ходе действа выясняется, что формат выгрузки не совпадает, т к версия П все ещё не последняя. Вася в ходе процесса становится экспертом по налоговой отчётности, превосходя в знаниях стремительно седеющую ГБ…


                    Акт 4. Звонок к Й в ходе которого выясняется, что обновить систему до последней версии не представляется возможным, т к это повлечет изменение структуры базы, а другие системы автоматизации на предприятии завязанные на данные с этой базы или на саму базу "отвалятся". На резонный вопрос "А какого хрена И́ не сказал об этом заранее и не продумал действия в такой ситуации", И́ разводит руками. ВП предъявляет ультиматум, что если И́ X не решит проблему, то "мы уйдем к И́ Y".


                    Акт 5, в котором Вася освобождается от всей работы на оставшуюся неделю, ему в "рабство" придается два бухгалтера и он включает свой сумрачный гений, что бы написать свою собственную, первую в его жизни, процедуру выгрузки данных из одной дерьмовой и морально устаревший системы в другую, ещё худшию, т к она сделана на остаток от распила. Если бы он знал сколько такого говна ему придется делать в жизни, то вместо поступления на АСУ ТП пошел бы работать настройку. Но мама сказала "сынок, на стройке жизни нет" Теперь то Василий знает, где по настоящему жизни нет, но отступать не в правилах Василия.
                    В ходе этого процесса Вася узнаёт много нового о старой системе. С этих пор он "программист-беспредельщик" — угрюмый, молчаливый и очень опасный. Вторая коварная ловушка подстерегает Василия уже на другой стороне — формат данных ему не известен и из письма не понятен. Но тёртого беспредельщика такой ерундой не остановить. Со 101-й попытки Василий проходит проверку валидатора из налоговой и в последний день отчётность уходит в налоговую. Однако налоговая требует ещё и бумажную копию… Ну ерунда- ещё пару дней и челлендж комплитед.


                    Акт 6 где ВП доносит ситуацию с И́ до верховного канцлера, Давида Аронович а:
                    ВП — нам в скором времени придется перейти на другую П, т к данную мы не можем апгрейдить, а многие вещи уже поменялись.
                    ДА — ну этож дорого и долго. К тому же эту П ты предложил сам всего то каких то 6 лет назад.
                    ВП — ну да, предложил, каюсь. Но тогда других особо не было, да и задачки были поменьше…
                    ДА, шевеля усами и причмокивая — а может как-нибудь обойдёмся? Сейчас есть цели по важнее. Вот у нас тут новый тц должен вот вот открыться и долг нужно поставщикам погасить…
                    ВП — ну до следующей сдачи отчётности можем конечно потерпеть, но там и другие проблемы уже начали вылазить — система еле ворочается, данных стало много. А тут ещё менеджеры из торгового со своим новым бизнес-процессом… Он туда "не встаёт" хоть тресни…
                    ДА: а что И́?
                    ВП: да только руками разводят. Они только и могут, что новые версии накатывать, да и то только на пустую базу… А чуть что не так, там суммы как за новую П.
                    ДА — ну а мож мы сами-сусами? У нас вон целый Василий есть…
                    ВП, почесывая подбородок — ну это будет ещё дольше, да и не понятно, что за чупакабра получится. Все ж таки промышленные П куча народу делает и тестирует.
                    ДА Ладно, давай сейчас посвободнее будет соберём совещание со всеми заинтересованными и решим что делать.


                    Акт 7 спустя год, в котором Вася становится матёрым "беспредельщиком". Как вы догадались, уважаемые зрители, совещание было собрано к лету и окончилось не чем, т к денег нет да и вообще "не время". И́ продолжил разводить руками, а Вася продолжил познавать глубины разработки собственной говно-erp.
                    История полностью вымышленная, все совпадения случайны. Но смысл передан точно.

                      –1
                      В этой истории меня больше всего интересует, где теперь этот Вася) Это явно очень опытный парень, повидавший много интересного.
                        +1
                        С большой вероятностью — там же. Зато ВП ушел в компанию покрупнее, возможно в Й (в резюме ведь теперь «организация разработки ERP»), а Й добавил себе на сайт благодарственный отзыв от ГБ.
                          +2
                          Здравствуйте, я друг того Васи.
                          В свое время приходилось разрабатывать EPR для группы изданий.
                          Процесс очень похож на описанный вами, с разницей что Вась было трое.
                          Чем закончилось — не знаю, ибо «я устал, я ухожу».
                            –1
                            Здравствуйте.
                            А чем вы сейчас занимаетесь? Пригодился опыт, полученный тогда при разработке ERP, в дальнейшей работе?
                              0
                              А чем вы сейчас занимаетесь?
                              Доработкой ПО для управления школами.
                              Пригодился опыт, полученный тогда при разработке ERP, в дальнейшей работе?
                              Конечно. Теперь я знаю как делать не нужно )))
                              На самом деле, в той EPR были удачные решения, и если представится подходящий аналогичный случай, я учту тот опыт.
                                +1
                                Ну раз вас так интересует, то один «Вася» уехал в Израиль, ибо «корни звали» и там устроился в какую то компанию уже занимающуюся настоящей разработкой ПО в сфере телекоммуникаций. Другой «Вася» чем только не занимался и на чем только не писал, но сейчас пока «осел» в Java-разработке. Ничего фантастического. «Владлен Петрович» на волне успеха с внедрением новой П (которое все же состоялось, но значительно позже) основал свою небольшую фирмочку по продаже софта и услуг в сфере 1С. Как дела у неё — без понятия, но не думаю, что сильно «прёт в гору» учитывая закукоживание малого и среднего бизнеса в РФ. А на покупку софта сейчас и вообще забили — покупают только то за что можно получить по башке: 1с, винду (причем по минимуму — если раньше в каждой конторе стоял сервер со всеми наворотами (Серверный виндоуз, АД, Exchange и т д) то сейчас в век флэшек и интернетов как то обходятся. Остальное админ «Петя» скачает с торентов. 1с — давно уже большинство на «типовухе» и основной доход — это обновления с соответствующей конкуренцией. Отсюда явственно следует, что по прямому назначению квалифицированный «Вася» и не нужен. Ну и хорошо, ибо ну его такую работу. Судьба глав.буха и прочих бухов остается туманной, как и судьбы всяких Й (ну кому оно интересно ) А Давид Аронович продолжает править и царствовать, но уже не как ген.дир а как «сооснователь группы компаний».
                                Что касается опыта от разработки ERP — да, пригодилось. Что бы понять что на такую работу лучше не ходить ) Положительная сторона — начинаешь задумываться о том как вообще должно строится ПО — архитектура, шаблоны, процессы разработки. Но быстро становится понятно, что в нынешней бизнес-модели этим правилам не может следовать как абстрактный Вася, так и многочисленные Й. Все получается совершенно не так как в книжках писано. «Гладко было на бумаге, да забыли про овраги» ©
                            0
                            сдесь ошыбок столька
                            катеца слиза
                            каг песать таг можна
                            о мои глоза
                              0
                              ладно, шутка не зашла, но реально, нельзя же так:
                              «какое то письмо»
                              «В слух»
                              «Там вроде бы они что то поменяли»
                              и это только первый абзац, и я просто молчу про разного рода запятые.

                              Мне, конечно, могут возразить про «когда не к чему прикопаться, прикапываются к грамматике» или там «по одёжке встречают только дураки, главное — ум!»
                              Но на практике, если к вам на улице подойдёт обоссаный, воняющий свежим дерьмом бомж, с которого сыплются вши, вы явно не будете слушать его философские выкладки.
                              А уровень грамотности здесь именно такой.

                              По одёжке встречают.
                              И если человек не умеет в элементарную грамотность — он тот самый обоссаный бомж.
                              И я как-то не верю в то, что он может быть хорошим профессионалом, извините.
                                –3
                                вы явно не будете слушать его философские выкладки

                                Избавьте меня от своей «ранимой тонкой натуры» и с*те отсюда в свой обоссанный (кстати, у вас в этом слове ошибка. Обоссанный. Да, хабр как не странно подчеркивает его правильное написание. Очевидно, остальное вы тоже писали, сверяясь с проверкой хабра, не так ли? Т. е. «познания» грамматики — не ваша заслуга, а хабра) угол. Я вас к стулу не привязываю и читать, то что я написал не заставляю. Вам не нравится — значит это не для вас.
                                И я как-то не верю в то, что он может быть хорошим профессионалом

                                Не верьте. Я к вам на работу идти не собираюсь. Живите дальше в своём маня-мирке.
                                  –1
                                  Одна Н пишется в прилагательных в суффиксах которых есть -ан-, -ян-, -ин-. Исключения — оловянный, деревянный, стеклянный.

                                  Слова «обоссаный» в исключениях нет. «как ни странно» пишется через «ни».

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

                                  Впрочем, если у вас уже есть работа и вы планируете проработать на ней до старости — ну, вероятно всё ок.

                                  Но, если серьёзно, без наезда в вашу сторону, как человек который прошёл кучу собеседований и как человек, который провёл кучу собеседований, могу сказать одно (ещё раз — это я сейчас не про вас, это я про собственнный опыт с обеих сторон) — если человек пишет неграмотно или, скажем, если человек пришёл на собеседование с сальными волосами и от него несёт немытым телом — его либо не возьмут, либо возьмут, но на сильно меньшие деньги, чем могли бы.

                                  Вы сейчас вероятно сочтёте, что я просто докопался, отстань уже, демон, но просто на всякий случай.
                                  Попробуйте больше читать художественной литературы. Это довольно быстро даёт ачивку «врождённая грамотность» (глаза тупо запоминают правильное написание) + развивает хорошую правильную речь и это, внезапно, работает в плане «работать столько же, а зарабатывать больше».

                                  В любом случае — желаю хорошей работы, вменяемого начальства и профессионального роста.
                                    –2
                                    Слова «обоссаный» в исключениях нет

                                    Т е вы отказываетесь признавать свои ошибки? ru.wiktionary.org/wiki/%D0%BE%D0%B1%D0%BE%D1%81%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9
                                    Тем более крепнет моё желание к вам на собеседование не попадать.

                                    пишуд «правельно» только «ранимые тонкие натуры»

                                    Нет, только они так реагируют на опечатки. У меня стойкое ощущение, что вы какой то сломанный.

                                    если человек пишет неграмотно

                                    О галактика! Только не говорите мне, что вы работаете как это сейчас называется, «ХаЭром». Т е вы «отшиваете» людей, только потому, что вам показалось, что они пишут не грамотно, вместо того, что бы отдать их на собеседование к специалисту?

                                    Попробуйте больше читать художественной литературы. Это довольно быстро даёт ачивку «врождённая грамотность» (глаза тупо запоминают правильное написание) + развивает хорошую правильную речь и это, внезапно, работает в плане «работать столько же, а зарабатывать больше».

                                    Еще один миф в сознании «гуманитария». Читаю я вполне достаточно. Как видно из того, что вашу «грамотность» сумел обмануть обычный чекер хабра — ничего это не даёт.

                                      –1
                                      Вы такой забавный.

                                      Почему-то вместо правил используете какой-то левый сайт, на котором это слово написано и так, и эдак (да-да, сначала с двумя «н», а ниже уже с одной).
                                      Сами себе придумали, что я использую чекер хабра.
                                      Сами себе придумали, что я HR и гуманитарий.
                                      Сами себе придумали, что я отшиваю людей.

                                      В общем, с чтением и пониманием написанного у вас так же, как с поиском информации и умением писать без ошибок.
                                      Вы полагаете, что отлично, ну что ж — не буду спорить, в этом диалоге вы сами всё проиллюстрировали.

                                      Всего вам доброго.
                                        0

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


                                        А правила у вас не работают потому, что это не прилагательное, а причастие. В причастиях в полной форме всегда две "н" пишутся.

                                          0
                                          Ну да, у нас тут сеанс специальной олимпиады.

                                          И мне уже тоже интересно, как правильно пишется. Про причастие не совсем согласен, потому что если «обоссаный» — причастие и пишется с двумя «н», то почему «ссаный» — с одним?
                                            0

                                            Потому что приставки нет. Я не вполне понимаю как так получилось, но отглагольное прилагательное не может быть образовано из причастия совершенного вида. Из-за чего "ссаный" может являться отглагольным прилагательным, а "обоссаный" — не может.

                                              0
                                              Причастие обозначает действие, обычно его можно заменить синонимичным глаголом, «перевернув» предложение или построив неопределенно-личное (безличное): Баржа выгружена рабочими — Рабочие выгрузили баржу; Что написано пером — Что написали пером.

                                              При причастии есть или можно придумать зависимое слово в творительном падеже, которое обозначает производителя этого действия или инструмент: выгружена (кем?) рабочими; написано (чем?) пером.

                                              Те слова, которые не удовлетворяют двум вышеописанным критериям, те. не являются причастиями, — краткие прилагательные. Добавим для большей надежности, что они отвечают на вопрос каков? какова?, обычно относятся к существительному и обозначают качество: девушка была красива и хорошо образованна (подсказкой может служить однородный член — краткое прилагательное красива).


                                              Т.е. в нашем случае «бомж обоссаный (кем?)», либо «бомж (каков?) обоссаный». В общем, получается, что можно писать и так, и так в зависимости от контекста. о_О

                                              Нужен филолог.
                                                +1

                                                Нее, нельзя и так и так писать. Если действие совершенное — то слово может быть только причастием.


                                                Упрощенное правило: если есть приставка — пиши две "н".


                                                http://gramota.ru/class/coach/tbgramota/45_106

                                                  0
                                                  Спасибо, буду знать.
                                                  В итоге, Arlekcangp был прав, а я нет.
                              0
                              Если имена поменять — история один в один как у меня сейчас, в этот самый месяц, еще не закончилось.
                              Выгрузка. Пенсионный фонд. Последние 3 недели до сдачи отчета, и я в роли Васи, первый раз увидивший пенсионные реформы, постановления ПФ РФ
                              Да еще почти везде в базе бухгалтера с кадровиками косяков поналепили — задолбался исправлять, доказывать им что ошибки есть. Только мысль что «ну наконец-то, осталось только XML собрать» — взгляд ловит еще один косяк. И опять по-кругу писать бухгалтерам, кадровикам, что это за хреновину они там завели.
                            0
                            Боюсь, мнение с другой стороны баррикад будет существенно отличаться от вашего.
                            Конечно оно может отличаться, но суть не поменяется, такие ошибки допускают от в подавляющем большинстве от недостаточного знания предметной области, это понятно каждому, в основном это начинающие программисты и тут нет ничего необычного, квалификация приобретается с опытом работы, но и цена у нее будет другая и вот тут камень преткновения с закономерным результатом ну и конечно сюда добавляется неспособность заказчика оценить квалификацию программиста, в таком случае или сарафан или рулетка, но это везде так, не только в программировании. Статистики сколько проектов дропнулось, потому что не смогли реализовать задуманное нету, а жаль, но таких проектов куча, это точно.
                            0
                            Прежде, чем что-то добавлять в ERP-систему, нужно три раза итеративно спросить:
                            Зачем Вам Это?
                            Обычно помогает. Иногда, но не всегда.
                              –1
                              Полностью с вами согласен.
                              уметь задавать неудобные вопросы пользователям.

                              — вот это как раз про такой вопрос.
                              Но если после таких вопросов пользователь понимает, что он не прав, но имеет возможность продавить программиста на реализацию этого решения, то толка особого в вопросах нет.
                              +2

                              Статья наглядно показывает что получается, когда вместо квалифицированного постановщика задач программистом командуют бухгалтера

                                0
                                по моему опыту обслуживания ERP, сотрудники пищат и директора тут же начинают орать на программистов, а ты можешь сколько угодно понимать, что делать так не следует, но тебя не спросили, тебя спросят потом, когда вылезут последствия, то что ты по заявке на разработку сделал.

                                Я понимаю что у вас видимо такая беда, что программисты принимают решения без согласования с опытными товарищами, но в жизни клиент всегда прав и мало кто хочет разбираться.
                                  0
                                  Некоторые предприятия так устроены, что там только костылями:
                                  Руководитель свято верит, что причина получающегося дерьма в нерадивых программистах, а не в нём.
                                  Разгрести это дерьмо у тебя не получится при любом желании, так как от тебя будут требовать писать всё больше и больше кода, который непонятно как придётся прикручивать к уже существующему, на вдумчивое разгребание времени не останется совсем.
                                  lurkmore.to/Умение_разбираться_в_чужом_коде
                                    +1
                                    На самом деле очень трудно противостоять давлению сотрудников при внедрении. Из опыта: перевнедрял одну систему после неудачного внедрения другой компанией. И на мой задумчивый вопрос
                                    — странно, нафига, они так сделали?
                                    Главбух ответила
                                    — это мы их так заставили сделать, что бы было как в старой программе.
                                    На мой вопрос
                                    — а зачем внедрять новую программу и делать из неё старую, если можно было просто остаться на старой?
                                    Она ответила
                                    — точно, что то мы не подумали. Мы ещё думали, что внедренцы так сильно сопротивлялись
                                      –1
                                      Да, это они любят делать)) Мы постоянно в это втыкаемся
                                      +1

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

                                        –2
                                        Расскажите еще немного про страну эльфов, пожалуйста. А то у нас тут дикая Россия, мы все ходим в лаптях с медведями на поводке, и словей-то таких не знаем даже.
                                        0
                                        Не понял, куда пропали функциональные консультанты и аналитики. Если с пользователем общается программист, то ничего хорошего из этого не выйдет.
                                          –1
                                          Ситуация: внедрили ERP-систему. Потратили на это нелегкое дело много денег, все более или менее работает, дальше надо сопровождать, делать небольшие изменения. Изменений не очень много, денег жалко. Поэтому берут одного программиста в штат и тот выполняет все функции: и аналитик, и программист, и архитектор, и админ.
                                          Да, это неправильно. Да, это может привести к плохим последствиям.
                                          Но это не такая уж редкость.
                                            0
                                            Ну на скольких заводах внедряли, кто мог потянуть полноценное внедрение ERP, всегда создавался отдел из местных аналитиков, которых втягивали в процесс и учили системе. Ну и ключевые пользователи знали не только свои БП, но и некоторые важные особенности системы.
                                              –1
                                              У меня немного иной опыт, более разнообразный:
                                              1. Были заводы, где создавался отдел из местных аналитиков и программистов.
                                              2. Были такие, где создавался отдел только из программистов.
                                              3. Были такие, где работал один программист, который обращался к нам при возникновении сложных вопросов.


                                              Да и уходят люди. Ключевые пользователи, обученные при внедрении аналитики — сегодня они работают, а завтра могут уже не работать.
                                                0
                                                Я поэтому и написал «кто мог потянуть полноценное внедрение ERP». С заказчиками второго и третьего случая не работаем, слава Гейтсу.
                                          0
                                          В этой теме не хватает автора этого цикла habr.com/en/post/451702
                                            –1
                                            Спасибо за рекомендацию) Шедевральный автор))
                                            0
                                            В основном вы рассказываете про примеры, когда под давлением внешних факторов, программисты совершают ошибки, которые приведут к проблемам в перспективе. Было бы интересно узнать из вашего опыта, как сами программисты, без видимых причин, «делали грязь» и как руководству это предотвратить (помимо кодревью).

                                            Мне, к счастью, незнакома специфика работы на промышленных предприятиях, но в «классической модели», у программиста имеется менеджер, который таки и должен обладать глубинными знаниями о бизнес процессах / фильтровать задачи от бухгалтеров, продажников и прочих, согласовывать их с директором / находить логические коллизии в поставленной сейчас задаче с тем, что делалось пол года назад.
                                            Я не хочу сказать, что менеджер снимает с программиста необходимость думать о бизнесе, но явно что правила работы с подрядчиками годовой давности, это не то, что программист должен знать наизусть.
                                              –1
                                              Если честно, не припомню такого, чтобы программисты сами по своей инициативе взяли и сделали что-то совсем плохое. Обычно этим людям есть чем заняться, просто так от скуки они портить ничего не будут. Максимум из любопытства — попробовать что-то новое, проверить, что будет если сделать вот так или так, — но для любопытства всегда есть тестовое приложение или приложение разработки.

                                              Кодревью — это основной механизм борьбы с «беспределом».

                                              Второй механизм — нанимать опытных разработчиков, которые поработали в конторах с хорошей программистской дисциплиной. Меня радует ошарашенный вид наших разработчиков, когда программист заказчика говорит про свой хардкод: «Ну мы всегда делаем так!» — это воспринимается ими как преступление, как что-то противоестественное. Такие ребята, скорее всего, не будут делать откровенную «грязь» в коде, даже работая у клиента. Ну по крайней мере, первые несколько лет)))
                                              Все остальные рекомендации — это то же ревью кода, но в другой форме: периодический внешний аудит кода, опытный менеджер-непрограммист и т.п.
                                                0
                                                Мне, к счастью, незнакома специфика работы на промышленных предприятиях, но в «классической модели», у программиста имеется менеджер

                                                А я могу вам рассказать, и это относится к любой не ИТ фирме, а не только промышленности.
                                                Средняя организация, от 50 до 300 рабочих мест, примерно 80% пользователей работают в корпоративной системе, не 1с. ОйТи отдел, примерно 5-7 человек включая начальника.
                                                Из них двое или трое уровня первой линии/хелпдеск/переустановить винду на компе. Ещё двое ковыряют ЕРП-систему, иногда есть отдельный админ на весь этот балаган, чаще нет.
                                                Если ковыряльщиков ерп двое, то возможны варианты, когда один рисует экранные формы пользователям и делает что-то несложное, а второй лезет в глубь системы и пытается из говна и палок SQL реализовать очередной отчёт корреляции количества клиентов от фаз луны и погоды на Венере.
                                                Или вариант, когда Болек и Лёлек примерно одинаковой низкой квалификации, и могут только помогать пользователям удалить какой-нибудь счёт или узнать, куда делись две позиции товара из накладной, а все сложные вопросы отправляются техподдержке производителя системы.
                                                А техподдержка отвечает примерно раз в неделю в стиле: так сделать нельзя потому что нельзя, или это баг, будет исправлен в следующей версии осенью следующего года.
                                                Вот из таких организаций и рождаются швецы-жнецы-надуде-игроки, которые с утра компы пылесосят, днём выясняют почему связь с филиалом пропала, а вечером ищут, куда же Алевтина Петровна партию товара со склада переместила.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое