On Monday, 22 July 2013 10:15:55 UTC+1, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksh8j8$6hm$...@s...invalid...
>
> >Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
> >systemu CRM, księgowości czy payroll?
>
> A nie można używać do księgowości etc.? Jakiś zakaz jest czy co?

W sensie żeby powiedzieć księgowym "Zamiast zamawiać wam system za miliony
dolarów, postanowiliśmy użyć darmowego Linuxa. Macie tutaj komputer z
Linuxem i prowadźcie na nim księgowość. Jakby wam czegoś brakowało, to piszcie
na listę linux-kernel, na pewno znajdzie się ktoś, kto wam doda co trzeba za
friko"?

> >kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
> >najtrudniej było z niej skorzystać.
>
> Ok, ale firma zamawiająca, sprzedająca "szlauchy i kalosze" (nie ma w niej
> dość "mocy przerobowej" do zrobienia programu, ale szef przypadkiem ma
> ukończone studia z informatyki, z zarządzania i z psychologii) może nie dać
> się łatwo wykiwać. I szybko zorientować, że ktoś sabotuje współpracę
> (utrudnia korzystanie).

Myślę, że takie przypadki wykonawca może wpisac w ryzyko.

Co natomiast proponujesz firmom potrzebującym zamówic oprogramowanie, gdzie
przypadkiem szef nie ma ukończonych studiów z informatyki, zarządzania i
psychologii?

> >Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które by
> >można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.
>
> Nie znasz? To znaczy że nie ma sensu zamawiać u ciebie programów ;)

Nie ma sensu przede wszystkim dlatego, że nie świadczę takich usług. Skoro
ty jednak wiesz o takich standardach, to może byś dla paddierżania razgawora
rzucił jakimś numerkiem ISO czy coś?

> >Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
> >wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten, co
> >je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego
>
> W tym właśnie miejscu przypomnijmy sobie "FAKT A" (czyli: że masz bogate
> doświadczenie i pracowałeś w wielu firmach).

Gwoli uwagi, fakt A brzmi jednak tak, że mam _wiele lat_ doświadczenia i
pracowałem w _kilku_ dużych firmach. "Wiele" jest oczywiście pojęciem
względnym, jest to wiele lat w stosunku do całości trwania mojej kariery
zawodowej i według mojego subiektywnego odczucia - oczywiście istnieją ludzie,
którzy pracują w branży znacznie dłużej i dla nich moje "wiele" może być
całkiem niewiele.

> Jeżeli Agile i ogólnie współpraca układają się tak dobrze - to nigdy nie
> musiałbyś "rozczytywać kodu" - bo po prostu tym kodem zajmowałby się ten, co
> pierwotnie go napisał.

Rozpatrujemy sytuację, kiedy wykonawca nie stosuje Agile, bo zamawiający
rozpatruje wyłącznie kontrakty fixed price fixed scope jako rzekomo najlepiej
zabezpieczające jego interesy. Całe rozważania o przejęciu kodu biorą się,
przypominam, z mojego pytania "a co jeśli po wykonaniu kontraktu fixed price
fixed scope okaże się, że chociaż program jest zgodny z umową, to UAT wykaże,
że przycisk jest źle umieszczony, a wykonawca zażąda ćwierć miliona za
przesunięcie go". Sprzedaż źródeł z programem nie załatwia problemu.

> To co robiłeś wynikało właśnie z tego, że - podobnie jak nieuchronna jest
> "zmiana" - podobnie nieuchronne jest, że kiedyś "ktoś inny będzie musiał
> poprawiać nasz program".

Jest kolosalna różnica między tymi sytuacjami.

Jeśli tym kims jest pracownik firmy, to taka sytuacja zdarza się bardzo rzadko
(przy jakiejkolwiek sensownej organizacji pracy). Problem dotyczy modułów,
które są bardzo rzadko ruszane, bo jeśli coś jest często ruszane, to
prawdopodobnie jest w zespole kilku developerów, którzy mają jakieś
doświadczenie z kodem danego modułu albo przynajmniej z modułami
współpracującymi z nim i można się ich spytać.

Dalej - nawet jeśli nei ma developerów, którzy by cokolwiek o tym kodzie
wiedzieli, to jest spora szansa, że przynajmniej będzie kilka osób z wiedzą o
funkcjonalności czy użytkownaiu danego modułu (analitycy, testerzy).

Dalej - nawet jeśli na module jako takim nikt się nie zna, to wielu członków
zespołu rozumie architekturę systemu, w którą ten moduł się wpasowuje, co
wybitnie może ułatwić zrozumienie kodu źródłowego i np. wnioskowanie o
możliwych skutkach ubocznych wprowadzanych zmian, skutecznych sposobach
testowania itd.

Dalej - jak dobrze pójdzie, moduł kodowany jest przy pomocy tych samych
coding standards, których dany programista uzywa na co dzień, co również
sprzyja rozczytaniu.

Jeśli mówimy o jakimś jednym egzotycznym module, to również brak sukcesu w
rozczytaniu nie powoduje straszliwych skutków - zawsze można zastąpić go nowym
modułem relizującym akurat potrzebny klientowi podzbiór funkcjonalności, ze
starego skanibalizować to, co się da odczytać a resztę oznaczyć jako
"deprecated".

Oczywiście jeśli konkretnie wykonawca stosuje Agile, to dostaje kilka
dodatkowych narzędzi zmniejszających prawdopodobieństwo takiego zdarzenia lub
ograncizających jego skutki - shared code ownership, programowanie parami,
acceptance tests, unit tests, simpel design, clean code, no bugs.

To jest zupełnie inna sytuacja, niż rzuceniem w nowego potencjalnego wykonawcę
milionem linijek kodu źródłowego, którego tamten wcześniej nie widział na oczy
i powiedzeniem "tutaj mam taki programik, chciałbym przesunąć ten o przycisk
trochę w lewo, ile czasu by wam to zajęło?"

Dodatkowo różnica jest taka, że wykonawca ma motywację do tego, żeby kod
pisany wewnętrznie był zrozumiały dla jego własnych pracowników, natomiast
jeśli oddaje kod klientowi, to w jego interesie jest to, żeby kod był jak
najtrudniejszy do przeczytania przez kogokolwiek innego.

> >kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny z
> >napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja
>
> Ba! Niektórzy autorzy nie żyją, inni są niedostępni. Ale wiesz co?
> Wynaleziono pismo, druk i nawet coś takiego jak dokumentacja, rysunek
> techniczny, UML i takie tam.

Które niekoniecznie będą dostarczone z kodem źródłowym. A jeśli będą bo umowa
tego będzie wymagać, to w interesie wykonawcy jest dostarczyć je w takiej
postaci, żeby były jak najmniej użyteczne.

> >Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale też
> >zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają, albo
> >proponują wyższe ceny.
>
> Dokładnie tak, jak w przypadku np. samochodów: można kupić tanie auto, bez
> gwarancji, do którego nie ma części zamiennych ani serwisu - albo nieco
> droższe, w którym jest serwis, są części zamienne i gwarancja, a do tego tak
> proste w konstrukcji że nie wymaga np. specjalnych narzędzi do naprawiania.

Jeśli chcesz mieć analogię do samochodu, to raczej sensowna byłaby taka:
kupując nowoczesny samochód wielu rodzajów napraw nie będziesz w stanie
wykonać ani samodzielnie, ani nie wykona ich nawet mechanik nie będący ASO
producenta, bo potrzeba specjalistycznych narzędzi. Żądanie kodu źródłowego to
tak, jakbys poszedł do przedstawiciela powiedzmy Hondy i powiedział, że chcesz
kupić nowy model Civic, ale żeby się zabezpieczyć na wypadek gdyby producent
przestał naprawiać, zbankrutował, albo podniósł znacząco ceny seriwsu, to
chcesz ten samochód ze wszystkimi schematami, projektem mechanicznym,
elektoronicznym, kodem żródłowym oprogramowania itd. wszystkim co potrzebne,
żeby sobie samemu takie narzędzia zbudować albo zlecić to komuś. I ile coś
takiego by kosztowało ekstra?

> >Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?
>
> A jest jakiś problem, aby to wpisać? Oczywiście konkretne sformułowanie może
> być nieco bardziej wyrafinowane i konsultowane z prawnikami.

