On Sep 2, 8:31 am, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-09-02 00:17, Andrzej Jarzabek pisze:
>
> No i dochodzimy do sedna różnic. Ja piszę cały czas o firmach typowo
> softwareowych, gdzie taka firma rozwija więcej niż jedno oprogramowania
> a przy okazji prowadzi prace, hmmm jakby to nazwać, mające na celu
> wynajdowanie nowych rozwiązań w zakresie tworzonego oprogramowanie lub
> nawet niezwiązanego z nim. To nie firma Kowalski i Synowie (bez urazy)
> która napisała program do faktur i do poprawia przez całe życie.

Urazy nie ma, ale moje osobiste doświadczenia dotyczą dwóch spółek
publicznych będących firmami "typowo software'owymi", notowanych na
londyńsiej giełdzie, z czego jedna w indeksie FTSE 250, oraz dużej
prywatnej korporacji z listy Fortune 500, zatrudniającej globalnie
około 20 000 pracowników - ta firma robi kilka rzeczy, ale w
większości związanych z produkcją własnego oprogramowania.

Z innych firm, gdzie wiem, że praca zorganizowana jest podobnie (bo
albo miałem rozmowę o pracę, albo znam tam ludzi), to też raczej nie
mówię o firmach Kowalski i Synowie: głównie są to banki inwestycyjne
(więc w tym przypadku zgadza się, że "nie firmy typowo software'owe"),
ale też kilka innych firm bądź czysto software'owych, bądź których
biznes w dużej części polega na sprzedawaniu software lub usług
opartych na własnych software.

> Więc programista nie jest przypisany do jednego projektu. Dalej idąc,
> przypominam sobie dyskusje gdzie byłeś przeciwny tworzeniu dokumentacji.

Tak w ogóle to nie jestem przeciwny tworzeniu dokumentacji. Zwrcam
tylko uwagę, że w opisanym przez ciebie modelu potrzebne jest bądź
tworzenie dokumentacji, bądź jakaś inna forma przekazywania wiedzy na
każdym stopniu rozbicia obowiązków developera. A każda taka forma
komunikacji, czy to w postaci tworzenia i czytania dokumentów, czy
zadawania i odpowiadania na pytania, zajmuje czas. Dodatkowo
komunikowanie się przez dokumentację jest bardziej czasochłonne niż
komunikowanie się face-to-face.

> I to by się zgadzało, jeśli weźmiemy pod uwagę jej brak, to
> rozdrobnienie zadań spowoduje chaos.

A jeśli weźmiemy pod uwagę jej obecność, to rozdrobnienie zadań
zwielokratnia ilość tworzonej dokumentacji i co za tym idzie ilość
czasu poświęcaną na pisanie i czytanie tejże.

> Jednak zapewniam Cie, że praca z
> dokumentacją projektową nie wygląda nawet w małym procencie tak jak to
> opisałeś powyżej. Nikt nie traci czasu na czytanie szczegółów i
> wgłębianie się w "niewiadomoco" bo wszystko jest jasne i przejrzyste.

No to mam dwa pytania: skąd programista wie co robić, skoro nie traci
czasów na czytanie szczegółów dokumentu projektowego, który dostaje, i
skoro programista nie traci czasu na czytanie tych szczegółów, to czy
pisanie tych szczegółów przez projektanta nie było stratą czasu?

> > Na moim przykładzie to wygląda tak, że robiąc te wszystkie czynności nie
> > będące kodowaniem nabywam zrozumienia tego, co trzeba zmienić, i mając
> > to zrozumienie potrafię dokonać zmiany w kodzie. Jednoznaczne
> > wyspecyfikowanie tej zmiany komuś, kto tego zrozumienia nie ma, zajęłoby
> > mi więcej czasu, niż dokonanie zmiany samemu.
>
> Programista nie musi rozumieć co z czego wynika, tylko ma wykonać kod
> zgodny z projektem.

No więc w oprogramowaniu, nad którym pracuję i pracowałem, sytuacja
jest taka, że jeśli projekt jest na tyle szczegółowy, że programista
może go zaimplemenować nie rozumiejąc co z czego wynika, to samo
stworzenie projektu na tym poziomie szczegółowości wymaga praktycznie
zawsze więcej czasu niż napisanie kodu. Nawet jeśli jest to trywialna
zmiana, polegająca powiedzmy na tym, że w jakiejś domyślnej
implementacji metody trzeba zmienić return true na return false (a
wiedza o tym, że to właśnie trzeba zrobić moze być wynikiem kilku dni
analizowania i dochodzenia co z czego wynika), to napisanie dokumentu
projektowego dla tej zmiany i naniesienie odpowiednich poprawek na
pierwotny projekt zajmuje wielokrotnie więcej czasu niż zamiana return
true na return false. A wszystkie pozostałe czynności i tak będą
musiały być wykonane.

