Software Requirements czyli wymagania na oprogramowanie
Tym razem książki czyli co się dzieje na świecie. Książki z "całego świata" na mojej półce mają dwa zadania. Pierwsze to dowiedzieć się co i jak robią inni. Drugie to:…
Analiza wymagań – zrozumienie
Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki…
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...
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.
Rynek 2013
Firmy odkrywają, że sprawny obieg dokumentów zaczyna stanowić większą wartość dla klientów niż sprawność rachowania. Dlaczego? Bo nasi klienci postrzegają nas poprzez to, jak sprawnie ich obsługujemy a nie przez to, jak sprawnie księgujemy u siebie ich pieniądze. Tu warto zwrócić uwagę na to, że to co często nazywamy system CRM, to "jakaś" obsługa klientów a potem dopiero jakieś zbędne "lejki sprzedaży". Dlaczego zbędne? Bo każda firma, która w końcu z sensem wdrożyła budżetowanie wie, że plan przychodów i jego bieżąca realizacja to po prostu budżet i jego bieżąca realizacja więc ów "lejek" dubluje coś, co i tak powinno być (budżet przychodów). Po usunięciu "lejka" z zakresu wymagań pozostaje nam zarządzanie "sprawami" czyli obsługa zapytań, umów, faktur itp. To wszystko robi (potrafi) system workflow (zarządzanie przepływem pracy i dokumentów). A rejestr klientów? Akurat to nie stanowi żadnego problemu... Co mamy? Systemy CRM także nie są przedmiotem "wielkich planów zakupowych" bo w ich miejsce wchodzą systemy workflow: mają dokładnie taka funkcjonalność. Tak więc CRM jako strategia jak najbardziej, CRM jako kolejny system w firmie już nie koniecznie. Kluczowe ryzyko: systemów tego typu nie da się wdrażać "zwinnie" bo wymagają one bardzo dokładnej analizy taksonomii dokumentów przed rozpoczęciem wdrożenia...