Często widzę taki problem w ramach projektowania rozwiązania:
- Dyskutujemy nad opcjami. Rozważamy kilku potencjalnych kandydatów.
- Określamy, jak duże zyski przyniesie każda z opcji.
- Zwykle wygrywa ta, która daje najwięcej i najszybciej.
Nikogo nie powinna dziwić taka kolej rzeczy, przecież oczywistym jest, że najchętniej będziemy się angażować w działania, których rezultaty szybko zobaczymy.
Jednak tu właśnie tkwi pułapka, w którą wpada wiele zespołów.
Problemy jednowymiarowego zysku
Zacznijmy od życiowej analogii. Ile razy mieliście tak, że kupowaliście sobie słodycze, aby zaspokoić chwilową zachciankę? Nie raz, prawda? Kolorowe opakowanie, obietnica słodkiego smaku i sztuczki sklepowych marketerów dopadły chyba każdego. No a szybki dopływ endorfin sprawia, że od razu żyje się lepiej. 😃
Na takie same pokusy możemy natrafić w procesie tworzenia oprogramowania. Tu pójdziemy na skróty, tam zrobimy takiego szybkiego fixa i od razu może lecieć na produkcję. PM i zespół zadowoleni, a my możemy brać się za kolejnego taska.
Takie rozwiązanie w krótkiej perspektywie wydaje się zyskowne. Ale patrząc bardziej długoterminowo:
- Jedzenie słodyczy tuczy niemiłosiernie.
- Wszystkie „ścięte rogi" mocno obniżają jakość produktu.
Kończymy z otyłością i systemem, którego nie da się utrzymywać.
Jak temu zaradzić?
Macierz zysków
Rozwiązaniem, które polecam zespołom, z którymi współpracuję, jest analiza zysków (i strat) w dwóch wymiarach:
- Krótkofalowym
- Długofalowym
Na takiej macierzy umieszczamy potencjalne propozycje. Następnie analizujemy, jak dana zmiana wpłynie na produkt.
Na tej podstawie możemy przeanalizować wprowadzoną zmianę po kątem tego, czy nie wygeneruje jednak większej ilości problemów niż rozwiązań.
Przykład
Weźmy na tapet dosyć typowy problem „Gdzie trzymać klucze do usług w naszym produkcie?".
Najprostszą i najszybszą opcją jest:
Trzymajmy to w kodzie. Tam developerzy mogą od razu je zmieniać.
Działa? Działa. 😃 Przynajmniej na początku. W dłuższej perspektywie będzie to wyglądało tak:
Patrząc w przyszłość widzimy więc następujące problemy:
- Pracownicy z dostępem do repozytorium kodu mają dostęp do wszystkich kluczy.
- Trudno jest zarządzać jaki klucz należy do jakiego środowiska (DEV, TEST, PROD).
- Wersjonowanie kluczy jest utrudnione.
Możemy się zastanowić nad innymi, być może lepszymi, opcjami:
- Klucze w bazie.
- Klucze w CI/CD.
- Brak kluczy – korzystamy z IAM.
Nasza macierz zmieni się wtedy następująco:
- Klucze w bazie – Nie dość, że trzeba teraz robić dodatkową strukturę, to długofalowo jest to trudno zarządzalne.
- Klucze w CI/CD – Możemy wykorzystać gotowe opcje od dostawcy i to się fajnie skaluje per produkty. Ale trzeba się tego nauczyć korzystać więc koszt początkowy istnieje.
- Brak kluczy IAM – Ta opcja pozwala w ogóle nie wrzucać kluczy, więc jeśli tylko jest taka opcja to czemu z tego nie skorzystać? 🤔
Widzimy szerzej wpływ każdej z opcji na produkt i możemy wybrać taką, z której będziemy zadowoleni zarówno teraz, jak i za rok.
Potencjalne wykorzystanie
W omawianym scenariuszu wykorzystujemy macierz do polepszenia jakości dyskusji technicznej w zespole. Nie jest to jednak jej jedyne zastosowanie:
- Spotkania wewnątrz zespołu — rozmowy na linii Dev / Test / PM o wpływie funkcji na produkt.
- Spotkania z interesariuszami —przekonywanie, jak „szybka" zmiana wpłynie na jakość produktu.
- Kwartalne spotkania OKR – wybór najlepszej funkcji do spełnienia założonych celów.
W każdej sytuacji, w której chcecie spojrzeć szerzej na wpływ danej zmiany na rozwiązanie, warto wyciągać macierz zysków i przeanalizować konsekwencje w szerszej perspektywie.