> Upraszczając dla danych wejściowych ma otrzymać
> oczekiwane dane wyjściowe. Od rozumienia co z czego wynika jest
> projektant. Jeśli programista miałby mieć o tym pojęcie, to wg Twojej
> zasady, do pisania oprogramowania księgowego, trzeba by zatrudniać
> programistę po wyższej ekonomicznej, do pisania oprogramowania rolnego
> po wyższej rolniczej (pomijam fakt że jeszcze pewno musiałby mieć
> praktyczne doświadczenie w danej dziedzinie). A to tak nie działa, bo
> dopiero to byłoby szalenie nieefektywne, szczególnie ekonomicznie.

Nie, od domain knowledge są osobni ludzie, zwykle analitycy. Tylko że
oni nie potrafią zaprojektować programu, bo znają się na księgowości
albo rolnictwie, ale niekoniecznie mają pojęcie o projektowaniu
programów.

Jeśli w twoim modelu to projektant zna się na księgowości, to tylko
przesuwasz problem: nie musisz zatrudniać programisty po wyższej
rolniczej, ale musisz zatrudnić projektanta oprogramowania po wyższej
rolniczej. Albo też z kolei masz analityka biznesowego po wyższej
rolniczej, rpojektanta i programistę, i w tej sytuacji zamiast dwóch
osób robiących tę samą robotę masz trzy i dwa razy większy narzut
komunikacyjny.

> > W zależności od organizacji będzie raczej korzystał z jakiegoś supportu,
> > ale support też nie zawsze wie. W każdym razie to nieistotne, istotne
> > jest to, że sam wszystkiego, czego potrzebuje, to nie wie.
>
> To czego potrzebuje to _powinien_ wiedzieć. Jeśli nie wie, to sprawa prosta.

Znaczy jaka prosta? Wyrzucasz go z pracy i dajesz ogłoszenie
"zatrudnimy wdrożeniowca wiedzącego wszystko o naszym produkcie"?

> > Powinien mieć taką wiedzę, jaka mu jest potrzebna do wykonywania pracy.
> > A ponieważ - jeśli jest pracownikiem firmy - ma dostęp nie tylko do
> > supportu, ale i analityków biznesowych i developmentu, to de facto nie
> > musi wiedzieć aż tak dużo.
>
> Czyli co? Z racji tego że ma do nich dostęp to może się obijać i kosztem
> ich czasu pracy sobie ułatwiać życie?

Ma sobie ułatwiać życie, bo jak sobie utrudni życie, to utrudni życie
klientowi firmy, i wtedy ten klient się będzie zastanawiał, czy
zamiast zatrudniać wdrożeniowca od producenta za dwa razy więcej, nie
opłaca mu się bardziej zatrudnić freelancera za dwa razy mniej. Bo to,
za co płaci dwa razy więcej biorąc wdrożeniowca od producenta to to,
że wdrożeniowiec od producenta ma właśnie dostęp do zasobów
producenta, w tym też możliwości dowiedzenia się, czy program da się
skonfigurować tak, żeby robił coś, czego jeszcze nikt nie próbował -
i to jest pytanie, na które support często nie potrafi odpowiedzieć.

> > Ja nie mówię o formalności takiej czy innej formy zatrudnienia, tylko o
> > ścieżce kariery, w której wdrożeniowiec po iluś latach pracy w firmie
> > produkującej oprogramowanie odchodzi z tej firmy i rozpoczyna
> > konkurencyjną działalność polegającą na wynajmowaniu się jako niezależny
> > wdrożeniowiec za pół tej ceny, po której można wynająć konsultanta od
> > producenta. W ten sposób można zarobić znacząco więcej niż na etacie,
> > ale do tego trzeba już rzeczywiście mieć dużą wiedzę i doświadczenie.
>
> Zakładając że:
> a. oprogramowanie jest dostępne na rynku dla każdego (bo skądś trzeba
> mieć go, żeby go wdrażać),

Nie musi być przecież: jeśli kupujesz oprogramowanie jakkolwiek, to
raczej masz możliwość je instalować i konfigurować samodzielnie, a
skoro masz taką możliwość, to możesz również zlecić to osobie z
zewnątrz.

> b. firma w ogóle bierze pod uwagę taki model dystrybucji (czyli że jest
> to w ogóle możliwe).

W okolicach, w których się obracam, zazwyczaj jest. Przypuszczam że to
dlatego, że wpisana w umowę konieczność wynajmowania wdrożeniowców za
każdy dzień obowiązywania licencji, czy się go potrzebuje, czy nie,
byłaby raczej odstraszająca dla potencjalnego nabywcy.

> Inna sprawa, że wraz z nową wersją zmienioną w znacznym stopniu do
> poprzedniej, wartość takiego samodzielnego wdrożeniowca spada do zera.

Większość oprogramowania nie zmienia się w _aż tak_ znacznym stopniu z
wersji na wersję.

