Koniec z deadline'ami w developmencie

Dowożenie oprogramowania w wyznaczonym terminie to przepis na katastrofę, prawda? Dlaczego nadal to robimy? Już niedługo będziemy patrzeć wstecz i się śmiać z tego, że dawniej ustalaliśmy terminy dostarczania oprogramowania.

Nie mówię, że nowa norma pojawi się już jutro, ale to już powoli się dzieje. Mówię o “dostawie bezdatowej” (Dateless Delivery) - procesie, który nakazuje, aby technologia była gotowa, gdy będzie gotowa, a wszystkie inne części, w tym data uruchomienia, muszą być ruchome w kalendarzu z procesem rozwoju, a nie na odwrót.

Kiedy raz uświadomimy sobie, że oprogramowanie jest lepiej budowane bez wiszącej nad nim chmury terminów, już do nich nie wrócimy.

Argumenty za deadlinami

Zdaję sobie sprawę, że terminy mogą być konieczne, a nawet obowiązkowe. W moim ostatnim startupie, nie mogliśmy być bardziej uwiązani terminami. Mówię o Automated Insights, gdzie współtworzyłem oprogramowanie, które pisało treści o ludzkim brzmieniu na podstawie danych (NLG). 

Po kilku półpublicznych testach, naszą pierwszą prawdziwą pracą było pisanie podsumowań meczów dla Yahoo Fantasy Football. Działało to w ten sposób: poniedziałkowa noc piłki nożnej zakończyła się przed północą. Uzyskujemy wszystkie dane z Yahoo do 3:00 rano we wtorek. Musieliśmy wycisnąć dziesiątki milionów doskonale wykonanych podsumowań meczowych do 6:00 rano, czyli mniej więcej trzy godziny po otrzymaniu danych.

Tak więc nasze oprogramowanie miało bardzo mało czasu, by zmusić maszyny do obrobienia tego wszystkiego dziesiątki milionów razy i każdy wynik musiał przejść test albo bylibyśmy publicznie wypatroszeni przez ludzi, którzy - w wielu przypadkach - faktycznie nie mieli nic lepszego do roboty.

Było nas dwunastu. Nie spaliśmy. Było warto?

Całkowicie. To było właśnie to, co dało Automated bezpieczną pozycję w branży. Niecałe trzy lata później zostaliśmy wykupieni. A te podsumowania funkcjonują do dzisiaj.

Czy zrobiłbym to jeszcze raz? Tak, ale zupełnie inaczej. Technicznie rzecz biorąc, dotrzymywaliśmy wszystkich naszych terminów, ale przy dużych kosztach i z dużą ilością taśmy klejącej. Naszym błędem było zbudowanie całej złożoności przy pierwszym podsumowaniu w tydzień, a następnie spędzanie kolejnych 16 tygodni na naprawianiu i przerabianiu go. To, co powinniśmy byli zrobić, to zbudować bardzo podstawowe podsumowanie w pierwszym tygodniu, a następnie budować na nim resztę w miarę upływu sezonu.

To błąd w Agile, ale Agile go nie naprawi

W dawnych czasach, kiedy oprogramowanie nie było ukończone lub było słabo zbudowane, zazwyczaj po prostu się nie kompilowało. Albo zainstalowalibyśmy je i instalacja by się nie powiodła. Albo wrzucilibyśmy je do QA, a ono po prostu by nie zadziałało.

Postępy w dziedzinie języków, platform i technologii, całkowicie usunęły te subtelne oznaki zbliżającej się katastrofy. Agile sprawił, że możemy zrobić wszystko z wątłym buildem i iteracją z czegoś, co po prostu wiemy, że działa.

Aż pewnego razu nie zadziała. Wtedy wszystko pójdzie do diabła.

Nie zrozum mnie źle. Wierzę, że Agile jest świetny i tak właśnie powinno się budować oprogramowanie i produkt. Iteracyjnie. Problem polega na tym, że reszta organizacji rzadko działa iteracyjnie. Prostym rozwiązaniem jest zmuszenie wszystkich, w tym klientów, do pracy w agile, pisanym przez małe a.

Kwestionuj wszystko