A jak konsultowany prawnik powie "z całym szacunkiem, ale pan to chyba na
głowę upadł"? Ja prawnikiem nie jestem, ale jestem sobie w stanie wyobrazić
przynajmniej kilka powodów, dla których wpisywanie takich rzeczy mogłoby być
czymś, czego zarówno zleceniodawca, jak i wykonawca woleliby uniknąć.

Dla zelceniodawcy ryzyko jest przede wszystkim takie, że w razie czego sąd
uzna taki zapis za nieegzekwowalny. Dla wykonawcy problem może się pojawić w
momencie, kiedy zleceniodawca stwierdzi, że woli nie płacić za program i
zacznie szukać dziury w umowie, która mu na to pozwoli. Łatwo mu wtedy będzie
powiedzieć "nasz fachowiec nie rozumie tego kodu (lub: trudno mu zrozumieć ten
kod), ergo nie jest łatwy do zrozumienia, ergo niezgodny z umową, ergo nie
zapłacimy." I weź się potem w jednym czy w drugim przypadku ciągaj po sądach i
udowadniaj że coś jest czytelne albo nieczytelne.

> Coś takiego w umowie powinno skutecznie odpędzić partaczy przy np.
> przetargu.

Raczej odpoędzi wszystkich trzech, którzy nie uciekli w momencie zażądania
kodu źródłowego.

> >Przecież gdyby zamawiający miał na etacie programistów potrafiących napisać
> >ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.
>
> Może ich ma, ale oni mają co innego do roboty? A może ich ma, ale zbyt mało
> ich jest?

To będą wyjątkowe przypadki - większość firm nie ma działu rozwoju
oprogramowania. Jeśli ma, ale ci ludzie mają co innego do roboty, to też mają
co innego do roboty niz pisanie i sprawdzanie szczegółowej specyfikacji
liczącej setki stron. A jeśli nawet to zrobią, to fakt, że na codzień zajmują
się czym innym znaczy, ze tak czy inaczej ich szanse na wyłapanie wszystkich
błędów przegapionych przez resztę ludzi zajmujących się danym kontraktem nie
są takie duże.

> Wyobraź sobie - firma zamawiająca ma dział IT z 3-4 dobrymi fachowcami.

"Dział IT z 3-4 dobrymi fachowcami" zazwyczaj oznacza kolesi od zarządzania
Microsoft Exchange, konfigurowania firewalli i zmieniania toneru w drukarkach,
a nie ludzi zamujących się inżynierią oprogramowania.

Z drugiej strony - spora część mojego zawodowego doświadczenia związana jest z
tworzeniem oprogramowania dla banków inwestycyjnych lub używanego przez banki
inwestycyjne. Takie banki mają działy IT liczące setki osób, zajmujące się
między innymi produkcją bardzo zaawansowanego oprogramowania na własne
potrzeby i zatrudniające naprawdę bystrych kolesi do wytwarzania tego softu.

Myślisz, że takie banki, kiedy zamawiają oprogramowanie u zewnętrznych
dostawców, nie mają problemów z błędnymi lub nieprecyzyjnymi specyfikacjami?

> Program, aby był na czas, musi pisać 15-20 ludzi. Więc firma zewnętrzna. Ale
> tych 3-4 fachowców może dość łatwo zorientować się, czy wszystko jest
> robione jak trzeba - czy też wykonawca partoli.

Nie może, przynajmniej dopóki umowa nie zostanie podpisana i wykonawca nie
zacznie faktycznie czegoś robić.

> >Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
> >przesłanek. W rzeczywistości mogą być dużo wyższe.
>
> Teraz wiem, dlaczego ja nie zamówiłbym u ciebie programu - raz piszesz
> konkretne liczby (250 000, 100 000 etc.), potem "w rzeczywistości mogą być
> dużo wyższe".

Panie prezesie, koro pan nie rozumie czym jest ryzyko i co to jest wartośc
oczekiwana, to ja bym nawet nie chciał, żeby pańska firma zamawiała u mnie
oprogramowanie, bo co z tego, że obieca mi w umowie nawet nie dwa, ale i pięc
milionów, skoro jak zgłoszę się po odbiór, to pańska firma zapewne będzie już
dawno w trakcie postępowania upadłościowego i tylę z tych milionów zobaczę.

