Управление разработкой сайта на предприятии

5 мая 2005 в 0:00

Выбор разработчика и их классификация, состав технического задания, заключение договора с разработчиком и стоимость - обо всем этом подробно рассказывает Юрий Зиссер.

Выбор разработчика

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

Разработчиков можно искать многими способами, например:

1. Через знакомых специалистов.
2. Посмотреть, кто разработал сайты, которые Вам нравятся, либо сайты Ваших конкурентов.
3. Через поисковые системы в интернете.

Классификация разработчиков

Студии дизайна можно разделить на три категории, перечисленные ниже по мере возрастания профессионализма.

1. Любители. Пара людей (или даже один человек), работающие дома или на работе в свободное от учебы или работы время. Основное конкурентное преимущество – демпинговая цена, достигнутая за счет низкого уровня доходов разработчиков, помноженная на уклонение от всех видов налогов и издержек за счет нелегального существования. Оплата – наличными или путем заключения договора с несуществующей фирмой, что чревато приходом на Ваше предприятие налоговой инспекции. Если не считать низкой цены, по всем остальным статьям любительские студии проигрывают двум следующим категориям. Важно отметить, что любительские студии не так уж часто становятся профессиональными. Проходят годы, а квалификация большинства любителей растет незначительно. Любители, достигшие уровня компетентности, поступают на работу в другие студии. Качество сайтов, разработанных лучшими профессиональными программистами отдела АСУП Вашего предприятия, вполне соответствует любительской категории «студий»: никто не стоит дальше от маркетинга, чем технические специалисты.

2. Отделы компьютерных, программистских фирм или интернет-провайдеров. Они получают заказы от своей материнской фирмы, для которой веб-дизайн – побочная деятельность. Квалификация разработчиков и цены средние. Зарплаты разработчиков невелики, и вообще веб-дизайн обычно находится далеко не в центре внимания руководства крупной материнской фирмы, что вынуждает специалистов студий искать «левые» заказы. Набравшись опыта, студии-отделы через 1,5-2 года после начала работ всей командой уходят в свободное плавание и становятся независимыми разработчиками. Явление исхода студий-отделов является скорее правилом, чем исключением. Причина – низкие доходы разработчиков, хронически отстающие от качества их работы. На освободившиеся места набирают новичков, качество работы которых вполне соответствует первой, любительской категории, после чего «двухлетний цикл» повторяется. По моим субъективным наблюдениям, особенно характерны подобные ротации кадров для некомпьютерных фирм и (почему-то) интернет-провайдеров.

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

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

Оценка студии-разработчика

Студии оцениваются по четырем следующим основным критериям.

1. Портфолио, или выполненные работы студии. Это самый важный критерий. Если портфолио нет, студия начинающая. Важно не только общее количество выполненных сайтов, но и их профиль. Скажем, если студия специализируется исключительно на разработке электронных магазинов, то еще неизвестно, до какой степени ей удастся с первой попытки разработать идеальный сайт для фабрики спорттоваров (хотя возможно и такое). Посмотрите сделанные студией сайты, причем особенно внимательно изучите собственный сайт студии. Он должен соответствовать критериям оценки сайта, изложенным в этой статье. Если студия толком не умеет продать свои услуги, то с большой вероятностью сделанный сайт Вашего предприятия тоже не будет ничего продавать. Вообще, способность порождать продажи – самый главный критерий оценки сайта. Не столь важны дизайнерские изыски, особенно для В2В-сайтов – посмотрите, например, на сайты мировых гигантов в области информационных технологий IBM www.ibm.com или Intel www.intel.com. Cайты этих компаний далеки от красочности, динамики и прочих дизайнерских «штучек». Зато на этих сайтах присутствует буквально вся информация, которая только может заинтересовать посетителя. Вот почему всё должно быть подчинено задаче увеличения продаж предприятия или иной провозглашенной цели создания сайта.

