Jak zaczęliśmy udostępniać funkcje dwa razy szybciej (studium przypadku)

Gdy firmy polegają na Twojej aplikacji w codziennej pracy, musisz być wystarczająco zwinny, aby szybko zaspokajać ich potrzeby. Jeśli nie, inni na pewno to zrobią. W bezlitosnym świecie SaaS opóźnianie krytycznej funkcji (lub pospieszanie kodu z błędami) oznacza utratę klientów. Solidny, zwinny przepływ pracy może wiele zmienić.

Jesteśmy zespołem odpowiedzialnym za Active Collab , aplikację do zarządzania projektami z ciągle rosnącym zestawem funkcji i sporą bazą użytkowników. Oznacza to, że nawet najmniejsza zmiana funkcjonalności wpłynie na dużą liczbę osób.

Dalsze czytanie na SmashingMag:

• Jak wprowadzać nowe funkcje bez szkody dla lojalnych użytkowników?
• Lista kontrolna uruchamiania strony internetowej – 15 niezbędnych kontroli przed uruchomieniem
• Skoncentrowane na użytkowniku podejście do projektowania stron internetowych na urządzenia mobilne
• Jak cokolwiek uruchomić
  

Dlatego proces rozwoju musi przebiegać płynnie i do standardu, z opóźnieniami zredukowanymi do minimum. Zanim jakakolwiek zmiana trafi do użytkownika końcowego, przechodzi przez pięć kluczowych faz: informacje zwrotne, projektowanie, rozwój, zapewnienie jakości i wdrożenie . W tym artykule podzielę się tym, czego nauczyliśmy się (w trudny sposób) o każdym z etapów przez ponad osiem lat w branży.

Pobudka

Zanim przejdę do szczegółów, spójrzmy, jak do tego wszystkiego doszło. Po latach dodawania funkcji bez wystarczającej kontroli nasza aplikacja cierpiała z powodu rozrostu funkcji. Przez lata dodaliśmy tak wiele funkcji, że nowi użytkownicy byli przestraszeni samą złożonością interfejsu (nigdy już nie wracali). Wiedzieliśmy, że musimy przebudować od podstaw, nawet jeśli oznaczało to przepisanie każdej funkcji od zera.

Potem przyszły opóźnienia. Funkcje nowych wersji były stale opóźnione. Na przykład młodszy programista miał opracować integrację z QuickBooks. Nie przewidzieliśmy dokładnie wymaganej złożoności, umiejętności lub wiedzy. Poza tym był jedynym przydzielonym do tego zadania i nikt nie mógł szybko wskoczyć mu z pomocą. W rezultacie to, co miało być dwutygodniową pracą, skończyło się na pięciu. To było kilka czerwonych flag.

Najwyraźniej nadszedł czas, aby przejść na bardziej zwinne podejście. Wzięliśmy to, co nam się podobało, z różnych zwinnych (i nie tak zwinnych) metod, połączyliśmy to z doświadczeniem i wymyśliliśmy własną wersję, która od tamtej pory przynosi świetne rezultaty.

Przyjrzyjmy się bliżej drodze, jaką musi pokonać funkcja, zanim zostanie zaoferowana użytkownikowi końcowemu.

Od sugestii do funkcji

W naszym przepływie pracy nowa funkcja zaczyna nabierać kształtu na długo przed dotarciem do zespołu programistów i zwykle rodzi się z opinii użytkowników. To nie przypadek — kiedyś udostępnialiśmy funkcje, których nikt nie potrzebował, zwykle tylko dlatego, że jeden użytkownik był szczególnie głośny lub po prostu uznaliśmy, że warto mieć coś fajnego. Zamiast wyobrażać sobie, jakich funkcji mogą potrzebować nasi użytkownicy, podejmujemy teraz decyzje w oparciu o rzeczywiste zapotrzebowanie.

Jeśli interesuje Cię szczupła produkcja, powiedziałbyś, że nasi klienci „wyciągają” pewne funkcje , żądając ich częściej niż inne. Nasze zespoły wsparcia i sprzedaży stanowią dużą część tego procesu, ponieważ są w stałym kontakcie z użytkownikami, którzy dzielą się swoimi potrzebami i pomysłami.

Na podstawie opinii nasze zespoły aktualizują formularz, który wygląda tak:

