Yammer: Tradycyjna struktura firm deweloperskich jest martwa

Kris Gale, wiceprezes ds. inzynierii w Yammerze, twierdzi, ze male zespoly sa kluczem do szybkiego tworzenia produktow w wiekszych firmach. Bada subtelnosci budowania organizacji w programowaniu i wyjasnia, jak swiadome podejmowanie decyzji w fazie wzrostu moze zapewnic, ze nie zostana utracone rzeczy, ktore sprawiaja, ze startup jest wyjatkowy i szczegolny. Ostatecznie zadaniem dyrektora technicznego jest zastanowienie sie, jak mozna zorganizowac i zoptymalizowac tworzenie oprogramowania.

Male zespoly dostarczaja szybciej

Na poczatku zespol Yammer przyjal dosc proste podejscie. Skupial sie glownie na samym produkcie i nie zastanawial sie zbytnio nad obsada personalna podczas rozrostu organizacji. Gdy firma rosla coraz bardziej, zauwazyly jednak, ze kracowy wzrost wydajnosci przy kazdym nowym deweloperie malal z powodu wiekszego nakladu pracy.

Jednoczesnie reszcie swiata stalo sie jasne, ze Yammer tworzyl cos wielkiego. Wszedie startupy probowaly skopiowac produkt, a nawet duze firmy wprowadzaly na rynek produkty konkurencyjne. W Yammerze zdawano sobie sprawe, ze moze byc tylko jedna dominujaca firma i ze bedzie to inna, jesli nie beda wystarczajaco zwinnymi. Nowoczesne aplikacje webowe musza byc zwinne i adaptowalne.

Aby szybciej dostarczac, w Yammerze przyje to podejscie pracy z malymi zespolami. Ale to oznacza wiecej niz tylko podzielenie firmy na male zespoly. Jesli te zespoly sa w jakikolwiek sposob ograniczone we wdrazaniu kodu, sa bezuzyteczne. Musza miec swobode wykonywania zadan takze poza organizacja.

Specjalizacja w malych zespolach

Na samym poczatku nowe funkcje w Yammerze byly rozdzielane miedzy trzech deweloperow wedlug specjalizacji. Nie bylo to jednak nic sztywnego. Gdy bylo duzo pracy z Railsami, Gale mogl troche pomoc, nawet jesli Rails nie byl jego mocna strona. Celem mialo byc tworzenie podobnych grup, ktore sa male i wyspecjalizowane, ale nie sa czystymi silosami, bo rozne problemy wymagaja roznych kompetencji (i roznych doswiadczen).

Procesy szeregowe i duze firmy technologiczne

To podejscie sprawdzalo sie naprawde dobrze przy trzech deweloperach. Gdy zespol Yammer rosna l, przeszli jednak do bardziej tradycyjnego modelu dla organizacji w programowaniu, w ktorym nastapil podzial wedlug umiejetnosci technicznych. Byl wiec zespol back-end, zespol front-end, zespol mobile itd. Pod koniec 2010 roku nad funkcjami pracowalo juz nie trzech, lecz okolo 30 deweloperow. Ale czy byli dziesiecia razy szybsi? Nie.

Zgodnie z prawem Amdahla o rownoleglym wykonywaniu programow, przyspieszenie programu przy uzyciu wielu procesorow jest ograniczone przede wszystkim przez szeregowa czesc problemu [poniewaz czasu jej wykonania nie mozna skrocic przez rownoleglizacje]. Np.: jesli masz program, z ktorego mozesz zrownoleglnic tylko polowe, mozesz podwoic predkosc nawet przy 100 procesorach. Nawet przy kolejnych 100 procesorach niewiele by sie to zmienilo. Czas szeregowej czesci calkowitego nakladu pracy pozostaje wiec zawsze taki sam.

Ludzie blednie zakladaja, ze w programowaniu kod jest pisany wedlug specyfikacji – ale tak nie jest. Decyzje techniczne sa rowniez bardzo wazne – i nikt nie moze zbudowac firmy deweloperskiej, jesli w to wierzy.

W typowej sredniej do duzej organizacji programistycznej mozna miec zespol front-end, zespol back-end i ewentualnie zespol middleware. Te zespoly maja wlasna baze kodu i wlasnego menedzera, ktory raportuje do przelozonego. Chodzi o to, ze organizacja i architektura kodu powinny do siebie pasowac.

Zanim przywodcy beda mogli rozdzielic i delego wac prace, musza najpierw zdecydowac, co dokladnie ma byc zbudowane. Potem pojawiaja sie takie pytania: „Nad czym bedzie pracowac zespol back-end?" i „Jak to polaczyc z zespolem front-end?"

