Brak umiejętności tworzenia specyfikacji biznesowej powoduje ogromne straty. Tworzone są projekty, które nie rozwiązują problemu (bo problem nie był właściwie zdiagnozowany), lub szuka się nowych rozwiązań, zamiast zauważyć już istniejące, dużo tańsze (wiesz, że np. każdego roku w Polsce tworzone jest parędziesiąt dedykowanych platform e-learningowych, mimo że paręset (!) jest już napisanych i gotowych do wdrożenia, z dokładnie takimi samymi funkcjonalnościami?).
Proces o którym dziś Ci opowiem ma wiele różnych nazw. Określa się go często jako „Specyfikacja biznesowa”, „analiza wymagań”, „wymagania funkcjonalne”, „potrzeby biznesowe”, itd. Z jednej strony jest to podstawa pracy zespołu, który w jednym dokumencie może spisywać wszystkie potrzeby zgłoszone z różnych departamentów firmy a z drugiej strony zaś specyfikacja jest często nieodłącznym elementem zapytania ofertowego i najczęściej dotyczy oprogramowania informatycznego.
W jaki sposób zrobić specyfikację biznesową? W jaki sposób przeprowadzić analizę wymagań biznesowych? Od A do Z.
Pierwszym, esencjonalnym krokiem jest ustalenie formy przepływu informacji względem osoby, do której piszesz. Czy jest to ktoś, kogo już znasz? Czy na przykład piszesz do kogoś całkiem obcego – z obcej, jeszcze nie znanej firmy? Zupełnie inaczej będziesz wdrażał w projekt kogoś, kto już Wami współpracuje i zna Waszą firmę lub dokonania, a inaczej do kogoś, kto pierwszy raz o Was słyszy.
Jeśli jest to pierwszy kontakt, zacznij od opisania tła projektu: napisz zdanie o firmie, waszej branży, pozycji na rynku i realizowanym przedsięwzięciu oraz jego celach. Przechodź od ogółu do szczegółu. Następnie powinieneś opisać wszystkie funkcjonalności systemu, cechy produktu lub parametry rozwiązania, które chcesz zamówić lub stworzyć wraz z dostawcą. Oto przykład: gdy zamawiałem platformę do kursu wideo Business Skills Academy, musiałem zdefiniować, jakie elementy chcę tam umieszczać, jak to powinno wyglądać i jakie możliwości ustawień produktu powinienem mieć. Musiałem zadać sobie mnóstwo pytań o to jak będzie to, co ujrzeć ma klient, w jaki sposób będę ustawiał opisy i odcinki, gdzie będę je hostował i jakich preferencji grup potrzebuję. Tu właśnie może pojawić się pierwszy poważny problem związany z tworzeniem specyfikacji. Najczęściej podczas pisania nie do końca znamy wystarczający poziom szczegółów rozwiązania które zamawiamy albo szczegółów projektu, w który wdrażamy innych.
Nie ma odgórnego, powszechnie obowiązującego standardu tworzenia specyfikacji wymagań biznesowych. Jego forma uzależniona jest od kształtu samego projektu, dostępnego czasu, budżetu, wewnętrznych procedur i innych aspektów. Czasami, np. zamawiając system CRM, specyfikacja oprogramowania może być niesłychanie długa. Niekiedy jednak, np. zamawiając wizytówki potrzebujesz jedynie przesłać projekt, napisać na kiedy, ustalić koszt i wybrać formę: czy druk powinien być cyfrowy czy offsetowy, a także czy powinna być jakaś folia na powierzchni.
Wymagania funkcjonalne. Wymagania niefunkcjonalne.
Wymagania w przypadku systemów informatycznych można podzielić na funkcjonalne i niefunkcjonalne. Funkcjonalne to kontekst powstania nowego systemu, opis użytkowników i grup – a więc to, kto będzie korzystał z narzędzia (na przykład administratorzy, klienci instytucjonalni, klienci indywidualni, moderatorzy, partnerzy i inni uczestnicy). Każda z tych grup może mieć inne uprawnienia, możliwości a czasem nawet wygląd w system.
Powinieneś także stworzyć opis funkcji systemu oraz sposoby korzystania z niego przez każdego z jego użytkowników, a więc: co i jak może w nim zrobić administrator, co może zrobić klient, co może zrobić handlowiec, a co księgowa – jeśli oczywiście przewidywane przez Ciebie są takie role. Wówczas – jeśli wdrażacie np. system CRM – księgowa może wystawiać i windykować faktury, a także generować raporty, handlowiec wypełnia umowy, a produktowiec umieszcza w systemie oferty. Jednocześnie jednak handlowiec nie może tworzyć własnych ofert, księgowa wypełniać umów, itd. Każdy ma tylko to, do czego jest uprawniony.
———
Ćwiczenie 1:
Ponieważ najlepiej jest uczyć się na bieżąco, najlepiej gdy w tym momencie spiszesz specyfikacje projektu tak, jak potrafisz. Postaraj się zawrzeć w niej wszystko co uznasz za stosowne, i wróć do dalszej części, aby udoskonalić swoją specyfikację w kolejnych krokach.
———
Dobrą praktyką jest spisywanie wymagań biznesowych w postaci tak zwanych. „przypadków użycia” (use cases), czyli ponumerowanych, pogrupowanych i jednoznacznie ponazywanych spraw. Przypadki użycia koncentrują się na przedstawianiu interakcji pomiędzy określonym użytkownikiem a systemem. Każdy przypadek użycia to opisana prosta sekwencja kroków, czyli zdarzeń zainicjowanych przez użytkownika i zadań wykonywanych przez system. Przykładem może być tu przypadek użycia pt. wystawienie faktury. Mógłby on wyglądać następująco:
- Księgowa otwiera umowę podpisaną przez klienta, którą handlowiec wprowadził do systemu.
- System sprawdza korzystając z bazy GUS i bazy dłużników czy kontrahent istnieje i jest wiarygodny.
- Po weryfikacji pokazuje informacje mówiącą o tym czy istnieje i czy warto zwrócić na coś uwagę. Sprawdza również czy taka faktura dla tej umowy nie została już wystawiona.
- System generuje plik PDF z fakturą i wysyła do kontrahenta na korespondencyjny adres e-mail.
Poza przypadkami użycia, rolami i ogólnymi funkcjonalnościami warto także uwzględnić w specyfikacji następujące rzeczy:
1. Opis środowiska, a więc na przykład informacje o tym, że firma korzysta np. z systemów iOS zamiast Windowsa, mają określone przeglądarki internetowe albo korzystają z dodatkowych oprogramowani które powinny być kompatybilne, np. poczta Google czy Outlook.
2. Warto także uwzględnić opis systemów, z którymi nowe rozwiązanie powinno się komunikować. A więc np. system do wystawiania faktur powinien łączyć się z systemem który prowadzi całą księgowość i skrzynką pocztową, która wyśle fakturę do klienta.
———
Ćwiczenie 2:
Przeredaguj wspomnianą wcześniej specyfikację uwzględniając informacje, które zdobyłeś w powyższej części. Popraw błędy i uzupełnij tekst o te elementy specyfikacji, których wcześniej brakowało, np. przypadki użycia czy opis środowiska.
———
Jakie błędy popełnia się przy tworzeniu specyfikacji wymagań biznesowych?
Pierwszym jest brak jasno sprecyzowanych priorytetów. Niektóre funkcjonalności powinny być obowiązkowe i kluczowe, niektóre są jednak drugorzędne. Nawet, jeśli zamawiasz rozwiązanie kompletne, to powinieneś uprzedzić jakie funkcjonalności będą dla Ciebie kluczowe, wówczas zwykle będą one dostarczone szybciej i w lepsze jakości. Warto stworzyć tabelę, która określi „Must have”, „Should have” oraz „Nice to have” w projekcie. Ewentualnie można skorzystać także z metody MoSCoW, którą opiszę bardziej szczegółowo w innym wpisie.
Drugi dość popularny błąd to przesada z nadmierną ilością wymagań. Czasami firmy przychodzą z tzw. „koncertem życzeń”. Jeśli jednak nie są one spójne z celami firmy, lub nie mają jasnych i zyskownych zastosowań, owe życzenia powinny być usunięte z listy. Dzięki temu nie przepłacicie i szybciej dostaniecie produkt końcowy.
Trzeci to mało precyzyjne plany na przyszłość. Być może zamawiane rozwiązanie będzie kiedyś kopiowane na inne serwery, albo tłumaczone na inne języki. Niekoniecznie musisz zajmować się tym już teraz, ale wspominając o tym dostawcy będzie on uwzględniał na przyszłość możliwość rozbudowy sytemu o wskazane funkcje albo wyceni przeniesienie praw autorskich do kodu – tak, abyś mógł dowolnie korzystać z narzędzia, także w celach dalszej odsprzedaży, i samodzielnych udoskonaleń.
Kolejnym błędem jest także pisanie specyfikacji w pojedynkę. Przy okazji nauki owej umiejętności nie ma problemu z działaniem tego typu. Pamiętaj jednak, że na twoją specyfikację powinny spojrzeć także inne osoby, których dotyczyć będzie budowane rozwiązanie.
Nie możesz także wychodzić z założenia, że wszystkie wymagania spisze się dopiero na starcie projektu, lub że nie będzie problemu z dodaniem kolejnych funkcjonalności w trakcie trwania prac. Czasami takie możliwości istnieją – czasami nie, czasem też zmiany tego typu są bardzo drogie. Aby uniknąć zaistnienia takich czynników powinieneś uzyskać potwierdzenie od zarządu dla końcowej wersji specyfikacji. To będzie podstawa dla Was do tego, by jako firma działać spójnie, z jednym, zatwierdzonym dokumentem.
Czasami specyfikacji brakuje odpowiedniego sformatowania tekstu. Podział na funkcjonalności formalne, nieformalne, tło projektu, informacje o firmie i tak dalej. Choć wydaje się to zbędne lub służące tylko czytelności projektu, pamiętaj że dokument ten ułoży w głowie osoby przygotowującej ofertę cały projekt w spójne i zrozumiałe definicje. Łatwiej będzie go wyceniać, a to może uchylić drogę do uzyskania niższej ceny lub większych możliwości negocjacyjnych (ponieważ firma, która wie, co chce, jest wygodniejsza do współpracy od takiej, która komunikuje się chaotycznie i na obsługiwaniu której traci się więcej czasu).
Ostatni element, który chcę poruszyć to umiejętność przełożenia na papier tego, co widzi się przed oczami jako końcowy produkt. Pamiętaj: nikt nie domyśli się tego, czego nie ma w tekście. Każda oczywistość dla Ciebie może nie istnieć dla Twojego rozmówcy. Twoja dwuznaczność opisu może wpłynąć na to, że otrzymasz inny produkt od tego, który chcesz. Dlatego po tym jak napiszesz specyfikację, powinieneś przeczytać ją ponownie zastanawiając się nad tym, jak inaczej można zrozumieć napisany przez Ciebie tekst. Jakie inne rozwiązanie może stworzyć dostawca czytając Twój opis? Im więcej znajdziesz możliwości, które prowadzą do innych rozwiązań niż to, które chcesz osiągnąć – tym lepiej. Dzięki temu dopiszesz zdania które ujednoznacznią Twoje zamówienie.
Wymagania niefunkcjonalne
Należy teraz skupić się na wymaganiach niefunkcjonalnych. Są to te ograniczenia nakładane na budowane rozwiązanie, które nie wiążą się bezpośrednio z zadaniami przezeń wykonywanymi. Dobrym przykładem są tu parametry jakościowe stawiane przed aplikacją. Wyobraź sobie sytuację, w której zamawiasz system opisywany powyżej – ten, który między innymi jest w stanie wysłać wygenerowaną fakturę na maila klienta. Stworzone narzędzie wykonuje swoje zadanie, wszystko działa poprawnie i nie ma powodu by nie zapłacić wykonawcy za odebraną usługę. Wszystko działa dobrze, ale… jest jeden problem. Po wciśnięciu przycisku powodującego generowanie faktury system robi to przez cały kwadrans, a przez ten czas nie można na nim robić innych rzeczy. Wszystkie wymagania funkcjonalne są spełnione, a mimo to paraliżuje to pracę Waszej firmy. Dlatego Twoja specyfikacja powinna zawierać oprócz cech funkcjonalnych także i niefunkcjonalne.
Mowa tu o:
– określeniu średniego czasu, w którym dane rzeczy powinny się dziać: na przykład o zadbaniu o to, aby strona ładowała się w mniej niż sekundę,
– przepustowości rozwiązania, czyli możliwości pracy pięćdziesięciu osób jednocześnie lub umożliwieniu dwóm tysiącom klientów bycia zalogowanym w tym samym momencie w systemie,
-określeniu maksymalnego czasu wdrożenia, a także wymagań wobec dokumentacji, która ma zostać opracowana przez wykonawcę: pozwoli ona później samodzielnie modyfikować i edytować pewne cechy rozwiązania,
– uwzględnieniu zasad bezpieczeństwa, czyli szyfrowania danych, odporności na ataki hakerskie, backup danych i dostosowanie się do określonych wymogów prawnych tam, gdzie to potrzebne,
– trudnego do opisania, ale bardzo ważnego współczynnika jakości; czasami będzie to jakość kodu, którą będą w stanie napisać i odczytać tylko programiści, czasami będą tu wymagania jakościowe odnośnie grafiki, które także trudniej zdefiniować w funkcjonalnościach. Możesz posłużyć się innymi stronami i gotowymi grafikami żeby przybliżyć jakość estetyczną, którą oczekujesz, i najczęściej w taki sposób jest ona definiowana na tym etapie. To też pozwoli odbiorcy zwizualizować sobie rozwiązanie bardziej zbliżone do tego, o którym myślisz.
W tym miejscu także warto pomyśleć o załącznikach, czyli: związanych ze szkicami formularzy, przykładowy wygląd faktury, logotypy firmy bądź księgę znaku, wygenerowany raport, albo uściślone procedury obowiązujące w firmie.
Na koniec
Ćwiczenie 3: Uzupełnij specyfikację o elementy z kolejnej części artykułu. Tak przygotowany projekt powinien spełnić oczekiwania wszystkich.
Najważniejsze
Pisanie specyfikacji projektu pozwala odkryć potrzeby firmy. W większości przypadków są gotowe rozwiązania na istniejące sytuacje, i zamiast tworzyć od nowa cały system, warto kupić istniejący (lub gotowy w 80%) aby zapłacić dużo mniej za spełnienie 100% wymagań. To potrafi oszczędzić w dużych projektach nawet setki tysięcy złotych.
Powodzenia!
Zawodowo jestem najbardziej dumny z TEGO i TEGO.
Wierzę, że rozwój wynika ze zrozumienia.
Od ponad 10 lat związany jestem ze szkoleniami oraz konsultingiem. Pomagam firmom budować know-how i uczę pracować efektywnie i wydajnie.
