Доработка сайта или приложения

Денис Гордиенко, директор Bright Mobile о том, что делать, когда программист пропадает на 90% выполненном проекте и стоит задача найти нового.

Часто бывает так, что к нам обращаются заказчики и говорят, что у них есть, то или иное приложение которое делал ранее какой-то программист, но проект не завершен, и клиенту хотелось бы его доделать. Такие проекты бывают разной степени готовности: у кого то на 90%, у кого то на 70%, а у кого то и вовсе на 50%. Давайте разберём, как действовать в таких ситуациях.

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

Второй вопрос: это небольшие задачи по существующим завершенным проектам, которые делал другой разработчик. Как известно, нет предела совершенству, всегда найдется множество мелких правок и небольших задач, которые нужно быстро решить, чтобы улучшить уже работающий проект. На FL чуть ли не 20% всех задач - это доработка.

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

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

Часто такие проекты заказчик пытается подать как "маленькую" задачку. У вас есть глобальные проекты, вы над ними работайте, а мой проект уже почти готов. Тут работы-то совсем чуть-чуть осталось, сделайте быстренько, пожалуйста, и я буду счастлив. При этом заказчик не учитывает текущее положение дел нового программиста.

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

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

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

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

Соответственно, заказчик, когда ставит такую задачу, думает "что там разбираться, это же уже написанный каталог и фильтр. Я тебе заплачу, ты доделай и все будут счастливы". А программист в этом случае видит некое давление на себя. Ему нужно изучить два весьма крупных модуля (каталог и фильтр), затем оценить доработку. И только потом, возможно, получить деньги. При этом, есть риск получить претензию от заказчика, когда доработка сломала ранее написанный функционал. Заказчик это подаёт, как гарантийный случай, а программист всё сильнее хватается за голову куда он ввязался... Итог, думаю, очевиден.

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

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

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

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

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

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

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

Второе — если доработки у вас реально небольшие рекомендую копить мелкие доработки до крупного объема. Возможно мелкие задачи придется долго “копить” для нужного объема чтобы потенциальному исполнителю был интересен ваш проект. В этом случае возможно есть смысл рассмотреть заключение договора на обслуживание вашего приложения. Здесь мелкий заказ должен нивелироваться долгосрочным сотрудничеством, подтвержденным на бумаге. Такой подход повышается в приоритетности студии.

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