Programista nie do zastąpienia

No, ale jak się ładnie temu klientowi zobrazuje katastrofę samolotową, gdzie na pokładzie byli wszyscy znający dany obszar systemu (albo lepiej - już była w projekcie sytuacja, że cała taka ekipa była na urlopie w tym samym momencie), to raczej się na to zgodzi. :D

nie do końca zrozumiałem metaforę z samolotem. Chociaż kojarzy mi się z tym, że "nie ma demokracji na pokładzie samolotu" - i że jednak musi być załoga, która nim steruje. Jakby każdy pasażer losowo się wymieniał drążkiem i sterował w swoją stronę, to nie byłoby fajnie. Czyli to byłby argument za specjalizacją, żeby poszczególne działki pozostawić (niezastąpionym) ekspertom, a nie bawić się full stackowanie.

LowSkiller napisał(a):

Trzeba też przy tym pamiętać, że zazwyczaj trzeba mieć kasę na rozbijanie silosów i dobrze sprzedać to klientowi - dzielenie się kompetencjami wiąże się z tym, że biznes godzi się na to, że dany bug/feature będzie robiony 2-3x dłużej, bo jest ktoś nowy, kto się tej działki uczy.

Myślę, że tu można argumentować w obie strony (albo i więcej).

Można twierdzić, że dany ficzer będzie robiony szybciej, bo będzie go robiło kilka osób, więc się podzielą pracą. A jakby jedna osoba robiła, to by musiała robić wszystko, więc wolniej. No i jak jest kilka osób, to każdy może robić to, w czym się zna, a nie, że jeden człowiek orkiestra.

A można twierdzić, że dany ficzer będzie robiony szybciej, bo będzie go robić jedna osoba, więc będzie mieć wolną rękę. I nie będzie narzutu na komunikacje, na bikeshedding, na ustalanie "co kto robi" na rozwiązywanie konfliktów czy na code review i poprawianie kodu po innych. Czy na wdrażanie osób nowych w projekcie.

Przydałyby się jakieś badania, które by sprawdzały, czy faktycznie zwiększenie osób w zespole wpływa na produktywność i w jaki sposób. I kiedy opłaca się dorzucać więcej ludzi do zespołu, a kiedy się to nie opłaca.

Kiedyś usłyszałem że nie ma osób nie do zastąpienia. A jeśli przypadkiem jest to należy ją jak najszybciej zwolnić zanim jeszcze bardzie się okopie i stanie się jeszcze bardziej nie do zastąpienia.

Naprawdę nigdy nie pracowaliście w projekcie, gdzie ostatni poprzedni programista zniknął w tajemniczych okolicznościach, a wy musicie niczym archeolog odcyfrować zapis pradawnej cywilizacji?
Jest to drogie, ale wykonalne. Co znaczy, że nigdy programista nie może okopać się tak by być nie do zastąpienia

KamilAdam napisał(a):

Kiedyś usłyszałem że nie ma osób nie do zastąpienia. A jeśli przypadkiem jest to należy ją jak najszybciej zwolnić zanim jeszcze bardzie się okopie i stanie się jeszcze bardziej nie do zastąpienia.

Klient dla którego pracuje "twój" outsourcing kupił biznes i włącza go w swoje struktury. Do zintegrowania jest wszystko co się da i co trzeba, a zostało to dawno temu zrobione przez firmy pracujące dla tamtego, wykupionego biznesu. Współpracy z tamtymi wykonawcami już nie ma i nie będzie.
Co się robi? Robi się w Polsce, w Wietnamie, na Białorusi i innych podobnych krajach i jest zrobione.

Wszystko/każdego da się zastąpić "tańszym zamiennikiem"

LukeJL napisał(a):

Przydałyby się jakieś badania, które by sprawdzały, czy faktycznie zwiększenie osób w zespole wpływa na produktywność i w jaki sposób. I kiedy opłaca się dorzucać więcej ludzi do zespołu, a kiedy się to nie opłaca.