> >Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
> >oparta była na szacowanych zyskach czy oszczędnościach z użycia tego
>
> I dlatego te oszacowania muszą być rzetelne, a nie wyssaną z palca
> konfabulacją.

Rzetelne? Powiedzmy, ze w fazie UAT użytkownicy zgłaszają problem, że UI
wprowadza ich w błąd i czasem wywołują nie tę operację, co chcieli. Wykonanie
błędnej akcji naraża klienta na stratę, ale jak często właściwie użytkownicy
będą popełniać ten błąd i jakie będą wielkości straty za każdym razem zależy
od wielu czynników. Żeby to rzetelnie oszacować musiałbyś zrobić badania
behawioralne na reprezentatywnych grupach, eksperymenty z grupą kontrolną,
musiałbyś zatrudnić dobrych specjalistów od psychologii żeby ci zaprojektowali
te eksperymenty i powiedzieli jakie czynniki musisz wziąć pod uwagę.
Specjaliści mogą ci powiedzieć, że użytkownicy mogą się inaczej zachowywać jeśli
wiedzą, że pracują w środowisku testowym, a inaczej jeśli mają świadomość
pracy w prawdziwym środowisku produkcyjnym. Mogą dodatkowo powiedzieć, że
zachowania mogą się zwiększać w czasie, np. na początku będą bardziej ostrożni
a potem wejdą w rutynę, lub odwrotnie - że w miarę używania programu będą
popełniać coraz mniej pomyłek. Jedno i drugie wraz z potrzebnymi do rzetelnego
oszacowania danymi liczbowymi trzeba zmierzyć eksperymentalnie. Skoro
potrzebne jest badanie zachowań użytkowników w warunkach produkcyjnych to i w
takich warunkach trzeba ich badać, i to w dość szerokim przekroju środowisk,
żeby zapewnić reprezentatywność danych. Oczywiście tobie i twoim pracownikom
raczej mało kto da prowadzić badania we własnym środowisku produkcyjnym, więc
będziesz musiał zatrudnić szacowną i budzącą zaufanie instytucję, np. jeden z
dużych uniwersytetów albo jakiś Gallup Institute. Taka instytucja też coś
weźmie za firmowanie tych badań, im bardziej szacowna i godna zaufania, tym
weźmie więcej. Na podstawie zebranych w ten sposób danych zatrudnieni przez
ciebie wybitni naukowcy zrobią analizę i wyciągną wnioski. Żeby jednak było
żetelnie, musisz wynająć inną pulę wybitnych naukowców i poprosić ich o
zrobienie peer review. Te recenzje wykażą ewentualne braki metodologiczne,
alternatywne interpretacje i hipotezy, problemy w argumentacji. Następnie
zatrudniasz kolejną pulę naukowców, których prosisz o zajęcie stanowiska, a
następnie dopuszczasz do debaty między wszystki grupami, z której to debaty
wyłaniają się kolejne badania, które trzeba wykonać w celu potwierdzenia lub
eliminacji poszczególnych hipotez. Cały proces powtarzasz tak długo, aż
zatrudnieni naukowcy osiągną consensus.

Jak widzisz rzetelne oszacowanie może być całkiem kosztowne. Czy wydasz 50
milionów dolarów, żeby rzetelnie oszacować straty wynikające ze źle
umieszczonego przycisku w programie za dwa miliony, jeśli przesumięcie tego
przycisku kosztuje 250 tysięcy dolarów? Czy będziesz czekał 10 lat?

Co więcej, nie jest nawet tak, że możesz od razu wiedzieć, albo nawet
rzetelnie oszacować koszty tych badań. Przecież koszty będą zależały od tego,
co powiedzą wybitni specjaliści, czego sam nie będąc wybitnym specjalistą nie
jesteś w stanie przewidzieć nawet w przybliżeniu, oraz tego, jakie będą wyniki
badań, które dlatego trzeba przeprowadzić, że właśnie tego nie wiadomo.

Pytanie powstaje więc: w jaki sposób rzetelnie oszacujesz koszty rzetelnego
szacowania?