Po wprowadzeniu pierwszego produktu na rynek, zacząłem kwestionować każdą następną datę wprowadzenia produktu na rynek. Możesz sobie wyobrazić, jak to popularny stałem się wśród klientów, ale trzymam się tej zasady do dziś. W zasadzie użyłem jej nawet ostatnio. "Dlaczego wybrałeś akurat te daty?"

Chcę wiedzieć, czym są czynniki nieruchome, bo poza czymś takim jak NFL i fantasy football i wszelkimi medialnymi pieniądzami z nimi związanymi, 9/10 odpowiedzi, które dostawałem, były niejasne i/lub całkiem elastyczne.

Marketing

Nie żyjemy już w świecie konsumentów, w którym budujemy produkt, a następnie płacimy jakiejś agencji wielocyfrową sumkę, aby przeprowadzili dla nas idealną kampanię telewizyjną i billboardową. Marketing jest dziś bardziej zautomatyzowany niż kiedykolwiek wcześniej i tym samym bardziej elastyczny.

Finansowanie

Używajmy tego terminu zarówno w odniesieniu do klientów z segmentu blockbuster, jak i dużego VCs. Ile jeszcze przerażających historii usłyszymy, gdzie klient/inwestor używa wagi swojej masywnej książeczki czekowej, aby naciskać na dostawę w określonym terminie, a następnie, kiedy zostaje dostarczony niekompletny produkt - zgadnij, kto musi brać za to odpowiedzialność?

Konkurencja

Apple nie stworzył pierwszego smartfona. Uber nie był pierwszą usługą carhailingową. Netflix nie był pierwszym serwisem filmowym. Tesla nie zbudowała pierwszego elektrycznego samochodu.

Na to wszystko mogę odpowiedzieć w taki sposób: Sprzedaż 10.000 działających jednostek produktu może często doprowadzić do sprzedaży 1.000.000 jednostek. Sprzedanie 100.000 niedziałających jednostek nie powiedzie się. Nigdy.

Wracamy więc do źródła problemu z trudnymi terminami. Rzuć mu wyzwanie i usuń go lub zredukuj zestaw funkcji w zależności od poziomu ryzyka, jakie ze sobą niesie. Następnie należy pozwolić, aby technologia przewodziła procesowi produkcji. Powtórz to sobie tyle razy, ile trzeba.

Pozostań Agile

Jak już mówiłem, bezterminowe dostarczanie oprogramowania nie rozpocznie się już jutro. I na pewno nie wzywam do zerowej odpowiedzialności za rozwój oprogramowania.

Zmierzam do bezterminowego dostarczania powoli, ponieważ myślę, że tak właśnie powinien wyglądać rozwój oprogramowania i zarządzanie produktem. Niektóre z pierwszych firm, które całkowicie zastosują się do Dateless Delivery, zapewne spalą się na tym, a niektóre z pierwszych osób, które sugerowały, że będzie to ryzykowne. powiedzą: "a nie mówiłem?".

Ale czy mi się wydaje, czy faktycznie widzimy coraz więcej przykładów wdrożeń technologicznych, w których technologia nie jest dostarczona w najwyższej jakości?

Spójrzmy na gry. Kiedy po raz ostatni dobra gra została dostarczona za pierwszym razem, zgodnie z terminem? A jeśli tak, to ile łatek potrzeba było, żeby warto było w nią grać?

Zdarza się to jeszcze częściej przy startupach. Byłem blisko firm, które poniosły bezpośrednią porażkę, ponieważ wprowadziły swój produkt zbyt wcześnie. Miał zbyt wiele bugów, zbyt wiele dziur w zabezpieczeniach, nie robił tego, co miało zrobić według opisu. 

Kiedyś było odwrotnie - gry i produkty oraz firmy zawodziły, ponieważ nie trafiły na rynek. Ale teraz jest tak łatwo dostać się na targ, że szala przechyliła się w drugą stronę.

Podsumowanie

Świat nie działa już na zasadzie terminów. Nie ma już premier w telewizji. Nie oglądamy filmów tylko w okresie letnim i świątecznym. Nowa muzyka nie wychodzi we wtorek. Ludzie nie są zaprogramowani, więc zdeprogramujmy sam produkt i wypuszczajmy go nie z hukiem, ale ze stałym, skoordynowanym ruchem.


Oryginał tekstu w języku angielskim przeczytasz tutaj.