Ryzykujemy upadek firmy z powodu jednego obrażonego pracownika…

To częste zjawisko: zemsta. Nie ma tu znaczenia czy "słuszna" czy nie bo nie ma słusznej zemsty, jest tylko łamanie prawa. Czy jest na to lekarstwo? Hm... nie ma na zemstę, czy jest lekarstwo na kradzieże? Tak: nie mieć czego ukraść lub nie być od tego uzależnionym. Zapewne dla wielu z Państwa brzmi to kuriozalnie ale im bardziej jakiś biznes (model biznesowy) oparty jest na tajemnicy tym bardziej jest on ryzykowany zaś im więcej mamy tajemnic tym bardziej tracimy wolność. Jaki z tego wniosek? Należy albo nie mieć tajemnic albo mieć świadomość konsekwencji ich posiadania i być przygotowanym. W przeciwnym wypadku ryzykujemy potencjalny upadek firmy z powodu jednego obrażonego pracownika... Ale... projektując system można wielu rzeczom zapobiec systemowo i proceduralnie... np. kluczem ochrony przed takim ryzykiem jest coś, co pewnie wzbudzi u wielu nie małe emocje: żaden pracownik firmy nie powinien być twórcą oprogramowania w niej wykorzystywanego...

Czytaj dalejRyzykujemy upadek firmy z powodu jednego obrażonego pracownika…

Jolt Award: Visual Paradigm for UML

[singlepic id=228 w=320 h=240 float=right] Nie tylko ja jestem zdania, że używanie zaawansowanych systemów wspomagających prowadzenie analiz jest cechą analityków (firm), którzy przekroczyli pewien próg profesjonalizmu. Zapewne pojawią się tu zarzuty o zarozumiałość albo "wydziwianie", ale rozejrzyjmy się. Analityk to osoba wspierająca np. wdrażanie złożonych systemów ERP lub innych, nie mniej złożonych dedykowanych systemów (oprogramowania). Skoro ktoś poleca swoim klientom zaawansowane oprogramowanie wspomagające zarządzanie złożoną firmą czy organizacją, to jak prezentuje się na tym tle on sam, używający prostych i pracochłonnych narzędzi by to złożone oprogramowanie projektować? Można powiedzieć: "po narzędziach go…

Czytaj dalejJolt Award: Visual Paradigm for UML

Jak zdobyć nasze maile? Jak ich nie wysłać?

No cóż, nie jest rzadkością zrobienie literówki w adresie, nie jest także złe zaadresowanie listu w sytuacji gdy wszechobecne funkcje podpowiadania adresata wstawią w pole Do: kogoś innego z naszej listy kontaktów. Nie trzeba wielkiego pośpiechu czy nieuwagi by się to przytrafiło. Umieszczanie w stopce sentencji w rodzaju "jeżeli nie jesteś adresatem tego listu powiadom o tym nadawcę i zniszcz treść przesyłki" jest dość naiwne jeśli niechcący wyślemy super ofertę nie temu klientowi... To zjawisko to klasyczny przykład czynnika ludzkiego, z którym poważni ludzie nie dyskutują tylko szukają sposobu jak mu zaradzić. Na pewno nie jest skutecznym sposobem administracyjny zakaz mylenia się z dużą karą za pomyłkę: po protu nikt się nie przyzna, i mało który przypadkowy adresat doniesie sam na siebie. Jak zaradzić problemowi? W sumie nie aż tak trudno: nie używać poczty elektronicznej do wysyłania ważnych dokumentów. Czyli? Zamiast ryzykować wysłanie mailem ryzykownej treści, np. negocjowanej umowy, bezpieczniej jest umieścić plik w repozytorium i udostępnić uprawnionej osobie (stosowanie kompresji zip na hasło jest tylko półśrodkiem). Może to być system zarządzania przepływem pracy, nieskomplikowane repozytorium z funkcją monitorowania, inne. Możliwości jest wiele, ważne by nie "przedobrzyć" z procedurami. Jak nie trudno się domyśleć, i tu warto wykonać rzetelną analizę wymagań, procesów komunikacyjnych wewnątrz firmy z jej otoczeniem, analizę ryzyk. Jednak o wymaganiach w tym poście już nie napiszę :) zaś moi klienci wiedzą, że używam w ważnych przypadkach, systemu wymiany dokumentów zamiast poczty od ponad trzech lat.

Czytaj dalejJak zdobyć nasze maile? Jak ich nie wysłać?
Cykl tworzenia oprogramowania metodą zorientowaną na modele (Model Driven Development)
MDA Development Sequence (źr. Business Process Trend Newsletter, Maj 2004 nr. 5)

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że "nie święci garnki lepią") dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi "projektowania" czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści. Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to: Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu. Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu. Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: "wiedza organizacji" tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalejHej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Znaczenie i zapotrzebowanie na specjalistów IT

