Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?

Propozycja powyższa (polecam pełny tekst) to próba ograniczenia roszczeń OZZ oraz ograniczenie typów urządzeń objętych tym parapodatkiem. Mam nadzieję, że kropla drąży kamień, i praktyki OZZ o innych “pasożytów” zostaną jeszcze bardziej ograniczone. Dlaczego? Bo miedzy innymi, co jest nie tylko nielogiczne ale jest zwykłym pasożytnictwem, obecne prawo skutkuje tym, że OZZ dostają pieniądze za to, że między innymi moje opracowania (do których nic nie mają owe OZZ), są przeze mnie i moich klientów kopiowane na papier i nośniki CD. Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?

Czytaj dalej Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?

Dokumentowanie wymagań na oprogramowanie ERP i podobne

Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…

Czytaj dalej Dokumentowanie wymagań na oprogramowanie ERP i podobne

Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Gdzie tkwi podstęp: Logika Biznesowa Dedykowana MUSI być udokumentowana osobno w sposób jednoznaczny, nie dający programiście pola do własnej interpretacji, a to wymaga opisania tego metodami formalnymi. Logika biznesowa dedykowana musi być odrębnym TWOIM kodem (w umowie prawa majątkowe do niego oraz umowa o ochronie Twojego know-how). Ale to dużo kosztuje! Dostawca oprogramowania i tak na Twój koszt to w jakiejś formie zrobi! Otóż praktyka pokazuje, że zaprojektowanie i wykonanie odrębnej Logiki biznesowej dedykowanej, kosztuje zawsze mniej (nie raz znacznie mniej!) niż koszt dostosowywania ogromnej istniejącej już logiki dostarczonej. Większość kupujących systemy ERP z powodu braku tej wiedzy i pod naciskiem dostawcy oprogramowania, przyjmuje niekorzystną dla siebie metodę wdrożenia i podpisując wcześniej niekorzystną dla siebie umowę (kastomizacja oprogramowania).

Czytaj dalej Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Śmierć aplikacji dedykowanych to mit

Nikt tu nie namawia nikogo do pisania zintegrowanych systemów ERPII od zera, jednak dostosowywanie ich (kastomizacja) w zasadzie przeczy zdrowemu rozsądkowi, o czym nie raz już pisałem (wyjaśnienie w cytowanym powyżej artykule). Przypomnę, że mamy tu dwa problemy: pierwszy to koszty kastomizacji dużego systemu są niemalże zawsze większe (ja od 20 lat nie spotkałem się z tym by były niższe) niż zaprojektowane nowego dedykowanego modułu. Drugi: kastomizacja powoduje, że całe know-how firmy (związane z tym dostosowywanym oprogramowaniem) zostaje przejęte przez dostawce oprogramowania, który może handlować nim na rynku.

Czytaj dalej Śmierć aplikacji dedykowanych to mit

Projekt wykonany – co było robione

Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM.

Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań). Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych.

Czytaj dalej Projekt wykonany – co było robione

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

Producent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta – kliencie pilnuj się, pomogę

Nie raz od klientów słyszę, że walka z dostawcę nie ma sensu, ale nie jest to prawda. Na etapie zawierania umowy zależy dostawcy bardzo, i jest to czas (ostatni!) by negocjować. Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!). Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!).

Czytaj dalej Producent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta – kliencie pilnuj się, pomogę