Как программисты обманывают неопытных покупателей, рассказывает 17 летний Владимир
Незнание этапов разработки и скрытых подводных камней может обернуться для клиента фатальной ошибкой уже в самом начале проекта. Ниже я расскажу, на что стоит обратить внимание при работе с программистами, чтобы избежать обмана и лишних расходов:
1. Старт:
Вы обратились и попросили написать сайт, вам дали стоимость в ответ на составленное тех задание, прошел 1 месяц и ваш сайт готов, вы начинаете проверять и понимаете что во многом это не то что вы хотели видеть.
И тут вопрос, что же делать?
Обычно — если вы уже столкнулись с этой проблемой, то либо давить, либо искать рычаги давления, указывая на свою правоту в ситуации.
Как я это решаю заранее?
Присылаю тех заданию и говорю что + 25% поверх него я могу вносить доработок, изначально программист не понимает для чего это и думает ну наверно если что то он забыл то добавим ( На самом деле — вы просто умнее и знаете что может случится когда проект будет сдан )
2. На что стоит обратить внимание и как происходит основной обман
Представим ситуацию:
Вы заказали разработку платежной системы, указали в тех задании ''Добавить платежную систему Trenbolon'', вам дали стоимость 50$ и началась разработка, через неделю вам сдали задачу в которой подключена платежная система в методе покупки товара но не подключена в методе пополнения баланса.
Программист раздвинет руками и скажет — Подключена там где я говорил, вы зададите вопрос ''Где я говорил что только там нужно?'' а он ответит:
Я уточнял ведь, платежная система при покупке верно?
Вы сказали да.
Опытные программисты любят уточнять, причем уточняют в свою пользу ( Они создают вопрос с уточняющим подтекстом в котором по итогу оказывается манипуляция оставляющая вас без возможности выбора )
И тут вопрос, что же делать?
Обычно — если вы уже столкнулись с этой проблемой, то либо давить, либо искать рычаги давления, указывая на свою правоту в ситуации.
Тут происходит серьезный расход мнений, следственно начинаются ссора и либо вы договариваетесь, либо теряете неделю впустую.
Как я это решаю заранее?
Я четко слежу за манерой диалога и если вижу что мной начинают манипулировать — начинаю сильно разбирать свое тех задание вплоть до мелочей
Уточняешь — получай все до мелочей!
Советы по работе с программистами из моего личного опыта:
- Про фиксацию договорённостей — совет закреплять все правки и пожелания письменно, чтобы в конце не было споров «а вы же говорили что только так».
- Про прототип — перед стартом стоит согласовать прототип или дизайн-макет, чтобы у программиста была чёткая визуальная опора, а не только текст ТЗ.
- Безопасность — сразу оставляйте пожелания что сайт должен быть защищен и закрыт от взлома в любом виде (если это DDOS то не стоит прописывать так как это определяется по факту во время проблемы, лишь можно подготовить минимальную защиту от DDOS)
- Манера общения — чувствуете что человек агрессивный - сразу забывайте его контакт, эмоциональный программист способен на очень многое, вы даже не представляете насколько.
- Запрос на документацию — просить, чтобы разработчик оставлял инструкции по работе с сайтом и комментировал код. Это спасает, если потом придётся передавать проект другому специалисту.
- Тестирование сторонними людьми — иногда заказчик привыкает к багам и не замечает их. Дать протестировать сайт человеку «со стороны» помогает выявить проблемы, которые вы упустили.
- Чёткие критерии готовности — заранее определить, что считается «сданным проектом», чтобы программист не мог заявить, что «всё готово», когда на самом деле половина функций не работает.Не платить всю сумму заранее — когда программист получает полный расчёт до завершения проекта, у него резко падает мотивация доводить работу до идеала. Возникает соблазн «сдать как есть» и исчезнуть. Разбивайте оплату на этапы: предоплата, промежуточные платежи за конкретные готовые функции, финальный расчёт — только после того, как вы убедились, что всё работает как надо. Это дисциплинирует обе стороны и упрощает решение спорных вопросов.
- Вести проект в GitHub или другой системе контроля версий— это ваша страховка. Если программист пропадёт, испортит код или начнёт что-то менять без вашего ведома, у вас всегда будет сохранённая версия проекта, к которой можно вернуться. Плюс, GitHub позволяет видеть всю историю изменений и понимать, что именно и когда было сделано. Это особенно важно при работе с несколькими разработчиками — исключает путаницу и потерю данных.
- Проверяйте скорость и доступность сайта — даже красивый и функциональный сайт теряет смысл, если он грузится медленно. Перед сдачей проекта прогоните его через PageSpeed Insightsот Google. Это покажет, насколько быстро сайт загружается на разных устройствах, и подскажет, что можно оптимизировать. Высокая скорость важна не только для удобства пользователей, но и для SEO — медленные сайты хуже ранжируются в поиске.
Важно говорить + 25,50% к тех заданию, чтобы потом можно было бесплатно добивать проект задачами и получить итоговый — результат мечты
Всем спасибо если вы прочли это до конца.