Comments 58
Как исполнитель, всегда работал без договоров и с оплатой по факту, хотя это и опаснее, но зато вызывало больше доверия у заказчиков, а кидал было видно уже после первых пяти минут обсуждения. За всё время работы кинули всего один раз, и то, кидалу удалось убедить (пусть и не совсем законными методами) оплатить заказ. За большие заказы, но без конкретного ТЗ брался только однажды, после чего зарёкся. Уж слишком много «хотелок» появляется в процессе работы. Заказчиков изучал не только по отзывам на бирже, но и искал о них информацию на других сайтах, использования в качестве поисковых запросов контактные данные.
Как-то фиксировали договоренности по проекту? Если да, то как? Я понимаю, что технические в ТЗ, но что насчет «процессуальных»? Возможно соглашусь, что слово «договор» в контексте данной статьи слишком «резкое» и стоит как-то переформулировать.
Что понимается под процессуальными? Ответственность сторон? Некоторые заказчики добавляли в ТЗ подобные пункты, например "-1% стоимости за каждый день просрочки", но зачастую все интересующие вопросы разрешались просто диалогом и закреплялись только в логах переписки, иногда выносились в ТЗ. Сроки и стоимость проекта очень редко значились в ТЗ, почти всегда они обсуждались при переписке и дальше неё не выносились. Кстати, юридически договор ведь может быть в устной форме, вот только не знаю, относился ли это к электронной переписке.
Забыл сказать о голосовом общении (совет №3). Я довольно плохо воспринимаю информацию на слух, в том смысле, что могу услышать какой то непонятный момент, задуматься над ним, и пропустить какую-нибудь важную информацию. Поэтому я старался по максимум избегать голосовых диалогов (а тем более договорённостей), и даже если такие случались, всегда просил отразить всё сказанное в ТЗ.
Забыл сказать о голосовом общении (совет №3). Я довольно плохо воспринимаю информацию на слух, в том смысле, что могу услышать какой то непонятный момент, задуматься над ним, и пропустить какую-нибудь важную информацию. Поэтому я старался по максимум избегать голосовых диалогов (а тем более договорённостей), и даже если такие случались, всегда просил отразить всё сказанное в ТЗ.
написаны 10 советов заказчику как снять с себя любую ответственность при работе с фрилансером
ну и пара вопросов по советам:
1) как технически заключать бумажный договор с фрилансером, чтобы это было просто, быстро и удобно?
2) какие преимущества дает договор в нашем «правовом» государстве? ну выиграли вы суд через год, еще полгода исполняли его, затратив кучу ресурсов и времени — в чем профит?
3) зачем вы пишите ТЗ, которые разные люди могут понимать по-разному?
4) вы сами часто работаете по факту в качестве исполнителя?
ну и пара вопросов по советам:
1) как технически заключать бумажный договор с фрилансером, чтобы это было просто, быстро и удобно?
2) какие преимущества дает договор в нашем «правовом» государстве? ну выиграли вы суд через год, еще полгода исполняли его, затратив кучу ресурсов и времени — в чем профит?
3) зачем вы пишите ТЗ, которые разные люди могут понимать по-разному?
4) вы сами часто работаете по факту в качестве исполнителя?
1) Мы все часто забываем про суть «договора»: для нас это стало просто некой бумажкой используемой юрлицами. Но ведь смысл в другом: на бумаге зафиксировать все основные договоренности о том как вы будете работать. Это может быть пол страницы А4, а может и 8 листом. Главное чтобы все понимали правила игры.
2) См. п. 1. Идеи идти в суд у нас никогда не возникало. Любой деловой человек должен банально следовать договоренностям, а чтобы их как-то сформулировать и нужен формальный договор.
3) Вы писали ТЗ, которое всеми понимается одинаково? Как вы это проверяете?:) Голосом?;) Язык наш неоднозначен и даже UML диаграммы могут быть двояко поняты. Если все-таки умеете писать однозначные ТЗ — то научите меня этому, пожалуйста.
4) Работал раньше — лет пять назад. Встречал и кидал и щедрых заказчиков — много повидал, так что представляю ситуацию и с другой стороны баррикад;)
2) См. п. 1. Идеи идти в суд у нас никогда не возникало. Любой деловой человек должен банально следовать договоренностям, а чтобы их как-то сформулировать и нужен формальный договор.
3) Вы писали ТЗ, которое всеми понимается одинаково? Как вы это проверяете?:) Голосом?;) Язык наш неоднозначен и даже UML диаграммы могут быть двояко поняты. Если все-таки умеете писать однозначные ТЗ — то научите меня этому, пожалуйста.
4) Работал раньше — лет пять назад. Встречал и кидал и щедрых заказчиков — много повидал, так что представляю ситуацию и с другой стороны баррикад;)
1-2) какие задачи тогда решает ваш «договор»? при грамотном исполнителе он оказывается ненужным (есть ТЗ), при кидале он не поможет
3) про ТЗ не скажу за всех, но лично в моей практике все как-то проще и однозначней. возможно дело в специфике моей деятельности. объяснять что-то обычно не требуется
4) сужу по себе, но я считаю, что без предоплаты работают только самые неквалифицированные и криворукие исполнители (опять же, возможно так только в моей сфере), у которых все равно нет никаких альтернатив по клиентам. а при работе с такими все ваши 9 оставшихся советов оказываются бесполезными
3) про ТЗ не скажу за всех, но лично в моей практике все как-то проще и однозначней. возможно дело в специфике моей деятельности. объяснять что-то обычно не требуется
4) сужу по себе, но я считаю, что без предоплаты работают только самые неквалифицированные и криворукие исполнители (опять же, возможно так только в моей сфере), у которых все равно нет никаких альтернатив по клиентам. а при работе с такими все ваши 9 оставшихся советов оказываются бесполезными
1-2) Задача «договора» обозначить правила игры. Когда и за что оплачивается, каковы сроки и условия их соблюдения, как и где ведется разработка/деплоймент. Если подобные «правила» ведутся где-то, то как данный «договор» называете?
3) А что за специфика деятельности? С исполнителями получается общаетесь только текстом?
4) Согласен. Но здесь дело в доверии. Если это серьезный исполнитель, то он умеет работать, понимает как обходить скользкие моменты, как управлять объемом работ и т.д. И если вы понимаете «серьезность исполнителя» то запросто: хоть полная предоплата:) Можно сказать, что в моем случае именно так и получилось: просмотрев профиль человека, пообщавшись в почте посчитал, что это серьезный исполнитель знающий свое дело.
3) А что за специфика деятельности? С исполнителями получается общаетесь только текстом?
4) Согласен. Но здесь дело в доверии. Если это серьезный исполнитель, то он умеет работать, понимает как обходить скользкие моменты, как управлять объемом работ и т.д. И если вы понимаете «серьезность исполнителя» то запросто: хоть полная предоплата:) Можно сказать, что в моем случае именно так и получилось: просмотрев профиль человека, пообщавшись в почте посчитал, что это серьезный исполнитель знающий свое дело.
> Меняя договор под пожелания исполнителя, помните: проект ваш, платите за него тоже вы, а значит удобно работать должно быть, в первую очередь, именно вам!
Ну-ну.
Ну-ну.
А что, по вашему, не верно в данном утверждении? Если исполнитель не готов работать по вашим правилам и вы с этим не happy, то может найти другого исполнителя? А если такого не находится, то это уже повод пересмотреть свой взгляд на мир: может быть слишком много хотите.
Подрабатываю на фрилансе, наверное, года 3. В основном заработать на интернет и телефон ну и что бы как-то разрядить рабочие будни. Т.е. пару тысяч в месяц. Т.е. мелкие задачи типа парсеров, правок и т.п. Но бывало и что то крупное.
Так вот всегда работаю с оплатой по факту, иначе лично у меня теряется интерес к работе, напрочь.
Кинули всего 2 раза, оба раза по 500 рублей.
Первый раз, 16-17 летний парень из Эстонии, которому надо было поставить на хостинг одну браузерную он-лайн игру.
Второй раз, человек из eventclick.ru, если верить их портфолио не шарашкина контора.
Если в первом случае было даже не обидно, то во втором случае я желаю им что бы их тоже кто кинул :)
Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день. Вот реально, если вы идёте на фриланс и ищите себе исполнителя, может быть вы сначала определитесь чего вы конкретно хотите?
Так вот всегда работаю с оплатой по факту, иначе лично у меня теряется интерес к работе, напрочь.
Кинули всего 2 раза, оба раза по 500 рублей.
Первый раз, 16-17 летний парень из Эстонии, которому надо было поставить на хостинг одну браузерную он-лайн игру.
Второй раз, человек из eventclick.ru, если верить их портфолио не шарашкина контора.
Если в первом случае было даже не обидно, то во втором случае я желаю им что бы их тоже кто кинул :)
Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день. Вот реально, если вы идёте на фриланс и ищите себе исполнителя, может быть вы сначала определитесь чего вы конкретно хотите?
Тоже работал раньше так, потом перешёл на 50% предоплаты. Хорошо показывает, готов ли человек сотрудничать или он чисто мозги пополоскать решил.
> Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день.
Таких зачастую видно сразу и можно вежливо посылать их. Если вам выносят мозги на весь день, тем более за 500 рублей, значит вы что-то неправильно делаете. Повысьте планку минимальной цены за заказ, количество неадекватов убавится.
> Т.е. мелкие задачи типа парсеров, правок и т.п.
Это неблагодарная работа, я считаю. Подчищать баги за другими.
Если походить отвественно к выбору заданий и отсеивать большую часть заказчиков, то доход будет тот же самый или больше и времени свободного больше будет и нервов целых тоже.
> Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день.
Таких зачастую видно сразу и можно вежливо посылать их. Если вам выносят мозги на весь день, тем более за 500 рублей, значит вы что-то неправильно делаете. Повысьте планку минимальной цены за заказ, количество неадекватов убавится.
> Т.е. мелкие задачи типа парсеров, правок и т.п.
Это неблагодарная работа, я считаю. Подчищать баги за другими.
Если походить отвественно к выбору заданий и отсеивать большую часть заказчиков, то доход будет тот же самый или больше и времени свободного больше будет и нервов целых тоже.
Таких зачастую видно сразу и можно вежливо посылать их. Если вам выносят мозги на весь день, тем более за 500 рублей, значит вы что-то неправильно делаете. Повысьте планку минимальной цены за заказ, количество неадекватов убавится.
К сожалению, не всегда, получается, определить с кем будут проблемы, а с кем нет, просто бывали разные случаи. Как то работал с девушкой, которая вначале казалась неблагонадёжной. В конечном итоге всё оказалось супер, и уже как-то временами, не часто, но от неё бывают маленькие заказы. Так что раз на раз не приходится.
Это неблагодарная работа, я считаю. Подчищать баги за другими.
Мне это нравится, я работаю 3 года один, а работая с чужими самописами, можно чего-нибудь интересное узнать.
Например, вот такую форму записи, в принципе банально и понятно, до сам бы я не додумался наверное до такого, что бы в 1 строчку и красиво:
$id = max(0, isset($_POST['id']) ? (int)$_POST['id'] : 0);А от написания парсеров я тащусь, это можно сказать, моё хобби небольшое.
Ну и цены, таксист в москве за полчаса берет 500р.
Ну, я сам из Питера. У меня сейчас цена, которую я считаю для себя комфортной — 500 рублей в час. Но не всегда получается такие заказы находить. Уж слишком большая конкуренция из СНГ и регионов. Либо просто такая у меня ниша на фрилансе.
А что за ниша? Вы упомянули парсеры. Мне кажется, в сложном парсинге веб сайтов мало конкуренции, не все осиливают.
500 рублей в час, в принципе, норм. Просто вы написали выше «а задачку в 500 рублей могут вынести мозг на весь день». День и час это разные вещи.
Вот пример, что описал выше, eventclick который. Там задача была спарсить товары с сайта кондиционеров с картинками — наименований не много, в районе одной тысячи(или пару сотен, уже не помню, но не суть).
Задача, в среднем, как понимаете, плёвая — час работы с общением, если клиент нормальный.
Вылилось это в квест игру на 4 часа.
Общение велось сначала на Фрилансиме, через комментарии к заказу( хотя свои контакты я всегда всем оставляю в первом же отклике). Я быстренько сделал работу, захожу ответить, а заказ выдаёт 403 ошибку(или что то похожее) — заказчик снял заказ с сайта. Я пишу в саппорт Фрилансима, объясняю суть проблемы. Они вошли в моё положение и выслали мне email с которого был зарегистрирован аккаунт заказчика(огромное им спасибо, кстати, и оперативно и помогли решить проблему).
Дальнейшее общение уже было по этому email. В конечном итоге, я выслал результат после пары мелких замечаний, после чего заказчик хотел что бы я ещё кое-что подправил, я отказал, мотивировав это словами. «заплатите за это, а там за отдельные деньги проговорим доп. работы». Заказчик спросил кошелёк и исчез :)
Задача, в среднем, как понимаете, плёвая — час работы с общением, если клиент нормальный.
Вылилось это в квест игру на 4 часа.
Общение велось сначала на Фрилансиме, через комментарии к заказу( хотя свои контакты я всегда всем оставляю в первом же отклике). Я быстренько сделал работу, захожу ответить, а заказ выдаёт 403 ошибку(или что то похожее) — заказчик снял заказ с сайта. Я пишу в саппорт Фрилансима, объясняю суть проблемы. Они вошли в моё положение и выслали мне email с которого был зарегистрирован аккаунт заказчика(огромное им спасибо, кстати, и оперативно и помогли решить проблему).
Дальнейшее общение уже было по этому email. В конечном итоге, я выслал результат после пары мелких замечаний, после чего заказчик хотел что бы я ещё кое-что подправил, я отказал, мотивировав это словами. «заплатите за это, а там за отдельные деньги проговорим доп. работы». Заказчик спросил кошелёк и исчез :)
Выберите узкий профиль по которму вы специлизируетесь, работайте в этом направлении, не ограничивайте себя только фриланс-сайтами. Ищите заказчиков и на других площадках. Сделайте себе сайт с описанием ваших услуг. Постепенно заказчики начнут к вам сами обращаться. Если хватататься за всё подряд, толку не будет.
Сложный парсинг это какой? Яндекс.Маркет, avito, auto.ru или что?
Я обычно всегда откликаюсь на мелкие правки в php самописах, парсеры и т.п. Вот тут, по опыту, если ответил не в течении пару часов после размещения заказа, шанс что тебе хотя бы Заказчик ответил — мал. Конкуренция огромная — видимо ни я один тащусь от написания парсеров :)
Я обычно всегда откликаюсь на мелкие правки в php самописах, парсеры и т.п. Вот тут, по опыту, если ответил не в течении пару часов после размещения заказа, шанс что тебе хотя бы Заказчик ответил — мал. Конкуренция огромная — видимо ни я один тащусь от написания парсеров :)
Сложный парсинг — парсинг любого сайта с большим количеством страниц, либо объектов с большим количеством свойств, либо сайта со сложной структурой. Например, кинопоиск, амазон или те сайты, что вы озвучили.
По парсингу со временем у меня сложились правила по которым я отсеиваю заказы:
* я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты
* я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент
Эти два пункта позволяют сильно сэкономить время и нервы. Ну и ещё я не тусуюсь на сайты типа фрилансим, заказчики сами обращаются, а я уже выбираю, с кем мне интересно работать.
По парсингу со временем у меня сложились правила по которым я отсеиваю заказы:
* я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты
* я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент
Эти два пункта позволяют сильно сэкономить время и нервы. Ну и ещё я не тусуюсь на сайты типа фрилансим, заказчики сами обращаются, а я уже выбираю, с кем мне интересно работать.
Ну кол-во страниц всё же, по моему мнению, почти не влияет на сложность парсинга. А вот свойства и сложная структура и самое интересное — защита — это да согласен. Но таких задач я не видел в свободном доступе. Только по знакомству перепала задачка Яндекс.Маркет парсить, вот это интересно было.
Тут я вас понимаю, да и хороший код отдавать за 500 рублей временами обидно.
В этом я с вами солидарен!
* я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты
Тут я вас понимаю, да и хороший код отдавать за 500 рублей временами обидно.
* я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент
В этом я с вами солидарен!
Количество страниц влияет самым прямым образом. Спарсить сайт на 50к страниц и на 500к это разные задачи, и тем более на несколько миллионов страниц и больше.
Чем больше страниц, тем:
* дольше длится парсинг
* находится больше специальных случаев, которые вы не предусмотрели
* больше шансов схватить какой-нибудь бан
* нужно больше cpu/IOPS/ram чтобы обрабатывать и хранить данные
* в случае ошибки, которые случаются часто, повторно обрабатывать большее количество страниц
Чем больше страниц, тем:
* дольше длится парсинг
* находится больше специальных случаев, которые вы не предусмотрели
* больше шансов схватить какой-нибудь бан
* нужно больше cpu/IOPS/ram чтобы обрабатывать и хранить данные
* в случае ошибки, которые случаются часто, повторно обрабатывать большее количество страниц
> Не платите авансом исполнителю, если вы с ним никогда до этого не работали.
Не работайте с заказчиком без предоплаты, если вы с ним никогда не работали.
> Торгуйтесь с кандидатами!
Понимать, что и почему сколько стоит — без проблем. А вот если начинаются предложения вида «давайте за эту задачу не 5000 рублей, а 4500», то заказчик всеми правдами и неправдами отправляется лесом. Проблем потом не оберешься.
Не работайте с заказчиком без предоплаты, если вы с ним никогда не работали.
> Торгуйтесь с кандидатами!
Понимать, что и почему сколько стоит — без проблем. А вот если начинаются предложения вида «давайте за эту задачу не 5000 рублей, а 4500», то заказчик всеми правдами и неправдами отправляется лесом. Проблем потом не оберешься.
5. Оплачивайте по факту
Я рекомендую делать так. Если с человеком дел не имели вообще, то берите с него хотя бы процентов 5 предоплаты, это конечно вас особо не порадует если вас киданут, но вы хотя бы отметете тех, кто может скинуть заказ сразу нескольким исполнителям, а также сократите шанс на появление новых пунктов, которые якобы маленькие и их надо сделать за даром.
А самое главное общайтесь с человеком по скайпу голосом, так можно оценить человека, а не надежные личности часто отсеиваются на предложение побеседовать голосом.
Полностью согласен! Если заказчик новый — с ним ещё не было опыта работы, пусть у него будут даже афигительный рейтинг и отзывы, я как исполнитель стараюсь брать хотя бы минимальную предоплату — заказчики тоже могут кинуть. А так заказчик после предоплаты становится очень внимательным и очень доходчиво объясняет чего хочет :) А ещё большие проекты, делим на части, и после завершения оплачивается сделанная часть.
Не 5, а 50. Если ему не нравится, есть и другие заказчики более сговорчивые.
Если задачка небольшая, то можно и не брать предоплату. Не заплатит, невелика потеря.
№10. Торгуйтесь с кандидатами!
Очень ИМХО, но — никогда не торгуюсь. У меня обычно есть два варианта.
Либо заказчик называет цифру которую он готов платить и я соглашаюсь, или нет.
Либо я называю свою цену — после этого заказчик говорит согласен он работать, или нет.
Если со стороны заказчика начинается торг — я обычно отказываюсь от такого проекта.
Да еще один момент. Сразу оговаривается то, что в случае дополнительных работ (например в ТЗ что-то не указали, или имели ввиду одно, а написали другое, и т.п.) они оцениваются отдельно. А в случае возникновения багов, или недоработок — исправления вносятся за мой счет.
Это еще раз повторюсь жуткое ИМХО, но как показала практика — очень способствует правильной фильтрации проектов и благополучному сотрудничеству в дальнейшем.
Очень ИМХО, но — никогда не торгуюсь. У меня обычно есть два варианта.
Либо заказчик называет цифру которую он готов платить и я соглашаюсь, или нет.
Либо я называю свою цену — после этого заказчик говорит согласен он работать, или нет.
Если со стороны заказчика начинается торг — я обычно отказываюсь от такого проекта.
Да еще один момент. Сразу оговаривается то, что в случае дополнительных работ (например в ТЗ что-то не указали, или имели ввиду одно, а написали другое, и т.п.) они оцениваются отдельно. А в случае возникновения багов, или недоработок — исправления вносятся за мой счет.
Это еще раз повторюсь жуткое ИМХО, но как показала практика — очень способствует правильной фильтрации проектов и благополучному сотрудничеству в дальнейшем.
Напомнило мне короткий диалог с одним из зарубежных заказчиков на крупный проект.
— Как насчет 25% скидки? Мы считаем, что она обоснована, так как проект крупный и тебе привалит куча бабла
— Отличная идея! И у меня есть контр-предложение: я делаю функционала меньше на 30%, потому что, считаю, что вы им никогда не воспользуетесь.
Как только я вижу людей, которые пришли покупать Феррари по цене старых Жигулей — бегу сразу. Вменяемые говорят просто: «Дорого, я пошел в другое место!» или «Начинаем работать!».
Насчет ТЗ у меня все просто: нет ТЗ — работаем на почасовой ставке. «Сделать как там» я не понимаю, поэтому все равно почасовка. «Сделай мне Фейсбук, там работы на неделю, знаю», выкатываю расчеты на миллиарды долларов с обоснованием почему так. Товарищей, которые говорят, «Хорошо, почасовка, только ты закончишь это за неделю» вношу в личный черный список.
— Как насчет 25% скидки? Мы считаем, что она обоснована, так как проект крупный и тебе привалит куча бабла
— Отличная идея! И у меня есть контр-предложение: я делаю функционала меньше на 30%, потому что, считаю, что вы им никогда не воспользуетесь.
Как только я вижу людей, которые пришли покупать Феррари по цене старых Жигулей — бегу сразу. Вменяемые говорят просто: «Дорого, я пошел в другое место!» или «Начинаем работать!».
Насчет ТЗ у меня все просто: нет ТЗ — работаем на почасовой ставке. «Сделать как там» я не понимаю, поэтому все равно почасовка. «Сделай мне Фейсбук, там работы на неделю, знаю», выкатываю расчеты на миллиарды долларов с обоснованием почему так. Товарищей, которые говорят, «Хорошо, почасовка, только ты закончишь это за неделю» вношу в личный черный список.
вы абсолютный профан в веб-разработке и управления веб-проектами
Поскольку мне повезло лично работать с DbLogs в одном проекте, могу заверить, что он исключительно грамотный и опытный профессионал. В том числе и в озвученных вопросах.
Многих описанных автором статьи проблем можно было избежать, если бы использовался не традиционный «водопад» с написанием подробнейшего ТЗ до начала разработки, а что-то более гибкое (Agile).
Я бы предложил скрам-процесс, так как в нем есть итерации. Итак, создаётся список задач (бэклог, backlog), который сортируется по важности — важное сверху. Для этого можно использовать разные инструменты начиная с канбан-досок типа trello.com и заканчивая Jira + GreenHopper. Каждая задача должна иметь критерии готовности. Если все критерии выполняются, то задача считается выполненной. Исполнитель даёт оценку (это может быть время или деньги) каждой задаче. Если он не может оценить — значит задача не ясна (нужно встретится и обсудить), либо слишком большая, — разбивать на части.
Спринты. Я бы предложил использовать одно-недельные спринты, чтобы сохранить динамику. В конце спринта — демо, где разработчик показывает что сделано, а заказчик принимает. Показывается только то, что работает на 100%. Если не работает или на демо вылезли ошибки — на переделку.
Оплачиваются только принятые заказчиком задачи. Оплата сразу после демо. Таким образом, для испольнителя — отработал спринт, сдал работу, получил оплату.
Заказчик во время спринта готовит задачи для следующего спринта, то есть на 1 неделю вперёд. Часть незавершённых задач переедет в след. принт или будет отложена, если это не важные задачи. Помните, что нужно начинать с важного, — таким образом можно избежать того, что вы потратите 80% бюджета на 20% видимой работы.
Это Agile и не нужно думать, что для этих процессов нужна большая команда разработчиков или большие проекты. Процесс нужно подстраивать под себя.
Если что-то пошло не так, что все потеряют только 1 неделю. Через неделю задачи и требования могут совершенно поменяться и заказчику хорошо бы иметь возможность их тоже реализовать. Но скорее всего, такой гибкий подход будет стоить вам дороже. Тут нужно определиться, что важнее — получить то, что вы ходите или уложиться в выделенный бюджет и сроки. Например, мой ремонт превышает ожидаемые расходы и затраты времени в 6 раз, но я получу то, что мне нравится. В процессе открылись разные нехорошие моменты и их нужно исправлять и от этого не уйти.
По-поводу метатегов и URL в Drupal по $200, то вас просто хотели обмануть. Это решается установкой бесплатных модулей. Даже настраивать ничего не нужно. Советую вникать в предметную область, иначе всегда будете переплачивать. Никто не запрещает задать вопросы на drupal.ru или drupal.ua.
Я бы предложил скрам-процесс, так как в нем есть итерации. Итак, создаётся список задач (бэклог, backlog), который сортируется по важности — важное сверху. Для этого можно использовать разные инструменты начиная с канбан-досок типа trello.com и заканчивая Jira + GreenHopper. Каждая задача должна иметь критерии готовности. Если все критерии выполняются, то задача считается выполненной. Исполнитель даёт оценку (это может быть время или деньги) каждой задаче. Если он не может оценить — значит задача не ясна (нужно встретится и обсудить), либо слишком большая, — разбивать на части.
Спринты. Я бы предложил использовать одно-недельные спринты, чтобы сохранить динамику. В конце спринта — демо, где разработчик показывает что сделано, а заказчик принимает. Показывается только то, что работает на 100%. Если не работает или на демо вылезли ошибки — на переделку.
Оплачиваются только принятые заказчиком задачи. Оплата сразу после демо. Таким образом, для испольнителя — отработал спринт, сдал работу, получил оплату.
Заказчик во время спринта готовит задачи для следующего спринта, то есть на 1 неделю вперёд. Часть незавершённых задач переедет в след. принт или будет отложена, если это не важные задачи. Помните, что нужно начинать с важного, — таким образом можно избежать того, что вы потратите 80% бюджета на 20% видимой работы.
Это Agile и не нужно думать, что для этих процессов нужна большая команда разработчиков или большие проекты. Процесс нужно подстраивать под себя.
Если что-то пошло не так, что все потеряют только 1 неделю. Через неделю задачи и требования могут совершенно поменяться и заказчику хорошо бы иметь возможность их тоже реализовать. Но скорее всего, такой гибкий подход будет стоить вам дороже. Тут нужно определиться, что важнее — получить то, что вы ходите или уложиться в выделенный бюджет и сроки. Например, мой ремонт превышает ожидаемые расходы и затраты времени в 6 раз, но я получу то, что мне нравится. В процессе открылись разные нехорошие моменты и их нужно исправлять и от этого не уйти.
По-поводу метатегов и URL в Drupal по $200, то вас просто хотели обмануть. Это решается установкой бесплатных модулей. Даже настраивать ничего не нужно. Советую вникать в предметную область, иначе всегда будете переплачивать. Никто не запрещает задать вопросы на drupal.ru или drupal.ua.
Владислав, все верно пишите. Но есть определенные проблемы:
1) Исполнитель должен согласиться на работу по agile. Не все знают и умеют работать по agile.
2) Сразу подразумевается почасовая оплата, а не фиксед. Не всегда это приемлемо.
3) Agile и почасовая оплата требует доверия: если исполнитель говорит, что сделает это за час, то вы ему должны верить.
Все данные пункты у меня не работали… Ну вот как можно поверить, что развернуть дамп на сервере стоит 2 часа рабочего времени(я сам разворачивал его дампы за 10 мин максимум)?:) А ведь были именно такие утверждения.
1) Исполнитель должен согласиться на работу по agile. Не все знают и умеют работать по agile.
2) Сразу подразумевается почасовая оплата, а не фиксед. Не всегда это приемлемо.
3) Agile и почасовая оплата требует доверия: если исполнитель говорит, что сделает это за час, то вы ему должны верить.
Все данные пункты у меня не работали… Ну вот как можно поверить, что развернуть дамп на сервере стоит 2 часа рабочего времени(я сам разворачивал его дампы за 10 мин максимум)?:) А ведь были именно такие утверждения.
Agile != почасовая оплата. Мало того, почасовая оплата не имеет вообще никакого отношения к Agile, хотя многие считают, что если у них почасовка, то это аджайл — увы это не так. У вас agile-процесс, если выполняются 4 условия, которые описаны в Agile-манифесте (http://agilemanifesto.org/iso/ru/). Обратите внимание, там нет ни слова про скрам, про канбан, про инструменты, про почасовую оплату!
Исполнитель действительно должен согласиться работать по такой схеме. Но мне кажется, что закачик имеет право именно диктовать условия, поэтому не стоит себя ограничивать. Вы же не требуете от него пройти курсы скрам-мастеров за 1000 долларов?! От исполнителя требуется сдавать работу в конце спринта и согласиться на то, что оплачено будет только то, что сделано и работает на 100%.
Да! Важный момент — он исполнителя требуется выполнять работу в порядке приоритетов выставленных заказчиком — это ключевой момент, который защищает заказчика от выполнения простой и незначительной работы в начале и сложного в конце. Откладывание сложного на конец проекта грозит срывом сроков и исполнитель может просто свалить, чтобы не возиться со сложным. Поэтому начинать нужно с самых главных «килллер»-фич проекта, а менее важное откладывать на конец. Таким образом, учитывая, что проекты почти всегда завершаются не вовремя, то к запланированному вами сроку у вас будет 1-2-3 важных фичи проекта и можно будет уже стартовать, походу доделывая второстепенные детали. Помните, что лучше раньше выйти на рынок с сырым продуктом, чем вылизать весь код, дизайн, архитектуру и опоздать с выходом.
По поводу оплаты (в том числе почасовой). Я писал, что исполнитель дает оценку каждой задачи. Это может быть оценка в деньгах — мы фиксируем деньги, но прим этом не фиксируем время. Исполнитель может тратить сколько угодно времени на задачу, но оплата будет одинаковая. Это может быть время — мы фиксируем срок выполнения и договариваемся про почасовую оплату. Превысил свой эстимейт — оплаты выше не будет. Вроде бы все просто.
Чтобы понять как это делается нужно помнить, что у любой задачи есть 4 параметра:
1. Срок (время) — оценку даёт исполнитель и затем обсуждает с заказчиком. Торг уместен!..
2. Объем работы (мы фиксируем объем работы, давая четкие критерии готовности задачи).
3. Стоимость (деньги) — часто зависит от времени, но не обязательно — могут быть задачи с фиксированной ценой. Исполнитель может давать оценку задачи и в деньгах, что тоже позже обсуждается с заказчиком.
4. Качество. Тут все очень сложно, но в agile подразумевается наивысшее качество и поэтому обычно даже не обсуждается. То есть, если нужно покрытие проекта тестами (а эта фича не имеет никакой бизнес-стоимости в глазах заказчика), то это делается по-умолчанию. Кроме того, никто не запрещает зафиксировать требования к качеству в критериях готовности.
Таки образом нужно зафиксировать как можно больше прараметров, чтобы избежать неприятных сюрпризов в конце проекта, но обычно один оставляется не зафиксированным, чтобы иметь свободу.
По поводу дампов — это технические задачи и вам, как заказчику не нужно их оплачивать и даже их обсуждать. Вам нужно платить за бизнес-фичи. Как только эта работа перестанет отдельно оплачиваться, — исполнитель найдёт способ сделать это быстрее. У меня дампы на 1.5 гига действительно разворачиваются минут 30.
Исполнитель действительно должен согласиться работать по такой схеме. Но мне кажется, что закачик имеет право именно диктовать условия, поэтому не стоит себя ограничивать. Вы же не требуете от него пройти курсы скрам-мастеров за 1000 долларов?! От исполнителя требуется сдавать работу в конце спринта и согласиться на то, что оплачено будет только то, что сделано и работает на 100%.
Да! Важный момент — он исполнителя требуется выполнять работу в порядке приоритетов выставленных заказчиком — это ключевой момент, который защищает заказчика от выполнения простой и незначительной работы в начале и сложного в конце. Откладывание сложного на конец проекта грозит срывом сроков и исполнитель может просто свалить, чтобы не возиться со сложным. Поэтому начинать нужно с самых главных «килллер»-фич проекта, а менее важное откладывать на конец. Таким образом, учитывая, что проекты почти всегда завершаются не вовремя, то к запланированному вами сроку у вас будет 1-2-3 важных фичи проекта и можно будет уже стартовать, походу доделывая второстепенные детали. Помните, что лучше раньше выйти на рынок с сырым продуктом, чем вылизать весь код, дизайн, архитектуру и опоздать с выходом.
По поводу оплаты (в том числе почасовой). Я писал, что исполнитель дает оценку каждой задачи. Это может быть оценка в деньгах — мы фиксируем деньги, но прим этом не фиксируем время. Исполнитель может тратить сколько угодно времени на задачу, но оплата будет одинаковая. Это может быть время — мы фиксируем срок выполнения и договариваемся про почасовую оплату. Превысил свой эстимейт — оплаты выше не будет. Вроде бы все просто.
Чтобы понять как это делается нужно помнить, что у любой задачи есть 4 параметра:
1. Срок (время) — оценку даёт исполнитель и затем обсуждает с заказчиком. Торг уместен!..
2. Объем работы (мы фиксируем объем работы, давая четкие критерии готовности задачи).
3. Стоимость (деньги) — часто зависит от времени, но не обязательно — могут быть задачи с фиксированной ценой. Исполнитель может давать оценку задачи и в деньгах, что тоже позже обсуждается с заказчиком.
4. Качество. Тут все очень сложно, но в agile подразумевается наивысшее качество и поэтому обычно даже не обсуждается. То есть, если нужно покрытие проекта тестами (а эта фича не имеет никакой бизнес-стоимости в глазах заказчика), то это делается по-умолчанию. Кроме того, никто не запрещает зафиксировать требования к качеству в критериях готовности.
Таки образом нужно зафиксировать как можно больше прараметров, чтобы избежать неприятных сюрпризов в конце проекта, но обычно один оставляется не зафиксированным, чтобы иметь свободу.
По поводу дампов — это технические задачи и вам, как заказчику не нужно их оплачивать и даже их обсуждать. Вам нужно платить за бизнес-фичи. Как только эта работа перестанет отдельно оплачиваться, — исполнитель найдёт способ сделать это быстрее. У меня дампы на 1.5 гига действительно разворачиваются минут 30.
А вы не могли бы описать ваше понимание дампов, заранее спасибо.
Со всем согласен, но опять есть «но»:) Вы сами пишете, что оценивается каждая задача в отдельности. И это не так уж важно: оценивается в часах (а потом конвертируется в деньги), либо сразу в деньгах. Но для мелких и средних задач (до 100 m/d) хочется видеть стоимость сразу: не занимаясь декомпозицией на подзадачи. Да и как показала практика: путем дробления задачи можно устремить стоимость проекта далеко к небесам.
Ну так дробите без фанатизма. По тем же дампам из вашего примера — это вообще не задача, вернее часть другой задачи но никак не самостоятельная (если это не база процессинга на терабайты данных с кучей нюансов).
Понятно что можно написать задачи:
1) Захожу на сервер по ssh — 20 центов
2) Заворачиваю базу в дамп — 1$ (1цент — таблица)
3) Переношу дамп на новый сервер…
…
но это согласитесь дебилизм.
Задача должна обладать S.M.A.R.T. критериями, тогда и раздувать не выйдет.
Понятно что можно написать задачи:
1) Захожу на сервер по ssh — 20 центов
2) Заворачиваю базу в дамп — 1$ (1цент — таблица)
3) Переношу дамп на новый сервер…
…
но это согласитесь дебилизм.
Задача должна обладать S.M.A.R.T. критериями, тогда и раздувать не выйдет.
Согласен с RicoX. Про S.M.A.R.T. забыл упомянуть. Задача должна быть самостоятельной фичей проекта, которая имеет для заказчика какую-то бизнес-ценность. Например, рефакторинг кода такой ценности не имеет, а значит о быть отдельной задачей не должен. Но иногда это может быть часть реализации новой фичи или улучшения, потому что иначе реализовать не получится — старый код ограничивает. В этом случае рефакторинг должен учесть разрабочик, когда оценивает задачу — это его ответственность, но лучше это проговорить в самом начале, потому что для многих это будет неочевидно.
У меня дамп — это дамп базы данных, который я беру с продакшена для разработки, чтобы всегда работать с данными максимально близкими к боевым. Там очень-очень много контента, около 650 таблиц, вес примерно 1.5 гига. Часть контента я удаляю, чтобы уменьшить размер — вот этот процесс и занимает около 30 минут. А импорт подготовленного дампа — пара минут, наверное, — не засекал, потому что это делает скрипт пока я задание читаю…
У меня дамп — это дамп базы данных, который я беру с продакшена для разработки, чтобы всегда работать с данными максимально близкими к боевым. Там очень-очень много контента, около 650 таблиц, вес примерно 1.5 гига. Часть контента я удаляю, чтобы уменьшить размер — вот этот процесс и занимает около 30 минут. А импорт подготовленного дампа — пара минут, наверное, — не засекал, потому что это делает скрипт пока я задание читаю…
Работаю в IT уже более 12 лет.
Кем Вы работаете?
По большинству пунктов соглашусь, кроме пожалуй 10.
Когда со мной, как с исполнителем начинают торговаться, я сразу прикидываю какую часть из своей работы мне придется выкинуть, чтоб мне заказ оставался интересным, потом понимаю что если выкинуть нужную часть, у проекта будут проблемы в дальнейшем и отказываюсь. По опыту самые «геморройные» проекты были те, где заказчики активно торговались, зарекся по таким работать. Назначая цену на fixed price, я, как исполнитель, в уме прикидываю сколько часов я на это потрачу +20% времени на нестыковки типа: забыли пароль от сервера, а админ помер. Снижать цену — это снижать свой рейт, а зачем если хватает тех, кто работает по такому, как я назвал.
По 5 пункту вопрос спорный, от продолжительности проекта зависит, если на пару дней, то можно и по факту сдачи оплату брать, а если на пару месяцев фултайма, тут только дробить на отдельные части и по ним производить расчет. В любом случае нужны четкие критерии сдачи-принятия работы или ее части.
Когда со мной, как с исполнителем начинают торговаться, я сразу прикидываю какую часть из своей работы мне придется выкинуть, чтоб мне заказ оставался интересным, потом понимаю что если выкинуть нужную часть, у проекта будут проблемы в дальнейшем и отказываюсь. По опыту самые «геморройные» проекты были те, где заказчики активно торговались, зарекся по таким работать. Назначая цену на fixed price, я, как исполнитель, в уме прикидываю сколько часов я на это потрачу +20% времени на нестыковки типа: забыли пароль от сервера, а админ помер. Снижать цену — это снижать свой рейт, а зачем если хватает тех, кто работает по такому, как я назвал.
По 5 пункту вопрос спорный, от продолжительности проекта зависит, если на пару дней, то можно и по факту сдачи оплату брать, а если на пару месяцев фултайма, тут только дробить на отдельные части и по ним производить расчет. В любом случае нужны четкие критерии сдачи-принятия работы или ее части.
Насчет 10 пункта, пожалуй, соглашусь. Попробую переформулировать в самой статье, но суть 10 пункта в том, чтобы обе стороны понимали структуру того что надо сделать и саму структуру оплаты.
Кстати, интересный момент: в мое случае под конец уже сам исполнитель начал торговаться «вот это +100$», и т.п. (Причем за вещи, которые обговаривались в самом начале). Но суть не совсем в этом, а в том, что я понял, что если раньше я прикидывал бонус исполнителю, если все будет хорошо и т.п., а его «торгашество» обозлило меня и тут уже я сам пошел на принцип. Так что согласен: «торговаться» подчас не стоит.
Касательно пятого пункта: сам исполнитель сказал, что через 3 недели будет все готово — прошло уже 3 месяца. Транши в начале платил исправно каждую неделю.
Кстати, интересный момент: в мое случае под конец уже сам исполнитель начал торговаться «вот это +100$», и т.п. (Причем за вещи, которые обговаривались в самом начале). Но суть не совсем в этом, а в том, что я понял, что если раньше я прикидывал бонус исполнителю, если все будет хорошо и т.п., а его «торгашество» обозлило меня и тут уже я сам пошел на принцип. Так что согласен: «торговаться» подчас не стоит.
Касательно пятого пункта: сам исполнитель сказал, что через 3 недели будет все готово — прошло уже 3 месяца. Транши в начале платил исправно каждую неделю.
В этом случае политика исполнителя скорее была направлена не на то чтоб сделать проект, а на то чтоб поругаться с вами и уйти обиженным, хлопнув дверью и просто не доделывать тот фронт работ, что он взвалил на себя. При таком перерасходе времени видно что исполнитель не компетентен в той работе, за которую взялся, при оценке небольшого проекта можно ошибиться в 2 раза (хотя на сроке 3 недели это должен быть конкретный форс-мажор), но не более того. Однозначно нужно прощаться.
Да, как заказчик, торгующегося исполнителя тоже шлю лесом.
С большим удовольствием прочел вашу статью. Когда стал писать комментарий, понял, что он вырастает в отдельный пост.
Довел до ума и разместил вот тут: habrahabr.ru/post/192502/. Буду рад если удостоите вниманием.
Довел до ума и разместил вот тут: habrahabr.ru/post/192502/. Буду рад если удостоите вниманием.
Хорошие советы, если бы не пункт 10. Т.е. вы хотите себя максимально обезопасить и это нормально. Но работать с вами становится сложнее и дороже. Поэтому если вы готовы за проект заплатить 2-3 стандартные суммы, то нет проблем. А если вы хотите навесить все свои пункты за обычную оплату, а потом еще и поторговаться, то… хороших специалистов вы не привлечете — у них и так работы много. А найдете скорее всего голодного студент а готового на все лишь бы получить проект, но проблем в итоге вы получите еще больше.
Обоснуйте, пожалуйста, почему «сложнее и дороже»? Разве четкость в ТЗ и четкость во взаимоотношениях приводит к этой сложности и дороговизне? Имхо, в среднем, как раз экономит, так как позволяет спорные ситуации решать очень быстро.
Чёткость, да. Но как вы и сами написали, даже самое чёткое ТЗ может быть понято как угодно. Значит, у вас будет обсуждение каждого пункта каждой задачи в проекте. Причём не только перед выполнением, но и в процессе, и даже по окончании.
Проект или задача стоит X денег и требует Y часов времени.
Обсуждение ТЗ с исполнителем это тоже время и работа над проектом, переписка, скайп, общение по телефону — это всё, по хорошему, тоже должно оплачиваться, то есть в калькуляции должна быть строка типа «Обсуждение и уточнение задачи», если её там нет, то либо исполнитель уже заложил это в рейт (x2, x3, т.к. обсуждение может быть очень долгим), либо будет настаивать на пересмотре стоимости.
Ещё проще: За ваши деньги — любой каприз, но каждый дополнительный каприз или хотелка это дополнительные деньги.
Проект или задача стоит X денег и требует Y часов времени.
Обсуждение ТЗ с исполнителем это тоже время и работа над проектом, переписка, скайп, общение по телефону — это всё, по хорошему, тоже должно оплачиваться, то есть в калькуляции должна быть строка типа «Обсуждение и уточнение задачи», если её там нет, то либо исполнитель уже заложил это в рейт (x2, x3, т.к. обсуждение может быть очень долгим), либо будет настаивать на пересмотре стоимости.
Ещё проще: За ваши деньги — любой каприз, но каждый дополнительный каприз или хотелка это дополнительные деньги.
UFO just landed and posted this here
В подавляющем большинстве случаев моральную ответственность за проект несет именно заказчик. Он должен проявлять дотошность в выборе исполнителя. Это ЕГО проект и он кровно в нем заинтересован! И никто более. Для исполнителя, в случае его чистоплотности — это всегда будет только работой и не более того, а риски — как временные так и финансовые несет заказчик. Вернуть потом затраченные финансы с исполнителя крайне проблематично.
Тут про подобное, но в другом разрезе событий http://habrahabr.ru/post/179731/
Тут про подобное, но в другом разрезе событий http://habrahabr.ru/post/179731/
Sign up to leave a comment.
10 советов для заказчика во фрилансе