Jak napisać projekt?, Planowanie, specyfikacja Opcje

[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

[!*!]

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.

Oczywiście, do momentu pierwszej poprawki i faktury za prace serwisowe. Ehhh widzę koledzy indywidualiści z wizją pięknego kodu...

[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

[Dejmien_85]

Noo, w końcu jakiś ciekawy temat z przemyśleniami, ha!

A teraz tak serio - problem jest w tym, że klient sam nie wie czego chce, klient nie ma pojęcia o "technikaliach", ani z pewnością nie ma żadnych grafik, z tego też powodu manager/analityk biznesowy nie przedstawi Ci od razu gotowego projektu do implementacji.

Kiedyś próbowano to robić, do klienta jechał zespół, który spędzał masę godzin, aby wszystko rozpisać szczegółowo, gdy po dziesiątkach godzin wszyscy przygotowali w końcu obszerną dokumentację, wtedy analitycy wracali z kupą dokumentów i zaczęto wdrażanie projektu.

Po X miesiącach projekt był gotowy, wszyscy stali z wysoko podniesionymi czołami, zaprosili klienta na demo i... katastrofa! Klient ciągle coś mruczał, że "nie tak miało być", że mu się nie podoba. Menadżerowie przedstawiali klientowi dokumenty, podpisane przez niego, mówili: "No przecież tak się umawialiśmy!". I później i tak trzeba było wszystko przerabiać.

Teraz jest "Agile", teraz już nie robi się super obszernych dokumentacji, opisujących cały projekt. W tej chwili projekt robi się po kawałeczku. Z tygodnia na tydzień omawia się nowe funkcjonalności, rozmowy z klientem są na bieżąco wraz z postępem nad projektem. Klient także co tydzień/dwa widzi demo nowych funkcjonalności, a to wszystko przez to, aby w razie czego szybko wyłapać rzeczy, które się źle zrozumiało, albo czego klient dobrze nie przedstawił.

Moim zdaniem klienci są bardzo dobrzy w złym opisywaniem tego czego chcą, posiadają także bardzo krótką pamięć i szósty zmysł do proponowania zmian, które totalnie rozpiżdżają aktualnie zrobione funkcjonalności (tj. wymagają wprowadzania dość dużych zmian, które wymagają konkretnego refactoringu kodu).

Także kolego, moim zdaniem próba przygotowania "wspaniałej dokumentacji", która wszystko opisze i wyjaśni to jak najbardziej Utopia. Klient coś powie, Analityk to inaczej zrozumie, kierownik projektu to przekręci, programista zrozumie po swojemu i później powstanie takie dzieło, że klient się będzie zastanawiał czy go w ogóle ktokolwiek rozumie. : >

Częste iteracje oraz częsty kontakt z klientem to dobra praktyka. Nic nie bierzmy "for granted".

[ZenekN]

Jako zwykły Kowalski podam ci przykład rozmowy

ja: ile kosztuje zrobienie szablonu na allegro ?
ktoś: Co ma sie tam znajdować?

moim zdaniem tutaj jest błąd ponieważ wiadomo co znajduje się na takim szablonie allegro
menu, parametry techniczne, zdjęcia i belka z lewej, ktoś kto pyta co ma się znajdować a jest od tego żeby to zrobić to lepiej niech się nie bierze do pracy,
to ty masz wiedzieć co tam ma się znajdować i nie zadawać takich pytań.

Moim zdaniem odbiorcę trzeba uświadomić że ten projekt ma właśnie tak wyglądać a nie inaczej bo ty jesteś w tym temacie zorientowany.

Takie jest moje zdanie

Ten post edytował ZenekN 30.01.2016, 12:55:00

[Pyton_000]

Taaa... Minąłeś się z powołaniem. To klient określa co ma być a nie "wiadomo co jest".

[ZenekN]

Ok ok trochę pojechałem ale moim zdaniem krokiem do udanego projektu to mocno wyrazne schematy/szablony widac to wyraznie w wiekszych serwisach typu allegro

[athabus]

Usmialem sie czytajac ten watek. Prowadze dzialalnosc w ecommerce. Jakbym sluchal porad programistow to... juz bym nie robil w ecommerce . Programista ma sie znac na programowaniu, spec od ux ma sie znac na ux itd, a klient musi sobie to wszystko ogarnac np. zatrudniajac ludzi albo sam sie znajac. Ja od programisty oczekuje, ze zrobi przyzwoicie co do niego nalezy i ewentualnie doradzi cos w kwestiach typu "jak bysmy to zrobili tak to bedzie lepiej/20% taniej itp".
Co do specyfikacji, to nie da sie na poczatku stworzyc dokladnej specki wszystkiego, bo zawsze cos sie urodzi po drodze i trzeba znalezc balans miedzy szczegolowoscia a elastycznoscia. Inna sprawa, ze PM czesto nie ogarniaja co sie do nich pisze w briefie/wstepnej specyfikacji potrzeb i potem sie robia dziwne problemy. Teraz np. mam takie wdrozenie, ze srednio raz w tygodniu musze udowadniac PM, ze cos bylo w specyfikacji i cytowac mu fragment... porazka jak dla mnie i juz widze jak sie musza programisci @$#@@!

[kayman]

Jakbym sluchal porad programistow to... juz bym nie robil w ecommerce

po czym

Ja od programisty oczekuje, ze zrobi przyzwoicie co do niego nalezy i ewentualnie doradzi cos w kwestiach typu "jak bysmy to zrobili tak to bedzie lepiej/20% taniej itp".

to w końcu ich słuchasz nie słuchasz

[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

[Omenomn]

Inna sprawa, ze PM czesto nie ogarniaja co sie do nich pisze w briefie/wstepnej specyfikacji potrzeb i potem sie robia dziwne problemy. Teraz np. mam takie wdrozenie, ze srednio raz w tygodniu musze udowadniac PM, ze cos bylo w specyfikacji i cytowac mu fragment... porazka jak dla mnie i juz widze jak sie musza programisci @$#@@! smile.gif

To Ja jestem bardzo ciekaw jak ten brief jest napisany.
Pewnie dlatego właśnie, że jest zbyt ogólnie nie wiadomo co trzeba zrobić.

Pracowałem nad projektem, który gdyby był dobrze zaplanowany, byłby napisany 2 razy szybciej, bo poprawki wynikają z tego, że programista nie wie do końca jak ma wyglądać dana funkcjonalność pisze tak jak mu się wydaje, a później trzeba poprawiać 5 razy, bo za każdym razem jest coś nie tak, a wystarczyłoby siąść uzgodnić dokładnie co jak ma się zachowywać i dlaczego i problem z głowy.

Tylko jak się nie ma bezpośredniego kontaktu z klientem, a kogoś nad sobą, to ten ktoś mówi 5 razy, że tak będzie okej, a później 5 razy trzeba zmieniać.

Robiłem cmsa, przy którym za nim cokolwiek zacząłem robić rozpisałem wszystko co można mega dokładnie. Klient to dostał i wszystko dokładnie wiedział co będzie miał. Zrealizowałem projekt i praktycznie zeeero poprawek. Można? Można.

Tylko jak się woli babrać, niż porządnie efektwnie pracować to później tak jest, że prace się przeciagają, a apka jest średnia.

Widzę, że nikt mojego zdania nie podziela, ostra akcja

Ten post edytował Omenomn 4.02.2016, 18:28:41

[mrc]

@Omenomn

Dlatego wymyślono zwinne metodyki wytwarzania oprogramowania. Klient widzi, co się buduje, i jeżeli coś jest nie tak, to wiesz od razu.

[Omenomn]

Spoko, jak zaplanujesz całą apkę, to przecież też można pokazywać etapy klientowi, nie widzę przeszkód.

[ohm]

Spoko, jak zaplanujesz całą apkę, to przecież też można pokazywać etapy klientowi, nie widzę przeszkód.

A co jak klient powie ze jednak część X po 2 tygodniach trzeba zmienić? Poświęcisz pół dnia na przepisywanie dokumentacji?

[Omenomn]

po to się dokładnie planuje, żeby nie było bezsensownych zmian

[ohm]

po to się dokładnie planuje, żeby nie było bezsensownych zmian

Czyli zaplanujesz wszystkie fanaberie klienta?

[mrc]

@Omenomn

Klient tutaj jest najważniejszy. Jeżeli coś z nim rozplanujesz, to on prześpi się przez noc z tym i rano powie Ci, "Mam lepszy pomysl". Jak nie przystaniesz na to o co klient prosi, to go stracisz. Niestety na niekorzyść Twoją zadziała fakt, że to jest najczęstsze zachowanie klienta.

[kayman]

po to się dokładnie planuje, żeby nie było bezsensownych zmian

imo firmy w ten sposób myślące wypadły już z rynku, reszta robi pod klienta, bo jeżeli klienta ma odpowiednią kasę to i niech ma fanaberie jakie chce, a jak nie ma są darmowe/niskobudżetowe rozwiązania i dostanie na ile go stać

[miang]

z mojego doświadczenia: nie pisze sie dokładanego projektu bo osoby zatrudnione jako projektanci nie potrafią tego zrobić i zrzucają swoją pracę na programistów