Zanim przejdziemy do tematu analizy i projektowania obiektowego (czyli wtedy, gdy większość z nas czerpie najwięcej radości z tego, co robimy poza samym pisaniem kodu), ważne jest, aby prześledzić kilka innych kwestii dotyczących zrozumienia wymagań klienta .
W poprzednim poście wspomniałem:
Jeśli poświęcisz trochę czasu, aby zrozumieć, czego chcą od samego początku, wymagania nie muszą być 50-stronicowym dokumentem opisującym, jak każdy pojedynczy moduł ma działać.
Na przykład za każdym razem, gdy zestawiam wymagania (lub zestawienie pracy), jak zwykle je nazywam, gdy wysyłam je do klientów, rzadko przekraczam dziesięć stron, a często jest to mniej.
I chociaż zdarza się, że jest dłuższy, myślę, że jednym z powodów opracowania krótkiego zestawu wymagań są wstępne dyskusje, aby upewnić się, że Ty i klienci opracowaliście wspólny język, z którym możecie pracować.
Kiedy to zrobisz, wymagania i zestawienie pracy – jakkolwiek je nazwiesz – nie muszą być tak długie.
Pisanie oświadczenia o pracy
Po pierwsze, chciałbym rozróżnić między oświadczeniem pracy a wymaganiami w kontekście tego postu.
- Wymagania są tym, co klient chce zbudować.
- Zestawienie pracy wyszczególnia, co zamierzasz robić, jak będziesz robić i za ile.
Te ostatnie omówię bardziej szczegółowo w tym poście. Wystarczy jednak powiedzieć, że wymagania mogą mieć formę dyskusji, dokumentacji lub obu tych elementów, jeśli chodzi o klienta.
Zanim przejdziemy do różnych części tego, co zawieram w zestawieniu pracy, jest kilka rzeczy, o których myślę, że warto wspomnieć:
- Nie pisz zestawienia prac, dopóki nie uzyskasz wszystkich wymagań od klienta.
- Upewnij się, że klient wie, czego może oczekiwać od zestawienia pracy.
- Jeśli masz zamiar poświęcić czas na napisanie zestawienia prac, zdecyduj, czy będziesz pobierać opłatę za czas, czy nie, i upewnij się, że klient jest świadomy, że będzie musiał za to zapłacić, czy nie
To jedna z tych rzeczy, które są wykonywane na zasadzie freelancer po freelancerze lub agencja po agencji. Mając to na uwadze, oto części zestawienia pracy, które zwykle dołączam.
Przygotowanie zestawienia pracy
Ilekroć sporządzam zestawienie pracy, mam szablon, z którego się korzystam. Podam tutaj podział, który obejmuje większość z nich.
Oto jak działa każda sekcja:
1 Zestawienie pracy
Celem tego dokumentu jest [określenie proponowanego rozwiązania dla PROJEKTU].
Wymagania projektu zostały przekazane przez [NAZWA KLIENTA], [ROLA KLIENTA NA NAZWĘ ICH FIRMY]. Warunki umowy są kombinacją warunków uzgodnionych przez [NAZWA KLIENTA] i [TWOJA NAZWA AGENCJI].
2 Przegląd wymagań
Celem tego dokumentu jest [określenie proponowanego rozwiązania dla PROJEKTU].
Wymagania projektu zostały przekazane przez [NAZWA KLIENTA], [ROLA KLIENTA NA NAZWĘ ICH FIRMY]. Warunki umowy są kombinacją warunków uzgodnionych przez [NAZWA KLIENTA] i [TWOJA NAZWA AGENCJI].
3 języki i technologia
Serwer WWW, oprogramowanie, narzędzia i podejście, które zostaną użyte do zbudowania rozwiązania.
4 obsługiwane przeglądarki
Jeśli jest to projekt internetowy, sprawdź obsługiwane przeglądarki, czy będzie dostępna funkcja responsywna i jak będą testowane poprzednie punkty.
5 języków i technologii
Serwer WWW, oprogramowanie, narzędzia i podejście, które zostaną użyte do zbudowania rozwiązania.
6 wymagań projektowych i kamieni milowych
Zazwyczaj najdłuższa sekcja dokumentu. Podsumowuje:
- Wymagania,
- Jak każde wymaganie zostanie zbudowane i dostarczone,
- Wszelkie dodatkowe uwagi, o których klient powinien być świadomy.
7 Proponowana oś czasu
Jest to oparte na kamieniach milowych przedstawionych w poprzedniej sekcji oraz na informacjach zwrotnych od klienta.
8 innych czynników
Różne rzeczy, które zdecydujesz się uwzględnić, takie jak to, co Ty lub Twoja agencja zdecydujecie się wprowadzić do projektu, jak opóźniona informacja zwrotna może wpłynąć na projekt i tak dalej.
9 Szacowany koszt
Obejmuje to całkowity koszt projektu i opcjonalny podział harmonogramu płatności.
Jest niezbędne
Wiem: mówiłem to już wcześniej w poprzednich postach z tej serii. To nie jest najbardziej efektowna część tego, co robimy. Zamiast tego przeskoczylibyśmy od razu do programowania.
Ale skąd wiesz, co zbudować (i zbudować to dobrze), jeśli nie rozwiązaliśmy właściwie problemu, który próbujemy rozwiązać?
I właśnie to daje nam wszystko, co prowadzi do analizy obiektowej i projektowania.
Analiza obiektowa
Teraz, gdy zlikwidowaliśmy papierkową robotę (lub nawet „rzeczy biznesowe", jak niektórzy mogą to nazywać), nadszedł czas, aby rozpocząć pracę nad programowaniem.
Jednak zanim to zrobisz, ważne jest, aby przeanalizować wymagania i określić, które części projektu będą służyć jakiemu celowi. Na przykład:
- Czy potrzebujemy istniejącego oprogramowania?
- Czy musimy napisać jakieś adaptery lub kod warstwy danych?
- Jak zbudujemy warstwę aplikacji i znajdujące się w niej encje?
- A co z front-endem?
I dla wielu właśnie tutaj zaczyna się zabawa. Dlatego też chętnie zacznę o tym rozmawiać. Zaczniemy w następnym poście.