Praca w IT

Zmień inżynierów we właścicieli produktów. Kilka lekcji z migracji

lekcje z migracji

My, inżynierzy, lubimy migrować rzeczy. Ciągle udoskonalać, by produkt, nad którym pracujemy stał się “dziełem”. Jest w nas jakieś przeświadczenie, że jesteśmy lepsi od poprzedników. Poprzedni inżynierzy byli źli, a my jesteśmy dobrzy. Co więcej, Biznes nie zatrzymuje się, potrzebuje kolejnych funkcji. Klienci uwielbiają szczególnie te, których nie potrzebują.

Po 5-7 latach pracy rozumiemy, jak dobrze zbilansowaliśmy rozwój swojego produktu. Produkt z kolei odpowie na pytanie, czy „pasuje do rynku”.

Jeśli jednak produkt nie spodoba się użytkownikom, będziesz miał pięć opcji:

  1. Produkt nie jest potrzebny. Wycofaj go, jeśli po latach widać, że koszty przewyższają zyski, brak stabilnego wzrostu liczby użytkowników czy zysków.
  2. Produkt jest potrzebny. Przy braku wymaganych umiejętności, zatrudnij wyspecjalizowane osoby do pomocy.
  3. Produkt jest potrzebny. Zbuduj nowy produkt. Wymaga to inwestycji z góry i zmiany priorytetów. Jest duża szansa, że to co zrobiłeś zostanie wyrzucone do kosza, trzeba również przygotować na to zespoły.
  4. Zostań tam, gdzie jesteś i rób to co zawsze mając nadzieję na poprawę.
  5. Spróbuj sprzedać produkt. Jest to możliwe, gdy adaptacja zajmie dekady i wymaga ogromnych nakładów środków przez najbliższe 10-20 lat. Przykładem jest Cisco i kupno StrataCom. Obecnie znane jako inwestycje długoterminowe i sprzedaż firmy na części.

Utrzymuj koszty operacyjne na niskim poziomie

Kiedy poprosisz 1000 menedżerów o cięcie kosztów, większość zdecyduje się wyłączyć produkty używane przez klientów lub zwolnić ludzi. Reszta będzie próbowała znaleźć podejście do optymalizacji bez podejmowania nieodwracalnych decyzji.

Cięcie kosztów kojarzymy ze zmniejszeniem wydatków, by przy niższych przychodach wydawać mniej. Częściej jednak chodzi o to, jak wykorzystać mózgi ludzi i upewnić się, że robią właściwe rzeczy.

1. Jak często dostarczasz na produkcję? 3 tygodnie? Dużo pracy ręcznej?

Zautomatyzuj proces aż do produkcji po merge’u. Jeśli potrzeba, zmień politykę firmy, w której pracujesz. Zmień podejście swoich inżynierów we właścicieli produktów. Spowoduje to dużo bólu, ale na dłuższą metę nie będziesz musiał wstawać tak często o trzeciej w nocy.

Po zmianie produkt zaczął dostarczać na produkcję 30 razy więcej. Rzeczywisty popyt był jeszcze większy i istniały możliwości poprawy. Przestoje, które kosztowały 1300 dolarów za minutę, nie były spowodowane przez juniorów, ale wypaczony proces.

2. Jak często aktualizujesz i sprawdzasz swoje zależności? Ile ich masz?

Każda zależność może powodować problemy, ale niektóre są konieczne. Najbardziej niebezpieczne są zależności zewnętrzne lub krytyczne.

Wybierając GCP masz dużą szansę, że następnego dnia Google porzuci wybrany przez Ciebie produkt. Uwielbiam AWS za jego obsesję na punkcie klientów. Dzięki podejściu „cloud-agnostic” możesz spać jeszcze lepiej.

Produkt zbudowałeś na AngularJS i .NET Framework. Google porzucił AngularJS. Firma Microsoft poprosiła Cię o aktualizację .NET Framework z wersji 4.6.1 do 4.6.2 i dała Ci ponad 5 lat. Zdefiniuj miesięczne zadania dla inżynierów w celu aktualizacji zależności. Jeśli którakolwiek z nich wymaga łącznie ponad trzech tygodni pracy w ciągu roku, czas rozważyć rozstanie.

Twój produkt zależy od produktów wewnętrznych udostępniających interfejsy API. Upewnij się, że masz umowy w formie papierowej lub e-mailowej. Ktoś może zdecydować się na zmianę priorytetów lub zapytać, kto to finansuje.

