// codeart.ru / Теория программирования / Фриланс. Проекты большие и маленькие Форум

Фриланс. Проекты большие и маленькие rss подписка

Автор: Evgeniy Sergeev

Не так давно я считал себя заядлым фрилансером. Так мне нравилось ни от кого не зависеть, что мне казалось будто вся моя оставшаяся жизнь целиком и полностью будет связана с работой через Интернет. Я даже придумал для себя набор правил и условий, которым должен был удовлетворять каждый заказ за выполнения которого я брался.

Сейчас уже нет смысла перечислять все, что тогда для меня имело значение, но стоит вспомнить об одном правиле, которое как мне кажется, может помочь многим фрилансерам в их повседневной работе. Это правило можно коротко сформулировать так: «Нигде, никогда и ни при каких условиях не брать крупных проектов.» И тому есть множество причин, о которых я хочу поговорить.

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

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

Прежде чем я продолжу свои рассуждения, давайте определимся, какой проект считается большим, а какой маленьким. Под большими проектами будем понимать, такие проекты которые требуют от 100 и более часов часов рабочего времени. А маленькими будем считать проекты на которые уходит до 20 часов. Все остальные проекты будут считаться средними.

Очевидно, что для команды фрилансеров подобная классификация не подходит, но для одного человека это вполне нормальные рамки. Честно говоря, самый большой заказ, который я встречал на RentACoder был расчитан на два месяца, или примерно 300 часов. А подавляющая масса больших проектов колебалась в районе 100-120 часов.

Как я уже сказал ранее, мне непонятна тяга фрилансеров к объединению в команды, чтобы делать большие проекты, но при этом зарабатывать те же деньги.

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

Во-первых, очевидно, что маленький заказ выполнить гораздо проще и быстрее чем большой, при этом если речь идет о программировании, то размер проекта очень сильно влияет на тестирование конечного результата. А это выливается в дополнительные, неоплаченные часы.

Во-вторых, всегда нужно помнить, что в большинстве случаев фрилансер получает деньги не более двух раз за проект, а это значит, что чем быстрее проект сдан, тем быстрее будет получена оплата за него.

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

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

