<h2 style="text-align:start;">Mamy osoby, ale co dalej? &nbsp;</h2>
Wyobraźmy sobie, że jako zespół rozpoczynamy projekt i na etapie białej kartki papieru dostaliśmy od zespołu HR-owego gotową 5 osobową grupę. Dlaczego grupę? Dlatego, że w tym momencie są to przypadkowi ludzie, których nie łączy nic. Docelowo łączyć ich będzie wspólny projekt, a co ważniejsze wspólny cel produktu. W takiej grupie, każda z tych osób jest nowa, nie zna się. Każda ma inny charakter, emocje, doświadczenia. &nbsp;
<h2 style="text-align:start;">Co zrobić na samym początku by patrzeć w tym samym kierunku? </h2>
1. Przedstawiamy cel projektu
2. Poznajemy naszych docelowych odbiorców w tym klientów, stakeholderów i odbiorców końcowych 
3. Określamy w jaki sposób pracujemy (może to być framework jaki wybieramy jako zespół, godziny spotkań np. scrumowych jeśli pracujemy w scrumie, określamy swoją dostępność, sposoby komunikacji itp.)
4. Przygotowujemy swoje środowisko, aby komunikować się transparentnie i by cyklicznie sprawdzać na jakim etapie jesteśmy (to pozwoli nam na bieżąco monitorować przyrost lub też pewne zagrożenia)&nbsp;

<h2 style="text-align:start;">Integracja? Na początku? TAK! &nbsp;</h2>
Myślę, że te 4 punkty są kluczowe, ale warto także pomyśleć o aspekcie socjologicznym. Nie znamy się, zatem warto poznać siebie na jakimś krótkim spotkaniu integracyjnym by przełamać tzw. pierwsze lody. Może mieć to formę spotkania po pracy, może być to interaktywny warsztat. Metod jest wiele. Warto jednak o tym nie zapominać i nie myśleć tylko czego potrzebujemy pod kątem projektu, lecz czego potrzebujemy też pod kątem ludzi, którzy będą ze sobą spędzać większość czasu w ciągu dnia. &nbsp;
<h2 style="text-align:start;">Etapy tworzenia zespołu według Tuckmana&nbsp;</h2>
Załóżmy, że wszystko to co opisałam wyżej zostało wykonane. Zespół pracuje. Jako osoba, która tym zespołem zarządza ważne jest, aby obserwować czy wszystko jest w porządku. Mam tu na myśli obserwacje ze spotkań, z rozmów czy też różnych zachowań. &nbsp;
W pracy jak i w życiu nie wszystko układa się zawsze tak jakbyśmy tego chcieli. Pytanie co zrobi nowy zespół, który napotka pierwszą, dużą przeszkodę? Reakcje mogą być różne. Ważne jest, aby wiedzieć jak zareagować. Ważniejsze jest jednak to by wynieść z każdych sytuacji i z każdego doświadczenia dla siebie lub dla zespołu jakąś wartość. &nbsp;
Nasuwa mi się tu myśl: co gdy po długim czasie wszystko z pozoru wydaje się być dobrze, ale osoby w gruncie rzeczy nie są zaangażowane i Ty jako osoba zarządzająca czujesz, że zespół wcale nie idzie razem, tylko kreuje pewne indywidualności? Możemy zatem odpowiedzieć, że to nie jest zespół. Czy tak jest na pewno? &nbsp;
W tym momencie chciałabym, abyśmy przeszli przez znany model Tuckmana w nawiązaniu do budowania zespołów (różnych, nie tylko zespoły w IT). &nbsp;
Bruce Tuckman był amerykańskim psychologiem i badaczem zachowań grup. Jako pierwszy opracował studium na temat dynamiki grup oraz w 1965 roku stworzył swój model w ujęciu budowania zespołów. Uważał, że fazy, które opracował oraz opisał są czymś naturalnym i to one umacniają zespoły tak, że wytwarzają wspólnie wszystkie rzeczy, projekty czy produkty.&nbsp;


<img src="https://mmsite.s3.eu-central-1.amazonaws.com/articles/a6d66787519e376084cef2789c310be6f45eea9c.png" alt="undefined" style="height: auto;width: auto"/>
Źródło: schemat własny, Canva&nbsp;

<h2>Każda z faz ma swój cel. Pokrótce przyjrzyjmy się jak każdy krok wygląda: &nbsp;</h2>
FORMING - początek zespołu. Każda strona stara się siebie poznać, osoby unikają zazwyczaj konfliktów czy też dyskusji spornych. Jest to swego rodzaju obserwacja siebie nawzajem, poznanie się. Efekty prac mogą nie być zadowalające, ponieważ zespół robi to co mu przekazano (dosyć książkowo), nie ma tu eksperymentowania. Wszyscy podchodzą raczej z dystansem, bo wciąż brakuje zgrania, a przede wszystkim zaufania. Osoba, która zarządza w tym zespole także poznaje poszczególnych ludzi, ich styl pracy i ma wpływ na to, by później w kolejnej fazie dograć zespół tak, aby razem tworzył jedną całość, szanując różne charaktery i styl pracy, co ostatecznie daje przyrost. W tym momencie także jest przestrzeń na stworzenie zasad współpracy razem z tworzącym się zespołem. Co istotne osoba zarządzająca powinna dopilnować, by zespół od początku wiedział jaki jest cel projektu, jaka ma być wartość ich prac i wszystkie niezbędne wytyczne, aby cel mógł zostać zrealizowany.&nbsp;
STORMING - w tej fazie wszystkie osoby zazwyczaj poznają przeciwne poglądy, inne spojrzenia i inne podejścia. Jest to swojego rodzaju faza buntu, burzy, w której następuje dyskusja lub też momenty konfliktów poprzez przeciwstawne poglądy. Osoby się “docierają” przez co wewnątrz grupy tworzą się wewnętrzne procedury i zasady współpracy. Najważniejsze jest by podczas tego etapu tworzenia się zespołu każdy miał do siebie wzajemny szacunek i starać się, aby nie dochodziło do nieprzyjemnych sytuacji. Lider grupy powinien wyłapać moment i ustanowić swego rodzaju strukturę po wszystkich odbytych wspólnie dyskusjach. Ważne jest też by wyciągnąć z tej fazy jak najwięcej doświadczenia i wniosków, aby w przyszłości “storming” nie występował. Czas trwania tej fazy jest różny. Nie ma określonego terminu. Jest to proces naturalny, który występuje zawsze i zawsze przechodzi. Gdy mamy w zespole ciągły storming wiemy, że coś nie jest tak jak powinno. &nbsp;
NORMING - w tym momencie zespół już posiada ustalone zasady współpracy. Współpraca się normuje, nabiera regularności. Osoba zarządzająca może zatem zostawić zespół i pozwolić mu na samoorganizację. Teraz czas, aby to zespół przejął odpowiedzialność za efektywność swojej pracy. W fazie tej procesy powinny także zostać z ewoluowane, aby przy jakichkolwiek problemach móc zmienić zasady, aby być bardziej optymalnym i bardziej efektywnym.&nbsp;
PERFORMING - etap działania to sprawne i płynne wykonywanie pracy zespołu bez żadnych konfliktów i bez żadnego nadzoru czy też zarządzania. Zespół sam wie jak działać tak by był widoczny efekt prac. Bardzo ważna w tej fazie jest ciągłość tego procesu to znaczy nieustannie bez zakłócenia pracujemy w ustalonych zasadach, z szacunkiem do siebie, transparentnie informując o statusach prac czy też demonstrując swoje efekty pracy. Każda z faz nie oznacza jej końca. W okresie normowania i działania zawsze w momencie pojawienia się konfliktów, wracamy naturalnie do fazy STORMINGU, po to by wyciągnąć wnioski, razem się rozwijać lub też gdy zespół ma nowych członków. &nbsp;
Warto zwrócić uwagę na to, że Tuckman podkreślał, że jest to naturalny i normalny proces u każdego, kto uczestniczy w pracy zespołowej. &nbsp;