Firma zbudowała produkty przy użyciu tylko Javy, ale nowi inżynierowie zdecydowali się wykorzystać w nowych produktach Pythona, C#, Go i zupełnie nową bazę danych blockchain! Nie rekomenduję tego podejścia. Skuteczne organizacje są nudne i korzystają z jednego zestawu narzędzi. Możesz dodać coś nowego, gdy jest to krytyczne dla wsparcia organizacji lub jej rozwoju.

Czy wysłałeś produkt Proof Of Concept na produkcję?

Jeśli w ciągu najbliższych sześciu miesięcy zabijesz swój produkt, bo jego celem jest zgromadzenie wiedzy, nie ma w tym nic złego. Wysyłaj szybko, nie przejmuj się kodem niskiej jakości. Przetestuj rynek i technologię, a kiedy uzyskasz dopasowanie do rynku, wyrzuć produkt do kosza i zacznij od nowa we właściwy sposób.

Oznaki, że robisz to w niewłaściwy sposób:

  1. Stosujesz zupełnie nowe technologie, których jeszcze nie użyłeś w swojej organizacji.
  2. Produkt zbudowany przez juniorów bez Seniora/Principala, który wie, jak to zrobić dobrze.
  3. Miało to zająć sześć miesięcy, a zajęło dwadzieścia miesięcy.
  4. Zbudowany przez błyskotliwą osobę, która nie chce pracować w zespole.

Za mało inwestycji w Developer Experience

Developer Experience (DevEx) definiuje techniki pomiaru produktywności. Nie musisz posiadać rozległej wiedzy z zakresu psychologii i czytać artykuły naukowe, by poprawnie mierzyć produktywność. Chodzi o to, jak inżynierowie postrzegają ją. Jeśli rozwiążesz problem, ale inżynierowie nie uznają go za rozwiązany, oznacza to, że nie rozwiązałeś problemu. DevEx pomaga lepiej postrzegać łatwość dostarczania oprogramowania, zaangażowanie, satysfakcję i zmniejszyć wypalenie zawodowe.

Organizacje często korzystają z DevOps/SRE i zespołów platformowych, aby zredukować te problemy. Często jednak widzę, że te zespoły budują rozwiązania dla siebie, a nie inżynierów. Inżynierowie nie zdają sobie sprawy, że to rozwiąże ich problemy. Czasami nawet trudno jest im wdrożyć takie rozwiązania.

Odziedziczyłem kiedyś produkt, który liczył trzy zespoły. Ze względu na odejścia posiadałem tylko połowę personelu. Pracownicy firmy postrzegali produkt ten jako „strefę zakazaną”. Z tego względu, pozostał w tyle. Nie było wsparcia, bo była to dla firmy nowa technologia nawet po czterech latach. Skupiłem się na tym, by zmienić to podejście. Po roku ponad 10 produktów chciało do nas dołączyć, ponieważ widzieli rozwiązania swoich problemów. Jednym z takich rozwiązań był wspomniany powyżej proces dostarczania.

Szeptana strategia to też strategia

Bez strategii wszystko jest możliwe. Najgorszy rodzaj strategii to ta, której uczysz się rozmawiając z ludźmi. Nie mając celu sami go znajdują lub zaczynają narzekać. Piękno narzekania leży w tym, że jak dobrze się wsłuchasz to jesteś w stanie dostrzec faktyczne priorytety. Mózg, kiedy mu zależy stara się z tym walczyć, co dla wielu kończy się wypaleniem zawodowym przez brak rozwiązywania tychże problemów.

Można narzekać na brak strategii. Lepiej jednak być pierwszym, który napisze propozycję planu strategicznego i poprosi o opinię. Najwyżej podejmiecie decyzję o wyrzuceniu jej do kosza. W najlepszym razie możesz zmienić trajektorię firmy we właściwym kierunku.

Pracowałem dla klienta, który uporczywie próbował znaleźć 10% redukcji kosztów infrastruktury. Największe inicjatywy optymalizowały kilkaset tysięcy dolarów a trzeba było znaleźć kilka milionów.

Wykonując swoją migrację rozmawiałem z ludźmi na różnych poziomach, ot tak, aby ich poznać. W rok udało mi się zebrać wystarczająco danych, aby zaproponować inicjatywy optymalizujące koszty o ponad dwa miliony dolarów plus kilka milionów do odzyskania w ramach redukcji pracy manualnej. To był ten moment, kiedy kilku dyrektorów i principali zarządzający ponad 300 osobami z dnia na dzień zmieniła swoje priorytety.

Zdrowie jest ważniejsze niż terminy

Ludzie są jak serwery produkcyjne, gdy przez cały czas pracują na poziomie ponad 70% swojej wydajności. Kiedy umrze wystarczająca liczba serwerów krytycznych, będziesz na pamięć znał definicję awarii kaskadowej, bez otwierania Wikipedii.

