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

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

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

Откуда проблема

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

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

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

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

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

Как ситуацию видит программист

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

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

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

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

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

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

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

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

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

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

Когда уместно поставить задачу

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

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

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

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

0
14 комментариев
Написать комментарий...
Виталий Подольский

О, Денис сам себя описал. Неужели готовится очередной слив клиента?

Тут же как минимум три человека писали, что вы им слили проект. В памяти свежо еще вот это: https://vc.ru/claim/100849-lichnyy-opyt-raboty-s-ekspertom-po-marketpleysam-bright-mobile

Насколько помню, Егор так и не нашел исполнителя на доработку кода после вашей компании. 

Ответить
Развернуть ветку
Альберт Штерн

Мне кажется это редакторы поменяли

Ответить
Развернуть ветку
Егор Рабцевич

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

Ответить
Развернуть ветку
Dmitry Egorov

Если заказчик говорит, что проект готов на 80-90%, это означает, что там работы ещё много осталось. Стараюсь избегать таких проектов. Они большей частью токсичные.

Принцип Парето нам намекает:
1. 20% усилий дают 80% результата
2. 80% усилий дают оставшиеся 20% результата

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

Чуть больше про принцип Парето рассказал в этой статье - https://vc.ru/dev/105105-keys-iz-chehii-lyudi-ne-umeyut-ocenivat-stoimost-po

Ответить
Развернуть ветку
Stas Sokolov

Всё намного проще - нужно изначально писать проект на массовом фреймворке. Я сам наступил на эти грабли.

Ответить
Развернуть ветку
Артём Рыжков

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

Ответить
Развернуть ветку
Stas Sokolov

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

Ответить
Развернуть ветку
Артём Рыжков

В целом согласен, но даже тут бывают свои косяки. Особенно в Fron-End разработке, так как там, почему-то, паттерн SOLID - многие даже не знают как расшифровывается. 

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Да, это частично снимает риски, но возьмите, к примеру, реакт. Накодил человек и пропал. Другому реактовцу же всё-равно нужно изучить что там сделал предшественник. 

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

Ответить
Развернуть ветку
Stas Sokolov

И на это спецу нужно несколько часов, если это известный фрейм.

Ответить
Развернуть ветку
Dmitry Egorov

Сомнительно.

Реальный кейс. Для заказчика на популярном фрейме мы разработали интеграцию с системой ЭДО. Трудоёмкость ~ 250 часов.

Некоторые фичи, которые были сделаны: 
- генерация xml по 4 типам исходящих документов (счёт, акт, накладная, счёт-фактура)
- upload в API вендора, хитрый docFlow по всем исходящим документам (он уникальный по каждому типу)
- загрузка входящих документов от поставщиков.

Опыт мне подсказывает, что меньше чем за 30 часов новый боец (без документации, журнала проекта) не разберётся во всех тонкостях работы решения

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

Ответить
Развернуть ветку
Dmitry Egorov

"Работало, а ты сломал" - отдельная большая боль.

Особенно неприятно бывает, когда ты знаешь, что не трогал ничего и оно так всегда работало.

Ответить
Развернуть ветку
Roman Krivin

Что делать, что делать. Самому пилить остаток проекта, как петух клюнет. Иначе это не работает, либо протрачивай дэдлайн и получай от клиента.

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда