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.

projektowanie o którym piszesz podniosło by cenę aplikacji o (gdybam) 25-30% a przecież ma być tanio, szybko etc by klienta nie stracić

a Ja sądziłem, że porządnie ma być, ehhh :/. Wszyscy tak uważają, żeby robić buble, byle by tylko zarobić?
Po za tym, nie wiem co by tak bardzo podniosło cenę? Poświęcenie paru dni na szczegółowe rozplanowanie aplikacji? Bez przesady...
Jak na aplikację przewidziane są 2 miesiące pracy to poświęcenie 3 dni na szczegółowe rozplanowanie, nie ma szans, żeby podniosło cenę nawet o 10-15 %, a do tego dochodzi, że jest szybciej pisana, więc te 3 dni się zwracają i cena się nie zmienia. Więc podważam Twój argument kayman

porządnie to jest wtedy gdy firma/programista pisze coś dla siebie, lub klient jest świadom pewnych spraw -> często jednak jego świadomość się budzi po 60 poprawce u piątego wykonawcy bo nikt go do tej pory nie uświadomił że jak wszędzie - tanio, szybko i dobrze do kupy się nie lubią

btw. porządnie zaprojektowany interfejs użytkownika kosztuje dużo, projektant interfejsów to jeden z lepiej opłacanych zawodów w it

Często koncepcje się zmieniają w trakcie trwania projektu. Oczywiście za każdym razem jak jest zmiana która znacząco ingeruje w projekt to jest ponownie wyceniana.

Można spotkać też podejście "watefall" czyli mamy ogólny koncept. Dzielimy to na moduły. Najpierw jest dokładne dogadanie 1 części, programiści siadają i piszą to co już jest ustalone, a potem w trakcie uzgadniany jest kolejny etap/moduł.

Dzięki temu na bieżąco mamy świeżą dokumentację i pomysły oraz na bieżąco mamy kod, który jeśli jednak klient stwierdzi że nie o to chodziło łatwo jest zmienić.

Zaznaczam że wszystkie takie operacje są uzgadniane co do czasu, i kosztu.

nie sądzę, że każdy klient chce płacić byle najtaniej i na pewno są klienci z profesjonalnym podejściem, nie każdy musi mieć taką klientele jak Ty kayman,
Po za tym nieświadomość klienta nie przeszkadza w stworzeniu zaplanowanego projektu. Trzeba po prostu wiedzieć co od klienta wyciągnąć, żeby móc dokładnie zaplanować projekt i jak już mówiłem, wcale to się z ceną nie kłóci, bo czas pracy nad projektem, bardziej może się skrócić niż wydłużyć.



Okej zmieniają się czasem koncepcje, ale to jest wymówka, żeby nie planować szczegółów, tylko uprawiać freestyle?



Ciekaw jestem jak taki ogólny concept chciałbyś wycenić i co kiedy nagle okazuje się, że ten concept wymaga o wiele więcej pracy, co wychodzi dopiero w trakcie i po wycenie projektu.

Jest ktoś kto uważa, że jak najdokładniejsza specyfikacja jest potrzebna?

wcale nie wymówka -> https://pl.wikipedia.org/wiki/Programowanie_zwinne

@Omenomn dla tego mówisz klientowi że wg. ogólnej specki wycena to w widełkach XXXX-YYYY, a każde zmiany koncepcyjne podlegają renegocjacji.
To Ty ustalasz czy coś jesteście w stanie zrobić wg. ustalonego budżetu czy nie.

To nie mnie powinno interesować zmiana ceny tylko klienta. To klient klepie wycenę zmian. Jeśli się zgadza to robisz, a jak nie to nie.
Czas? Czas nie gra roli chyba że klient chciał na wczoraj, to wtedy liczy się dużo wyższe wyceny.

Nie rozumecie, okej programowanie zwinne spoko.
Ale zawsze na początku jest koncepcja, którą trzeba wyszczególnić, rozłożyc na czynniki pierwsze.
Ja nie twierdzę, że można aplikacja w sposób totalny przewidzieć od a-z i to zaplanować, bo tak nie jest.
Twierdzę natomiast, że każdą koncepcję należy rozkładać na czynniki pierwsze i planować, a kiedy ktoś zleca aplikacje to ma wizję jakaś konkretną i tą wizje należy rozłożyć na czynniki pierwsze i ją wykonać i z następną wizją zrobić to samo. Wtedy jest porządek, a aplikacja się nie rozsypie.
Programowanie zwinne bez rozkładania na czynniki pierwsze każdej iteracji sprawi, że oprogramowanie zamieni się w kupę koderskiego gruzu i w końcu runie.

Jest ktoś kto podziela moje zdanie, czy sami freestylowcy od bubli programistycznych?

Sam zacytowałes moją wypowiedź w której miałeś wytłumaczone programowanie zwinne. Tym samym jest to odpowiedź na twoje pytanie z postu.

