Analiza biznesowa / Zespół radzi Analitykowi

Twórzmy na konkretach cz.1

Luty 1, 2016 0
Podziel się:

Projekty prowadzone są w przeróżny sposób. Brałem udział w projektach, które nie miały dokumentacji, była ona szczątkowa (ale była) oraz takich z dobrze prowadzoną. Jak pracowało mi się przy tych projektach? Różnie. Po części miała na to wpływ istniejąca dokumentacja, po części podejście do projektu osób wyższego szczebla oraz sposób, w jaki definiowane są kolejne zmiany.

AKT I

Jednym z pierwszych projektów, w których byłem programistą, była projekt wytworzenia aplikacji na urządzenia mobilne. Tak na prawdę to sama aplikacja miała już trochę lat na karku (bodajże 10) a mój zespół tworzył ostatnią z wachlarza platform mobilnych. Miałem wrażenie, że mało kto nami się interesował ponieważ byliśmy daleko w tyle za innymi a nowe funkcjonalności nadal spływały. Można było pokusić się o stwierdzenie, że była to komfortowa sytuacja. Aplikacja wygrzana, sprawdzone i przetestowane funkcjonalności, nic tylko brać i pisać. Otóż nie. Problemem była właśnie dokumentacja. Musiała istnieć, być gdzieś ukryta, zakopana głęboko w czeluściach czyichś komputerów/serwerów.

Jak zatem wyglądała nasza praca, gdy dokumentacji brak, ponieważ team leader/platform leader jej nie przekazał z jemu tylko wiadomych powodów? Inne platformy są na “produkcji”, tak? Użytkownicy na nich szaleją, a poważnych błędów już na nich nie ma, tak? “Kod jest najlepszą dokumentacją”, tak? W pewnym stopniu sprawdzało się to podejście i odnieśliśmy sukces. Gdy mieliśmy podstawowe funkcjonalności, aplikacja została wypuszczona w świat i sprzedaje się.

AKT II

Kolejny przypadek, który chcę przytoczyć, jest już trochę inny. Głównie ze względu na to, że nie jest to własny produkt tylko projekt klienta zewnętrznego. Tak jak wcześniej w momencie mojego dołączenia do projektu aplikacja była na produkcji. Być może plusem, być może minusem jest fakt, że ten projekt posiada tylko jeden interfejs, webowy.

Problemem, jaki tutaj chcę przedstawić, jest sposób spływania “rzeczy do zrobienia”. Nie zmieniają one zasadniczo samej aplikacji, ponieważ są to zmiany wizualne. UX-designer zbudował parę ekranów, do których mamy się dostosować. więc teoretycznie nic wielkiego. Otóż nie do końca, ponieważ poza samymi ekranami w wymaganiach nie ma nic więcej oprócz krótkich stwierdzeń  typu “Dostosowanie części strony”, etc. Jest dobrze, o ile zmiany dotyczą widoków, w których nie ma edycji. Pytanie co w sytuacji, gdy na stronie pojawia lista obiektów, które można na niej edytować. Domyślam się, że zapisywanie ma być automatyczne. Tylko co z walidacją takich obiektów? Co z faktem, że nagle ilość edytowanych pól drastycznie spada? Tak, wiem, trzeba “dostosować”. Tylko co autor miał na myśli?

Jest jeszcze kilka aktów tej sztuki, ale szczegóły w kolejnym poście 🙂

Oceń ten post
Jacek Nakonieczny
Autor: Jacek Nakonieczny
Programista Salesforce oraz Ruby on Rails odpowiedzialny za implementację dedykowanych systemów klasy CRM czy SFA/FFM. W wolnym czasie odwiedza konwenty fantastyki, robi zdjęcia, jeździ rowerem oraz lata quadcopterem. Pomagał przy organizacji Lubelskich Dni Informatyki w latach 2012-2014, a obecnie udziela się w lokalnej społeczności Makerspace/Hackerespace.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz