W dniu 2011-09-02 12:37, Andrzej Jarzabek pisze:

> 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.

Tak, tylko dokumentacja minimalizuje skutki 'wyjścia' jakiejkolwiek
osoby z projektu. W przypadku gdzie programista wie co i jak, bo zarówno
jest projektantem, programistą analitykiem, w przypadku jego 'wyjścia' w
projektu robi się wielki bałagan, terminy biorą w łeb itd itp. Pisząc
'wyjście' nie koniecznie mam na myśli zwolnienie się, ale jakiekolwiek
czynniki powodujące niedyspozycyjność pracownika przez jakiś czas.

> 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.

Dlaczego zwielokrotnia? Dokumentacja ma taką objętość żeby miała sens i
była użyteczna.

> 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?

Zależy co masz na myśli pisząc "szczegóły". Jasne, musi przeczytać tę
część dokumentacji projektu, która będzie w danym momencie
implementował. Jaka jest różnica pomiędzy przeczytaniem szczegółów a
rozmową z projektantem na ten temat?
Dobra dokumentacja minimalizuje dodatkowe pytania, a w przypadku
zapomnienia jakiegoś elementu można bez problemu znaleźć potrzebny punkt
w dokumentacji, a nie zawracać ponownie głowę projektantowi.

> 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.

Czytasz między wierszami. Projekt nie jest gotowym programem w np.
pseudokodzie, nie ten poziom szczegółowości. Ale nie jest też poleceniem
typu, np. button jakiś tam powoduje wystawienie KP.
Opisuje dla jakich danych wejściowych po zastosowaniu jakich algorytmów
otrzymamy dane wyjściowe.

> 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.

Jeśli jest to wynikiem kilku dni analizy, to nie ma znaczenia czy zrobi
ją projektant, czy programista. Ktoś będzie musiał poświęcić ten czas na
przeanalizowanie tego, a dopiero końcowym efektem będzie podmiana tego
true na false. Ale o ile taka analiza jest w gestii projektanta (skoro
coś skopał) to już programista na tym etapie może zająć się czymś innym,
wracając do feralnego return w momencie ustalenia ogólnie akceptowanego
stanowiska.

> 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.

Masz chyba problem z komunikowaniem się :P

A poważnie, nie nikt nie musi mieć wykształcenia kierunkowego. Faktem
jest, że u nas projektanci często mają przeszłość zbieżną z typem
wytwarzanego oprogramowania, ale to raczej był ich atut przy
zatrudnianiu niż wymaganie. Na etapie analizy wymagań oraz projektu
posiłkujemy się osobami praktycznie obeznanymi z tematem.

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

Prosta, albo się douczy do tego co jest potrzebne do wykonywania jego
zawodu, albo się rozstajemy. I tak daje ogłoszenie, ale nie takie. Osoba
z call center awansuje na konsultanta, a nowa przyjmowana jest na jego
miejsce (oczywiście jeden i drugi ma szkolenia równające jego
kwalifikacje z wymaganymi).

> 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ć.

Nie wnikam w Twoje doświadczenia. Tak gdzie pracuje nie ma takiej
możliwości, oprogramowanie nie jest dostępne na rynku, nie można go
kupić w wersji pudełkowej i nie ma obrotu wtórnego. Zresztą przy
jakichkolwiek wdrożeniach program jest dostosowywany do klienta, co
polega nie tylko na instalacji czy konfiguracji. Z tej przyczyny
odpadają firmy zewnętrzne które mogą to zrobić.
Z drugiej strony miałem też możliwość oglądania w akcji wdrożeniowców
zewnętrznych oprogramowania dystrybuowanego tylko w ten sposób (firma
nie zajmowała się wdrażaniem). Jak dla mnie porażka, poziom wiedzy, tak
niski że aż strach. Może to był wyjątek, nie wiem, ale zraziłem się.

> 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.

Jeśli mówimy o czymś pokroju Word'a, czy jakiegoś prostego
niedostosowanego ERPa to ok. W moim przypadku z tym z czym miałem do
czynienia, posiadanie instalki nie dawało żadnych możliwości :)

> 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.

No pewno, ale nie o to chodzi. Oprogramowania z którym mam do czynienia
nie da się ot tak zainstalować (w sumie się da, ale nic poza tym), bo
jako takie jako całość nie istnieje. Jest dobierane i konfigurowane pod
klienta.

> 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

Raczej do dokumentacji wewnętrznej w moim przypadku.

> 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".

Ale w czym problem? Firmy są raczej po to żeby zarabiać, a nie żeby
dawać zarabiać innym.

>> 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.

Ja pisałem o dokumentacji ogólnie. Dokumentacji dostępnej wewnątrz firmy
w tym dla konsultanta, zarówno tej projektowej, analizy wymagań czy
czegokolwiek innego. Instrukcja czy dokumentacja dla odbiorcy w tym
wypadku to całkiem coś innego.

pozdrawiam,
Przemek O.