W dniu 2013-01-22 23:42, Andrzej Jarzabek pisze:
>> Ale to tylko na marginesie, to tylko przykład (abstrakt) zagadnienia,
>> który (niby) wszyscy znają więc mogą się wypowiadać.
>
> Ja się nie wypowiadam, czy jest skomplikowane, czy nie, bo się nie znam.
> Odnoszę się tylko do tego, czy da się znaleźć fachowców. Jakby się nie
> dało, to by nie było płatników VAT, bo nikt by nie potrafił wystawić
> faktury.

To tylko dowód na to że tacy istnieją. Czy wszyscy z nich byli
fachowcami w momencie jak rozpoczynali pracę w tej dziedzinie? Pytanie
jak ich wybrać pozostaje otwarte.

>
>>> Naiwnością jest myślenie, że jak nie potrafisz znaleźć fachowców, to
>>> będziesz potrafił się sam nauczyć na tyle, żeby stworzyć poprawnie
>>> działający program - tym bardziej na podstawie takiego myślenia dawanie
>>> klientom jakichkolwiek gwarancji.
>>
>> 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ć. A inne firmy będą mi przeszkadzać (nie
zawsze pomogą np w wyborze kandydata), a kandydaci potrafią dobrze
udawać że wiedzą.

>
>>> Na pewno dobrze jest, jeśli programista może się dopytać czy podzielić
>>> wątpliwościami, ale założenie, że wyłapie błędy analityka jest, jak
>>> pisałem, ryzykowne. Z drugiej strony jeśli ma tracić czas na czytanie
>>> ustaw, to IMO lepiej, żeby przeczytał sobie książkę o ATDD albo nauczył
>>> się jakiegoś narzędzia typu FitNesse albo Cucumber.
>>
>> 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.

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


>
> Poza tym mi nie tyle chodzi o to, co ja zabronię lub do czego zniechęcę
> programistę.
>
>>> Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
>>> stworzenia oprogramowania do wystawiania faktur też jest raczej
>>> przepaść.
>>
>> Ale mając błędne wyobrażenie jak w danym przypadku wystawia się faktury
>> też się nie stworzy dobrego oprogramowania.
>
> Zależy jak szeroko pojmujemy określenie "błędne". Jeśli błędne znaczy
> również np. niepełne, to jak najbardziej można.
>

Można co bo nie rozumiem?

> Prawdę mówiąc nie wierzę w takie szacunki.
>
>>>> A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
>>>> nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
>>>> pojawią się orzeczenia, praktyka. A program musi być tworzony tu i
>>>> teraz.
>>>> Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
>>>> programistów.
>>> 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.


>>> W rzeczywistości przecież jakoś firmy działają, faktury wystawiają i
>>> podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
>>> księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
>>> rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po bandzie. I
>>> tego samego wymagasz od analityka.
>>>
>>
>> Zgadza się że wymagam, ale czy otrzymam?
>
> To samo pytanie można zadać w przypadku dowolnego księgowego, prawnika
> czy kogo tam odpowiadającego za zgodność faktur z przepisami. Czy w
> zasadzie kogokolwiek (odpowiednio do zadania).
>
No właśnie.

>> Przecież nie mówię o tym, aby coś robić bez analizy. Natomiast przyczynę
>> upatruję w tym co można przeczytać między wierszami: wykonawca otrzymał
>> specyfikację i tak zrobił program, nieistotne dla niego jest to czy to
>> jest dobre dla zamawiającego, czy się analityk pomylił, analogicznie
>> pozostałe strony.
>
> 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
strukturach takie sprzężenie występuje naturalnie, natomiast tam gdzie
jest bardzo sformalizowana hierarchia jest stosunkowo ograniczone.


>>> I jeśli ktoś nie potrafi zatrudnić analityków albo odróżnić douczonych
>>> od niedouczonych, to nie powinien prowadzić biznesu polegającego na
>>> usłudze "z analizą" - bo przecież programista może przeczytać ustawę i
>>> poprawić babole niedouczonego analityka.
>>
>> Nie ma takich to zupełnie nie potrafią oraz takich co potrafią na 100%
>> bezbłędnie. W wielu przypadkach nie da się też powiedzieć że ktoś jest
>> bezwzględnie lepszy, bardziej douczony. Wiec powyższa zasada jest
>> bezużyteczna.
>
> Żey zasada była użyteczna nie potrzeba takich, co zupełnie nie potrafią
> ani takich, co potrafią na 100%. Wystarczy, że są tacy, co potrafią na
> 99% i tacy, co potrafią na 1%.
>
>> 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ć.

>>> Jest różnica między kwestią, czy programista powinien wyrażać
>>> wątpliwości, sugerować czy wypytywać (się zgadzam, że powinien), a tym,
>>> czy powinien wgłębiać się w ustawy i interpretacje - IMO niekoniecznie
>>> powinien, a jeśli ma być to odpowiedź na problem, że analityk jest
>>> niedouczony, to moim zdaniem problem ten ma lepsze rozwiązania.
>>>
>> po pierwsze niekoniecznie niedouczony (może się pomylił, może nie
>> zapytał, może nie skojarzył)
>> po drugie przedstaw to rozwiązanie
>
> Dla firmy? Po pierwsze, żeby potrafić ocenić kompetencje zatrudnianych
> specjalistów. A jak się nie potrafi, to nie prowadzić działalności
> wymagającej tych kompetancji.

Większość firm które się rozwija nie stosuje się do tego. Pojawia się
nowa możliwość to się z niej korzysta z takimi ludźmi jakimi się
dysponuje. Jak się uda to do już się prowadzi działalność z
wystarczającymi kompetencjami (bo to czego brakowało to nabyli)

Po drugie żeby oszacować ryzyko i
> zatrudnić tylu analityków i o takich kompetencjach, żeby to ryzyko można
> było uznać za dopuszczalne - żeby jak jeden się pomyli, to drugi go
> poprawił. Jeśli zatrudnienie takiej ilości analityków czyni interes
> nieopłacalnym, to znowu - nie prowadzić danej działalności.
>

j.w.
Po co drugi analityk jak wiem że mój inżynier oprogramowania ma pewne
doświadczenie tam, gdzie analityk wydaje się słabszy

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.


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



--
Darek