На днях наткнулся на размышления финансового аналитика, который рассуждал на тему, что некоторые вещи в своей жизни нельзя делегировать. В качестве одного из примеров он упомянул попытки бизнеса делегировать маркетинг под ключ. Поймал себя на мысли, что в разработке систем автоматизации для бизнеса все тоже самое. Невозможно нанять подрядчика, который разработает систему автоматизации для вашего бизнеса под ключ. Если вы приняли решение в пользу своей разработки, то будьте готовы засучить рукава и работать вместе со своим подрядчиком на общий результат.
Одним из главных пожеланий, которое я стараюсь продавливать в итоге, является выделение человека, курирующего разработку со стороны бизнеса. И если вы думаете, что он будет только контролировать процесс и принимать готовую работу, то глубоко заблуждаетесь. Зачастую у него появляются свои обязанности, от выполнения которых зависит итоговый результат. Нужно учитывать и быть готовым к тому, что этот человек будет тратить бОльшую часть своего времени на участие в разработке.
Почему же я так категоричен? Ответ прост, никто не может знать бизнес лучше, чем сам бизнес. Даже аналитики в команде разработчиков никогда не будут погружены в бизнес процессы настолько, чтобы разбираться в них как и тот, кто находится внутри них каждый день. Да и чего уж греха таить, хорошие аналитики в команде разработчиков – крайне редкое явление. На что можно рассчитывать – это на то, что вам помогут сформулировать требования (ключевое слово тут «помогут»), настроят процесс разработки, ну и собственно разработают систему на основе ваших требований.
К тому же разработка своей системы автоматизации — это уникальная возможность лучше узнать свой бизнес, обнаружить серые зоны в процессах и сформировать более цельное представление о том, как все работает.
Очень часто возникают ситуации, когда на вопрос «а что будет в таком вот случае?» заказчики отвечают что-то из серии «У нас таких случаев не бывает» или «Не знаем». Далее следует допрос с пристрастием с попыткой добиться более точных ответов, ответственный со стороны бизнеса отправляется в турне по отделам, чтобы получить ответы из первых уст. И очень часто выясняются интересные детали, что «несуществующие случаи» вполне себе существуют и сотрудники справляются с ними на свой страх и риск. Нередко попытка автоматизации приводит к изменению самих бизнес процессов. Через некоторое время представитель бизнеса, участвующий в разработке, накопит знания о том, как все функционирует не только в автоматизации, но и вообще в компании. Поэтому желательно, чтобы этот человек не был «случайным» и в случае его ухода необходимо заранее организовывать процесс передачи его знаний.
Если в разработке участвуют несколько подрядчиков, то представитель компании обязан выступать модератором их взаимодействия. К сожалению, очень часто этого нет, одному из исполнителей предлагают связаться с другим и что-то решить между собой. Выглядит очень странно, когда представители одной компании, не имея никаких рычагов влияния, пытаются достучаться до другой. К тому же неизвестны контрактные условия, на основе которых второй подрядчик работает с заказчиком. Да, разные подрядчики должны взаимодействовать между собой для достижения общего результата, но представитель заказчика обязан следить за этим процессом и вмешиваться в спорных ситуациях.
Следующей задачей, которой бизнесу придется решать – это внедрение системы автоматизации. Разработчики не смогут сделать этого своими силами. Опять же по причине отсутствия полномочий. Однако, даже если выдать им такие полномочия, то из-за незнания внутренней кухни, они могут наломать дров.
В большинстве случаев готового специалиста, способного взаимодействовать с разработчиками нет, поэтому заказчики любят тянуть с выделением ответственного за разработку со своей стороны. Но рано или поздно это придется сделать, и лучше раньше. Чем раньше начнется погружение, тем быстрее появится положительный результат. В нашей практике есть разные примеры представителей от заказчиков. Есть люди, имеющие ИТ-шный опыт, есть люди, которые никакого отношения к ИТ не имели. Но все они играют очень важную роль в разработке, которую иногда даже не осознают сами.