Совместим ли гибкий подход с наличием подрядчиков в штате?

С одной стороны, гибкий подход подчеркивает сплоченную команду, которая подотчетна друг другу и принимает коллективное участие в проекте.

С другой стороны, компании используют программистов по контракту, чтобы они могли управлять пиками и долями финансирования, не увольняя реальных сотрудников. Если существует дефицит финансирования, подрядчики первыми уходят, даже если они являются полностью интегрированными членами команды (а есть сотрудники, которых нет). Компаниям также нравится держать подрядчиков в течение ограниченного периода времени. Это несколько смягчается тем, что некоторые подрядчики могут быть привлечены в качестве постоянных сотрудников.

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

РЕДАКТИРОВАТЬ: ответы показывают, что я, возможно, не выразил напряженность, с которой я сталкиваюсь хорошо, поэтому позвольте мне сделать еще один выстрел.

Я постоянный работник. Гибкий подход (по крайней мере, как он реализован здесь) побуждает меня видеть всех членов команды, как постоянных сотрудников, так и подрядчиков, в качестве равных членов сплоченной команды. Корпоративный подход к подрядчикам побуждает меня рассматривать их как расходуемые ресурсы, к которым мы не должны чрезмерно привязываться.

Мне любопытно, как другие решили это напряжение.

Многие команды работают только с проворными подрядчиками. Некоторые компании, такие как ThoughtWorks, основаны на идее «продавать» гибкие команды. Мы команда из 10 подрядчиков, работающих на большую телекоммуникационную компанию, все из одной подрядной компании.

Я видел проблемы, когда в одной команде было две компании по аренде кузовов ... через некоторое время команда стала проблематичной (в любом случае, это не имеет ничего общего с гибкой).

Да, это определенно может работать. Хитрость заключается в том, чтобы:

a) Правильно структурируйте договор о заключении договора - если вы платите за сдельную работу, тогда подрядчики мало заинтересованы в том, чтобы делать гораздо больше, чем просто складывать вещи, чтобы тратить меньше времени на «работу».
b) Продать своему руководству не каждый цент, за который они платят. идет непосредственно в продукт - там будет некоторое обучение / планирование / обсуждение, которое будет на часах и в конечном счете улучшит указанный продукт. Это была самая сложная часть для меня.
c) Подберите подходящих подрядчиков - вся проворная вещь начнет окупаться, если вы сможете постоянно нанимать одну и ту же команду.

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

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

С точки зрения команды разработчиков, нет разницы между подрядчиком и работником. Мы все в одной команде, и у всех нас одна цель. Добавление и удаление членов команды будет иметь одинаковое нарушение, будь то сотрудники или подрядчики. Все члены команды имеют одинаковые обязанности.

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

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

Предыдущий ответ

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

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

То, что сводится к тому, что вы будете получать первоначальный удар производительности, когда вы нанимаете новых разработчиков и подрядчиков, пока они не наберут скорость. Чем больше вы это делаете, тем больше это негативно влияет на производительность вашей команды. Hense, старая поговорка «Добавление большего количества разработчиков в уже опоздавший проект делает его позже». (Я полагаю, что это был Фред Брукс, если он не цитировал кого-то еще).

Как подрядчик, который очень заботится о Agile и производит отличное программное обеспечение, я могу пообещать, что есть подрядчики, которые никогда не будут выпускать код без промедления, если они могут ему помочь, и всегда вкладывают свое сердце во все, над чем они работают.

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

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

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

Тем не менее, это может работать, когда подрядчики не являются временными. Я работал над проектом, где команда была построена на 95% подрядчиков с одним или двумя сотрудниками. Подрядчики были там в течение 2 или 3 лет, пока проект не будет выпущен. После освобождения сотрудники проводят техническое обслуживание. Этот способ работы очень распространен.

Обобщить:

Agile, и особенно Scrum, обеспечат все свои преимущества в стабильной команде .