Gdy nie mamy wszystkich potrzebnych nam informacji, skontaktujemy się bezpośrednio z klientami. Odbywa się to zwykle za pomocą ukierunkowanych ankiet na starannie dobranej próbie. Chodzi o to, że słuchamy. Żadna informacja zwrotna na nas nie zostanie utracona. Jest to zawsze potwierdzone i udokumentowane.

Następnym krokiem jest analiza. Każdego miesiąca podliczamy wyniki, aby zobaczyć, która funkcja uzyskała najwięcej głosów. Ponadto dzięki odpowiedniej kategoryzacji uzyskujemy szerszą perspektywę na to, które części naszego oprogramowania muszą działać. Na przykład, jeśli kalendarz otrzymuje wiele skarg, rozważymy przeróbkę całej sekcji, zamiast wprowadzać funkcję, która uzyskała najwięcej głosów (np. eksport kalendarza).

Jednak nawet po uzyskaniu wyników decyzja o wprowadzeniu funkcji nie jest ostateczna. Zanim trafi na naszą listę rzeczy do zrobienia, zawsze przeprowadzamy dokładną kontrolę zdrowia psychicznego:

• Jakie korzyści przyniesie ta funkcja dla użytkowników?
• Czy pasuje do naszej filozofii produktu?
• Czy doda niepotrzebnej komplikacji?
• Czy ładnie komponuje się z istniejącym interfejsem i funkcjonalnością?
• Czy mamy zasoby, aby dostarczyć go w rozsądnych ramach czasowych?

Gdy funkcja przejdzie przez listę kontrolną, a właściciele produktu ją zatwierdzą, nadszedł czas, aby przejść do deski kreślarskiej.

Projektowanie dla użytkownika

Doświadczenie nauczyło nas, że dodanie nowej funkcji nie oznacza tylko umieszczenia jej na wierzchu interfejsu użytkownika — musisz połączyć ją z istniejącym projektem, z myślą o użytkowniku. Jeśli tego nie zrobisz, wkrótce otrzymasz aplikację tak złożoną, że tylko nieliczni odważni przetrwają pierwsze pięć minut okresu próbnego (tak, już tam byliśmy). Estetyka jest również ważna dla dobrego pierwszego wrażenia, ale naszą główną troską jest łatwość użytkowania . Funkcję należy dodać w sposób naturalny dla użytkownika.

Zachowujemy perspektywę, pytając, gdzie użytkownik oczekiwałby tej opcji?

Dla istniejących użytkowników ważne jest, aby nowy projekt był zgodny ze znanymi im wzorcami i nie zakłócał ich przepływu pracy. Ponadto istnieją branżowe standardy i konwencje, do których wszyscy (podświadomie) jesteśmy przyzwyczajeni. Nigdy nie oczekuj, że Twoi użytkownicy całkowicie zmienią swoje nawyki. Bardziej prawdopodobne jest, że będą szukać gdzie indziej, jeśli interfejs nie jest intuicyjny.

Korzystaj ze skrótów klawiaturowych. Możesz stworzyć własny zestaw skrótów i oczekiwać, że użytkownicy się ich nauczą (prawdopodobnie nie będą). Możesz też dodać te, z których ludzie już korzystają. Wielu naszych użytkowników korzysta już na przykład ze Slacka, więc dodaliśmy skrót, który już znają ( Command + K do szybkich skoków działa również w Active Collab ).

Gdy przepływy użytkowników są już na miejscu, nasz projektant UX makiety projektu w Sketch. Rzadko używamy HTML na wczesnych etapach. Dobrze przemyślane wizualizacje Sketch dają nam wystarczającą elastyczność, że nie musimy cofać się, kiedy zaczynamy kodować. Wstępny projekt zwykle kończy się dopasowaniem około 80% produktu końcowego. Reszta jest dodawana i dostosowywana po drodze.

Kolejnym ważnym etapem procesu projektowania jest kopiowanie. Nasi copywriterzy poświęcają wiele uwagi każdemu słowu. Mamy nawet własny przewodnik po stylu, który ma brzmieć jak najbardziej przystępnie i być tak łatwym do zrozumienia, jak to tylko możliwe. Na przykład, powiedzenie „certyfikat bezpieczeństwa” zamiast „certyfikat SSL” oznacza w sposób laikowy coś, z czym przeciętny użytkownik może nie być zaznajomiony.

