15 lat bloga

Ten blog ruszył 19 marca 2004, równo 15 lat temu (na zamykanym właśnie serwisie Blox.pl). Taka okrągła rocznica, warto przypomnieć sobie co to był za rok.

Wtedy blogi były uważane za „pamiętniczki”. Co odnotowałem w owym 2004 roku:

Apple sprzedał więcej iPodów niż Maków

Google uruchomiło… swojego bloga.

Sieci socialne popularne w tym czasie nazywały się: Orkut, Friendster i Grono.net (Fejs ruszył, ale nikt o tym nie wiedział).

iTunes Music Store ruszył w Europie. 1 Euro za piosenkę.

Było Euro, takie w piłkę

„Wired” zdecydował, że będzie pisał „internet” a nie „Internet”

Olimpiada miała miejsce.

Wirtualna Polska zdawała się upadać.

Onet kupił serwis randkowy Sympatia

Do kin wszedł „Ja, robot”

Kataryna zaczęła blogować.

Wired opublikował artykuł „The Long Tail”

Nowe Yahoo, Nowy Onet – redesigny były popularne

Pojawił się Firefox 1.0

Po co ludzie piszą o sobie w Internecie, gdzie każdy – wychowawczyni, mąż, sąsiadka czy kolega z pracy – może przeczytać to, co napisali? – zastanawiały się „Charaktery”

Bill Gates dostawał 4 mln maili dziennie.

Twórcy Tlenu trafili na okładkę „Wprost” (dziś zajmują się Wirtualną Polską).

Blog był słowem roku, przynajmniej wg Merriam-Webster.

Francuski Le Monde dał czytelnikom narzędzie do blogowania.

Trzeba było kombinować by dostać zaproszenie do poczty Gmail.

Drudge Report to 3 najczęściej szukane w Google źródło informacji.

Bittorrent był popularny.

Sam byłem na organizowanym w Ernst & Young szkoleniu z zarządzania projektami. Bardzo sensowne zdroworozsądkowe podejście, mocno na mnie wpłynęło. Spośród różnych szkoleń akurat to doceniłem od razu.

OK 230 tys. ludzi w 14 krajach zginęło wskutek tsunami w grudniu.

Płyta Brygady Kryzys w otwartym przez Interię sklepie muzycznym kosztowała ok 20 pln

Oczywiście nie pisałem o milionie ważnych rzeczy, w szczególności o tym, że tak wtedy wyglądał telefon:

Samodzielne zespoły – największe wyzwania

By zespoły były rzeczywiście niezależne potrzebne są spore zmiany w organizacji. Trzeba pokonać kilka barier. Część z nich oparta jest na wieloletnich przyzwyczajeniach i starych sposobach robienia rzeczy.

Pisałem już kiedyś o rozmiarze zespołu – nie może być za duży. Przy większych grupach trudniej buduje się zaufanie i nie da się osiągnąć tzw. bezpieczeństwa psychologicznego. Sprawia ono, że każdy zabiera głos i zapadają lepsze decyzje. W Amazon twierdzą, że jeśli na lunch zespół potrzebuje więcej niż dwie pizze, wtedy jest on zbyt duży.

Photo by Ricardo Frantz on Unsplash

Z drugiej strony członkowie zespołu powinni mieć w sumie wszystkie kompetencje niezbędne do działania. W startupie finansowym Transferwise, który zajmuje się międzynarodowymi przelewami, w zespołach zajmujących się ekspansją są bankowiec i prawnik.

Zespoły zaczynają naprawdę przynosić korzyści, gdy ich wysiłek dotyczy tego, co widzą odbiorcy. Nie są to struktury ani procesy, użytkownicy widzą produkty. Dlatego zamiast pionowych układów opartych na hierarchii mamy grupy zajmujące się tym, co tworzy firma.

Trzeba tak określić zakres odpowiedzialności, żeby zespół mógł działać niezależnie – nie czekając na zgody czy pracę innych. Rzeczy, które wymagają koordynacji zawsze trwają dłużej. Planowanie zajmuje czas, współpraca wymaga komunikacji co daje więcej możliwości popełniania błędów. Na dodatek priorytety koordynujących się mogą być różne.

