ФМ-ВЕЩАНИЕ: Само— или Тамореализация?

ФМ-ВЕЩАНИЕ: Само— или Тамореализация?

Автор: Феликс Мучник

На круглом столе, который проводил Сергей Рыжиков на Microsoft WebDevCon’06, обсуждалась тема о заказе разработок веб-приложений. Кому их заказывать — внутреннему подразделению компании или стороннему разработчику? Как их разрабатывать — с нуля или на основе тиражных разработок? Правда, всегда есть еще и пятый вариант — ничего не делать.

Вполне естественно, что с веб-приложений обсуждение плавно перетекло на любые IT-системы. Так как время круглого стола на конференции ограничено, то почему бы не продолжить обсуждение в журнале. Для затравки могу примерно повторить свою позицию применительно к уникальным веб-проектам. Что делать, если у вас возникла уникальная или инновационная технологическая бизнес-идея? Примерных аналогов в мире раз-два и обчелся, на тиражных продуктах сверху надстроить что-нибудь вряд ли получится. Выхода другого нет, как писать систему с нуля.

Главное — погасить первый душевный порыв и не писать систему самому на коленке. Естественно, некий прототип вы напишете, установите его на виртуальном хостинге, «это» даже будет работать на ограниченном числе клиентов, транзакций или что вы там будете обрабатывать. Но как только начнется настоящая работа, реальная нагрузка на систему, вы начнете работать одновременно директором, бухгалтером, системным администратором, поднимающим ночью упавший сервер, программистом, срочно латающим дыры в безопасности, логистом и бог знает кем еще. В сутках, конечно, 24 часа, но явно не 48. Я думаю, все интернетчики это проходили, а некоторые до сих пор думают, что это нормально.

Итак, страстей порыв погашен, приступаем к выбору вариантов. Вариантов, собственно, не так и много. Можно организовать у себя группу разработчиков, выбрать из них или нанять правильного руководителя проекта, объяснить ему задачу, поставить срок для запуска (предположим, шесть месяцев) и начать платить зарплату. Так как, по одному из принципов Паркинсона, «работа занимает все отведенное на нее время», то через шесть месяцев от руководителя проекта поступит предложение удлинить срок еще на шесть месяцев. Один мой знакомый разработчик вполне серьезно утверждал, что срок, объявленный программистами, надо умножать на 3,14. Через год система запустится, но так как во внутреннем (на два листа) техническом задании не были оговорены всякие мелочи, то еще через полгода система будет сдана в опытную эксплуатацию. За это время ряды коллектива разработчиков, подучившись, поредеют в связи с переходом на более высокооплачиваемую работу. Поэтому года через три руководитель проекта, кряхтя и матерясь, будет разбираться сам в коде, чтобы объяснить его четвертому составу разработчиков. Это совершенно не отрицает того факта, что система получится хорошая и рабочая.

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

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

О системах, которые можно построить, надстроить, настроить из тиражных продуктов, можем поговорить в одной из следующих колонок. Самим это делать или довериться опытной компании? Нужно ли учить у себя людей, умеющих настраивать тиражный продукт, если вы уже заказали всю работу сторонней фирме? Вопросов много, и я с удовольствием, как обычно, их прочту в письмах или в комментариях в моем блоге felixm.blogspot.com.