Specyfikacja a wydajność pracy

Jedną z bardzo ważnych spraw w tworzeniu oprogramowania jest jego specyfikacja definiująca, co i jak ma zostać stworzone. Jej forma nie jest ważna, zaś sam fakt posiadania jej ułatwia znacząco pracę i wypływa pozytywnie na wydajność pracy programisty.

Nie zależnie od tego jakiego rodzaju metodykę stosujemy w projekcie, zawsze siadając do pracy powinniśmy wiedzieć co mamy zrobić. Nie musimy wiedzieć jak ale co jest bardzo ważne.

To co powinno definiować dokładnie wynik naszej pracy, nasz cel.

Niejasność wymagań, jak i określenie ogólnego celu, doprowadza do sytuacji, gdy my programiści, siedzimy przed komputerem i dosłownie marnujemy czas naszego pracodawcy próbując osiągnąć dany cel. Nie piszę tutaj o sprawach myślenia jak rozwiązać problem, jaką architekturę, infrastrukturę i inne sprawy, ale jak doprowadzić to co rozpoczęliśmy do tego by osiągnąć wynik który mamy zaprezentować.

Tak naprawdę, specyfikacja jest tym czymś, co stosujemy prawie w każdej naszej czynności. Świadomie lub nie świadomie wiemy co chcemy osiągnąć – im bardziej doprecyzujemy co chcemy tym łatwiej wykonamy nasze zadanie.

Weźmy dla przykładu kompletnie błahą rzecz, zakupy na tydzień. Wiemy, że musimy kupić jedzenie, nasza lodówka jest pusta, a finansowo bardziej opłaca się pojechać gdzieś do jakiegoś marketu i kupić kilkanaście rzeczy na raz. Zrobiliśmy wcześniej porównanie cen i dla przykładu zgrzewka wody w lokalnym sklepie kosztuje nas 15zł zaś w hipermarkecie 11zł. Czyli na pewno wiemy, że tam trzeba pojechać. Pakujemy się do autobusu lub samochodu i jedziemy na zakupy. Mijają dwie godziny, w naszym koszu jest masa rzeczy, pewnie połowy z nich nie wykorzystamy teraz, ale w przyszłości może się przyda albo się wywali – w końcu jest taniej.

Wychodzimy ze sklepu i z zażenowaniem patrzymy na zegarek, tyle czasu. A wystarczyło by zdefiniować wcześniej co chcemy kupić, zrobić listę rzeczy i już czas wybierania będzie znacząco krótszy – czas w stania kolejce nie koniecznie. Ale jesteśmy wstanie zoptymalizować nasz czas, dzięki czemu będziemy mieli go więcej na to by zrobić coś innego – ugotować obiad, książka, whatever.

Tak samo jest z projektami, jeżeli siadamy do projektu, gdzie specyfikacja jest super ogólna, będziemy tracić czas nad zrozumieniem jak i rozszyfrowaniem jak coś można zrobić.

Przejdźmy na przykład bardziej informatyczny

Ktoś nas prosi o wyświetlenie wszystkich powiadomień w systemie, mówiąc, że te tyczące aplikacji X nas nie interesują. Pokazuje nam screenshot jak coś ma wyglądać i prosi o estymację. Zadajemy kilka pytań, dowiadujemy się pewnych szczegółów, dajemy estymację i siadamy do pracy.

Stworzyliśmy widok tak jak powinien wyglądać, napisaliśmy mockupy, testy i zabieramy się do pisania query, które nam zwróci wszystkie powiadomienia zgodnie z założeniami. Od razu natrafiamy na problem, gdyż słowo powiadomienia jest nazwą wyświetlaną encji o nazwie akcje. Dodatkowo powiadomienia są wykorzystywane w dodatkowej encji o nazwie dokumenty, zaś każdy z dokumentów może być powiązany z opiniami, które na nowo są powiązane z powiadomieniami. Zaczyna nam się kręcić. Ale próbujemy dalej pisać.

Coś w końcu dostajemy za wynik, piszemy do osoby od specyfikacji i pytamy się czy o to jej chodziło? Dostajemy odpowiedź, że tak, tak to ma wyglądać. Więc poprawiamy pytanie i dopytujemy się czy wynik jest poprawy.

Dostajemy informacje, że jeżeli wyświetlamy to i to, to jest w porządku. Jednak naciskamy i dopytujemy się o konkretne encje z których mamy pobierać dane, gdyż to wygląda tak i prezentujemy opis jak do tego doszliśmy.

Nagle dostajemy informację zwrotną, że niby tak, ale pominęliśmy jeszcze te i te powiadomienia, które są powiązane z tymi nazwa wyświetlana oraz powinnyśmy to jeszcze przefiltrować po określonym systemie.

