Battle for Agility

Zachęta, przynęta i takie tam…

February 10th, 2009 Marcin Niebudek

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?

Kategorie: Agile dla managerów, Agile dla klientów, Relacje z klientem

(No Ratings Yet)

Loading ...

4 komentarzy Dodaj komentarz

1. Jacek Rybicki | February 20th, 2009 at 22:58

Należy dążyć do tego, aby sprawy były proste, ale nie prostsze. Jeden wskaźnik: koszt/ilość problemów to nie jest wystarczające rozwiązanie. Dobre statystyki, to tylko takie, które pokazują że nadal zbyt duże jest ryzyko przeniesienia wszystkiego do Chin :)

Idea, którą rozumiem, jest taka: dać obu stronom to czego potrzebują: podkładki dla wyższego managementu, gwarancję stałych wpływów i wypływów, motywację do zwiększenia efektywności pracy.

Nasuwa mi się taki model: Koszty utrzymania są wyznaczane na podstawie statystyki i umów ramowych.

Co rozumiesz przez wydajność zespołu utrzymaniowego? Średni koszt rozwiązania problemu? Ilość rozwiązań, które zostały odrzucone? Średnia ważoną opóźnień względem zobowiązania dla danego priorytetu zgłoszenia?

Może spróbuj wynająć (oczywiście taniej zaprosić na piwo, ale to grozi zajęciem kilku wieczorów) na jeden dzień kogoś z firmy, która zajmuje się na poważnie utrzymaniem od kilku lat. Zaoszczędzisz więcej niż wydasz :)

pozdrawiam,
Jacek
2. Tomek Dąbrowski | March 27th, 2009 at 12:32

Ja zaproponowałbym inne rozwiązanie. Z opisu wynika, że jedynym zadaniem zespołu jest praca utrzymaniowa, czyli naprawa błędów. Rozumiem więc, że istnieje jakaś lista błędów (Bugs backlog). Zróbmy więc spotkanie z zespołem, oszacujmy w Story Points każdy z błedów. Następnie określmy jakie jest velocity zespołu np. w ciągu 2 tygodni. Mając tą metrykę i wstępnie oszacowane błędy, oraz priorytety błędów wg upodobań klienta, mamy możliwość zobligowania się do naprawienia konkretnych rzeczy w mniej więcej określonym czasie.
3. Marcin Niebudek | March 27th, 2009 at 13:09

No powiedzmy, że to jak oszacować w story points zgłoszenia, które potraktujemy jak user story to jest dla mnie jasne. Techniczny aspekt takiego projektu jest tutaj najprostszy.

Moim problemem jest coś innego co jest niezależne od przyjętej przez zespół metody. Chodzi o ustalenie… “osi współpracy”(?) w takim miejscu, żeby żeby obu stronom opłacało się dbanie od wydajność i jakość. Bo jak na razie to mam wrażenie, że to tak nie funkcjonuje i zespół utrzymaniowy wyoutsourcowany poza firmę macieżystą najlepiej powinien “spieszyć się powoli”. To dla mnie jest bardzie problem z samym modelem outsourcingu tego typu usługi i jakoś nie mogę uwierzyć w jego powodzenie, więc proszę o przykłady, które wyprowadzą mnie z tego przeświadczenia :-)
4. Marcin Niebudek | March 27th, 2009 at 13:13

Może zagram ostrzej :-)

“Czy ktoś z was pracuje w zespole utrzymaniowym, który działa w modelu nearshoringowym/outsourcingowym i z czystym sumieniem może powiedzieć, że jego zespół robi wsztystko aby być jak najwydajniejszy bo się mu to opłaca?”

Pytania pomocnicze:
1. Co zrobiliście, żeby tak ułożyć współpracę?
2. Co zrobił klient, żeby was do tego zachęcić?