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
>>
>> 1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
>> 2. Spytać "fachowca" jak ma być
>> 3. Stwierdzić że coś nie pasuje
>> 4. Sprawdzić to i owo w internecie
>> 5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)
>
> 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. 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ć.



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

>> Potem można zabrać się za rozważania jak program ma działać.
>>
>> Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
>> na to jak można wtopić na błędach założeń :)
>> Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
>> podatek który musi być ujawniany na dokumencie) jest dopuszczalne
>> na wiele sposobów, w tym takich trudniejszych do wymyślenia,
>> ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
>> się do któregoś spośród tych wielu)
>
> Oczywiście z druiej strony założenie, że fachowiec usiądzie i napisze od
> ręki specyfikację, w której będzie wszystko, co potrzeba. 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.
>
>> i wtedy na .podatki pojawia
>> post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
>> bo twierdzą że system nie pozwala" :P
>>
>> Nie, nie mam na myśli stawki itede :)
>>
>> 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ć.

>
>> Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
>> "24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
>> umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
>> poprawienie wszystkich pól, bo nie sposób przewidzieć która
>> z kombinacji "metod" może wyskoczyć.
>> Uczciwie - przewidziałbyś?
>
> 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.
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?


> 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 przygotować dokumentację/opis projektu
>>
>> Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
>> narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
>> (patrz p.1 :), polecam osobiście zajrzeć do treści)
>
> 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. Tyle że nie taka jak się zazwyczaj słyszy: klienta: że coś
jest niedoprecyzowane (przecież pisze "zgodnie z przepisami"), analityka
ż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ść. 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.


--
Darek