2. Человеческий фактор, наличие квалифицированных кадров. Обязательно посетите офис студии и внимательно понаблюдайте за обстановкой в офисе и за отдельными сотрудниками. Обратите внимание на манеры общения сотрудников друг с другом и – особенно – на отношение руководства к подчиненным. Невзначай выясните, те ли это работники, которые делали замечательные прошлогодние работы: ведь разработчики с тех пор могли уволиться всей командой, а работы остались в портфолио студии. Постарайтесь определить масштабы лжи и решите, находится ли она в пределах, согласующихся с Вашими представлениями о честности и порядочности. Если молодые ребята говорят, что разработали 15 сайтов, а оказалось, что только 12, это неважно. А вот если они приписывают себе чужие работы, откровенно без повода обливают грязью конкурентов и общаются друг с другом на высоких тонах или на «фене», то лучше не иметь с ними дела. Если с разработчиками неприятно общаться, либо они не сразу отвечают на письма и звонки, то тоже не стоит продолжать, кто бы ни рекомендовал их Вам.

3. Уровень технологической оснащенности студии. Хороший мастер виден по его инструментам. У каждой уважающей себя студии есть собственные наработки, инструменты, «движки». Обычно их называют системами управления контентом и присваивают им марочные имена. Если такой системы нет, то работа делается «на коленке», и перед Вами – типичные любители-ремесленники. Впрочем, хорошие технологии, как правило, сопутствуют богатому и разнообразному портфолио, поэтому этот критерий скорее вспомогательный по отношению к первому – качеству портфолио.

4. Поговорите с кем-нибудь из предыдущих заказчиков студии. Координаты легко взять с их сайтов, перечисленных в портфолио студии-разработчика. Расспросите, довольны ли они своим сайтом, есть ли от него польза, легко ли работалось со студией, было ли взаимопонимание, соблюдались ли сроки, оперативной ли была реакция на пожелания, каким образом осуществляется поддержка сайта. Если первое же «интервью» расходится с Вашими представлениями, полученными из пп.1-3, это должно Вас насторожить (хотя бывают и откровенные наветы). В таких случаях имеет смысл поговорить еще с 1-2 предыдущими заказчиками.

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

Использовать ли системы управления контентом?

Декларация наличия собственной системы управления контентом (информационным наполнением сайта) – признак зрелости разработчика. Как упоминалось выше, разработка динамических сайтов обходится значительно дороже, чем статических. Существуют типовые программы-«движки» для динамических сайтов, называемые «системами управления контентом», или по-английски CMS – Content Management System. В состав CMS включаются стандартные программные модули публикации новостей и анонсов, формы опросов, рассылок, счетчиков, анкет, а также каталогов товаров, цен, форм заказа, «корзина покупателя» и др.

Проблема в том, что лучшие зарубежные CMS производства фирм IBM, WebMethods, Intershop и пр. чрезмерно дороги для нашего рынка и являются скорее мощными инструментами разработки, чем готовыми системами. Некоторая возможная экономия за счет получения готового качественного многофункционального «движка» компенсируется дороговизной работ по адаптации, «привязке» и дальнейшему сопровождению системы, требующей высокооплачиваемых сертифицированных специалистов. (Для специалистов-компьютерщиков ситуация напоминает последствия приобретения СУБД Oracle для малых автоматизированных систем). Число внедрений в СНГ всех зарубежных CMS, вместе взятых, составляет менее сотни, а в Беларуси - единицы.

Лучшие российские и отечественные системы управления контентом (Dynasite, Saitistika, SiteHead и др.) также не получили широкого распространения. Например, в обзоре «Системы управления контентом» («Сети», 4.03.2003) система DynaSite отнесена к числу наиболее распространенных на том основании, что за 5 лет с ее помощью реализовано более 20 сайтов. Зная примерное число сайтов в России (порядка 150 тыс в домене .ru, плюс примерно столько же российских сайтов, находящихся вне доменной зоны .ru), нетрудно подсчитать, что рыночная доля этого продукта составляет менее 0,01%. Конечно, мне могут справедливо возразить, что для простых сайтов система управления контентом вообще не нужна. Однако, даже если считать, что CMS нужна лишь в одном сайте из 10, все равно доля использования стандартных CMS ничтожна. Подавляющее большинство ресурсов, в том числе крупных, работает на доморощенных «скриптовых» CMS, специально разработанных для данного сайта и больше нигде и никогда не используемых.

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

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

