Как принимать проекты от других разработчиков

Вы взяли сделанный кем-то до вас сайт на поддержку и началось:

• После вас в нем появились ошибки.

• До вас их не было.

• Другие ошибки были, а вот именно этой - не было

• И вообще сайт работал без проблем

Худшее, что можно сделать в этой ситуации - кинуться бесплатно исправлять ошибки.

Потому что тем самым вы

• Признаете себя виноватым в не вами созданной проблеме
• Как следствие, рушите отношения свои с заказчиком
• Роняете рентабельность проекта
• Торопитесь и как следствие, плодите ошибки дальше
• А ведь это не последняя ошибка в проекте, будут и следующие

В итоге через 2-3 месяца вы расстаетесь с клиентом, потратив на него бесплатно 50-150 часов разработки и напрочь потеряв его лояльность.

Как все же зарабатывать на поддержке проблемных сайтов?

Позитивная психология учит нас, что чувство счастья состоит из

• Чувства контроля

• Чувства прогресса

• Чувства высшей цели

Во-первых, в момент принятия проекта, нужно нарисовать клиенту дорожную карту будущей работы

Примерно так:

• У нас есть проект, который до нас 2 года разрабатывали и поддерживали. Более-менее подробной документации по коду в нем нет. Есть задачи, которые надо решить и есть проблемы, которые надо устранить. Плюс, в нем гарантированно есть проблемы, которые еще не проявились. По-этому готовимся к 2 месяцам «переходного периода». То есть в это время в проекте могут всплывать проблемы, о которых мы ранее не знали. Их нужно будет устранять платно. После этого мы с вами получим идеально работающий проект, полностью изученный командой разработки.

Во-вторых, ошибки реально надо искать и устранять

Как минимум: провести тестирование сайта на ошибки (платно, конечно же). Проверить его же на вирусы. При наличии, устранить

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

Первое и главное - увести обсуждение от поиска виноватых. Так уж сложилось, что искать можно или виноватых, или решение. И то и то сразу - не получается (в фокусе ясного внимания у человека единовременно находится только один объект).

Пример:

• Мы не можем доказать, что мы в этом не виноваты. Вы, в свою очередь, вряд-ли сможете доказать, что мы виноваты. То, что проблема возникла после нашего вмешательства, не означает, что она возникла из-за него. По-этому мы просим доверять нам на время и сумму исправления проблемы.

Продаем исправление ошибки. Исправляем. Ищем однотипные проблемы в проекте. Их тоже исправляем.

Их делаем исключительно на тестовой копии проекта. При помощи системы контроля версий, переносим сделанные работы на «боевую» версию сайта. Аналогично с ее помощью, переносим «хотфиксы» с боевой версии на версию для разработки.

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

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