<h2>Po każdej burzy wychodzi słońce lub tęcza&nbsp;</h2>
Warto podkreślić kończąc ten artykuł, że jak to mówi przysłowie: “po każdej burzy wychodzi słońce” i tak to jest moim zdaniem także w procesie tworzenia się zespołu. &nbsp;
Jeśli przyjmujemy zmiany za coś normalnego, postaramy się do nich dopasować, to naturalnie jako zespół przejdziemy przez fazy opisane przez Tuckmana, mając na uwadze ciągły rozwój, ciągłe dopasowywanie się do zmieniającego się otoczenia i zmiennych wymagań biznesowych. To wszystko po to by dostarczać rozwiązania oraz produkty, które są odpowiedzią na wszelakie potrzeby zmieniającego się świata.&nbsp;
Źródła:&nbsp;
<a href="https://pl.linkedin.com/pulse/etapy-budowania-zespo%C5%82u-brucea-tuckmana-pe%C5%82en-opis-tomasz-dulewicz" target="_blank"><ins>https://pl.linkedin.com/pulse/etapy-budowania-zespo%C5%82u-brucea-tuckmana-pe%C5%82en-opis-tomasz-dulewicz </ins></a>&nbsp;
<a href="https://annakolm.pl/494/budowanie-zespolu-fazy-wg-tuckmana/" target="_blank"><ins>https://annakolm.pl/494/budowanie-zespolu-fazy-wg-tuckmana/ </ins></a>&nbsp;

Tworzenie zespołu - model Tuckmana

