Фрилансер и заказчик. Взаимодействие

    Каждый, кто имеет дело с IT в той или иной форме, так или иначе сталкивался/слышал о том, что существует такое явление, как фриланс. Как может показаться на первый взгляд, фриланс несет в себе одни плюсы. Ни тебе работника в офисе, для которого надо организовать рабочее место, ни проблем с оформлением его по ТК и последующим увольнением (если нанимать на четко заданный объем работ). Так же стоимость фрилансера, как правило, оказывается от 2 до 20 раз меньше, чем у фирмы, предлагающей те же самые услуги.

    Тем не менее, существует огромное количество негативного опыта работы с фрилансом. О его приинах и возможных способах устранения — под катом



    Предисловие



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

    Этап первый. Постановка задачи



    Данный этап скорее для заказчика, чем для фрилансера. Прежде всего, забудьте о том, что ваши родственники что то умеют делать. Я работал в двух разных сферах — автосервисные услуги и программирование, и из обоих я вынес железное правило — у родственников либо бесплатно, либо никак. Это же касается и друзей, выстроить с ними грамотно бизнес — огромная наука, которая подвластна не каждому. История пестрит примерами, когда работа с другом приносила только разочарование и заваленный в нуля проект.

    Второе, о чем следует задуматься — хотите ли вы сами контролировать этот процесс, или хотите поручить это манагеру. Если вы решите идти по первому пути, то готовьтесь тратить на это время. Минимум час в день, а лучше — пару. Работать над проектом, контролируя результат раз в неделю не получится. Даже сайт-визитка требует к себе минимум полчаса в день внимания, не говоря уже о более крупных десктопных проектах.

    Тут, кстати, не лишним будет развеять миф о манагерах. В небольших фирмах/сообществах фрилансеров манагер выполняет уйму ролей — он, как правило, знаком с программированием и даже может выполнять роль архитектора приложений. Он сводит в кучу исходники, которые получены от разных исполнителей, решает внутренние конфликты, которые, если программистов больше чем 1, неизбежны, он является буфером между программистами и вами как заказчиком, так как программисты не всегда являются замечательными в общении людьми, а с заказчиками выяснять вопросы так вообще не любители. Он будет контролировать ход выполнения проекта, раздавать таски (одно дело — написать «хочу программу» и другое — разбить хотелки на правильную последовательность взаимосвязанных тасков). Так же, как правило, обладая опытом работы с заказчиками, манагер проекта умеет задавать вопросы, о которых вы даже не задумываетесь, но думают программисты. Если работать непосредственно с самими программистами, то они данные вопросы как не освещенные выполнят так, как посчитают нужным, что может отрицательно сказаться на важных характеристиках приложения. Так что манагер в небольших фрилансерских сообществах/фирмах — важный элемент процесса, который не занят перекладыванием бумажек. Это не Газпром. И если встретите в коммерческом предложении данную статью расходов — не нужно вопить, что это лишнее расходование средств. Оцените час вашей работы, возьмите примерное количество человек, занятых в процессе разработки, умножьте это количество на 1 час, и умножьте на количество дней, в течение которых будет длиться проект — я более чем уверен, что если вы цените свое время, то это убедит вас в необходимости такого человека в команде.

    Далее сядьте и представьте себе в подробностях то, что нужно сделать. Если вы уже составляли ТЗ — это шикарно. Если нет, то попробуйте описать то, что вы хотели бы видеть в проекте, свободной форме. После чего переходим к следующему этапу.

    Этап второй. Выбор



    Заказчик


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

    После этого публикуем проект. Что нужно указывать в проекте?

    Название. Как правило, никто не сидит на сайтах и не жмет F5. Все сайты имеют RSS API. через которое любая программа с данной функцией, будь то почтовик или спецсредства, умеет забирать проекты. Как правило же, в таких программах проекты отображаются как список заголовков. Даже если это не так, то вот простой пример — работа с 6-ю биржами приносит порядка 2 тыс проектов в день. Естественно, читать каждый не получится физически. Соответственно, все они просматриваются по заголовкам. откажитесь от такого неинформативного кала, как «проект», «требуется исполнитель», «срочно». Шансы найти требуемого вам исполнителя резко повысятся, если указать предмет беседы. «Сайт-визитка», «ПО для клиник», «требуется курсовой» :))) — гораздо более информативно, и позволит хотя бы понять, стоит ли просматривать сообщение.

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

    Контакты. Тут вопрос спорный. Как правило, все сайты представляют возможность вести общение в виде чата, что удобно и понятно, и иметь всегда под рукой всю переписку со всеми. Указывание контактов же. особенно на проект типа «требуется сайт», гарантировано принесет вам в контакты 30-40 человек в первые же сутки. А потом эта канитель будет продолжаться. пока проект не будет снят с публикации. общаться с такой кучкой народу в аське/скайпе гораздо неудобней, но это — мое ИМХО. С другой стороны, если проект вам надо сделать сейчас, то указание контактов — один из способов ускорить и упростить процедуру.

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

    Фрилансер


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

    Для начала, обратите внимание на грамматику. ИМХО — самый серьезный показатель. Если предложение все в ошибках, от которых скулы сводит — я предпочитаю не связываться.

    Второй момент — бюджет проекта. Если он вас устроил — переходим к следующему шагу. Если он слишком низок — присмотритесь, может имеет смысл сделать проект и получить профит в виде отзыва, а может проект просто интересный и будет полезен для саморазвития. Если стоимость, на ваш взгляд, высока — не спешите отвечать на данный проект и подумайте. Во всем важна постепенность. Я тоже сначала радовался проектам на 1 мес при бюджете в 7 т.р., но шел по пути увеличения бюджетов постепенно. Если вы считаете, что денег платят много, это значит что:

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

    В любом случае, если ваши обычные проекты находятся на уровне 100 т.р., а вы видите проект на 500, то это повод хорошенько подумать. Тут, кстати, можно попробовать снизить цену, но при этом нужно точно и досканально ознакомиться с проектом. Упасть в цене и выяснить потом, что это было зря — не самый удачный расклад.

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

    Если все устраивает, смело пишем заявку. Несколько правил:

    а) не пишите заявку вида «застолбил место». Раздражает хуже безграмотно написанной заявки. Если у вас нет 10 минут, чтобы написать заявку, то нафига вам этот проект
    б) не пишите слишком короткую или слишком длинную заявку. Комментарии вида «сделаю!» не должны встречаться, равно как и полное жизнеописание. Идеальным, на мой взгляд, ответом может быть ответ, содержащий приветствие (обязательно!), 2-4 сроки с ответом на заявку, контакты (не ленитесь, не каждый исполнитель полезет в профиль смотреть вашу аську или скайп) и подпись.
    в) не лишним будет в заявке задать уточняющий вопрос или пару (больше не надо). Это поможет начать диалог по проекту. Остерегайтесь неграмотных вопросов, для каждой сферы они свои.
    г) совсем чудесно будет указать вилку цен и сроков на проект. Можно указать их приблизительно, а так же от чего зависит изменение в положительную/отрицательную стороны.

    Часть третья. Общение



    Применительно как к заказчику, так и к исполнителю. Сейчас стало очень модно обращаться на «ты». Уж так меня воспитали, но меня реально коробит, когда и заказчики, и исполнители начинают с первых строк тыкать. Это вполне приемлемо, если у вас спросили, можно ли перейти на ты, тут отказывать не принято, но если начали прям с порога — повод задуматься.

    Заказчик


    Посмотрите на тех, кто ответил на ваш проект. Если вы читаете статью целиком, то стоит обратить внимание на заполнение заявок, которые описаны во второй части. Если вы узрели в ответах хамство, то лучше с таким человеком не связываться — итог огорчит.

    Так же стоит посмотреть, насколько фрилансер опреирует профессиональными терминами и насколько готов пояснять вам непонятные моменты. Спрашивать тут не постыдно, а наоборот приветствуется, так как вы платите деньги. и если вам предлагают на выбор php или asp, то стоит разобраться, что это за звери применительно к вам. Т.е. я не призываю понять серверные особенности данных технологий, я предлагаю вам спросить у исполнителя, чем мне это грозит. Ответы вида «да по сути одно и то же» — тут же в топку. По крайней мере, это разные хостинги, и если у вас уже есть сайт на какой то площадке под php, с большой долей вероятности сайт на asp подсадить к нему не получится. То же касается технологий разработки ПО для десктопа. Исполнитель обязан помочь вам сделать осознанный выбор, если таковой имеется.

    Фрилансер


    Прежде всего, начав переговоры, не бойтесь отвечать на вопросы и предлагать варианты. Причем последнее, если есть различия в реализации, недурно подкреплять влиянием на сроки и стоимость. Например — «ПО можно реализовать на C#, либо на C++. Последний вариант увеличит стоимость на 15 т.р. и срок разработки на 2 недели, но при этом даст (тут описать какие то плюшки, ради которых вы вообще затеяли этот разговор)». Не стесняйтесь отвечать, только разговор укрепит ваши отношения с заказчиком. При этом не надо ржать над заказчиком, который попросил вас объянить, что такое html. У него есть задача и деньги, а быть специалистом в данной области он не обязан. Идеальное решение — разместить на своем сайте цикл статей с прописными истинами. Тогда всегда можно а) не писать опять горы текста и б) лишний раз показать свой сайт.

    На данном этапе, как правило, и заказчик, и фрилансер уже в состоянии по общению понять, подходит ли данный человек для совместной работы. Касается опять же всех — избегайте работы с теми, кто вам не приятен. Это удел фирм, а в фриланс мы не для этого шли, верно? Каких бы денег не сулил проект, если нет возможности достичь взаимопонимания — это будут лишние нервы с обоих сторон и недовольство по завершению проекта. Оно вам надо? :)

    Всех с наступающим.

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 21

      +3
      Получилось как-то достаточно объемно и обо всем сразу. Тяжеловато для восприятия. Еще не очень понравилось как местами написано.

      Вообще кажется что подобных статей очень много, хотя может мне только кажется.
        0
        Нет, не кажется. Статей подобных достаточно много. Если бы еще читали перед тем, как начать пробовать свои силы :))))

        Ну а что касается объема, то да, ну и нюансов опять же столько много, что это — всего лишь основы.
          0
          Основы — это хорошо :) А продолжение?)
          Статей действительно много на подобную тематику. И на хабре проскакивают с завидной регулярностью. Только вот все начинают писать… и не доводят мысли до конца. Надеюсь, вы не из их числа?)

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

          И второй вопрос, как заказчика: что делать, если фрилансер «теряется». Рвать и метать? Войти в положение и подстраиваться под исполнителя? Бывает, что фрилансер понравился, обо всем максимально профессионально поговорили. Даю задачу. Реализует часть. И пропадает. Через несколько дней появляется с кучей отмаз… Как предусмотреть подобные нюансы заранее?

          В общем, жду продолжения :) Спасиб!
      0
      Вполне себе дельные советы для начинающих. Объяснил бы мне кто-нибудь все это в самом начале, удалось бы избежать огромного количества шишек.

      P.S
      frig прав, это не первая такая статья, однако судя по поведению контингента на фрилансе их мало кто принимает к сведению.
        +1
        Согласен на все сто. Как показывает практика наблюдения за работодателями/соратниками при ответах, так и сами ответы на мои проекты, такие статьи надо писать, писать и еще раз писать. Мало кто, начиная работать с фрилансом, приходит туда, прочтя некое количество статей. еще меньшее количество людей лезут искать информацию, когда у них не получается (а правильно, нафига разбираться, если можно просто сказать, что фриланс фигня).
          0
          Хоть статей и много, начинающие их не читают. И увеличением количества статей ничего не изменишь. Начинающим и так много чего читать и учить приходится.
          Можно было бы изменить добавлением соответствующей дисциплины в ВУЗах, например, но в такое как-то слабо верится.
            –1
            у нас в ВУЗах до сих пор обучение ведется на устаревшей элементной базе, о каких таких прогрессивных методиках может идти речь? :)

            ИМХО, это опыт, как чужой так и свой, по другому как то не пролучается
          0
          Всё прекрасно, но не охвачен очень важный момент: взаимодействие в процессе работы. Здесь то и начинаются (особенно, когда работаете с новым фрилансером/заказчиком первый раз) все проблемы и конфликты, которые нужно уметь грамотно разрешать. Иначе проект может затянуться и не быть выполненным вообще.
            0
            Согласен, самое главное оставлено за рамками статьи. Плюс финансовые вопросы — их тоже лучше всего обговорить детально и ДО начала работы, включая этапы и способы оплаты.
              0
              Мне тут и так вменили в вину слишком большое количество информации :) То, что вы хотите видеть, еще на пару статей. Если интересно — могу написать, тем более — выходные.
                0
                Конечно хотим:) Пишите ещё! Это же крайне полезный опыт
          0
          а мне понравилась статья. хоть и обо всем сразу, но компактно и доступно.
          с одной стороны, это все очевидно, но порой, совершенно не понимаешь, как люди могут игнорировать прописные истины.
          по поводу «тыканья» прямо со знакомства тоже поддержу автора — раздражает, но стараюсь не заострять внимания, потому как после все равно переходим на ты :)
          единственное с чем не соглашусь — это по поводу объяснения, «что такое хтмл». были у меня случаи, когда из-за незнания менеджеров приходилось переделывать часть работы. не могу же я каждому заказчику в начале давать краткий теоретический курс.
          p.s. а однажды, вообще шикарный случай был. пришло время оплаты и я скинул менеджеру номер кошелька z… (wmz). менеджеру видать кроме я.денег ничего не показали и деньги ушли на чей-то яндекс.кошелек. а потом на меня вроде еще как и обиделись немного из-за того, что я не уточнил, что это был webmoney…
            0
            Не могу сказать, что рассказывать основы это плохо. Как правило, заказчик делает выбор тех или иных технологий на основании фазы луны и цвета козявок из носа. Даже я сам в некоторых вопросах веду себя точно так же. Так что дать аргументированную консультацию поможет и не делать изначально кривое по технологиям решение, и даст заказчику понимание того, что вы профессионал.

            По поводу перехода на ты — для меня это тоже нормальная ситуация, но не тогда, когда с этого прям начинают без предисловий…
            0
            По опыту могу сказать — самое главное — решить всё на берегу, составить ТЗ, договор, учесть все скользкие моменты, обязательно подписать и иметь каждому по копии. Дальше — фрилансер берет процент от оплаты, чтобы быть уверенным в том, что не останется с ненужным неоплаченным продуктом и передает его целиком только в случае оплаты и подписания актов выполненных работ, чтобы не стать рабом заказчика. Если объем работы большой, то лучше выполнять его по частям, а еще лучше с помощью гибких методологий типа SCRUM, чтобы корректировать график и получать ровно столько, сколько заслужил.

            Если всё документально закреплено, то остальное — вопрос личностных качеств, так что тут сложно что-то регламентировать. И самое важное — не давать себе послаблений вроде «он же мой друг/сват/брат/москвич/суровый уральский мужик, обойдемся пока и без техзадания и договора, на словах, на доверии», так как всегда может возникнуть непонимание и в таком случае каждый будет тянуть одеяло на себя. И тогда либо фрилансер может кинуть заказчика на результат, либо заказчик может кинуть фрилансера на деньги или на объем работы.
              +1
              У меня возникала еще такая проблемка с заказчиком, когда я первый раз выполнял работу как фрилансер и у меня еще не было репутации, то после выполнения работ заказчик не шел на закрытие контракта и выдачи оценки (feedback). Этот процесс затянулся и у меня долго не было оценки чтобы найти новый проект. Приходилось сидеть на багфиксинге или просто простаивать. У заказчика была такая отговорка — он никак не мог протестировать проект. Правда все деньги были уплачены и загвоздка была именно в оценке. Завершилось всё тем, что я сам разорвал контракт и уговорил заказчика поставить оценку. Это всё про oDesk.
                0
                Здесь еще и интересные мелочи есть. Например, очень понравилась идея с RSS-подписками
                  0
                  на зарубежных биржах есть возможность составить личную подписку по категориям и даже по ключевикам
                  0
                  Я не встречал еще ни разу ни одного фрилансера за которым не пришлось бы доделывать!
                    0
                    Прошу указать ссылки на другие части, было бы удобно переходить.

                    Only users with full accounts can post comments. Log in, please.