Comments 44
Интересная статья. Спасибо автору! Было над чем задуматься!
Очень много зависит от возможности заказчика объяснить то, что он хочет получить. Я склоняюсь к мнению, что заказы среднего уровня чаще вызывают сложности.
Роберт Чалдини «Психология влияния». Рекомендую. Много интересных примеров на основе контраста. Книга пригодится продажникам, да и просто увлекательное чтиво. Много нового узнал.
Однако на большое количество маленьких заказов должен быть больше overhead на поиск заказов, согласование — всякие накладные расходы…
Чтобы согласовать большой заказ надо еще больше времени. Причем в результате может быть даже не пропорционально больше — большой проект требует времени на вникание, на понимание, там могут быть пересекающиеся вещи, все это может дать как раз тот overhead, но в другую сторону. С мелкой задачей обычно все понятно. Именно по этому крупные проекты и делят на небольшие задачи :).
Ну и одно дело обсуждать большой проект несколько дней и потом не сойтись в цене, а другое дело — потерять 20 минут на обсуждение небольшого. Это в раздел рисков, наверное.
Ну и одно дело обсуждать большой проект несколько дней и потом не сойтись в цене, а другое дело — потерять 20 минут на обсуждение небольшого. Это в раздел рисков, наверное.
В большом проекте все гораздо критичнее с согласованием. Потому как заложено сразу очень многое и ошибка / неточность на многих этапах может привести к значительным изменениям бюджета. Поэтому стараются продумать все как можно тщательнее.
На небольших этапах ошибки могут часто простить вовсе и предложить выполнить задачу по-другому за дополнительные деньги.
На небольших этапах ошибки могут часто простить вовсе и предложить выполнить задачу по-другому за дополнительные деньги.
Вы отличную тему затронули. Я очень часто наблюдаю, как многие заказчики пытаются довести свой проект до конца, что-то изменить или доработать. И очень мало людей берется за такие работы. А порой там за 5-10 минут работы клиент свободно может отдать 1000 руб. Более того, есть достаточно большое количество заказчиков, которые постоянно что-то дорабатывают.
Я какое-то время занимался такими небольшими работами и все отлично получалось.
Кстати, с накладными расходами не совсем соглашусь. С мелкими заказами заказчики порой гораздо проще подходят к делу. Они не боятся потерять небольшую сумму, поэтому легче доверяют ее разработчику. Всякими согласованиями, оформлениями тоже периодически пренебрегают.
Я какое-то время занимался такими небольшими работами и все отлично получалось.
Кстати, с накладными расходами не совсем соглашусь. С мелкими заказами заказчики порой гораздо проще подходят к делу. Они не боятся потерять небольшую сумму, поэтому легче доверяют ее разработчику. Всякими согласованиями, оформлениями тоже периодически пренебрегают.
Тут могут быть нюансы, конечно. Хотя я считаю, что исполнитель заинтересован в корректной постановке задания ничуть не меньше заказчика и исполнитель может и должен уточнять задание — иначе не избежать проблем. Если смотреть с этой точки зрения, то отношение заказчика к небольшому проекту не так значительно.
Разумеется уточнения важны. Но чем проще проект, тем проще подходят к оформлению задачи. Представить большой проект без должного оформления сложно. А на простых задачах порой все вообще решается устно.
Представить большой проект без должного оформления сложно.
Если бы все так и было :(. К сожалению часто у заказчика есть только деньги и «хочу». Причем сумма ограниченная, а объем «хочу» — нет.
На небольшой задаче все равно меньше рисков и проблем. Даже если надо будет полностью переделать с нуля — это не тоже самое, что смена платформы в конце реализации крупного проекта.
часто и денег-то нет, а звонят просто чтобы поинтересоваться «почему так дорого» ithappens.ru/story/6448
Насчет заказчика, который отказался от перевода на цмс в пользу вас — тут играет роль не только общая сумма, которую он потратил, но и еще несколько вещей:
1. Заплатить в течение месяца 10 микроплатежей проще, чем 1 большой. Особенно если кампания небольшая, и у нее все деньги в обороте а не лежат на счетах.
2. Время заказчика на освоение вашей цмс и самостоятельное внесение правок стоит дороже, чем ваша цена — потому что заказчик лучше быстро вам объяснит, что надо, и будет дальше заниматься своей основной работой
3. Интересный момент — если бы вы сразу по собственной инициативе бесплатно перевели его на цмс то впоследствии могли бы заработать еще больше, ведь, хотя вы сначала и сработали в убыток, в последствии себестоимость каждой правки (временные затраты) были бы для вас практически нулевыми, а клиент все равно был бы к вам привязан и вы могли бы назначать цены как будто правите хтмл.
1. Заплатить в течение месяца 10 микроплатежей проще, чем 1 большой. Особенно если кампания небольшая, и у нее все деньги в обороте а не лежат на счетах.
2. Время заказчика на освоение вашей цмс и самостоятельное внесение правок стоит дороже, чем ваша цена — потому что заказчик лучше быстро вам объяснит, что надо, и будет дальше заниматься своей основной работой
3. Интересный момент — если бы вы сразу по собственной инициативе бесплатно перевели его на цмс то впоследствии могли бы заработать еще больше, ведь, хотя вы сначала и сработали в убыток, в последствии себестоимость каждой правки (временные затраты) были бы для вас практически нулевыми, а клиент все равно был бы к вам привязан и вы могли бы назначать цены как будто правите хтмл.
1. Да, но сумма от этого не меняется. Кстати он частное лицо.
2. Времени надо бы было гораздо меньше чем он тратил даже на подготовку заданий. Каждая страница была в doc файле. Это он сам сидел и готовил их. И картинки готовил. С cms он тратил бы на публикацию страницы сопоставимое время. Причем ему бы потом не пришлось мне платить.
3. Я не знал сколько я буду работать с этим заказчиком и вкладываться изначально — рискованно. А еще «назначать цены как будто правите хтмл» — не в моем стиле. Я считаю что это не правильно.
2. Времени надо бы было гораздо меньше чем он тратил даже на подготовку заданий. Каждая страница была в doc файле. Это он сам сидел и готовил их. И картинки готовил. С cms он тратил бы на публикацию страницы сопоставимое время. Причем ему бы потом не пришлось мне платить.
3. Я не знал сколько я буду работать с этим заказчиком и вкладываться изначально — рискованно. А еще «назначать цены как будто правите хтмл» — не в моем стиле. Я считаю что это не правильно.
Приучаю своих клиентов к хорошему — посылать подальше девелоперов собственных велосипедов.
лепить типовые сайты на типовых CMS?
UFO just landed and posted this here
Благодарю, небольшая история от меня:
Есть у меня умный Клиент, решил он сделать еще один сайт для нового направления своего бизнеса.
Позвал Человека и предложил поднять зауряднейший сайт на Joomla, т.к. все остальные сайты, какие у него есть тоже на Joomla и он ей вполне доволен.
Человек сказал, что «Joomla не гибкая ничего сделать на ней нельзя».
Вот так вот.
Есть у меня умный Клиент, решил он сделать еще один сайт для нового направления своего бизнеса.
Позвал Человека и предложил поднять зауряднейший сайт на Joomla, т.к. все остальные сайты, какие у него есть тоже на Joomla и он ей вполне доволен.
Человек сказал, что «Joomla не гибкая ничего сделать на ней нельзя».
Вот так вот.
А у меня причина брать именно небольшие заказы донельзя банальна — есть основная работа, где ну никак нельзя сказать «насяльника, приходи через недельку, а то я сейчас занят».
И в этом случае с фрилансерским заказом на день-два-три намного проще — в конце-концов можно и до ночи посидеть и сделать. А вот с большим сложнее — это уже или неделю и больше подряд ночами сидеть, или отказываться, что крайне плохо.
И в этом случае с фрилансерским заказом на день-два-три намного проще — в конце-концов можно и до ночи посидеть и сделать. А вот с большим сложнее — это уже или неделю и больше подряд ночами сидеть, или отказываться, что крайне плохо.
Иногда с малых заказов, начинаются долгие романтические отношения.
Тем более, будь я заказчиком с большим проектом, я бы проверил незнакомого фрилансера в маленьком сражении, перед тем как брать его на важную битву.
Поэтому малые заказы иногда полезны, для завоевания репутации и выстраивания отношений с этим заказчиком и теми кого он сможет привести, если вы покажетесь ему внимательными и адекватными.
Тем более, будь я заказчиком с большим проектом, я бы проверил незнакомого фрилансера в маленьком сражении, перед тем как брать его на важную битву.
Поэтому малые заказы иногда полезны, для завоевания репутации и выстраивания отношений с этим заказчиком и теми кого он сможет привести, если вы покажетесь ему внимательными и адекватными.
внимание сарказм. 100 раз так делал.
Я по правде говоря не чувствую себя специалистом и боюсь брать крупные проекты, зато мелкие с доработками где задача поставлена ясно и четко делаю. Никто еще не жаловался.
Я по правде говоря не чувствую себя специалистом и боюсь брать крупные проекты, зато мелкие с доработками где задача поставлена ясно и четко делаю. Никто еще не жаловался.
UFO just landed and posted this here
Странный подход, какой-то «лучше много маленьких геморроев, чем один большой»… Нет уж, лучше один большой проект и потом на поддержке и дальше уже свои дела в свободное время.
Единственный минус, на мой взгляд, это недостаток интересных задач в таких вот небольших проектах. Механическая работа может сильно угнетать.
Почему-то многим разработчикам интересней делать большие и сложные задачи, чем много мелких однотипных или наоборот разнообразных, требующих поверхностного или не очень изучения новых технологий.
Именно.
Любой крупный проект состоит из множества небольших задач. Крупный проект может быть до предела скучным и однообразным, может выпить всю кровь. Также как и небольшая задача может быть новой и свежей. От размера это зависит не так сильно как вы говорите. Иначе бы крупный проект, состоящий из множества небольших был просто набором однотипных или требующих поверхностного изучения задачек.
А вы не думали, что лучше долго работать над одним большим и дорогим проектом, уделяя внимание мелочам и получая удовольствие, чем постоянно переключаться от проекта к проекту, теребя нервы согласованиями?
Я описал преимущества небольших проектов. Я не выдумал это — я выполнял и небольшие задачи и работал над крупными проектами, видел и то и это. С крупняком все понятно — все любят «долго работать над одним большим и дорогим проектом», но большой проект далеко не всегда дорогой — велика вероятность ошибиться в оценке, сложнее двигать бюджет и так далее по тексту. Это все есть в топике. И да, размер и адекватность оплаты в равной мере касаются проектов любого размера. С поправками на цену ошибки.
Я не призываю отказаться от крупных проектов, я предлагаю пересмотреть отношение к небольшим.
Крупный проект также требует согласований. И если вы устанете от этих многочисленных согласований, утратите бдительность и что-то пропустите — вы просто попадате на деньги. Полезно это для нервов? Не думаю. Возможно ли подобное? Вполне.
Еще раз — я говорю не о преимуществе небольших проектов над крупными, я говорю о том, что небольшие проекты часто недооценивают и относятся к ним предвзято.
Я не призываю отказаться от крупных проектов, я предлагаю пересмотреть отношение к небольшим.
постоянно переключаться от проекта к проекту, теребя нервы согласованиями?
Крупный проект также требует согласований. И если вы устанете от этих многочисленных согласований, утратите бдительность и что-то пропустите — вы просто попадате на деньги. Полезно это для нервов? Не думаю. Возможно ли подобное? Вполне.
Еще раз — я говорю не о преимуществе небольших проектов над крупными, я говорю о том, что небольшие проекты часто недооценивают и относятся к ним предвзято.
Не согласен только с эстимацией проекта в $2000. $2000 / $15 (обычный рейт) / 8 = 17 человеко-дней. Не ошибусь, если скажу что я практически никогда не делал оценок меньше. Эстимэйт считается хорошим, если он находится в границах +-20% (обычно плюс :) ). Правда, заказчику такое оправдание совсем не нравится — он уже настраивается на названную сумму и ни долларом больше.
Полностью согласен, в этих кастрированных задачах есть что-то стоящее. Опять же. Лучше 10 клиентов держать на легкой поддержке по 5к, чем одного крупного на 30к. Эта практика бытует не первый десяток лет. Сарафанка опять же работает лучше…
Вы опускаете еще один аспект, временной. В проекте за 100$ вы указываете время с точностью до нескольких часов. В проекте за 100 000$ можно набросить сверху еще пару месяцев, на риски так сказать. Хорошо это или плохо? Предположим, вы все спланировали, заказчик без претензий и риски не состоялись. В случае маленького проекта вы не получаете ничего. В случае большого, пару месяцев оплаченного «безделья».
В проекте за 100$ вы указываете время с точностью до нескольких часов.
Не указываю с точностью до нескольких часов. Если проект на 3 часа — я скажу «два дня». Потому, что два дня большинство людей устроит. Заказчик на поиски исполнителя может потратил больше чем два дня. Сделаю за 3 часа, сдам через день — заказчик будет доволен, я получу свое и тоже буду доволен. Уж за два то дня можно успеть раз 5 выполнить такой объем.
В проекте за 100 000$ можно набросить сверху еще пару месяцев, на риски так сказать.
Можно набросить, да. Но хватит ли двух месяцев для такого проекта? Не знаю, мне сложно оценить. В сравнении с размером проекта мне кажется это совсем не много. Очень далеко от 2-х дней в первом случае.
В случае большого, пару месяцев оплаченного «безделья».
Тут вообще не совсем понял. Сделал проект, сдал, а заказчик мне потом еще два месяца платит? Это как? :)
Не двух месяцев на проект, а сверху 2 месяца. Тоесть определяется что примерно на проект уйдет полгода. После этого накидывается еще 2 месяца на риски, итого проект занимает 8 месяцев.
И заказчик оплачивает 8 месяцев, исходя например из почасовой ставки.
Теперь представим, что риски не наступили и разработчики уложились в 6 месяцев. Далее проект вялотестируется, а разработчики занимаются уже другим проектом.
После 8 месяцев проект сдается, 2 месяца в денежном выражении либо пилятся поровну, либо менеджер себе забирает :)
Это не значит, что так всегда, это значит, что так может быть. При условии, если команда профессиональная, есть наработки, есть жесткое утвержденное ТЗ, ну и так далее.
И заказчик оплачивает 8 месяцев, исходя например из почасовой ставки.
Теперь представим, что риски не наступили и разработчики уложились в 6 месяцев. Далее проект вялотестируется, а разработчики занимаются уже другим проектом.
После 8 месяцев проект сдается, 2 месяца в денежном выражении либо пилятся поровну, либо менеджер себе забирает :)
Это не значит, что так всегда, это значит, что так может быть. При условии, если команда профессиональная, есть наработки, есть жесткое утвержденное ТЗ, ну и так далее.
UFO just landed and posted this here
Согласен с автором статьи. Пример из жизни:
Сам занимаюсь вёрсткой. Проект который я могу реализовать за 4-5 часов я оцениваю где то в 6-8 тыс.р. и называю срок до двух дней. Я счастлив, заказчик доволен. Так можно поставить на поток ряд сайтов и, допустим за 2 недели заработать порядка 60к, причём особо не напрягаясь. И другой пример.
Заказ который по реализации занимает порядка двух недель сложно оценить дороже чем в 30к, даже учитывая то что посреди разработки можно вклинить пару мелких сайтов. Всё равно в итоге менее выгодно получается.
Сам занимаюсь вёрсткой. Проект который я могу реализовать за 4-5 часов я оцениваю где то в 6-8 тыс.р. и называю срок до двух дней. Я счастлив, заказчик доволен. Так можно поставить на поток ряд сайтов и, допустим за 2 недели заработать порядка 60к, причём особо не напрягаясь. И другой пример.
Заказ который по реализации занимает порядка двух недель сложно оценить дороже чем в 30к, даже учитывая то что посреди разработки можно вклинить пару мелких сайтов. Всё равно в итоге менее выгодно получается.
А есть ли способ узаконивания доходов от всяких мелких заказов вида
«физик попросил машинку починить за 1000руб.»?
«физик попросил машинку починить за 1000руб.»?
Sign up to leave a comment.
В небольших заказах тоже есть жизнь