Battle for Agility

Zachęta, przynęta i takie tam…

Co prawda, to co za raz napiszę nie ma takiego bezpośredniego związku z agile, ale od jakiegoś czasu mnie to nurtuje. Zainspirowany lekturą książki “Implementing Lean Software Development” i korzystając z faktu, że mam akurat okazję obserwować tworzenie się zespołu typu nearshore, mam do was pytanie.

Jak zbudować relację firma matka - firma nearshore, tak aby obie opierały swoją pracę na modelu obopólnej korzyści? W języku angielskim jest takie zgrabne słowo incentive (zachęta? korzyść?). Gdzie szukać tej korzyści dla obu stron?W swojej książce Marry i Tom Poppendieck użyli przykładu outsourcingu usług typu help desk, gdzie wykonawcy wcale nie musi zależeć na rozwiązywaniu problemów klientów swojego zleceniodawcy jeśli jego model współpracy oparty jest na ilości obsłużonych błędów. W takim wypadku rozwiązywanie problemów odbiera pracę (i dochody) wykonawcy a to na pewno nie leży w jego interesie.

Mój przypadek jest bardzo pobony, tzn. firma typu nearshore buduje zespół głównie utrzymaniowy (być może w przyszłości także i rozwojowy). Spojrzmy na obie strony tego układu.

Klient:

• liczy na niższe koszty,
• potrzebuje nowych ludzi, a lokalny rynek się wyczerpał i bardzo trudno jest rekrutować specjalistów,
• zależy mu na tym, aby nowy zespół stał się równie wydajny jak jego własni ludzie

Wykonawca (firma typu nearshore):

• jest tańsza i łatwiej się jej pozbyć niż zwalniać własnych ludzi w razie kryzysu (modne słowo ;-),
• ma dostęp do ludzi i jest ich w stanie zrekrutować,
• zależy jej na trwaniu kontraktu i pozyskiwaniu coraz większej liczby zadań dla większej liczby ludzi bo zarabia na marży od ich pracy

No właśnie… pierwsze dwa punkty po obu stronach teoretycznie pasują do siebie i zwykle z połączenia właśnie takich celów rodzi się pomysł na nearshoring lub offshoring. Gorzej z punktem trzecim o którym jakoś cicho.

Zespół utrzymaniowy działa prawie jak help desk. Jeśli szybko rozwiąże problemy, to pozbawi się dochodu (jeśli rozliczany jest na godziny, czyli na zasadzie time and material). Z drugiej strony mamy jednak do czynienia z naprawianiem błędów oprogramowania. Gdyby przyjąć wynagrodzenie takiego zespołu oparte o ilość rozwiązanych problemów to byłoby to dość niebezpieczne dla wykonawcy, bo tego typu problemy bywają bardzo różne i jedne wymagają dużo więcej pracy niż inne.

Co powinny być w takim razie tą wspólną zachętą do współpracy dla obu stron, tak aby klient miał pewność, że jego partner wykona swoje zadania jak najlepiej i jak najszybciej, a wykonawca miał taki sam interes w takim właśnie podejściu do realizacji kontraktu? Czy to możliwe aby taki model współpracy nie wymagał skrupulatnej kontroli ze strony klienta, i ciągłego sprawdzania czy zespół nearshore pracuje a nie leży z założonymi rękami? Jak mierzyć wydajność takiego zespołu? Szacować pracochłonność zleceń tak jak szacujemy naszą pracę przy nowych projektach?

4 comments February 10th, 2009