Jeśli masz już swoją odpowiedź, to teraz ja powiem, czym jest on dla mnie. Dla mnie to najbliższe grono mi osób, z którym mam coś wspólnego i w którym razem dążymy do pewnych celów (czasem lepiej określonych, a czasem mniej). Zespół to dla mnie rodzina ta najbliższa, grono znajomych, z którymi spotkamy się by wspólnie spędzić czas czy zespoły, z którymi pracuję od poniedziałku do piątku. Gdy byłam związana z koszykówką to także tam grałam na każdym meczu z innym zespołem i razem tworzyliśmy pewną całość. Naszym celem wówczas był wygrany mecz.&nbsp;
<h2 style="text-align:justify;">Zerknijmy teraz do literatury: czym jest zespół na jej podstawie?&nbsp;</h2>
Zespół według słownika PWN to: “(...)grupa ludzi wspólnie pracujących lub robiących coś w jakiejś dziedzinie.” Według Encyklopedii Zarządzania “Zespół to zbiór osób, które posiadają wspólny, konkretny cel działania i wzajemnie uzupełniające się umiejętności” (K. Kmiotek 2012, s. 162). Scrum Guide z kolei definiuje zespół w ujęciu agile jako podstawowy element metodyki i wskazuje, że “(...) Scrum Team nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia. To spójna grupa profesjonalistów skupionych na pojedynczym celu określanym jako Cel Produktu.”.
To wszystko, co widzimy, ma sens. Jest mocne. Sama teoria przybliża do siebie ludzi i wskazuje na jedną ważną (przynajmniej dla mnie) cechę: potrzebujemy ludzi, by ze sobą współpracować, by coś wytwarzać a przede wszystkim, by żyć.&nbsp;
Wszystko to, co jest powyżej, wskazuje na samą sielankę, jednak nie jest tak do końca. Nikt z nas przecież nie jest taki sam. Pracując/będąc w zespole, trafiamy na różne osobowości, różne charaktery, nastawienia czy też emocje. Nasuwa mi się pytanie: czy zatem istnieje zespół idealny? Moim zdaniem nie, ale istnieje zespół dopasowany, szanujący się i idący w tym samym kierunku.&nbsp;
<h2 style="text-align:justify;">Czy każdy zespół jest taki sam? Uważam, że nie i dlatego poruszmy teraz rodzaje zespołów.&nbsp;</h2>
Każdego dnia poruszam się w obszarze zarządzania projektami w IT więc odniosę się najpierw do ogółu pod kątem zarządzania, a następnie przejdę do własnych doświadczeń.&nbsp;
Według literatury zespoły projektowe wymienia się z podziałem na:
- zespół izomorficzny gdzie głównym celem jest produkt, który powstaje z danego projektu. W takim projekcie osoba zarządzająca blisko współpracuje z każdą osobą z projektu i pilnuje, by wszystkie zadania prowadziły do spójnej całości jako produkt.
- zespół ekspercki - w zespole tym, każdy pracuje nad różnymi zadaniami ze swojej branży. Każda z osób bierze wówczas pełną odpowiedzialność za swoje zadania. Osoba zarządzająca takim zespołem potrzebuje opanować cały projekt łącznie, wszystkich ekspertów naraz.
- zespół kolektywny - z samej już nazwy dla mnie dobrze to brzmi. W tym zespole tym liczy się całokształt, czyli finalnie produkt. Każdy w tym projekcie ma wpływ. W zespole tym osoby sobie pomagają i nie są ekspertami w jednej dziedzinie. Nie ma tutaj indywidualności, lecz wspólne działanie i wspólny cel. Cechą szczególną jest brak jakiejkolwiek osoby przywódczej, która wskazuje, co ma być wykonane i jak.
- zespół ze strukturą chirurgiczną - rodzaj tego zespołu wywodzi się z firmy IBM. Główną osobą w zespole jest szef, a pozostali członkowie są jego asystentami, ekspertami itd.. Ich zadaniem jest wówczas dostarczanie odpowiednich danych, narzędzi by szef miał odpowiednie warunki do spełnienia celu projektu. Szef skupia się na kluczowych zadaniach, tak jak robi to chirurg (precyzyjnie, bez dodatkowych zadań rozpraszających, bo ma do tego asystentów).&nbsp;
Specjalnie wymieniłam tu rodzaje bez ich opiniowania. No może w kolektywnym stwierdzam, że sama nazwa jest pozytywna i to wszystko. Myślę, że w każdych z tych krótko przedstawionych struktur zespołów można wskazać zalety, jak i wady, jak we wszystkim. Gdybym miała wybrać swój preferowany styl, to już wiecie, że byłby to kolektywny. Dlaczego? Odpowiedź poniżej.&nbsp;
<h2 style="text-align:justify;">Zespół w ujęciach Scruma&nbsp;</h2>
Scrum wymienia bardzo ważne cechy zespołu deweloperskiego, w które ja wierzę i z którymi się utożsamiam. Są nimi:
a. samoorganizacja - rozumiem to tak, jak w zespole wyżej kolektywnym, nie ma żadnego szefa, który wskazuje drogę, w tym przypadku może to być Scrum Master, który edukuje i powtarza cechy Scruma i daje szansę, by to członkowie zespołu sami wiedzieli, jak iść i w którą stronę. Nikt nie każe iść w prawo i w lewo, to zespół wspólnie decyduje i ustala ścieżkę (czy to developmentu, czy rozwoju, czy też optymalizacji produktu)
b. interdyscyplinarność - każdy z członków zespołu jest otwarty na zdobywanie wiedzy i ciągły rozwój, nie skupia się na swojej specjalizacji, lecz łączy umiejętności, tak by razem z innymi dodać wartość do końcowego celu projektu
c. zaangażowanie - zespół ten zna jasno przedstawiony cel, ze sprintu na sprint stara się dostarczyć minimalną użyteczną i działającą wartość do produktu końcowego. By tak się stało zespół, jest skoncentrowany oraz zaangażowany. &nbsp;
No i teraz podsumowując: osobiście chciałabym dążyć do struktury kolektywnej oraz do zespołu scrumowego. Bardzo mi się podoba podejście scrumowe, jednak jestem zdania, że często zwłaszcza na samym początku tworzenia się zespołu ważna jest osoba, która zespół poprowadzi, wskaże szlak. Resztę zespół w procesie tworzenia utworzy sam.&nbsp;
O zespołach można by pisać bardzo dużo. Chciałabym tym artykułem rozpocząć krótką serię o umiejętnościach miękkich, które mogą się przydać każdemu z nas, lub też osobom, które są w zespołach lub też zespołami w jakiś sposób zarządzają.&nbsp;
Myślę, że warto się zastanowić, a zwłaszcza pomyśleć, w jakim zespole się znajduję i co mogę uczynić, by zespół ten czuł się dobrze, był zadowolony ze wspólnych sukcesów, wyciągał wnioski z potknięć i by cały czas się rozwijał.&nbsp;
Na koniec chciałabym rzucić pytanie do przemyślenia: co jeśli zespół nie realizuje wspólnego celu? Czy dalej jest to zespół? Nie. To grupa i to jest zasadnicza różnica.
Zespół ma wspólny, jasno określony cel, grupa zaś realizuje swoje cele indywidualne.
Grupa jest jakby zbiorowiskiem osób przypadkowych, gdzie każdy ma swoje zadanie i każdy indywidualnie ponosi odpowiedzialność. W zespole kierujemy się zasadą zbiorowości, celowości i wspólnej odpowiedzialności.&nbsp;
Polecam ciekawy artykuł na stronie ASANY: <a href="https://asana.com/pl/resources/group-vs-team" target="_blank">https://asana.com/pl/resources/group-vs-team</a>, podsumowując, wykorzystam tu ich prosty graf na temat różnicy między grupą a zespołem.&nbsp;

