Поиск исполнителей
3240 сообщений
#16 лет назад
Цитата ("stanma"):Спасибо за отзыв!
Предлагаю соединить усилия и сделать эту статью - будет замечательно, как на меня.
Развитие темы, поднятой в статье "10 уловок заказчика, чтобы платить Вам меньше".
Недавно в блоге Станислава Малкина ( ссылка ) наткнулся на неплохую статью "10 уловок заказчиков, чтобы платить Вам меньше" ( ссылка ).
С автором согласен, особенно с первыми пунктами. Также хотелось бы продолжить тему, и добавить еще несколько подобных уловок.
11. "Я вам предлагаю не мелочевку, а большой проект. Поэтому ожидаю, что вы мне сделаете скидку в цене".
Мало того, что понятие "большой проект" у каждого свое, так заказчики часто почему-то думают, что разработчики просто обязаны дать ему "оптовую скидку" на по его мнению крупный заказ. И что прискорбно, часто разработчики, увидев (возможно, впервые в жизни) четырехзначные суммы, соглашаются на это...
Ну что тут сказать... Опт - это если был бы большой проект, состоящий из почти одинаковых маленьких проектиков. Например сделать 10000 баннеров - тут опт уместен, так как разработчикам можно минимизировать свои временные затраты на однотипной работе.
Но если есть "монолитный" большой проект, например на 4-5 тыс. человеко-часов, то часто бывает наоборот. Потому что:
1. Чем крупнее проект, тем больше в нем рисков, заказчик это понимает и идет навстречу.
2. На большом проекте обычно больше затраты на менеджмент и синхронизацию работ.
3. Новичок большой проект не сделает, поэтому нужно чтобы команда в таком проекте состояла как минимум наполовину из матерых профессионалов. А опытные спецы обычно очень дорогие.
4. Нормальный адекватный заказчик обычно соглашается оплатить большой объем работ по дополнительным таскам, таким как QA, QC и Technical Writing, ведь он понимает, что в его интересах чтобы к проекту подключались дополнительные люди или целые команды.
12. "Вычеркните из сметы QA. Мы вас нанимаем, потому что вы - лучшие профессионалы, которые пишут код без дефектов".
Это бывает, когда заказчик хочет экономить, урезать бюджет. Перед этим он обычно пишет что-то типа: "Обоснуйте Вашу цену. Распишите пожалуйста очень подробно, из чего состоит Ваше предложение цены, по пунктам". Пока что все нормально, это заказчика можно понять что он хочет знать за что он платит.
Но вот потом начинается: "Вычеркните QA", вычеркните "Написание документации по проекту", вычеркните то, вычеркните се. А потом при приемке проекта это все равно всплывает. В том числе это касается тех же найденных позже дефектов в проекте, которые фиксить придется бесплатно... Обычно это касается времени на дополнительные расходы, не связанные непосредственно с разработкой.
Многие команды, особенно молодые, соглашаются, и затем получается, что команда тратит огромное количество человеко-часов бесплатно.
13. "Мы и так платим вам за разработку по дикому рейту. Вычеркните из сметы время на менеджмент и на синхронизацию работ, это ваши расходы".
Могут и какие-то значащие пункты вырезать. Например время на деплоймент на сервере заказчика, пример аргумента: "Это же минутное дело установить OsCommerce!". Хотя реально тут может занять огромную массу времени например война с админами хостинга, установка всего с нуля на выделенный сервер, разбираться почему не работает отсылка почты, почему MySQL не понимает кириллицу и т.д.
Также такой заказчик может вычеркнуть из сметы время на переговоры по проекту, время на менеджмент, синхронизацию работ с другими командами, написание документации... Проблема тут в том, что заказчик думает, что все эти расходы входят в рейт разработчиков. При этом, например, такой заказчик может абсолютно бесплатно отжирать на общение ежедневно до 3-4 часов времени у менеджера команды разработчиков (который обычно - один из самых дорогих специалистов в команде).
14. "Хоть ваш рейт и высокий для Украины, но я готов платить профессионалам за хорошую работу! Только смету пересмотрите, что это вы тут написали 'подсистема авторизации на сайте - 4 часа', да я сам форму логина за 20 минут напишу".
Еще говорят: "Вы что, первый день работаете? У вас что, нет наработок для такой-то типовой функциональности?". Для достижения пущего эффекта обычно перед этим такой заказчик довольно долго восхищается профессиональными качествами исполнителей, портфолио, и т.д. При этом заказчик явно давит на самомнение, что как это так, мастер и "так долго" будет выполнять такую-то элементарную задачу, якобы студент сделает быстрее.
Конечно, при этом заказчик не учитывает (или делает вид что не учитывает) большой массы деталей, специфичности проекта, условий, технических требований, и т.д. А разработчик часто в порыве разговора может и упустить что-то по проекту, что обдумывал до этого делая смету, и дать себя уговорить снизить цифру по данному пункту.
15. "Мне нужно 5 вариантов дизайна, я выберу лучший, и заплачу за него".
С первого взгляда, заказчика можно понять, зачем же ему оплачивать неудачные варианты, или просто халтуру. И некоторые наивные разработчики соглашаются, идут на это, а потом удивляются, почему они потратили целую неделю, а заработали только 100 USD за один из вариантов.
Тут же нужно учитывать, что разработка нескольких вариантов заказа также требует трудозатрат, и сразу нужно заказчику об этом говорить, включать это время в стоимость.
16. "Это что за дефект? А это что? А вот это решение в коде вообще не выдерживает никакой критики! Поэтому, исправьте дефекты и проведите рефакторинг за ваш счет, а заодно, добавьте то, то и это".
Такое часто бывает, когда заказчик предлагает сделать какие-то хотелки, а разработчики выдвигают ему счет на них. Заказчик при этом специально находит в коде или технических решениях какие-то проблемы, и начинает давить на команду по этому поводу изо всей силы, в то же время намекая и подталкивая сделать ему эти хотелки бесплатно.
Например, можно минут 10 давить на психику по поводу ламерства в коде, потом намекнуть про свою хотелку. Затем еще минут 10 давления, и опять тонкий намек про хотелку, ведь ее добавить так просто для хорошего спеца, занимает так мало времени... Программист через несколько таких итераций часто сам предлагает заказчику сделать эти хотелки бесплатно. Практическая психология в действии.
Такое может случиться через какое-то время после начала разработки у молодых команд. При этом обычно код действительно не идеальный, и его действительно хорошо бы улучшать. Но это не повод дать волю чувству вины, и соглашаться сделать заказчику бесплатно еще целый ряд работ по проекту.
При таком положении дел правильный подход - твердо и однозначно предлагать заказчику отделять мух от котлет, и решать проблемы отдельно, а обсуждать новые changes к проекту - отдельно.
230 сообщений
- сколько таких халявщиков я мимо себя пропустил 