Как стать автором
Обновить

15 заповедей IT-фриланса и мелкой разработки

Время на прочтение10 мин
Количество просмотров13K
Всего голосов 25: ↑24 и ↓1+23
Комментарии19

Комментарии 19

Жаль, что "сделайте сначала это, а дальше видно будет", "требования изменились, не составлять же новое тз" и "сделай это к вчера" сводят на нет всю красивую и логичную теорию фриланса.
Может быть кто-то знает, как работать с такими вот заказчиками?
Фриланс — это дикое поле, нет там теории.
Проблема фриланса в том, что тут действуют участники самой разной квалификации и принципов, поэтому им часто бывает трудно договориться. Условно, у любого фрилансера или заказчика есть некий уровень зрелости, и он может сотрудничать с определенным сегментом контрагентов, который этому уровню соответствует. Попытка работы в чужом сегменте, если даже удастся договориться, приведёт к неоплате, несправедливой оплате, недовольству результатом и взаимной обиде. Иначе говоря, ваших заказчиков на рынке навскидку не более 20%. Остальные — не плохие и не хорошие, они просто вам не подходят, а вы — им.
В статье перечислены моменты, которые, на наш взгляд, помогут вам обозначить свой уровень и подобрать аудиторию, которая приемлет план, может сформулировать или хотя бы утвердить свои же требования, да и в принципе готова сотрудничать, а не «мне только спросить». В этом русле получаются самые устойчивые отношения.
«сделайте сначала это, а дальше видно будет», «требования изменились, не составлять же новое тз»

Если вопрос в варианте сотрудничества, да ещё так чтобы голова не болела, то почасовка. Любители работать вне эскроу без таймтрекеров могут составить доп соглашения к основному договору.

«сделай это к вчера»

Тут варианта два. Если заказчик не идиот, то по повышенной ставке или с бонусом за срочность. Иначе золотое правило don't work with assholes.
Заказчик для вас человек посторонний, поэтому работать надо спокойно: дали оценку, назвали срок, запросили аванс. Есть аванс — работаем, нет — не принимаем близко к сердцу.

Вопрос — какой опыт фриланса у автора, и с каким контингентом приходиось работать — имеется ввиду прежде всего: отечественный или зарубежный

Фрилансерский опыт только с отечественными заказчиками и достаточно эпизодический, между серьезными подрядами.
Поразмышлял над этим, хочу добавить: я живу за счет подрядов как раз потому что использую приемы этой статьи. Не получается засидеться во фрилансе, заманивают в крупный проект как штатного работника или ИП (сейчас я ИП на субподряде). Не потому что я крутой разработчик, а потому что мыслю согласно чаяниям потенциального работодателя.
Мои отношения с крупным заказчиком длятся в среднем 2.5 года, в том числе я работал на крупнейшие зарубежные банки — как консультант компании, не как фрилансер. Это хорошие деньги, поначалу интересные проекты, но становится скучно.
Фриланс даст только на хлеб и ипотеку, но здесь интересно: я использую конструкторы и могу дать волю фантазии, чего нет и не будет в энтерпрайзе.
Довольно хорошая статься для таких юных подаванов как я, но мне кажется, что на практике она больше применима для офисных работников чем фриласеров.
Я бы особенно рекомендовал её диспетчерам фрилансеров — вот у кого серьезные проблемы с вышеизложенным.
Если у вас уходит два дня на оценку и клиент это время ждет — этот проект никак нельзя назвать мелким.
Вообще большинство решений во фрилансе принимаются в течении пары часов, и типичный мелкий проект занимает эти же два дня. Проекты больше недели довольно редки.

Количество проектов, на которых заказчик соглашается на НЕ-единоличное владение исчезающе мало.

Гарантийный срок — класно, но всегда надо ограничивать срок и состав притензий. Также надо оговаривать время приемки.

И кстати если просить отзыв — где-то на пол бала меньше получаешь, в среднем.

Опыт фриланса — 20 лет.
Вероятно, мы работаем с заказчиками из разных сегментов или по разной тематике.
Ваш пример мне напоминает как раз мои отношения с фрилансерами как заказчика: обычно я не заказыааю ничего, что нужно делать больше 5-8 часов (сделать макет, написать или надиктовать текст, сверстать несколько страниц html и т.п.). Мой минимальный проект стоил 22500, я сделал прототип для сетевой школы английского. Проекты моих коллег подороже, стоимостью до сотен тысяч.
И, кстати, я выкидываю половину результатов, заплатив за них деньги, просто потому что не могу их использовать — они не годятся в моём случае. Фрилансер об этом не узнает, но и я к нему не вернусь.

