Когда заказчик просит просто дописать?

Как поступать если заказчик говорит “надо просто дописать проект”, а когда открываешь его и смотришь ТЗ понимаешь что кто-то что-то нарыгал а заказчик думает что у него что-то ценное уже есть?

Вот сейчас открыл ТЗ и понимаю что с нуля написать условно будет стоить 10 000 на что заказчик говорит чтоб я не выдумывал “дописать ведь можно”, говорю тогда только почасово 20/час - соглашается.

Я уже сталкивался с такими ситуациями и всегда это заканчивалось одинаково - дописывание сьедает весь бюджет заказчика 2 раза (на то чтобы сделать с нуля бюджета хватило бы) в итоге проект не готов и все рассорились. Но тогда не я договаривался и менджерил и мне было все-равно.

Конечно можно и дальше идти по-принципу как раньше - работаем пока заказчик платит почасово пока у него деньги не закончатся. при этом все понимают что проект не имеет шансов сколько бы его не дописывали
Как быть?
  • Вопрос задан
  • 220 просмотров
Пригласить эксперта
Ответы на вопрос 4
mazhekin
@mazhekin
Frontend, Backend Web Developer
Ну тут как бы вот какая ситуация. Программирование такая штука, что самое страшное - это запутаться в собственном коде. В основном проекты факапятся именно из-за этого. Много программистов которые знают по чуть-чуть разные языки, апи, интерфейсы, всякие модные термины и т. п. Но очень мало программистов, которые знают их глубоко и могут организовать код так, чтобы и самим не запутаться и не запутать своих коллег. Для этого требуется опыт и умения, немного другие, чем небольшие знания языка и всяких апи. Тут нужны умения применять инструменты, рефакторинга и всяких приемов разделения проекта на части, декомпозиции.

Ну начинается проект все ок. Программист пишет - пишет вроде бы начинают появляться рабочие экраны или работающий функционал, но он не следит за чистотой кода, игнорит или не знает рекомендованные стайлгайды, стиль кода постоянно меняется, все накручивается на базовых примитивах типа for-if, нарушаются декомпозиционные сущности, рефакторинг собственного кода (для дальнейшего облегчения понимания) отсутствует (главное чтоб работал). Постоянно его костылит. И код превращается в кучу крепко завязанного, запутанного говна. Попытки внести фиксы или дополнительный функционал в такой код приводят к ещё большим проблемам. Причем снаружи - это действительно выглядит как будто что то не работает по мелочам. Но поддержка и развитие такого проекта останавливается и автору коду уже невмоготу с ним работать, потому что петля этого монолита уже крепко затянута. И человек либо тянет время и просит нанять ещё разработчиков, либо просто уходит на "лучший офер". Заказчик думает что там осталось совсем чуть чуть. И любая попытка погрузить нового программиста в этот проект проваливается.

Тут бесполезно объяснять заказчику, что код очень сильно запутан. Воспринимайте этот запутанный проект - как челендж для себя. Думайте о том, что если вы его распутаете, поблочно перепишете и разложите все по полочкам, ваша стоимость увеличится в разы как специалиста. Оцените свои силы, научитесь жёсткому параллельному рефакторингу вместе с текущими задачами, декомпозируйте код на части, изолируйте части кода. Заказчику не произносите слово "рефакторинг". А писать с нуля - это не вариант. Вы просто протянете время и не факт, что не придёте к тому же, что сделал предыдущий разработчик. И потом свалите. Лучше научитесь плавно метаморфизировать проект при этом выполняя текущие задачи.

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

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

Да... работа такая у программиста запутанное(сложное) делать понятным(простым), а не наоборот.
Ответ написан
Lucian
@Lucian
https://ttttt.me/joinchat/AAAAAEyBK_H_kjlMf7ALig
Есть неадекватные заказчики, с ними лучше не связываться, т.к. уже по разговору понятно что проблемы будут с оплатой. Вы сами выбираете, дописывать вечно за другими или делать с нуля и качественно, чтобы другим не пришлось дописывать за вами.
Ответ написан
@Kostik_1993
PHP Backend Developer, Laravel, Yii, Vue, Node.js
Что-то вы лукавите. Если заказчик готов платить нормальные деньги то шанс стать полезным при наличии прямых рук разработчиков и адекватном управлении есть даже у какашки

Вопрос в том что вы не хотите этого делать изначально. 90% работающих проектов написаны по также как и описали вы, просто их кто-то взял и дописал как есть.
Безусловно если вы начнёте писать проект так как того хотите вы, то у вас не хватит на то времени и средств, потому что вы принципе хотите писать его с нуля. Доработать и запустить можно все и вам должно ровно побоку что там сейчас
Ответ написан
sim3x
@sim3x
Нет никакого рецепта
Слушайте, что и как говорит заказчик, подстраивайтесь, выясняйте его мотивацию, модерируйте его ожидания
И тп чепуха, которая никак не относится к ИТ
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы