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.

[athabus]

Ten fragment odnosił się do tego, że programista ma wiedzieć co się np. znajduje w szablonie Allegro (swoją drogą szablonów Allegro nie robią programiści) - moim zdanie nie musi tego wiedzieć, tak samo jak nie musi wiedzieć co i jak ma funkcjonować w sklepie. Zrzucanie takich rzeczy na programistów to jest porażka, bo skąd biedak ma się znać na handlu w internecie, ux, marketingu itp? W życiu bym takich rzeczy nie oczekiwał od programisty - oczywiście może się zdarzyć, że widział podobne rozwiązania i coś doradzi z dobrego serca, ale to nie jest jego zakres obowiązków i co ważniejsze klient musi sobie zdawać sprawę, że taka rada nie musi być dobra. Ja akurat ogarniam programowanie i jest to nagminne, że PM próbują mi wcisnąć jakieś rozwiązanie pod płaszczykiem "tak będzie lepiej", gdy tak na prawdę chodzi im tylko o to aby zmniejszyć czasochłonność zadania, którego podjęli się wykonać w określonej stawce.
To klient ma wiedzieć czego oczekuje, a programista może jedynie doradzić/odradzić pewne rozwiązanie ze względów technicznych. Wszystko ponad to jest miłym bonusem.

Drugi fragment właśnie odnosi się do kwestii technicznych. Np. programista mówi, ta funkcjonalność to 50h pracy - proszę się zastanowić, czy jest ona kluczowa czy nie - albo doradzi jak można to zrobić w podobny sposób ale w 5h zamiast 50h - takich porad jak najbardziej programista powinien udzielić, bo sami jako programiści wiecie, że czasami z pozoru prosta sprawa wymaga sporego refactoringu kodu i jest bardzo czasochłonna. Tutaj jest właśnie pole do doradztwa technicznego, gdzie czasami klienta trzeba uświadomić co do opcji aby mógł podjąć świadomą decyzję.

Natomiast fakt jest, że od firm wdrażających np. platformy sklepowe na rynku "niekorporacyjnym" (zazwyczaj 1-3, gdzie umówmy się często pracują raczej ci słabsi programiści) klienci oczekują, że oni rzucą hasło "proszę mi zrobić sklep" i firma zrobi im sklep. Potem kończy się to tak, że jak przegląda się portfolio takiej firmy to oczy bolą, bo sklepy najczęściej są skrajnie nieużyteczne i nie spełniają podstawowych zasad zwiększających współczynnik konwersji, są "anty-seo" itp.
Taki standardowy przykład - wszystkim wydaje się, ze sklep musi być piękny i wciskają na maksa ozdobników nie mówiąc już o wszechobecnych widgetach JS, które sprawiają, że sklep ciągle rozprasza bo coś się porusza/powiększa itp. A praktyka pokazuje, że o wiele lepiej sprawdzają się sklepy schludne ale o prostym interfejsie. Sklep ma nie straszyć wyglądem, być maksymalnie intuicyjny i budzić zaufanie. Wiedzą to główni gracze na rynku - wystarczy porównać to co wdrażają przeciętnie firmy od Magento i Presty z sklepami, które "sprzedają".
Po prostu chodzi mi tutaj o pomieszanie z poplątaniem pewnych ról na etapie projektu. Ja to obserwuję w ecommerce - pewnie jak ktoś się zna na innej działce to podobne rzeczy wychodzą w np. systemach erp, księgowych czy nawet prostych aplikacjach użytkowych.

Inaczej ma się sprawa, gdy udajemy się do agencji, która twierdzi, że ogarnia temat od a do z, czyli nie tylko zajmuje się programowaniem, ale całym etapem koncepcyjnym. Tu już klient płaci za cały cykl rozwoju produktu, a nie tylko programowanie. Wtedy oczywiście specyfikacja, rozrysowanie ekranów, ścieżek itp jest jak najbardziej na miejscu.

Jak ja zlecam projekt komuś na zewnątrz to we własnym, dobrze pojętym interesie dostarczam:
- makiety
- specyfikację opisową, jakich funkcji oczekuję
- jako, że jestem trochę techniczny, to dodatkowo często opisuję jak coś ma być zrobione (technologie, jakieś wytyczne specyficzne dla danego typu oprogramowania itp).
- jeśli chodzi o wdrożenie jakiegoś OS to dodatkowo wcześniej się z nim zapoznaję, żeby wiedzieć co jest tam w standardzie a co trzeba dorobić, bo tu często pojawiają się nieporozumienia.

Takie rzeczy ratują tyłek, bo dzisiaj firmy najpierw biorą zlecenie i je wyceniają, a potem dopiero czytają specyfikację. Ok ich sprawa, ale potem współpraca wygląda tak, że co chwila trzeba pokazywać palcem, czego w specyfikacji nie przeczytali.

Ten post edytował athabus 31.01.2016, 14:02:34