On 17/01/2013 17:12, darekm wrote:
> W dniu 2013-01-16 08:51, Andrzej Jarzabek pisze:
>> On 15/01/2013 22:28, Gotfryd Smolik news wrote:
>>> Ja tak z pozoru offtopicznie:
>>>
>>> On Thu, 27 Dec 2012, boryspower wrote:
>>>
>>>> Przykład: Stworzenie aplikacji do fakturowania
[...]
>> Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
>> wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
>> tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.
>
> 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.

> Naiwnością jest myślenie że znajdę
> dobrego fachowca i zrobi mi dobrze. Żeby wybrać tego douczonego muszę
> mieć szczęście albo samemu się douczyć.

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.

>> W ogólnym przypadku założenie, że inżynier oprogramowania po
>> przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
>> mądrzejszy od fachowca jest dość ryzykowne.
>
> W drugą stronę również. Ale razem mają większe kompetencje niż każdy z
> osobna, należy to "tylko" wykorzystać.

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.

>>> Obstawiam że takich przypadków jest sporo - coś co wydaje się
>>> proste zawiera pułapki które później trudno usunąć.
>>
>> Natomiast inżynier oprogramowania powinien wiedzieć jak robić programy,
>> z których dowolne pułapki można łatwo usunąć.
>
> Dowolne i łatwo: to chyba nie inżynier. To jest słownictwo menadżera.
> Oczywiście w zależności od projektu konkretne pułapki można taniej lub
> drożej likwidować/omijać. Ale może też należało by oszacować ryzyko
> awarii i potencjalne koszty i wdrożyć zabezpieczenia niekoniecznie
> programistyczne. Tylko prawnicy i matematycy mogą skutecznie twierdzić
> że wszystko można na 100% przewidzieć.

Nic mi nie wiadomo o prawnikach ani matematykach, ale w praktyce
tworzenia oprogramowania nie ma znaczenia, czy absolutnie zawsze łatwo,
tylko właśnie ryzyko.

>> Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
>> robić, a my dostarczamy program, który robi właśnie to", albo usługę
>> "nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
>> powinien robić i jak, a wy się zgodzicie albo nie".
>
> Jeżeli zamawiający potrafi samodzielnie wykonać usługę ale chce ją
> taniej to wybierze wariant pierwszy. Jeżeli nie zależy na efekcie (np
> decyzja została narzucona , chce pogrążyć wykonawcę itd) to wybierze
> wariant drugi.

Rzeczywistość jest raczej trochę bardziej skomplikowana. Po pierwsze -
druga opcja będzie zwykle droższa. Po drugie istotne jest, dlaczego
klient w ogóle zamiawia oprogramowanie, skoro do tej pory nie miał
funkcjonował. Bywa tak, że związane jest to ze zmianą potrzeb czy
sytuacji, i może być tak, że zamiawiający nie ma dobrego rozeznania w
tej noowej sytuacji - więc bardziej mu się np. opłaci zamówić
oprogramowanie z analizą, niż samemu zatrudniać analityków.

Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
stworzenia oprogramowania do wystawiania faktur też jest raczej przepaść.

> Jeżeli usługa jest nietrywialna i istotna dla obu stron to uczciwie
> będzie współpracować. Wykonujący i zamawiający wzajemnie nabywają od
> siebie nowych kompetencji. Ryzyko też powinno być podzielone, ale nie
> wiem czy równo, solidarnie czy uczciwie?

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.

>> Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
>> wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
>> zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.
>
> 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.

>> Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
>> analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
>> niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
>> nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
>> księgowych, prawników czy kogo tam, którzy określą zgodność z przepisami.
>
> 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?

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.

Pytanie jednak - jak zwykle - o kasę. Czas analityków, a zwłaszcza
dobrych analityków, kosztuje. Jeśli zamawiający ma księgowego, który wie
wystarczająco dużo o wystawianiu faktur i może poświęcić odpowiednio
dużo czasu na uzgadnianie specyfikacji, to może szukać tańszej opcji
wykonania pod dyktando bez analizy. Bez analizy nie znaczy, że
programiści czy menedżerowie nie będą wypytywać, sugerować, czy
znajdować prawdopodobne dziury w specyfikacji, tylko że jak mimo to
program wystawi fakturę niezgodną z przepisami, to wykonawca będzie mógł
powiedzieć, że program jest zgodny z uzgodnioną specyfikacją, a on tylko
to obiecywał - o niezgodność z przepisami zamawiający może mieć
pretensje do swojego księgowego.

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.

> Tyle że nie taka jak się zazwyczaj słyszy: klienta: że coś
> jest niedoprecyzowane (przecież pisze "zgodnie z przepisami"), analityka

Jeśli wykonawca zobowiązał się zrobić "zgodne z przepisami", to powinien
mieć analityków od tego. Jeśli nie potrafi takich zatrudnić, nie
powinien się zgadzać na taki zapis.

> że ktoś czegoś nie przedstawił (nikt nie mówił o takim przypadku),
> programistę ("ja nie znam się na przepisach"). Nie powinno być ostrego
> podziału kompetencji kiedy każde naruszenie granic jest zamachem na
> niezależność.

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.

> Jak każdy weźmie fragment odpowiedzialności za cudze błędy
> to może nie powstanie "ziemia niczyja" kiedy projekt pada lecz nikt nie
> ma wyrzutów sumienia.

Jak każdy weźmie fragment odpowiedzialności, to w razie problemów każdy
będzie miał inne zdanie na temat, który dokładnie fragment kto wziął.