Adaptacja do nowych warunków środowiska to nieodłączny element życia wszelkich gatunków fauny i flory. Programiści nie są w tym wypadku żadnym wyjątkiem, w końcu nasza codzienność jest obarczona nieustannym podążaniem za nowościami technologicznymi. Nauka nowych języków, frameworków czy poszerzanie wiedzy domenowej jest dla nas jak najbardziej naturalna. Dlaczego więc zmiany dotyczące sfer niezwiązanych z technikaliami tak bardzo wpływają na naszą pracę?
Zmiany w projektach to chleb powszedni programisty. Zmieniają się wymagania, terminy wydań, dokumentacja czy technologia. Rozumiemy to doskonale, szczególnie ci pracujący na co dzień w metodologiach zwinnych. Powszechny niepokój budzą natomiast zmiany zachodzące w obszarach niezwiązanych bezpośrednio z wytwarzaniem oprogramowania. Choć najczęściej nie dotykają one programistów w dużym stopniu, to potrafią spowodować niemałe zamieszanie w strukturach firmy.
Weźmy pierwszy z brzegu przykład. Korporacja postanawia wprowadzić nową strukturę organizacyjną zespołów, orientując ją na szybsze wytwarzanie projektów kosztem utrzymania dotychczasowej platformy. Z punktu widzenia zarządu zmiana ta przyniesie zwiększoną intensyfikację wytwarzania oprogramowania. Wystarczy „tylko” jakoś zadbać o architekturę kodu i sprawa załatwiona, ale tylko teoretycznie. Pozostaje jeszcze przegrupować zespoły tak, by w każdym z nich znalazł się specjalista z najważniejszych obszarów projektu i można grzać silniki oraz poinformować pracowników o zachodzącej zmianie.
Oczywistym jest fakt, że nie wszystkim ten nowy pomysł się spodoba – niektórzy zdążyli już zżyć się z innymi członkami zespołu, lecz przyjmijmy, że miękkie zagadnienia z pogranicza psychologii i informatyki uznamy za statystycznie nieistotne. Rozsądnym rozwiązaniem będzie uruchomienie menadżerów liniowych do przekazania nowiny działowi w taki sposób, by podwładni zaakceptowali pomysł i przyjęli jako odpowiedź na ich problemy. Wyjście w pierwszej kolejności od odpowiedzi „dlaczego?”, zamiast „jak?” lub „co?” daje przewagę w postaci uprzedniej argumentacji, a niezadowolonym malkontentom wytrąca oręż niezrozumienia sensu jakiejkolwiek zmiany. Za Simonem Sinekiem, autorem książki „Start with Why”: Ludzie nie kupują tego co robisz; kupują to, dlaczego to robisz. Unaocznienie powodów transformacji pozwoli pozyskać oddolne wsparcie i ugruntować pomysł, który zostanie przyjęty lepiej, niż narzucona, mglista wizja top managementu.
Restrukturyzacja, niezależnie od dziedziny, w jakiej jest przeprowadzana, powinna zostać przeprowadzona wychodząc od przejrzystego celu, do jakiego zmierza organizacja. Na pytanie „dlaczego?” odpowiedzi należy szukać w misji firmy. Jeśli dana firma nie odpowiada na pytanie, dlaczego przeprowadza zmiany, można zakładać, że nie wie, jaki jest główny cel jej istnienia. Stwierdzenie to jest dość radykalne, lecz zadane z poziomu szeregowego pracownika przybiera na sile. Skoro ci na górze nie potrafią wytłumaczyć powodów zmiany, być może w ogóle nie rozumieją sensu mojej pracy? Powstaje zatem pytanie: kto na daną zmianę okazuje się nieprzygotowany – programista czy firma?