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

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

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

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

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

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

Я часто вижу это у начинающих аналитиков и программистов. Они просто отвечают на вопрос, который им задал заказчик. При этом не думают — почему он об этом спросил, действительно ли ему это необходимо? Со временем это проходит, но на первых порах приходится ловить и объяснять.

Разработчик в ERP не должен быть просто реализатором изменений, которые озвучивают пользователи. Ему необходимо понимать логику системы и выступать её защитником от всякого бреда. Для этого неплохо бы разбираться в бизнес-процессах хотя бы на уровне здравого смысла и уметь задавать неудобные вопросы пользователям.

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

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

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

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

Что с этим можно сделать? Для начала — не ставить программиста в подчинение экономическим службам. Он должен работать в другом подразделении и иметь определённую независимость от руководства отделов, чья работа автоматизируется.

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

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

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

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

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

Все рекомендации интегратора можно прочитать в официальном блоге компании ICL Services на Habr.