fbpx

Wiedza odpływa z organizacji

6 komentarzy

  1. This comment has been removed by the author.

  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

  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

  4. Jasna sprawa, dzięki za sprostowanie.

  5. A jednak Core Domain z puli strategicznych technik DDD 😛

  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ę:)