Jak przedstawiany jest projekt programiście?

Cześć!
Jestem studentem i ciekawi mnie jedna kwestia, ale niestety nie znalazłem w internecie odpowiedzi na moje pytanie. Tak jak w tytule, ale bardziej szczegółowo:
kiedy zostaje wprowadzony projekt np. zrobienia aplikacji (jakiejkolwiek) to co dostaje programista? Chodzi mi o to jakie informacje dostaje?
Tylko o czym aplikacja ma być, czy bardziej szczegółowo - metody, jak ma wyglądać interfejs?
Czy jeśli informacje są ,,skromne'' to czy to znaczy że ma wolną rękę w niektórych kwestiach dot. tego jak ma program wyglądać i co robić?

IgnatiusTender napisał(a):

kiedy zostaje wprowadzony projekt np. zrobienia aplikacji (jakiejkolwiek) to co dostaje programista? Chodzi mi o to jakie informacje dostaje?

Różnie, od zlepka maili z ustaleniami co tam mniej więcej ma być, przez excela z wylistowanymi wymaganiami, po gotowe taski w JIRA do naklepania. Od "A weź zrób żeby było i żeby pokazać klientowi, potem się zrobi jak trzeba" po gotową specyfikację np. jakiś projekt UI, czy wymagania do API etc.

Tylko o czym aplikacja ma być, czy bardziej szczegółowo - metody, jak ma wyglądać interfejs?

Różnie, może być tak, że robisz pod jakąś konkretną specyfikację "co ma robić / jak ma robić", czasem lecisz z prototypem i ustalasz wszystko na bieżąco, masz jakiś feedback loop, a czasem jest tak, że nie możesz nawet nazwać po swojemu jakiegoś licznika w pętli, bo zaraz znajdzie się jakiś pan i władca który zleje Cię za to po d**ie.

Czy jeśli informacje są ,,skromne'' to czy to znaczy że ma wolną rękę w niektórych kwestiach dot. tego jak ma program wyglądać i co robić?

Jak nie masz powiedziane wprost "zrób to po swojemu, nie zależy nam" to lepiej naciskać i dopytywać do skutku, żeby zebrać tyle wymagań, ile się da - bo inaczej możesz dostać po d**ie za samowolkę. Już przerabialiśmy z zespołem takie sytuacje, że pan i władca nie dopowiedział czegoś, kazał tylko zrobić to i to, dostał co chciał, był zadowolony, a po paru miesiącach zlał nas za to samo po d**ie bo sobie przypomniał, że nie podał nam jakichś dodatkowych wymagań - bo oczywiście to my byliśmy winni temu, że ich nie podał.

Najczęściej dowiaduje sie o projekcie na jakimś zebraniu, gdzie ktoś opisuje pomysł i prezentuje jak dzięki projektowi wszyscy staniemy się bogaci, a dzieci w afryce będą jeszcze bardziej głodne. A potem się to rzeźbi - czasem miesiącami, czasem latami.
Mniejsze projekty czasem trafaiają do mnie w formie opisu słownego plus kartki z rysunkiem. Zwykle rysunki są zupełnie nieczytelne, zdania wzajemnie sprzeczne i nie pasujące do opisu słownego, a kartka jest już raz zjedzona i wyrzygana przez psa.
Te drugie projekty lubie - zwykle coś z tego fajnego wychodzi.

Poza tym, co mówili przedmówcy, to dodam, że najczęściej programista dostaje dane fragmentaryczne. Nie na temat całej aplikacji, tylko na temat jego fragmentu, np. jednego okienka dialogowego, które trzeba w danym tygodniu zaklepać.

Z jednej strony wydaje się dobrze (bo można się skupić na jednej rzeczy), jednak na dłuższą metę takie podejście rodzi problemy. Bo jeśli nie wiesz jak będzie wyglądać całość (cała aplikacja albo cały podsystem aplikacji, czy cały "zestaw widoków" - w każdym razie coś większego niż tylko jedno "zadanie") to w zasadzie nie możesz zaplanować sobie pracy w wydajny sposób. Ile razy ja już pisałem coś, bo dostałem garść informacji, a potem okazało się, że "biznes" zachwycił mnie czymś totalnie niespodziewanym, i potem się okazało, że moje założenia były w kontekście większej całości błędne (a można było tego uniknąć po prostu przekazując big picture, zamiast traktować jak robotnika na taśmie, który ma tylko robić swój kawałek roboty i nic wiecej).

