Gdy byłem młody, w mojej okolicy zbudowano szpital. Był on łatwo dostępny i świadczył doskonałe usługi. Z upływem lat szpital rozrastał się o nowe kliniki i oferował dodatkowe usługi. Żeby umożliwić ten rozwój, obiekt został drastycznie zmieniony, aby umożliwić postawienie budynków i parkingów. Teraz są tam wąskie drogi dojazdowe, ograniczenia dotyczące parkowania oraz obszary zablokowane barykadami z cementu. Podczas dostaw nowego sprzętu, co zdarzyło się kiedyś, gdy tam byłem, główne ulice przejazdowe były zablokowane w trakcie rozładowywania ciężarówek przez pracowników. Lubię ten szpital, ale korzystanie z niego stało się przykrym doznaniem.
Na przestrzeni lat doświadczyłem tego samego efektu z oprogramowaniem, w którym projektowałem obwody drukowane. Miałem zestaw narzędzi, z którymi dobrze mi się pracowało, a potem te narzędzia kupiła inna firma i wplotła je w istniejący zestaw narzędzi nowego dostawcy. Wkrótce pojawiły się nowe cechy i funkcje wbudowane w narzędzia, żeby umożliwić łączenie starych narzędzi z innymi systemami oferowanymi przez dostawcę oprogramowania. Rozwój jest dobry, ale utrata łatwości i funkcjonalności, do których przywykłem, na rzecz stania się „mega” zestawem narzędzi, była dla mnie bezproduktywna. Masz podobne doświadczenia? Jeśli tak, to dalsza część artykułu prawdopodobnie będzie brzmieć znajomo.
Przejęcie oprogramowania do projektowania przez inną firmę softwarową często jest motywowane chęcią wypełnienia luk we własnej gamie narzędzi. Jest to dość powszechne zjawisko, jednak może przyprawić o ból głowy użytkowników oryginalnych narzędzi. Wkrótce nowe wersje narzędzia zawierają nowe funkcje, żeby wpisać dane narzędzie w funkcjonalność narzędzi firmy dominującej. Jeśli takie funkcje nie są nam wcale potrzebne albo po prostu nam się nie podobają, jesteśmy skazani na to, że nasze ulubione narzędzia podążają w niepożądanym przez nas kierunku.
Zazwyczaj oznacza to zmiany interfejsów użytkownika, z którymi pracowaliśmy przez wiele lat. Często takie zmiany są z początku niewielkie, ale z czasem stają się coraz bardziej ogromne. Niejednokrotnie słyszałem od inżynierów wdrożeniowych, że nie ma się czego obawiać, bo fuzja nie wpłynie na podstawową funkcjonalność moich ulubionych narzędzi. Ale kilka miesięcy później wszystko zaczyna się zmieniać i ja również muszę się zmienić, żeby dotrzymać kroku.
W chwilach kryzysu nikt nie chce się martwić zmianami narzędzi do projektowania
Podrażnienia wynikającego z konieczności opanowania swojego ulubionego narzędzia softwarowego od podstaw w ogóle nie da się porównać z nieskrywanym gniewem, jaki czułem, gdy narzędzia przestawały być takie jak przedtem. Czasami narzędzia naprawdę ulegały awarii w przypadku problemu z kompatybilnością między starymi narzędziami a nowym systemem. Po kilku iteracjach poprawek błędów i aktualizacjach oprogramowania często problemy były niwelowane, jednak nie obywało się bez bólu związanego z koniecznością wdrożenia dodatkowych procesów przekształceń lub innych działań zastępczych. Prostota poprzedniego procesu projektowania często zostaje utracona, gdy trzeba zmusić stare narzędzia do pracy w nowym systemie.
Czasami kierunek obrany przez dostawcę nowego oprogramowania rozbijał mój proces projektowania. W pewnym momencie mojej kariery pracowałem nad zestawem narzędzi do projektowania przejętych przez innego dostawcę, który włączył ich funkcjonalność do swoich istniejących narzędzi. Podczas szkolenia dotyczącego korzystania z wymienionych narzędzi zapytałem instruktora, dlaczego pewien proces manipulowania ekranem przestał być dostępny. Jego odpowiedź była zdumiewająca: „dlaczego w ogóle chciałbyś robić to w tamten sposób, skoro nasz sposób jest lepszy?”. Najwyraźniej dostawca nowego oprogramowania nie przejmował się zbytnio ogromną rzeszą użytkowników, którzy byli przyzwyczajeni do określonego sposobu pracy w środowisku projektowania i po prostu go wyeliminował. Jak mówią: jeśli coś nie jest zepsute, nie naprawiaj tego.