W takiej sytuacji stres pozytywny zamieni się w stres negatywny, który spowoduje niższą produktywność i problemy zdrowotne. Ludzie to nie kontenery, które można odtworzyć. Powinieneś zrobić wszystko, by każdy z zespołu był jak gepard. Skup się na jednym biegu, aby upolować ofiarę. Pozostały czas wykorzystaj na regenerację.

Pracowałem kiedyś z inżynierem z zewnętrznego zespołu, nazwijmy go Mateusz. Mateusz dokonał zmiany w bibliotece SDK, która uszkodziła serializację i deserializację JSON. Nikt nie mógł wywołać naszych interfejsów API a musieliśmy się upewnić, że te biblioteki działają zgodnie z oczekiwaniami.

Mateusz chciał to naprawić, ale był chory. Przekonałem go, żeby wrócił do domu i wyzdrowiał. Zrobiłem to, bo mogłem przetestować mechanizmy odtwarzania po awarii i plany sukcesji. Poza tym było to słuszne postępowanie.

Mój inżynier rozwiązał problem. Uzgodniłem z Principal Software Engineerem Mateusza, że będzie on stosował nasze standardy kontroli jakości. Przyspieszyło to pętlę informacji zwrotnej i bezpieczeństwo. Gdy Mateusz wyzdrowiał, bardzo chciał pracować nad tą inicjatywą.

Ludzie mogą zamknąć laptopy i wyjść z pracy, ale praca ich nie opuści. Sztuka polega na tym, aby odciąć mentalne korzenie swoim ludziom, aby mogli zregenerować się i nie myśleć o pracy.

Firmy zwalniają nawet wybitnych i kompetentnych ludzi

Pozytywna polityka, taka jak możliwość wywierania wpływu i robienia właściwych rzeczy, ma kluczowe znaczenie. Negatywna polityka, gdy pracujesz w bardzo nieprzyjaznym środowisku, jest czymś, co powinieneś nienawidzić. Jeśli należysz do tej drugiej organizacji, uciekaj, dopóki nie podejmiesz wyzwania posprzątania domu.

Praca z byłym wiceprezesem Amazona pozwoliła mi zrozumieć moje słabości. Zrozumiałem też, dlaczego dyrektor generalny zwolnił mojego dyrektora. Zbudował całą organizację 10 lat temu i wszyscy go lubili. Prezes zwolnił go po migracji, która zablokowała rozwój na 5 miesięcy. Nigdy nie miał dobrego Executive Presence. Nowy dyrektor nie obdarzył go zaufaniem i samodzielnie kierował organizacją. Kiedy rozmawiałem z ludźmi, stworzyło to więcej problemów i spaliło wiele mostów w branży.

Migracja była konieczna, ponieważ po ponad 20 latach tworzenia oprogramowania, do drzwi “zapukały” duże braki kadrowe spowodowane brakiem pieniędzy i dług techniczny. Usłyszałem w głowie wtedy: „Spłacisz dług albo po raz ostatni widzisz swoją produkcję…”

Kiedy musisz wybierać pomiędzy utrzymaniem a utrzymaniem nie ma miejsca na dodanie wartości. Przyniesie ona odwrotny skutek, przez co oberwiesz rykoszetem.

Aby osiągnąć ten cel przy mniejszym dramatyzmie, konieczne były inwestycje z góry w inicjatywy dotyczące platformy. Jedynymi osobami zwolnionymi w tej organizacji był on i ja, ponieważ „moja praca nie była krytyczna”. Cztery lata później firma nadal korzysta z fundamentów stworzonych przeze mnie, na których opiera się ponad 200 usług i ponad 40 produktów.

Bądź pozytywny!

W Polsce mówimy bez przekleństw:

„To jasne, że jesteśmy w piekle. Problem w tym, że zaczynamy się tu osiedlać.”

Migracje są trudne jak życie. Dlatego otaczaj się pozytywnymi ludźmi i unikaj tych z negatywnym nastawieniem.

Ostatnią rzeczą, o której powinieneś pamiętać, jest to, że dobrze się bawiłeś z ludźmi, z którymi lubiłeś pracować. Więcej tego nie zrobisz, ale k… było warto!


Artykuł został pierwotnie opublikowany na xeinaemm.substack.com. Grafika główna artykułu pochodzi z envato.com.

Inżynier oprogramowania skupiony na budowaniu skalowalnych fundamentów produktów i poprawie produktywności programistów. Jego celem osobistym jest optymalizacja organizacji, w których chce się pracować, z wykorzystaniem psychologii.

Podobne artykuły