Czym zajmuje się ustawodawca w IT

Obecne ustawy idą w kierunku ustalania metody projektowania systemów teleinformatycznych, opisywania ich szczegółów, metod powstawania. Po co na poziomie ustawy definiować np. pojęcie minimalnych wymagań skoro nie zdefiniowano tego minimum? To już elementy metodyki specyfikowana i tworzenia oprogramowania. Znacznie lepiej by było, gdyby powstał dokument będący np. metodyką dla projektów finansowanych ze środków publicznych. Po co tworzyć ustawowy proces tworzenia systemów teleinformatycznych? Wydaje mi się, że stwierdzenie czy jakikolwiek dokument spełnia ustawowe "minimalne wymagania dla systemu teleinformatycznego" jest niemożliwe bo jak? Jakim testem? Co miało by być wzorcem dla audytu? Ma jednak sens moim zdaniem, by wymagania na systemy były dokumentowane w postaci testów akceptacyjnych. Te są wymierne i "zerojedynkowe". Nie udawałoby się prawnikom dostawców oprogramowania wykazywać zgodności dostarczonego oprogramowania z wymaganiami w postaci OPZ (Opis Przedmiotu Zamówienia) w brzmieniu np. "system ma być wygodny w użyciu" bo każdy go jakoś tam jest wygodny. Należało by w drodze takich testów stwierdzić, czy oprogramowanie daje pożądane efekty. Tu nie będzie pola do popisu dla interpretacji prawnych, często niejednoznacznych zapisów w OPZ-tach. I na koniec: ustawodawca w moich oczach wykazuje, że nie ma kompetencji by tworzyć prawo. Zamiast tworzyć reguły, zaczyna opisywać konkretne metody ich realizacji a to zły kierunek. Po drugie te zbyt szczegółowe regulacje w ustawach wyglądają często na efekty złego lobbingu dostawców technologii. Może warto, by przy rządzie powstał jakiś THINK TANK ukierunkowany na systemowe, całościowe podejście do IT w administracji publicznej. Myślę, że Analiza Systemowa i [[Architektura Korporacyjna]], jako całościowe podejście, a nie lokalne w poszczególnych urzędach, jest na to sposobem. Niestety chyba nie mamy w rządzie kompetentnych ludzi...

Continue ReadingCzym zajmuje się ustawodawca w IT

Mega projekty czyli jak zjeść słonia

Uszczegóławianie wymagań odkładamy "na ostatni moment". W ten sposób "kwartał po kwartale" doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może "wylecieć" z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów. Pierwszy etap ma pewną cechę: tworzy jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem. Dlatego z reguły nie mają sensu: wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM), projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian), mega projekty ERPII czyli "all in one" dla firmy w ramach jednego projektu. Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku...

Continue ReadingMega projekty czyli jak zjeść słonia

Recepta na porażkę

recepta na porażkę: Wymagania zbieraj wyłącznie jako efekt burz mózgów i wywiadów z przyszłymi użytkownikami oraz ich przełożonymi, niech wszyscy spiszą je w postaci tabeli np. w arkuszu kalkulacyjnym i edytorze tekstu. Organizuj długie spotkania warsztatowe, po których powstają kolejne wiersze w tabelach. Wszystkie dodatkowe ustalenia załatwiaj mailem ad-hoc. Tak powstałą listę nazwij Wymagania i daj do realizacji. Projekty informatyczne to zawsze nowy cel i nowa droga ale dobrze znane środowisko. Dlatego wzorce jak najbardziej mają sens, ale nie recepty bo te tu nie mają zastosowania. Antywzorce, hm..., znamy statystyki i mimo to stale podejmowane sa nowe projekty, w których kluczową metodyką pracy jest warsztat-dyktafon, to czy zapisujemy to jako slajdy prezentacji czy z pomoc nawet bardzo dobrego narzędzia CASE nie ma żadnego znaczenia jeżeli faktycznie zapisujemy jedynie to, opis i obrazki, co podyktuje Święty User. Na zakończenie jedno zdanie: pojawienie się metod zwinnych (rok 2001, Agile Manifesto) nie zmieniło tej czarnej statystyki nawet o jotę, więc nic wskazuje na to, że są one w czymkolwiek lepsze. Wiadomo zaś, że stosowanie metod formalnych jest bardzo skuteczne ale kosztowniejszej od opisanych wyżej maili, arkuszy i tekstów. Jednak jeżeli średnie przekroczenie kosztów dochodzi do 200% to znaczy, że jednak metody formalne są per saldo znacznie tańsze... a są stosowane tam, gdzie "ryzyko jest duże" a przynajmniej ryzyko nie jest ignorowane. Czemu jednak tak rzadko stosuje się metody formalne? Bo jest różnica pomiędzy wiedzieć a umieć... Jeżeli więc ktoś mówi, "nie rób tego tak, bo to się raczej nie uda" (powyższe statystyki) to warto tego posłuchać i zapytać o pozostałe 20% bardziej udanych projektów.

Continue ReadingRecepta na porażkę