On 06/09/2011 16:40, Przemek O. wrote:
> W dniu 2011-09-02 15:24, Andrzej Jarzabek pisze:
>
>> 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.
>
> Aha... I one nie powodują dodatkowego narzutu czasowego?

Powodują, ale też pełnią inną rolę, która jest ich podstawowym celem:
poprawę jakości kodu i gotowego produktu.

>> 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 i? Zakładając tylko analityka i developera, zakładasz dodatkowe
> zasoby wiedzy u obydwu stron. Inaczej nie było by możliwości
> zrozumienia.

A jednak w praktyce jest, bez żadnych szczególnych dodatkowych zasobów
wiedzy.

>> Jedno i drugie jest do bani, jakby sam projektował, to by nie musiał
>> ani pisać dokumentu, ani czytać ani o tym rozmawiać.
>
> Tak, oczywiście :/ Jeśli to nie jest notatnik, to powodzenia...

Na notatniku się nie znam, ale w przypadkach, które znam, potrafi to
działać całkiem dobrze.

>> Ale tak poza tym to oczywiście rozmowa jest szybsza niż pisanie
>> dokumentów.
>
> Bierz jeszcze pod uwagę że pamięć ludzka jest zawodna.

Jak trzeba, to można sobie w trakcie rozmowy wynotować co trzeba.

>> 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'.
>
> Trywializujesz. Chyba że typowe IO jest dla Ciebie sednem algorytmu...

W mniej trywialnych przypadkach jest tak samo. Po prostu do precyzyjnego
opisu algorytmów lepiej nadają się wysokopoziomowe języki programowania,
niż języki naturalne.

> Nie rozumiesz, lub starasz się nie zrozumieć jak działa zespół.
> Poprawki/zmiany są wprowadzane zazwyczaj, gdy projekt główny jest gotowy
> zatwierdzony i przekazany do realizacji. Tak więc programista, nawet
> jeśli później zdarzy się problem i trzeba coś zmieniać, ma jeszcze
> duuuużo innej pracy którą najczęściej może wykonywać równolegle.

No to przepraszam, w projektach, przy których pracuję ogromna większość
workloadu to nie jest programowanie, tylko albo właśnie dochodzenie co
jak i dlaczego, a jeśli jest dużo programowania, to wiąże się ono
zazwyczaj ze znacznymi zmianami projektu. W pewnych fazach bywa inaczej,
ale ciężko mi sobie wyobrazić, żeby firma robiła taką żonglerkę
programistami i produktami bez poważnych negatywnych konsekwencji.

> Zmiany w projekcie powodowane zmianą wymagań są bardzo rzadkie... albo
> analityk nie wykonał swojego zadania poprawnie.

W moim świecie przewidzenie wszystkich wymagań z góry jest niemożliwe.
Natomiast zmiany w projekcie są raczej na porządku dziennym.

>> 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.
>
> Raczej dokładnie odwrotnie, czas pracy programisty jest na tyle cenny,
> że nie widzę żadnych obiektywnych powodów, żeby tracił go na inne
> czynności.

Np. czytanie dokumentów projektowych?

A czas poświęcony na dochodzenia i projektowanie nie jest czasem
traconym. Ktoś to musi zrobić, żeby program działał, i ten ktoś musi
mieć kompetencje programisty (pomijam dochodzenia czysto biznesowe)

>> 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.
>
> Konsultant / wdrożeniowiec musi mieć określoną wiedzę. Odnosiłem się do
> stwierdzenia, że nie nauczy się bo nie chce sobie utrudniać życia, a
> przy okazji może wykorzystać zespół (w tym programistów). Nikt nie
> twierdzi (w tym i ja), że musi wiedzieć wszystko, bo wiedzieć
> wszystkiego się nie da, choćby właśnie ze względu na specyfikę
> oprogramowania.

Ja też przecież nie twierdzę, że wdrożeniowiec się niczego nie nauczy,
tylko że w danym momencie będąc wdrożeniowcem na etacie wcale nie musi
mieć faktastycznej wiedzy, która by wymagała nie wiadomo jakich
zarobków. Wręcz może mieć wiedzę całkiem nieprzesadną, a i tak firmie
opłaca się go zatrudniać, bo jak czegoś nie wie, to po to ma wsparcie
firmy. Kontraktowy wdrożeniowiec musi wiedzieć odpowiednio więcej, bo
tego wsparcia nie ma. Ale i zarabia więcej, bo pieniądze płacone przez
klienta bierze w całości do kieszeni.

>> 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?
>
> J.W. Chodziło o Twoje stwierdzenie, że osoba _nie_ _musi_ się niczego
> uczyć, bo może się pytać np. programistów.

Nie musi się nauczyć, zanim zacznie pracować jako wdrożeniowiec. Kurs
jakiś tam oczywiście robi, ale to nie daje mu samo z siebie imponującej
wiedzy. Akurat wiem jak bywa, bo jako programista zdarzyło mi się kilka
razy robić kursy z produktu razem z wdrożeniowcami.

>> 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.
>
> Najwyraźniej wiesz lepiej i więcej o oprogramowaniu które produkuje i
> sprzedaje. No nic...

Najwyrażniej nie potrafisz czytać ze zrozumieniem. No nic...

>> 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.
>
> No widzisz, u mnie powoli odchodzi się od tego modelu na rzecz SAS
> (choćby właśnie ze względu na stopień skomplikowania procesu
> instalacji), więc to powyżej za chwilę nie będzie miało sensu.

Jak pracowałem w firmie, gdzie sięę robiło trading platforms, to SAS
było ofertą raczej dla średnich klientów, duży klient brał wersję na
własnych kompach i ciężko customizował: jakbyśmy im powiedzieli, że mogą
tylko wziąć SAS bez customizacji, to by poszli do konkurencji.