Po co badania? Spójrz na świat biznesu - wielkie, niezarządzalne, niezatapialne korporacje które nawet nie wiedzą co robią i dla kogo ale rada nadzorcza kosi premie za wykresy w PowerPoincie. Teamy które latami potrafią pracować nad projektami który już dawno zostały zapomniane i nigdy nie wejdą na produkcję. Jak potrzeba coś innowacyjnego to się przegląda rynek bierze najbardziej obiecujący startup daje właścicielom kilkaset baksów na urządzenie życia a wielkość i siła nabywcy pozwala na gwałtowne zwiększenie skali. Słupki w PP rosną, premie również.

Później kolejne przegięcie krzywej i cykl zaczynamy od nowa.

Programistów pewnie można, ale jeśli chodzi o inżynierów oprogramowania to moim zdaniem istnieją tacy nie do zastąpienia, co nie oznacza, że nie można się bez nich obejść.

Przez "nie do zastąpienia" rozumiem zbiór pewnych unikalnych kompetencji, które powodują, że zespół, dział czy nawet firma nie jest w stanie realizować bez nich pewnych strategii. Czy zespół sobie bez nich poradzi? Pewnie tak, po prostu będzie realizował inną strategię, możliwe że gorszą, możliwe, że prowadzącą do innego celu niż założone, ale zawsze jakiegoś celu. Sam pracuję przynajmniej z 2-ma takimi. Ich niezastępowalność nie ma nic wspólnego z ich stylem kodowania czy podobnie nieistotnymi rzeczami. Po prostu ich wiedza i doświadczenie powodują, że bez nich nie powstałyby rozwiązania problemów rzutujących na strategię firmy. Gdyby ich nie było od początku, to pewne rzeczy po prostu by nie powstały, a strategia firmy byłaby gorsza. Gdyby ktoś miał ich zastąpić w pół projektu, to albo by ten projekt natychmiast uwalono, co było by względnie rozsądnym zadaniem, albo pozwolono by dziesiątkom ludzi pracować jeszcze przez jakiś rok by w końcu przyznać się do porażki i tego że założenia nie zostaną osiągnięte.

To trochę jak z pytaniem, czy da się zastąpić samochód. Do pewnych rzeczy pewnie tak - do dojazdów do pracy można zastąpić autobusem czy nawet hulajnogą. Ale żeby być za 5 godzin 400 km. stąd. to albo innym samochodem, albo helikopterem. Więc jeśli nie masz tych środków transportu, to po prostu nie będziesz w tym miejscu w zadanym czasie, wybierasz np. transmisję telewizyjną i żyjesz dalej :)

Programistów pewnie można, ale jeśli chodzi o inżynierów oprogramowania

Jak to dobrze, że jestem oficjalnie starszym inżynierem oprogramowania :)

GutekSan napisał(a):

Przez "nie do zastąpienia" rozumiem zbiór pewnych unikalnych kompetencji, które powodują, że zespół, dział czy nawet firma nie jest w stanie realizować bez nich pewnych strategii.

Przecież nieredukowalna złożoność to BS dla kreacjonistów ;)

LowSkiller napisał(a):

LukeJL napisał(a):

nie do końca zrozumiałem metaforę z samolotem. Chociaż kojarzy mi się z tym, że "nie ma demokracji na pokładzie samolotu" - i że jednak musi być załoga, która nim steruje. Jakby każdy pasażer losowo się wymieniał drążkiem i sterował w swoją stronę, to nie byłoby fajnie. Czyli to byłby argument za specjalizacją, żeby poszczególne działki pozostawić (niezastąpionym) ekspertom, a nie bawić się full stackowanie.

Masz rację, zgadzam się z tym. Tylko chodziło mi o samolot w innym znaczeniu.

Samoloty, samoloty
https://www.pacificventury.com/post/the-737-max-8-case-what-happened-to-the-leadership-compass-of-boeing

W małych firmach są ludzie, których czasami bardzo trudno zastąpić, bo mają wiedzę, która wymaga 2-3 specjalistów wchodzących z zewnątrz, a kasy na nich brakuje. W dużych firmach o ludziach nie do zastąpienia po miesiącu już nikt nie pamięta.

hadwao napisał(a):

W małych firmach są ludzie, których czasami bardzo trudno zastąpić, bo mają wiedzę, która wymaga 2-3 specjalistów wchodzących z zewnątrz, a kasy na nich brakuje.

1 admin
2 projektant & grafik
3 programista full stack

3 w 1* /do tego Janusz wpierniczający przy rozmowie telefonicznej chipsy/*