Lekcje i antylekcje od Elona Muska
Dzisiaj bierzemy na tapet najnowszą biografię Elona Muska (tak, są dwie😅). Na nasze, inżynierskie potrzeby odrzucimy całą politykę i zastanowimy się, jakie lekcje i antylekcje o tworzeniu produktów cyfrowych możemy wyciągnąć z książki.
Czego z biografii Muska nauczy się inżynier?
Elon Musk jest postacią bardzo kontrowersyjną. Z jednej strony ma za sobą szereg z sukcesem zrealizowanych inicjatyw, z Teslą i SpaceX na czele. Z drugiej — olbrzymie dramy, chaotyczne zarządzanie dawnym Twitterem (a aktualnie platformą X) i pociąg do ideologii alt-right. Ale to wszystko niewiele ma wspólnego z naszymi obowiązkami. Także dziś kwestie światopoglądowe zostawimy na boku, skupiając się na tym, z czego faktycznie możemy skorzystać.
Zajmiemy się więc dziś tym, co możesz jako lider lub inżynier, wyciągnąć z biografii Elona Muska. W tym celu przygotowałem dla Ciebie kilka lekcji i antylekcji, które możesz zastosować w rozwoju swojego produktu. Żeby nie być gołosłownym, postaram się również przytoczyć adekwatne cytaty z książki. Może będzie to dla Ciebie kolejna zachęta by sięgnąć po książkę?😃 Bo jednak, koniec końców, myślę, że warto.
Uwaga: Celowo nie będę tutaj przytaczał w całości często pojawiającego się protokołu Elona. Dlaczego? W mojej opinii przynajmniej część porad nie jest w najmniejszym stopniu aplikowalna do rzeczywistości produktów cyfrowych. Więc nam, inżynierom może narobić więcej problemów niż zysków.
Lekcja – Role zespołowe muszą ściśle ze sobą współpracować
W ramach każdej wdrażanej inicjatywy Elon Musk kładł nacisk na to, by nie doprowadzać do dużych podziałów pomiędzy rolami pracującymi w ramach projektu.
Instead, engineers would team up with product managers. It was a philosophy that he would carry through to Tesla, SpaceX, and then Twitter. Separating the design of a product from its engineering was a recipe for dysfunction. Designers had to feel the immediate pain if something they devised was hard to engineer.
Taka współpraca pozwoliła szybko zauważać problemy, które wynikają z połączenia wymagań różnych ról. To natomiast przekładało się na proaktywną kooperację i deeskalację problemów w zarodku.
Jak pracować lepiej?
Ogromne straty w pracy na systemem wynikają często z braku współpracy pomiędzy rolami produktowymi : inżynierowie, graficy, produktowcy, specjaliści od bezpieczeństwa itd. Przykładowo, jeśli graficy zaprojektują bardzo złożone makiety, łatwo się domyślić że te będą niesamowicie czasochłonne i trudne do dowiezienia z perspektywy programistów. Z drugiej strony, inżynierowie tworzą czasem rozwiązania, które są całkowicie nie do zaakceptowania ze względów bezpieczeństwa. Wtedy najczęściej kończymy z:
Ogromnymi opóźnieniami przez robienie perfekcyjnych rzeczy niepotrzebnych naszym klientom.
Zwrotkami do początku procesu, co skutkuje stratami tego co już zostało dowiezione.
Dzieje się tak, ponieważ brakuje pętli zwrotnej, która skupi wszystkie role dookoła rzeczywistych możliwości pracy. Dużo o tym opowiada John Cutler w artykule Developer & Designer Collaboration, czy Maciej Wyrodek w prezentacji o Shift Left.
Antylekcja – Nie rozróżniaj decyzji odwracalnych od permanentnych
Chociaż większość z naszych decyzji można w miarę bezproblemowo zmienić, to jednak część z nich będzie nieodwracalna. Należy wiedzieć, jak je rozróżniać. Niestety spostrzeżenie to umknęło Muskowi, który przez swoją brawurę, o tym nie pomyślał. I kupił Twittera po cenie, która wyszła z luźno rzuconego żartu.
They had come up with a proposed share price to offer: $54.20. Musk and Birchall laughed, because it again played into the internet slang for marijuana.
His lawyers finally convinced him at the end of September that he would lose the case if they took it to trial. It was best just to close the deal on the original terms, $54.20 a share, $44 billion in total.
Luźno rzucona kwota przeistoczyła się następnie w wymóg kupienia Twittera po stawce zdecydowanie powyżej rynkowej.
Jak pracować lepiej?
Więcej rozsądku wykazała w tej kwestii inna znana postać z branży – Jeff Bezos. Znany jest jego list do interesariuszy, w którym pisze o odwracalnych decyzjach.
Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors.
Musimy zauważać, kiedy podejmujemy decyzje, które są nieodwracalne. I wtedy:
albo analizujemy mocno naszą decyzję, aby nie popełnić błędu,
albo staramy się zmodyfikować naszą decyzję, aby jej konsekwencje były mniej dotkliwe
Kiedy może się to przekładać na twoją pracę? Między innymi w takich sytuacjach:
Migracja do chmury — Przed wykonaniem pełnej migracji, warto przeprowadzić testy wydajności rozwiązania. Często sprawdzenie małych elementów pokazuje, jak różnią się deklarowane możliwości i faktyczna wydajność.
Wybór usługodawców — Jeśli podpisujesz kontrakt na daną usługę, to warto, byś najpierw zbudował Proof of Concept. Sprawdzając uprzednio możliwości, będziesz w stanie podjąć lepszą decyzję.
Wybór bazy danych — Nie dokonuj wyboru na początku projektu, kiedy jeszcze niewiele wiesz o otoczeniu biznesowym. Lub zastosuj opcję, którą można szybko zmienić się w inną (np. jakiś Low-Code).
Lekcja - Testuj założenia (i obalaj, kiedy jesteś w stanie)
Pomimo disclaimera — jeden aspekt protokołu Elona to jednak poruszymy 😉 Chociaż nieco od innej strony.
Pierwszą zasadą, którą Musk stosuje, jest usuwanie niepotrzebnych wymagań:
Question every requirement, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.
Musk took an iterative approach to design. Rockets and engines would be quickly prototyped, tested, blown up, revised, and tried again, until finally something worked. “It’s not how well you avoid problems,” “It’s how fast you figure out what the problem is and fix it.”
Wiele z projektów Elona wypaliło tylko dlatego, że sprawdzał, czy założenia, na których opierały się inne osoby, są prawdziwe. Ktoś mówił, że wymagane jest X, a Elon mówił „zrób bez X i sprawdź". I w części przypadków okazywało się, że jednak da się bez X.
Jak pracować lepiej?
Terresa Torres uczy nas, że istnieje 5 rodzajów założeń, jakie możemy poczynić tworząc produkt:
Desirability — Dlaczego nasi klienci chcą tego rozwiązania? Na jakiej podstawie uważamy, że będą skłonni zrobić to, czego od nich wymagamy, aby uzyskać z tego wartość?
Viability — Czy rozwiązanie będzie korzystne dla naszej firmy? Czy przyniesie zyski?
Feasibility — Czy damy radę zbudować to rozwiązanie? Czy poszczególne części są możliwe do wykonania? Czy tego w ogóle potrzebujemy?
Usability — Dlaczego, naszym zdaniem, klient będzie mógł skorzystać z tego rozwiązania?
Ethical — Czy budowanie tego rozwiązania wiąże się z jakąkolwiek potencjalną szkodliwością?
Każde z założeń buduje następnie wymagania, które chcemy wbudowywać w system. A jeśli założenia nie są prawdziwe, to również wymagania nie są aktualne.
Dlatego w naszej pracy ważne jest definiowanie tego, co faktycznie jest wymaganiem, a co jedynie założeniem, a następnie szybkie walidowanie tych założeń i tego, czy naprawdę są potrzebne. W efekcie nie dostarczamy naszym klientom rozwiązań nadmiernie, a wręcz bezsensownie złożonych.
Antylekcja – Automatyzuj wszystko jak leci
Dobrze jest automatyzować nasze zadania. Problemem pojawia się, gdy automatyzujemy coś, co nie jest stabilne.
Musk came to the same realization, he had in Nevada about the perils of pursuing automation too relentlessly.
Musk took responsibility for the over-automation. He even announced it publicly. “Excessive automation at Tesla was a mistake,” he tweeted. “To be precise, my mistake. Humans are underrated.”
Zautomatyzowano niestabilne procesy. Przez co nie udało się osiągnąć zysku w postaci zmniejszenia czasu produkcji. A koszty zostały poniesione.
Jak pracować lepiej?
W ramach automatyzacji i wykorzystywania gotowych rozwiązań warto sobie zadać pytania:
Jak często to wykonujemy?
Jaką to ma wariancje? Ile jest różnych przypadków brzegowych?
Jak często zmienia się proces? Jak mocno się zmienia?
Jaki jest koszt automatyzacji?
Jaki co się stanie, gdy się pomylimy?
Jak dobrze rozumiemy automatyzowany proces?
Do pomocy może nam przyjść Cynefin Framework ze swoim spojrzeniem na rodzaje problemów:
W przypadku problemów po lewej stronie, trudno znaleźć sensowne scenariusze automatyzacji, kiedy rzeczy, które robimy dopiero się kształtują.
To nam pozwala zauważyć sytuacje w których nie będziemy automatyzować, bądź stworzymy semi-automatyzację. Czyli czasem tylko część procesu będzie zautomatyzowana. Ta, którą faktycznie da się zautomatyzować.
I zwróćcie uwagę, że mówię to ja, mając w pamięci jak kiedyś przez 3 dni pracowałem nad automatyzacją procesu uruchamianego raz w miesiącu, na 15 minut. 😬
Lekcja – Skupiaj się na małych wygranych
Rakiety Elona Muska były znane z wagi diametralnie lżejszej od tych produkowanych przez konkurencję. Jednak, aby to osiągnąć, Elon nie wprowadzał żadnych przełomowych zmian w konstrukcji. Zamiast tego stosował stopniowe okrajanie :
Musk obsessed over reducing the weight of his rockets. That has a multiplier effect: removing a bit of weight—by deleting a part, using a lighter material, making simpler welds—results in less fuel needed, which further reduces the mass the engines have to lift.
Za pomocą wprowadzania wielu pozornie nieistotnych zmian w coraz to kolejnych miejscach, ostatecznie udało się nieporównywalnie zwiększyć efektywność rakiet.
Jak pracować lepiej?
Żeby pracować efektywniej, nie musisz od razu wprowadzać olbrzymich rewolucji. Wystarczy, że zauważysz, w których aspektach jesteś najmniej efektywny i co można w związku z tym zoptymalizować.
W naszym świecie inżynierskim może być to na przykład:
Boy Scout Rule — praktyka zostawiania swojego kodu, lub miejsca pracy w nieco lepszym stanie, niż poprzednio.
Unikanie strat procesowych — związanych z pracą osób, takich jak zwrotki do poprzednich etapów pracy, np. poprzez asynchroniczny code review.
Unikanie strat technicznych — związanych z błędnie wykorzystywanymi technologiami np. błędogenny pipeline CI/CD, dziurawy monitoring.
Efektywna praca lokalna — opisany i powtarzalny proces uruchamiania i debugowania systemu
Wprowadzanie drobnych standardów — np. lintery pozwalają uniknąć kłótni „taby vs spacje".
Przestrzeń na usprawnienia — by każdy czuł, że ma chociaż te 5% czasu na wdrażanie usprawnień, a nie tylko „gonienie króliczka".
Każde z powyższych usprawnień może przyczynić się do poprawy tylko o kilka procent. Niewiele? Jeśli wdrożysz takich zmian odpowiednio dużo, to nagle na twój sukces zaczyna pracować magia procentu składanego. I niespodziewanie twój zespół dowozi o połowę szybciej, chociaż w teorii nie zmieniło się „prawie" nic 😃.
Antylekcja – Nie wdrażaj stopniowo
W ramach zmian na Twitterze, Elona Muska ewidentnie zawiodło bazowanie na doświadczeniach ze świata fabryk. Tuż po zakupie platformy, szybko wdrożył nowy znacznik Twitter Blue. I w mgnieniu oka zaczęły się ataki botów:
When Twitter Blue began rolling out on the morning of Wednesday, November 9, the impersonation problem was as bad as Musk and Roth had feared. There was a tsunami of fake accounts with blue checks pretending to be famous politicians and, worse yet, big advertisers.
Fabryka działa inaczej niż produkt cyfrowy:
Jeśli zmienisz coś w fabryce, to problemy da się jeszcze naprawić, zanim produkt wyjedzie do klienta.
Jeśli zmienisz coś w produkcie cyfrowym, to klienci natychmiastowo to odczują.
W naszym świecie należy wdrażać stopniowo.
Jak pracować lepiej?
Zakładając, że masz produkt na produkcji, masz też X klientów**. Zawsze (no, w 99% przypadków) można rozpocząć od wdrożenia zmiany w produkcie dla 1/10, 1/100 czy nawet 1/1000 000 użytkowników.**
W roku 2023 mamy do dyspozycji szeroki wachlarz praktyk i narzędzi dookoła stopniowego wdrażania. Możesz je wykorzystać, aby przetestować rozwiązanie na mniejszej grupie docelowej i dopiero w następnej kolejności skalować szerzej.
Canary Deployment – wdrażanie nowych funkcji tylko dla części klientów.
A/B testing – pokazywanie różnych scenariuszy klientom, by badać ich zachowania.
Experiment Feature Toggles – flagi umożliwiające testowanie na żywo różnych scenariuszy systemowych.
Dark Launch – wdrażanie funkcji tak, by była niewidoczna dla zwykłych użytkowników.
Dzięki czemu przekonasz się, czy funkcja działa odpowiednio na produkcji oraz czy nie ma żadnych outlinerów.
Podsumowanie
To tylko kilka lekcji i antylekcji, które można wyciągnąć z biografi Elona Muska. Niezależnie od Twojego podejścia do miliardera, zachęcam Cię by zapoznać się z książką chociażby po to, by samemu wyciągnąć kilka lekcji.
Może akurat coś Cię zainspiruje?