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

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

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

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

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

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

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

Возьмем аналогии из жизни. Есть два исполнителя. Первый получил подряд на строительство дороги. Второй — аналогичный подряд, но увязанный с обслуживанием этой дороги на протяжении 5 лет и поддержанием ее в соответствии с ГОСТами.

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

Леонид Боголюбов Apps4All, главный редактор
Если что-то не устраивает — надо от этого отказываться. Но для этого эту ситуацию надо просчитывать задолго до ее возникновения — хотя бы на уровне получения исходников программного продукта по завершению разработки.

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

В общем говоря, по моему, ситуацию проще предусмотреть на уровне договора (юридически), чем заниматься переходом.

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

Делается это исключительно для выбивания дополнительных денег с клиента.

Дело не столько в СП, сколько в архитектуре.
Архитектура - дело тонкое, творческое.

То есть, программистам не хватает настоящей работы и они вынуждены ее выдумывать?

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

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