Mam wrażenie, że czasem programistów traktuje się jak małe dzieci, nie przekazując im całej informacji na temat wymagań biznesowych czy designu, a jedynie jakieś urwane z całości fragmenty. To utrudnia pracę (jeszcze też kwestia na jakim etapie dołączasz do projektu - jeśli wchodzisz do projektu na początku, to może jest trochę lepiej, niż jak dołączasz do istniejącego projektu i masz za zadanie nauczyć się żonglować 200 piłeczkami ping-pongowymi "dość szybko wdrożyć do projektu" (skreślony tekst dobrze określa, jak takie "szybkie wdrożenie się" zwykle wygląda). Bo wtedy większość zespołu ma już "big picture", wie, z czego wynikały decyzje biznesowe i architektoniczne - a ty możesz jedynie to zgadywać albo pytać się ciągle ludzi.

LukeJL napisał(a):

Mam wrażenie, że czasem programistów traktuje się jak małe dzieci, nie przekazując im całej informacji na temat wymagań biznesowych czy designu, a jedynie jakieś urwane z całości fragmenty.

• urwane fragmenty
• wzajemnie sprzeczne informacje
• informacje okazujące się całkowicie z d**y w konfrontacji z (dość smutną) rzeczywistością
• brak informacji, bo tak naprawdę nikt nie wie jak było/jest/miało być - kończy się poklepaniem programistów po plecach, hasłem "dacie radę, za 2 miesiące release" i zamówieniem zestawu "mały detektyw" dla każdego.
• ukrywanie z premedytacją istotnych dla projektu informacji np. wiesz że jakiś inny system będzie babrał bezpośrednio w Twojej bazie (sic!) ale nie powiedzą Ci jak dokładnie, co może robić i na co musicie przyszykować d**ska "bo nie" (sic! x2)

To utrudnia pracę

Eeee tam wcale nie, przecież to programiści są źli, niedobrzy, niekomunikatywni i celowo robią z igły widły, na złość biznesowi mijają się z estymatami, szczególnie tymi które każdy szczebelek obciął sobie o 10-20% dla podpicowania statystyk i z pół roku zrobiło się 6 tygodni :D

@LukeJL: odnośnie traktowania programistów jak małe dzieci - pamietaj, że każdy kij ma dwa końce, a takie podejście pewnie z czegoś wynika. Znajomy kilka lat temu został szefem IT w polskiej filii Europejskiej firmy z branży około ubezpieczeniowej (nie chce dawać zbyt wielu konkretów).

Przejrzał stosowane rozwiązania i uznał, że część rzeczy trzeba zmienić, między innymi system obsługujący zgłoszenia i koordynujacy pracę ekip w terenie oraz obsługiwanego przez nich sprzętu. Udało mu się przekonać do tego zarząd, co wcale nie było łatwe, bo kwota wcale mała nie była. Przy pomocy swoich informatyków oraz kilku nowych zaczęli pisać nowy system.

Od początku wszyscy wiedzieli, co to za system, jak ma działać, funkcjonalność i wizja całości były regularnie omawiane na spotkaniach, na pewno nie były żadną tajemnicą dostępną jedynie dla wybranych. Zgodnie z tym, co pisałeś wcześniej, wszystko powinno iść jak po maśle, prawda?

Nie pamietam w tej chwili już konkretnie, co tam się działo, wiem że ostatecznie system został zrobiony, ale pamietam za to, jak się kumpel wkurzał na bezmyślność i olewactwo (albo totalny brak świadomości) programistów. Pierwszy przykład który mi przychodzi do głowy - totalny brak walidacji/kontroli wprowadzanych danych. Przykładowo - koleś tworzy okienko do wprowadzania zgłoszenia, trzeba tam podać informacje dotyczące pojazdu. Wiadomo, że w pole "wysokość" (to akurat dotyczyło samochodów) sensowne jest wpisanie wartości między 1 a 4 metry. Ale programista na to nie wpadł,więc można było wpisać cokolwiek: 4658, 0.066 albo "4g7xx". Kolega oceniając postęp prac to zauważył i zapytał, czemu tak to zostało zaimplementowane, na co dostał odpowiedź "bo w specyfikacji nie było, że mam coś sprawdzać". Kolejne pytanie "czy nie wydało Ci się to trochę dziwne? Przecież mogłeś dopytać, czy walidacja by się nie przydała" i kolejna odpowiedź "robiłem to, co miałem na liście zadań".

Jak widzisz - traktowanie jak dzieci może wynikać z tego, że część ludzi reprezentuje sobą właśnie taki poziom. I żeby nie było niedomówień - nie byli to żadni programiści z łapanki czy po jakichś kursach wieczorowych, wszyscy byli po studiach, a za swoją pracę mieli całkiem nieźle płacone.

Pijany Krawiec napisał(a):

Ostatnio jest modna patologia pod tytułem SCRUM. Manadżerowie to lubią, bo nie muszą rozkminiać planowania ani specyfikowania - w dwa tygodnie development team podejmie za nich wszystkie decyzje, definition of done zapobiegnie bugom, sprawy miękkie ogarnie scrum master, a sprawy trudne wrzuci się do backlogu na wieczne zapomnienie.

Jakież to jest prawdziwe :D
Tak półżartem, no.

IgnatiusTender napisał(a):

Tylko o czym aplikacja ma być, czy bardziej szczegółowo - metody, jak ma wyglądać interfejs?

Programista rzadko ma do czynienia z nową aplikacją. I jeszcze rzadziej jest tym akurat zaczynającym projekt. Częściej to jest raczej bugfixing czegoś co jest już od lat.

Wymagania są na pewno bardziej szczegółowe niż „o czym ma być”, ale nie spotkałem się osobiście (choć słyszałem z opowieści) o wymaganiach na poziomie klas czy metod.
Interfejs powinien być oczywiście rozrysowany. Zresztą od grafiki mamy grafików, którzy dobrze sobie z tym radzą: zakodzić trzeba tak by wyglądało jak na obrazku. Może nie zawsze pixel-perfect, ale prawie.

cerrato napisał(a):

Nie pamietam w tej chwili już konkretnie, co tam się działo, wiem że ostatecznie system został zrobiony, ale pamietam za to, jak się kumpel wkurzał na bezmyślność i olewactwo (albo totalny brak świadomości) programistów. Pierwszy przykład który mi przychodzi do głowy - totalny brak walidacji/kontroli wprowadzanych danych. Przykładowo - koleś tworzy okienko do wprowadzania zgłoszenia, trzeba tam podać informacje dotyczące pojazdu. Wiadomo, że w pole "wysokość" (to akurat dotyczyło samochodów) sensowne jest wpisanie wartości między 1 a 4 metry. Ale programista na to nie wpadł,więc można było wpisać cokolwiek: 4658, 0.066 albo "4g7xx". Kolega oceniając postęp prac to zauważył i zapytał, czemu tak to zostało zaimplementowane, na co dostał odpowiedź "bo w specyfikacji nie było, że mam coś sprawdzać". Kolejne pytanie "czy nie wydało Ci się to trochę dziwne? Przecież mogłeś dopytać, czy walidacja by się nie przydała" i kolejna odpowiedź "robiłem to, co miałem na liście zadań".

Jak widzisz - traktowanie jak dzieci może wynikać z tego, że część ludzi reprezentuje sobą właśnie taki poziom. I żeby nie było niedomówień - nie byli to żadni programiści z łapanki czy po jakichś kursach wieczorowych, wszyscy byli po studiach, a za swoją pracę mieli całkiem nieźle płacone.

Tutaj dochodzimy do tego jak zorganizowana jest praca w danym miejscu. Możesz mieć architekta, który ma za zadanie przygotować odpowiednio dokumentację, a programista to tylko robotnik w rodzaju murarza, który faktycznie nie musi znać kontekstu biznesowego tylko klepie taski, ale możesz mieć też (nie użyję słowa na S i kończącego się na crum) pewną swobodę w działalności programistów, gdzie odpowiedzialność za odpowiednią postać produktu jest rozkładana na zespół.