Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Что же, идея хорошая, но и минусов в ней достаточно (не бывает "+" без "-"). Конечно, минусы на практике можно попытаться обратить и в "+", но тут нужно и полное понимание всего механизма работы такой организации не только «верхам», но и «низам»…
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…
Какие я вижу минусы:
1) Заказчик 1 — у него, соответственно, монополия на заказы… В принципе, решается введением еще нескольких начальников (заказчиков).
2) Есть возможность у исполнителя уйти на более интересный проект (мало ли что, такое запрещать нельзя, ведь насильно мил не будешь :)), в этом случае появляется опасность того, что ключевой разработчик просто уйдет.
3) А что в плане з/п? Если комбинировать — то откуда брать постоянную часть зарплаты, если команд разработки много, а заказов мало? «Нахлебников» терпеть особо не любят…
4) Санкции на невыполнение работы — не есть хорошо.
5) Кто будет устанавливать сроки? Если ты изначально неправильно оценил объем работ или заказ поменялся, то все летит кувырком…
6) Как и было сказано, нужно проработанное ТЗ, что значит, что его надо проработать. А кто этим занимается? Лучше всего, когда этим занимается именно тот человек, кто будет непосредственно реализовывать это все…
В принципе, список можно продолжать… Все это требует более глубокой проработки, но и пока не попробуешь на практике, не поймешь всех минусов, а часть может оказаться надуманной…
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…
Какие я вижу минусы:
1) Заказчик 1 — у него, соответственно, монополия на заказы… В принципе, решается введением еще нескольких начальников (заказчиков).
2) Есть возможность у исполнителя уйти на более интересный проект (мало ли что, такое запрещать нельзя, ведь насильно мил не будешь :)), в этом случае появляется опасность того, что ключевой разработчик просто уйдет.
3) А что в плане з/п? Если комбинировать — то откуда брать постоянную часть зарплаты, если команд разработки много, а заказов мало? «Нахлебников» терпеть особо не любят…
4) Санкции на невыполнение работы — не есть хорошо.
5) Кто будет устанавливать сроки? Если ты изначально неправильно оценил объем работ или заказ поменялся, то все летит кувырком…
6) Как и было сказано, нужно проработанное ТЗ, что значит, что его надо проработать. А кто этим занимается? Лучше всего, когда этим занимается именно тот человек, кто будет непосредственно реализовывать это все…
В принципе, список можно продолжать… Все это требует более глубокой проработки, но и пока не попробуешь на практике, не поймешь всех минусов, а часть может оказаться надуманной…
В реальности, чтобы такое заработало — надо просто взять и сделать ;) Да, рискованно; да, страшно, но без практического внедрения это все остается только идеями и далее ни куда не уходит…
Согласен. Для того и хочу рассмотреть эту идею с разных сторон. Хочется попробовать внедрить её в нашей компании.
Спасибо за ваши комментарии. Какие-то вещи я начал представлять лучше.
Попробую пройтись по «минусам»:
1) В нашем случае — это несколько одновременно идущих проектов со своим PM'ом. Сложность — примерно одинакова. Тематика, технологии — различаются. При этом, периодически возникает ситуация, когда один из проектов требует дополнительных трудозатрат в какой-то период. Обычно это решается указанием сверху — Вася Пупкин переходит из проекта А в проект Б. Что думает Вася — не важно. В общем, во всех конторах, где довелось поработать — всегда были несколько параллельных разработок (просто иногда они практически не отличались одна от другой:)
2) Это как раз тот минус, о котором вы писали, который можно обратить в плюс. Лучше давать человеку свободу внутри компании, чем подавлять его и ограничивать и тем самым подводить к тому, что он просто уйдёт совсем. Не в другой, более интересный проект, а в другую компанию.
Дело в том, что это добавляет прозрачности в отношения компания-сотрудник. Если с одного проекта бегут — нужно разбираться. Но это путь развития. В обычных условиях все просто молчат и работают, пока не устанут окончательно, а тогда уже удержать можно только деньгами, деньгами, деньгами. А как же душа?:)
3) Нахлебники — это плохо. Но! Если продумать, как доносить до всех результаты работы каждого, то это уже становится делом коллектива. То есть, сидят Петя с Колей и впахивают по-стахановски, а рядом Вася — и сёрфит весь день в инете, в проекты не рвётся (устраивает его базовый оклад). Раньше в этой ситуации дёргался только PM, теперь же все понимают, что кормят Васю из своих. И должны будут Васе по-дружески объяснить, что он не прав:) Таким образом — мы и гражданское общество построим!:)
4) Почему санкции это не хорошо? Как я понимаю, они могут возникнуть если:
а) Разработчик неверно оценил объём работ и свои силы
б) Расслабился
Если а), то помогаем человеку расти и лучше оценивать. Если б) — воспитываем ответственность (первую сессию тоже многие заваливают, от новизны ситуации — никто не стоит над душой; но потом ведь учатся!)
5) Да PM тоже нужно будет расти. Многие вещи, которые бы раньше прошли и так, теперь придётся планировать по-другому. Ну ничего, можно ведь договариваться с разработчиками не только по fixed-cost, но и по time&materials, для секций, где много неясного и высокие риски (но компании между собой как-то управляются, а мы чем хуже?:)
6) Как разрабатывать ТЗ — сходу не ответишь, нужно подумать. Если совсем правильно, то опять же на договорной основе привлекать архитектора и платить ему денежку. И в этом случае, у нас появляется новый тип проектов — предпроектный Research. Может быть кому-то у нас в коллективе именно этого не хватает для ощущения полноты бытия?:)
2) Я имел в виду, что человек переходит на новый проект внутри компании, при этом «бросая» старый. Минус в том, что если появился «денежный» проект, то старый может остаться без разработчиков. Способ обхода данного момента — обмен, а не переход. Т.е. ты не уходишь, а меняешься с человеком проектом (конечно, можно и переход предусмотреть, но уже с ограничениями, когда можно, а когда нельзя). Но тут тоже минус — не все разработчики обладают равной квалификацией. (Выход — пусть и с командой согласовываются все переходы). Но опять же проблема: а как рассчитывать вклад каждого в проект?
5+6) Рекомендуется оценивать сроки именно человеку, который будет это все реализовывать (в этом случае сроки самые маленькие получаются). Можно дать возможность команде на 1-м этапе составить ТЗ и примерные сроки. Потом дать им возможность или сменить проект или разработать его. За разработку ТЗ давать некий % от цены.
В этом случае есть есть несколько вариантов:
1) Разработал ТЗ и реализовал — все хорошо
2) ТЗ, но без реализации — в этом случае можно брать другую команду, пускай она оценит сама сроки и реализовывает (тут можно и по срокам сравнить).
3) Находишь проект с ТЗ и делаешь его.
Т.е. получается самоорганизация: Ты или только с ТЗ можешь работать, или только по ТЗ, или полный цикл. Все сами выбирают то, что им больше нравится и лучше получается (врятли любитель составлять ТЗ, но у которого это не выходит сумеет «продать» свое ТЗ другой команде).
Еще надо продумать момент, что иногда у команд разные спецификации. Скажем, одна — программисты, другая — дизайнеры/тестеры и т.д. В этом случае тоже надо продумать коммуникацию между ними.
5+6) Рекомендуется оценивать сроки именно человеку, который будет это все реализовывать (в этом случае сроки самые маленькие получаются). Можно дать возможность команде на 1-м этапе составить ТЗ и примерные сроки. Потом дать им возможность или сменить проект или разработать его. За разработку ТЗ давать некий % от цены.
В этом случае есть есть несколько вариантов:
1) Разработал ТЗ и реализовал — все хорошо
2) ТЗ, но без реализации — в этом случае можно брать другую команду, пускай она оценит сама сроки и реализовывает (тут можно и по срокам сравнить).
3) Находишь проект с ТЗ и делаешь его.
Т.е. получается самоорганизация: Ты или только с ТЗ можешь работать, или только по ТЗ, или полный цикл. Все сами выбирают то, что им больше нравится и лучше получается (врятли любитель составлять ТЗ, но у которого это не выходит сумеет «продать» свое ТЗ другой команде).
Еще надо продумать момент, что иногда у команд разные спецификации. Скажем, одна — программисты, другая — дизайнеры/тестеры и т.д. В этом случае тоже надо продумать коммуникацию между ними.
1) А вот как раз разницу в трудозатратах надо продумать очень тщательно. Но, думаю, грамотно выбранная стратегия «перехода» из команды в команды может сильно помочь и упростить это все.
Как вариант — строгое деление команд по «модульному» признаку. Например:
Надо сделать сайт. Что мы имеем:
На 1-м этапе работает команда PM, она разрабатывает ТЗ и продумывает все, что надо.
Потом к ней подсоединяются, скажем, команды «кодеров» и дизайнеров. Идет активная стадия разработки.
И на последнем этапе подключается команда тестеров. При этом команда PM на всех этапах не покидает проект. Они и кодируют, и дизайном занимаются и т.д. (какой же ты специалист, если не занимаешься практическим применением своих навыков. Пусть будут «старшими» товарищами для остальных). В этом случае команда PM полностью контролирует процесс разработки, она определяет численность команды и ее специфику.
Если команды делать небольшими (скажем, по 3-5 человек), то можно довольно «динамично» варьировать текущую нагрузку по проекту. А когда кто-нибудь решит, что он готов к образованию своей команды — у него все карты на руках :)…
Как вариант — строгое деление команд по «модульному» признаку. Например:
Надо сделать сайт. Что мы имеем:
На 1-м этапе работает команда PM, она разрабатывает ТЗ и продумывает все, что надо.
Потом к ней подсоединяются, скажем, команды «кодеров» и дизайнеров. Идет активная стадия разработки.
И на последнем этапе подключается команда тестеров. При этом команда PM на всех этапах не покидает проект. Они и кодируют, и дизайном занимаются и т.д. (какой же ты специалист, если не занимаешься практическим применением своих навыков. Пусть будут «старшими» товарищами для остальных). В этом случае команда PM полностью контролирует процесс разработки, она определяет численность команды и ее специфику.
Если команды делать небольшими (скажем, по 3-5 человек), то можно довольно «динамично» варьировать текущую нагрузку по проекту. А когда кто-нибудь решит, что он готов к образованию своей команды — у него все карты на руках :)…
>> первую сессию тоже многие заваливают, от новизны ситуации — никто не стоит над душой; но потом ведь учатся!
Окститесь, в первую сессию все её обычно сдают, как раз из-за того, что «надо готовиться ко встрече со звездой», а потом уже, попривыкши, на расслабухе таскаются на пересдачи.
Окститесь, в первую сессию все её обычно сдают, как раз из-за того, что «надо готовиться ко встрече со звездой», а потом уже, попривыкши, на расслабухе таскаются на пересдачи.
По сути описана вариация на тему того, что нынче называется удаленной работой
… если убрать расстояние между заказчиком и исполнителем, но оставить принцип взаимодействия — как раз получится описанное. То есть удаленка это некий полуфриланс+полупостоянная работа на расстоянии. По слухам, попадаются дотошные заказчики, которые хотят контролировать каждый чих даже по удаленке, но всё равно при удаленке больше свободы.
Требования по skill'ам на следующую итерацию можно публиковать, чтобы люди могли планировать свою занятость на следующий период. Ну тут можно ещё много чего навыдумывать…
Для написания этой статьи были необходимы следующие скиллы:
Программирование: 5
Менеджмент: 10
Грамотность: 5 (+ артефакт проверка орфографии +3)
=)
«Модель отношений «я начальник-ты дурак» малопригодна для сферы IT, где люди отличаются интеллектом по определению.»
Что за бред, дальше даже читать не стал.
Что за бред, дальше даже читать не стал.
Работа программиста более творческая, чем привыкли думать. И как в любом творчестве тут важна самореализация. Если строить центролизированное управление, то сотрудники зачахнут и производительность упадёт.
Нет, я не спорю. Тут напрягает фраза «где люди отличаются интеллектом по определению». Это, типо, врачи, дизайнеры, инженеры, переводчики и т.д. дураки? IT профессия такая же профессия как и выше указанные. А данная фраза создает впечатление какое-то нетакое что ли.
Ну имелось в виду известное сравнение процесса разработки ПО с фабрикой. И разработчики противопоставлялись занятым на конвейере рабочим.
Никого не хотел обидеть.
Никого не хотел обидеть.
Имелось ввиду «не лезь, коли не знаешь», про начальников и манагеров.
Тут на все сто согласен. Но опять же не факт, что начальник «не знает». Меня, самого напрягают некие вторжение из вне. Но нужно понять, что программист, дизайнер — это творческие личности — да, но никак не люди искусства. И готовый продукт может быть очень крутым, но цель то не сделать его крутым, а продать. Тут то и манагеры приходят на помощь и вот принижать их «помощь» не всегда уместно.
Неправильная формулировка.
«Отличаются интеллектом» не от всех остальных профессий, а внутри компании, внутри команды.
Пусть автор пояснит, что имелось ввиду.
«Отличаются интеллектом» не от всех остальных профессий, а внутри компании, внутри команды.
Пусть автор пояснит, что имелось ввиду.
Да, похоже необходимо пояснение. Имелась в виду, что в разработке как раз очень важно заинтересованное участие разработчика в процессе. Именно он, а не руководитель может знать лучший подход в решении возникшей проблемы. Цель PM — дать проявиться этой творческой инициативе. Или, если не можешь помочь прорасти, хотя бы не давить.
Думаю автор хотел сказать, что программист одна из хитровы.банных профессий и их так просто не построишь.
Для среды ИТ скорее характерно смешивание «я начальник-ты дурак» и творчества. Т.е. из… нись как хочешь, но сделай то, что сказали :)
Вопросов действительно больше чем ответов. При такой схеме работы должны быть люди которые изначально видят весь проект, чтобы мочь сделать его декомпозицию на разных исполнителей и при этом подстраховаться от их ухода, передачи знаний третьим лицам и т. д.
Много уже сказали про планирование и ТЗ.
Моделью, которую предлагает автор, можно дополнить тот же SCRUM, в котором довольно большое внимание уделяется планированию. То есть от SCRUM взять «итерации», этап планирования и «done criterias».
Моделью, которую предлагает автор, можно дополнить тот же SCRUM, в котором довольно большое внимание уделяется планированию. То есть от SCRUM взять «итерации», этап планирования и «done criterias».
В целях обеспечения минимального гарантированного дохода и соблюдения законодательства можно сформировать своего рода внутренний резервный фонд и внутреннюю квазивалюту. Вначале новому сотруднику выдается своего рода кредит, который он должен окупить за испытательный срок; затем условия могут пересматриваться по мере повышения. Если сотрудник ушел ниже минимальной суммы кредитов из-за лени или штрафов, поначалу он кредитуется (выговор), а при падении ниже нуля вообще может быть уволен за невыполнение служебных обязанностей — кредиты используются только во внутреннем учете начисления премий и никакого трудового законодательства не нарушают. Впрочем, это типичная схема начисления бонусов; самое главное начинается тогда, когда в компании формируются своего рода рынки — внутренний и внешний (продажа конечного продукта за «валюту», то есть реальные деньги), внутренняя бюджетно-социальная политика, а в будущем и эволюция политической власти от абсолютной монархии к чему-то более демократическому. В конечном итоге такая компания представляет собой разноплановое сообщество полуавтономных подразделений (кстати, она может эволюционировать как из традиционной компании, так и из фрилансерских команд, которые объединяются в «клубы» для более эффективного продвижения своих интересов).
C моей точки зрения «Гарантированный доход» при постоянной занятости — не более, чем самоуспокоительная фикция. Если у работодателя начнутся проблемы с количеством заказчиков, и босс посчитает, что 3 кодера сравятся с работой, а 4-й не нужен — четвертый кодер начнет понимать значения слова «гарантированный» через 24 часа после решения начальника. Также работник может заболеть (тьфу-тьфу-тьфу) — сильно больные работники никому не нужны, принесут один раз конверт и будут считать что долг выполнили. Работник может рассориться с начальником на корпоративном выпивоне. Или просто, наступит «ротация».
Все. И работник лишается не только «гарантированного», но и просто «дохода». Конечно, рано или поздно он устроится на новую работу, но всякое бывает…
Фрилансер же, имея 10 клиентов, теряя одного клиента — теряет не смысл существования, а всего лишь 10% «негарантированного дохода». Потерять же в короткий срок всех десятерых клиентов — и не приобрести новых — по теории вероятности более маловероятное событие, чем вылететь из офиса.
Все. И работник лишается не только «гарантированного», но и просто «дохода». Конечно, рано или поздно он устроится на новую работу, но всякое бывает…
Фрилансер же, имея 10 клиентов, теряя одного клиента — теряет не смысл существования, а всего лишь 10% «негарантированного дохода». Потерять же в короткий срок всех десятерых клиентов — и не приобрести новых — по теории вероятности более маловероятное событие, чем вылететь из офиса.
Зачем компания нанимает людей на постоянную работу?
* они обучаются общим стандартам, методикам, инструментам компании — уменьшается стоимость обучения людей для каждого проекта
* компания может управлять занятостью человека: убрать его из одного проекта, направить на другой, и т.п.
* уменьшаются транзакционные издержки (на согласование всех деталей, постоянную проверку, ...).
* наверное что-то ещё.
Поскольку в предложенном варианте не гарантируется занятость каждого человека, оплата идёт за сделанное, из всех преимуществ постоянной работы в компании остаётся разве что знакомство с общими технологиями, но это ещё нужно постараться, чтобы оно сохранилось.
Т.е. разница между этим подходом и обычным наймом фрилансеров — только в наличии неких общих правил работы, которые всеми соблюдаются и всем понятны.
Это будет сложно заставить работать.
Но пробовать стоит.
* они обучаются общим стандартам, методикам, инструментам компании — уменьшается стоимость обучения людей для каждого проекта
* компания может управлять занятостью человека: убрать его из одного проекта, направить на другой, и т.п.
* уменьшаются транзакционные издержки (на согласование всех деталей, постоянную проверку, ...).
* наверное что-то ещё.
Поскольку в предложенном варианте не гарантируется занятость каждого человека, оплата идёт за сделанное, из всех преимуществ постоянной работы в компании остаётся разве что знакомство с общими технологиями, но это ещё нужно постараться, чтобы оно сохранилось.
Т.е. разница между этим подходом и обычным наймом фрилансеров — только в наличии неких общих правил работы, которые всеми соблюдаются и всем понятны.
Это будет сложно заставить работать.
Но пробовать стоит.
Можно попробовать, как и в стартапах, ввести некоторые внутренние акции. Акции за каждый этап раздаются заново согласно совместной договоренности и распределенной ответственности.
Деньги за каждый закрытый этап будут распределяться согласно количеству акций на руках.
Свои акции можно отдавать, делегируя ответственность другим членам команды. Таким образом решается вопрос срыва сроков.
Периодические собрания могут легко решать перераспределения акций в форс-мажорных случаях, например, если человек не справляется, но не хочет делиться своими акциями.
В случае возникновения доработок или обнаружения багов, вся команда решает, стоит ли их рассматривать как дополнительные ( все скидываемся акциями) или как чей-то косяк.
Деньги за каждый закрытый этап будут распределяться согласно количеству акций на руках.
Свои акции можно отдавать, делегируя ответственность другим членам команды. Таким образом решается вопрос срыва сроков.
Периодические собрания могут легко решать перераспределения акций в форс-мажорных случаях, например, если человек не справляется, но не хочет делиться своими акциями.
В случае возникновения доработок или обнаружения багов, вся команда решает, стоит ли их рассматривать как дополнительные ( все скидываемся акциями) или как чей-то косяк.
Ну вообще практическая реализация уже есть, у меня допустим и я знаю ещё пару человек (они тут есть и если пожелают отпишутся) у которых также всё организовано.
Я ранее писал о том как у нас fenixdeveloper.habrahabr.ru/blog/60460/, но немного в другом ключе.
Из минусов есть проблема с финансовым вопросом. Вот допустим как в фирмах с этим: известна ставка стоимости человеко-часа, в которой учтены все расходы + рентабельность. Дальше определяется срок исполнения проекта, высчитываются необходимые человеко-часы и получается нужная сумма, которая уже варьируется тем кто договаривается в большую (зачастую сразу), а иногда в меньшую сторону чтобы договориться если стратегически важный проект.
В описанной вами ситуации бюджет необходимо распределить между исполнителями, не забыв при этом менеджера или менеджеров (для больших проектов), также бухгалтерию и прочих сотрудников, а ведь ещё есть аренда помещения (если эта компания в офисе сидит, а не дома) и куча других расходов. То есть приходится делать весь бюджет проекта на 2 части — часть которая идёт в оплату конечным исполнителям, и часть на расходы компании и её же прибыль. Но такой делёж достаточно сложен.
У меня это решается немного по другому: всё как везде, но минимальные зарплаты, а с каждого проекта назначается премия, которая в зависимости от работы изменяется в большую или меньшую сторону. С этой стороны хорошо ещё то, что сохраняются социальные гарантии, типа выплаты больничных, отпускных, или если человек отправился на обучение/повышение квалификации, за ним сохраняется его минимальный оклад. Но есть и сотрудники без трудоустройства, именно фрилансеры и их свобода не ограничивается, по мере надобности кто свободен присоединяется к проекту. Такая структура очень гибкая и удобная на мой взгляд. Бывают некоторые сложности с коммуникацией, организацией, но это уже решается опытом совместной работы и сходит на нет со временем.
Я ранее писал о том как у нас fenixdeveloper.habrahabr.ru/blog/60460/, но немного в другом ключе.
Из минусов есть проблема с финансовым вопросом. Вот допустим как в фирмах с этим: известна ставка стоимости человеко-часа, в которой учтены все расходы + рентабельность. Дальше определяется срок исполнения проекта, высчитываются необходимые человеко-часы и получается нужная сумма, которая уже варьируется тем кто договаривается в большую (зачастую сразу), а иногда в меньшую сторону чтобы договориться если стратегически важный проект.
В описанной вами ситуации бюджет необходимо распределить между исполнителями, не забыв при этом менеджера или менеджеров (для больших проектов), также бухгалтерию и прочих сотрудников, а ведь ещё есть аренда помещения (если эта компания в офисе сидит, а не дома) и куча других расходов. То есть приходится делать весь бюджет проекта на 2 части — часть которая идёт в оплату конечным исполнителям, и часть на расходы компании и её же прибыль. Но такой делёж достаточно сложен.
У меня это решается немного по другому: всё как везде, но минимальные зарплаты, а с каждого проекта назначается премия, которая в зависимости от работы изменяется в большую или меньшую сторону. С этой стороны хорошо ещё то, что сохраняются социальные гарантии, типа выплаты больничных, отпускных, или если человек отправился на обучение/повышение квалификации, за ним сохраняется его минимальный оклад. Но есть и сотрудники без трудоустройства, именно фрилансеры и их свобода не ограничивается, по мере надобности кто свободен присоединяется к проекту. Такая структура очень гибкая и удобная на мой взгляд. Бывают некоторые сложности с коммуникацией, организацией, но это уже решается опытом совместной работы и сходит на нет со временем.
«Свобода выбора заданий» разработчиками в рамках компании, производящей конечный продукт (а не работающей на сторонних заказах — 2 сайта в месяц и т.п.) имеет огромное количество минусов.
а) Задания, которые объективно делать никому не хочется (рутина, «портирование» кода и т.п., где креатива/свободы разработчика минимум)
б) пришел новый разработчик(пусть и достаточно высокого уровня, но мы этого не знаем) — он сразу хочет сложные задания (ему это интересно), хочет большей свободы — в результате получается код, отличный от «привычного» в компании, плюс сроки так же плавают.
в) конкуренция за задачи. распределение путем «торга» среди разработчиков кто предложит меньшую цену/время? качественную реализацию? внутрикорпоративный тендер? :) куча вопросов, в общем.
Опять же люди чувствуют конкуренцию со стороны друг друга, что местами не очень правильно, и возникает мотивация «лучше закончить свою часть быстрее, чем помогать коллеге».
У фриланса есть свои плюсы, есть свои плюсы и у «постоянной занятости», что хорошо описано в посте, но мешать их, имхо, не очень правильно — именно в рамках компаний со «стабильными» долговременными проектами. Командная работа, коллегиальные решения и распределение задач прекрасно работают и достаточно мотивируют на собственное развитие (больше знаешь — интереснее подзадачи получаешь). Тем более, что и другие средства мотивации никто не отнимал.
а) Задания, которые объективно делать никому не хочется (рутина, «портирование» кода и т.п., где креатива/свободы разработчика минимум)
б) пришел новый разработчик(пусть и достаточно высокого уровня, но мы этого не знаем) — он сразу хочет сложные задания (ему это интересно), хочет большей свободы — в результате получается код, отличный от «привычного» в компании, плюс сроки так же плавают.
в) конкуренция за задачи. распределение путем «торга» среди разработчиков кто предложит меньшую цену/время? качественную реализацию? внутрикорпоративный тендер? :) куча вопросов, в общем.
Опять же люди чувствуют конкуренцию со стороны друг друга, что местами не очень правильно, и возникает мотивация «лучше закончить свою часть быстрее, чем помогать коллеге».
У фриланса есть свои плюсы, есть свои плюсы и у «постоянной занятости», что хорошо описано в посте, но мешать их, имхо, не очень правильно — именно в рамках компаний со «стабильными» долговременными проектами. Командная работа, коллегиальные решения и распределение задач прекрасно работают и достаточно мотивируют на собственное развитие (больше знаешь — интереснее подзадачи получаешь). Тем более, что и другие средства мотивации никто не отнимал.
Один маленький нюанс.
Получается, если один из членов команды «проваливает» сроки — то пеню получает вся команда. При этом все остальные члены не виноваты.
Как тут быть?
Получается, если один из членов команды «проваливает» сроки — то пеню получает вся команда. При этом все остальные члены не виноваты.
Как тут быть?
Ну вы же понимаете, что это невозможно? ;) Я имею в виду в реальной жизни и с реальными правовыми отношениями?
Я не менеджер, но чем это отличается от обычного аутсорсинга?
Только у меня такое чувство, что множество плюсов — это минусы, а минусов — плюсы?
А с блогом не ошиблись?
Имхо, это в какой-нибудь блог для работодателей или про бизнес, и название лучше поменять.
Увидев в блоге «Учись работать» статью с таким названием, я ожидал прочитать о том, как совместить фриланс и полную занятость, т.е. работать и в офисе «на дядю», и фрилансить на себя — я как раз подумываю о таком.
Имхо, это в какой-нибудь блог для работодателей или про бизнес, и название лучше поменять.
Увидев в блоге «Учись работать» статью с таким названием, я ожидал прочитать о том, как совместить фриланс и полную занятость, т.е. работать и в офисе «на дядю», и фрилансить на себя — я как раз подумываю о таком.
На данный момент мы работаем по схожей схеме (уже 3й год) и я планирую ее пересматривать. Эта схема оказалась интересной на ранней стадии развития, когда все работают вместе, в одном офисе, но действует правило «работу сделал до конца — получил деньги». И эта схема действительно очень хорошо мотивирует, а сотрудники могут работать сколько хотят и когда хотят.
Проблемы возникают в тот момент, когда самое ответственное лицо (пм) начинает забивать на свои обязательства и перестает качественно держать связь с клиентом. И начиная с этого момента страдают все и никто не получает деньги во время.
Эта схема просто отлично работает для конечных исполнителей, но для pm'a она должна дополнительно содержать очень жесткую пеню, но кто тогда согласиться работать по такой схеме? :)
Проблемы возникают в тот момент, когда самое ответственное лицо (пм) начинает забивать на свои обязательства и перестает качественно держать связь с клиентом. И начиная с этого момента страдают все и никто не получает деньги во время.
Эта схема просто отлично работает для конечных исполнителей, но для pm'a она должна дополнительно содержать очень жесткую пеню, но кто тогда согласиться работать по такой схеме? :)
А смысл? Почему при такой схеме тогда не уйти полностью во фриланс?
Как известно, фиксированная оплата выгодна работодателю именно из-за покупки ваших услуг оптом по низкой цене, при этом работодатель берет на себя риски, что в общем-то справедливо.
Я бы не пошел работать в такую контору. Это значит я должен работать за теже малые деньги, но беря на себя риски работодателя. Нет, спасибо
Как известно, фиксированная оплата выгодна работодателю именно из-за покупки ваших услуг оптом по низкой цене, при этом работодатель берет на себя риски, что в общем-то справедливо.
Я бы не пошел работать в такую контору. Это значит я должен работать за теже малые деньги, но беря на себя риски работодателя. Нет, спасибо
Несмотря на описанные предыдущими комментаторами минусами, идея отличная, но в первую очередь для работника, а какие плюсы получит работодатель?
Как представляется мне, тема затронутая ближе к концу поста — «чтобы верхи захотели, а низы смогли» является главной проблемой, которая будет препятствовать внедрению этой схемы.
Как представляется мне, тема затронутая ближе к концу поста — «чтобы верхи захотели, а низы смогли» является главной проблемой, которая будет препятствовать внедрению этой схемы.
Подскажите, где и как вообще стоит искать адекватного PM-а? По-моему, это человек от которого на 90% зависит успешная реализация проекта. Но тогда встает вопрос: как выбрать его и снизить вероятность ошибки?
Учиться на своем опыте получается слишком дорого…
Учиться на своем опыте получается слишком дорого…
К наиболее популярным атакам без сомнения можно отнести этот популярный способ, когда веб-сервер переполняется запросами от ботов и не может нормально обслуживать запросы посетителей.
В результате такой атаки сайт становится недоступным, а с серверной стороны можно наблюдать рост нагрузки на сервер, большое число процессов веб-сервера и конечно, значительный рост коннектов. Если атака будет очень сильной и паразитный трафик превысит пропускную способность канала к серверу, то на него нельзя будет зайти по ssh.
Но столь сильные атаки — редкость, так как 10-20Mbps такого трафика вполне способны свалить неподготовленный сервер.
Способов борьбы с такими атаками очень много, как программных так и аппаратных. Кроме этого существуют отдельные сервисы, которые «чистят» трафик, присылая только легальные запросы.
Я же хочу рассмотреть очень простой и элегантный способ борьбы, для которого нам потребуется nginx и iptables с модулем string.
Слабое место ботов в том, что они не понимают кукисы. На этой особенности и основана моя система защиты. Мы будем передавать на все запросы к веб-серверу «печеньку», и разделять трафик на легальный и мусорный, основываясь именно на этом параметре.
Сначала нужно будет спрятать веб-сервер, например повесив на 8080 порт, а на его место поставить быстрый nginx, и сконфигурировать страницу-заглушку. В качестве примера подойдет стандартный конфиг nginx, единственное, что нужно сделать — добавить cookie, дописав в конфиге nginx:
add_header Set-Cookie «type=this-is-not-bot»;
На самой странице-заглушке можно написать нечто вроде «Извините, сайт под DDOS, включите кукисы в браузере и нажмите на ссылку для перехода».
Когда посетитель откроет такую страницу, то при следующем запросе он передаст эту «печеньку», на основе которой можно направить трафик к спрятанному веб-серверу:
iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string «this-is-not-bot» --algo kmp -j REDIRECT --to-ports 8080
Разумеется, что для нормальной работы сайта не следует забывать передавать в кукисах эту заветную строчку.
Ожидали чего-то более сложного? Извините…
P.S. Поисковые боты не принимают кукисы, так что будет вполне разумно сделать для них заблаговременное исключение.
В результате такой атаки сайт становится недоступным, а с серверной стороны можно наблюдать рост нагрузки на сервер, большое число процессов веб-сервера и конечно, значительный рост коннектов. Если атака будет очень сильной и паразитный трафик превысит пропускную способность канала к серверу, то на него нельзя будет зайти по ssh.
Но столь сильные атаки — редкость, так как 10-20Mbps такого трафика вполне способны свалить неподготовленный сервер.
Способов борьбы с такими атаками очень много, как программных так и аппаратных. Кроме этого существуют отдельные сервисы, которые «чистят» трафик, присылая только легальные запросы.
Я же хочу рассмотреть очень простой и элегантный способ борьбы, для которого нам потребуется nginx и iptables с модулем string.
Слабое место ботов в том, что они не понимают кукисы. На этой особенности и основана моя система защиты. Мы будем передавать на все запросы к веб-серверу «печеньку», и разделять трафик на легальный и мусорный, основываясь именно на этом параметре.
Сначала нужно будет спрятать веб-сервер, например повесив на 8080 порт, а на его место поставить быстрый nginx, и сконфигурировать страницу-заглушку. В качестве примера подойдет стандартный конфиг nginx, единственное, что нужно сделать — добавить cookie, дописав в конфиге nginx:
add_header Set-Cookie «type=this-is-not-bot»;
На самой странице-заглушке можно написать нечто вроде «Извините, сайт под DDOS, включите кукисы в браузере и нажмите на ссылку для перехода».
Когда посетитель откроет такую страницу, то при следующем запросе он передаст эту «печеньку», на основе которой можно направить трафик к спрятанному веб-серверу:
iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string «this-is-not-bot» --algo kmp -j REDIRECT --to-ports 8080
Разумеется, что для нормальной работы сайта не следует забывать передавать в кукисах эту заветную строчку.
Ожидали чего-то более сложного? Извините…
P.S. Поисковые боты не принимают кукисы, так что будет вполне разумно сделать для них заблаговременное исключение.
Работал по примерно похожей схеме. Я был в штате, получал фикс + управлял своей командой которая была на фрилансе (+ я получал еще процент от заказа).
Вначале все было идеально, потом ситуация пошла вразнос.
Мной, как штатным сотрудником пытались заткнуть все возможные дыры. Доходило до абсурда. Я получал втык от генерального, зато, что слишком громко работают телефоны в офисе. На мой вопрос, а причем тут ПМ — получал ответ — «Ну ты же главный по ИТ».
В итоге, из-за перерывов (не по моей вине) в работе, финасирование было заморожено — команда ушла на другие проекты. Когда работы были возобновлены и начался аврал (конечных сроков никто не отменял) работать было просто не кому. В итоге, на меня постарались повесить всех собак и обвинить во всех смертных грехах. Проект без меня так и не завершили.
Из этго я вынес то, что работать нужно только находясь во вне и заключая договора между юр. лицами с прописыванием всех возможных пунктов, вроде остановки работ, порядка разрешения споров, ПМИ и.т.п.
Надеюсь мой опыт кому-то поможет не наступать на те же самые грабли. Удачи.
Вначале все было идеально, потом ситуация пошла вразнос.
Мной, как штатным сотрудником пытались заткнуть все возможные дыры. Доходило до абсурда. Я получал втык от генерального, зато, что слишком громко работают телефоны в офисе. На мой вопрос, а причем тут ПМ — получал ответ — «Ну ты же главный по ИТ».
В итоге, из-за перерывов (не по моей вине) в работе, финасирование было заморожено — команда ушла на другие проекты. Когда работы были возобновлены и начался аврал (конечных сроков никто не отменял) работать было просто не кому. В итоге, на меня постарались повесить всех собак и обвинить во всех смертных грехах. Проект без меня так и не завершили.
Из этго я вынес то, что работать нужно только находясь во вне и заключая договора между юр. лицами с прописыванием всех возможных пунктов, вроде остановки работ, порядка разрешения споров, ПМИ и.т.п.
Надеюсь мой опыт кому-то поможет не наступать на те же самые грабли. Удачи.
Я тут писал давно свои мысли об автоматизации рабочего процесса:
speakus.net/node/25
Мысли тоже нацеленны на убирание недостатков полной занятости.
Если заинтересовало — велкам в личку
speakus.net/node/25
Мысли тоже нацеленны на убирание недостатков полной занятости.
Если заинтересовало — велкам в личку
> Устанавливаем для каждого за раннее завершение бонус (размер определяется индивидуально), а за срыв сроков — пени (здравствуй Мотивация, слава Богу ты пришла!:)
вы только что изобрели прогрессивно-повремённую оплату труда и штрафные санкции
о да! это прорыв
вы только что изобрели прогрессивно-повремённую оплату труда и штрафные санкции
о да! это прорыв
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как подружить фриланс и полную занятость?