Pracuj\u0119 z firmami, kt\u00f3re maj\u0105 \u015bwietnych developer\u00f3w, dobre technologie i ambitne cele. A jednak czas dostarczania funkcji jest d\u0142u\u017cszy ni\u017c powinien. Spotkania, poprawki, czekanie \u2013 czy to tylko \u201ez\u0142a organizacja\u201d?<\/p>\n
Z mojego do\u015bwiadczenia w audytach technologicznych wynika, \u017ce cz\u0119sto winne s\u0105 trzy z pozoru niewinne elementy: nadmiar proces\u00f3w, zbyt du\u017ca liczba kontekst\u00f3w oraz brak odpowiedniego narz\u0119dzia do priorytetyzacji. Nie chodzi o brak talentu, ale o system, w kt\u00f3rym ten talent si\u0119 dusi.<\/p>\n
Przyjrzyjmy si\u0119 tym blokerom na konkretnych przyk\u0142adach z \u017cycia polskich firm, z kt\u00f3rymi pracowa\u0142em.<\/p>\n
Wyobra\u017a sobie: programista pracuje nad now\u0105 funkcj\u0105 p\u0142atno\u015bci. W po\u0142owie dnia przychodzi alert o b\u0142\u0119dzie w starym module, potem brief z marketingu, a po godzinie kolega prosi o code review. Taka jest codzienno\u015b\u0107 w wielu zespo\u0142ach.<\/p>\n
Problem nazywa si\u0119 przeci\u0105\u017ceniem kontekstowym (context switching). Ka\u017cda zmiana zadania kosztuje \u2013 badania m\u00f3wi\u0105 o 15-30 minutach na odzyskanie pe\u0142nego skupienia. Je\u015bli developer prze\u0142\u0105cza si\u0119 5 razy dziennie, traci nawet 2,5 godziny produktywnego czasu.<\/p>\n
Przyk\u0142ad z rynku<\/strong><\/p>\n W jednej z agencji e-commerce, z kt\u00f3r\u0105 wsp\u00f3\u0142pracowa\u0142em, zesp\u00f3\u0142 6 os\u00f3b mia\u0142 jednocze\u015bnie 3 projekty i utrzymanie 2 starszych system\u00f3w. Wdro\u017cenie prostej zmiany w koszyku zajmowa\u0142o 2 tygodnie, cho\u0107 sama implementacja wymaga\u0142a 2 dni. Reszta to czas tracony na prze\u0142\u0105czanie mi\u0119dzy zadaniami.<\/p>\n Rozwi\u0105zanie?<\/strong><\/p>\n Wprowadzili\u015bmy zasad\u0119 \u201eblok\u00f3w skupienia\u201d \u2013 3 godziny dziennie bez przerw na Slack, spotkania czy maile. Developerzy pracowali wtedy nad jednym tematem. Wynik? Czas realizacji \u015bredniego zadania spad\u0142 o 40%.<\/p>\n Drugim krokiem by\u0142o ograniczenie liczby r\u00f3wnoleg\u0142ych projekt\u00f3w do maksymalnie dw\u00f3ch na osob\u0119. To wymaga\u0142o odwagi od kierownictwa, ale op\u0142aci\u0142o si\u0119.<\/p>\n Ka\u017cda firma ma procedury: Code review, daily standupy, retrospektywy, szacowanie task\u00f3w. Problem pojawia si\u0119, gdy te procesy przestaj\u0105 s\u0142u\u017cy\u0107 zespo\u0142owi, a staj\u0105 si\u0119 biurokracj\u0105.<\/p>\n Zauwa\u017cy\u0142em, \u017ce wiele firm ma zbyt du\u017co punkt\u00f3w blokuj\u0105cych<\/strong> w przep\u0142ywie pracy. Przyk\u0142ad? Code review, kt\u00f3re trwa 3 dni, bo recenzenci s\u0105 przeci\u0105\u017ceni. Albo cotygodniowe spotkanie planistyczne, kt\u00f3re trwa 2 godziny i omawia szczeg\u00f3\u0142y techniczne, kt\u00f3re r\u00f3wnie dobrze mo\u017cna przekaza\u0107 asynchronicznie.<\/p>\n Przyk\u0142ad z rynku<\/strong><\/p>\n W jednym SaaS-ie mieli\u015bmy proces wdro\u017ceniowy sk\u0142adaj\u0105cy si\u0119 z 15 krok\u00f3w, w tym potr\u00f3jne testy QA, review architekta i zatwierdzenie product ownera. Ka\u017cdy krok dodawa\u0142 \u015brednio 1 dzie\u0144 oczekiwania. W efekcie wdro\u017cenie hotfixa trwa\u0142o tydzie\u0144.<\/p>\n Przeanalizowali\u015bmy, kt\u00f3re kroki faktycznie chroni\u0105 jako\u015b\u0107, a kt\u00f3re s\u0105 pozosta\u0142o\u015bci\u0105 po dawnych l\u0119kach. Okaza\u0142o si\u0119, \u017ce 7 z 15 etap\u00f3w mo\u017cna usun\u0105\u0107 lub zautomatyzowa\u0107 bez ryzyka. Po zmianach wdro\u017cenie hotfixa zajmowa\u0142o 2 dni.<\/p>\n Wskaz\u00f3wka praktyczna<\/strong><\/p>\n Regularnie przeprowadzajcie \u201eaudyt proces\u00f3w\u201d \u2013 spiszcie ka\u017cdy krok od pomys\u0142u do wdro\u017cenia i zadajcie pytanie: Czy ten krok dodaje warto\u015bci klientowi?<\/em> Je\u015bli odpowied\u017a brzmi \u201enie\u201d lub \u201echroni nas przed b\u0142\u0119dem, kt\u00f3ry zdarza si\u0119 raz w roku\u201d \u2013 rozwa\u017ccie jego usuni\u0119cie.<\/p>\n Cz\u0119sto spotykam si\u0119 z sytuacj\u0105, w kt\u00f3rej zesp\u00f3\u0142 ma list\u0119 50 task\u00f3w, ale wszystkie s\u0105 oznaczone jako \u201ewa\u017cne\u201d. Wtedy developerzy wybieraj\u0105 to, co wydaje si\u0119 prostsze lub bardziej interesuj\u0105ce, a nie to, co przynosi najwi\u0119ksz\u0105 warto\u015b\u0107 biznesow\u0105.<\/p>\n Efekt?<\/strong><\/p>\n Przyk\u0142ad z rynku<\/strong><\/p>\n W jednej platformie e-commerce zesp\u00f3\u0142 rozwija\u0142 jednocze\u015bnie 5 funkcji: nowy checkout, integracj\u0119 z marketplacem, optymalizacj\u0119 wyszukiwarki, raportowanie i modu\u0142 SEO. Po 3 miesi\u0105cach \u017cadna z tych funkcji nie by\u0142a gotowa w 100%. Zesp\u00f3\u0142 by\u0142 wypalony, a biznes niezadowolony.<\/p>\n Rozwi\u0105zanie? Wprowadzili\u015bmy limit work in progress (WIP)<\/strong> \u2013 zesp\u00f3\u0142 m\u00f3g\u0142 pracowa\u0107 maksymalnie nad 2 funkcjami jednocze\u015bnie. Ka\u017cda funkcja musia\u0142a mie\u0107 jasno zdefiniowany priorytet biznesowy (np. oczekiwany wzrost przychod\u00f3w).<\/p>\n Po 2 miesi\u0105cach wdro\u017cyli\u015bmy pierwsz\u0105, w pe\u0142ni dzia\u0142aj\u0105c\u0105 funkcj\u0119 \u2013 nowy checkout. Wzrost konwersji o 15% potwierdzi\u0142, \u017ce priorytety by\u0142y s\u0142uszne. Reszta funkcji posz\u0142a w kolejnych iteracjach.<\/p>\n Jak to wdro\u017cy\u0107?<\/strong><\/p>\n Zamiast d\u0142ugiej listy task\u00f3w, stw\u00f3rzcie \u201emap\u0119 priorytet\u00f3w\u201d z 3 kategoriami: must have<\/em> (najbli\u017csze 2 tygodnie), should have<\/em> (kolejne 2 tygodnie) i nice to have<\/em> (wolny czas). Trzymajcie si\u0119 tego sztywno.<\/p>\n Wiele firm szuka ratunku w narz\u0119dziach: Jira, Trello, Asana, Linear. I faktycznie, mog\u0105 one pom\u00f3c w zarz\u0105dzaniu priorytetami i ograniczeniu WIP. Ale pami\u0119taj: narz\u0119dzie nie zast\u0105pi kultury skupienia i odwagi do ci\u0119cia proces\u00f3w.<\/p>\n Z mojego do\u015bwiadczenia, Linear<\/strong> jest \u015bwietny dla ma\u0142ych zespo\u0142\u00f3w, kt\u00f3re ceni\u0105 prostot\u0119, Jira<\/strong> \u2013 dla wi\u0119kszych organizacji z rozbudowanymi procesami (ale uwaga na zbytnie skomplikowanie), a Notion<\/strong> mo\u017ce s\u0142u\u017cy\u0107 jako \u201ewszystko w jednym\u201d przy odpowiedniej dyscyplinie.<\/p>\n Kluczowe jest, by narz\u0119dzie wspiera\u0142o proces, a nie go komplikowa\u0142o. Widzia\u0142em firmy, kt\u00f3re mia\u0142y Jir\u0119 skonfigurowan\u0105 tak, \u017ce developer sp\u0119dza\u0142 30 minut dziennie na aktualizowaniu status\u00f3w \u2013 to strata.<\/p>\n Tw\u00f3j zesp\u00f3\u0142 prawdopodobnie nie jest wolniejszy dlatego, \u017ce ma s\u0142abych programist\u00f3w. Winny jest system, w kt\u00f3rym pracuj\u0105: nadmiar kontekst\u00f3w, przero\u015bni\u0119te procesy i brak priorytetyzacji.<\/p>\n Zamiast zatrudnia\u0107 kolejnych ludzi, przejrzyjcie swoje procedury. Ograniczcie liczb\u0119 r\u00f3wnoleg\u0142ych projekt\u00f3w. Dajcie developerom czas na skupienie. Wprowad\u017acie limit WIP.<\/p>\n Efekt? Kr\u00f3tszy time-to-market, mniej wypalonych pracownik\u00f3w i wy\u017csza satysfakcja klient\u00f3w. A to przek\u0142ada si\u0119 na realne oszcz\u0119dno\u015bci i zyski.<\/p>\n Je\u015bli chcecie przeanalizowa\u0107 swoje procesy, mo\u017cemy to zrobi\u0107 wsp\u00f3lnie. Na JurskiTech.pl od lat pomagamy firmom odblokowa\u0107 potencja\u0142 zespo\u0142\u00f3w \u2013 nie tylko przez technologie, ale te\u017c przez lepsze zarz\u0105dzanie prac\u0105.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Tw\u00f3j zesp\u00f3\u0142 programistyczny jest wolniejszy ni\u017c powinien? 3 ukryte blokery Pracuj\u0119 z firmami, kt\u00f3re maj\u0105 \u015bwietnych developer\u00f3w, dobre technologie i ambitne cele. A jednak czas dostarczania funkcji jest d\u0142u\u017cszy ni\u017c powinien. Spotkania, poprawki, czekanie \u2013 czy to tylko \u201ez\u0142a organizacja\u201d? Z mojego do\u015bwiadczenia w audytach technologicznych wynika, \u017ce cz\u0119sto winne s\u0105 trzy z pozoru<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[482,965,379,244,447],"class_list":["post-2504","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-bledy-w-devops","tag-blokery-produktywnosci","tag-globalne-skalowanie","tag-procesy-it","tag-wydajnosc-zespolu-it"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2504","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2504"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2504\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. \u201eProcesy\u201d kt\u00f3re sta\u0142y si\u0119 celem samym w sobie<\/h2>\n
3. Brak jasnej priorytetyzacji \u2013 robienie wszystkiego naraz<\/h2>\n
\n
Bonus: Narz\u0119dzia, kt\u00f3re mog\u0105 pom\u00f3c (ale nie zast\u0105pi\u0105 kultury)<\/h2>\n
Podsumowanie<\/h2>\n