<img src="https://mmsite.s3.eu-central-1.amazonaws.com/articles/99352f8001960db854420f1380214072e154bc7e.png" alt="undefined" style="height: auto;width: auto"/>

Źródło: Artykuł online <a href="https://asana.com/pl/resources/group-vs-team" target="_blank"><ins>https://asana.com/pl/resources/group-vs-team </ins></a>&nbsp;
Na koniec jeden z moich ulubionych cytatów. Cytat Babe Ruth’a mówi więcej niż tysiąc słów. Kim był Babe? Polecam poczytać jego historię w świecie sportu.&nbsp;
“(...) Sposób, w jaki drużyna gra jako całość, determinuje jej sukces. Możesz mieć największą grupę pojedynczych gwiazd na świecie, ale jeśli nie grają razem, klub nie będzie wart ani grosza. (...)” Babe Ruth Źródła:
<ol>
<li style="text-align:left;"><a href="https://sjp.pwn.pl/sjp/zespol;2545568.html" target="_blank">https://sjp.pwn.pl/sjp/zespol;2545568.html </a>&nbsp;</li>
<li style="text-align:left;">&nbsp;<a href="https://mfiles.pl/pl/index.php/Zesp%C3%B3%C5%82https://mfiles.pl/pl/index.php/Zesp%C3%B3%C5%82" target="_blank">https://mfiles.pl/pl/index.php/Zesp%C3%B3%C5%82</a>&nbsp;</li>
<li style="text-align:left;"><a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf" target="_blank">https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf </a>&nbsp;</li>
<li style="text-align:left;"><a href="https://asana.com/pl/resources/group-vs-team" target="_blank">https://asana.com/pl/resources/group-vs-team </a>&nbsp;</li>
<li style="text-align:left;"><a href="https://thepdcafe.com/pl/30-inspirational-team-building-quotes/" target="_blank">https://thepdcafe.com/pl/30-inspirational-team-building-quotes/ </a>&nbsp;</li>
</ol>

Zespół - to zawsze one team one goal.

