Jak napisać projekt?, Planowanie, specyfikacja Opcje

[Omenomn]

Cześć, w swojej karierze programisty zauważyłem pewne dość popularne zjawisko, które według mnie nie koniecznie jest dobre, chodzi o sposób zabierania się do tworzenia i planowanie projektów.

Główni programiści lub menadżerowie projektów, tworzą jakieś ogólne opisy funkcjonalności na 2-3 strony w zależności od złożenia projektu i to jest wszystko co dostaję jako wiedzę o projekcie, na której mam bazować ( Jeszcze widoki psd, ale to oddzielna kwestia ).

Zaczynając pracę nad projektem posiłkując się takim dokumentem w momencie kiedy zaczynam tworzyć daną funkcjonalność za każdym razem muszę dopytywać jak dokładnie ma działać i wyglądać, bo jej opis jest zbyt ogólny.
Bardzo często widoki (psd) nie uwzględniają wszystkich potrzebnych funkcjonalności, o których wiadomo jest od początku, lub byłoby wiadomo gdyby bardziej szczegółowo projekt został obmyślony.

Mam wrażenie jakby to był jakiś standard w pracy w zawodzie programisty i, że właśnie tak powinno się pracować.
Jakieś takie spontaniczne tworzenie aplikacji i dokładniejsze planowanie poszczególnych funkcjonalności w trakcie ich tworzenia.
Porównać to można do budowania domu, bez jego projektu, bezwiednego i nieprzemyślanego wcześniej zabierania się za każdy następny etap budowy (nie chciałbym w takim domu mieszkać ).

Nie wiem z czego to wynika, czy to jest kwestia lenistwa menadżerów projektów i głównych programistów, natłoku zadań, podejścia, czy jeszcze czegoś innego.

Według mnie przed w ogóle rozpoczęciem pisania jakiegokolwiek kodu i tworzenia widoków psd, aplikacja powinna być rozpisana tak szczegółowo jak to tylko możliwe, dzięki czemu w czasie trwania prac nie ma zaskoczeń, przestojów, zbędnego zastanawiania się za co następne się brać i jak to wykonać, bo wszystko jest rozpisane, a pracę idą płynniej, efektywniej, sam kod może być bardziej uporządkowany i przemyślany.

Uważam, że porządna specyfikacja zawiera w sobie takie elementy jak:
- wypisane wszystkie podstrony ( wszystkie adresy url)
- wszystkie formularze odpowiedzialne za wprowadzanie i edycję danych w poszczególnych funkcjonalnościach wraz z wszystkimi polami, walidacją i przyciskami
- wszystkie dane na poszczególnych podstronach jakie mają zostać wyświetlone ( index rekordów, show rekordu w zależności czy mają istnieć)
- wszystkie formularze odpowiedzialne za usuwanie danych, pojedyncze lub mnogie, lub takie i takie
- najlepiej wszystkie akcje, które użytkownik może wykonać tj. get, post itp.
- studium przypadku poszczególnych akcji, żeby wychwycić możliwe błędy lub problemy.
- jeśli to mozliwe to zaplanowanie bazy danych ze wszystkimi polami, kluczami i referencjami

Chciałbym poznać Wasze zdanie na ten temat i dowiedzieć się ilu jest ludzi, którzy w jakimś stopniu podzielają moje zdanie. Może dodalibyście coś do tej listy?

Sądzę, że żeby napisać optymalną i efektywnie funkcjonującą aplikację, szczegółowe jej obmyślenie jest nieodzowne.
Detale uważam za całkowicie istotne, bo to one zbierają się na całokształt.
Wątpię, żeby google lub inne marki w dziedzinie aplikacji www, podchodziły w sposób spontaniczny do tworzenia swoich projektów.

[Omenomn]

Jeżeli coś mi się wydaje nieprzemyślane, to zapewne znajdzie się mnóstwo użytkowników, którzy podzielają moje zdanie i zrezygnują z użytkowania nieprzemyślanej i nieoptymalnej aplikacji.

Pisząc wprost: najczęściej najwięcej wie ten, kto będzie na tym robił pieniądze

Ten kto wykłada kasę najczęściej ma ogólną wizję, a My jesteśmy od tego, żeby tą wizję wdrożyć najlepiej jak się da. Takie moje zdanie.

Ten post edytował Omenomn 21.12.2015, 11:13:20

[darko]

Jeżeli coś mi się wydaje nieprzemyślane, to zapewne znajdzie się mnóstwo użytkowników, którzy podzielają moje zdanie i zrezygnują z użytkowania nieprzemyślanej i nieoptymalnej aplikacji.
Ten kto wykłada kasę najczęściej ma ogólną wizję, a My jesteśmy od tego, żeby tą wizję wdrożyć najlepiej jak się da. Takie moje zdanie.

Jeśli zgłasza się do Ciebie człowiek z gotowym projektem graficznym, precyzyjnym opisem wymagań i budżetem na realizację projektu, to rozumiem, że odmówisz pracy dla niego, bo po przeanalizowaniu materiałów, które dostarczył dojdziesz do wniosku, że to wszystko jest nieprzemyślane i zbyt ogólne? Dążę do tego, że w praktyce, to już nie jest Twoje zmartwienie czy coś jest wg Ciebie przemyślane czy nie. Często jest tak, że wszystkiego nie wiemy i nie musimy. Po prostu. Inaczej sytuacja wygląda, jeśli przyjdzie ktoś, kto faktycznie nie wie czego chce, a ma pieniądze i rozumiem, że o takim przypadku pisałeś. Btw. poprawki zdarzają się zawsze i wszędzie, nawet w najlepiej napisanym kodzie i są nieodłącznym elementem pracy programisty. Nie ma w tym nic złego, że trzeba coś poprawić, żeby lepiej działało. A specyfikacja przydaje się też po wdrożeniu produkcyjnym, żeby ktoś mógł po drugiej stronie odebrać wykonane prace i stwierdzić, że wszystko, za co zapłacono, zostało wykonane według specyfikacji.

Ten post edytował darko 21.12.2015, 14:58:41