Dnia Sun, 27 Jan 2013 00:41:30 +0000, Andrzej Jarzabek wyszeptal:

> On 25/01/2013 10:34, darekm wrote:
>> W dniu 2013-01-22 23:42, Andrzej Jarzabek pisze:

>> Czy wszyscy z nich byli fachowcami w momencie jak rozpoczynali pracę w
>> tej dziedzinie?
>
> Nie mam pojęcia, ale jestem w stanie sobie wyobrazić, że są ścieżki
> kariery nie wymagające rozpoczynania pracy jako analityk od faktur nie
> wiedząc nic o wystawianiu faktur. Na przykład można zacząć od tego, że
> się skończy jakieś studia czy kurs, a potem się pracuje ileś czasu na
> stanowisku, na którym się samemu te faktury wystawia.

Część szkół biznesowych opiera się na tym modelu, z pominięciem ostaniej
linijki.

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

>> A inne firmy będą mi przeszkadzać (nie
>> zawsze pomogą np w wyborze kandydata), a kandydaci potrafią dobrze
>> udawać że wiedzą.
>
> Nie rozumiem w ogóle twojego problemu. Komu mają te firmy (i jakie firmy
> w ogóle) przeszkadzać? I przed kim kandydaci mają udawać? Zazwyczaj jest
> tak, że jak się przyjmuje kogoś do pracy, to rozmowę przeprowadza ktoś,
> kto się dobrze zna na temacie.
>
>>>> Tu jest różnica: wg Ciebie programista nie może(nie musi, nie
>>>> powinien) interesować się ustawami bo od tego jest analityk
>>> Może się interesować, czym chce. Według mnie nie powinien musieć.
>>
>> Widzę pewien dysonans. Programiście każdy może zgłaszać błąd bo wszyscy
>> wiedzą co program ma robić. Ale ten nie może nikomu, a szczególnie
>> analitykowi, bo ten jest nieomylny, perfekcyjny. Czyli najlepszy
>> programista to jak żołnierz - nie pyta się dlaczego.
>
> 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? Nie wiem dlaczego, ale najczęściej w moim
doświadczeniu dobrze radziły sobie firmy, które utrzymują jakiś standard
kultury. Co oczywiście każdy inaczej rozumie, niektórzy uważają
kwiecistą mowę za szczyty niedościgłe, inni traktowanie firmy jako My
a nie "ten #$%#%^ analityk/programista".

>>>> Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne)
>>>> ale jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę,
>>>> uniemożliwię) to tego zysku nie będzie.
>>>
>>> Może być zysk czasu.
>>
>> 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. Właśnie po to, żeby nie musiał czytać ustaw
istnieje obieg informacji, tu: analityk pytany przez programistę.

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.

>>>>> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak
>>>>> tego nie wiedzą sami twórcy ustawy?
>>>> To jest sztuka
>>> Znaczy, nie ma żadnego argumentu na to, że wszyscy razem dojdą lepiej
>>> niż douczony analityk.
>>
>> Niż idealny analityk to zgoda. Zazwyczaj jednak ma się do czynienia z
>> nie ideałami. I proszę nie przesadzaj w drugą stronę. To nie ma być
>> demokratycznie ustalanie specyfikacji.
>
> 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.

> Tylko że oboje dobrze wiemy, że w rzeczywistości tak nie jest. Nawet to,
> czy twóca ustawy ją rozumie, czy nie, jest nieistotne - istotne są
> praktyczne konsekwencje wystawiania takich a nie innych liczb na
> fakturach. I analityk jest od tego specjalistą, żeby wiedzieć, jaka jest
> praktyka: co się powszechnie robi i urząd się nie czepia, do czego się
> jednak czepia, jak interpretują to sądy i tak dalej.

Nie znam się na wystawianiu faktur, ale większość oprogramowania
ma opcję ręcznej modyfikacji i późniejszego sprawdzania spójności danych
księgowych. Wie to, jak niektórzy mówią, "każdy głupek". Analitycy wciąż
mają najwięcej do zrobienia w doprowadzeniu całości do stanu, który
będzie pozwalał użytkownikowi lawirować pomiędzy przepisami, ale
programista ma swoją rolę, której analityk za niego nie spełni. M.in.
jak napisać system, który potrafi wyjść z sytuacji, w której dane
zostały z powodu błędu - jakiegokolwiek - doprowadzone do stanu,
w którym wymaga on poprawienia. Bez współpracy analityków i programistów
to się nie uda. Współpraca polega na tym, że obie role znajdują
w proponowanych rozwiązaniach błędy, które wymagają korekcji.

>>> A ja natomiast nie mówię o tym. Jeśli założysz, że wykonawca,
>>> analityk,
>>> programista, i kto tam jeszcze starają się zrobić tak, żeby klient był
>>> zadowolony, to nadal niekoniecznie czytanie i interpretowanie ustaw
>>> przez programistę jest najlepszym sposobem na osiągnięcie tego celu.
>>
>> Same starania mogą nie wystarczyć. Zakładam że każdy poprawnie wykonuje
>> swoje zadania, z typową jakością (dobrze, ale nie idealnie).
>> odpowiednio dobrane sprzężenie zwrotne (np. przepływ informacji od
>> programisty do analityka) podnosi stabilność czyli pewność osiągnięcia
>> celu. W luźnych
>
> 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.

>>>> Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach,
>>>> prawnik sprawdzi tylko kary umowne, bo nie zna kompetencji własnej
>>>> firmy a programisty i tak nikt nie zapyta czy np ma wolne moce
>>>> przerobowe. Karykaturalne ale do pewnego stopnia prawdziwe.
>>>
>>> Współczuję doświadczeń.
>>>
>> To są cudze doświadczenia, ja za nie płaciłem choć mogę korzystać.
>
> Skoro za nie płaciłłeeś, to tym bbardziej współczuję.

Współczuję Wam obu :)

>> Pojawia się nowa możliwość to się z niej korzysta z takimi ludźmi
>> jakimi się dysponuje.
>
...
>> Po co drugi analityk jak wiem że mój inżynier oprogramowania ma pewne
>> doświadczenie tam, gdzie analityk wydaje się słabszy
>
> Jak ma, to dobrze, i zapewne takiego doświadczenia nabędzie pracując w
> danym temacie. Z drugiej strony jeśli ma dopiero czytać ustawy i spędzić
> dużo czasu na pytaniu analityka "dlaczego", to może da się lepiej
> wykorzystać jego czas.
>
>> To co piszesz jest bardzo dobre dla działających firm. Przy takim
>> nastawieniu nikt nowy się nie pojawi, nie będzie konieczne zmagać się z
>> nową konkurencją a ze starą ustalono podział runku.
>
> Większość nowych firm dość szybko bankrutuje, wtapiając oszczędności
> założycieli. Sensownym punktem wyjścia do ograniczenia tego ryzyka jest
> rozkręcanie interesu z luźmi, którzy się znają na tym, na czym się
> trzeba znać.
>
> 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? 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.

>>> Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji
>>> z
>>
>> Czyli jednak zakładasz współpracę z analitykiem przy tworzeniu
>> specyfikacji? Bo jeżeli tak to w zasadzie mamy to samo zdanie.
>
> Współpraca to jedno, czytanie ustaw przez programistów to zupełnie inna
> sprawa.

Programiści z zasady nie czytają ustaw. Nie ma nich UMLa, a ustawy
są napisane po chińsku ;). Programista to taki konwerter UMLa
na kod, czasami wyjdzie kupić coś do jedzenia - tylko dzięki temu
wiadomo, że to jednak człowiek. pl.comp.programming?

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.

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.

--
Edek