I tak w kółko.

Możemy bardzo łatwo dość do sytuacji, że mając wszystko gotowe nie jesteśmy napisać ostatecznego zapytania o pobranie danych. Szukamy opisu jak dane są skonstruowane, szukamy informacji co to są powiadomienia i jak to ugryźć. Nagle task, który miał nam zająć 3h zajmuje 2 dni. Specyfikacja nie jest pomocna, a osoba która tworzyła ten model też zbytnio nie rozumie słownictwa użytego w dokumencie. Zaczynają się robić problemy, ktoś coś gdzieś powie, ktoś coś gdzieś dopiszę – jednak źródłowy dokument nie jest aktualizowany.

Dochodzimy do sytuacji kryzysowej. Piszemy zapytanie mając nadzieję, że jest dobre. Jak nie to zostanie to wykryte przy testach – albo powinno zostać.

Znając jednak życie te nasze problemy nigdy nie wyjdą w trakcie testów, nasze zapytanie trafi na produkcję, potem ktoś nieśmiało zwróci nam uwagę, że chyba jest coś nie tak, Twoje zapytanie zwraca zły wynik, zgodnie ze specyfikacją miało zwracać X a zwraca Y. Ty zaczynasz tłumaczyć co i jak i się dowiadujesz, że w ogóle nie po tej encji robisz zapytanie, albo nie po tym statusie i że powinieneś to jeszcze ograniczyć po określonej widoczności – prywatne, publiczne itp.

Po 3 miesiącach dowiadujesz się, żę zmarnowałeś 3-4 dni pracy na coś co mogłeś zrobić w 30 minut znając wszystkie niezbędne dane, albo mając dobrą specyfikację.

Ile razy mieliście taką sytuację? Ile razy spędzaliście niezliczoną liczbę godzin próbując zrozumieć co autor specyfikacji miał na myśli?

Ja takich sytuacji miałem wiele i za każdym razem pluje sobie w twarz mówiąc jak tego mogłem nie przewidzieć. A jednak, niektórych sytuacji nie da się przewidzieć. Czyta się dokument, wygląda sensownie, są dane co i jak wyświetlić, następnie się do tego siada, i z każdej strony uderza nas to, że coś jednak było niedoprecyzowane. Nagle się okazuje, że status zgłoszenia Otwarte ma także wartości Zapisane, Skończone, Wgrane które powinieneś uwzględnić jako otwarte zaś Analizowane i Zakończone jako zamknięte. Albo ktoś Cię informuje po X dniach, że dodał kolejny status zgodnie specyfikacją jego części kawałka softu. Sytuacje są różne. Dlatego dobra specyfikacja to podstawa.

A tak jak wspomniałem wcześniej, jej postać może być różna. W jednym z projektów był to jedynie zbiór screenshotów prezentujący co ma zostać zaprezentowane (wraz z wymaganymi polami) oraz kontakt do osoby, jakby były problemy z zapytaniami typu po jakich encjach i jakich wartościach.

W innym był to dokument ze screenshotami, z dokładnym opisem skąd dane mają być pobrane i jakiego typu filtry zastosowane.

W jeszcze innym były tylko screeny plus informacja, że model danych jest zależy od nas developerów.

Zaś co do metodyki zarządzania projektem – jeżeli specyfikacja jest nie pełna, ogólnikowa to nawet poruszanie problemów na kolejnych spotkaniach nie rozwiąże problemu. Jedynie zakolejkuje go. To czy zostanie on rozwiązany, czy nie zależy od ludzi, typu projektu oraz dostępu do osób posiadających wiedzę z danego tematu.

Można pisać/mówić że istnieją metodyki które nas przed tym uchronią – to nie prawda, zmniejszą one liczbę problemów jednak nie uchronią przed wszystkim.

Czasami sami możemy się wybronić gdy specyfikacja jest nie pełna/nie dokłada lub po zgodzeniu się na pewne rzeczy, okazuje się, że coś innego trzeba oprogramować. Jednak nie zawsze istnieje taka możliwość, albo nie zawsze kiedy mówimy, że coś zrobimy posiadamy pełną wiedzę. Problemy wychodzą w trakcie implementacji, w trakcie testów, w trakcie zabierania się za robotę. Nie jesteśmy wstanie wszystkiego przewidzieć. Niektóre rzeczy rozumiemy i jest dla nas jasne jak to czytamy, następnie problem występuje gdy stykamy się z rzeczywistością – ciężko jest sprawdzić jak wyglądają encję na których mamy pracować bez napisania kodu który pobiera dane. Ciężko też jest od razu sprawdzić wszystkie możliwości. Nie ma sensu przed wzięciem projektu lub zadania, sprawdzać wszystkie możliwe opcje, to by zabierało za dużo czasu i energii.

