On 14/02/2013 22:28, Edek Pienkowski wrote:
> Dnia Sun, 27 Jan 2013 00:41:30 +0000, Andrzej Jarzabek wyszeptal:
>
>
>>>>> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a
>>>>> jednak firmy realizują projekty.
>>>> To, że ty nie umiesz nie znaczy, że nikt nie umie.
>>> Ale ja też bym chciał umieć.
>>
>> To sobie chcij, tylko że jak się to ma do tematu dyskusji?
>
> Dobry analityk potrafi zatuszować swoje błędy. Na dodatek im
> lepszy, tym trudniej znaleźć kogoś, kto to zweryfikuje. Analityk
> to nie szef, który ma prawo robić błędy - więc jak nie mając
> żadnego analityka z dziedziny zatrudnić analityka który zweryfikuje
> kolejnych? Poważnie pytam.

Założyć spółkę z kolegą, który się na tym zna.

>> Pewnie, że może pytać, ale musi też się liczyć z odpowiedzią "tak ma
>> być, nie będę tłumaczyć dlaczego". I nie chodzi o to, że jest nieomylny,
>> tylko o to, że jego omylność jest wliczonym w działalność ryzykiem.
>
> Fochy też są wliczone?

Czas weryfikuje to, czy analityk raczej faktycznie się zna i
przynajmniej jak stanowczo twierdzi, że jest tak a nie śmak, to
najczęściej faktycznie nie jest śmak, czy jednak wali fochy jak mu ktoś
wytyka błędy. Czy da się tego z góry uniknąć? Może najlepiej nie
zatrudniać asertywnych, dynamicznych, pewnych siebie, wertykalnie
zintegrowanych dupków z przerostem ego?

> Nie wiem dlaczego, ale najczęściej w moim
> doświadczeniu dobrze radziły sobie firmy, które utrzymują jakiś standard
> kultury.

Jak dla mnie elementem tej kultury jest też szacunek dla
współpracowników i nie zakładanie z góry, że skoro mamy różnicę zdań
związanych z ich specjalnością, to ja mam rację, a oni są niedouczeni.

>>> Dostarczę program szybciej ale z większą liczbą błędów?
>>
>> Może wcale nie z większą, ale powiedzmy nawet, że tak. Otóż jeśli
>> studiowanie ustaw i wypytywanie analityka dlaczego jest jak jest
>> spowoduje, że zaimplementowanie danego kawałka funkcjonalności zajmie
>> cztery tygodnie zamiast dwóch, to program będzie dwa tygodnie wcześniej
>> oddany do testów a może nawet wdrożony do produkcji, co dać może tyle,
>> że znalezionych zostanie więcej błędów, niż znalazłby programista
>> czytający ustawę.
>
> To jest jeden z modeli, ja go nazywam UMLowym. Drugi jest taki, że
> programista rozumie co robi.

Rozumie, co robi, ale niekoniecznie zna dziedzinę równie dobrze, co
analityk. Jeśli analityk powie programiście, żeby zrobił źle, to
programista rozumiejąc, co robi, nadal tworzy program z błędem.

> Właśnie po to, żeby nie musiał czytać ustaw
> istnieje obieg informacji, tu: analityk pytany przez programistę.

Jak najbardziej, ale jeśli analityk przekazał już programiście
informację potrzebną do implementacji programu, i możne nawet
wytłumaczył dlaczego i po co na tyle, na ile da się szybko wytłumaczyć,
to spędzanie dodatkowo potencjalnie długiego czasu na szczegółowym
tłumaczeniu dlaczego tak, a nie inaczej, wydaje mi się mało produktywne.
Jeśli analityk mimo zgłoszonych wątpliwości jest pewien, że tak jak
mówi, jest dobrze, to lepiej albo wypuścić program robiący właśnie tak i
ewentualnie potem poprawić, albo zatrudnić lepszego analityka.

