Thursday, April 4, 2013

Wiedza odpływa z organizacji

Nie wiem, czy kryzys rzeczywiście był, czy go nie było, ale widzę skutki plotek o kryzysie. Departamenty IT dostały bana na zwiększanie kosztów stałych, czyli na zatrudnianie programistów. Backlog rzadko kiedy się skurczył, więc aby sprostać wymaganiom biznesu zastosowano najbardziej narzucające się rozwiązanie outsourcing.

Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.

Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:
  • Konsultanci wykonują większość prac programistycznych
  • Etatowi programiści nadzorują pracę konsultantów
  • Jeśli dla konsultanta przez pewien czas (np. tydzień) nie można znaleźć zajęcia to trzeba go zwrócić do puli
  • Konsultanci działają na zasadzie stateless, więc jeśli znów potrzebujemy konsultanta, to dostajemy nie poprzednio zwróconego, lecz pierwszego wolnego

W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:
  • przyuczaniu konsultantów i nadzorowaniu ich pracy
  • routowaniu maili między biznesem a konsultantami i ew. zewnętrznymi podwykonawcami
  • przygotowywaniu dokumentacji wynikającej z procedur organizacyjnych, których początki są tak stare, że chyba już skamieniały
  • analizowaniu logów systemowych, gdy coś się wywali

Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.

Utrzymujący się taki stan rzeczy ma następujące skutki:
  • Konkretna wiedza systemie, jego architekturze, problemach w kodzie migruje od programistów etatowych do konsultantów
  • Rotacja konsultantów sprawia, że wiedza techniczna w ogóle odpływa z organizacji
  • Nikt nie jest odpowiedzialny za rozwój architektury, która zaczyna dryfować
  • Dla podkreślenia: nie, etatowi programiści nie zajmują się architekturą (choćby nawet takie były początkowe ustalenia) bo niby co to oznacza? rysowanie umli? etatowi programiści zajmują się organizowaniem zajęcia dla konsultantów
  • Jakość kodu zaczyna się dramatycznie obniżać
  • Dryfowanie architektury sprawia, że z każdą funkcjonalnością coraz trudniej dodawać nowe i modyfikować istniejące
  • W pewnym momencie pojawia się osobliwość, czyli taki moment, w których za pomocą metod inżynierskich, architektury nie da się już naprawić; o czym pisałem trochę tutaj

Nie oddawaj core własnego biznesu

Z perspektywy organizacji, która nie jest softwarehousem takie postępowanie ma sens. Tworzenie oprogramowania nie jest core biznesu, więc spokojnie można je oddać komuś do podwykonania. Mam jednak wrażanie, że próbuje się z jednej strony mieć marchewkę i zjeść marchewkę. Z jednej strony chcemy sami tworzyć soft, aby móc go dostosowywać i być elastycznym (kolejne po "architektura") słowo-wytrych. Z drugiej strony chcemy outsourcować, aby zapłacić za to jak najmniej. Ostatecznie wydatkujemy więcej za kiepski produkt.

Przeciwdziałanie

Można przeciwdziałać odpływowi wiedzy z organizacji przestrzegając pewnych zasad. Oczywiście nie jest to tak banalne jak poniższe sformułowania. Najtrudniejsze jest przecież wdrożenie i konsekwentne trzymanie się n/w wytycznych. O następujących rzeczach warto jednak pamiętać:
  • zatrudniaj konsultantów na długo i nie zwracaj ich do puli, gdy przez kilka dni nie mają nic do roboty
  • dbaj, aby konsultantów było nie więcej niż etatowych programistów
  • etatowi programiści pełnią tymczasowe role teamliderów w miniprojektach powoływanych na wdrożenie konkretnych funkcjonalności
  • teamliderzy implementują jakąś część ticketów (tak, wiem, że kiedyś twierdziłem inaczej, ale złagodziłem nieco to zdanie
  • dbaj, aby działał nazwany proces rozwoju architektury, czyli podczas dostarczania, można realizować itemy techniczne

Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)

6 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Cześć Michał,

    Pracuję w firmie dostarczającej usługi konsultanckie dla top10 banków inwestycyjnych, nasz polski oddział zajmuje się rozwiązaniami IT.

    Dokładnie tak jak opisałeś jest ale w przypadku outsourcingu do vendorów, nie doświadczonych i dobrze zorganizowanych konsultantów. Na zdecydowanej większości projektów które u siebie prowadzimy to my jesteśmy specjalistami i to my prowadzimy projekty, naszym zadaniem jest też dzielić się doświadczeniem. Klient zatrudniając nas rozumie że nie musi się już przejmować zdrobiazgami - sami robimy research, często sami prowadzimy projekty, egzekwujemy best practice, sugerujemy potencjalne cele. Kiedy mamy nadmiar tasków prostych lub jasno zdefiniowanych, przekazujemy je właśnie vendorom lub stałym pracownikom klienta w lokalizacjach off-shore.

    Jednym z naszych podstawowych zadań jest też dokumentacja i jakość kodu aby dowolny zespół (klienta czy vendora) mógł bez trudu rozwijać nasze rozwiązanie. Często po stabilizacji projektu sami szkolimy następców.

    Chyba odwieczny problem definicji vendor/konsultant.

    Pozdrawiam

    ReplyDelete
  3. Siemka, Bartek

    Dzięki za spojrzenie z drugiej strony. Moje spostrzeżenia wynikają wyłącznie z sytuacji, z którymi się spotykałem (co starałem się ująć w preambule do bloga). Jeśli post sprawia wrażenie, że generalizuję to nie taka była intencja.

    Jasne, że warto ousourcować coś, co jest corem biznesu do doświadczonych konsultantów. W poście starałem się ująć sytuację, w której firma coś outsourcuje, a nie powinna. Zastanawiałem się, po czym poznać, że warto zrezygnować z utrzymywania własnego zespołu. Opisana sytuacja to trochę stanie okrakiem między: powinienem oddać, a nie chcę

    pozdr,
    mb

    ReplyDelete
  4. Jasna sprawa, dzięki za sprostowanie.

    ReplyDelete
  5. A jednak Core Domain z puli strategicznych technik DDD :P

    ReplyDelete
  6. "Ducha nie gaście, duchy badajcie! Co dobre przyjmujcie, unikajcie wszystkiego, co ma choćby pozór zła" 1Tes 5, 19-22

    Jakby się wczytać w moje posty to da się zauważyć, że jestem fanem 2nd i 3rd części książki. Po za tym te "strategiczne techniki" nie zostały wymyślone przez DDD, tylko zaczerpnięte od innych. A zaczęło się już chyba od lat 70, kiedy zauważono, że zespoły programistyczne mają tendencję do tworzenia takiej architektury, która odwzorowuje strukturę komunikacyjną w organizacji.
    http://en.wikipedia.org/wiki/Conway's_law
    Wszytko już było, naprawdę:)

    ReplyDelete