On Sep 2, 12:41 pm, "Przemek O." <p...@o...eu> wrote:
>
> 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.

To jest osobny problem, ale to są jednak sporadyczne sytuacje, znaczy
jak programista się zwalnia, to ma mmiesiąc wypowiedzenia i ten czas
może poświęcić na przygotowanie odpowiedniej dokumentacji i/lub
przekazanie wiedzy kolegom w inny sposób, sytuacje kiedy programistę
potrąci ciężarówka są bardzo rzadkie. A i na nie są inne, moim zdaniem
znacznie bardziej skuteczne sposoby: coding standards, shared (albo
propagowany w Agile collective) ownership, code review, change
control, widoczność zmian na poziomie team lead, orientacja testerach
w funkcjonalności produktu i zmian w tejże i tak dalej.

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

Bo jeśli zamiast analityka i developera masz analityka, projektanta i
programistę, to zamiast jednego dokumentu, który analityk przygotowuje
a developer czyta, masz dwa dokumenty, jeden pisany przez analityka a
czytany przez projektanta i drugi, pisany przez projektanta i czytany
przez programistę. Jeśli rozbijesz to dalej na domain experta,
analityka software'owego, projektanta i programistę, to dokumentów
masz trzy razy tyle co w wariancie pierwotnym.

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

Jedno i drugie jest do bani, jakby sam projektował, to by nie musiał
ani pisać dokumentu, ani czytać ani o tym rozmawiać.

Ale tak poza tym to oczywiście rozmowa jest szybsza niż pisanie
dokumentów.

> 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 ale co się dzieje, jak jest żądanie dodania albo zmiany
funkcjonalności, które wymaga zmiany w kilku miejscach istniejącego
projektu? Projektant robi projekt zmian i osobno zmienia projekt
pierwotny? A co, jeśli przez subtelnopści gramatyki i kontekstu zmiany
opisane w projekcie zmian będzie mozna zrozumieć inaczej, niż zmiany
naniesione na projekt? Programista, który nie rozumie co jest po co i
dlaczego zrobi zmiany zgodne z dokumentem dokumentującym zmiany
projektu, ale niekoniecznie zgodne z nowym projektem całości...

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

No więc jeśli on rzeczywiście jednoznacznie i dla każdego przypadku
opisuje to, co piszesz, to to jest to samo co pseudokod, tylko że
prozą. Na przykład zamiast
if inpout[0] = 'x' then output[3] = 'y'
można napisać
Jeśli pierwszym znakiem komunikatu wejściowego będzie literka 'x', to
na czwartym znaku komunikatu wyjściowego powinna pojawić się literka
'y'.

Jak nietrudno zauwazyć, pisanie drugiej wersji trwa więcej niż pisanie
pseudokodu i trwa również więcej, niż pisanie samego kodu. W dodatku
wprowadza dodatkowe okazje do pomyłek.

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

Nie może, bo programista potrafi tylko impelmentować zmiany
wyspecyfikowane w dokumentacji dostarczonej przez projektanta, a
projektant nie dostarcza dokumentów, bo zajmuje się dochodzeniem gdzie
trzeba zmienić true na false żeby program robił to, co ma robić.

Oczywiście może się akurat zdarzyć tak, że będzie cośtam mógł robić,
ale jeśli jesteś w takiej fazie projektu, że na każdych pięć
zmienionych czy dopisanych linijek kodu masz trzy dni dochodzenia co
właściwie trzeba zmienić i dzień komunikowania testerom i technical
writerom jak się zmienił produkt i jak to przetestować, przy czym
zarówno dochodzenie jak i tłumaczenie wymagają zrozumienia sensu tej
zmiany, to twoi programiści nie mają nic do roboty, a projektanci nie
wydalają z wypełnianim wszystkich zadań. Jak jesteś w innej fazie
projektu, gdzie powstaje bardzo dużo nowego kodu, a wymagania się nie
zmieniają, to z kolei potrzebujesz tych wszystkich programistów, więc
nie wyjdziesz na tym najlepiej, jeśli w poprzedniej fazie ich
zwolnisz. No chyba że bierzecie programistów z jakiejś agencji pracy
tymczasowej, co by mnie nawet nie zdziwiło, sądząc po tym, co piszesz.

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

Oj, przecież nie potraktowałem tego wykształcenia kierunkowego
dosłownie. Chodziło o 'domain knowledge'.

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

A to przepraszam, ja raczej pracuję przy produktach, których nie da
się po prostu douczyć. Najszybszym sposobem douczania się jest i tak
praca przy wdrażaniu, ale nawet ludzie, którzy robią to od wielu lat
nie wiedzą wszystkiego.

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

No ale skoro poprzedni konsultant z kilkuletnim doświadczeniem miał
szkolenia a jednak nie wiedział wszystkiego, to na jakiej podstawie
uważasz, że osoba z call center będzie widziała?

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

Ja też mówię o takiej sytuacji.

> Z tej przyczyny odpadają firmy zewnętrzne które mogą to zrobić.

Najwyraźniej jednak nie z tej przyczyny, bo poza waszą firmą i jej
oprogramowaniem jest jednak sporo zewnętrznych konsultantów od
oprogramowania kupowanego w ten sposób. Znaczy oprogramowanie robione
jest jednak w taki sposób, że po dostarczeniu klient może sobie
samodzielnie dostosowaać, dokonfigurować, oskryptować, pospinać z
innymi systemami i tak dalej.

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

Tutaj normą jest to, że kontraktowi konsultanci od programu X to byli
etatowi konsultanci w firmie produkującej X, którzy poczuli się, że na
tyle wiedzą o produkcie, że mogą świadczyć konkurencyjna usługe bez
specjalnego dostępu.

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

Nie mówię o Wrodzie ani o ERPach, ja akurat mam głównie doświadczenie
z oprogramowaniem finansowym: trading platforms, trade/order/position
management, i takie tam. Zapewniam cię, że nie są to programy zbyt
proste.

Niemniej jednak raczej normą było, że jak klient opłacił licencję, to
miał dostęp do instalek, które mógł sobie zainstalować, miał możliwość
zmiany konfiguracji i dostawał end user documentation wyjaśniającą jak
instalowac i jak konfigurować produkty, dodatkowo też konrakt
supportowy, który uprawniał go do uzyskiwania dodatkowych odpowiedzi i
objaśnień w tej kwestii.

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

Problem? Tłumaczę ci tylko, że jak bierzesz konsultanta etatowego, to
nie płacisz za to, że on wszystko wie (bo nie ma kogoś takego), tylko
za to, że w razie potrzeby, jak czegoś nie wie, to może się
dowiedzieć. Więc wartość takiego konsultanta nie wynika przede
wszystkim z jego wiedzy, tylko ze wsparcia firmy. Nie ma więc powodu,
żeby płacić mu od razu straszne kokosy (w porównaniu powiedzmy z
developeram), bo przecież na początek to supportowiec z dodatkowym
dwudniowym szkoleniem: podwyżkę 20% weźmie z pocałowaniem ręki.


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

Nawet w tym przypadku - konsuultant pracujący dla firmy tym się różni
od zewnętrznego, że ma dostęp do tej dokumentacji. Jak klient płaci
dwa razy tyle za konsultanta od producenta, to płaci za ten dostęp, a
nie za człowieka, który wszystko wie.