Przy ustalaniu zakresu „własności” wyzwaniem są aspekty technologiczne, zwłaszcza dla firm rozwijających oprogramowanie. Trzeba tak budować systemy, by składały się z części, w których zmiany można wprowadzić niezależnie. Autonomia nie może przy tym prowadzić do sytuacji, w której tylko ludzie z konkretnych zespołów są w stanie zmieniać i naprawiać swoje części aplikacji. W starszych (co może oznaczać „tylko” 10 lat) i złożonych systemach jest to trudniejsze. Czasem ciężko ocenić, czy większym problemem jest technologia czy bariery związane z lękiem bardziej doświadczonych inżynierów. Nie chcą oddawać odpowiedzialności bojąc się o jakość i bezpieczeństwo.

Wcześniej zapewniały to struktury (jeśli zapewniały) co skutkowało jednak wolniejszym działaniem. Nowy podział idzie w poprzek wszystkiego co dotąd obowiązywało. Lider zespołu zwykle nie jest nawet szefem ludzi, z którymi pracuje. Czasem nawet nikt nie jest liderem, a ta rola na pewno nie musi wynikać z funkcji. Zmienia się odpowiedzialność szefów – w szczególności szef produktu może nie podejmować już samodzielnie decyzji o… produkcie. To celowo przerysowany przykład. Teraz jego zadaniem będzie nauczyć specjalistów od produktu tak działać, by dobrze robili swoje współpracując z zespołem. Nadal do nich będzie należało podejmowanie decyzji o priorytetach, jednak muszą to robić angażując zespół.

Kluczowe jest to „dobrze”. Nie zostawiamy ludzi samymi sobie by w jakiś demokratyczny sposób dla własnej satysfakcji robili co im się podoba. Zadaniem tzw. managementu jest zapewnić, by w swojej kompetencji członkowie zespołów osiągnęli pozwalającą na samodzielność sprawność i „fachowość”. To też kluczowy element – mieć w każdym zespole na tyle dobre kompetencje w danym obszarze, by jego przedstawiciel samodzielnie lub choćby w parze mógł reprezentować swoją dziedzinę. Dlatego zespoły się „buduje” a nie po prostu tworzy inaczej niż dotychczas układając ludzi.

Zespół sam decyduje co i jak robi, a kluczowe w ustalania co te rzeczy mają dać są cele. Cele, a nie szczegółowe plany rozwojowe. Cele, które mówią co chcemy osiągnąć i po czym poznamy, że to się udało. Cele zorientowane na poprawę produktu, która może być mierzona np. popularnością czy parametrami świadczącymi o jakości dla odbiorców. Nie da się uniknąć współpracy i koordynacji między zespołami. W tym również pomagają wspólnie określane cele i działający proces podejmowania związanych z nimi decyzji.

Dlaczego zwinne zespoły to konieczność?

Łatwo powiedzieć „inwestujcie w zespoły”. To jedno z większych wyzwań przed zmieniającymi się firmami: jak ułożyć organizację, by współpraca ludzi o różnych specjalnościach dawała szybko efekty dobre dla klientów i biznesu.

Pisałem już o tym dwa lata temu. Jednak gdy o tym opowiadam w kontekście pracy z celami, dla wielu jest to całkowicie nowy temat. Zespoły zamiast działów? Ale jak to?

Na początek trochę propagandy – „najlepsi już tak robią”. Skuteczne firmy produktowe – Amazon, Netflix czy Spotify organizują ludzi w zespoły produktowe. Zwłaszcza „model Spotify” jest szeroko opisany. Wg badań Deloitte autonomiczne zespoły wielofunkcyjne („cross-functional” – rzadziej przekrojowe lub interdyscyplinarne) to pierwsza z pięciu kluczowych praktyk stosowanych przez dojrzałe firmy po cyfrowej transformacji. Tam działają „zwinne zespoły”.