Ale oczywiście właśnie w takiej sytuacji jest przewaga brania
wdrożeniowca od producenta: nie dlatego, że ten automagicznie nabywa
nowej wiedzy wraz z wypuszczeniem nowej wersji programu, tylko właśnie
dlatego, że ma dostęp do zasobów firmy, takich jak developerzy, którzy
zrobili nowy ficzer, którego jeszcze nikt nie użył, i potrafią
odpowiedzieć na takie pytania dotyczące tego ficzeru, na które support
odpowiedzieć nie potrafi lub nie czuje się w obowiązku odpowiadać -
również dlatego, że firma chce zarabiać na wynajmowaniu konsultantów i
support może mieć w związku z tym politykę mówienia w pewnych sprawach
"takie są usankcjonowane i udokumentowane sposoby korzystania z
produktu, jak chcecie go hackować, to polecamy usługi naszych
konsultantów".

> > Ja nie mówię o zmianach, tylko o tym, że konsultant pracujący dla
> > producenta ma możliwość dowiedzieć się różnych szczegółów, które nie są
> > jednoznacznie wyspecyfikowane w dokumentacji, między innymi dzięki temu,
> > że dział konsultacyjny współpracuje z developmentem i w pewnych
> > sytuacjach może poprosić developera, żeby popatrzył na kod źródłowy i
> > powiedział, jak coś dokładnie działa albo czy dany myk, którego jeszcze
> > nikt nigdy nie próbował, da się zrobić.
>
> Po pierwsze w dokumentacji (jakiejkolwiek) dostępnej dla konsultantów
> powinno być wszystko. Jeśli tego nie ma to dokumentacje można do kosza
> wywalić. Wiem, Ty mówisz że się tak nie da, że to strata czasu itp itd.
> Ja mówię odwrotnie, bo czas poświęcony na utworzenie takiej dokumentacji
> zwraca się właśnie w takich momentach.

Hej hej, mylisz tutaj różne rzeczy. Odbirca dostaje dokumentację
użytkownika, a nie dokumentację projektową, analizę wymagań,
sprawozdania z testów czy inne formy dokumentacji związanej z cyklem
rozwoju oprogramowania. Dokumentacja przeznaczona dla końcowego
użytkownika powinna oczywiście być tworzona, ale od tego też są osobni
ludzie, ani programiści, ani projektanci, tylko technical writerzy.

I to, czy w takiej dokumentacji jest wszystko, czy nie jest nie zależy
w praktyce od ilości dokumentacji powstającej w procesie developmentu,
tylko od złożoności produktu. Przy każdym większym i bardziej
konfigurowalnym programie, np. udostępniającym różne interfejsy, API,
możliwość skryptowania, konfigurację z rozbudowanym językiem wyrażeń,
rozmaite kombinacje komponentów, współpracę z systemami zewnętrznymi
itp. zawsze będzie możliwość zadania pytania "czy da się zrobić tak,
że...", na które nie będzie się dało odpowiedzieć w jednoznaczny
sposób tylko na podstawie dokumentacji użytkownika. W takiej sytuacji
jedyną możliwością dowiedzenia się tego jest spytanie developera,
nieważne, czy projektanta, który zajrzy do dokumentacji projektowej,
czy inżyniera oprogramowania, który zajrzy w kod (z wyjątkiem tego, że
zajrzenie w kod da odpowiedź bardziej zgodną z prawdą, bo wartość
informacji z dokumentacji projektowej zalezy od tego, czy klepacz
rzeczywiście wklepał dokładnie tak, jak się projektantowi wydaje, że
dana specyfikacja powinna być wklepana.

Na dodatek dokumentacja pisana jest w języku naturalnym, który ze
swojej natury jest mocno niejednoznaczny i kontektstowy.

> A przy okazji, pomimo jasnego rozdziału ról, nigdy nie napisałem, że
> konsultant nie może poprosić o coś takiego programisty, czy projektanta.
> Ale to nie ma wynikać ze sposobu prowadzenia projektu i być tym sposobem
> samym w sobie. Bo mając 20 wdrożeniowców mogłoby się okazać że
> programista nie robi nic innego jak tylko sprawdza w kodzie czy myki
> zadziałają.

Mogłoby się okazać, ale też mogłoby się okazać, że to jest takie
własnie wykorzystanie czasu programisty, które się najbardziej opłaca.
Ogólnie to jest przecież kwestia zarządzania zasobami, która zapada na
wyższym szczeblu.

A z drugiej strony jak masz programistę, który doskonale wie, jak dany
ficzer działa, bo sam pracował przy analizie wymagań, zaprojektował
ten ficzer, zaimpementował, opisał na tickecie i powiedział testerom
jak go testować, to często jest tak, że na trudne pytanie, na które
nikt inny nie potrafi odpowiedzieć, taki programista odpowiada albo z
marszu, albo powiedzmy potrzebuje trzech minut na zajrzenie w kod.