Я бы проговорил риски заказчика

Я старался показать как снизить риски заказчика: основной риск из-за отсутствия взаимопонимания и из-за разного представления об ожидаемом результате с обеих сторон. Мы пытаемся здесь снизить неопределенность и сразу зафиксировать понимание.
Вроде бы и полезные вещи и всё на удивление по делу (кроме, пожалуй, собственности на продукт — этот вопрос даже не обсуждается, она всегда за заказчиком, причем на уровне законодательства, т.е. в договоре может даже не упоминаться). А вот со сроками и оценками задач внутри статьи как раз беда какая-то.

Цитата 1: сотня отчетов в системе… Разработка отчета обычно занимает не более нескольких минут.

Вот как разработка отчета может занять несколько минут, когда на одно только общение и уточнение деталей может уйти десятки минут?! Не говоря уже про тестовые данные и проверку этого самого отчета. Ни разу не видел ни одного конструктора отчета, который «за несколько минут» что-то полезное может сделать.

Цитата 2: Инструкция в простом случае займет у вас 3-4 часа работы

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

P.S. В статье нет самого главного — не гонитесь за заказами и не снижайте бюджеты ради этого (и уж тем более не пытайтесь уложиться в те суммы, что указаны в заявке на каком-нибудь фрилансе — типичная ошибка новичков). Вы пришли зарабатывать на жизнь, а не выживать. Давайте реальную оценку сроков и стоимости, исходя из своих ставок. Пускай заказчик и выберет «самого дешевого» — но он все-равно вернется, уже за нормальным специалистом и с горьким опытом «сэкономить».
(кроме, пожалуй, собственности на продукт — этот вопрос даже не обсуждается, она всегда за заказчиком, причем на уровне законодательства, т.е. в договоре может даже не упоминаться)

Для небольших проектов и заказчиков всё так, вопрос даже не поднимается.
А вот со строительными компаниями мы трижды теряли заказ от 400 до 850 тысяч (за первую фазу), потому что мой партнёр не смог мирно договориться об этой самой собственности.
Цитата 1: сотня отчетов в системе… Разработка отчета обычно занимает не более нескольких минут.

Вот как разработка отчета может занять несколько минут, когда на одно только общение и уточнение деталей может уйти десятки минут?! Не говоря уже про тестовые данные и проверку этого самого отчета. Ни разу не видел ни одного конструктора отчета, который «за несколько минут» что-то полезное может сделать.


В конструкторе даже простое приложение можно накликать за 15 минут, с отчетами и графиками.

Бывают сложные отчеты, как вот проводка документов, но обычно отчет может сделать сам заказчик или он диктует по телефону, вроде: хочу выборку за месяц по лидам с группировкой по источнику, отсортированную по убыванию популярности источника, повешенные на менеджеров из группы Сидорова. Таких отчетов — большинство, и они делаются сразу: заказчик объясняет, что ему нужно, и тут же может видеть результат, нажимая F5 в браузере.
Цитата 2: Инструкция в простом случае займет у вас 3-4 часа работы

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


Первая версия приложения обычно достаточно простая и инструкции может быть написана за пару часов. Вот пример такой инструкции, вместе с тестовыми данными.

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

Это отдельный пункт в техническом задании и он должен оплачиваться соответственно.

Сделаем скидку на то, что это фриланс :-)
Мы включаем инструкцию в оценку, ибо это профессионально, и честно делаем её, покуда за эту работу платят.
P.S. В статье нет самого главного — не гонитесь за заказами и не снижайте бюджеты ради этого (и уж тем более не пытайтесь уложиться в те суммы, что указаны в заявке на каком-нибудь фрилансе — типичная ошибка новичков). Вы пришли зарабатывать на жизнь, а не выживать. Давайте реальную оценку сроков и стоимости, исходя из своих ставок. Пускай заказчик и выберет «самого дешевого» — но он все-равно вернется, уже за нормальным специалистом и с горьким опытом «сэкономить».

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

Публикации

Истории