Обходя ловушки

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

В статье «Внимание! В контрактах встре?чаются ловушки» (Computerworld Россия, № 6, 2004) рассказывалось о проблемах, которые могут возникнуть у ИТ-менеджеров при внедрении информационных систем или даже просто при закупке программного обеспечения, а также о путях их решения.

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

Купить или сделать?

Первый вопрос, которым задаются ИТ-директора, — заказать разработку программного обеспечения «с нуля» или купить готовый продукт? И кто будет разрабатывать (или доводить готовую программу «до ума») — свои разработчики или приглашенные со стороны.

Аутсорсинг весьма моден у теоретиков, но отечественные ИТ-директора относятся к нему достаточно прохладно. Ольга Соловьева, директор по информационным технологиям ОАО «Детский мир-Центр», уверена, что разработка силами программистов собственного ИТ-отдела имеет много плюсов: «Наша компания очень большая, мы многое разрабатываем для себя сами. Выгоднее держать в штате своих программистов, которые знают бизнес-процессы изнутри. Им не нужно долго объяснять, о чем идет речь, и, как следствие — в техническом задании им требуется не столь подробная формализация».

Отчасти с ней солидарен Андрей Паниди, начальник отдела информационных технологий Radisson SAS Slavyanskaya Hotel & Business Center, полагая, что заказ программного обеспечения собственным сотрудникам обойдется компании существенно дешевле, а кроме того, облегчит и значительно снизит затраты на последующую доработку, которая понадобится в любом случае. Правда, делать это можно лишь при условии, что они имеют достаточную квалификацию, опыт и свободное время.

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

Впрочем, разработка силами сотрудников собственных ИТ-отделов, имеет и достаточно минусов. Геннадий Серпик, директор по информационным технологиям ABBYY Software House, отмечает: «В некоторых компаниях, чей профиль не связан с информационными технологиями, сложилась порочная практика привлекать к разработке сотрудников своих ИТ-подразделений. То есть заставлять системных администраторов что-то разрабатывать на коленке. Но это не их работа. Они грамотные люди, но очень занятые и не обладающие специальными знаниями. Они не разработчики, они — эксплуатационщики».

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

Словом, если в ИТ-отделе компании кроме системных администраторов есть группа разработчиков, то прибегнуть к их услугам иногда действительно бывает выгодно и удобно. Если же речь идет о довольно серьезной программной системе, то вопрос этот вовсе не очевиден. Но, так или иначе, если вы все же решили заказать программное обеспечение стороннему разработчику, то постарайтесь правильно его выбрать.

Мы выбираем...

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

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

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

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

В каждой шутке...

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

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

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

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

С ним согласен Смирнов: «Договор — это попытка хотя бы отчасти застраховаться от проблем, которые могут возникнуть в производственном процессе. Но только в случае, если в договоре содержатся юридически значимые средства его реализации. Особенность России в том, что только в очень больших проектах можно завести судебную тяжбу и с ее помощью заставить договор работать. Но, как правило, проблемы между заказчиком и исполнителем решаются в личном общении, а не в судебно-правовом. Лично мне важно обеспечить удовлетворение клиента, а не побуквенное выполнение условий договора. Договор — это как элемент теории. А отношения с заказчиком — практика».

Все хотят «как лучше»

Описание желаемого результата — это, пожалуй, самый ответственный пункт контракта. Именно он определяет, что в конце концов получит заказчик. Мнения ИТ-директоров по этому поводу очень близки. Сергей Дмитриев, директор управления ИТ торгового дома «Копейка», полагает, что при заключении контракта необходимо, прежде всего, грамотно поставить задачу и четко описать результат, которого хочется достичь. Соловьева согласна с ним: «Самое главное в договоре — единое представление сторонами предметной области бизнес-процессов заказчика».

Ольга Соловьева уверена, что разработка силами программистов собственного ИТ-отдела имеет много плюсов, в частности им «не нужно долго объяснять, о чем идет речь»