Gdy to wszystko zostanie zrobione, funkcja zostanie przypisana do zespołu programistów. Zespół składa się z kierownika projektu, głównego programisty oraz wielu programistów back-end i front-end, w zależności od obciążenia pracą. Kierownik projektu dba o to, aby wszystko przebiegało sprawnie i zgodnie z harmonogramem, podczas gdy główny programista dba o techniczną stronę rzeczy. Zajmują się również koordynacją i mentoringiem młodszych programistów.

Czas na kopnięcie

Nasze spotkania inauguracyjne nie są nudnymi spotkaniami motywacyjnymi. Są okazją dla zespołu programistycznego (składającego się z młodszych i starszych programistów) do spotkania się z kierownikiem projektu i właścicielem produktu.

Zamiast pozwalać na puste monologi, skupiamy się na przekładaniu słów wszystkich na zadania, które można wykonać. W ciągu dnia odbywają się trzy ważne spotkania :

• Właściciel produktu przedstawia zespołowi daną funkcję, stojące za nią pomysły, wstępne projekty i oczekiwane rezultaty.
• Następnie zespół ma własne spotkanie, na którym omawia plan działania, potencjalne problemy i harmonogram testów.
• W ostatnim spotkaniu biorą udział wszyscy zaangażowani, a plan nabiera ostatecznego kształtu. Pod koniec tego spotkania zespół podaje szacunkowe dane dotyczące dem i ostateczny termin wykonania.

Trzy spotkania mogą wydawać się dużo na jeden dzień, ale w ten sposób upewniamy się, że problemy są rozwiązywane na wczesnym etapie. Wypełnianie pustych miejsc na tym etapie oszczędza naszym programistom dużo czasu, falstartów i cofania się. Spotkania zachęcają również do pracy zespołowej i sprawiają, że wszyscy czują, że ich wkład jest mile widziany.

Po spotkaniach zespół będzie posiadał wszystkie niezbędne informacje:

1. Co? Jest to zakres funkcji i obejmuje wszystko, co należy zrobić, a także potencjalne blokady i wąskie gardła. Staramy się przewidywać jak najwięcej scenariuszy i przypadków brzegowych. Przewidywanie ich wszystkich nie jest łatwe; często pojawiają się, gdy idziemy.
2. Czemu? Właściciel produktu szacuje wartość biznesową funkcji i wyjaśnia, dlaczego warto podjąć wysiłek. W ten sposób zespół uzyskuje jasny obraz korzyści dla klientów i produktu. Głównym motywatorem jest tutaj to, że każdy powinien zrozumieć, dlaczego jego praca ma znaczenie i jaki wkład wnosi do firmy jako całości.
3. W jaki sposób? Przedstawiając kroki wymagane do ukończenia funkcji , upewniamy się, że nasi programiści nigdy nie zgubią kompasu. Ustalamy również realistyczne oczekiwania, dodając znacznik złożoności. Wybraliśmy rozmiary t-shirtów — S można rozwiązać w ciągu kilku godzin, a ukończenie XXL zajmuje tygodnie lub więcej.
4. Kto? Lider zespołu jest odpowiedzialny za zakończenie funkcji lub zadania na czas oraz za aktualizowanie właściciela produktu na temat postępów. Inni członkowie zespołu są przypisani do własnego zestawu podzadań, dzięki czemu jest całkowicie jasne, kto jest za co odpowiedzialny. Zapewnienie jak największej przejrzystości informacji pomaga nam zobaczyć, czy ktoś ma problemy lub powoduje opóźnienia.
5. Gdy? Biorąc wszystko pod uwagę, szacowany jest termin płatności . Jeśli zadanie jest opóźnione, analizujemy przyczyny i wykorzystujemy to doświadczenie następnym razem. W ten sposób niedotrzymany termin staje się okazją do nauki, a nie źródłem stresu.

Dzień rozpoczęcia może być gorączkowy, ale jest też bardzo owocny. Wszyscy zgłaszają się z pomysłami i komentarzami. Zadanie przekształca się z pustej planszy w centrum komentarzy, edycji i aktualizacji. Pod koniec dnia zespół programistów ma jasny obraz przyszłej pracy i solidne podstawy, na których można budować.

Przechodzimy przez tę listę kontrolną przed rozpoczęciem pracy:

• wyjaśniona funkcja,
• opisane kroki do realizacji,
• wartość biznesowa przypisana przez właściciela produktu,
• złożoność przypisana przez zespół,
• zidentyfikowane zależności funkcji i błędów,
• zidentyfikowane kryteria wydajności (w razie potrzeby),
• zaplanowane dema,
• daty rozpoczęcia i zakończenia ustalone przez lidera zespołu.