Daily według nowego Scruma to <a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf" target="_self"><ins>“(...) 15‐minutowe wydarzenie dla Developerów danego Scrum Teamu. Aby ograniczyć złożoność, odbywa się ono o tej samej porze i w tym samym miejscu w każdy dzień roboczy w trakcie trwania Sprintu. Jeśli Product Owner lub Scrum Master wykonują pracę związaną z elementami Sprint Backlogu, uczestniczą w spotkaniu jako Developerzy.” </ins></a>Pierwsze, co może rzucić się w oczy, to jasno sprecyzowany czas trwania spotkania. Widzimy też, że spotkanie odbywać się powinno codziennie w tym samym miejscu i o tej samej porze. Wiemy już całkiem sporo, ale zadajmy sobie teraz pytanie: co powinno wnosić takie spotkanie? Obecnie często się słyszy, że spotkania należy ograniczać. Po co zatem to daily? W skrócie celem daily jest monitorowanie postępu prac w sprincie. Codzienne, krótkie i transparentne spotkanie w trakcie trwania sprintu pokazuje nam jako zespołowi w jakim miejscu jesteśmy w porównaniu do tego gdzie chcemy być i gdzie być powinniśmy. Ma nam to pomóc w realizacji planu na kolejny dzień pracy. Jako zespół gramy do jednej bramki jaką jest przyrost i dostarczanie sprint po sprincie niewielkiej, działającej części systemu/produktu/usługi. 
<h2>Jak powinno wyglądać idealne daily? Czy idealne daily w ogóle istnieje? </h2>
Myślę, że każdy zespół robi daily po swojemu i najlepszych praktyk jest wiele. Przede wszystkim należy przestrzegać zasady 15 minut (nie chcemy kolejnego godzinnego spotkania o niczym). Daily ma być krótkie, jasne i na temat.
Przewodniki scrumowe mówią o <ins>3 pytaniach</ins>, na które powinniśmy sobie odpowiedzieć podczas daily: 1. co zrobiłem wczoraj? 2. co zrobię dziś? 3. co poszło ok. a z czym miałem problem ? Oczywiście wiele zespołów używa wariacji tych pytań, ale najważniejsze nie są same pytania, a informacje, które dostarczane są poprzez cenną odpowiedź. Według podejścia agile to właśnie transparentność jest jednym z trzech filarów Scruma. Wyobraźmy sobie, że nie mamy daily, nie komunikujemy się, mamy tylko Jirę. Podejście idealne - jeżeli jesteśmy robotami. Ale zanim wygra Skynet, by widzieć postęp prac musimy ze sobą rozmawiać, współpracować i wymieniać się wiedzą. Dzięki rozmowie każdy z członków zespołu wie jak idzie całościowy proces wytwórczy czyli development. 
Podsumowując mogę napisać, że w Mad Mountain bardzo cenimy sobie nasze daily. Jest to doskonałe i proste narzędzie. Lubimy ze sobą rozmawiać. Nie zdradzimy jakie pytania zadajemy sobie nawzajem, niech każdy ma swoją małą tajemnicę daily, ale róbmy je bo jest ważne. &nbsp;

Potęga Daily - czemu jest tak istotne

