Do czytania

  1. Model Tuckmana jest z nami od dłuższego czasu i jednym z nadużyć, jakie widzę w osobach powołujących się na niego, jest to, że zapominają, że to nie jednokierunkowy tor. Nowy pomysł na rozwój naturalny trochę stara się to opisać lepiej, stosując inne nazewnictwo. ⏩️ Tuckman’s Model vs Modern Teams: A New Five Stage Approach https://andiroberts.com/teamwork/why-tuckmans-model-may-no-longer-serve-21st-century-teams

  2. Wszyscy mieliśmy z nimi do czynienia. W każdej organizacji znajdziemy ich przedstawicieli. Jak radzić sobie z toksycznymi personami w pracy? ⏩️ How To Deal With Difficult People At Work: 4 Secrets From Experts - Barking Up The Wrong Tree https://bakadesuyo.com/2025/11/difficult-people/

  3. Źródłem wielu problemów w zespołach i całej organizacji jest podejmowanie decyzji. A nawet nie samo podejmowanie, ale co dzieje się później. Jak robić to lepiej? ⏩️ The Hard Thing About Decisions: Why Your Teams Are Struggling to Make Good Choices https://www.thedecisionstack.com/the-hard-thing-about-decisions-why-your-teams-are-struggling-to-make-good-choices/

  4. A skoro już jesteśmy przy podejmowaniu decyzji, to właśnie to autor tego tekstu uważa za kluczowe w przyszłości roli PM i sztucznej inteligencji. ⏩️ What’s the Future of PMs? https://dpereira.substack.com/p/warning-pms-are-regressing-with-better

  5. Również o AI i roli PM, jednak z bardzo trafnymi segmentami, w których osoby pracujące z produktem powinny się rozwijać i skupić w przyszłości. ⏩️ So What’s Going to Happen to Product Management Anyway? https://creatoreconomy.so/p/so-whats-going-to-happen-to-product-management-anyway

  6. W jednym z ostatnich zestawień podrzuciłem materiał o user journeys i customer journeys. Teraz przyszła pora na persony, które również możemy podzielić na te związane z doświadczeniem użytkownika oraz klienta. ⏩️ User Personas vs Customer Personas: What’s the Difference? https://www.interaction-design.org/literature/article/user-personas-vs-customer

  7. Ciekawa opinia na temat podejmowania decyzji o wypuszczaniu nowej wersji oprogramowania na produkcję i znajomych bugach. ⏩️ Everything New Has Bugs https://mikefisher.substack.com/p/everything-new-has-bugs

  8. Agile może i wygrało wojnę, ale przegrało pokój. ⏩️ Agile won the war but lost the peace https://www.allankelly.net/archives/2762/agile-won-the-war-but-lost-the-peace/

  9. I jako rozwinięcie poprzedniego wpisu, odpowiedź na pytanie, czy Agile skonało? ⏩️ Agile: not Dead, but evolving https://www.allankelly.net/archives/10556/agile-not-dead-but-evolving/

  10. Bardzo dobre porady dla każdego, kto boryka się z niedziałającymi retrospektywami. Why your retrospectives don’t work and how to fix them https://lucasfcosta.com/blog/retrospectives

  11. Gdyby jeszcze do kogoś nie dotarło, że pomiar “osiągów” indywidualnie dla członków zespołu, to nie tylko kiepski pomysł, ale walka z wiatrakami, to w tym tekście solidna dawka argumentacji powyższego. ⏩️ Using Metrics to Measure Individual Developer Performance — Laura Tacho https://lauratacho.com/blog/using-metrics-to-measure-individual-developer-performance

  12. Tak, tak i jeszcze raz tak. Mikrozarządzanie jest niemalże uniwersalnie demonizowane w tematyce zarządzania zespołem, czy ludźmi, gdy przecież to tylko i wyłącznie narzędzie, które podobnie do wielu innych, może być użyte w odpowiedni lub nie, sposób. ⏩️ Understanding Micromanagement https://shreyasdoshi.substack.com/p/understanding-micromanagement

  13. Dlaczego musimy szacować pracę i dlaczego to tak szczególnie trudne dla programistów? ⏩️ https://thorsell.io/2025/12/07/estimates.html

  14. Jako osoba, która co kwartał jest świadkiem planowania kwartalnego, doskonale rozumiem ten artykuł…. i nieco płaczę wewnętrznie. ⏩️ The Only Thing That Matters On Your Roadmap Is the Next Step | ProdPad https://www.prodpad.com/blog/product-roadmap-next-step/

  15. Ile lekcji można wyciągnąć z pracy w Google? Okazuje się, że 21. I większość naprawdę ciekawa. ⏩️ 21 Lessons from 14 Years at Google https://addyo.substack.com/p/21-lessons-from-14-years-at-google

  16. Jestem fanem metryk DORA, jednak podobnie do wielu pożytecznych narzędzi w tworzeniu oprogramowania w organizacji, potrafią być pomocą, jak i utrapieniem dla tych zespołów. ⏩️ DORA metrics considered harmful. https://theitriskmanager.com/2025/12/19/dora-metrics-considered-harmful/

  17. Choć arykuł nie porusza problemów, które powodują, że daily standupy nie przynoszą spodziewanej wartości, warto przeczytać, jakie środowisko pracy wprowadzają do zespołu. ⏩️ RDEL #122: How do daily stand-ups boost team performance? https://rdel.substack.com/p/rdel-122-how-do-daily-stand-ups-boost

  18. Allan Kelly dzieli się swoimi dobrymi praktykami dla stawiania OKR w organizacji. ⏩️ 6 ways my OKRs are different - Allan Kelly https://www.allankelly.net/archives/10543/6-ways-okrs-enable-change/

  19. Warto jednak pamiętać, że OKR (podobnie do DORA wcześniej) mogą spowolnić zespół i jego dostarczanie wartości, jeśli podejdziemy do nich w nieodpowiedni sposób. ⏩️ Why OKRs Are Killing Your Team’s Performance with Radhika Dutt https://dpereira.substack.com/p/why-okrs-are-killing-your-teams-performance

  20. Jakiś czas temu słyszałem ciekawą opinię na temat tego, dlaczego developer gry wideo indie, nie zdecydował się na tworzenie swojej produkcji wspólnie z graczami jako early acees - zrobił to ponieważ nie chciał mieć “akcjonariuszy przerzucających na niego oczekiwania i życzenia odnośnie finalnego produktu”. Dużo w tym prawdy i ten artykuł również porusza te kwestie, choć nadal ukazuje plusy budowania publicznego. ⏩️ Building In Public is scary. Do it anyway. https://www.elenaverna.com/p/building-in-public-is-scary-do-it

  21. Powiem tak: rozumiem korzyści płynące z kierowania zespołem w formie “self-management”, ale WŁAŚNIE - kierowania. Moim zdaniem można prowadzić zespół i jednocześnie nie zabijając jego samoorganizacji. ⏩️ Should Product Teams be Self-Managing? https://www.romanpichler.com/blog/self-managing-product-teams/