Dobry odcinek, a listę powodów można by wymieniać bez problemu przez kilka godzin. Zaczynając od tego, że zespoły nie ustaliły wspólnego języka i pod tym samym terminem/słowem kryją się różne pojęcia, poprzez różne poziomy umiejętności i wiedzy członków zespołu, poprzez błędne założenia czy to samego projektu czy zakładanie, że coś jest oczywiste. Brak wiedzy dziedzinowej osób implementujących, wojny ego członków projektu. Część ekspertów, zwłaszcza wewnętrznych w firmach, została ekspertami z mianowania, poprzez zasiedzenie i mają 'posłuch' w firmie bo reszta ogarnia jeszcze mniej. Błędy historyczne, brak dokumentacji obecnego procesu i stanu, brak chęci zmiany przez osoby decyzyjne różnych obszarów firmy w obawie przed zmianami, itd... na prawdę nie wiem czy da się tę listę wyczerpać 🙂
W skrócie: Agile, presja cenowa i zmiany kulturowe w branży, które kładą nacisk na skille miękkie oraz pogoń za hypem, która uniemożliwia zdobycie głębokich kompetencji - indywidualnie, zepsołowo, organizacyjnie. Przykład, Android Automotive.
niezrozumienie potrzeb jest bardzo ogólnym pojęciem ale jest też powodem prawie każdego fakapu. Od niezrozumienia potrzeb biznesowych, przez niedopowiedzenia po niewłaściwie dobrany stack technologiczny. Najgorzej jeśli klient upiera się przy jakimś stacku, bo tak gdzieś usłyszał lub to jest modne - musi być cloud, żaden PHP i ten konkretny cms/framework/serwis. Jest to częste w średniej wielkości firmach, gdzie jakiś dział IT istnieje, ale no widać nie na tyle kompetentny by samemu stworzyć aplikację. Ogólnie to mam takie poczucie że brzytwa ockhama tu się pojawia, bo najgorsze projekty jakie wspominam to takie w których był ktoś kto aspirował do bycia programistą i miał jakąś wizję która z powodu braku doświadczenia okazuje się zgubna, a jest praktycznie wymaganiem projektu dosłuchałem dalej: widzę że wspominasz dokładnie o tym samym xD
przyjemnie się słucha
dzięki :)
Dobry odcinek, a listę powodów można by wymieniać bez problemu przez kilka godzin.
Zaczynając od tego, że zespoły nie ustaliły wspólnego języka i pod tym samym terminem/słowem kryją się różne pojęcia, poprzez różne poziomy umiejętności i wiedzy członków zespołu, poprzez błędne założenia czy to samego projektu czy zakładanie, że coś jest oczywiste. Brak wiedzy dziedzinowej osób implementujących, wojny ego członków projektu. Część ekspertów, zwłaszcza wewnętrznych w firmach, została ekspertami z mianowania, poprzez zasiedzenie i mają 'posłuch' w firmie bo reszta ogarnia jeszcze mniej. Błędy historyczne, brak dokumentacji obecnego procesu i stanu, brak chęci zmiany przez osoby decyzyjne różnych obszarów firmy w obawie przed zmianami, itd... na prawdę nie wiem czy da się tę listę wyczerpać 🙂
To prawda, temat niezwykle otwarty i szeroki :) Bardzo fajne argumenty, dzięki!
W skrócie: Agile, presja cenowa i zmiany kulturowe w branży, które kładą nacisk na skille miękkie oraz pogoń za hypem, która uniemożliwia zdobycie głębokich kompetencji - indywidualnie, zepsołowo, organizacyjnie. Przykład, Android Automotive.
To cenna obserwacja - hype jest jedną z rzeczy, która drażni mnie dość mocno.
niezrozumienie potrzeb jest bardzo ogólnym pojęciem ale jest też powodem prawie każdego fakapu. Od niezrozumienia potrzeb biznesowych, przez niedopowiedzenia po niewłaściwie dobrany stack technologiczny. Najgorzej jeśli klient upiera się przy jakimś stacku, bo tak gdzieś usłyszał lub to jest modne - musi być cloud, żaden PHP i ten konkretny cms/framework/serwis. Jest to częste w średniej wielkości firmach, gdzie jakiś dział IT istnieje, ale no widać nie na tyle kompetentny by samemu stworzyć aplikację. Ogólnie to mam takie poczucie że brzytwa ockhama tu się pojawia, bo najgorsze projekty jakie wspominam to takie w których był ktoś kto aspirował do bycia programistą i miał jakąś wizję która z powodu braku doświadczenia okazuje się zgubna, a jest praktycznie wymaganiem projektu
dosłuchałem dalej: widzę że wspominasz dokładnie o tym samym xD
Great minds think alike! :D