W tym momencie zadanie przechodzi do kolumny „W toku”.

Czas na kodowanie!

Praca zespołowa na wyświetlaczu

Nasi programiści nigdy nie pracują sami — zawsze jest to wysiłek zespołowy i jest to zdecydowanie najskuteczniejszy sposób na udostępnianie nowych funkcji. Przed wprowadzeniem zespołów (młodszy) programista utknął z problemem i mógł kręcić się w kółko przez wiele dni (nikomu o tym nie uświadamiając). Albo, gdyby nie byli typem samotnika, nieustannie rozpraszaliby współpracowników i menedżerów.

Z drugiej strony w zespołach łączymy ludzi o różnych zestawach umiejętności i poziomach doświadczenia. Oznacza to, że każdemu przydzielany jest zestaw zadań odpowiedni do jego poziomu. Ponadto seniorzy czerpią korzyści z nauki zarządzania młodszymi kolegami z drużyny i trenowania ich — a juniorzy mogą prosić o pomoc. Ponieważ jest to wysiłek zespołowy i wszyscy dążą do tego samego celu, pytania nie są uważane za rozpraszające, a zespół może znacznie skuteczniej rozwiązywać każdy problem. Zespół staje się samoorganizującą się całością, dzieląc pracę na fazy (lub sprinty) i prezentując swoją pracę podczas demonstracji.

Pokaż i powiedz

Zgodnie z harmonogramem zespół przeprowadzi demo dla właściciela produktu. Celem demonstracji jest pokazanie, jak dobrze dana funkcja działa w obecnym stanie i gdzie wymaga dopracowania. To sprawdzenie rzeczywistości, które nie pozwala na wymówki typu: „Wystarczy tylko kilka wykończeń” (poprawki, które zajęłyby kolejny miesiąc). Ponadto, jeśli sprawy przybierają zły obrót, właściciele produktów mogą szybko reagować.

Cotygodniowe Spotkania

Zaczęliśmy od regularnych, codziennych, krótkich spotkań, w których uczestniczyli wszyscy deweloperzy. Każdy programista pokrótce opisałby, nad czym pracował, jakie ma problemy, jakie środki blokuje i czy potrzebuje pomocy. Szybko stało się oczywiste, że te spotkania muszą być bardziej skoncentrowane i przynosić wymierne rezultaty. Przeszliśmy więc na spotkania z poszczególnymi zespołami mniej więcej raz w tygodniu. W ten sposób właściciele produktu i kierownik projektu są na bieżąco, a wszelkie potencjalne problemy rozwiązywane są na miejscu.

Przeprowadzanie tego na próbę

Kod jest napisany, dema zakończyły się sukcesem, wszystko wydaje się ładnie się układać… dopóki nie zwolnisz funkcji i nie zobaczysz, że aplikacja się zawiesza. Dlatego każda wykonywana przez nas funkcja przechodzi kontrolę jakości (Q/A). Zawsze. Nasz tester skrupulatnie przechodzi przez każdy możliwy scenariusz, sprawdzając wszystkie opcje i przeprowadzając testy w różnych środowiskach. Funkcja rzadko przechodzi przez pytania i odpowiedzi za pierwszym razem.

Aby zwiększyć produktywność, pozwalaliśmy programistom na rozpoczęcie pracy nad nowymi funkcjami w tej fazie, ale to spowodowało wiele opóźnionych, w połowie ukończonych funkcji. Tak więc teraz zespół programistów jest zajęty pracą nad małymi zadaniami konserwacyjnymi, podczas gdy ich funkcja jest sprawdzana. Jeśli Q/A znajdzie problem, programiści natychmiast go naprawiają i przesyłają ponownie. Proces jest powtarzany, dopóki funkcja nie przejdzie pytań i odpowiedzi i przejdzie do przeglądu kodu.

To wtedy starszy programista upewnia się, że kod jest napisany zgodnie z naszymi standardami. Ostatnim krokiem przed wydaniem jest napisanie dokumentacji — nie chcesz zostać zasypany e-mailami wsparcia po wydaniu funkcji, której nikt nie wie, jak używać. Nasi copywriterzy aktualizują również informacje o wydaniu i piszą materiały marketingowe, takie jak ogłoszenia e-mail i wpisy na blogu.

Oto nasza definicja „gotowego”:

