On 18/01/2013 10:23, darekm wrote:
> W dniu 2013-01-18 00:06, Andrzej Jarzabek pisze:
>> On 17/01/2013 17:12, darekm wrote:
>>>
>>> Tylko co jak takich fachowców nie ma lub nie da się sprawdzić czy są
>>> douczeni, bo dziedzina jest nowa.
>>
>> No faktycznie, wystawianie faktur o coś, co wymyślili wczoraj.
>
> Właśnie że wymyślili i to nie raz. Zagadnienie fakturowania nie jest tak
> banalne jak się większości wydaje, twierdzę że jest bardziej
> skomplikowanie niż to co zwyczajowo nazywa się Elektronicznym Obiegiem
> Dokumentów.
>
> 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.

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

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

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

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.

>> Oczywiście, że współpraca jest jak najbardziej pożądana, ale dobrze jest
>> też mieć wspólne rozumienie tego, co jest sprzedawane i kto za co
>> odpowiada. A może nawet jest to w umowie.
>
> Ktoś powiedział że umowa jest na czas wojny, w normalnej współpracy się
> jej nie używa

Jeśli klieent i wykonawca mają rozbieżne wyobrażenia na temat tego, za
co jeden płaci drugiemu, to wojna jest całkiem prawdopodobna.

>>> Jak masz kompetencje to właściwie oszacujesz ryzyko i koszty, jeżeli nie
>>> to to jest hazard i albo się uda albo nie.
>>
>> Jak właściwie oszacujesz ryzyko i koszty, to też jest hazard i albo się
>> uda, albo nie. Na tym właśnie polega ryzyko.
>
> To nie to samo. Ryzyko jest zawsze. Każdy z projektów może wyjść albo
> nie, ale statystycznie łącznie przy prawidłowych szacunkach jesteś do
> przodu.

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.

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

>> Pytanie jednak - jak zwykle - o kasę. Czas analityków, a zwłaszcza
>> dobrych analityków, kosztuje.
>
> Jeżeli ktoś jest dobry to też efektywniej pracuje, więc niekoniecznie
> usługa musi być droższa.

Jest nominalnie droższa. Czy jest sumarycznie droższa, to zależy -
analityk, który efektywnie mówi ci rzeczy, które już wiesz,
niekoniecznie ci się opłaca. Dlatego też pisałem, czasem sensowna jest
usługa "z analizą", czasem bez.

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

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

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

Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji z
przykładami, stosowanie przy tym skutecznych metodologii i narzędzi,
częste dostarczanie działającego oprogramowania, dostarczanie
najbardziej wartościowej funkcjonalności w pierwszej kolejności,
porządny projekt, czytelny kod, TDD, prostota, prostota, prostota,
utrzymanie tego wszystkiego przy zmieniającej się specyfikacji przez
refaktoryzację.