Czy podejście zwinne jest zgodne z zatrudnianiem kontrahentów?

Z jednej strony zwinne podejście kładzie nacisk na zgrany zespół, który wzajemnie się rozlicza i akceptuje zbiorową własność projektu.

Z drugiej strony firmy korzystają z programistów kontraktowych, aby mogli zarządzać szczytami i dolinami finansowania bez zwalniania rzeczywistych pracowników. Jeśli brakuje środków, wykonawcy są pierwszymi, nawet jeśli są w pełni zintegrowanymi członkami zespołu (a nie ma pracowników). Firmy lubią też utrzymywać kontrahentów tylko przez ograniczony czas. Jest to nieco złagodzone przez to, że niektórzy kontrahenci mogą zostać zatrudnieni jako stali pracownicy.

Tak więc moje pytanie, czy istnieje fundamentalna sprzeczność posiadania zwinnego zespołu z mieszanką pracowników i kontrahentów, a także bardzo różne statusy, które się z tym wiążą?

EDYCJA: Odpowiedzi wskazują, że mogłem nie wyrazić napięcia, z którym mam do czynienia, więc pozwól mi zrobić jeszcze jedno zdjęcie.

Jestem stałym pracownikiem. Podejście zwinne (przynajmniej tak jak tu wdrożone) zachęca mnie do postrzegania wszystkich członków zespołu, zarówno stałych pracowników, jak i kontrahentów, jako równych członków spójnego zespołu. Korporacyjne podejście do kontrahentów zachęca mnie do postrzegania ich jako zasobów do wydatkowania, do których nie powinniśmy się nadmiernie przywiązywać.

Jestem ciekawy, jak inni rozwiązali to napięcie.

Wiele zespołów pracuje tylko ze sprawnymi kontrahentami. Niektóre firmy, takie jak ThoughtWorks, bazują na pomyśle „sprzedaży” zwinnych zespołów. Jesteśmy zespołem 10 wykonawców pracujących dla dużego operatora telekomunikacyjnego, wszyscy z tej samej firmy wykonawczej.

Kiedy widziałem problemy, były dwie firmy wynajmujące ciała w tym samym zespole ... po pewnym czasie zespół stał się problematyczny (zresztą i tak nie ma to nic wspólnego ze zwinnością).

Tak, to zdecydowanie może zadziałać. Sztuką jest:

a) Właściwie ustrukturyzuj umowę - jeśli płacisz za pracę akordową, wówczas kontrahenci nie są zainteresowani robieniem czegoś więcej niż tylko łączeniem rzeczy w celu poświęcenia mniejszej liczby godzin na „część”
b) Sprzedaj swoje zarządzanie, że nie za każdy cent, za który płacą idzie bezpośrednio do produktu - odbędzie się szkolenie / planowanie / dyskusja, która odbędzie się na czas i ostatecznie poprawi ten produkt. To była dla mnie najtrudniejsza część.
c) Wybierz odpowiednich kontrahentów - cała zwinność zaczyna się opłacać, jeśli możesz stale zatrudniać tę samą załogę.

Generalnie twierdziłbym również, że tego rodzaju scenariuszowi bardzo pomagają zwinne praktyki - jeśli ludzie cały czas przychodzą i wychodzą z zespołu, możliwość sprawdzenia się, odpalenia i rozpoczęcia kodowania jest nawet ważniejsza niż w przeciwnym razie .

W odpowiedzi na Twoją edycję istnieją różne zestawy oczu, aby spojrzeć na sytuację. Aby więc wyjaśnić wszelkie potencjalne nieporozumienia, pomaga zrozumieć, które perspektywy mają zastosowanie.

Z punktu widzenia zespołu programistów nie ma różnicy między kontrahentem a pracownikiem. Wszyscy jesteśmy w tym samym zespole i wszyscy mamy ten sam cel. Dodawanie i usuwanie członków zespołu będzie miało takie same zakłócenia, niezależnie od tego, czy są oni pracownikami czy kontrahentami. Wszyscy członkowie zespołu mają takie same obowiązki.

