В предыдущей статье о проблемах внедрения ERP на промышленных предприятиях в качестве кейса к одному из пунктов был приведён «Программистский беспредел».
У нас есть заказчик, сотрудники которого теперь, отправляя нам сомнительные требования, уточняют, не является ли это программистским беспределом. А некоторые не уточняют, а творят его.
Тема это актуальная, и я решил написать о ней отдельную статью.
Какие картины рисует ваше воображение, когда вы слышите фразу «программистский беспредел»?
Программистский беспредел – это ситуация, когда в результате программирования, целью которого было решение определённых проблем бизнеса, создаются другие, зачастую более серьезные, проблемы для бизнеса.
Приведу пару примеров:
Я хотел назвать статью «Программистский беспредел. Плач интегратора», но понял, что никого не волнуют наши слезы. А вот советы, как избежать таких ситуаций, могут пригодиться.
Попробую заранее очертить границы своих рекомендаций – речь идёт о:
Так каковы причины этого явления и что с этим можно сделать?
Я часто вижу это у начинающих аналитиков и программистов. Они просто отвечают на вопрос, который им задал заказчик. При этом не думают – почему он об этом спросил, действительно ли ему это необходимо? Со временем это проходит, но на первых порах приходится ловить и объяснять.
Поэтому если к вам ни разу не прибегал кто-то из пользователей с жалобами на наглость программиста, который отказался реализовывать его «хотелки», к этому разработчику стоит присмотреться. Возможно, он просто делает то, что ему скажут. А это редко заканчивается чем-то хорошим.
Это тот случай, когда программистский беспредел творится не разработчиками, но при их попустительстве.
Любой серьезный продукт несёт в себе не только набор определённых функций, но и идеологию, лучшие практики. А люди хотят работать по-старому. И давят на программиста, чтобы он им эту возможность обеспечил. И если он не смог доказать, что так делать нельзя, то всё может закончиться грустно.
Неплохо бы ещё добавить одно звено в эту цепочку: любые серьёзные доработки должны получить согласование не только у исполнителя, но и у кого-то, кто понимает бизнес предприятия в целом, и имеет власть. Такой человек точно сможет сказать: «Нет».
Любовь к автоматизации ведёт к прогрессу, но иногда вредит. Я бывал свидетелем того, как вместо того, чтобы поручить людям вручную вводить данные в систему, этот ввод автоматизировали. Автоматизировали, забыв какие-то детали или особенности, которые при ручном вводе обязательно были бы замечены, обсуждены и, скорее всего, исправлены. А так – все уверены, что ошибок нет, но через некоторое время массово вылезают последствия, исправить которые уже намного сложнее, чем первопричину.
Поэтому, когда программиста просят написать скрипт, чтобы исправить 200 ошибок, которые возникли из-за того, что пользователи работали не по инструкции, то он не должен сломя голову бросаться за клавиатуру. Надо оценить, сколько времени занимает исправление одной ошибки вручную, и, если время на ручное исправление всех ошибок не превышает трудоёмкости написания скрипта на порядок, заставить пользователей исправить эти ошибки самостоятельно: так больше шансов, что в будущем они будут работать по инструкции. Это надо ввести в качестве правила, повесить на стене около программиста, чтобы он мог в эту бумажку тыкать всех посетителей.
К тому же, мы почему-то думаем, что если освободить людей от рутинной работы за счет автоматизации, то они займутся чем-то полезным: начнут предлагать идеи по улучшению бизнес-процессов, оптимизируют отчётность, обучат менее опытных коллег. Но скорее всего у них просто станет больше времени на чай, перекуры и интернет на работе. Так стоит ли это того?
Есть функционал, который не стоит дорабатывать. В Аксапте это, например, сводное планирование. На моей памяти мы его трогали всего 2 раза. И каждый раз это было не встраивание в код, а своего рода «нашлепки» — функции, которые выполнялись перед или после сводного планирования. И даже так я вспоминаю эти доработки с тоской.
Есть и менее очевидные места, куда лезть не стоит. И отличный способ отличить опытного программиста от начинающего – предложить доработать такую функциональность: опытный будет удивлён и откажется, может посоветует оптимизировать бизнес-процесс, а начинающий скажет: «Давай».
Тут можно посоветовать одно: брать на работу людей с опытом, которые уже у других заказчиков или на других проектах набили все шишки, которые в принципе можно было набить.
Когда мы берём проект на сопровождение, один из первых документов, который просим у заказчика – это регламент разработки, описывающий среду разработки, правила именования объектов, запреты и ограничения. Самое странное, что иногда его не бывает. И это верный признак – в коде будет трэш: начиная от классического отсутствия комментариев и заканчивая ситуациями, когда прямо в тексте были прописаны конкретные значения из справочников для разных веток алгоритма. А трэш в коде – первый шаг к проблемам с бизнесом.
Поэтому не надо рассказывать о том, что «программирование — это искусство. Его не регламентировать», «а как же agile?» и вот это всё. Если у вас ведется разработка, то должен быть регламент. И это не 3 пункта:
Это должен быть полноценный документ на десяток страниц с разделами:
Как правило, весь хардкод делается по принципу «Сделаем по-быстрому, а потом сделаем нормально». Делается по-быстрому, а потом забывается… А когда есть подписанный документ, в котором указано, что так делать нельзя, то всегда можно ткнуть в него и сказать пользователю: «Быстро не получится, мне запрещено так работать. Извини, Алевтина Светозаровна, я бы рад тебе прямо на рабочей все проверки закомментировать, но меня потом уволят».
Одинокий программист – это зло. Всегда должен быть рядом тот, кто скажет: «Ну и что ты, дурак, накодил?» – иначе разработчик расслабляется, подзабивает на правила, забывает об ответственности. Отсюда начинается хардкод, сомнительные архитектурные решения, ошибки, влияющие на бизнес.
По-умному это называется «ревью кода» и это то, что должно всегда идти вместе с регламентом разработки. После каждой доработки перед её тестированием должна быть проверка на соответствие кода регламенту разработки и лучшим практикам. Ревью кода позволит:
Поэтому разработчиков должно быть минимум 3 штуки (двое всегда договорятся о том, что можно ничего не делать, третий участник системы вероятность сговора существенно уменьшит). И они должны работать по внутреннему регламенту, одним из ключевых пунктов которого является обязательное ревью кода.
Таким образом, чтобы уменьшить вероятность «программистского беспредела» надо формировать свой отдел внутренней разработки по следующим правилам:
Естественно, это мое видение. Его можно оспорить, на каждый из этих пунктов даже я могу из своего опыта привести контрпримеры, когда требование не соблюдалось, но всё было прекрасно. Но эти рекомендации можно использовать в качестве отправной точки для формирования своих принципов борьбы с программистским беспределом.
У нас есть заказчик, сотрудники которого теперь, отправляя нам сомнительные требования, уточняют, не является ли это программистским беспределом. А некоторые не уточняют, а творят его.
Тема это актуальная, и я решил написать о ней отдельную статью.
Что же это такое?
Какие картины рисует ваше воображение, когда вы слышите фразу «программистский беспредел»?
Бородатый мужчина с задумчивым умным взглядом бьёт заплаканного главбуха томиком Кнута, приговаривая: «Копейка, говоришь, у тебя в счёт-фактуре не сошлась? Грузополучатель в ячейке не умещается? Сейчас мы его утрамбуем книжкой и всё влезет!»
В производственном цехе стоит ряд стульев, к ним патч-кордами привязаны мастера. Усталая девушка прохаживается перед ними, обводит их ненавидящим взглядом и задает вопросы: «Кто ещё не может найти 10 минут в день, чтобы зафиксировать выполнение работ в системе и списание материалов? Кому перекуры важнее правильного учёта? И кто после этого на каждом совещании орет, что система не работает?» — а потом бьёт током каждого мастера, который посмеет что-то промямлить в ответ… А рядом бегает её коллега и ноет: «Давай оптимизируем процесс – правильнее будет соединить всех мастеров проводами и просто замыкать цепь: так ты одним движением бьёшь током всех, минимум движений. Вот и код ты так пишешь: вместо одного общего класса создаешь десяток… Да и электроды лучше к соскам крепить…»Явление это менее красочное, чем можно нафантазировать, но более ужасное. В конце концов, главбуха можно успокоить, утереть слёзы и отправить к психологу, мастеров можно отвязать от стула и отправить работать. А вот кривые проводки в InventTrans и неработающее из-за просчетов в архитектуре решения и ненужных доработок сводное планирование психолог не исправит.
Программистский беспредел – это ситуация, когда в результате программирования, целью которого было решение определённых проблем бизнеса, создаются другие, зачастую более серьезные, проблемы для бизнеса.
Приведу пару примеров:
- Бухгалтер попросил программиста быстренько поправить ошибку с неправильной датой в нескольких документах, тот оперативно написал скрипт, который всё исправил прямо на рабочем приложении. В итоге перестала корректно отрабатывать какая-то проверка и вся отгрузка товаров клиентам встала, потому что не получается формировать отгрузочные документы.
- Предприятие решило внедрять учёт готовой продукции по серийным номерам. Программист подумал, что стандартная функциональность серийных номеров не очень подходит в их случае, и «запилил» свои нестандартные серийные номера. В итоге уже лет пять на предприятии реализация любых изменений втыкается в необходимость дополнительной доработки нестандартных серийных номеров. Уже года четыре ведётся обсуждение того, как перейти от нестандартных серийников к стандартным, но это слишком трудоёмко и откладывается.
Я хотел назвать статью «Программистский беспредел. Плач интегратора», но понял, что никого не волнуют наши слезы. А вот советы, как избежать таких ситуаций, могут пригодиться.
Попробую заранее очертить границы своих рекомендаций – речь идёт о:
- программистах, которые участвуют во внедрении или сопровождении ERP-систем. Считаю, что к ним немного иные требования, чем, например, к разработчикам нового продукта или технологии;
- программистах, которые работают у клиента. Разработчики интеграторов в меньшей степени склонны к «беспределу».
Так каковы причины этого явления и что с этим можно сделать?
Нежелание или неумение взглянуть в суть процесса
Я часто вижу это у начинающих аналитиков и программистов. Они просто отвечают на вопрос, который им задал заказчик. При этом не думают – почему он об этом спросил, действительно ли ему это необходимо? Со временем это проходит, но на первых порах приходится ловить и объяснять.
«А можно увеличить количество знаков после запятой для этого коэффициента до 4?» — «Конечно». А ничего, что этот коэффициент используется для индексации параметра, у которого точность в 1 знак после запятой, а значения не превышают 50? Вся точность коэффициента уйдёт в округление. Так может лучше этого не делать?
«Добавьте новое поле такого типа в справочник номенклатур» — «Хорошо. Трудоемкость 15 минут». Так, а для чего вам это поле в номенклатурах? Это же характеристика, которая меняется от партии к партии. Может лучше это поле добавить в справочник партий?Разработчик в ERP не должен быть просто реализатором изменений, которые озвучивают пользователи. Ему необходимо понимать логику системы и выступать её защитником от всякого бреда. Для этого неплохо бы разбираться в бизнес-процессах хотя бы на уровне здравого смысла и уметь задавать неудобные вопросы пользователям.
Поэтому если к вам ни разу не прибегал кто-то из пользователей с жалобами на наглость программиста, который отказался реализовывать его «хотелки», к этому разработчику стоит присмотреться. Возможно, он просто делает то, что ему скажут. А это редко заканчивается чем-то хорошим.
Недостаточная стойкость в борьбе с желанием оставить все по-старому
Это тот случай, когда программистский беспредел творится не разработчиками, но при их попустительстве.
Любой серьезный продукт несёт в себе не только набор определённых функций, но и идеологию, лучшие практики. А люди хотят работать по-старому. И давят на программиста, чтобы он им эту возможность обеспечил. И если он не смог доказать, что так делать нельзя, то всё может закончиться грустно.
Предприятие потратило много миллионов рублей, внедряет новую систему, были договоренности о внесении правок в учетную политику, в подходы к работе. Все радостно декларируют приверженность к новым подходам и новым ценностям. Но при этом сотрудник экономической службы приходит к программисту и говорит: «Вот этот отчет у нас на предприятии формируется ежемесячно с 1974 года, мне надо, чтобы он формировался из новой системы». И бесполезно объяснять, что в системе данные не ведутся в этом разрезе, что этот отчет устарел и есть другие, в которых можно пусть немного иначе, но посмотреть ту же информацию. «Мне надо, я генеральному этот отчет показываю, остальное – твои проблемы». И вот программист, униженный и оскорбленный экономическими службами, делает документ, для формирования которого надо в системе дополнительно заполнять десяток справочников и при обработке каждого производственного заказа ставить несколько дополнительных галочек. И если забыть поставить хотя бы одну галочку, то данные в отчете будут кривые. А ставят эти галочки не сотрудники экономической службы, а те самые мастера, которые чудом избежали ударов током. И вот мы обеспечили себя развлечениями на долгие годы: каждый месяц искать причины, почему этот отчет формируется неправильно, разборки экономистов с производством из-за галочек, куча негатива по отношению к новой системе. Хотя надо было просто один раз сказать: «Нет».Что с этим можно сделать? Для начала – не ставить программиста в подчинение экономическим службам. Он должен работать в другом подразделении и иметь определённую независимость от руководства отделов, чья работа автоматизируется.
Неплохо бы ещё добавить одно звено в эту цепочку: любые серьёзные доработки должны получить согласование не только у исполнителя, но и у кого-то, кто понимает бизнес предприятия в целом, и имеет власть. Такой человек точно сможет сказать: «Нет».
Привычка решать все проблемы программированием
Любовь к автоматизации ведёт к прогрессу, но иногда вредит. Я бывал свидетелем того, как вместо того, чтобы поручить людям вручную вводить данные в систему, этот ввод автоматизировали. Автоматизировали, забыв какие-то детали или особенности, которые при ручном вводе обязательно были бы замечены, обсуждены и, скорее всего, исправлены. А так – все уверены, что ошибок нет, но через некоторое время массово вылезают последствия, исправить которые уже намного сложнее, чем первопричину.
Был у нас клиент, который производил довольно сложную продукцию, состав которой определялся заказчиками. Сотрудник клиента сказал, что введет все покупные, детали, сборки в номенклатурный справочник руками. И сделал это. Не помню точно, но речь вроде шла о нескольких тысячах позиций. И ошибок в части номенклатур в дальнейшем было меньше, чем у клиентов, для которых данные в справочник загружались автоматом. Для меня это был отличный урок: эффективность и качество ручного ввода часто недооценивают.
Поэтому, когда программиста просят написать скрипт, чтобы исправить 200 ошибок, которые возникли из-за того, что пользователи работали не по инструкции, то он не должен сломя голову бросаться за клавиатуру. Надо оценить, сколько времени занимает исправление одной ошибки вручную, и, если время на ручное исправление всех ошибок не превышает трудоёмкости написания скрипта на порядок, заставить пользователей исправить эти ошибки самостоятельно: так больше шансов, что в будущем они будут работать по инструкции. Это надо ввести в качестве правила, повесить на стене около программиста, чтобы он мог в эту бумажку тыкать всех посетителей.
К тому же, мы почему-то думаем, что если освободить людей от рутинной работы за счет автоматизации, то они займутся чем-то полезным: начнут предлагать идеи по улучшению бизнес-процессов, оптимизируют отчётность, обучат менее опытных коллег. Но скорее всего у них просто станет больше времени на чай, перекуры и интернет на работе. Так стоит ли это того?
Самоуверенность
Есть функционал, который не стоит дорабатывать. В Аксапте это, например, сводное планирование. На моей памяти мы его трогали всего 2 раза. И каждый раз это было не встраивание в код, а своего рода «нашлепки» — функции, которые выполнялись перед или после сводного планирования. И даже так я вспоминаю эти доработки с тоской.
Есть и менее очевидные места, куда лезть не стоит. И отличный способ отличить опытного программиста от начинающего – предложить доработать такую функциональность: опытный будет удивлён и откажется, может посоветует оптимизировать бизнес-процесс, а начинающий скажет: «Давай».
Тут можно посоветовать одно: брать на работу людей с опытом, которые уже у других заказчиков или на других проектах набили все шишки, которые в принципе можно было набить.
Отсутствие регламента разработки
Когда мы берём проект на сопровождение, один из первых документов, который просим у заказчика – это регламент разработки, описывающий среду разработки, правила именования объектов, запреты и ограничения. Самое странное, что иногда его не бывает. И это верный признак – в коде будет трэш: начиная от классического отсутствия комментариев и заканчивая ситуациями, когда прямо в тексте были прописаны конкретные значения из справочников для разных веток алгоритма. А трэш в коде – первый шаг к проблемам с бизнесом.
Поэтому не надо рассказывать о том, что «программирование — это искусство. Его не регламентировать», «а как же agile?» и вот это всё. Если у вас ведется разработка, то должен быть регламент. И это не 3 пункта:
- разработка ведётся на приложении dev;
- тестирование ведётся на приложении test;
- в коде должны быть комментарии.
Это должен быть полноценный документ на десяток страниц с разделами:
- Требования к приложениям для разработки.
- Требования к написанию постановки задачи.
- Требования к написанию кода.
- Требования к тестированию.
- Требования к переносу между приложениями.
Как правило, весь хардкод делается по принципу «Сделаем по-быстрому, а потом сделаем нормально». Делается по-быстрому, а потом забывается… А когда есть подписанный документ, в котором указано, что так делать нельзя, то всегда можно ткнуть в него и сказать пользователю: «Быстро не получится, мне запрещено так работать. Извини, Алевтина Светозаровна, я бы рад тебе прямо на рабочей все проверки закомментировать, но меня потом уволят».
Одиночество и бесконтрольность
Одинокий программист – это зло. Всегда должен быть рядом тот, кто скажет: «Ну и что ты, дурак, накодил?» – иначе разработчик расслабляется, подзабивает на правила, забывает об ответственности. Отсюда начинается хардкод, сомнительные архитектурные решения, ошибки, влияющие на бизнес.
По-умному это называется «ревью кода» и это то, что должно всегда идти вместе с регламентом разработки. После каждой доработки перед её тестированием должна быть проверка на соответствие кода регламенту разработки и лучшим практикам. Ревью кода позволит:
- контролировать качество разработки;
- обучать менее опытных программистов.
Поэтому разработчиков должно быть минимум 3 штуки (двое всегда договорятся о том, что можно ничего не делать, третий участник системы вероятность сговора существенно уменьшит). И они должны работать по внутреннему регламенту, одним из ключевых пунктов которого является обязательное ревью кода.
Заключение
Таким образом, чтобы уменьшить вероятность «программистского беспредела» надо формировать свой отдел внутренней разработки по следующим правилам:
- Это должна быть команда хотя бы из 3 человек.
- Хотя бы один из этой команды должен иметь опыт внедрения или сопровождения ERP-системы, это должен быть его n-й по счету проект, где n > 3.
- Отдел разработки должен подчиняться в идеале непосредственно генеральному директору.
- Конечные пользователи должны иногда жаловаться на то, что программисты отказываются реализовывать некоторые их требования.
- Даже для такого маленького отдела обязательно должны быть разработаны регламенты, за нарушение которых надо наказывать.
Естественно, это мое видение. Его можно оспорить, на каждый из этих пунктов даже я могу из своего опыта привести контрпримеры, когда требование не соблюдалось, но всё было прекрасно. Но эти рекомендации можно использовать в качестве отправной точки для формирования своих принципов борьбы с программистским беспределом.