Иначе, по словам Серпика, возникает такая ситуация: «Бывает, что пользователи, увидев новые экранные формы, разводят руками и говорят: ?Мы имели в виду совсем не это?. Разработчик предъявляет подписанное ТЗ, диаграммы. А заказчик: ?Но мы же не представляли, что это будет именно так?».

Иногда случается конфликт между требованиями и спецификацией.

«Обычно работу начинают с формулирования требований, список которых после согласования подписывается обеими сторонами, — констатирует Евгений Смирнов. — Далее на основе этого документа составляется спецификация для разработчика, подписанная также двумя сторонами. Но при этом существует риск, что, подписав спецификацию, заказчик, не будучи профессионалом в программировании, какие-то вещи понимает неправильно. Нередко бывает, что продукт сделан по спецификации, а клиент ориентируется на требования. Вопрос в том, для кого какой документ является первичным».

Решение проблемы, по мнению Паниди, в объединении усилий: «То, что вы платите деньги разработчику, не снимает с вас ответственности за проект. Вам придется работать не меньше, чем ему, иначе начнутся проблемы, вызванные различным пониманием того, как нужно было делать, и на проекте можно будет поставить крест».

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

Что написано пером?

Еще один камень преткновения — комплектность конечного продукта. Вопрос касается не только документации, но и, скажем, исходного кода программы.

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

Серпик добавляет: «Наличие документации крайне важно не только для пользователя, но и для разработчика, поскольку команда разработчика не всегда стабильна, люди мигрируют. Требование документировать разработку вынуждает аналитика изучать все фазы ее создания, а кодировщика — нормальным образом документировать код, подчиняя его определенным индустриальным правилам программирования. Эти правила должны существовать в любой программистской компании».

Петровский резюмирует с юридической точки зрения: «Момент, который не урегулирован законодательством, но периодически возникает на практике, касается исходных кодов. Закон ничего не говорит о том, надо их передавать или нет. Но если закон внимательно прочитать, то можно увидеть, что исходные коды и сама программа могут рассматриваться, как равноправные продукты. То есть по закону программа может быть представлена в разных формах. Если в договоре это специально не описано, то программа может быть поставлена в виде исполняемого модуля, в виде исходного кода, текстового либо объектного. А значит, в договоре должно быть четко указано, что поставляется».

Время — деньги

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

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

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

Возможна и иная ситуация.

«Изменившиеся условия иногда требуют ускорения разработки, но это может оказаться невозможным, — делится опытом Смирнов. — В договоре это отразить очень трудно, так как описать, сколько стоит такое ускорение, можно только опираясь на какую-то объективную основу. Тут важен опыт и использование понятных и разработчику, и заказчику метрик. Обычно мы начинаем с выделения области возможных решений, затем выбираем оптимальное решение из возможных, например, по цене».

Приемка — делу венец

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

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

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

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

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

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

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

Петровский указывает на следующую типовую ошибку: «Заключая договор на поставку программного обеспечения, заказчик не оговаривает, на какие права (исключительные либо не исключительные) он претендует. Поэтому такой договор охватывает фактически только один аспект — поставку заказчику лишь материального носителя, на который записана программа. Исключительные же права — это право заключать договора с другими лицами на использование данного ПО, а также право распространять его с доработками либо без таковых. Здесь есть еще одна тонкость. Если в договоре для заказчика прописывается получение исключительных прав на разрабатываемый продукт, это не означает автоматическое получение им исходных кодов — его нужно оговаривать специально. Другими словами, договор имеет два основных аспекта, один из которых регулируется законодательством об интеллектуальной собственности, а другой — нормами Гражданского кодекса о купле-продаже».

Краткий итог

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

Билль о правах

Клиент имеет право:

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

Команда проекта имеет право:

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

Источник: Software Project Survival Guide by Steve McConnell (Microsoft Press, 1997), перепечатано с разрешения издателя.