Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę! Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy i "nieuchronność" kary za niepowodzenie. W efekcie Dostawca szybko staje się "Panem projektu", bo…
Na niedawno zakończonej konferencji beIT organizowanej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygłosiłem referat zatytułowany Filozofia czyli Aplikacja jako element biznesowej rzeczywistości (a nie gra komputerowa). Przesłanie tej prezentacji to: Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polegać na zrozumieniu i udokumentowaniu mechanizmu działania "tego czegoś" a nie jedynie na spisaniu zewnętrznych oznak tego działania i zarządzanie tym spisem. Referat miał lekkie podłoże filozoficzne :). Ten artykuł nie będzie jednak powtórzeniem referatu (wyżej link…
Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to: ... communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog) To "prawo" wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to - architektura - jest lepszym lub…
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…
Cóż, kolejny raz odkrywam, że jestem zwinny :). A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80'tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie "wodospadowe" złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie "rezygnacja z pracochłonnej dokumentacji" (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie…