Team of teams – ilustracja z książki gen Stanley’a McCristala

To co firmy dają klientom i użytkownikom rzadko jest odbiciem struktury organizacyjnej a niemal nigdy nie jest wytworem ludzi jednej specjalizacji. Przykładowy „dział UX” w zasadzie nic nie wytwarza – wartość powstanie dopiero, gdy projekty zostaną wdrożone przez zespół deweloperski. Najlepiej to działa, gdy projektant jest po prostu częścią tego zespołu. To pierwszy powód – dopiero zespół jest w stanie przynieść wartość.

Zwykle taki sposób działania wiąże się z rozwojem oprogramowania, ale nie musi. Polski dystrybutor sprzętu elektronicznego, z którym pracowałem, zdecydował, że w dziale marketingu zorganizuje się w kilka wirtualnych teamów. Jeden z nich może np. odpowiadać za aktywność w social media. Pracownik może być członkiem dwóch teamów. Np. grafik, czy redaktor treści może działać w zespole „socialowym” oraz zajmującym się rozwojem stron WWW z ofertą.

To ilu ludzi mamy do dyspozycji ma mniejsze znaczenie niż szybkość i skuteczność ich współpracy. Lepiej zorganizowany 30 osobowy team może być skuteczniejszy niż dwa razy większy. Zasoby zawsze są ograniczone – nawet na poziomie małej grupy trzeba wybierać w jakiej kolejności realizowane są zmiany. Na szybkość wpływa kilka rzeczy np. to jak ludzie współpracują i czy zespół ma wszystkie niezbędne do wprowadzania zmian kompetencje. Jeśli musi czekać na projekt albo decyzje projektantów, będzie wolniejszy i mniej zaangażowany. Szybkość to powód drugi.

To jak klienci odbierają usługi najlepiej widzą pracownicy na pierwszej linii – pracujący z użytkownikami lub mający dostęp do ich reakcji. Powinni oni móc podejmować decyzje o tym, jak ma działać produkt. Rzadko kiedy lepiej zdecyduje o tym zarząd. Zespół najszybciej lepiej poradzi sobie, gdy nie będzie musiał czekać na zgody z „góry”, która ani nie ma tylu informacji, ani nie będzie w stanie podejmować tylu decyzji. Więcej dobrych decyzji to trzeci powód.

Trzeba podkreślić: nie są to organizowane ad hoc zespoły projektowe, bo logika „zaplanowany efekt + budżet = projekt” oparta jest na fałszywym założeniu, że wszystko przypomina budowanie mostów czy domów. Tu można przewidzieć co się stanie, bo to powtarzalna działalność. Tymczasem często, nie tylko w rozwoju produktów, nie ma takich zależności. Niespodzianki są stałym fragmentem gry, zwłaszcza w czasach technologii.

Dobrze zbudowany, zrównoważony zespół, jest w stanie działać bez nadzoru. Gdy któryś z członków odejdzie pozostała grupa często jest w stanie zapełnić braki. Gdy taki człowiek byłby jedynym „decydentem”, menedżerem czy innego rodzaju „alfą i omegą” – tak często kończymy stawiając na „geniuszy” – to gdy go zabraknie dziura jest trudniejsza do załatania. Ułożenie współpracy w większym stopniu wpływa na skuteczność niż zatrudnianie wybitnych. Geniuszy jest niewielu, wystarczająco dobrych – cała masa. Nie wiem jeszcze jak nazwać ten powód, wygląda na to, że jest czwarty i piąty.

Amerykańscy szpiedzy w czasie Drugiej Wojny zaobserwowali, że 22 letni niemieccy porucznicy byli w stanie skutecznie dowodzić oddziałami, gdy ich dowódcy ginęli. Nie było to możliwe w siłach aliantów. Wynikało z modelu szkoleń i zastosowania taktyki zadaniowej u Niemców, w której definiuje się cele, środki zostawiając w kompetencjach realizujących. Tak właśnie trzeba podchodzić do zespołów – przekazując im odpowiedzialność a nie wyznaczając zadania. O tym wkrótce.