Ситуация стабилизируется в течение нескольких лет: системы управления контентом станут более надежными и гибкими, будут хорошо документированы, число внедрений ведущих CMS превысит по крайней мере сотню-другую, их возможности существенно вырастут, а цены упадут в несколько раз – до сотен долларов. Тогда на них появится массовый спрос, и через 10 лет станет непонятным, по какой причине в начале XXI века при разработке сайтов не использовались CMS.

Состав технического задания

В состав технического задания включаются следующие обязательные разделы.

1. Аннотация. Здесь указывается, что содержит документ. В аннотации принято указывать основание появления документа на свет – например, делается ссылка на полученную студией заявку.

2. Содержание. Обычное оглавление с перечислением разделов и подразделов и номеров страниц.

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

4. Общее описание сайта. Здесь отражаются общие требования к направленности и содержанию сайта, которые Вы передали студии: вид сайта («электронный буклет», электронный магазин, промо-сайт и др.), доменное имя и т.д.

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

6. План-график выполнения работ. В плане должны стоять конкретные даты сдачи этапов с указанием содержания каждого этапа.

7. Порядок разработки и ввода контента (информации): текстов, картинок, фотографий, логотипов и т.д. 1-2 фразы о том, кто, как и когда предоставляет контент.

8. Порядок приемки-передачи выполненных работ. Здесь может оговариваться создание комиссии по приемке выполненных работ и указываться ее состав.

9. Порядок внедрения, размещения на хостинг-площадке и запуска сайта (только для сложных сайтов). Объем – на усмотрение разработчика. В одних случаях достаточно лишь упоминания об этом, в других – в этом разделе может обосновываться выбор хостинга.

10. Состав документации. Как правило, обязательно только краткое Руководство пользователя. Для крупных сайтов могут потребоваться и другие документы: Руководство администратора сайта, Руководство администратора электронного магазина или торговой площадки, Руководство системного администратора и т.д.

11. Обратная связь. Указываются полные координаты разработчика и лица, ответственные за контакты с Вами.

Оценка технического задания

Оцените качество оформления полученного документа. Техническое задание представляет собой формальный (реже неформальный), хорошо оформленный (желательно в соответствии с государственным стандартом) документ длиной 10 и более страниц. Если оно короткое (2-3 страницы) либо плохо оформлено, студия не очень-то опытна. Документ должен быть хорошо структурирован, легко читаться и не содержать грубых грамматических ошибок. Техническое задание составляется в настоящем времени, т.е. пишется «Сайт содержит то-то и то-то», а не «сайт будет содержать» или «сайт должен содержать». В техническое задание не включаются явно рекламные тексты и общие рассуждения, раздувающие объем документа.

Обратите особое внимание на то, чтобы все Ваши требования к сайту нашли формальное отражение в техническом задании – по крайней мере, те требования, которые были выражены Вами письменно. По степени учета Ваших пожеланий можно судить, насколько серьезно к Вам отнеслись, и насколько серьезна студия.

В то же время не ждите, что разработчик будет Вам заранее бесплатно расписывать все подробности и проводить полное обследование предприятия до заключения договора. В техническом задании только упоминаются и перечисляются необходимые моменты. Немногие из разделов технического задания занимают больше 1-2 абзацев. В соответствии с требованиями государственных стандартов каждый раздел должен начинаться с новой страницы. Вот почему правильно оформленное техническое задание состоит из полутора-двух десятков страниц, на большинстве которых заполнено всего несколько строк. В «правильном» техническом задании должно быть порядка 15000-20000 знаков или 2000-2500 слов.

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

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

Организация выбора разработчика

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

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

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

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

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

Заключение договора с разработчиком

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

1. Наличие подробного плана-графика выполнения работ, в котором каждый этап сдается не реже чем 1 раз в 2-3 недели.

2. Гарантийный срок, на протяжении которого замеченные дефекты устраняются бесплатно. Обычно этот срок составляет от 3 до 12 месяцев.