Допустим стоимость проекта составляет 1000 у.е., скажем вы хотите получить на 20% больше за выполнение этой работы, т.е. на 200 у.е больше. Но заказчик категорически не хочет платить, потому что эта сумма ему кажется большой. А доплатить 20 у.е. на проекте стоимостью в 100 у.е. ( те же самые 20%) соглашается гораздо охотнее, потому что воспринимает эту сумму как незначительную.

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

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

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

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

  1. Как начать заниматься фрилансом

    Лучшие комментарии

  1. Женя, ты конечно меня прости, но с тем, что написано выше — я категорически не согласен.

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

    К тому же с мелкими проектами намного чаще бывает больше «головняка», чем в одном большом.

    Мне встречались проекты на 300 и более часов, прямо сейчас в командной разработке проект, расчитанный на 3 месяца, из которых уже месяц отработали, тоесть в среднем по 5-6 часов в день на 3 программиста. Итого около 300 часов уже выработано. И это только треть проекта.

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

    Мелкие проекты не дают ничего, кроме денег.

    Теперь насчет «заказчик не согласен платить». Забудь о том, что заказчик может еще кого-то найти. Если он уходит — значит это просто не твой заказчик и будут другие.

    «Нигде, никогда и ни при каких условиях не брать крупных проектов.” — вообще странное правило..Возможно потому ты и ушел снова работать в офис ибо такое правило к другому и не могло привести — это отсутствие роста и в оплате и в постоянстве.

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

    Не проявляется на самом деле, Женя. Если заказчик адекватен, то ему не трудно пояснить человеческим языком, почему эта работа стоит большее на 200 долларов.

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

    Ну и еще: если у заказчика есть уже пару тысяч долларов, то найти еще 200 долларов — это вообще не проблема, а иначе — это посредник, а вот с посредниками работать на больших проектах — не стоит, таких надо сразу «сплавлять» — пусть дальше идут и ищут дешевую рабочую силу и возможность срубить бабла, не заплатив за это достаточные для разработчика деньги.

  2. «Например, мне не понятно — зачем становиться фрилансером, чтобы потом искать команду в которой работать? Ведь в конечном итоге любая кооперация приводит к возникновению порядков ничем не отличающихся от офисных.»
    ———————————

    А мне понятно. Джоэл Спольски, например, считает, что для качественного _превращения денег в программный продукт_ необходимы в первую очередь талантливые и грамотные люди. А как еще талант и грамотность проверить, кроме как поработав вместе?

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

    «Во-первых, очевидно, что маленький заказ выполнить гораздо проще и быстрее чем большой»
    ——————

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

    Во-вторых, именно работу над _большими_ проектами и призвано облегчить планирование и написание спецификаций. Уже на себе проверил :)

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

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

    И не говорите мне, что _спецификацию для вас составляет заказчик_! Не поверю 😉 Ее должен писать руководитель разработки, а в случае с фрилансером, сам фрилансер.

    «при этом если речь идет о программировании, то размер проекта очень сильно влияет на тестирование конечного результата. А это выливается в дополнительные, неоплаченные часы.»
    ——————————
    С этим согласен. Но, опять же, планирование призвано облегчить вашу (и мою заодно) жизнь :) И те же спеки..

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

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

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

  4. Не стал читать до конца, с четвёртого абзаца стало понятно, что хочет сказать автор и чем мотивирует свою точку зрения и конечно его просчёты.
    Автор ненамеренно упускает несколько моментов. Например участи в крупном проекте избавляет вас не только от бесконечных поисков мелких — а это затраты времени и ресурсов и отсутсвие заработка, далее каждый раз договариваясь с новым работодателем вы опять таки тратите время и ресурсы — это существенные затраты времени, которые не оплачиваются. Ко всему прочему, риски, которые часто вынужден брать фрилансер, а согласно статистике, именно мелкие заказы чаще являются заказами нечистоплотных работодателей.
    Далее, чем крупнее заказ, тем крупнее заказчик, тем лучше себе он готов нанять исполнителей, тем больше он им готов заплатить именно исходя из трудочасов.
    Остальные проблемы в работе командой — является исключительно личностной характеристикой. На самом деле не каждый способен работать в команде, мало кто умеет ей управлят. А постороение эффективных команд — было есть и будет постоянно изучаемым вопросом.
    К тому же вы упускаете из виду, что команда в состоянии брать не только крупные заказы, но и массу мелких, так что я не вижу никакой выгоды от работы в одиночку.
    В мою пользу так же говорит разделение труда, то есть каждый участник команды занимается исключительно своим делом, в котором он наиболее эффективен, и в случае форс мажоров, возможна подмена или взаимопощь.А одиночка в состоянии полагаться только на свои силы, форс мажоры он не преодолеет, например болезнь и прочее. И вынужден постоянно заниматься не своей работой: искать исполнителя, оговаривать с заказчиком условия, строить проект, контролировать и поддерживать связь с с ним же и т.д.
    Конечно, повторюсь — у каждого своя стихия и свои методы — которые наиболее эффективны ему, но один в поле не воин сказанно давно и не мной.
    Сам являюсь менеджером, команда постоянна обеспечена работой, заработком, исполнитель качественной продукцией. В цене за трудочас — может быть где то теряют, но в конечном итоге никто не желает возвращаться в вольное плавание. Так как до объеденения зарабатывали порядком меньше каждый в отдельности, хотя иногда и выполняли работу по более высокой цене. Ну чисто ИМХО :)

  5. Евгений, я работая в команде выполнял проекты такими заказчиками как Русал, Русгидро и т.д. Стоимость проектов от 3 миллионов рублей, до 9 миллионов. Проекты в основнот 6 месяцев, кол-во человек задействованых в проекте около 10.
    Итак, как делаются подобные проекты:
    Шаг 1. Оформляется технорабочий проект и рабочая документация. Порядка 13 книг. Могут быть разные, но обычно обязательно есть следующие (на вскидку): Формуляр, Ведомость покупных изделий, Спецификация, Пояснительная записка, Описание технических средств, Описание программных средств, Методика предварительных испытаний и т.д. Делается все по ГОСТам, согласовывается с большим количеством людей и т.д. Поверьте, шаг очень нудный, даже при условии, что все идет гладко. Приходится делать тонну работы, чтобы только приступить к созданию системы.
    Шаг 2. Реализация. Здесь вроде все просто, берешь технорабочий проект и делаешь. На самом деле, полная засада. Так как технрабочий проект делался большую часть отведенного срока, то приходится работать с постоянными сверхурочными.
    Шаг 3. Внедрение. Если коротко, то система быстро развертывается и настраивается. А потом начинается самое нудно — оформление актов (ОС-14, НА-14, НА-1, ОС-15 и т.д. — это все унифицированные формы), потом акты локальные, свойственные для каждой компании. Так как обычно этот этап выполняется в декабре, а все средства должны быть освоены до конца года, то здесь приходиться очень даже побегать..

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

    Отдача от проекта для специалиста не такая уж и большая — зарплата, может премиальные. И все. Все остальное прибыль фирмы.

    А это еще не учитываются некоторые особенности ведения бизнеса в России…

    Так что по мне лучше делать свои небольшие заказы, и работать напрямую с заказчиком. Чем делать крупные проекты и быть мелкой шестеренкой. Если не сказать хуже.

  1. ну во первых не всегда большие заказы приносят каждому в команде такие же деньги как небольшие для одного фрилансеры, не все вокруг глупые, кое-кто может аргументировать «сбивчивость» в стаи;).

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

  2. Гвидон Маляров, на Ваш взгляд в большом заказе каково соотношение рутинной работы к технически интересной работе?

    Почему маленький заказ не может быть технически интересен?

    Почему вожак стаи должен быть лучшее/добрее/умнее чем руководитель в офисе?

    У Вас не было такого, что выполняя большой проект в голове были мыли о том, чтобы быстрее его завершить? А после завершения чувство пустоты и никакого морального удовольствия?

  3. А я начал с фриланса, потом поработал 2 месяца на офисе и понял, что офисная работа не для меня…

  4. Хм… Интересная тема. )
    Большие проекты…. Объединения в группы…..

    А вот знаешь — это бывает удобно. Найти 2-х ребят с низкой ставкой и объёденится на проекте, который ты принёс. Выстроить их больно. И Затратив минимум ресурсов получить денежку…. Ладно — это философия.

    В превалирующим большинстве случаев большие проекты действительно изматывают, но обычно большие проекты несут с собой интересный функционал или большие ставки.

    И я позволю себе ответить на вопросы для Гвидона:
    > Ваш взгляд в большом заказе каково соотношение рутинной работы к технически интересной работе?
    Рутина — 70% Интересное — 30%
    К сравнению в большинстве случаев маленький проект:
    Рутина — 95% Интересное — 5%

    >Почему маленький заказ не может быть технически интересен?
    Может, но очень редко.

    >У Вас не было такого, что выполняя большой проект в голове были мыли о том, чтобы быстрее его завершить? А после завершения чувство пустоты и никакого морального удовольствия?
    Это больше не от проекта зависит, а от клиента.

  5. Женя, насчет — «два поменьше одного большого, да лучше» согласен полность, с моей стороны — не фрилансера.
    У нас постояно с шефом разногласия, он видит хорошую предоплату, я же чуствую нарастающий дед лайн и грядущие проблемы. (:

  6. фриланс — это стиль жизни… это мое

  7. Согласен с Гвидоном. Мне самому редко попадались проекты на том же RentACoderе требующие сложной архитектуры. Зачастую это обычная трехслойная модель. А ведь хотелось и веб-фермы, -фабрики построить. Решать проблемы масштабирования и большой нагрузки на сервер. Думаю это скорее вопрос темперамента и амбиций, чем принадлежность или наоброт — не принадлежность фрилансерству.

  8. Женя, ты конечно меня прости, но с тем, что написано выше — я категорически не согласен.

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

    К тому же с мелкими проектами намного чаще бывает больше «головняка», чем в одном большом.

    Мне встречались проекты на 300 и более часов, прямо сейчас в командной разработке проект, расчитанный на 3 месяца, из которых уже месяц отработали, тоесть в среднем по 5-6 часов в день на 3 программиста. Итого около 300 часов уже выработано. И это только треть проекта.

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

    Мелкие проекты не дают ничего, кроме денег.

    Теперь насчет «заказчик не согласен платить». Забудь о том, что заказчик может еще кого-то найти. Если он уходит — значит это просто не твой заказчик и будут другие.

    «Нигде, никогда и ни при каких условиях не брать крупных проектов.” — вообще странное правило..Возможно потому ты и ушел снова работать в офис ибо такое правило к другому и не могло привести — это отсутствие роста и в оплате и в постоянстве.

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

    Не проявляется на самом деле, Женя. Если заказчик адекватен, то ему не трудно пояснить человеческим языком, почему эта работа стоит большее на 200 долларов.

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

    Ну и еще: если у заказчика есть уже пару тысяч долларов, то найти еще 200 долларов — это вообще не проблема, а иначе — это посредник, а вот с посредниками работать на больших проектах — не стоит, таких надо сразу «сплавлять» — пусть дальше идут и ищут дешевую рабочую силу и возможность срубить бабла, не заплатив за это достаточные для разработчика деньги.

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

    Тоесть — они не сомневались к кому идут и зачем и уже сделали предварительный выбор. Поэтому вопрос в «поднять планку на 200 долларов» — никогда не стоял, это не тот уровень, когда люди будут жадничать, если уже сделали выбор исполнителя.

  10. Я считаю что мелкими проэктами смысла нет заниматся,интереса нету,да и развитие приостанавливается

  11. Я считаю, что работа фрилансера дает свободу, но в каком-то плане лишает спокойствия и стабильности.

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

    Но, риск — благородное дело. Если фриланс не покорился Вам с первого раза, можно попробовать снова!

    Важно проанализировать почему эта работа себя не оправдала.

    Дело в том, что можно быть отличным программистом, но не уметь правильно себя презентовать, как специалиста. Фрилансер должен быть не только профи в своей области, но также хорошим продавцом и пиар-менеджером. (А еще очень важно не занижать цену на свои товары и услуги)

  12. а мне понравилось содержание, статьи только надо сделать маленькую сноску. эта статья наверно больше относится к начинающим, что бы понять что это и к чему это может привести.

  13. >>> Как я уже сказал ранее, мне непонятна тяга фрилансеров к объединению в команды, чтобы делать большие проекты, но при этом зарабатывать те же деньги.

    А по моему все просто… Человек, который на волне эмоций вырвался из офиса все так же неготов или подсознательно не хочет работать один и сам на себя. Хочется ему к людям в офис, а тут альтернатива — команда

  14. А я заметил, следующию тенденцию, фрилансы чаще не в фирму уходят работать, а сами создают эти фирмы.. ))), так как привыкли к свободному графику работы

  15. Может фрилансер и одиночка, но без единомышленников бывает очень и очень трудно психологически. А жизнь ведь не только деньгами измеряется. Некоторые вообще без коллектива работать не могут.

  16. Моё мнение такое: небольшие проекты хлебны, но, как выше говорилось, ничего не приносят, кроме денег. Единственное исключение — проекты на неизученной технологии. Знакомые на Bitrix’е очень неплохо зарабатывают, тратя едва ли по два дня на проект.

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

  17. «Например, мне не понятно — зачем становиться фрилансером, чтобы потом искать команду в которой работать? Ведь в конечном итоге любая кооперация приводит к возникновению порядков ничем не отличающихся от офисных.»
    ———————————

    А мне понятно. Джоэл Спольски, например, считает, что для качественного _превращения денег в программный продукт_ необходимы в первую очередь талантливые и грамотные люди. А как еще талант и грамотность проверить, кроме как поработав вместе?

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

    «Во-первых, очевидно, что маленький заказ выполнить гораздо проще и быстрее чем большой»
    ——————

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

    Во-вторых, именно работу над _большими_ проектами и призвано облегчить планирование и написание спецификаций. Уже на себе проверил :)

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

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

    И не говорите мне, что _спецификацию для вас составляет заказчик_! Не поверю 😉 Ее должен писать руководитель разработки, а в случае с фрилансером, сам фрилансер.

    «при этом если речь идет о программировании, то размер проекта очень сильно влияет на тестирование конечного результата. А это выливается в дополнительные, неоплаченные часы.»
    ——————————
    С этим согласен. Но, опять же, планирование призвано облегчить вашу (и мою заодно) жизнь :) И те же спеки..

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

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

  18. Вы упускаете из виду тот факт, что с каждым годом программирование и проекты становятся все сложнее и сложнее. И количество часов, затрачиваемых на на эти проекты растет. Недалек тот день, когда в одиночку будет просто нереально разработать конкурентноспособное ПО. Именно поэтому, как Вы пишете малых проектов никогда не бывает в достаточном количестве, чтобы быть занятым на 100%.

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

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

  20. Не стал читать до конца, с четвёртого абзаца стало понятно, что хочет сказать автор и чем мотивирует свою точку зрения и конечно его просчёты.
    Автор ненамеренно упускает несколько моментов. Например участи в крупном проекте избавляет вас не только от бесконечных поисков мелких — а это затраты времени и ресурсов и отсутсвие заработка, далее каждый раз договариваясь с новым работодателем вы опять таки тратите время и ресурсы — это существенные затраты времени, которые не оплачиваются. Ко всему прочему, риски, которые часто вынужден брать фрилансер, а согласно статистике, именно мелкие заказы чаще являются заказами нечистоплотных работодателей.
    Далее, чем крупнее заказ, тем крупнее заказчик, тем лучше себе он готов нанять исполнителей, тем больше он им готов заплатить именно исходя из трудочасов.
    Остальные проблемы в работе командой — является исключительно личностной характеристикой. На самом деле не каждый способен работать в команде, мало кто умеет ей управлят. А постороение эффективных команд — было есть и будет постоянно изучаемым вопросом.
    К тому же вы упускаете из виду, что команда в состоянии брать не только крупные заказы, но и массу мелких, так что я не вижу никакой выгоды от работы в одиночку.
    В мою пользу так же говорит разделение труда, то есть каждый участник команды занимается исключительно своим делом, в котором он наиболее эффективен, и в случае форс мажоров, возможна подмена или взаимопощь.А одиночка в состоянии полагаться только на свои силы, форс мажоры он не преодолеет, например болезнь и прочее. И вынужден постоянно заниматься не своей работой: искать исполнителя, оговаривать с заказчиком условия, строить проект, контролировать и поддерживать связь с с ним же и т.д.
    Конечно, повторюсь — у каждого своя стихия и свои методы — которые наиболее эффективны ему, но один в поле не воин сказанно давно и не мной.
    Сам являюсь менеджером, команда постоянна обеспечена работой, заработком, исполнитель качественной продукцией. В цене за трудочас — может быть где то теряют, но в конечном итоге никто не желает возвращаться в вольное плавание. Так как до объеденения зарабатывали порядком меньше каждый в отдельности, хотя иногда и выполняли работу по более высокой цене. Ну чисто ИМХО :)

  21. Евгений, я работая в команде выполнял проекты такими заказчиками как Русал, Русгидро и т.д. Стоимость проектов от 3 миллионов рублей, до 9 миллионов. Проекты в основнот 6 месяцев, кол-во человек задействованых в проекте около 10.
    Итак, как делаются подобные проекты:
    Шаг 1. Оформляется технорабочий проект и рабочая документация. Порядка 13 книг. Могут быть разные, но обычно обязательно есть следующие (на вскидку): Формуляр, Ведомость покупных изделий, Спецификация, Пояснительная записка, Описание технических средств, Описание программных средств, Методика предварительных испытаний и т.д. Делается все по ГОСТам, согласовывается с большим количеством людей и т.д. Поверьте, шаг очень нудный, даже при условии, что все идет гладко. Приходится делать тонну работы, чтобы только приступить к созданию системы.
    Шаг 2. Реализация. Здесь вроде все просто, берешь технорабочий проект и делаешь. На самом деле, полная засада. Так как технрабочий проект делался большую часть отведенного срока, то приходится работать с постоянными сверхурочными.
    Шаг 3. Внедрение. Если коротко, то система быстро развертывается и настраивается. А потом начинается самое нудно — оформление актов (ОС-14, НА-14, НА-1, ОС-15 и т.д. — это все унифицированные формы), потом акты локальные, свойственные для каждой компании. Так как обычно этот этап выполняется в декабре, а все средства должны быть освоены до конца года, то здесь приходиться очень даже побегать..

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

    Отдача от проекта для специалиста не такая уж и большая — зарплата, может премиальные. И все. Все остальное прибыль фирмы.

    А это еще не учитываются некоторые особенности ведения бизнеса в России…

    Так что по мне лучше делать свои небольшие заказы, и работать напрямую с заказчиком. Чем делать крупные проекты и быть мелкой шестеренкой. Если не сказать хуже.

Leave a Reply

« »