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?

>Powiem w ten sposób - mam wiele lat przepracowanych w dużych firmach (a

Ok, to będzie ważne, zapamiętajmy więc to jako "FAKT A".

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

Autentyczna historia: w pewnej firmie trzeba było wymienić klozety, położyć
kafelki/flizy i takie tam. Zdziwienie brygady remontowej nie miało granic,
gdy okazało się że szef firmy zna się na tym lepiej niż oni (nie całe życie
był szefem firmy) i... po prostu nie przepuści, ma być zrobione dobrze. A
umowę robili prawnicy, co prawda nie jacyś nadzwyczajni, ale wystarczająco
dobrzy...

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

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

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

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

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

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

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

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

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

Wyobraź sobie - firma zamawiająca ma dział IT z 3-4 dobrymi fachowcami.
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.

>E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś działają,
>często z większym powodzeniem niż poprzednio.

W tej samej branży? Podaj przykłady. Ja znam jeden, ale facet najpierw, już
po bankructwie, spłacił wszystkich swoich wierzycieli.

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

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

Jak ktoś tego nie rozumie, to niech poszuka najbliższego sandboxa i robi
babki z piasku, a nie poważny biznes.