Почему нужно просить нормальных денег за работу

http://miumau.livejournal.com/980578.html

Читать всем фрилансерам (и заказчикам) в обязательном порядке :).

Футболки с котэ

Котэ

Не прошло и пяти лет, как я открыл магазин с футболками «Motivate me right!»— всем читателям моей хулиганской книжки про мотивацию посвящается :).

Я с самого начала хотел продавать футболки, и даже напечатал несколько в 2008 году, но дело не пошло, потому что времени не было всем этим заниматься. Но теперь такой магазин можно сделать всего в пару кликов с помощью Print Direct: далее реклама :)

Парсер OZON.ru версии 1.26

Парсер обновился. Теперь он не только поддерживает последние изменения на сайте ozon.ru, но и умеет делить кэш на несколько сайтов.

Скачать можно по адресу: Парсер OZON.ru (теперь он живет тут).

Решение найдено. (ex: Нужна помощь коллективного разума)

потому что мой уже трещит по швам :).

Неведомая фигня происходит на моем компе. У меня есть вот такая программка:

// a.c
#include 

int main (int argc, char** argv) {
  FILE* f = fopen("x", "w");
  fprintf(f, "Hello!\n");
  printf("Hello!\n");
  fclose(f);
}

Компилирую, запускаю:

a.exe > y

— файл "y" создается, а "x" — нет.

Windows 7, компилятор mingw (Visual Studio C++ тоже пробовал).

И такая хрень происходит с любым моим C'шным скомпилированным кодом — файлы не создаются. Потом вдруг рррраз, создались! А потом снова не создаются.

Update: Спасибо Лехе aka "Android", решение найдено. Это был Avast, мать его. Стоит выключить его файловый экран, все работает, включаю - перестает. И, блин, хоть бы он голос подал, что ему моя программа подозрительна. Так нет, он молча все делает - без намека на проблему. И, как пишут на форумах, эта проблема с Avast не только у меня появилась после его обновления до версии 7.

Почасовая ставка vs. Fixed price

Несколько мыслей о том, почему я люблю работать на почасовой ставке и не люблю проекты с фиксированной ценой.

На fixed price я заинтересован сделать проект как можно меньшими усилиями. Т.к. заказчики неохотно идут на увеличение бюджета fixed-проектов, я буду всячески сопротивляться любым требованиям, выходящим за рамки начального объема работ. Если у меня будут идеи о том, как сделать продукт лучше, я, скорее всего, их придержу, чтобы не оказаться в ситуации, когда мне придется их реализовывать забесплатно.

С почасовой ставкой я заинтересован работать как можно больше (в пределах недельного контракта, если он есть), однако ответственность за мою производительность с точки зрения заказчика лежит целиком и полностью на мне — если я стану делать слишком мало и долго, у заказчика будет повод отказаться от моих услуг. Т.е. с одной стороны, мне выгодно работать много, с другой — максимально эффективно. Так что главный путь увеличения дохода (т. е. отработанных часов) — реализация дополнительной функциональности и тщательность проработки деталей. В случае работы на ставке я обычно сыплю идеями улучшений функциональности, юзабилити и т.п. Также я гораздо более внимателен к тому, насколько хорошо все работает.

Fixed price часто выбирают «жадные» клиенты. Они легко увеличивают объем работы, но не бюджет. Все мои постоянные клиенты работают со мной на почасовой ставке. Причем это не означает, что они платят больше за свои проекты, чем те, что предпочитают fixed-price.

Учитывая возможность увеличения объема разработки, я заранее определяю бюджет fixed-price проекта с запасом (для новых или особо стремных клиентов этот запас бывает весьма ощутимым :), и стараюсь договориться на максимально возможную сумму, на которую готов пойти заказчик. На деле работа может оказаться не такой сложной. Так что в итоге я получу больше денег, чем если бы делал ее с оплатой по часам.

С Fixed-price я беру технические риски по проекту на себя — если всплывет какая-то сложность, которая не была учтена при определении бюджета, мне, скорее всего, придется работать над ней за свой счет. В случае почасовой ставки этот риск лежит на заказчике.

Как определить плохого заказчика? По следам вебинара «Как построить хорошие отношения с заказчиками»

Спасибо всем, кто пришел меня послушать, и, конечно же Сергею Бережнову, что пригласил меня выступить!

Запись уже обработана, Сергей в ближайшее время обещал выложить.

Как и обещал, публикую несколько полезных ссылок, а также свой check-list для определения потенциально «плохого» заказчика.

Полезные ссылки по теме

Семь признаков плохого заказчика

  1. Неадекватно жадный.
  2. Fixed-price проекты c размытым функционалом и оплатой по факту выполнения.
  3. Низкая доступность заказчика по ходу работы с последующим появлением в конце разработки со словами «нет, это совсем не то».
  4. Не готов к уступкам.
  5. Ограничивает взаимодействие с ключевыми людьми в проекте со своей стороны.
  6. Изначально не доверяет.
  7. Считает достаточным вкратце формализовать задачу и закончить разговор словами «Ну вы же профессионал, сами все должны понимать, к тому же мы вам СТОЛЬКО платим».

Семь признаков хорошего заказчика

  1. Понимает, что хорошая работа стоит хороших денег.
  2. Знает, что из низкой цены, качества и скорости разработки можно выбрать только два пункта.
  3. Ежедневно доступен для связи и охотно идет на контакт.
  4. Регулярно участвует в обсуждениях по проекту.
  5. Не занимается микроменеджментом.
  6. Изначально обладает высоким уровнем доверия.
  7. Как правило, из западных компаний и работает по адекватному процессу.