Sprzedam Ci prawa do kodu czyli wielka ściema

A może chcecie prawa do kodu źródłowego?

A jasne, możemy chcieć. “No to zapłaćcie za to prawo”. A przepraszam za co teraz? Kod, który powstał to utwór zależny, jest więc chroniony i już mamy na niego wyłączność, nie musimy ekstra za to płacić. Ale nie chcemy tego sami pisać (kodować) jeszcze raz. No dobrze, patrzymy na faktury, a tam jest kilkaset godzin programistów. Czyli co? Już zapłaciliśmy za ich pracę, za ten kod! Wystarczy!

Kiedy pojawia się problem?

W większości przypadków z jakimi się niestety spotykam to projekty, w których nie powstała opisana tu dokumentacja. Jaki mamy efekt? No jest kod, wszelkie prawa do niego i jego logiki ma wykonawca (jest autorem całości). Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych podlega wyłącznie ochronie jako dzieło literackie, jednak niestety to-co-program-ma-robić to tylko idea, a ta nie podlega ochronie (stwierdzenie faktu, że wystawiamy faktury, jako treść, nie stanowi żadnego zdatnego do ochrony tajemnicą firmy know-how). Tak więc wszelkie prawa do kodu ma w takim wypadku programista bo sam od zera to napisał (kod).

Pada propozycja: za dodatkowe pieniądze sprzedamy prawa majątkowe do kodu, będziecie się Państwo czuli bezpiecznie. I teraz pytanie: jaką wartość ma nieudokumentowany kod oprogramowania? Tysiące linii kodu programu, nie raz kilka milionów, pisany bez projektu w wielu iteracjach. Mamy którąś tam jego wersję, w końcu powstawał w bólach, wielokrotnie modyfikowany, bez projektu. Nakład pracy znacznie przewyższający jego przepisanie. Kto i jakim kosztem będzie ten kod analizował by go zrozumieć i rozwijać? Ten kod, bez jego autora, jest BEZWARTOŚCIOWY a My, bez tej opłaty, nie mamy żadnych praw do tego za co zapłaciliśmy (poza licencją czyli prawem do korzystania).

Tak więc niejednokrotnie oferta na sprzedaż praw do kodu to zwykła ściema!

Czytaj dalej Sprzedam Ci prawa do kodu czyli wielka ściema

Krótki wpis o śladowaniu

Dobrze opracowany, kompletny model organizacji, łączy w sobie:

model motywacji biznesowej,
[[model struktury organizacyjnej]],
model procesów biznesowych (wymieniony już powyżej),
model reguł biznesowych.
Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym, analizowane procesy są wywodzone z modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń.

Mając tak opracowany kompletny model organizacji, zawierający śladowanie, i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu.

Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana obecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadanie poprawnie wykonanego modelu.

Czytaj dalej Krótki wpis o śladowaniu

Nagrane referaty video z konferencji

"Jeśli chcesz opisać prawdę, elegancję zostaw krawcom."(A. Einstein) Poniżej wybrane moje wystąpienia. Regularnie dzielę się wiedzą na konferencjach, bywam zapraszany przez dostawców oprogramowania ERP by opowiedzieć ich klientom jak podejść…

Czytaj dalej Nagrane referaty video z konferencji

Jedno wymaganie – kilka perspektyw

Tak więc każde wymaganie:

kojarzymy z realizującym go przypadkiem użycia,
testujemy (z pomocą dobranego scenariusza testowego),
dokumentujemy modelem opisującym jego realizację (np. Obiekt biznesowy w modelu dziedziny).
Takie podejście powoduje, że zanim jeszcze dotkniemy gotowego produktu (tu niestety już po jego wyborze) możemy po pierwsze: przetestować samą specyfikację a po drugie przekazać potencjalnemu dostawcy (na etapie zapytania) pełna informację o tym, czego oczekujemy od produktu.

Powyższe podejście w postaci ‘full wypas” może być pracochłonne, dlatego możliwe są warianty pośrednie czyli tylko dla wymagań oznaczonych jako ryzykowne budujemy testy lub elementy modelu dziedziny, jednak mamy narzędzie do panowania nad tym ryzykiem. Po drugie zyskujemy narzędzie do weryfikacji, odbiór oprogramowania nie będzie sprawdzaniem listy dziesiątek cech, będzie “jazdą próbną na sucho” a więc relatywnie tania metodą testów: dostawca deklaruje (oferta na nasze zapytanie) zgodność z naszymi wymaganiami a te są weryfikowalne.

Czytaj dalej Jedno wymaganie – kilka perspektyw

Jak przygotować zapytanie ofertowe?

Ten artykuł jest pewną kontynuacją poprzedniego. Potraktujmy go jako "prostszą wersję" :) popartą oczekiwaniami przyszłego wykonawcy, który w swoim artykule niejako "składa zamówienie na dokument wymagań". Wpadła mi swego czasu…

Czytaj dalej Jak przygotować zapytanie ofertowe?

Wymiećmy spod kołdry brudy informatyzacji

W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że: - Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w…

Czytaj dalej Wymiećmy spod kołdry brudy informatyzacji

Troszkę o narzędziach… czyli jak pracuje firma analityka – moja

Jednym z głównych problemów wielu projektów analitycznych (i nie tylko) jest komunikacja i dokumentowanie działań. Projekty analityczne mają to do siebie, że opisują organizację beneficjenta projektu. Tworzenie jej modeli wymaga "sprzężenia…

Czytaj dalej Troszkę o narzędziach… czyli jak pracuje firma analityka – moja

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty “na żywioł”. Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany “maintenance”) niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.

Czytaj dalej Znaczenie ma nie wielkość projektu, a cykl jego życia…