3. Ответственность за нарушение сроков со стороны разработчика должна составлять не менее 0,5% суммы договора за каждый день опоздания по его собственной вине. Разумеется, право разработчика – оговорить при этом, что в случае задержки предоставления предприятием необходимой информации срок отодвигается на число дней задержки, а также потребовать от Вашего предприятия взаимной ответственности за задержку оплаты выполненных работ.

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

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

6. Наличие подробного технического задания, включая содержание сайта, схемы расположения элементов экрана (если необходимо), форматы данных для связи с программами других разработчиков. Например, если речь идет об электронном магазине, то необходимо предусмотреть оповещение отдела сбыта по электронной почте, передачу данных в систему управления сбытом, связь с бухгалтерским и торговым комплексом (например, с программами серии 1С:Предприятие).

7. Документация по использованию сайта и программ. В ней должно быть достаточно подробно описано, как рядовой компьютерно грамотный пользователь без помощи разработчика или программиста может совершать действия по обновлению сайта. Не забывайте, что обновление сайта на крупном предприятии вполне может быть децентрализованным. Например, на сайте банка курсы валют может ежедневно вводить валютный отдел, процентные ставки по депозитам и кредитам – соответственно депозитный и кредитный отдел и т.д. (Пытаться централизовать сбор и обновление большого объема часто обновляемых данных обычно не стоит, т.к. это может привести к задержкам и сбоям с их публикацией). Средствами нерегулярного обновления вполне могут являться любительские подручные инструменты типа FTP-доступа через простую знакомую Вам программу (Windows Commander, FAR и т.п.), о чем должно быть сказано в документации. Однако если обновление ведется часто, то необходимо включить в техническое задание на разработку сайта специальные администраторские формы обновления (как их называют на жаргоне, «админки»), которые должны быть описаны в документации. Кроме того, ответственный за сайт может самостоятельно разместить (или, как говорят дизайнеры, «залить») сайт на компьютере хостинг-провайдера, а также изменить, добавить, удалить любую информацию на сайте без помощи разработчика.

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

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

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

Цена

Твердых цен на разработку сайтов не существует. Сайт может обойтись и в 300, и в 30000 долл в зависимости от объема работ, степени динамичности сайта, квалификации студии, качества получившегося сайта и объема последующей рекламной кампании. Если разработчик называет цену своих услуг еще до выяснения требований к сайту – гоните его.

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

Существует следующий способ управления затратами: выполнить предоплату 20-25% и ждать первых результатов; если понравится – платить дальше и т.д.

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

Как рассчитать цену? Для этого широко используется почасовая ставка. В целом по отрасли накладные расходы нередко достигают 200%. Это означает, что для обеспечения производственному персоналу (дизайнерам, программистам) заработной платы в 200-300 долл «чистыми» на него должно приходиться хотя бы 800-900 долл безналичных денежных поступлений.

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

Не слушайте экономистов крупных предприятий о якобы чрезмерно большой величине накладных расходов в 200%: мол, таких высоких процентов не может быть, и 40-50% - это якобы максимум. Спросите у этих экономистов, каковы, по их мнению, должны быть расходы по разовым работам. Ведь накладные расходы крупных белорусских промышленных предприятий по изготовлению уникальных товаров малыми партиями по разовым заказам нередко составляют 2000-2500%.

Объяснение состоит в том, что эти экономисты промышленных предприятий привыкли иметь дело с другими (обычно материалоемкими) отраслями серийного или непрерывного производства, а также с предприятиями массового рынка, в которых накладные расходы редко превышают 40-60% из-за однотипности производства и высокой доли стоимости материалов в цене изделий. В то же время проектный характер труда сам по себе предполагает высокий уровень накладных расходов.

Как сделать подряд успешным

Коммуникация – ключевой момент для успеха подряда. Необходимо продумать способы общения (личная встреча, электронная почта, телефон, ICQ и т.д.). Лучше всего, когда студия находится ближе к Вашему офису.
Главный Ваш риск при подряде – потеря контроля над разработкой. Ведь Вы не видите, что и как делает разработчик. Поэтому необходимо предусмотреть как можно больше контрольных точек. Думать, что можно заключить договор и забыть о проекте до момента сдачи работы – опасная иллюзия, сгубившая не один проект. Если Вы не будете участвовать в процессе разработки, то можно гарантировать, что в результате получится совершенно не то, чего хотелось изначально.

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

