«Плохой разработчик» vs. «Недовольный заказчик»

Заказчики → «Плохой разработчик» vs. «Недовольный заказчик»

Заказчик обиженный ранее не профессиональным и\или низкобюджетным разработчиком сравни человеку после болезненного расставания – обижен, недоверчив к новым компаниям и долго выстраивает доверительные отношения с новой командой.

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

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

Единственное что приходит в голову это сказать – не пинайте пианиста он играет как умеет :-) но речь не об отвратительном музицировании, а о потерянных деньгах… и специально вставляемых палках в колеса своим недавним клиентам.

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

Есть  разработчики которые сначала демпингуют, и льют мед в уши – берутся сделать «все то же самое, но гораздо дешевле», а потом получая деньги и разумеется не справляясь с задачей – начинают увлекательный процесс общения и палковтыкательства тем кто за них переделывает то, с чем они не справились.
 
Поскольку нам довольно часто приходится полностью переделывать даже достаточно свежие проекты (проекты не отпраздновавшие годовщину создания, а то и не дошедшие до релиза :-) ) делимся  самыми популярными проблемами и «козлениями» со стороны предыдущих разработчиков с которыми сталкивались наши новоиспеченные клиенты.

Основные палки в колеса:

• клиенту не отдаются права на домен;
• клиенту не даются реквизиты хостинга;
• абслютно весь код проекта шифруют Zend Guard’ом;
• полное отсутствие документирования разработки;
• реализация проекта силами фрилансеров;  

Проблема №1 –  клиенту не отдаются права на домен

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

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

Проблема №2 –  клиенту не даются реквизиты хостинга :

Хостинг и база – да бог с ними все равно 99% случаев приходится его менять под нормальный ресурсоемкий тариф или даже выделенный сервер, но часто нужно забирать контент из БД т.к. он остается на 90% одним и тем же.

Если проблема не решается – клиент платит за ручной перенос информации, написание парсеров выдирающих эти данные и т.п.

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

Проблема №3 – абсолютно весь код проекта шифруют Zend Guard’ом

Zend Guard… как много в этом слове гордого, особенно в срезе прямого назначения этого обфускатора и хэшировщика. По идее Zend предназначен для защиты интересов интеллектуальной собственности разработчика.  Но в свете «козления» неумелого разработчика, то, что кодируется  интеллектуальной собственностью назвать сложно, такое стыдно публично показывать не то, что права собственности на такое отстаивать.

Вообще крайне странно видеть такое поведение от компаний пишущих на open source языках и изначально декларируя клиенту кастомную разработку.

Что получает клиент? 

• Не редактируемый и чаще всего еще и не работающий как надо код;
• невозможность исправлять корявости силами других разработчиков;
• невозможность безболезненно привлекать других разработчиков для смежных работ – seo например;

В нашей практике seo-продвижения одного зазенденного проекта всплыло,  что он  не имел инструментария управления метатегами, не соблюдалась целостность БД  и юрлы одних и тех же страниц постоянно менялись –  это называется родили нежизнеспособную зверюшку и за это еще и деньги с клиента получили….

Теги внешним софтом были нами забороты на уровне подмены, а вот уродство неработающего кода лечить без исходников не возможно.   

Ответ полученный от разработчиков меня просто ошеломил – код зазенден для сохранения гарантии :-)))))) Гарантии чего? Того что сайт работает через ж***у ? Дак для этого и зендить не надо. Исправлять сформулированные нами грубейшие ошибки – отказались.

В кастомной разработке на open source языках обфускация и хэширование кода – дурной тон.

Когда я слышу о защите «подобных» технологий мне смешно – это тоже самое если бы автоВАЗ  защищал технологии применяемые в ржавой копейке от инженеров BMW…

Проблема №4 –  полное отсутствие документирования разработки

Отсутствие программного документирования кода это показатель уровня разработчика.

Тут все прозрачно… бюджета хватило на 1,5 инвалида, который в лучшем случае взял open source коробку и прикрутил как умеет, в худшем взял свой «лисапед» и прикрутил его.

Про такие вещи как SVN, версии, ревизии и т.д я даже не говорю – они и близко не используются.

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

Самый популярный итог – не масштабируемый проект жизнеспособное функционирование, поддержка и эксплуатация  которого, будет, сравни содержанию двадцатилетнего, постоянно ломающегося, иностранного автомобиля.
 

Проблема №5 – реализация проекта силами фрилансеров

Тут все просто – фрилансеры для студии из 2-3 менеджеров сделали работу, и пропали.
Далее начинается багфиксинг, доработки, а доделывать некому…

А учтивые 2-3 менеджера встречавшие клиента в офисе ранее и обещавшие ему за пару K$ всё на свете, срывают все сроки, не делают что нужно, и более того с вероятностью 99% клиент плавно перетекает в сценарий проблемы №4 :-)

Это разумеется не все проблемы, но эти наиболее распространенные.

Основная причина всех вышеописанных болячек кроется в непрозрачности структуры продукта и вообще процесса разработки для Заказчика (сайтом называют всё и вся , что выкладывают на хостинги, а php-программистом заявляет себя любой мало покопавшийся с какой-нибудь cms прыщ ), но тут как и с любым кастомным продуктом мерило только одно – опыт, сама команда, и разумеется профессиональное success story.

Хотя если клиентом используется подход сопоставления сметных оценок ТЗ по критерию ИТОГО, а не тому как эти цифры декомпозированы и что они в себя включают – то такой клиент становится нашим потенциальным тогда, когда получит первый «приятный» опыт неоправданных ожиданий :-))). 
 

nadeyev

Вернуться к списку постов