Tag: zarządzanie

W poprzednim tekście nt. Flow Management (Strefa PMI, nr 36) przedstawiłem negatywne konsekwencje tradycyjnego systemu pracy i zarządzania, konieczność myślenia systemowego, całościowego oraz odpowiedź na pytanie: po co ten Flow Management. Teraz czas na przedstawienie praktyk i metryk Flow Management oraz ich różnych zastosowań do zarządzania pracą zespołu, procesami i projektami oraz portfelem projektów.

U moich klientów czasami widzę, że UX jest traktowany po macoszemu. Na poziomie deklaracji mówi się, że UX jest ważny, jednak w praktyce główny nacisk kładzie się na prace inżynieryjne i rozwiązania techniczne. Kwestie takie jak design produktu, spełnianie potrzeb przyszłych użytkowników, wizja biznesowa czy w ogóle zasadność produktu są na drugim planie.

„Po co mi ten Junior?” – to pytanie zadaje sobie wielu kierowników projektów stając przed wyzwaniem zwiększenia poziomu juniority w swoich zespołach projektowych, w domyśle parafrazując je do postaci – „Po co mi ten kłopot?”. Trywializowanie tego zagadnienia jest efektem zakorzenionej w nas potrzeby pozostania w pewnej strefie komfortu, która jednak, z perspektywy projektu, tworzy jedynie złudne poczucie bezpieczeństwa i jest zazwyczaj efektem mylnego przeświadczenia o opanowanym ryzyku w tym obszarze. Nie wygląda to najlepiej, prawda? I tak by pewnie było, gdybyśmy rzeczywiście traktowali stanowiska juniorskie jako problem. Spróbujmy więc zadać sobie pytanie – „Jak mogę przekuć ten kłopot w szansę?” i poszukać na nie odpowiedzi.

Podstawową różnicą między zarządzaniem projektem a zarządzaniem zmianą jest uzyskanie w drugim przypadku o wiele wyższego poziomu zaangażowania pracowników. Bardzo dużą rolę w procesie zarządzania zmianą odgrywa komunikacja. I ma ona o wiele więcej niuansów, niż dobrze przygotowany komunikat na temat zmian w organizacji. Znaczenie ma też kto, kiedy co i jak mówi, a także… o czym nie mówi.

Dobro się mnoży kiedy się nim dzieli. Ta zasada sprawdza się w życiu, ale czy również w biznesie? Czy obowiązkiem firmy jest dzielenie się tym, co wypracuje? Absolutnie nie. Chyba, że... wola przedsiębiorcy podpowiada inaczej.

Czy projekty realizowane w Agile wymagają zwinnych umów? To pytanie retoryczne. Oczywiście, że tak. W przeciwnym wypadku będą zwinne tylko z nazwy albo – cytując klasyka – będziemy mieli do czynienia z dwiema prawdami: prawdą umowy i prawdą projektu. Pytanie tylko, co to znaczy, że umowa jest zwinna i jakie są cechy charakterystyczne dla tego typu kontraktów?