@Omenomn:
Żyjesz w świecie utopii. Teoria mówi jedno, a praktyka pokazuje co innego. Czas to pieniądz, często nie ma czasu na "tracenie" go na tworzenie dokumentacji i pełnej specyfikacji systemu. W pracy zajmujemy się akurat pojedynczymi modułami, dostajemy konkretną funkcjonalność do wykonania i to robimy. Mimo, że są to mniejsze kroki niż cały projekt od 0 to też nie mamy czasu na przygotowanie się do zadania. Otrzymujemy czasem wręcz szczątkowe informacje i trzeba zacząć robić. W międzyczasie uściśla się wymagania, niektóre wywalające do góry nogami to co już zostało stworzone. Problem jest w określaniu terminów takich prac gdy do końca nie wiesz co i jak trzeba zrobić. Swego czasu kolega otrzymał do oszacowania (cytat!): "Zmiany na widoku użytkowników"... To już było kuriozum


W moim przypadku klientem jest pracodawca więc "robić buble byle zarobić" w tym momencie nie znajduje zastosowania.

Dyskusja schodzi na drogę metodyk programowania, a Ja chciałem pogadać o specyfikacjach.
Uważam, że iteracje są spoko, ale mi chodzi o to, żeby każda iteracja była w sposób ścisły planowana.

Przykładowo można napisać specyfikację w taki sposób w przybliżeniu:
1. Rejestracja użytkownika
2. Logowanie
3. Zarzadzanie kontem
4. Admin
5. Upload zdjęć
6. Zarządzanie kategoriami

Albo rozpisać wszystko na czynniki pierwsze i zaplanować wszystkie urle, inputy, buttony, wyświetlane dane itp.

I to jest ta sama iteracja.
Okej po wdrożeniu tego można to rozwijać, dodawać kolejne iteracje spoko, ale powyższy przykład specyfikacji nie mówi praktycznie nic programiście o projekcie oprócz pokazania ogólnych funkcjonalności i tak na prawdę nie zdradza dokładnie ilości pracy jaką trzeba włożyć w projekt.

A ten temat założyłem właśnie dlatego, że widzę, że tego rodzaju ogólne specyfikacje iteracji są jakimś standardem dla mnie ciężkostrawnym.

Tylko, że na takie przygotowanie się potrzeba czasu, którego często nie ma.

A ja napiszę tak: ciesz się, że w ogóle dostajesz jakieś plan. W mojej praktyce zawodowej spotykam się, zwłaszcza w pracy z systemami ticketowymi, jedynie ze skromną informacją od klienta na zasadzie: chciałbym aby to było zrobione tak i tak. Koniec. O wszystko trzeba podpytać, czasami klienta uświadomić, że rozwiązanie w tej formie jaką on sobie wymyślił nie sprawdzi się w praktyce, albo że można zrobić coś zupełnie inaczej, znacznie lepiej. Często przypomina to niedokończoną książkę, z której, pomimo materialnego braku kartek i okładki trzeba zrozumieć główny wątek, motywy bohaterów i napisać jej streszczenie. Bez sporej dozy zdrowej wyobraźni ani rusz. W idealnym świecie, programista bez otrzymania konkretnej dokumentacji technicznej planowanego projektu tj. diagramów pakietów, klas, erd, sekwencji itd. w ogóle nie powinien zabierać się do pracy. Niestety rzeczywistość wygląda zupełnie inaczej. Czasami przypomina to walkę z klientem o każdy strzęp, niemal ochłap informacji na temat planowanej modyfikacji. Jaki z tego wniosek? Zdobywanie wiedzy o wdrożeniu jest częścią naszej pracy. Odpowiednie zadawanie pytań klientowi/PMowi, logiczne wnioskowanie, budowanie pełnego obrazu na podstawie fragmentów bazując jedynie na doświadczeniu i wiedzy jest tak samo częścią naszego warsztatu jak znajomość podstaw języka programowania, w którym pracujemy, albo podstaw frameworka na którym budujemy aplikacje.

no i dla mnie to jest właśnie programistyczna tragedia.

Ps. nie mówię o dokumentacji.



Ja nie mówię o współpracy z klientem bezpośrednim, trudno wymagać od klienta bezpośredniego specyfikacji heheh.
Mówię o podejściu głównych programistów i menadżerów projektów do tego.

tak po za tym, jak się robi marne oprogramowanie, to nie dziwota, że trzeba spinać się i pisać szybko, bo się dostaje marne pieniądze.

Nigdzie nie napisałem o bezpośredniej pracy z klientem, bo system ticketowy jednak nie jest taką formą współpracy. Ja też mam PMa nad sobą i wiem, co piszę. Spinać się nie trzeba, bo jak to ująłeś tu chodzi o specyfikę biznesu. W projektach do pewnej skali nikt nikomu nie zapłaci za zaplanowanie aplikacji, a za jej konkretne wykonanie. Tutaj liczy się czas, bo jak wiadomo - to pieniądz. Tylko tyle, albo aż tyle. Btw. projekty z marną dokumentacją albo jej brakiem wcale nie muszą być marne ani słabo płatne. Nie generalizujmy.

