Прошу оценить статью...
В Интернете очень популярны статьи вроде: "10 случаев, когда я говорю «нет»", "5 полезных советов фрилансеру" и т. п. Я решил тоже не отставать и написать свои 10 вредных советов фрилансеру. Почему вредных? Конечно, да, выше названные статьи весьма неплохо повышают уровень самооценки фрилансера, но это вовсе не значит, что они повышают степень его успешности. Могу сказать однозначно, что они уменьшают его шансны получить работу на современном рынке с нынешней жесткой конкуренцией, а значит и снижают количество и частоту задач, решаемых фрилансером, а зачастую это приводит к застою - ведь только в работе человек может поддерживать и наращивать свой уровень профессионализма. И наоборот, отказав одному, второму, третьему фирлансер сидит ждет свою "крупную рыбу", но в итоге теряет навык работы.
Именно поэтому я свои советы где-то считаю вредными, сам их никогда не придерживался, однако, это нередко приводило меня к различного рода конфликтным ситуациям. Поэтому решать вам самим, принимать рынок с его работодателями таким, как есть и, возможно, адаптироваться к нему, либо же сберечь свои нервы и переориентироваться на какие-либо другие направления. Я выбрал второе. Веб-программирование и сайтостроение на заказ я решил считать легкой халтурой в свободное время, которую я не намерен больше искать специально. Пускай работа сама ищет меня. "Была бы шея, а хомут найдется!"
И вот исходя из выше изложенных соображений, я и хочу дать 10 советов, по сути, 10 видов проанализированных совершаемых мною ошибок, неких 10 правил, которых отныне я и сам старатюсь всячески придерживаться. Но для тех, кто собирается и дальше всякими правдами-неправдами, унижаясь и пресмыкаясь, выхватывать работу на фрилансе и выполнять ее в запарках, работая без сна и отдыха за миску похлебки я не рекомендую читать мои советы - они им окажутся несомненно вредными.
Совет 1. "Я тут вкратце набросал". Очень редко (практичеки никогда) на фрилансе встретишь проекты, в которых сразу же можно загузить для ознакомления детальное гармотно составленное техническое задание. Самое печальное тут, что даже при первом контакте с работодателем, когда просишь его предоставить подробное ТЗ, чаще всего нарываешься на ответ: "я тут в кратце наборосал" или "давайте я вам в аське все изложу". Итак, первый, и, возможно, самый главный совет: Никогда не беритесь делать работу до тех пор, пока вам не будет предоставлено грамотное подбробное ТЗ!
Почему я так категоричен? Богатый личный опыт. К сожалению, работодатели не понимают (или наоборот понимают), что ТЗ - это не просто доступное пониманию исполнителя указание, что необходимо сделать, но это прежде всего документ регламентирующий объем работ. ТЗ и только ТЗ может служить критерием оценки того, что работа была завершена и выполнена качественно, т. е. соответсвует требованиям технического задания. Чем же мы рискуем, принимаясь за работу без согласованного ТЗ? Перечислю несколько пунктов риска, с которым я сам непосредственно сталкивался.
Риск 1. "Еще чуть-чуть". Эта ловушка мне встречалась чаще всего, поэтому я склонен думать, что многие заказчики специально избегают составления правильного ТЗ. Происходит так, вы задачу поняли в общих чертах и приступили к работе, когда выполнили около 90% работы, вы начинаете предъявлять заказчику свой результат. Тут мне вспомнилась шутка, которую я вычитал в одной из статей, посвященных созданию технического задания: "90% времени занимает создание 90% проекта, оставшиеся 10% проекта занимают другие 90% времени"
Именно так, после того, как вы показали заказчику результат работы, приближающейся на ваш взгляд к завершению, тут-то как раз и начинается самая большая работа. Закачик сразу же вспоминает о нескольких дополнениях, которые он сразу почему-то забыл сказать, а потом вот этот кусок работы он вообще представлял не так и просит вас его переделать по-другому. Потом еще чуть-чуть переделать, а потом еще чуть-чуть доделать и так до бесконечности. Хорошо еще, если при этом оплата увеличивается хоть немного и на вас не начинают давить по срокам, угрожая наоборот оплату урезать.
Риск 2. "Разве я это просил сделать?" Эта ситуаия возникает как от банального непонимания задачи, так и опять же от несерьезности заказчика, который преднамеренно умолчал некоторые особо сложные аспекты проекта, но об этом мы поговорим в третьем пункте. Не правильно же понятая задача чаще всего выливается в недовольство заказчика результатом вашей работы, после чего либо вам прийдется все переделывать заново, либо заказчик просто откажется от вашей работы, не заплатив ни копейки. Так иногда месяцы работы летят на смарку.
Риск 3. "Сколько можно делать?" и "Какая еще доплата?" На этот вид граблей ваш покорный слуга наступал неоднократно и, думаю, что в некоторых из случаев заказчик не без умысла скрыл некие сложные аспекты своего проекта, ограничившись коротким описанием, с целью выдать сложную задачу за простую, чтобы на этапе согласования цены повлиять на стоимость работ, значительно занизив ее. Потом, когда вы дочитываетесь до пунктов, недостаточно детализированных, начинаете уточнять, оказывается, что работать вам прийдется без выходных. Например, за фразой "лента новостей" может скрываться полнофункциональный блог с комментированием, категориями, регистрацией пользователей и так далее, а за словом "календарь" может прятаться полнофункциональный планировщик задач с установкой сложных расписаний и сервисом напоминания. В итоге, вы будете пыхтеть над этой работой в три раза дольше обещанного срока, заказчик будет давить на вас за срыв сроков, а на все разговоры о повышении оплаты он тут же будет вспоминать о деловой этике, мол, не хорошо менять назначенную цену задним числом.
Совет 2. "Назовите цену и сроки". Первый совет я не зря назвал одним из главных, так как все остальные весьма близко перекликаются с ним. Часто заказчик, не дав четкого ТЗ и едва обрисовав задачу в двух словах, немедленно требует назвать цену и сроки выполнения работы. Никогда не называйте цены и сроков, не ознакомившись с детальным подробным ТЗ. Чем чревато нарушение этой заповеди не сложно догадаться, вы можете представить себе задачу по-одному, а заказчик будет представлять ее совсем по-иному. Как правило, в ТЗ, если вы его все же потом получите, окажется проект раза в два-три объемнее, чем вы себе представляли.
Совет 3. "Сделайте, как тут". Иногда может показаться, что образец в виде готового сайта куда нагляднее любого самого подробного технического задания, однако, это ощущение несколько обманчиво. Во-первых, для того, чтобы выяснить некоторые детали, вам надо будет потратить уйму времени на изучение сайта-образца, а во-вторых, вы ведь сможете увидеть только его внешнюю сторону, а о том, как устроен сайт изнутри, как выглядит его админ-панель, по каким алгоритмам работает - этого вы скорее всего узнать не сможете. Итак, мой совет: Не позволяйте заказчику ТЗ заменять сайтом-образцом. Хотя ссылки на такие сайты могут быть хорошим дополнением к ТЗ.
Совет 4. "Предоплата". Любой сложный проект занимает у разработчика массу времени и труда, а любой труд должен быть по достоинству оплачен. Если вы беретесь за работу без предоплаты, вы даете возможность заказчику в любой момент времени передумать. Хуже всего, когда заказчик передумывает только в самом конце, когда заказ уже готов на 99%. Такой случай совсем недавно произошел со мной, мне с трудом удалось добиться от заказчика оплаты неустойки в размере 50%. Так вот: Всегда берите с заказчика предоплату в размере 30-50%. Это избавит вас от таких несерьезных работодатлей, которые не смогли сами определиться нужна им ваша работа или не нужна. По-крайней мере неустойку за отказ вы уже будете иметь в кармане на всякий случай. Так же это повысит ваш вес при решении спорных вопросов, например, на счет не указанных в ТЗ доработок и переделок. Не буду выделять жирным и другой совет: не берите предоплату 100% и, тем более, не тратьте полученные наперед деньги. Поскольку предвкушение оплаты за работу дает некий психологический стимул для работы. Наоборот, когда деньги уже получены и давно потрачены, выполнять потом такую работу очень не хочется, но если вы порядочный человек, то надо обязательно. Именно из-за этого "надо" всегда обычно и не хочется. Хотя, возможно, это личное - терпеть не могу работать "из под кнута".
Совет 5. "Да там работы на полчаса". Совсем недавно ко мне в аську стукнул один, ТЗ не предоставил, сказал "сделай, как тут", потом потребовал по-скорее назвать цену и сроки, еще заявил, что ему знакомый программист сказал, что там работы на полчаса, а потом еще и нахамил перед тем, как попасть в игнор-лист, чем подтвердил правильность моего отказа. Человек нарушил все ранее озвученные принципы, следующим шагом была бы неоплата, наверняка. Но оставим в покое упоянутого товарисча, бог ему судья. Просто вспомнилось именно потому, что в его исполнении прозвучала ключевая фраза: "работы на полчаса", т. е. человек заведомо считает, что это работа простая и дешевая, хотя сам в этом не разбирается, но якобы подкрепляет слова мнением некоего знакомого специалиста в этой области. Возникает резонный вопрос, почему не дал возможности заработать легких денег (работа ведь простая) своему знакомому, а ищет заказчика на стороне? Ответ прост, либо оплата заведомо не соответствует сложности, либо и вовсе нет никакого знакомого программиста. Человек явно хочет сбить цену и, поэтому получает отказ. Никогда не беритесь за работу, если заказчик заведомо сбивает цену.
Совет 6. "Может можно быстрее?" Иногда бывает, что заказчик хочет, чтобы вы сократили срок разработки. Возможно, вам хочется работать по ночам и без выходных, тогда соглашайтесь. Я же предпочитаю всегда называть срок в 1.2-1.5 раза больше расчетного, так как всегда могут возникнуть непредвиденные обстоятельства. Я считаю, лучше приянто удивить заказчика, сделав работу досрочно, чем огорчить его срывом сроков. Никогда не соглашайтесь на сокращение сроков. Иногда для разработчика сроки очень принципиальны, например, он сам взял работу, которую не успевает сдать в срок, поэтому решил спихнуть ее на вас. Возможно вы молоды и здоровы, а денег хочется заработать очень, поэтому вы готовы согласиться в расчете, что справитесь, пожертвовав сном и отдыхом. Поверьте, молодость и здоровье быстро и незаметно пройдут, если вы будете все время вкалывать за копейки, особенно, если при этом вы еще и не впишетесь в сроки, а заказчик будет вам каждый день портить нервы своим настойчивым "когда наконец?"
Совет 7. "Может можно дешевле?" Хорошо, сегодня вы уступите вашему заказчику. Вопрос, уступят ли вам завтра, когда вам надо будет платить по счетам за электричество, за Интернет, за телефон, за коммунальные услуги? Сделают ли вам скидку в транспорте или в магазине? Может быть в ресторане для вас установят льготные цены?
Скажете, как-то все это жестко и по-жлобски звучит? Мол, сегодня вы помогли, а завтра вас не оставят в беде? Может быть, может быть в этом мире и есть немного места милосердию и благотворительности, однако, альтруизм хорош до тех пор, пока он творится от излишка. Я все думал, как бы по-мягче сформулировать седьмой совет и решил так: Не снимайте с себя последнюю рубаху.
Вообще, я считаю, что правильно расчитанная цена не может быть жлобской, поэтому в ней практически нет места для скидки, а расчитывается эта цена приблизительно так: вы определяете сроки выполнения работы и с учетом своих потребностей определяете стоимость своего дня/часа работы, умножаете одно на другое и получаете требуемую сумму. Это мой метод, но я встречал где-то на форумах, что так делают многие. Как же правильно определить срок выполнения работы и определить стоимость своего часа работы?
О сроках я уже писал выше. Конечно, это приходит с опытом, когда вы уже можете приблизительно судить сколько времени у вас займет та или иная работа, главное тут быть внимательным, дочитываться до каждой мелкой детали в ТЗ, которое вне всяких сомнений должно присутствовать.
Что же касается часа работы, эта вещь достаточно субъективна. Можно, конечно, ориентироваться на существующую на рынке труда ситуацию, например, на сайтах по трудоустройству просмотреть объявления о вакансиях на должность веб-программиста или той профессии, представителем которой вы являетесь, вычислить среднюю зарплату, которая там предлагается. Надо не забывать, что зачастую там пишут зарплату на испытательный срок, поэтому полученную сумму можно увеличить раза в полтора, потом разделить на 20 рабочих дней и на 8 часов. Это один метод, которым я, кстати, до сих пор не пользовался, но сейчас я сделаю экспримент. Я проверю этим методом уровень своей самооценки
Именно по субъективной самооценке и подсчету своих основных потребностей я назначил цену за свои услуги в размере 4 доллара в час (у меня реально скромные запросы). Теперь идем на сайт rabota.ua и в поиске выбираем раздел "Веб-мастера, веб-дизайнеры, техписатели", смотрим... гммм, 3 вакансии и во всех зарплата не указана. Ладно, идем на weblancer.net в раздел вакансии и смотрим там: Программист на постоянную удаленную работу - 500 у. е., Ищем профессионального PHP-программиста - 1000 у. е., Разработчик сайтов под ключ - 5000 у. е., Web-программист - 1000 у. е., Требуются программисты из Санкт-Петербурга - 1000 у. е., Программист PHP MySQL AJAX - 2500 у. е. Думаю, достаточно. Расброс, конечно, приличный. Признаюсь, я отсек варианты 100 у. е. и 10 000 у. е. - это предложения от людей, живущих где-то не на этой планете
Итак, суммируем: 500 + 1000 + 5000 + 1000 + 1000 + 2500 = 11 000. Делим: 11 000 / 6 = 1833. Умножаем на 1.5 с учетом испытательного срока и получаем 2750 у. е. Делим на 20 рабочих дней и на 8 часов, результат: приблизительно 17 баксов. Да, я явно свои запросы слишком уж ужимаю. С сегодняшнего дня, мои услуги будут стоить 5 баксов в час
Совет 8. "Любой дурак разберется". Бывают случаи, когда вам предлагают сделать работу, в которой на данный момент вы не компетентны, а вы как человек здравый отвечаете отказом, поскольку не знаете сколько времени вам понадобиться на то чтобы разобраться и не можете сказать, уложитесь ли вы предъявляемые требования по срокам. Не редко у меня бывало так, когда меня все-таки убеждали зачем-то, что работа проста, мол, любой дурак разберется. Потом получалось так, что я не справлялся и в намеченный срок не укладывался. Сейчас я уже давно перестал брать заказы на авось разберусь как-нибудь. Стараюсь брать только ту работу, которую знаю четко, как делать и сколько времени понадобится для выполнения данной работы. Бывают исключения, когда, не смотря на мои предупреждения, что я с какой-то частью работы на данный момент не знаком, заказчик все же соглашается и предоставляет не слишком жесткие по срокам условия. Как раз такие варианты я очень даже приветствую - лишняя возможность изучить что-нибудь новое и получить еще и деньги за это. Вобщем, так: Старайтесь избегать браться за незнакомую вам работу в сжатые сроки.
Совет 9. "Тут только чуть-чуть подправить". Этот совет в принципе похож на пятый, но он чуть менее экстремален и акцент немного на другом. Зачастую заказчик, обманываясь незначительностью внешних исправлений, составляет себе не правильное впечатление о том, какие внутренние работы на сайте прийдется произвести и, самое главное, сколько труда необходимо для того, чтобы сначала вникнуть в чужой код, найти лучший способ для внесения в него требуемых изменений так, чтобы не нарушить целостность программы. Так же не стоит забывать о лицензионных ограничениях - не во всякий код можно бесцеремонно вносить собственные изменения. Совет будет звучать так: Трижды подумайте, не будет ли проще сделать заново, чем исправлять то, что есть. А если вы все-таки решитесь - примите все меры предосторожности, чтобы сохранить текущую копию проекта на случай, если вы нарушите работоспособность скрипта своим вмешательством. Кстати, тоже из личного опыта. Правда, тогда все обошлось, я смог найти, что я нарушил и вернуть на место, но сколько нервных клеток отдали богу душу, этого никто не считал...
Совет 10. "Есть идея, предлагаю партнерство". У меня тоже есть не меньше десятка идей, может лучше возьмемся за одну из них? Часто встречаются умники, которые придумывают всякие идеи, но сами не умеют ничего сделать и денег не имеют на разработку, тогда они начинают искать, кто бы сделал на халявку. Конечно, не всегда стоит отказывать, иногда бывают вполне интересные заслуживающие внимания идеи, но живые деньги это всегда живые деньги. Делать чужие (да и свои тоже) идеи, которые потом когда-то может быть принесут доход (а может быть и нет) - занятие рискованное. И этим если уж и стоит заниматься, то только при соблюдении нескольких условий: это действительно стоящая идея, ваш партнер тоже что-то может сделать для проекта, он предлагает вам долю, соответсвующую вашему вкладу и у вас достаточно средств для существования, а значит есть для такой всякой чепухи свободное время. Не распыляйтесь на множество сомнительных проектов, делайте в первую очередь то, что принесет доход в кратчайшие сроки. Остальное - как хобби, пожалуйста.
На этом круглом числе я заканчиваю свои вредные советы. С радостью принимаются все конструктивные замечания и предложения по статье.
Оригинал здесь http://junkabyss.com/post/44
В Интернете очень популярны статьи вроде: "10 случаев, когда я говорю «нет»", "5 полезных советов фрилансеру" и т. п. Я решил тоже не отставать и написать свои 10 вредных советов фрилансеру. Почему вредных? Конечно, да, выше названные статьи весьма неплохо повышают уровень самооценки фрилансера, но это вовсе не значит, что они повышают степень его успешности. Могу сказать однозначно, что они уменьшают его шансны получить работу на современном рынке с нынешней жесткой конкуренцией, а значит и снижают количество и частоту задач, решаемых фрилансером, а зачастую это приводит к застою - ведь только в работе человек может поддерживать и наращивать свой уровень профессионализма. И наоборот, отказав одному, второму, третьему фирлансер сидит ждет свою "крупную рыбу", но в итоге теряет навык работы.
Именно поэтому я свои советы где-то считаю вредными, сам их никогда не придерживался, однако, это нередко приводило меня к различного рода конфликтным ситуациям. Поэтому решать вам самим, принимать рынок с его работодателями таким, как есть и, возможно, адаптироваться к нему, либо же сберечь свои нервы и переориентироваться на какие-либо другие направления. Я выбрал второе. Веб-программирование и сайтостроение на заказ я решил считать легкой халтурой в свободное время, которую я не намерен больше искать специально. Пускай работа сама ищет меня. "Была бы шея, а хомут найдется!"
И вот исходя из выше изложенных соображений, я и хочу дать 10 советов, по сути, 10 видов проанализированных совершаемых мною ошибок, неких 10 правил, которых отныне я и сам старатюсь всячески придерживаться. Но для тех, кто собирается и дальше всякими правдами-неправдами, унижаясь и пресмыкаясь, выхватывать работу на фрилансе и выполнять ее в запарках, работая без сна и отдыха за миску похлебки я не рекомендую читать мои советы - они им окажутся несомненно вредными.
Совет 1. "Я тут вкратце набросал". Очень редко (практичеки никогда) на фрилансе встретишь проекты, в которых сразу же можно загузить для ознакомления детальное гармотно составленное техническое задание. Самое печальное тут, что даже при первом контакте с работодателем, когда просишь его предоставить подробное ТЗ, чаще всего нарываешься на ответ: "я тут в кратце наборосал" или "давайте я вам в аське все изложу". Итак, первый, и, возможно, самый главный совет: Никогда не беритесь делать работу до тех пор, пока вам не будет предоставлено грамотное подбробное ТЗ!
Почему я так категоричен? Богатый личный опыт. К сожалению, работодатели не понимают (или наоборот понимают), что ТЗ - это не просто доступное пониманию исполнителя указание, что необходимо сделать, но это прежде всего документ регламентирующий объем работ. ТЗ и только ТЗ может служить критерием оценки того, что работа была завершена и выполнена качественно, т. е. соответсвует требованиям технического задания. Чем же мы рискуем, принимаясь за работу без согласованного ТЗ? Перечислю несколько пунктов риска, с которым я сам непосредственно сталкивался.
Риск 1. "Еще чуть-чуть". Эта ловушка мне встречалась чаще всего, поэтому я склонен думать, что многие заказчики специально избегают составления правильного ТЗ. Происходит так, вы задачу поняли в общих чертах и приступили к работе, когда выполнили около 90% работы, вы начинаете предъявлять заказчику свой результат. Тут мне вспомнилась шутка, которую я вычитал в одной из статей, посвященных созданию технического задания: "90% времени занимает создание 90% проекта, оставшиеся 10% проекта занимают другие 90% времени"
Именно так, после того, как вы показали заказчику результат работы, приближающейся на ваш взгляд к завершению, тут-то как раз и начинается самая большая работа. Закачик сразу же вспоминает о нескольких дополнениях, которые он сразу почему-то забыл сказать, а потом вот этот кусок работы он вообще представлял не так и просит вас его переделать по-другому. Потом еще чуть-чуть переделать, а потом еще чуть-чуть доделать и так до бесконечности. Хорошо еще, если при этом оплата увеличивается хоть немного и на вас не начинают давить по срокам, угрожая наоборот оплату урезать.
Риск 2. "Разве я это просил сделать?" Эта ситуаия возникает как от банального непонимания задачи, так и опять же от несерьезности заказчика, который преднамеренно умолчал некоторые особо сложные аспекты проекта, но об этом мы поговорим в третьем пункте. Не правильно же понятая задача чаще всего выливается в недовольство заказчика результатом вашей работы, после чего либо вам прийдется все переделывать заново, либо заказчик просто откажется от вашей работы, не заплатив ни копейки. Так иногда месяцы работы летят на смарку.
Риск 3. "Сколько можно делать?" и "Какая еще доплата?" На этот вид граблей ваш покорный слуга наступал неоднократно и, думаю, что в некоторых из случаев заказчик не без умысла скрыл некие сложные аспекты своего проекта, ограничившись коротким описанием, с целью выдать сложную задачу за простую, чтобы на этапе согласования цены повлиять на стоимость работ, значительно занизив ее. Потом, когда вы дочитываетесь до пунктов, недостаточно детализированных, начинаете уточнять, оказывается, что работать вам прийдется без выходных. Например, за фразой "лента новостей" может скрываться полнофункциональный блог с комментированием, категориями, регистрацией пользователей и так далее, а за словом "календарь" может прятаться полнофункциональный планировщик задач с установкой сложных расписаний и сервисом напоминания. В итоге, вы будете пыхтеть над этой работой в три раза дольше обещанного срока, заказчик будет давить на вас за срыв сроков, а на все разговоры о повышении оплаты он тут же будет вспоминать о деловой этике, мол, не хорошо менять назначенную цену задним числом.
Совет 2. "Назовите цену и сроки". Первый совет я не зря назвал одним из главных, так как все остальные весьма близко перекликаются с ним. Часто заказчик, не дав четкого ТЗ и едва обрисовав задачу в двух словах, немедленно требует назвать цену и сроки выполнения работы. Никогда не называйте цены и сроков, не ознакомившись с детальным подробным ТЗ. Чем чревато нарушение этой заповеди не сложно догадаться, вы можете представить себе задачу по-одному, а заказчик будет представлять ее совсем по-иному. Как правило, в ТЗ, если вы его все же потом получите, окажется проект раза в два-три объемнее, чем вы себе представляли.
Совет 3. "Сделайте, как тут". Иногда может показаться, что образец в виде готового сайта куда нагляднее любого самого подробного технического задания, однако, это ощущение несколько обманчиво. Во-первых, для того, чтобы выяснить некоторые детали, вам надо будет потратить уйму времени на изучение сайта-образца, а во-вторых, вы ведь сможете увидеть только его внешнюю сторону, а о том, как устроен сайт изнутри, как выглядит его админ-панель, по каким алгоритмам работает - этого вы скорее всего узнать не сможете. Итак, мой совет: Не позволяйте заказчику ТЗ заменять сайтом-образцом. Хотя ссылки на такие сайты могут быть хорошим дополнением к ТЗ.
Совет 4. "Предоплата". Любой сложный проект занимает у разработчика массу времени и труда, а любой труд должен быть по достоинству оплачен. Если вы беретесь за работу без предоплаты, вы даете возможность заказчику в любой момент времени передумать. Хуже всего, когда заказчик передумывает только в самом конце, когда заказ уже готов на 99%. Такой случай совсем недавно произошел со мной, мне с трудом удалось добиться от заказчика оплаты неустойки в размере 50%. Так вот: Всегда берите с заказчика предоплату в размере 30-50%. Это избавит вас от таких несерьезных работодатлей, которые не смогли сами определиться нужна им ваша работа или не нужна. По-крайней мере неустойку за отказ вы уже будете иметь в кармане на всякий случай. Так же это повысит ваш вес при решении спорных вопросов, например, на счет не указанных в ТЗ доработок и переделок. Не буду выделять жирным и другой совет: не берите предоплату 100% и, тем более, не тратьте полученные наперед деньги. Поскольку предвкушение оплаты за работу дает некий психологический стимул для работы. Наоборот, когда деньги уже получены и давно потрачены, выполнять потом такую работу очень не хочется, но если вы порядочный человек, то надо обязательно. Именно из-за этого "надо" всегда обычно и не хочется. Хотя, возможно, это личное - терпеть не могу работать "из под кнута".
Совет 5. "Да там работы на полчаса". Совсем недавно ко мне в аську стукнул один, ТЗ не предоставил, сказал "сделай, как тут", потом потребовал по-скорее назвать цену и сроки, еще заявил, что ему знакомый программист сказал, что там работы на полчаса, а потом еще и нахамил перед тем, как попасть в игнор-лист, чем подтвердил правильность моего отказа. Человек нарушил все ранее озвученные принципы, следующим шагом была бы неоплата, наверняка. Но оставим в покое упоянутого товарисча, бог ему судья. Просто вспомнилось именно потому, что в его исполнении прозвучала ключевая фраза: "работы на полчаса", т. е. человек заведомо считает, что это работа простая и дешевая, хотя сам в этом не разбирается, но якобы подкрепляет слова мнением некоего знакомого специалиста в этой области. Возникает резонный вопрос, почему не дал возможности заработать легких денег (работа ведь простая) своему знакомому, а ищет заказчика на стороне? Ответ прост, либо оплата заведомо не соответствует сложности, либо и вовсе нет никакого знакомого программиста. Человек явно хочет сбить цену и, поэтому получает отказ. Никогда не беритесь за работу, если заказчик заведомо сбивает цену.
Совет 6. "Может можно быстрее?" Иногда бывает, что заказчик хочет, чтобы вы сократили срок разработки. Возможно, вам хочется работать по ночам и без выходных, тогда соглашайтесь. Я же предпочитаю всегда называть срок в 1.2-1.5 раза больше расчетного, так как всегда могут возникнуть непредвиденные обстоятельства. Я считаю, лучше приянто удивить заказчика, сделав работу досрочно, чем огорчить его срывом сроков. Никогда не соглашайтесь на сокращение сроков. Иногда для разработчика сроки очень принципиальны, например, он сам взял работу, которую не успевает сдать в срок, поэтому решил спихнуть ее на вас. Возможно вы молоды и здоровы, а денег хочется заработать очень, поэтому вы готовы согласиться в расчете, что справитесь, пожертвовав сном и отдыхом. Поверьте, молодость и здоровье быстро и незаметно пройдут, если вы будете все время вкалывать за копейки, особенно, если при этом вы еще и не впишетесь в сроки, а заказчик будет вам каждый день портить нервы своим настойчивым "когда наконец?"
Совет 7. "Может можно дешевле?" Хорошо, сегодня вы уступите вашему заказчику. Вопрос, уступят ли вам завтра, когда вам надо будет платить по счетам за электричество, за Интернет, за телефон, за коммунальные услуги? Сделают ли вам скидку в транспорте или в магазине? Может быть в ресторане для вас установят льготные цены?
Скажете, как-то все это жестко и по-жлобски звучит? Мол, сегодня вы помогли, а завтра вас не оставят в беде? Может быть, может быть в этом мире и есть немного места милосердию и благотворительности, однако, альтруизм хорош до тех пор, пока он творится от излишка. Я все думал, как бы по-мягче сформулировать седьмой совет и решил так: Не снимайте с себя последнюю рубаху.
Вообще, я считаю, что правильно расчитанная цена не может быть жлобской, поэтому в ней практически нет места для скидки, а расчитывается эта цена приблизительно так: вы определяете сроки выполнения работы и с учетом своих потребностей определяете стоимость своего дня/часа работы, умножаете одно на другое и получаете требуемую сумму. Это мой метод, но я встречал где-то на форумах, что так делают многие. Как же правильно определить срок выполнения работы и определить стоимость своего часа работы?
О сроках я уже писал выше. Конечно, это приходит с опытом, когда вы уже можете приблизительно судить сколько времени у вас займет та или иная работа, главное тут быть внимательным, дочитываться до каждой мелкой детали в ТЗ, которое вне всяких сомнений должно присутствовать.
Что же касается часа работы, эта вещь достаточно субъективна. Можно, конечно, ориентироваться на существующую на рынке труда ситуацию, например, на сайтах по трудоустройству просмотреть объявления о вакансиях на должность веб-программиста или той профессии, представителем которой вы являетесь, вычислить среднюю зарплату, которая там предлагается. Надо не забывать, что зачастую там пишут зарплату на испытательный срок, поэтому полученную сумму можно увеличить раза в полтора, потом разделить на 20 рабочих дней и на 8 часов. Это один метод, которым я, кстати, до сих пор не пользовался, но сейчас я сделаю экспримент. Я проверю этим методом уровень своей самооценки
Именно по субъективной самооценке и подсчету своих основных потребностей я назначил цену за свои услуги в размере 4 доллара в час (у меня реально скромные запросы). Теперь идем на сайт rabota.ua и в поиске выбираем раздел "Веб-мастера, веб-дизайнеры, техписатели", смотрим... гммм, 3 вакансии и во всех зарплата не указана. Ладно, идем на weblancer.net в раздел вакансии и смотрим там: Программист на постоянную удаленную работу - 500 у. е., Ищем профессионального PHP-программиста - 1000 у. е., Разработчик сайтов под ключ - 5000 у. е., Web-программист - 1000 у. е., Требуются программисты из Санкт-Петербурга - 1000 у. е., Программист PHP MySQL AJAX - 2500 у. е. Думаю, достаточно. Расброс, конечно, приличный. Признаюсь, я отсек варианты 100 у. е. и 10 000 у. е. - это предложения от людей, живущих где-то не на этой планете
Итак, суммируем: 500 + 1000 + 5000 + 1000 + 1000 + 2500 = 11 000. Делим: 11 000 / 6 = 1833. Умножаем на 1.5 с учетом испытательного срока и получаем 2750 у. е. Делим на 20 рабочих дней и на 8 часов, результат: приблизительно 17 баксов. Да, я явно свои запросы слишком уж ужимаю. С сегодняшнего дня, мои услуги будут стоить 5 баксов в час
Совет 8. "Любой дурак разберется". Бывают случаи, когда вам предлагают сделать работу, в которой на данный момент вы не компетентны, а вы как человек здравый отвечаете отказом, поскольку не знаете сколько времени вам понадобиться на то чтобы разобраться и не можете сказать, уложитесь ли вы предъявляемые требования по срокам. Не редко у меня бывало так, когда меня все-таки убеждали зачем-то, что работа проста, мол, любой дурак разберется. Потом получалось так, что я не справлялся и в намеченный срок не укладывался. Сейчас я уже давно перестал брать заказы на авось разберусь как-нибудь. Стараюсь брать только ту работу, которую знаю четко, как делать и сколько времени понадобится для выполнения данной работы. Бывают исключения, когда, не смотря на мои предупреждения, что я с какой-то частью работы на данный момент не знаком, заказчик все же соглашается и предоставляет не слишком жесткие по срокам условия. Как раз такие варианты я очень даже приветствую - лишняя возможность изучить что-нибудь новое и получить еще и деньги за это. Вобщем, так: Старайтесь избегать браться за незнакомую вам работу в сжатые сроки.
Совет 9. "Тут только чуть-чуть подправить". Этот совет в принципе похож на пятый, но он чуть менее экстремален и акцент немного на другом. Зачастую заказчик, обманываясь незначительностью внешних исправлений, составляет себе не правильное впечатление о том, какие внутренние работы на сайте прийдется произвести и, самое главное, сколько труда необходимо для того, чтобы сначала вникнуть в чужой код, найти лучший способ для внесения в него требуемых изменений так, чтобы не нарушить целостность программы. Так же не стоит забывать о лицензионных ограничениях - не во всякий код можно бесцеремонно вносить собственные изменения. Совет будет звучать так: Трижды подумайте, не будет ли проще сделать заново, чем исправлять то, что есть. А если вы все-таки решитесь - примите все меры предосторожности, чтобы сохранить текущую копию проекта на случай, если вы нарушите работоспособность скрипта своим вмешательством. Кстати, тоже из личного опыта. Правда, тогда все обошлось, я смог найти, что я нарушил и вернуть на место, но сколько нервных клеток отдали богу душу, этого никто не считал...
Совет 10. "Есть идея, предлагаю партнерство". У меня тоже есть не меньше десятка идей, может лучше возьмемся за одну из них? Часто встречаются умники, которые придумывают всякие идеи, но сами не умеют ничего сделать и денег не имеют на разработку, тогда они начинают искать, кто бы сделал на халявку. Конечно, не всегда стоит отказывать, иногда бывают вполне интересные заслуживающие внимания идеи, но живые деньги это всегда живые деньги. Делать чужие (да и свои тоже) идеи, которые потом когда-то может быть принесут доход (а может быть и нет) - занятие рискованное. И этим если уж и стоит заниматься, то только при соблюдении нескольких условий: это действительно стоящая идея, ваш партнер тоже что-то может сделать для проекта, он предлагает вам долю, соответсвующую вашему вкладу и у вас достаточно средств для существования, а значит есть для такой всякой чепухи свободное время. Не распыляйтесь на множество сомнительных проектов, делайте в первую очередь то, что принесет доход в кратчайшие сроки. Остальное - как хобби, пожалуйста.
На этом круглом числе я заканчиваю свои вредные советы. С радостью принимаются все конструктивные замечания и предложения по статье.
Оригинал здесь http://junkabyss.com/post/44
Я так иногда попадалась! Теперь знаю как надо! 
