Podział zespołów na frontend i backend nie ma sensu
HTML-код
- Опубликовано: 9 янв 2025
- Najgorszy możliwy podział to oczywiście osobne zespoły analityczne, deweloperskie i testerskie. Ale na drugim miejscu dumnie stoi podział na zespoły frontendowe i backendowe. No bo jaką konkretnie wartość dla klienta dostarczają zespoły backendowe? I czy naprawdę ich praca jest skończona, gdy frontend jeszcze jest daleko z tyłu?
Odezwij się do #białko:
bialko.eu/wspa...
bialko.eu/kont...
NIe wyobrażam sobie by w refinemencie funkcjonalności nie uczestniczyli devi z back-endu i front-endu jednocześnie. Wyjaśnienie sobie wzajemnie zalezności, omowienie komuikacji backend-frontend (np potrzeba nowych endpointów lub update istniejących) już na tym etapie wiele ułatwia. I eliminuje (w dużym stopniu) poprawki zadań back-endowych w chwili gdy po testach rozpoczęto prace nad częścią front-endu. A generalnie to przez 9 lat pracy w softwarehousie nie pracowałem z tak wyspecjalizowanymi zespołami :) zawsze to były grupy crossfunkcjonalne.
Bardzo dobry film. Niestety ciągle zespoły myślą zadaniowo niż dostarczaną wartością.
Niestety, jest to baaaaardzo powszechne. Jakieś 10 lat temu był mały boom na krossfunkcjonalne zespoły, który niestety dość szybko minął. Na obronę zespołów można dodać, że jeśli taka organizacja została narzucona (zespoły zadaniowe, a nie skupione na wartości; rozliczanie z zadań, a nie efektów), to dość naturalnie przyjmuje się taki punkt widzenia.
@@bialkooczywiście to często wina organizacji bo tak łatwiej, bo łatwiej rozliczyć osobę za zadanie niż zespół.