Według Forrester zmieniający się porządek zapotrzebowania na specjalistów IT wynika głównie z trzech rzeczy: Coraz większa popularność różnych technologii i rozwiązań jak np. SaaS (Software -as-a-service) bądź Business Intelligence, które wpływają na zapotrzebowanie na konkretne umiejętności; Coraz bardziej rosnące znaczenie outsourcingu ze względu na łatwą dostępność czasową specjalistów o bardzo wysokich kwalifikacjach jak również opłacalność takiego modelu dla obu stron; Chęć redukcji kosztów wpływa coraz bardziej na decyzje podejmowane przez decydentów. Podczas badań jako skalę przyjęto skalę procentową odzwierciedlającą opinię decydentów w przebadanych firmach na temat znaczenia (ważności) ról w…

Czytaj dalejZnaczenie i zapotrzebowanie na specjalistów IT

Raport: Zarządzanie wymaganiami 2011

Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.) Jak widać brzmi znajomo z dwóch powodów: problemy znane każdemu i powody niestety także. Ciśnie mi się na usta "a nie mówiłem"... Czyli jednak wiemy że problemem projektów z zakresu inżynierii oprogramowania są zbyt proste metody i narzędzia zarządzania wymaganiami (pakiet biurowy), które w większości są stosowane. Wiemy, że modelowanie jest najskuteczniejsza metodą analizy i projektowania a mimo to nie stosuje się tych metod szukając stale "drogi na skróty". Dlaczego dostawcy oprogramowania nie stosują metod powszechnie jednak uznawanych za skuteczne?

Czytaj dalejRaport: Zarządzanie wymaganiami 2011

Cloud Computing to architektura systemu

Jak widać, można wskazać wiele korzyści z CC. Przede wszystkim model opłaty może być za gotowość, za realne wykorzystanie lub na innej zasadzie. Nie ma tu mowy o licencjach, jest mowa o wykonanej pracy. Problemem jest tu ocena czy danej firmie w ogóle CC pomoże, a jeśli tak to gdzie. Decydowanie się na CC nie powinno być efektem zauroczenia treścią np. takiej jak ta konferencji. Nie powinno być też emocjonalną decyzją po wysłuchaniu wizji dostawców takich usług. Skoro CC to jednak architektura, proponuję kolejność następującą: analiza biznesowa (cel projektu), analiza wymagań, projekt architektury systemu, decyzja, które komponenty system możliwe są do kupienia, a które należy potraktować jako zasób zewnętrzny (cudzy). Osobiście nie polecam podejścia polegającego na znalezieniu "fajnego" komponentu i zastanawianiu się gdzie go u siebie upchać. To często spotykany przypadek, w którym "coś nam sprzedano". Polecam rzetelne, pragmatyczne spojrzenie biznesowe, kończące się tym, że znajdziemy i kupimy od kogoś coś, co jest nam potrzebne i przyniesie korzyści, także finansowe.

Czytaj dalejCloud Computing to architektura systemu

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

A co mówią statystyki? Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com). Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.

Czytaj dalejSłabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy. Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się "opisem przedmiotu zamówienia".

Czytaj dalejPrawo autorskie, szpiegostwo przemysłowe i projektowanie

W sądach i urzędach giną dokumenty, nie musi tak być

Zapewne nie odtworzy się oryginałów ale poświadczone, elektroniczne kopie można posiadać. Dlatego urzędom, i nie tylko, sugeruje rozważenie: zamiast walczyć z wdrażaniem mało tu skutecznych, kosztownych i długotrwałych we wdrożeniu, systemów obiegu dokumentów, wdrożyć porządne repozytorium dokumentów, archiwów elektronicznych. Łatwiej jej wdrożyć, są w znacznej części gotowe wymagania dostępne na stronach Archiwum Państwowego. Zarządzanie procesem przepływu dokumentów jest trudniejsze bo po pierwsze, wymaga powyżej wykonanej analizy, po drugie system workflow i tak wymaga dobrego repozytorium dokumentów. Mając dobre archiwum zabezpieczymy lekko licząc 90% związanych z zarządzaniem dokumentami potrzeb bo: mamy ich kopie w repozytorium możliwe jest automatyczne monitowanie terminów właściwym osobom, możliwe jest więc dekretowanie, niemożliwe jest ukrycie tego, na jakim etapie (u kogo) jest dana sprawa i jak długo jest załatwiana. Tak więc można ... Czy ktoś chce mnie może przekonać, że w firmach dokumenty nie giną? Giną i to znacznie częściej niż w urzędach, więc pokory proszę w ocenie urzędów ...

Czytaj dalejW sądach i urzędach giną dokumenty, nie musi tak być

Koniec treści

Nie ma więcej stron do załadowania