// edit
Jeszcze w temacie dokumentacji: możesz tworzyć kilka miesięcy nawet najlepszą dokumentację na świecie, papier przyjmie wszystko, w założeniach wszystko powinno działać i ze sobą współgrać, niestety w praktyce też tak nie jest i dopiero pewne rzeczy wychodzą w praniu, wiele osób wie o tym, dlatego często dokumentacja powstaje jednocześnie z kodem. Dla mnie dobrą dokumentacją w projektach w php jest ... phpDoc plus ewentualnie jakiś komentarz, w jakim celu dana metoda powstała. Nic więcej nie jest mi potrzebne, oprócz informacji na temat tego, w jaki sposób coś ma działać. A jak ja już to zrobię to praktycznie nikogo nie interesuje, byleby działało dobrze. Co nie oznacza, że tworzymy kod marnej jakości, niewydajny itd.

powtarzam, że nie mówię o dokumentacji, ona jest dla mnie nie istotna.
Mówię o specyfikacji, czyli o tym co programista ma do wykonania, nie co już wykonał.



To dobry ten PM, skoro musisz go uświadamiać o tym, że coś się nie sprawdzi.

Fakt, nie zauważyłem, że totalnie pominęliśmy w rozmowie kwestię dokumentacji technicznej. Mój błąd. Pomińmy więc ten temat.

Specyfikacja wymagań powstaje jako jeden z pierwszych dokumentów projektowych na etapie podpisywania papierów, choć różnie to bywa w różnych firmach. Często ustalenie jej kształtu odbywa się na zasadzie negocjacji z klientem, tzn. najpierw zbiera się wymagania ogólne, następnie w porozumieniu z analitykami lub/i team leaderami dobiera odpowiednie narzędzia, planuje prace i odsyła się taki dokument klientowi do akceptacji. Klient nanosi swoje uwagi i czynność powtarza się do uzyskania akceptacji. Na tym etapie, pisząc o wdrożeniu od zera, robimy często wycenę poszczególnych elementów najczęściej sklepu internetowego, mamy rozpisanych większość czynności do wdrożenia, ale jeszcze bez konkretów, tj. często pracuje się bez makiet, z częściowym projektem graficznym lub bez itd.. Celem tego jest akceptacja wyceny czasowej prac, a zatem na jej podstawie zaplanowanie czynności do wykonania i uzyskanie wstępnej informacji o kosztach. Po akceptacji wyceny jest etap wdrożenia. Jeśli jest już wyznaczony zespół który będzie pracował nad projektem i wiadomo ile to powinno potrwać, następuje rozdzielenie zadań. Dopiero w tym momencie powstają konkretne zadania w systemie ticketowym na podstawie których można implementować. Najczęściej sporządza je klient lub ktoś z nim skomunikowany np. product owner, opisując słownie to, co należy konkretnie wdrożyć wg jego wizji. Powstają z tego user stories z mniej lub bardziej konkretnymi wymaganiami. Jeśli coś jest niejasne, to uruchamiamy serię pytań i czekamy na odpowiedzi. Ale i tutaj nie dysponujemy żadnymi diagramami, jest jedynie opis słowny, czasami jakieś screeny. Wszystko było by fajnie gdyby to jakoś ujednolicić, np. nakłonić ownera do korzystania z narzędzi BPMN, żeby wymodelował procesy biznesowe po swojej stronie i żeby było widać, jak na co dzień ludzie w jego firmie będą korzystać z systemu, który dopiero powstaje.

//edit
Do specyfikacji wymagań należałoby też dodać wymagania niefunkcjonalne, które pominęliśmy, czyli np.
- konieczność skonfigurowania certyfikatu SSL
- obowiązek wdrożenia zabezpieczeń aplikacji na konkretnym poziomie
- wymagania sprzętowe
- wymóg zamieszczenia informacji o ciasteczkach i ochronie danych osobowych, akceptacji regulaminu itd.
- konieczność testowania oprogramowania
- dostosowania treści regulaminów do prawodawstwa określonego kraju etc.

Powiem tak:
Jak aplikacja może być przemyślana, kiedy nie jest przemyślana?

Ale to dobrze Darko, że jakoś jednak planujecie projekty, chociaż Wy

Pisząc wprost: najczęściej najwięcej wie ten, kto będzie na tym robił pieniądze. Jeśli ktoś to przemyślał i wykłada na to pieniądze, to powinien wiedzieć, co robi i najczęściej wie. Czasami trzeba spojrzeć z drugiej strony.

// to, co wydaje się nieprzemyślane z Twojej strony niekoniecznie musi faktycznie takie być od strony kogoś, kto za to płaci.

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.

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

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.

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".

Jako zwykły Kowalski podam ci przykład rozmowy



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

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

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

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 @$#@@!

po czym



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

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.

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

@Omenomn

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

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?

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

Czyli zaplanujesz wszystkie fanaberie klienta?

@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.

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ć

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