> Rozumiejąc kontekst społeczny pytania analityka jako tego wyżej przez
> programistę jako tego niżej dodam, że może warto zatrudniać ludzi, którzy
> wiedzą, jaką spełniają w danym momencie rolę. Istnieją różne modele
> współpracy analityków i programistów, również (?) takie, gdzie analityk
> mówi, dlaczego A jest niemożliwe, a programista dlaczego B jest
> niemożliwe - a wtedy najczęściej trzeba kreatywnie wypracować
> jakieś rozwiązanie C.

Pełna zgoda. Ale przecież też programista może powiedzieć, że coś jest
niemożliwe bez konieczności tłumaczenia analitykowi teorii obliczeń,
teorii złożoności, założeń paradygmatów programistycznych, problemów
wynikających z duplikacji, synchronizacji wątków albo Liskov
Substitution Principle. Dla analityka też powinno wystarczyć, że jak
programista mówi "niemożliwe/trudne/niepraktyczne", to jest pewien limit
pytania "dlaczego" po którym sensowną odpowiedzią będzie tylko "uwierz
mi, że tak właśnie jest".

>> Nawet jeśli douczony nie znaczy idealny, to nadal nie ma żadnego
>> argumentu. No i odnosiłem się do tego, że przedstawiłeś temat jako
>> niepojęty, w któym nic się nie da wiedzieć. Jeśli tak jest i głupek
>> wioskowy może mieć rację równie dobrze co fachowiec, to żadnych
>> fachowców nie potrzebujesz, ale też bez sensu żeby programista czytał
>> ustawę, skoro nawet twórca ustawy nie wie, co znaczy jej treść - niech
>> zrobi po uważaniu, najlepiej tak, żeb było najprościej.
>
> Nie zauważyłem wcześniej argumentacji o niezatrudnianiu analityków,
> a tylko o rozmowie pomiędzy pracownikami. Oczywiście to żaden argument.

Była argumentacja, że analityk nic nie wie, bo nikt nic nie wie. Otóż
nawet jeśli nikt nie wie na dany temat wszystkiego, to są tacy, co
wiedzą więcej on innych. No chyba że chcesz zatrudnić specjalistę od
diety różowych jednorożców.

>> Przepływ informacji jest jak najbardziej potrzebny, ale on też jest
>> możliwy bez czytania ustaw przez programistę.
>
> Ale najczęściej zawodzi, gdy ktoś mówi "tak ma być" i nie jest prezesem
> i nie zrobi przy tym jakiegoś przyjaznego gestu.

Można wprowadzić zasadę, że kto mówi "tak ma być" stawia kolejkę :)

>> W ukłądzie, o którym mówię, odniesiebnie sukcesu przez nową firmę jest
>> jak najbardziej możliwe, np. w scenariuszu gdzie doświadczeni analitycy
>> (albo chociaż spece od faktur) dogadują się z doświadczonymi inżynierami
>> oprogramowania i zakładają spółkę.
>
> Jeżeli mogę spytać: czy to prawda, że często takie firmy powstałe przez
> pączkowanie pozostają jako podwykonawcy?

Nie wiem jak często, na pewno nie tak, że "prawie zawsze". Ja się raczej
spotkałem z sytuacjami, że idą do klientów firm, dla których poprzednio
pracowali.

> I chciałbym też zauważyć, że
> powstają firmy, które z początku mają dwóch pracowników, studentów,
> którzy są jednocześnie prezesami.

Chyba większość takich firm bankrutuje albo się rozpada?

> Argument nie jest "czy programista zna ustawę lepiej niż analityk
> ds. Opisanych w Ustawie" tylko, jak widzę, "programista ma nie czytać
> ustaw" i "ma nie pytać analityka dlaczego tak". Nawet jak faktycznie
> coś zauważy.

Nie mój argument.

> Dla poparcia cytat:
> AJ:
> Raczej trzeba
> się nastawić na to, że fachowiec powie jak ma być, proramista napisze
> program, który to właśnie robi, potem fachowiec powie, że może być
> jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
> że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.

Przecież nie dlatego, że programista nie może pytać dlaczego, tylko
dlatego, że życie jest skomplikowane.