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

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

До сих пор люди не придумали ничего лучшего, чем бесконфликтное выполнение, но такое, которое не принесёт никаких проблем. Да, таким образом мы потеряем немного времени, но уйдём от необходимости вступать в долгие переговоры, которые вряд ли кончатся чем-то хорошим. На выручку приходит локальное программирование, или программирование в языковой среде используемой системы.

Предположим, что некий руководитель компании, в обслуживании которой мы кровно заинтересованы, вполне официально потребовал создания возможности прямого изменения складских остатков: без инвентаризации через созданное мобильное приложение android, оформления приходных и расходных ордеров, актов списания. Скажете, что такое невозможно? Практика показывает, что такие «просьбы» встречаются в ходе любого внедрения локальных бизнес-приложений. Казалось бы, выбор стоит между тем, чтобы делать, что приведёт базу данных в негодность, и не делать, что потребует каких-то обращений к вышестоящему руководству. Но есть и третий путь: создать для него совершенно автономную базу данных актуальных остатков, синхронизировать с настоящей и открыть доступ для прямого изменения нужных показателей. И дело тут не только в дипломатии и желании уйти от конфликта.

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

• выявляем истинное состояние дел и актуализируем проблему;

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

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