Jednak gdy prace sa, jak wlasnie opisano, podzielane i delegowane przez wyzsze szczeble kierownictwa, cos idzie zle. Pomysl o tym. Gdy bowiem osoba, ktora ma wdrozyc kod, znajdzie problem w specyfikacji, musi ona lub on zlozych propozycje ulepszenia w gore do szczebla kierowniczego, ktora nastepnie musi byc przekazana z powrotem w dol. Ten proces hamuje produkt i ostatecznie doprowadza go do zastoju. Ponadto deweloperzy w innych czesciach organizacji postrzegaja to jako zaklocene, poniewaz nie wspolpracuja scisle z deweloperem, ktory zaproponowal zmiane. Po prostu nie rozumieja powodu tej zmiany.

Tego nie chciano w Yammerze.

Kierownictwo nie powinno podejmowac decyzji deweloperskich

Nalezy zawsze zatrudniac ludzi, ktorzy sa lepsi i madrzejsi od siebie. Jesli sie to robi, czy nie nalezy ufac wlasnie tym ludziom w podejmowaniu decyzji, ktore inaczej samemu by sie podelo? Ostatecznie zadaniem lidera technicznego jest budowanie i wspieranie organizacji. Prawdopodobnie szybciej niz sie mysli trzeba przestac skupiac sie tylko na pisaniu kodu i skupic swoja uwage na samej organizacji.

Nie sadze, ze powinienes budowac produkt. Sadze, ze powinienes budowac organizacje, ktora buduje produkt.

Badz bardzo ostrozny w ufaniu menedzerom przy decyzjach deweloperskich. W rzeczywistosci powinienes delegowac wszystkie te decyzje w dol do ludzi, ktorzy musza je rowniez wdrozys. Wyraznym sygnale m ostrzegawczym jest sytuacja, gdy menedzerowie sa jedynymi, ktorzy podejmuja decyzje dla ponad 30-40 osob.

Jak wiec budowac funkcje?

Gdy w Yammerze buduje sie funkcje, zawsze ma sie na celu poprawe jednej z trzech glownych metryk:

• Wiralnosc
• Zaangazowanie
• Monetyzacja

Zasadniczo w Yammerze chce sie budowac funkcje, ktore przyciagaja klientow, zatrzymuja ich i sa przez nich kupowane. Nawet jesli Twoje kluczowe wskazniki wygladaja inaczej, powinienes zdecydowanie zaczac komunikowac kilka glownych celow w calej organizacji. W przeciwnym razie nie mozesz upowaznic wszystkich pracownikow swojej firmy do podejmowania dobrych decyzji.

W tradycyjnych organizacjach kierownicy projektow pisza specyfikacje wedlug swoich pomyslow. W Yammerze jest inaczej. Zamiast pisac sztywna specyfikacje na temat tego, co ma byc zbudowane, specyfikacja jest postrzegana jako punkt wyjscia dla wielofunkcyjnego zespolu, ktory moze ja nastepnie opracowac. Jezeli specyfikacja jest juz zbyt dluga lub zbyt wiele jest w niej przepisane, nalezy byc ostroznym. Deweloperzy, ktorych to dotyczy, powinni moc rozumiec decyzje dotyczace danej funkcji, aby mogli wdrozyc kod w najwydajniejszy i najskuteczniejszy sposob.

Regula „Dwa i dziesiec"

Najwazniejsza zasada w Yammerze brzmi: dwa do dziesieciu osob, dwa do dziesieciu tygodni. W zasadzie nie ma projektow wiekszych ani bardziej skomplikowanych. Istnieje nielinearny zwiazek miedzy zlozonoscia projektu a koncowa faza integracji. W przypadku wszystkiego, co trwa dluzej niz dziesiec tygodni, czas trwania fazy konco wej staje sie nieproporcjonalnie dlugi.

Trzymanie sie tej zasady zmusza rowniez do czestszego wydawania, testowania zalozen i niezajmowania sie zbytnio bledami. Jest to podobne do Lean Startup i jesli chcesz to wyprobowac, musisz to skodyfikowac w swojej firmie.

Musisz rozwinac poczucie pilnosci. Bardzo dlugie projekty czesto sa winne temu, ze deweloperzy trac a z oczu rzeczywisty cel. Jest to podobne do pieszej wycieczki. Kiedy wyruszasz, masz jeszcze duzo energii, cieszy cie wycieczka i posuwasz sie dosc szybko do przodu. Z czasem jednak Twoje cialo staje sie zmeczone i nie mozesz juz rozpoznac, gdzie zaczales ani dokad idziesz. Kiedy dojdziesz do tego punktu, potrzebujesz silnej woli, aby motywowac sie do dalszego marszu. Niestety wiele organizacji postawilos swoich deweloperow w tej sredniej fazie przy wiekszosci ich zadan.