• napisane autotesty,
• wykonane Q/A i wszystkie wynikające z tego zadania zakończone,
• przegląd kodu wykonany i kod scalony z masterem,
• zaktualizowane informacje o wydaniu,
• zidentyfikowane zależności funkcji i błędów.

Zadanie osiągnęło ostatni etap, zwany „Wydanie Q”.

Dzień wydania

Wybierając dzień dla nowych wydań, od razu zdecydowaliśmy się zrezygnować z piątku i poniedziałku. Piątek nie jest dobry, ponieważ wszelkie potencjalne problemy zostaną rozwiązane dopiero w poniedziałek; plus, zespół wsparcia był już wtedy dość zajęty. Poniedziałek nie jest najlepszym czasem, ponieważ każda większa aktualizacja wymaga przygotowania, które musiałoby się odbyć w weekend. Zawsze dobrze jest zostawić dzień na ostatnie poprawki. To zawęża opcje do trzech dni — i wybraliśmy wtorek. Dlatego:

• Mamy poniedziałek, aby przejrzeć wersję i dodać ostatnie poprawki przed wdrożeniem.
• Jeśli są jakieś nieprzetłumaczone frazy (nasza aplikacja internetowa jest dostępna w siedmiu językach), mamy wystarczająco dużo czasu, aby dokończyć tłumaczenie.
• Zespół marketingowy ma mnóstwo czasu na rozsyłanie biuletynów i ogłoszeń za pośrednictwem mediów społecznościowych.
• Jesteśmy dostępni, aby szybko i wydajnie zapewnić wsparcie w zakresie aktualizacji przez resztę tygodnia.
• Jeśli z jakiegokolwiek powodu minął termin, nadal mamy środę lub czwartek na zakończenie pracy.

Dzień bezpłatnej aktywności

Dzień po premierze to dzień wolny dla zespołu. To wtedy uczą się nowych umiejętności lub robią cokolwiek związanego z pracą, co ich interesuje. Mimo że wszyscy chcą wiedzieć, którą funkcję rozpoczniemy następnego dnia, zespół jeszcze o tym nie rozmawia. Zamiast tego zrelaksują się i może obejrzą prezentację na temat historii Erlanga lub dokończą czytanie tego artykułu o tym, dlaczego PSR-7 i oprogramowanie pośredniczące są ważne dla współczesnego rozwoju PHP, albo przeprowadzą własną retrospektywną dyskusję. To zasłużony dzień na naładowanie baterii i świętowanie dobrze wykonanej pracy.

Dzień polowania na robaki

Oprócz opracowywania głównych nowych funkcji, zawsze trzeba pracować nad już istniejącymi. Niezależnie od tego, czy jest to poprawka błędu, aktualizacja projektu, czy niewielka zmiana funkcjonalności, zespół musi się tym zająć w rozsądnym czasie.

Dlatego przynajmniej raz w miesiącu organizujemy dni polowania na robaki. To wtedy wszyscy programiści przestają pracować nad swoimi głównymi projektami i zwracają uwagę na utrzymanie. Ten skoncentrowany wysiłek okazał się wielkim sukcesem. Kiedy wszyscy tego samego dnia pracują wyłącznie nad błędami i są gotowi sobie nawzajem pomóc, zespół rozwiązuje ogromną liczbę problemów.

Jaki jest wynik?

Wydanie dużej funkcji zajmuje teraz średnio około trzech tygodni, od rozpoczęcia do rozwoju, testowania, przeglądu kodu, dokumentacji i ostatecznego wydania. Cecha o równoważnej złożoności zajmowała nam 45 dni. Z naszej perspektywy oznacza to wzrost produktywności o 100% . Osiągnęliśmy to przy użyciu tych samych zasobów i ludzi, jedyną różnicą jest usprawniony przepływ pracy.

Tak więc, jeśli mamy dla Ciebie jeden wniosek, to jest to: pielęgnowanie kultury firmy, która eliminuje strach przed zmianami, sprawi, że Twój zespół będzie lepszy w tym, co robi. Nie ma znaczenia, czy nazwiesz to Scrum, Kanban czy Lean, o ile pomaga to Twojej firmie się rozwijać. Eksperymenty i innowacje leżą u podstaw każdego zwinnego podejścia. Nie bój się testować różnych rozwiązań, mierzyć wyniki i na podstawie wyników modyfikować istniejące praktyki. Przyjdą dobre wyniki.