„Tak Google tworzy strony docelowe. To standard branżowy.”
„Nie możemy dostarczyć tego wcześniej niż w sierpniu. Zsumowaliśmy nasze szacunki i wyszło nam sześć miesięcy.”
„Po prostu poczekaj dwa tygodnie na tę pilną poprawkę. Nie możemy przerwać sprintu, bo przestalibyśmy być zwinni.”
Każde z tych stwierdzeń to kłamstwo, które zespół techniczny mówi tobie — i samemu sobie. Te bardzo powszechne nieporozumienia wynikają z fundamentalnego błędu typowego dla inżynierów: przekonania o istnieniu „lepszego” rozwiązania.
Lepsze nie znaczy lepsze (dla każdego)
Wewnątrz komputera istnieje kraina jedynek i zer. Nie ma wątpliwości ani niepewności w arytmetyce i bramkach logicznych, a pomijając sporadyczne promieniowanie kosmiczne, maszyna jest całkowicie deterministyczna i za każdym razem podąża tą samą ścieżką, gdy dostarczysz jej te same dane wejściowe.
Nawet pozorna losowość w grach lub symulacjach jest w rzeczywistości iluzją. Jeśli podasz określone „ziarno pseudolosowe” na przykład w grze Minecraft, podczas każdej rozgrywki uzyskasz dokładnie takie samo zachowanie. Warto pamiętać, że każdy członek twojego zespołu IT wybrał zawód, który wiąże się z takim poziomem pewności i przewidywalności; wykonywanie ich pracy bez rygorystycznego rozumowania opartego na podstawowych zasadach jest dosłownie niemożliwe.
Ale poza obszarem obliczeń spotykamy nieprzewidywalnych ludzi i wszelkie założenia przestają obowiązywać. Żaden zespół sprzedażowy nawet nie rozważałby zastosowania tej samej prezentacji lub oferty wobec każdego potencjalnego klienta, a każda rozmowa z klientem w sprawie obsługi jest inna i zaskakująca. Skrypty i szkolenia pomagają pracownikom zachować spójność, oczywiście, ale kluczowe jest dostosowanie podejścia do każdej sytuacji — przekonało się o tym wiele organizacji, gdy próbowały przyjąć holakrację lub metody odchudzone na wzór sukcesu firm Zappos i Toyota, ponosząc całkowitą porażkę.
Jest to równie prawdziwe w tworzeniu oprogramowania, jak w działalności operacyjnej, finansach czy strategii: nie ma jednego właściwego sposobu zaprojektowania ekranu logowania, stworzenia raportu ani odkrycia, za jakie funkcje klienci będą skłonni zapłacić. Dlatego inżynierowie opracowali oszałamiającą różnorodność metodyk tworzenia oprogramowania, takich jak Scrum, Kanban, ShapeUp, model Spotify, SAfE i setki innych — wszystkie skuteczne w niektórych przypadkach i katastrofalne w innych.
Teraz możesz zrozumieć, dlaczego my, ludzie z branży technologicznej, padamy ofiarą pułapki lepszego rozwiązania. Każdy z nas uznałby za atrakcyjną wiarę, że gdzieś istnieje kamienna tablica z wyrytym rozwiązaniem naszych problemów, ale pewność jest niebezpiecznie kusząca, gdy na co dzień pracujesz z narzędziami i maszynami, których działanie zależy od absolutnej spójności. Jak jednak przełamać nawyk myślenia binarnego?
Po pierwsze, nieustannie zadawaj pytania
Dla tak wielu z nas technologia to po prostu czarna magia. Inżynierowie mamroczą dziwne zaklęcia o Kubernetesie, zettabajtach, a znikąd pojawiają się strony internetowe, e-maile i płatności kartą kredytową. Kiedy więc czarodzieje z autorytetem mówią nam, że stosują „najlepsze praktyki”, kim jesteśmy, żeby w nich wątpić?
Odpowiedź brzmi: TY! Podobnie jak wszyscy inni członkowie zespołu, twórcy oprogramowania potrzebują informacji zwrotnej na temat tego, czy ich plany i dostarczane rozwiązania są zgodne ze strategią firmy. Nie musisz używać żargonu technicznego, aby przekazywać swoje reakcje i wskazówki; to ich zadanie, aby dowiedzieć się wystarczająco dużo o twoim rynku i celach, by móc skutecznie odpowiadać przed tobą, posługując się standardowym językiem. Nie bój się zadawać wszelkich pytań dotyczących tego, co ustalają jako priorytet, powodów wyboru tej czy innej technologii, a zwłaszcza tego, jak według nich skorzysta na tym reszta firmy.
Tak mocno wierzę w zadawanie pytań, że wydrukowałem eleganckie certyfikaty ze złoceniami, udzielające oficjalnego pozwolenia na pytanie inżynierów o absolutnie dowolny temat, i wręczam je przy każdej możliwej okazji. Poniżej znajduje się przykład. Jeśli chcesz mieć taki na swojej ścianie, napisz do mnie, a wyślę ci jeden (bezpłatnie!)
Następnie zagraj w grę „dlaczego?”
Gdy pokonasz strach przed zadawaniem pytań i dowiesz się więcej o podejściu swojego zespołu technicznego, czas zagrać w grę „dlaczego?”. Zasady są proste i znane każdemu pięciolatkowi: najpierw pytasz, co robi programista, a następnie wielokrotnie pytasz „dlaczego”.
„Zastępuję naszą stronę płatności.”
„Dlaczego?”
„Bo jest nieefektywna.”
„Dlaczego jest nieefektywna?”
„Wykonujemy zbędne kontrole, które wydłużają czas naszej reakcji.”
„Dlaczego szybkość ma znaczenie?”
„Bo użytkownicy rezygnują, gdy muszą zbyt długo czekać na dokonanie płatności.”
Sygnałem do zakończenia jest moment, gdy dochodzisz do pieniędzy. Gdy usłyszysz: „ponieważ zwiększy to konwersje”, „ponieważ więcej klientów przejdzie na wyższy plan” lub „ponieważ obniżymy koszty badań”, wygrywasz. Jeśli nigdy do tego nie dojdziesz i zakończysz słowami „Nie wiem” lub „bo Jane tak powiedziała”, to ty, a nie inżynier, przegrywasz grę o „dlaczego”. Szukaj sposobów na znacznie ściślejsze powiązanie zespołu technicznego z wynikami biznesowymi, aby następnym razem wszyscy byli zwycięzcami.
Po kilku rundach pytań „dlaczego” zaczniesz dostrzegać wzorce i luki. Na przykład pracowałem z jednym zespołem, który był całkowicie skoncentrowany na zwiększaniu współczynnika konwersji, ale zupełnie ignorował koszty. Nic dziwnego, że znacznie przekroczyli budżet przez nadmiernie zoptymalizowane strategie reklam społecznościowych, które były zdecydowanie zbyt skomplikowane jak na prostą kampanię bożonarodzeniową.
Owszem, ich złożone algorytmy były „lepsze” w uzyskiwaniu niewielkiej przewagi cenowej dla określonych słów kluczowych, ale rachunek za Facebooka był brutalnym zderzeniem z rzeczywistością, gdy nadszedł (uwzględniał nawet opłaty za faktyczne przeciążenie niektórych serwerów reklamowych facebook.com zbyt dużą liczbą żądań!). Gdy dostrzegasz takie martwe punkty, skoryguj priorytety, anuluj to, co niepotrzebne, i wzmocnij przekaz, że technologia musi być ściśle dopasowana do celów biznesowych.
Na koniec zadbaj o odpowiedzialność
Teraz, gdy znalazłeś i wyeliminowałeś „lepsze” rozwiązania technologiczne, które w rzeczywistości ci nie służą, zapewnij inżynierom proste sposoby na pokazanie, że pozostają zgodni z celami i podążają właściwą ścieżką. Zauważ, że nie wspomniałem o „pociąganiu zespołu technicznego do odpowiedzialności” — takim podejściu polegającym na wskazywaniu winnych, które zawsze sprawia, że mam ochotę schować się pod najbliższym biurkiem. Zamiast tego umożliw deweloperom ponoszenie odpowiedzialności przed tobą. Na przykład:
- Planuj cotygodniową prezentację usprawnień IT, podczas której liderzy zespołów będą opisywać korzyści biznesowe i zbierać uwagi od ciebie oraz innych osób.
- Skonfiguruj pulpit nawigacyjny pokazujący ważne wskaźniki, takie jak dostępność systemu czy liczba odebranych połączeń, i często proś deweloperów o wyjaśnienie, w jaki sposób ich działania poprawiają wyniki.
- Utwórz ścieżkę realizacji do śledzenia postępów w kluczowych projektach i szybkiego odzyskiwania tempa, gdy realizacja kluczowych elementów się opóźnia.
Jasna strategia częstego zbierania informacji zwrotnych i koncentracja na rzeczywistych, namacalnych korzyściach biznesowych zagwarantują, że wydatki na IT nie zostaną zmarnowane na sprytne, lecz bezużyteczne „lepsze” projekty. A jeśli ty, podobnie jak większość firm, z którymi pracuję, inwestujesz w technologie miliony, a rezultaty są co najwyżej niejasne, czyż nie warto mierzyć zwrotu z tej ogromnej inwestycji?
Zasubskrybuj biuletyn The CTO Club, aby otrzymywać więcej porad od naszej społeczności.
