Zmiana jest naturalną rzeczą jeśli chodzi o organizacje. Rynek zmienia się często i szybko. Chyba już nie istnieją sektory czy branże, które są "stabilne" (czasami się zastanawiam czy takie kiedykolwiek istniały, może to tylko miejska legenda?). IT ma za zadanie wspierać biznes, więc powinno być elastyczne. Systemy powinny pozwalać na szybkie zmiany. Oczywiście łatwo powiedzieć, ale czy równie łatwo zrobić?
Nowoczesne metodologie pozwalające na zarządzanie projektami/produktami IT pozwala na szybką reakcję na zmiany (Scrum i generalnie cały agile, lean oraz inne), niemniej jednak sama metodyka to nie wszystko.
Elastyczne założenia
Brzmi dziwnie, nieprawdaż? Podczas zbierania wymagań, trzeba zrobić założenia. Skoro to założenia to powinny być przecież stabilne! Praktyka brutalnie uczy, że założenia wyglądające jak skały tatrzańskie albo i nawet same Tatry także mogą zostać ruszone w rozumieniu zmienione (znacie powiedzenie o przenoszeniu gór? pasuje tu!). Myślę, że nawet założenia związane z teorią grawitacji mogą zostać podważone na gruncie IT ;)
Nowoczesne metodologie pozwalające na zarządzanie projektami/produktami IT pozwala na szybką reakcję na zmiany (Scrum i generalnie cały agile, lean oraz inne), niemniej jednak sama metodyka to nie wszystko.
Elastyczne założenia
Brzmi dziwnie, nieprawdaż? Podczas zbierania wymagań, trzeba zrobić założenia. Skoro to założenia to powinny być przecież stabilne! Praktyka brutalnie uczy, że założenia wyglądające jak skały tatrzańskie albo i nawet same Tatry także mogą zostać ruszone w rozumieniu zmienione (znacie powiedzenie o przenoszeniu gór? pasuje tu!). Myślę, że nawet założenia związane z teorią grawitacji mogą zostać podważone na gruncie IT ;)
Ok, co można zrobić aby oswoić zmianę?
Architektura - małe moduły/funkcjonalności którą są niezależne (na tyle ile to możliwe)
Plan - długoterminowe plany są ok, ale tylko gdy nie są zbyt szczegółowe. Długoterminowa wizja jest ważna, ale szczegółowy plan powinien być wytyczony tylko dla krótkiego okresu. Trzymanie się kurczowo planu długoterminowego, podczas gdy rzeczywistość się zmieniła, nie jest dobrym pomysłem (chyba że naszym celem jest dostarczenie bezużytecznego narzędzia).
Architektura - małe moduły/funkcjonalności którą są niezależne (na tyle ile to możliwe)
Plan - długoterminowe plany są ok, ale tylko gdy nie są zbyt szczegółowe. Długoterminowa wizja jest ważna, ale szczegółowy plan powinien być wytyczony tylko dla krótkiego okresu. Trzymanie się kurczowo planu długoterminowego, podczas gdy rzeczywistość się zmieniła, nie jest dobrym pomysłem (chyba że naszym celem jest dostarczenie bezużytecznego narzędzia).
Wymagania - bądź pewny że się zmienią w czasie. Napisz je tak aby umożliwiały nagłe zmiany (zwłaszcza w strategicznych obszarach).
Założenia - sprawdzaj od czasu do czasu czy się nie zmieniły. Niestety, do końca świata nie zostaną takie jak były na początku :(
Metodologia - nie jest to koniecznie Twoja brożka, ale jak możesz to wybierz taką która jest elastyczna, lekka i wspomagająca zmiany.
Założenia - sprawdzaj od czasu do czasu czy się nie zmieniły. Niestety, do końca świata nie zostaną takie jak były na początku :(
Metodologia - nie jest to koniecznie Twoja brożka, ale jak możesz to wybierz taką która jest elastyczna, lekka i wspomagająca zmiany.
Jest mnóstwo innych rzeczy pomagających adaptować się do zmiany: continuous delivery, continuous integration, całe mnóstwo metodyk testowania itp. Zatrzymam się jednak tu. Może kiedyś napiszę o tym z punktu widzenia analityka ;) Może być interesująco!
Pamiętaj! Do not underestimate the power of change!
Brak komentarzy:
Prześlij komentarz