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…
Kolejnym problemem jest niestety jakość projektowania: Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce - PAP SA). Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów jest już raczej nieracjonalne...
Sam pomysł na metryki bardzo dobry, bardzo mi się spodobał, jednak ma on sens pod warunkiem, że będzie ona (metryka czyli format metadanych) jednolita (pomijam ogłoszona w terminie zapowiadanym w ustawie). Efektem było by jedno, dobrze opracowane [[JRWA]] dla całego kraju oraz spójne informacje o przebiegu spraw. Jest nawet instytucja, która ma stosowne kompetencje by ją stworzyć: [[Archiwa Państwowe]]. I co? I nic! Jak widać mamy bałagan... :( i chyba znowu popis niekompetencji... Metryka dałaby podstawy budowy spójnego systemu zarządzania wiedzą w administarcji. Niestety jak widać nowe ministerstwo popełniło albo falstart albo ktoś nie wie co robi...
zły model to złe oprogramowanie.... Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią. Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".
Swego czasu przewalała się w środowisku IT fala głosów za "certyfikacją zawodu informatyka". Po pierwsze pojawił się kłopot z definicją kim jest ów "informatyk", po drugie pojawił się kłopot z wykazaniem korzyści dla ogółu klientów, bo korzyść dla środowiska "informatyków" (co by to słowo nie miało tu oznaczać) jest prosta: ograniczenie dostępu do zawodu czyli jego monopolizacja. Zalety w rodzaju "podniesie się jakość usług" do mnie, i nie tylko do mnie, nie przemawiają. Nie wierzy w to nikt, kto ma w praktyce do czynienia z "certyfikowanymi" specjalnościami. Certyfikat (czyli po portu zdany test) to nic innego jak "wiem jak to robić" co nie ma nic wspólnego z "umiem to zrobić". Każdy (prawie) wie jak się biega, jak się robi zdjęcia, jak się śpiewa, wie (w końcu uczą tego w szkole podstawowej i średniej) jak się pisze książki i wiersze, wie .... większość z nas wie jak siw robi większość tego co mamy wokół siebie, czy jednak potrafimy? Certyfikaty itp. to w większości przypadków żadna gwarancja a nie raz wręcz odwrotnie.