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

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

В закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 13, "likes": 3, "favorites": 37, "is_advertisement": false, "subsite_label": "flood", "id": 106730, "is_wide": false, "is_ugc": true, "date": "Wed, 12 Feb 2020 19:22:31 +0300", "is_special": false }
Создать объявление на vc.ru
Дизайн
Adobe прекращает поддержку Muse CC. Ближайший аналог — Nicepage
Adobe Systems 26 марта 2020 года прекращает техническую поддержку Muse CC, сам проект закрыт еще в 2018. Muse CC — это…
0
13 комментариев
Популярные
По порядку
Написать комментарий...
7

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

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

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

Ответить
1

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

Ответить
3

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

Ответить
2

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

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

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

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

Ответить
0

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

Ответить
2

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

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

Ответить
0

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

Ответить
1

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

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

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

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

Ответить
1

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

Ответить
0

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

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

Ответить
0

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

Ответить

Прямой эфир