Comments 18
интересно очень. а существуют такие?
Хорошие исполнители уже давно не исчут заказы…
А только выбирают наиболее привлекательные для них.
… нет опыта — лучше во фриланс не лезть., а идти и набираться его в команде.
есть опыт — читаем сообщение с самого начала…
__
*и вроде бы одна и таже тема поднимается цатый раз… тока в разных вариациях…
А только выбирают наиболее привлекательные для них.
… нет опыта — лучше во фриланс не лезть., а идти и набираться его в команде.
есть опыт — читаем сообщение с самого начала…
__
*и вроде бы одна и таже тема поднимается цатый раз… тока в разных вариациях…
полностью согласен, обычно через 2-6 месяцев (у каждого по разному) появляются постоянные партнёры, клиенты, старые клиенты приводят новых и т. д. И вследствии фрилансбиржи могут понадобится только при повышении расценок на услуги
При чем здесь заказы? Речь идет о грамотной организации работ когда верстальщик верстает и изучат особенности IE, а не лезет проектировать БД или выбирает платформу для построения системы.
Только не надо это воспринимать как запрет для верстальщика учить другие ветви ремесла: я говорю о профессиональных интересах, а не о хобби.
Только не надо это воспринимать как запрет для верстальщика учить другие ветви ремесла: я говорю о профессиональных интересах, а не о хобби.
При чем здесь заказы? Речь идет о грамотной организации работ когда верстальщик верстает и изучат особенности IE, а не лезет проектировать БД или выбирает платформу для построения системы.
Простие, а о какой серьезности и качестве можно говорить. если кто то даже что мастер на все руки — это хорошо.
Простие, а о какой серьезности и качестве можно говорить. если кто то даже что мастер на все руки — это хорошо.
Незнаю, на практике я конечно от фриланса далек, но насколько я рассматривал эту нишу — только низкооплачиваемый-неквалифицированный-рабский-труд (произносится слитно, на одном дыхании :)) проходит по принципу «все в одном», серьезные заказчики сами ищут отдельного испольнителя на каждую отдельную область работ, отдельно программистов, отдельно дизайнеров и т. п., заказчик в конце концов сам должен понимать взаимосвязь между оплатой и качеством выполненной работы, если он нанимает за бесценок одного единственного работника на выполнение всех работ сразу — то значит и на качество он может рассчитывать соот-щее.
Можете поверить или проверить, но если «все в одном», то не «низкооплачиваемый-неквалифицированный-рабский», а прямо-таки наоборот.
Про проблемы с передачей материалов по цепочке дизайнер->верстальщик->программист->тестировщик->сео я писал в пункте 4. Например, если скажет сеошник чистить код от инлайн стилей и яваскрипта, то это должен делать не тестировщик и не программист который перед ним в цепочке, а верстальщик. А если этот самый верстальщик закончил свою часть работ и укатил на моря, то как поступать? В предложенной схеме работы верстальщик сидит в той же скайп-конференции и тут же берется за работу.
Про проблемы с передачей материалов по цепочке дизайнер->верстальщик->программист->тестировщик->сео я писал в пункте 4. Например, если скажет сеошник чистить код от инлайн стилей и яваскрипта, то это должен делать не тестировщик и не программист который перед ним в цепочке, а верстальщик. А если этот самый верстальщик закончил свою часть работ и укатил на моря, то как поступать? В предложенной схеме работы верстальщик сидит в той же скайп-конференции и тут же берется за работу.
Звучит убедительно. Только для этого нужен специализированный ресурс с достаточным количеством осведомлённых о нем людей.
Идея интересная, фактически на фрилансе существует прослойка, которая зарабатывает на посредничестве и предложенная схема работы призвана направить посредничество в цивилизованное русло. Только есть несколько но:
1. при открытой схеме интерес посредника тает на глазах: если все учасники знают бюджет проекта — каждый будет стараться максимизировать свою прибыль от участия.
2. Дележка шкуры неубитого медведя — это bad. Более того, нужно проработать механизмы защиты заинтерисованных сторон от злоупотребления доверием как со стороны заказчика, так и со стороны исполнителей.
3. Исключение из группы в ходе проекта — эта мысль не прокатит. Представим ситуацию: вы дизайнер — сделали макеты, отдали в верстку, заказчик говорит: что-то фиговый у нас дизайнер, давайте его выкинем нахер. Согласно пункту №1, быстро набирается нужное число голосов и дизайнер остается с носом. Аналогично возможна такая ситуация с любым участником.
4. Предложенная идея подразумевает необходимость очень четкого автоматизированного процесса разработки. К сожалению, это большая редкость в IT-сфере. Можно было бы предложить какую-нибудь agile методологию, но они плохо работают на проектах с fixed price.
Вообщем, пока что это скорее утопия, чем идея для реализации.
1. при открытой схеме интерес посредника тает на глазах: если все учасники знают бюджет проекта — каждый будет стараться максимизировать свою прибыль от участия.
2. Дележка шкуры неубитого медведя — это bad. Более того, нужно проработать механизмы защиты заинтерисованных сторон от злоупотребления доверием как со стороны заказчика, так и со стороны исполнителей.
3. Исключение из группы в ходе проекта — эта мысль не прокатит. Представим ситуацию: вы дизайнер — сделали макеты, отдали в верстку, заказчик говорит: что-то фиговый у нас дизайнер, давайте его выкинем нахер. Согласно пункту №1, быстро набирается нужное число голосов и дизайнер остается с носом. Аналогично возможна такая ситуация с любым участником.
4. Предложенная идея подразумевает необходимость очень четкого автоматизированного процесса разработки. К сожалению, это большая редкость в IT-сфере. Можно было бы предложить какую-нибудь agile методологию, но они плохо работают на проектах с fixed price.
Вообщем, пока что это скорее утопия, чем идея для реализации.
>1. при открытой схеме интерес посредника тает на глазах: если все учасники знают бюджет проекта — каждый будет стараться максимизировать свою прибыль от участия.
Все правильно. Посредник действительно остается не у дел. Даже человек который создает команду обязан кроме факта нахождения заказчика приносить команде пользу во время работы. Для посредников остается узкая лазейка в виде исполнения роли менеджера по работе с клиентами в проекте.
>2. Дележка шкуры неубитого медведя — это bad. Более того, нужно проработать механизмы защиты заинтерисованных сторон от злоупотребления доверием как со стороны заказчика, так и со стороны исполнителей.
Тут можно спорить что более bad: недомолвки и грызня внутри команды (помните как Паниковский и Балаганов деньги делили? :) ) или дележка шкуры медведя. Это даже не только IT бизнеса касается.
>3. Исключение из группы в ходе проекта — эта мысль не прокатит. Представим ситуацию: вы дизайнер — сделали макеты, отдали в верстку, заказчик говорит: что-то фиговый у нас дизайнер, давайте его выкинем нахер. Согласно пункту №1, быстро набирается нужное число голосов и дизайнер остается с носом. Аналогично возможна
такая ситуация с любым участником.
Зачем кому-то в команде голосовать против дизайнера который уже «в теме», который хорошо знает требования заказчика? Если у заказчика есть претензии к дизайнеру по одному из требований пункта 1, то возможно дизайнер действительно виноват. Если же заказчик хочет просто скинуть цену, то у него не будет серьезных оснований для претензий и на голосовании большинство будет против исключения дизайнера. Кроме того, совсем против будет человек который приглашал дизайнера в команду т. к. он теряет 20% своей части на пустом месте.
Кстати, есть мысль вести статистику подобных голосований, чтобы скандальных заказчиков было видно издалека.
Что касается механизмов защиты, я об этом не упоминал, но варианты похожие на веблансерский СБС предополагались по-умолчанию.
>4. Предложенная идея подразумевает необходимость очень четкого автоматизированного процесса разработки. К сожалению, это большая редкость в IT-сфере. Можно было бы предложить какую-нибудь agile методологию, но они плохо работают на проектах с fixed price.
Можете развить идею? Я что-то не очень понял насчет «очень четкой автоматизации процесса разработки»? Что именно на ваш взгляд стоит автоматизировать?
>Вообщем, пока что это скорее утопия, чем идея для реализации.
Идея сыра, но предмет для обсуждения уже есть.
Все правильно. Посредник действительно остается не у дел. Даже человек который создает команду обязан кроме факта нахождения заказчика приносить команде пользу во время работы. Для посредников остается узкая лазейка в виде исполнения роли менеджера по работе с клиентами в проекте.
>2. Дележка шкуры неубитого медведя — это bad. Более того, нужно проработать механизмы защиты заинтерисованных сторон от злоупотребления доверием как со стороны заказчика, так и со стороны исполнителей.
Тут можно спорить что более bad: недомолвки и грызня внутри команды (помните как Паниковский и Балаганов деньги делили? :) ) или дележка шкуры медведя. Это даже не только IT бизнеса касается.
>3. Исключение из группы в ходе проекта — эта мысль не прокатит. Представим ситуацию: вы дизайнер — сделали макеты, отдали в верстку, заказчик говорит: что-то фиговый у нас дизайнер, давайте его выкинем нахер. Согласно пункту №1, быстро набирается нужное число голосов и дизайнер остается с носом. Аналогично возможна
такая ситуация с любым участником.
Зачем кому-то в команде голосовать против дизайнера который уже «в теме», который хорошо знает требования заказчика? Если у заказчика есть претензии к дизайнеру по одному из требований пункта 1, то возможно дизайнер действительно виноват. Если же заказчик хочет просто скинуть цену, то у него не будет серьезных оснований для претензий и на голосовании большинство будет против исключения дизайнера. Кроме того, совсем против будет человек который приглашал дизайнера в команду т. к. он теряет 20% своей части на пустом месте.
Кстати, есть мысль вести статистику подобных голосований, чтобы скандальных заказчиков было видно издалека.
Что касается механизмов защиты, я об этом не упоминал, но варианты похожие на веблансерский СБС предополагались по-умолчанию.
>4. Предложенная идея подразумевает необходимость очень четкого автоматизированного процесса разработки. К сожалению, это большая редкость в IT-сфере. Можно было бы предложить какую-нибудь agile методологию, но они плохо работают на проектах с fixed price.
Можете развить идею? Я что-то не очень понял насчет «очень четкой автоматизации процесса разработки»? Что именно на ваш взгляд стоит автоматизировать?
>Вообщем, пока что это скорее утопия, чем идея для реализации.
Идея сыра, но предмет для обсуждения уже есть.
Идея оригинальная. Однако есть такая штука как "социальная ленность", которая с ростом количества людей в аморфном коллективе быстро сведёт эффективность к минимуму.
даешь на главную, хороший пост!
Нечто подобное я задумывал сделать лет эдак пять-шесть назад, однако сам был слишком молод и бестолков :) В моих терминах это называлось «артель», и суть сводилась к тому что каждый специалист экономит время и силы на сопутствующую деятельность (поиск заказов, поддержка собственного сайта, договора, налоги и другая бюрократия) — то есть, примерно как и у вас.
Сейчас мне видится тут один ключевой недостаток. В проекте должен быть администратор, который будет, как минимум, единолично управлять ресурсами. Демократия тут работать не будет, потому что вопрос распределения гешефта — это игра с нулевой суммой. Сейчас я думаю, что эту роль должен выполнять кто-то со стороны заказчика, т.е., мы фактически включаем его в команду в роли одного из руководителей.
Есть недостатки и менее существенные. В первую очередь я сюда отношу инфраструктуру проекта, которую всякий раз надо создавать заново, что противоречит самим основам проектной деятельности. Во-вторых — банальная «сработанность» команды.
Однако в эту сторону имеет смысл думать и работать, чтобы иметь возможность гибко собирать работоспособный коллектив для решения конкретной задачи, сохраняя при этом качество.
Сейчас мне видится тут один ключевой недостаток. В проекте должен быть администратор, который будет, как минимум, единолично управлять ресурсами. Демократия тут работать не будет, потому что вопрос распределения гешефта — это игра с нулевой суммой. Сейчас я думаю, что эту роль должен выполнять кто-то со стороны заказчика, т.е., мы фактически включаем его в команду в роли одного из руководителей.
Есть недостатки и менее существенные. В первую очередь я сюда отношу инфраструктуру проекта, которую всякий раз надо создавать заново, что противоречит самим основам проектной деятельности. Во-вторых — банальная «сработанность» команды.
Однако в эту сторону имеет смысл думать и работать, чтобы иметь возможность гибко собирать работоспособный коллектив для решения конкретной задачи, сохраняя при этом качество.
Sign up to leave a comment.
IT-шабашки как альтернатива фрилансу и студиям