Одна из ошибок при переходе от инхауса к аутсорсингу

На неделе выступал перед довольно масштабной аудиторией наших разработчиков. Так как развитием ИТ систем в нашей компании занимается несколько сотен человек, то недостатка в слушателях не было. Выступая, затронул новую для себя тему. Похоже, об этом я еще нигде не рассказывал.
Итак, зачем компании нужна сервис-ориентированная архитектура
Существуют два, довольно разнящихся способа развития заказных, т.е. создаваемых по требованиям пользователя, ИТ систем компании внутренняя разработка и аутсорсинг. С внутренней разработкой все боле менее ясно. Сидит в штате компании группа программистов и рисует пользователям приложения. Пользователи регулярно прибегают с запросами на изменения, программисты лезут в код и что-то меняют. При аутсорсинге ситуация другая. Пользователи рисуют требования, согласуют стоимость их реализации, утверждают внутри компании необходимость потратить деньги на свои развлечения и отдают задачу внешнему разработчику. Через X месяцев у пользователей появляется ИТ система, с которой они потом будут работать через предоставленный им красивый графический интерфейс, у администраторов появляется административная консоль в которой они будут заниматься эксплуатацией системы, а вот у подразделения, ответственного за развитие систем, как правило, не появляется ничего(!) кроме проблем на ближайшие несколько лет.

Аутсорсер рано или поздно соскочит. Он живет проектами и когда тема исчерпает себя, делать ему в компании становится нечего. Ну, выпустит несколько релизов, но чем дальше, тем релизы (и выделяемые деньги) становятся меньше. Так что аутсорсер уйдет. Внутренние разработчики, конечно, тоже уходят, но не так быстро как аутсорсеры. А вот пользователи никуда не денутся. Они привыкли сочинять требования и не хотят отказываться от регулярных, как им кажется, улучшений.

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

Одна из ошибок при переходе от инхауса к аутсорсингу: 2 комментария

  1. В последнее время все чаще прихожу к выводу – хочешь сделать хорощо – сделай все сам! Поэтому, даже когда внедрением занимаются внешние подрядчики, руководство проектом должно быть у Заказчика, который должен максимально быстро создавать экспертизу по ИТ-решению внутри компании.

    1. Именно так! Может в этом сообщении я был излишне эмоционален, но просто ко мне приходят заказные разработки когда с ними уже и сделать ничего нельзя – экспертизы нет, менеджмент не справляется, интегратор ушел в глухую оборону.

      Как раз в этот момент у руководства и возникает желание “разобраться с архитектурой решения” =)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *