9 июня 2009 в 13:21
В последнее время всё чаще сталкиваюсь с тем проектами, где предыдущий разработчик что-то не закончил, не доделал или не успел.
Опыт показывает, что заниматься подобными "работами над ошибками" просто вредно.
Почему?
- Нормальный разработчик в состоянии закончить свою работу, а раз она, в силу разных обстоятельств, не была закончена, то можно судить о качестве кода, архитектуры и аккуратности.
- Кроме того, как правило встречаются сайты, которые пытаются быстро собрать за счёт CCK, Views, Panels, Contemplate, что сказывается и на архитектуре и на производительности сайта.
- Как правило делаются вещи, которые можно быстро включить и показать, а не глубинные изменения за которыми заказчик как раз и обращается ко последующему (чуть не написал второму - а зачем же себя ограничивать!..) разработчику. Следовательно заказчик считает сайт готовым, но нужны "незначительные" доработки, а это сказывается на отношении к стоимости работы.
- Разбираться в чужом коде всегда сложнее, чем в своём, хотя в подобных проектах кода как правило мало, но всё же.
- Предыдущий разработчик считает, что он работу выполнил на все 100% и помогать в развитии соотвественно не заинтересован - деньги-то он уже получил!..
- Разработчик, который не закончил работу как правило исчерпал бюджет заказчика и последний старается на оставшиеся деньги быстренько вдохнуть жизнь в сайт...
Я предлагаю заклеймить позором таких разработчиков и не соглашаться на подобные заказы, потому что:
- Нужно иметь самоуважение и не убирать мусор за другими неряхами.
- Разработчик должен отвечать за свои слова и подтверждать это делом.
- Вы не сможете гордо подписаться под этим "сайтом", а значит для портфолио эта работа не имеет смысла.
- Если разработчик начал делать сайт, то он должен его закончить и заказчику нужно решать вопросы с тем, кто сайт делал.
Предлагать заказчику создать сайт с нуля глупо, потому что он считает, что сайт уже почти-почти готов и нет смысла тратить деньги снова, поэтому ничего другого я не могу придумать как оставить заказчика наедине со своим почти работающим сайтом для анализа своих отношений с разработчиками...
Разве что вариант конкретной модификации сайта, но и тут много подводных камней, потому что иногда кажется, что это сделать легко, но архитектура, которую заложил предыдующий разработчик просто не позволяет это реализовать и придётся серьёзно переделывать сайт.
Советы заказчикам:
- Если вы хотите экономить на создании сайта, то лучше экономьте на своей зарплате - сайт должен работать без посторонней помощи годами (за исключением обновлений модулей и ядра), поэтому есть смысл найти хорошего разработчика и оплатить его работу.
- Хороший разработчик доводит свою работу до конца. Это вы можете проверить договорившись о поэтапной оплате работы.
- Контролируйте каждый этап и не думайте, что вы нашли "гуру", который и сам знает что и как нужно сделать. Примерно половина времени разработки уходит на согласование деталей - иначе человек сделает так как сочтёт нужным и это может не совпасть с вашим видинием.
- Распределяйте сложность работ по этапам равномерно, чтобы в самом начале было видно справляется разработчик или нет.
- Нужно понимать что чем ниже цена, тем ниже качество. Если вас это устраивает, то лично я предпочитаю делать качественные сайты и гордится своей работой.
Если вы уже счастливый обладатель "почти" готового сайта, то вы можете поделиться своими впечатлениями ниже.
PS. Интересное наблюдение. К ногам планета хорошо прилипает, а вот к голове как-то не очень.
К голове и спине тоже нормально, к голове и пузу и даже к попе и ногам хорошо прилипает, а вот от головы постоянно отклеивается...
Мда. Эту планету ещё программировать и программировать... 
Комментарии
+100500
даже оспорить нечего, хотя иногда приходится браться за веник. Но обычно это заканчивается плачевно в том плане что либо в конце оказывается что денег нет 
или начинается тупо правка тобой-же залитого кода и упрекание что вот я говорил сделать а вы не сделали, что в итоге приводит в разладу (это из личного опыта, был заказчик я правлю СSS заливаю вечером на живой хост, утром приезжаю на работу вижу в аське сообщение что я ничего не сделал и вижу старый css перезаливаю его пишу заказчику он говорит что ничего не работает я смотрю css опять старый и т.д.).
За "доработку" проектов уже давно не берусь. Причину вы указали совершенно правильную - для заказчика сайт психологически "готов" и поэтому бюджет крайне низок и он ожидает, что всё поправить - 5 минут, но вот времени на его доработку в рамках заложеной первым программистом концепции может уйти очень много.
Заказчику действительно нужно уделять много времени процессу разработки (а разработчику самому теребить заказчика, если тот пассивен).
P.S. Кстати, "недоработанные сайты" имхо, часто возникают из-за несогласованного заранее чёткого плана и содержания работ. В итоге, к концу проекта разработчик думает что сайт в целом готов, а работодатель только начинает смотреть "чего же там в итоге" и, совершенно естественно, образуется огромный объём работ.
Сам не раз попадал в похожие ситуации, когда заранее по каким-то причинам не было чёткого ТЗ. Собственно исполнитель тут виноват прежде всего - это разработчик должен инициировать получение детальной задачи.
Советы понравились. А недоработки постоянно будут встречаться, к сожалению
Ну что тут скажешь, плюс стопяцот
Браться стоит, но лишь с таким же подходом, как и разработка с нуля. Формулировка задач, ТЗ, бюджет, сроки.
Сначала был согласен почти со всем, что написано, потом резко нет.
Заказчик к сожалению, часто просто не готов и работа с ним может идти очень долго.
В ЧИСЛЕ ПРОЧИХ, вариант с дешевым быстро сделанным сайтом - вводит Заказчика в курс дела. Он понимает за что надо платить и сколько это стоит и стоит ли.
"Быстрячок" - это ко всему еще своего рода углубленное ТЗ. В процессе6 становится ясно что требуется и что хочется и дает ли это эффект.
Если дает, - то к эффекту привыкают (!) и уже легче соглашаются платить за что-то стоящее.
(Эффект в смысле - эффективность)
Так что не всё так просто.
Это можно сравнить с покупкой компьютера. Когда человек не может решится на хорошую дорогую вещь (не уверен что это оправдано и т.п.) и берет сначала дешевое б.у., потом, через время привыкает к нему и уже не может без него. Тогда через время с легкостью покупает стоящую машину.
Промежуточные варианты (в т.ч. и недоделки) - это этапы созревания и осмысления, и еще - осознания своих потребностей (в результате на новый проект есть уже готовое в деталях ТЗ - "вот так как здесь только то и то по-другому").
P.S.
Это не просто рассуждения, а опыт :). Именно так на практике довольно часто срабатывает схема выделения денег на профессиональный проект.
Еще один момент может быть не совсем по теме.
Если Вы - сисадмин (или IT-менеджер), то когда перед Вами стоит задача то никто не спрашивает можете или нет. Дается скудный бюджет со словами: "а вот у... тех-то так было..." и ОТКАЗАТЬСЯ... конечно можно, но это уже вам в минус (репутация IT-специалиста, который может помочь с ЛЮБЫМИ вопросами своего профиля - дорогого стоит). Поэтому приходится изголяться. Потом заказчики созревают...
Т.е. вы готовы взяться за доработку проекта с исчерпанным предыдущим исполнителем бюджета с ужасным кодом и кучей косяков в целях будущего возможного сотрудничества?
В этом плане я согласен с Али, как за новый проект со своим ТЗ списком задач сроков и своевременных оплат. + оплат всех исправляемых недостатков от предыдущего разработчика если таковые имеют место (а то что они есть так это 100%).
И тут у вас есть выбор — учить его за свой счет, либо зарабатывать деньги с другим заказчиком. О чем и статья.
PS. Хороший заказчик тот, который дважды сменил веб-разработчика
Если заказчик от предложения оплатить работу с нуля категорически отказывается, то следует посылать его на хрен, не вдаваясь в лирику, т.к. время течёт необратимо и дороже его ничего в мире нет.
согласен с
. правда дополню один тип заказчика, думаю что сталкивались. заказчик хочет реализовать маленькую по его понятиям рюшечку и говорит - но это же легко и мелочь, делается типа в пару кликов в его понимании. Но на самом деле эта рюшечка влечет за собой переделку всего сайта. Это только дополнение. а так все верно.Поправлю не его понятиям а понятиям его знакомого программиста, который по словам заказчика эту ерундистику сделал бы за пару минут, а вот ты исполнитель тут 3 часа паришься да еще и требуешь за это каких-то 20-30 уёв (в зависимости от стоимости Вашего часа) :).
на такие понятия есть один простой вопрос. который работает.
Если все так просто, почему знакомый программист УЖЕ это Вам не сделал за "пару минут"?
как правило бредни про "знакомого программиста", и "делов на пару минут/часов/(ну опционально)" много раз пройдены.
или после вопроса начинается проект или стоит просто прекратить общения с "халявщиком". - времени на перепалки уйдет больше.
его "я больше знаю" просто попытка сбить цену и потянуть время. авось оголодает кодер и согласится. не оголодает.
жалко начинающие этому принципу не следуют.
Такой вопрос. "Манифест элитности" - уместен ли он для Drupal (открытой системы с огромным сообществом)?
Мне кажется акцент этой проблемы несколько другой.
заказчика.
исполнителя.
1. Неумение слушать - "зажравшегося"
2. Неумение объяснять - "зазнавшегося"
Стоит ли на основе этих двух неумений рубить какое-то правило? (суть которого в трех словах, одно из которых - из трех букв)
Что касется того стоит или не стоит браться - здесь тоже нет правила. Все зависит от перспектив и умения их оценить. И от случая. Иногда конечно бывают ошибки. Те с кем стоило зацепиться оказались ошибочно отброшены, а те с кем зацепился отнимают время...
Но бывает и наоборот.
Иногда можно и взяться за старый сайт со скудным бюджетом, с правильными и точными объяснениями всех причин и возможных последствий.
Важно суметь объяснить и оценить - услышали тебя или нет.
Все дело в этом - в понимании на уровне общения человек-человек.
P.S.
Лет 50 назад в отвал уходил уголь который сейчас научились использовать. Т.е. проблема была не в угле а в умениях - не умениях.
Ну и в целесообразностях - времена были другие.
P.P.S
Часто слышал подобные манифесты от знакомых профи примерно такого рода - "ЦМС - для лохов и бедных" и еще недавно услышал - "PHP - быдлоязык".
И т.д. и т.п.
P.P.P.S.
Я не такой уж профи и не имею большого опыта в этом - могу и ошибаться.
IMHO всё конечно.
На самом деле "быстрячок", как вы говорите, должен быть сделан тоже качественно - иначе именно на этом этапе закладываются непомерные расходы на содержание и разработку этого сайта.
Если вести процесс разработки грамотно и использовать например модель Rational Unified Process да в полную силу, то "быстрячок" как раз и создает сам разработчик, а дальше на готове и отлаженное ядро "навешиваются" дополнительные сервисы. При этом каждый этап тщательно тестируется и в результате имеет в любой момент времени рабочий сайт.
Вывод: я за то, чтобы делать качественные сайты, а не доделывать халтуру за другими. Пердлагаемый быстрый вариант это отличный метод разработки и Друпал позволяет использовать модель RUP в полноте (благодаря модульности).
Бывает такое и довольно часто. Просто мы по разные стороны барикад. Моё мнение такое - нужно называть реальную стоимость работы и, если заказчика заинтересует разобраться в том за что там платить - попробовать в общих чертах описать. Зачем?
Лично я считаю, что заказчик имеет право знать логику работы сайта. Я стараюсь даже предложить несколько вариантов реализации - оин могут быть разными и по цене, и по трудоёмкости, и по универсальности.
Если же человек убеждён, что это пара кликов - пусть кликает!
Речь не идёт об элитности. Речь о том, что сложилась такая ситуация, что Друпал стал популярен и все кто раньше занимались Joomla и WP стали гордо именовать себя Drupal-гуру, но то, что они делают это плохо.
Они с одной стороны позорят Drupal, потому что у заказчиков складывается негативное впечатление.
С другой стороны они демпингуют чтобы ухватить заказ, но не могут его за эти деньги довести до ума и бросают.
Вот с этой проблемой я бы и хотел разобраться. Если мы перестанем за них доделывать кривую работу и общаться с обиженными ими заказчиками, а будем их отправлять за поддержкой сайта к разработчику, то я думаю, что всё станет на свои места.
Согласен с Химическим Али в смысле, что браться можно, но оговорив точное ТЗ и соответственную стоимость работы, и все равно весьма рискованно(почему - ниже).
Конечно во многих случаях заказчик уже не готов выложить необходимую сумму, тогда просто не работаем.
Из личного опыта - пару раз после выполнения ТЗ по доработке обнаруживались новые баги, связанные с работой предыдущего разработчика, а заказчик утверждает, что до ваших правок все работало. Велик риск потерять свои заработанные. Так как заранее детально оговаривал все мелочи, то удавалось убедить, что это не моя работа. Но заказчики разные и может не прокатить...
Было и такое. Для этого нужно иметь копию кода и базы на момент начала работ, чтобы можно было предъявить заказчику на анализ, но ситуация не хорошая, потому что это конфликт и в любом случае будут потери - либо заказчик должен согласиться, что он не досмотрел принимая работу, либо разработчик, что он это исправит бесплатно.
Поэтому проще не браться - мало ли там ещё мин разбросано...
Я полностью не согласен с Владом.
Отфутболивать заказчиков нельзя ни в коем случае.
С заказчиками нужно поддерживать легкие и приятные отношения.
Даже если я занять по горло и не могу в данный момен заняться другим проектом, то я говорю "Сделаем, но по позже." Если заказчик согласен ждать то будет работа, если нет, то у него отстанется приятное впечатление от вас.
Это первое.
Теперь по поводу "метлы".
Я так полагаю, что настоящего специалиста будет очень мало волновать качество кода, который ему предлагают. Любой код можно либо "допилить", либо переписать. Вопрос времени.
Сложнее всего здесь оценить именно время, но как только вы сможете оценить время, то сразу же можете назвать сумму. В таком случае, заказчик говорит либо "да", либо "нет", и все.
В чем проблема то?
Если Вы говорите "принципиально не нужно дорабатывать чужие проекты" - это чушь.
В итоге страдает ни в чем не повинный заказчик. А с заказчиками нужно поддерживать хорошие, деловые отношения.
тут был комментарий
Причина отказа именно в этом, ведь для адекватной оценки времени на доработку - нужно потратить не пять минут своего времени и не просто "глянуть", а провести чуть ли не реверсивный анализ, чтобы понять чего и как будет. При этом опыт подсказывает, что в большинстве случаев бюджет на доработку очень невелик и чаще всего сжат по срокам. Так может проще "проходить мимо", чем тратить время и силы на анализ, а потом в 90% случаев всё равно не работать над заказом?
Другой вопрос если заказчик постоянный и вы уже хорошо можете оценить его запросы.
Дело вовсе не в принципиальности дорабатывать или нет, я к примеру привык оставлять за собой такой код, который сможет понять любой кодер мало мальски разбирающийся в API друпала все чисто и прозрачно
да может я не пишу модули за 15 минут, может я слишком скурпулезно отношусь к хардкоду в page.tpl.php и т.д, может я слишком придирчив к тому что иногда попадается на доработку и реально проще переписать все с нуля (уйдет реально меньше времени) чем разргебать мусор и дебри оставшиеся от предыдущего исполнителя. В жизни бывают разные ситуации тащил человек проект потом что-то случилось так оставь после себя "чистое убранное рабочее место" в хорошем смысле этого слова, а то счас начнется снести свой код и т.д. А дорабатывать за непрофессионалами, а большинство недоработок именно они это уж извините, нехочу, небуду, нежелаю.
Из личного счас дорабатываю проект который реально было приятно разворачивать у себя на локали ни одного бока, чистый и грамотный код, нормальный адекватный прямой заказчик а не посредник (как это тоже частенько бывает). Тем более каждый из нас видит что написано дилетантом буквально с первых строчек кода.
И насколько я понимаю Влад именно против этого и я его в этом отношении полностью поддерживаю.
А с заказчиками нужно поддерживать именно "хорошие, деловые отношения".
Репутация репутацией, а нервы тоже надо беречь.
Довольно часто встречаются: «Сделать то-то, то-то и еще там подправит, ну для знающих там работы на 20 мин». Такое я обхожу сразу. Если чел решил что там работы на 20 мни, так пускай сам эти 20 минут и тратит. Хотя тут-же появляется вопрос: как он определили что там работы только на 20 мин.
Да, есть и такие заказчики, которые уверенны что их проект почти завершен и просят доработать и, естественно, денег платить не хотят много, так как первому недоработчику уже много уплачено.
Правильно сказал Химический Али про подход к доработкам, иначе будет себе дороже.
Реально, это никогда не получится. В отдельных случаях да. А так, только при отсеивании заказчиков. Хорошие и деловые - согласен.
Если красивый (грамотно написанный) код дороже заказчика то возникает пустоты в схеме "спрос-предложение", которые заполняются "учащимися" (ну и пусть - да?) и специалистами по IT-маркетингу.
Вывод: за ТЗ на блюдечке с голубой каемочкой тоже прийдется платить.
Клиентов которые знают что хотят не так уж и много...
Я не знаю как Вам, но мне к примеру брать проект который прошел через 5-6 исполнителей и представляет из себя полную помойку просто не приятно брать в руки, равно как и есть из грязной посуды, а если еще при этом бюджет данного действа 100 рублей (цифра названа образно) то и подавно. Да я готов помыть посуду и убрать за предыдущими, но этот труд должен быть оплачен соответствующим образом, но повторюсь лучшая уборка после бурной вечеринки, это сгрести все в кучу, выкинуть вон и как говорится с чистого листа.
Это реально жалко, я конечно понимаю стремление заработать, но извините всему надо учится и учится не на реальных заказчиках, а точнее сказать не хапать то что не под силу и по несколько штук, а то аж тошнит иногда "Мы молодая, перспективно развивающаяся команда". В реалии они только гвозди научился забивать а уже кричат о том что готовы делать мебель евростандарта а простые табуретки это удел "ламеров", хотя сами таковыми и являются не в обиду читающим эти посты новичкам будет сказано.
+1
Работать желательно только с адекватными заказчиками, а с неадекватными не работать. Вопрос как их быстро различать между собой. )
Недоделанный проект, зачастую, признак проблемного заказчика.
Несколько раз встречал заказчиков, которые адекватно не могут сформулировать своё видение проблемы/задачи. Приходиться буквально вытягивать из них их желания и состовлять ТЗ. Думаю, если разработчик взявшись за работу не закончил её, то это полностью вина заказчика. Как минимум, потому, что проявлял интереса к заказу, как таковой. Мошеники обычно не бросают дело на полпути
Они обычно её вообще не делают. 
Да, вспоминаю такой один: случай когда начал разрабатывать сайт а знакомый программист сказал заказчику что на ucoz сайты за 2 часа делаются. Вот до сих пор знакомый программист его на ucoz и делает. Главное обижает что потрачено много времени на переговоры по утверждению дизайна и так далее нет чтоб сразу заказчик сказал что у него есть "знакомый программист". Сразу вспоминается надпись при входе в сервисный центр Samsung - "Вход с мороженным, собаками и знакомыми программистами ЗАПРЕЩЕН"
Использование поэтапной оплаты снижает риски и разработчика, и заказчика.
Только расписывать все этапы и делать новое ТЗ бесплатно не всегда хочется
Если это работа, то она должна быть оплачена - включите в стоимость.
попадал в такие ситуации в качестве заказчика
CMS, CMF - это, в первую очередь, набор стандартов. И нужны эти стандарты именно для того один мог подхватить то, что уронил другой.
В этом основная идея!