<h1 style="text-align:justify;">Podsumowanie 2021 roku</h1>
2021 rok był to czas wyzwań oraz stawianiu czoła wielu zmiennym (typowe jak na środowisko agile, prawda?). Jak im sprostaliśmy? Kończymy rok z uśmiechami na twarzach, więc poszło nam całkiem nieźle :) 
<ul>
<li>W 2021 roku do naszego zespołu zleceniobiorców dołączyło kilka nowych osób. Musieliśmy w związku z tym zadbać o jeszcze lepszą komunikację i organizację naszej współpracy, aby uniknąć nieporozumień i marnowania czasu na nadmierną ilość spotkań, tysiące wiadomości na Slacku i codzienne telefony. Cenimy sobie nasz czas i czas naszych klientów.</li>
<li>Współpracujemy zgodnie z metodyką Scruma, dlatego w zeszłym roku współpracowaliśmy przede wszystkim nad interdyscyplinarnością zespołu. Dzisiaj możemy powiedzieć, że zespół jest wielofunkcyjny oraz empatyczny, pomaga sobie i jest jednością. Co cieszy to fakt, że osoby w zespole nie boją się trudnych tasków, współpracują ze sobą i starają się rozwijać w technologii, których do tej pory nie znały. Otwartość na nowe oraz chęć samokształcenia jest w istocie napędem do dalszego rozwoju własnego oraz firmy. </li>
<li>W 2021 roku zrealizowaliśmy wiele ciekawych, przełomowych dla nas, projektów. Część z nich możecie zobaczyć w naszym portfolio. Nie zamykamy się na żadną z branż, dlatego poprzedni rok był niesamowicie ekscytujący i różnorodny pod kątem realizowanych projektów. &nbsp;</li>
</ul>
By nie pokazywać życia tylko w różowych barwach, wiadomym jest, że mieliśmy też te gorsze momenty, z których jednak wspólnymi siłami zdołaliśmy wyjść. Wyciągnęliśmy z nich wnioski i uzbrojeni w nowe doświadczenia i wiedzę, weszliśmy w rok 2022. Eksperyment na 2022 rok - czterodniowy tydzień pracy Po podsumowaniu 2021 roku, zaczęliśmy zastanawiać się, co jeszcze możemy zmienić, aby rok 2022 był dla nas przełomowy. Wspólnie uznaliśmy, że chcemy spróbować współpracy w systemie czterodniowym. Na pierwszy rzut oka wydaje się to trudne do realizacji, ale w 2018 roku słyszeliśmy to samo, kiedy mówiliśmy, że wszyscy współpracujemy z domów. Rok później, cały świat musiał przestawić się na home office, który w wielu firmach trwa do dzisiaj. Naszym pierwszym celem celem jest przestawienie się na cztery dłuższe dni 4 x 10h, ale jeśli ten system się sprawdzi, już od 2023 roku chcemy współpracować w systemie 4 x 8 h czyli poprostu cały dzień krócej. Korzyści płynące z czterodniowego tygodnia Według <a href="https://innpoland.pl/170227,4-dniowy-tydzien-pracy-w-polsce-te-firmy-juz-go-wprowadzily" target="_self">INNPOLAND.PL</a> “(...) zagr aniczne testy 4-dniowego tygodnia pracy pokazują, że ma on wpływ na zwiększenie motywacji i zaangażowania oraz wzrost efektywności. Potwierdzają to zarówno firmy, jak i całe państwa. [...] Japoński oddział Microsoftu był jedną z pierwszych firm testujących takie rozwiązanie i to jeszcze przed pandemią. O eksperymencie zrobiło się głośno po tym, jak okazało się, że nowy system pracy spowodował wzrost produktywności pracowników o 40 proc.”. Bardzo wierzymy, że mimo dodatkowego dnia wolnego od świadczenia usług nasza produktywność wzrośnie, a cotygodniowy długi weekend przyniesie korzyści duchowe, personale oraz te związane z życiem rodzinnym lub edukacyjnym. 
Zagrożenia płynące z czterodniowego tygodnia współpracy Jak każdy projekt, tak i ten, musimy nadzorować w odniesieniu do ryzyka. Ponieważ jako jedni z pierwszych w Polsce planujemy przejść na czterodniowy tydzień współpracy, musimy zadbać przede wszystkim o komunikację i organizację, aby nasi klienci nie odczuli tego w negatywny sposób. Postanowiliśmy, że część zespołu będzie dostępna w poniedziałki, a pozostali piątki, tak aby zawsze ktoś był na posterunku. Zoptymalizowaliśmy nasze spotkania i komunikację, aby każdy znał plan działania na dzień, w którym pracuje tylko połowa zespołu. To pozwoli uniknąć przestojów w pracy spowodowanych niewystarczających informacji. W trakcie trwania nowego systemu, będziemy stale monitorować nasze postępy i zadowolenie. Miernikiem sukcesu nowego systemu będzie efekt realizacji projektów. Będziemy mierzyć czy dostarczamy tyle samo, mniej lub więcej. Ankiety i rozmowy pokażą, czy zespół czuje się wydajniejszy albo może wręcz przeciwnie - nie może się odnaleźć w tej sytuacji. Najpierw testy, a później wyciągnięcie wniosków na podstawie danych. Podsumowując, to będzie <ins>rok testowania</ins>. Testujemy nowy system pracy by być bardziej efektywnym zespołem z zachowaniem życia prywatnego w większej skali. Dodatkowo nie bez powodu napisaliśmy “testowania”. Chodzi też o to, że testy w tym roku stawiamy jako najwyższą wartość. Jest ono dla nas kluczowym elementem przy wytwarzaniu oprogramowania. &nbsp;

4-dniowy system

Wszystkie

Witaj na naszym blogu! Jesteśmy firmą, która specjalizuje się w tworzeniu aplikacji dla branży IT, aby pomagać naszym klientom w zarządzaniu i optymalizacji ich działalności. Na naszym blogu publikujemy artykuły o najnowszych trendach i rozwiązaniach w branży IT, a także opowiadamy o naszych własnych projektach i sukcesach.

Realizacje

Sandra Baruffi

Wszystkie posty autora:

Tworzenie zespołu - model Tuckmana

Zespół - to zawsze one team one goal.

Potęga Daily - czemu jest tak istotne

4-dniowy system