12 апреля 2012 г.

Бремя выбора. К вопросу о заказной разработке



После публикации анонса о выпуске совместного решения лидера ПО для построения социальных решений для бизнеса компании Jive Software и пионера в индустрии геймификации – компании Bunchball, прочитал следующий вопрос в сообществе Jive, квинтэссенция которого заключается в следующем :”Почему компания, которая имеет достойную разработку, сама не написала модуль геймификации, а предпочла использовать продукт партнера?”
Ответ не заставил себя долго ждать, и, в достаточно лаконичной форме, сразу же просматривается высокий профессионализм команды управленцев вендора, которым не откажешь в построении четкой стратегии по достижению конечной цели (а именно, доступности качественного сервиса и решений для клиентов и, как следствие, своего финансового благополучия) – зачем разрабатывать что-то самим, когда можно взять самое лучшее на рынке и обогатить тем самым свою платформу (с меньшими для себя рисками, и, следовательно, сроками и себестоимостью реализации нового функционала).

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

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

Правило №1. Не изобретайте велосипед!
Никогда не ввязывайтесь в заказную разработку, максимально используя при этом готовые модули или решения. Другими словами, заказная разработка – это последний аргумент, когда все остальные средства оказываются несостоятельными или не подходящими для нужд вашего бизнеса. По моему опыту, это, как правило:

  • разработка уникальных систем, приципиально отличающихся от того, что есть на рынке;
  • различные работы по интеграции существующих унаследованных систем заказчика;
  • развитие или портирование унаследованных систем на другие платформмы или версии продуктов.

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

Правило №2 Анализируйте варианты!
Если Правило №1 все-таки не сработало и заказной разработке «быть», убедитесь в том, что компания-партнер (которую вы планируете привлечь к выполнению заказчной разработки) имеет достаточный опыт и ресурсы в реализации подобного уровня и тематики проектов. В противном случае, вы становитесь заложником полного случайностей процесса.

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

Помните, что по статистике только 30% проектов в ИТ заканчиваются в рамках изначально утвержденного бюджета и согласованных сроков. Искренне желаю, чтобы ваши проекты были в числе этих 30%, но и вы со своей стороны обезопасьте себя по всем направлениям, убедившись в компетентности подрядчика при выполнении заказных разработок и вашей комфортности по управлению проектом.

Не позволяйте себя вовлечь в проект, где исполнитель предстает перед вами как «черый ящик». Это – прямой путь к нервному срыву (и не только). Оно вам надо?

Правило №3 Надежный тыл – залог победы
Если все-таки ваша компания пришла к необходмости выполнения заказной разработки, подумайте, кто и как будет заниматься сопровождением и развитием решения, после завершения разработки. Как варианты, вы должны быть готовы к тому, чтобы своими силами суметь в дальнейшем развивать решение или же изыскать возможность по привлечению сторонних компаний (или команд разработчиков), которые смогут предложить вам более оптимальное соотношение цена-качество (так же помним о Правиле №2).
Учитывайте технологии, на которых делается решение. Если это уникальные технологии (редкие или слабораспространенные на рынке платофрмы разработки), то нужно серьезно задуматься, стоит ли ввязываться в такой проект. Стоимость поддержки и развития такого решения выльется вашей компании в копеечку, поскольку:
  1. на рынке мало специалистов в данной области;
  2. стоимость этих специалистов достаточно высока (по причине пункта 1)
и вы попадаете в зависимость к одной компании.

Правило №4 Конролируйте процесс
Доверяй, но проверяй. Начиная новое дело (проект), убедитесь, что в составе вашей проектной команды есть специалист (-ы), которые владеют как минимум следующим знаниями:
  1. управление проектами;
  2. знание предметной области;
  3. технологический гуру
что поволит вашей компании существенно снизить проектные риски.

Если кого-то из указанных персоналий в проектной команде нет – попробуйте найти его на стороне (только не у исполнителя, конечно) – это создаст хороший противовес с точки зрения принятия правильных решений на проекте. Следует помнить, что любое из перечисленных направлений, а тем паче, их комбинация, существенно влияют на то, окажется ли ваш проект в заветных 30% или нет (см. Правило №2).


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

Что лучше – заплатить за работающее решение с четкой ценовой политикой и дорожной картой развития сервиса и поддержки (с которым, к тому же, можно поработать) и сосредоточиться на его применении для управления компанией, или же начать заказную разработку, базирующуюся на вашем видении вопроса, с привлечением сотрудников, навыки которых, возможно, не совсем вписываются в бизнес вашей компании (см. Правила №3 и №4), принять риски, связанные с разработкой.

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

И хотелось бы всем пожелать, чтобы ваши решения были взвешенными и хорошо просчитанными как с точки зрения уникальности ваших требований, так и минимизации потенциальных рисков, которые могут сопровождать ваш проект.
Удачи!