Nie mówię tutaj o prototypowaniu, to inna sprawa. Niektórzy mają na to czas i możliwości inni nie. To na pewno pomaga, ale prototypowanie służy także temu by sprawdzić czy coś jest możliwe, zaś kiedy już są podjęte decyzje co do tego jak UI ma wyglądać (z małymi modyfikacjami w trakcie pracy), czy też, że korzystamy z danego źródła danych z którego korzystają inne projekty, prototypowanie nie sprawdzi się na tyle na ile w kwestiach weryfikacji idei.

Dlatego, miejcie to na uwagę kiedy będziecie brać kolejny projekt na wasze barki, analizujcie dokładnie to co jest napisane, upewnijcie się, że w razie co macie do kogo się zgłosić by zdobyć konkretną wiedzę. Nie wychwycicie wszystkich – oj nie, to by było zbyt piękne, jednak może znaleźć na przykład problemy z brakiem słownika. U mnie w jednym z projektów Akcja, byłą wykorzystywana w 4 różnych znaczeniach, i nawet rozmowa i próba uzyskania odpowiedzi nie była łatwa bo osoba pisząca specyfikację sama gubiła się w tych znaczeniach – a to bez podpytywania się ciężko jest wykryć.

Zaś jak wy jesteście odpowiedzialni za pisanie specyfikacji… sami wiecie jako programiści czego potrzebujecie, jakich konkretnych informacji. Co jest niezbędne by wykonać daną funkcjonalność/task. Skoro wiecie, nie idźcie na skróty – chyba, że sami piszecie dla siebie spec ;) Poświęćcie czas na to by napisać specyfikację tak by była zrozumiała dla was, biznesu jak i developerów. Jeżeli zaś preferujecie minimalizm, to upewnijcie się, że przynajmniej macie osoby do których dev mogą się zgłosić w razie problemu – możecie to być wy lub ktoś inny. Nie ważne, ważne by programista nie zależnie czy senior/junior/normal/czy ktokolwiek wie kto z pytaniem odnośnie wymagań/specyfikacji miał się do kogo złość i uzyskać odpowiedź.

Na koniec, ja tutaj odróżniam między słowami dev, który potrafi napisać zapytanie/kod od takiego który nie potrafi. To są inne kwestie – i zawsze będą. Całość oparłem na jednym prosty założeniu – my, wiemy jak coś napisać – to nie jest problem w tym, że się uczymy i nie potrfimi czegoś zrobić. Znów to jest inne kwestia.

Dla przykładu:

Wymaganie: wyświetlić wszystkie newsy w systemie, które mają flagę ustawioną na opublikowaną:

Select x, y, z from News where flag == 10

To co autor spec miał na myśli: wyświetl wszystkie artykuły, które są powiązane z produktem i mają typ ustawiony na News zaś flaga (W trakcie akceptacji, Zaakceptowane, Opublikowane) oznacza Opublikowane.

Do tego sami nie dojdziecie – oj nie :) nie ma szans, do póki nie zagłębicie się w bebechy bazy danych i nie zorientujecie się, iż News to tak naprawdę Blog Post (nazwa wyświetlana), a News to tak naprawdę status.

I nie jest to tylko problem tak przyziemny jak bazy danych, weźcie na przykład wymaganie typu Jako użytkownik, chcę mieć możliwość wyłączenia wszystkich funkcji social network tak by mi się one nie wyświetlały na stronie. Proste prawda? Nie, bo pod social network kryje się: wiadomości prywatne z forum, mój email, mój folder z plikami itp.

Różnica pomiędzy dwoma wymaganiami jest taka, że w drugim można za pomocą kilku pytań dojść do tego o co chodziło w wymaganiu (tylko pytanie po co marnować na to czas, jak wymaganie powinno być już jasne!), w pierwszym nie dojdziemy do porozumienia do póki nie znamy dokładnie modelu danych, i słownictwa użytego zarówno w nazewnictwu encji jak i w ich nazwach wyświetlanych.

Podsumowanie

Nie wiem czy udało mi się przekazać to co naprawdę chciałem i czy to co przekazałem jest zrozumiałe :) Mam nadzieję, że tak ;)

Czy wy macie podobne spostrzeżenia? Czy natrafiliście na podobne problemy? Jak sobie w takich sytuacjach radziliście?

PS.: komentarze są dużo bardziej wartościowe niż sam blog post, więc zachęcam do komentowania :)