1. Управляйте внешним проектом тщательнее, чем внутренним.

2. Сделайте приоритетом общение с разработчиком. Выделите специалистов для ответов на вопросы разработчика.

3. Тщательно выбирайте разработчика и тщательно готовьте договор.

4. Техническое задание должно быть как можно более подробным.

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

1. Частая (хотя бы один раз в неделю) оценка результатов. Это помогает получить сайт, адекватный Вашим ожиданиям.

2. Регулярная отчетность разработчика перед заказчиком о ходе работ.

3. Ведение разработки полностью или частично на территории Вашего предприятия. Эта чисто западная практика аутсорсинга (так называемый consulting, кстати, не имеющий ничего общего с консультированием) позволяет Вам полностью контролировать процесс разработки, скорее всего, за счет повышения цены.
Большая часть проблем, возникающих при подрядной разработке – не технические, а организационные, психологические, культурные. Они требуют от обеих сторон доброй воли, доверия и постоянного общения.

Управление доработками сайта

Уже в договоре на разработку сайта необходимо предусмотреть возможность бессрочной платной поддержки. Ведь поддержка – работа для разработчиков невыгодная. Дело в том, что для любой студии выгоднее взять новый крупный заказ на 10000 долл и спокойно работать над ним несколько месяцев, чем бегать неделю к заказчику, уточняя мелкое изменение, за которое предприятие, стиснув зубы, нехотя выплатит какие-нибудь 300 долл. Да еще нужно будет доказать заказчику, что требуемое изменение займет существенное время и не может быть сделано бесплатно. Для дизайнера переделка – ненавистная работа, т.к. кажущиеся заказчику незначительными на вид изменения часто влекут полную переработку дизайна. Если же речь идет о программировании, то даже если нужно изменить одну строчку в большой программе, на ее поиски и последующее тестирование нередко уходит несколько дней и даже недель.

«Ведь тут же достаточно чуть-чуть подправить!» – возмущается заказчик и настаивает на символических ценах. Трудоемкость разработки 5000-долларового сайта нередко оказывается всего лишь вдвое-втрое выше, чем по выполнению «небольшого» 500-долларового пакета десятка малозначительных изменений. Поэтому не удивляйтесь, если разработчики под любыми предлогами (перегруженность, болезнь, отпуска) саботируют процесс внесения изменений, затягивая его на годы. Бывает, что откровенно предлагают полный редизайн сайта – за соответствующие деньги, конечно. Вот почему пока так редки случаи обновлений: настаивая на демпинговых условиях («Ведь мы же уже один раз заплатили Вам деньги!») и не найдя компромисса, предприятие выбирает другую студию, которая полностью переделывает сайт, причем новый сайт удивительно часто оказывается хуже старого.

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

1. Незначительные, на Ваш взгляд, изменения могут повлечь трудоемкие переделки, и наоборот.

2. Не пытайтесь вынудить разработчика за незначительные суммы переделывать половину сайта. Цена должна быть адекватной объему работ, который для Вас может быть неочевидным. Внимательно прислушивайтесь к аргументам разработчика.

3. Старайтесь договориться о доработках с первым разработчиком, ибо это всегда лучше и дешевле. Меняйте разработчика только в том случае, если Вы не удовлетворены его работой в целом, и сайт все равно нужно разрабатывать заново.

4. Старайтесь максимально участвовать в процессе разработки, чтобы сайт максимально удовлетворял Вашим представлениям о нем.

5. Не исправляйте часто и понемногу. Вносите изменения достаточно редко (не чаще 2-3 раз в год) крупными порциями. Это будет легче и проще и для разработчика, и для Вас.

Автору лишь остается пожелать Вам успехов в управлении разработкой сайта.

Впервые опубликовано в Журнале TUT.BY по электронному бизнесу, #12, 2004г.