Bliski konca wycieczki mozesz jednak znow dostrzec swoj cel i motywacja wraca. Z kazdym krokiem cel jest troche blizej. Wazne jest, aby Twoi deweloperzy znajdowali sie w tej fazie, w ktorej moga mierzyc i wizualizowac swoje postepy. Tylko w ten sposob mozna utrzymac pilnosc i morale pracownikow.

Wlasnosc kodu

Ostroznosc z wlasnoscia kodu – gdy ludzie maja wlasna baze kodu, moze to stworzyc wiele blednych bodzcow, ktorych nalezy unikac. W Yammerze organizacja jest podzielona na dziedziny. Deweloperzy sa w koncu naprawde inteligentni i zmotywowani, a gdy moga sie orientowac na cel firmy, moga osiagac niezwykle rzeczy (i to calkowicie samodzielnie).

Definiowanie, jak wyglada pracujacy zespol

Zanim zostanie stworzony zespol produktowy dla funkcji, dokladnie przygladamy sie specyfikacji. Dokladniej mowiac, staramy sie oszacowac naklad pracy dla tej funkcji.

Wezmy Produkt X. To wyobrazonu funkcja, ktora zwiekszasza wiralnosc, umozliwiajac zapraszanie znajomych podczas procesu rejestracji. W tym przykladzie nacisk kladziony jest na front-end, co oznacza, ze byc moze potrzebne beda dwie osoby do interfejsu uzytkownika. A poniewaz prawdopodobnie trzeba tez cos zmienic w procesie rejestracji, z pewnos cia potrzebna bedzie rowniez osoba z zespolu Rails, aby napisac kod.

Gdy zespol produktowy uzgodnil priorytety projektu, wystarczy poczekac, az deweloperzy beda dostepni (w tym przypadku dwa dla front-endu i jeden dla Railsow). W Yammerze jest duza tablica z siatka, zwana „Big Board". Po jednej stronie wymienione sa projekty, po drugiej wszyscy deweloperzy pracujacy nad funkcjami. Oczywiscie deweloper moze w tym samym czasie pracowac tylko nad jednym projektem. Big Board tworzy rowniez dobra przejrzystosc priorytetow. Wszystko, co jest robione podczas programowania, jest tam wymienione, a dyrektor generalny moze w kazde j chwili rzucic na to okiem i stwierdzic: „Nad tym wiec pracuja teraz deweloperzy."

Jesli uda Ci sie zabezpieczyc skupienie na jednym projekcie, Twoja firma stanie sie juz znacznie szybsza. Zaskakujace jest, ze nikt w swojej organizacji nie robi z tego warunku – a przeciez w zasadzie kazdy wie, jak drogie jest prze laczanie kontekstu. Przy absolutnym skupieniu buduje sie jedna rzecz, dostarcza sie ja i mozna przejsc do czegos innego.

Ale kto sie wtedy zajmuje bledami?

Gdy wszyscy pracuja nad funkcjami, kto sie wtedy zajmuje bledami? W Yammerze sa po prostu liczne wielofunkcyjne zespoly. Bierze sie kilka osob z zespolu Rails, z zespolu front-end i z zespolu mobile itd. i mowi sie im: „Wasze zadanie polega na naprawianiu bledow i pracy nad nasza lista." Jest to tylko chwilowa sprawa (jak wszystkie grupy zorientowane na projekt) i ludzie wymieniaja sie przy tym. Ta struktura organizacyjna umozliwia zajmowanie sie wsparciem bez wplywu na tworzenie funkcji.

Ponadto nie powstaje w ten sposob druga klasa deweloperow. Nie sa po prostu wyznaczani tylko mlodsi deweloperzy do naprawiania bledow; rowniez starsi deweloperzy sa wlaczani. I tego sie chce, bo gdy bledy maja byc naprawiane, nie chce sie ich przykrywac, lecz usuwac przyczyne. Bardziej doswiadczonym ludziom nalezy pozwolic na refaktoryzacje kodu, jesli zajdzie taka potrzeba. Ten system prowadzi rowniez do petli informacji zwrotnej miedzy tymi, ktorzy buduja funkcje, a tymi, ktorzy naprawiaja bledy. Znajomosc czestotliwosci i rodzaju bledow to wazne informacje dla decyzji, ktore moga napedzac tworzenie produktow.

Niniejszy tekst pochodzi z bloga First Round i zostal przez nas przetlumaczony na jezyk polski.