Z punktu widzenia zarządzania istnieje różnica. Firma stara się chronić swój najcenniejszy zasób - pracowników. Z tego powodu firma będzie wolała trzymać swoich pracowników nad kontrahentami. Jeśli wykonawca okaże się bezcenny dla zespołu, firma prawdopodobnie spróbuje przekształcić go w pracownika. Tego rodzaju decyzje obowiązują poza codziennym procesem rozwoju.

Zwinne procesy są bardziej zainteresowane codziennymi działaniami programistycznymi i zarządzaniem sposobem dostarczania wysokiej jakości produktu. Zwinne procesy są mniej związane z obowiązkami zarządczymi, takimi jak decyzje dotyczące wynajmu / pożaru / umowy, a bardziej z tym, jak wykorzystujemy dostępne zasoby.

Poprzednia odpowiedź

Nie jest to fundamentalna sprzeczność, ale stanowi pewne wyzwanie treningowe. Zwinne procesy sprzyjają bardzo naturalnemu środowisku mentoringowemu. Zasadniczo programiści mogliby zawsze być głosem doświadczenia - przynajmniej w odniesieniu do kultury korporacyjnej i specyfiki zwinności zespołu.

Regularne odpływy i przepływ programistów kontraktowych będą stanowić te same wyzwania, niezależnie od tego, czy jesteś zwinny, czy nie. Musisz poinformować pracownika kontraktowego o tym, jak prowadzisz działalność - obejmuje to procesy programistyczne i fakturowanie. Musisz edukować programistę kontraktowego na temat obecnego projektu systemu, aby mógł on jak najszybciej zacząć wnosić wkład. Nadzieją jest to, że pracownicy kontraktowi są Szybkie badania i może zacząć przyczyniając się do projektu bardzo szybko. Szkolenie w miejscu pracy (OJT) działa tutaj całkiem dobrze.

Sprowadza się to do tego, że zatrudnisz nowych programistów i wykonawców, dopóki nie osiągną oni szybkości. Im częściej to robisz, tym bardziej negatywnie wpływa to na wydajność Twojego zespołu. Hense, stare powiedzenie „Dodanie większej liczby programistów do już spóźnionego projektu sprawia, że ​​później”. (Myślę, że to był Fred Brooks, chyba że cytował kogoś innego).

Jako kontrahent, który bardzo dba o Agile i produkuje doskonałe oprogramowanie, mogę obiecać, że są kontrahenci, którzy nigdy nie stworzą kodu slap-dash, jeśli mogą mu pomóc, i zawsze wkładają serce w to, nad czym pracują.

Sztuką jest znalezienie tych kontrahentów. Poszukaj dowodów na to, że są gotowi pójść o krok dalej - blogi, rozmowy, materiały open source, warsztaty, rekomendacje itp. Zapytaj o ich wcześniejsze doświadczenia z Agile i poszukaj dowodów na to, że kochają swoją pracę. Zasadniczo rozumiemy, że jesteśmy tymczasowymi pracownikami, a niektórzy z nas lubią to, wykorzystując czas między umowami do doskonalenia naszych umiejętności i poszerzania naszej wiedzy.

Jeśli znajdziesz naprawdę świetnych wykonawców, zwiększą oni spójność twojego zespołu, a nie będą go pogarszać. Trzymaj nas na miejscu przez czas trwania projektu, a następnie pozwól nam odejść, gdy zespół zwalnia. Weźmiemy wakacje i będziemy przy okazji rozpoczęcia kolejnego projektu, jeśli będziesz nas potrzebować.

Masz całkowitą rację, kiedy powiedziałeś, że umowy tymczasowe mają negatywny wpływ na zespół. W rzeczywistości prędkość jest powiązana z określoną konfiguracją zespołu. Każde nowe przybycie lub odlot unieważnia obliczenia prędkości dokonane przez miesiące.

Może jednak działać, gdy kontrahenci nie są tymczasowi. Pracowałem nad projektem, w którym zespół składał się z 95% kontrahentów z jednym lub dwoma pracownikami. Kontrahenci byli tam przez 2 lub 3 lata do czasu wydania projektu. Po zwolnieniu pracownicy wykonują konserwację. Ten sposób pracy jest bardzo powszechny.

Podsumowując:

Zwinny, a zwłaszcza Scrum zapewni wszystkie swoje korzyści w stabilnym zespole .