Kategoria: PL

Dawno, dawno temu, gdzieś w odległej galaktyce… pracowałem w gazecie. Takiej zwykłej, wydającej 1 numer każdego dnia. To była ostatnia szansa by przed internetem załapać się na media w starym stylu. Nauczyłem się wtedy wielu rzeczy, ale trzy z nich w rozwoju produktów są naprawdę ważne.

Zadawanie pytań. Zanim coś napiszesz do gazety, musisz zebrać informacje. Robi się to docierając do źródeł i zadając pytania. Potem weryfikuje się ustalenia w innych źródłach. W efekcie dowiadujesz się o wiele więcej, niż potem wykorzystasz. Używa się 15 procent zebranych informacji.

Gdy rozwijamy serwis / usługę trzeba poznać jak coś działa, jak korzystają z tego użytkownicy. Zadaje się pytania, by dotrzeć do sedna sprawy. Potem, by poznać możliwe rozwiązania problemu projektowego. Prowadzącym projekty umiejętność zadawania pytań pozwala na poprawę skuteczności. Od ludzi, z którymi współpracują dowiadują się rzeczy, które mają wpływ na przebieg prac. Ustalają np. kiedy coś może zostać zrobione. Gdy są dociekliwi, wiedzą więcej, co pozwala uniknąc niespodzianek. Pytając „skąd to wiesz” albo „co daje Ci tę pewność” weryfikują informacje, które pozyskują. Należy ufać ludziom, ale nie wszyscy wokół nas są profesjonalistami, a nawet tacy nie zawsze wszystko przewidzą.

Zadawanie pytań jest jedną z kluczowych kompetencji innowatorów – ustalili to specjaliści zajmujący się zarządzaniem, analizując sposób ich pracy. Świetna metoda docierania do sedna to zadawanie pięciu kolejnych pytań dlaczego. Oto dlaczego (Amazon, jak zwykle).

Pisanie. W redakcjach się pisze, potem to drukują (albo nie), to oczywiste. Większość z nas po kilkunastu latach edukacji nie ma pojęcia o pisaniu. W szkołach tego nie uczą. Komplikujemy zdania i wypowiedzi. Używamy zbyt wielu słów. Tracimy wątek i używamy ozdobników, które nic nie znaczą. Pakujemy do tekstów masę niepotrzebnych detali, bez wpływu na narrację. Potrzeba praktyki by dojść do umiejętności tworzenia tekstu, który zawiera wszystkie kluczowe informacje podane w strawnej formie.

W rozwoju komunikacja pisemna jest kluczowa – trzeba pisać, dokumentować ustalenia, choćby po to, by móc do nich wracać. Pisać na temat, jednoznacznie i precyzyjnie to wielka sztuka.

Jason Fried radzi „zatrudnij lepiej piszącego”. W Amazonie nie można używać Power Pointa. Zebrania dyrektorów zaczynają się od ciszy, w czasie której wszyscy z uwagą czytają wydrukowane materiały na temat, o którym będa rozmawiać. To raczej eseje niż ustalenia spisane w punktach. Jeff Bezos mówi, że żeby coś takiego napisać nie można nie mieć dobrze przemyślanego tematu. Powerpointa potrafi wyprodukować prawie każdy.

Przekazywanie informacji to jedna rzecz, pisanie o rozwoju, tłumaczenie związanych z nim tematów, zupełnie inna. Ciągle szukam formy jak to robić i ciągle z niej nie jestem zadowolony. Choć test, który zrobiłem pokazał, że to co piszę jest zrozumiałe 😉

Redagowanie. Kiedyś wydawało mi się, że to co piszą dziennikarze bez większych zmian trafia na łamy. Tymczasem pierwsze wydrukowane teksty wcale nie przypominały tego, co stworzyłem. Nie chodzi o konstrukcję zdań, czy poprawność językową. Wyglądąły jakby wyszły z pralki. Zawsze były krótsze, treściwsze i lepsze. To się nazywa redakcja. Potrzebny jest do niej czas i redaktor, który – uwaga – nie zawsze jest „lepszym dziennikarzem”.

Projekty i produkty też wymagają edycji. Jeśli nie wymusi jej ktoś, kto ma doświadczenie i dba o jakość, zmusi nas do tego konkurencja lub użytkownicy. Redagować warto nie tylko komunikację do użytkownika – chodzi też o modyfikacje imterfejsów i stron. O detale, których na pozór nie ma. Czasem czegoś nie widać i trzeba to uwypuklić, czasem coś warto trochę schować, żeby było dostępne ale nie przeszkadzało. To małe zmiany, które powodują dużo.

Wielu rzeczy się nauczyłem, ale te wydają mi się z perspektywy czasu najbardziej istotne. W tych tematach zostanę w starej szkole. Nowe media, które nie znają ograniczeń produktują dużo i zbyt wiele z tego nie ma żadnej wartości. Ograniczona powierzchnia papieru wymuszała selekcję, dziś muszą ją realizować użytkownicy – polecają coś z papki, która powstaje, albo nie. Ale to już zupełnie inny temat.

Gdy budujemy coś nowego pytanie „kiedy” należy do trudniejszych. Trudno ocenić ile zajmie realizacja projektu, a jego najmniej przewidywalny etap to projektowanie. To w jego trakcie szuka się rozwiązań. Gdy nie wiadomo co będzie projektowane, nie sposób powiedzieć ile potrwa. Na dodatek projekt zwykle zatwierdzają jacyś decydenci. Mogą go odrzucić i spowodować powrót do początku prac. Samo projektowanie ma miejsce na samym początku realizacji. Do deadlinów jest daleko i może się wydawać, że projekt jeszcze się nie toczy. Trudniej w takiej sytuacji o mobilizację.

Jak organizować projektowanie by szło sprawnie a efekt był przewidywalny? Próbą odpowiedzi na to pytanie jest cykl wpisów o procesie projektowym realizowanym przez Google Ventures Design Studio. Autor, Jake Knapp, postawił sobie za cel zamknąć projektowanie od konceptu do testów w pięciu dniach „sprintu”. To co pisze jest interesujące nie tylko ze względu na metodę, ale na spostrzeżenia dotyczące pracy w zespołach.

Projektanci należą zwykle do „rzadkich” zasobów. Jak pisze Knapp, w samym Google nie było trudno pozyskać na kilka dni 3-4 projektantów. W startupach, z którymi współpracuje Design Studio (i mniej zasobnych korporacjach) szczęściem jest dostęp do jednego. Dlatego jeśli już mają coś robić, warto szukać sposobów, by szło sprawnie. Sporo zależy od dyscypliny. Knapp uważa, że praca w ograniczonym czasie zwykle daje dobre efekty. Deadline wymusza postęp.

Choć nad projektem pracuje zespół, nie jest to praca grupowa w tradycyjnym rozumieniu. W ostatnich latach coraz częściej pisze się o jej wadach. W grupie głos mają najgłośniejsi, rzadko najbardziej utalentowani. Często efektem ustaleń jest kompromis – posługując się nim rzadko wybiera się dobre rozwiązania. Początkowa burza mózgów z dużą liczbą pomysłów to dobra zabawa, jednak najciekawsze pomysły pochodzą od jednostek. Uwagi nt. dynamiki grup i sposobu podejmowania decyzji projektowych są wybitne – widać, że czytamy słowa praktyka.

Projektowanie to przede wszystkim podejmowanie decyzji. Jeden z częściej popełnianych przez projektantów błędów to rozpoczynanie od makiet wysokiej jakości. Ich tworzenie zajmuje dużo czasu i powoduje, że autorom trudno się z taką makietą rozstać. Zamiast szukać najlepszej drogi, poświęcają energię na obronę własnej. To tylko utrudnia wybór. Gdy trzeba wybierać potrzebny jest dobry proces krytyki propozycji. Konflikty jakie się pojawiają najlepiej pokazują możliwości i wostrzają kluczowe aspekty projektu. Nie należy ich unikać, warto zwrócić szczególną uwagę na rzeczy, które budzą kontrowersje.

W czasie projektowania potrzebne jest zaangażowanie wszystkich, zwłaszcza osoby, która decyduje. Gdy później zakwestionuje ustalenia, cały proces okaże się stratą czasu. Często jest to umowny „dyrektor”, nie na co dzień dostępny. Należy go sprowadzić w kluczowych momentach. Co ciekawe, nawet osoby, które zwykle decydują, w grupie zaczynają się zachowywać bardziej demokratycznie niż zwykle. Nie zawsze potem będą popierać decyzje, które podjęły. Dlatego warto zastosować jakieś metody wymuszające u nich asertywne zachowania.

Kontynując temat mitów dotyczących rozwoju produktów: dlaczego „pełne obłożenie zasobów” i minimalizacja zmian w harmonogramach utrudniają rozwój? Jak większość rzeczy, o których piszę, problem dotyczy większych organizacji. Jednak ich natura i przyczyny zainteresują wszystkich, którzy rozwijają produkty. Również w start-upach.

W dużych firmach część realizacyjna czesto jest niezależna od produktów. Składa się z kilkudziesięciu osób – programistów, projektantów, grafików i innych specjalistów. Z jej usług korzystają działy produktowe. Zadanie zarządzających polega na tym, by z ich pomysłów wybrać najkorzystniejsze dla organizacji i zapewnić im sprawną realizację.

W takiej sytuacji naturalnym wydaje się dążenie do systemu, w którym jak najmniej jest „przestojów” i każdy z ludzi odpowiedzialnych za realizację ma co robić cały czas. Dla każdego, kto miał styk z procesami produkcji „pełne obłożenie zasobów” jest kuszącym celem. Dla specjalizujących się w czystym zarządzaniu (taki MBA bez specjalistycznych dodatków – dziś robię internet, pojutrze pastę do zębów) to również dobry, prosty cel. Łatwo powiązać go z efektywnościa. Większość firm dąży w rozwoju produktów właśnie do pełnego obłożenia zasobów.

Problem w tym, że jest to zły cel – piszą autorzy omawianego artykułu. Osiągnięcie pełnego obłożenia ma sens w produkcji. Tu mamy powtarzalne, opisane procesy. W rozwoju produktów nie da się wszystkiego przewidzieć i zaplanować. Gdy zaczynamy projekt rozwojowy, możemy określić dla niego pewne ramy – co mniej więcej ma powstać i jaki problem trzeba rozwiązać. Można narzucić budżet i termin, ale to nie gwarantuje stworzenia sensownego produktu.

Gdy chcemy mieć wyniki – tworzyć produkty, które mają znaczenie – maksymalizacja wykorzystania zasobów będzie szkodliwa. Jak wpłynie na projekty? Będzie wymuszała pracę kaskadową, w której projekt w kolejnych fazach przechodzi przez analizę, projektowanie, grafikę a potem jest kodowany. Gdy zaczynają się prace programiści rzadko są potrzebni. Ich umiejętności nie są wykorzystywane np. przy ustalaniu potrzeb użytkowników. Dlatego nieefektywne jest „wyjmowanie” na ten czas programisty z innych projektów. W efekcie poznaje on projekt dopiero, gdy przychodzi jego kolej. Nie jest już w niego tak zaangażowany, jak inni członkowie (oby byli).

Samej pracy kaskadowej nie da się zaplacować tak, by projekty gładko, bez przerw, przechodziły od fazy do fazy. Programista ani projektant nie potrafi dokładnie określić kiedy skończy swoje prace. Nie wynika ze złej woli czy braku umiejętności. Oni po prostu za każdym razem robią coś pierwszy raz w życiu. Na dodatek często zmieniają kontekst pracy. Jeśli ktoś robi jedną rzecz przez 20 godzin rozsmarowanych na 3 tygodnie – a tak czasem wygląda praca w takiej organizacji – nie ma szans szans głęboko wejść w temat. Dłużej czeka też na feedback dotyczący tego co wytworzył. Trudniej wtedy wytworzyć coś wartościowego.

Gdy projekt dobiega końca możliwe są dwie sytuacje. Zespół uznaje, że osiągnął wszystko i można zamknąć projekt, albo domaga się tuningu i poprawek w produkcie. Gdy komuś zależy na efekcie, przeważnie ma miejsce to drugie. Spełnienie żądań zespołu – dodanie czasu pracy – powoduje, że inni muszą czekać dłużej. Paradoks polega więc na tym, że im bardziej chcemy być w tym układzie efektywni, tym dłuższe kolejki sobie fundujemy. Zarządzanie wieloma projektami realizowanymi przez określone „zasoby” zawsze kończy się żonglerką i stałą aktualizacją planów.

Jak z tym sobie radzić? Wg autorów HBR zamiast poziomu obłożenia lepiej monitorować czas całkowitej realizacji i długość przestojów. Naturalnym sposobem wydaje się zwiększanie zasobów w wąskich gardłach. Trzeba też kontrolować ilość projektów w toku. W Gazeta.pl ustaliliśmy limit równolegle trwających projektów na 30. Apple radzi sobie z tematem wybierając tylko nieliczne projekty do realizacji. Jak mówił kiedyś Steve Jobs, nie była to nigdy firma, która ma nadmiar zasobów. Kolejny sposób to tworzenie buforów przy planowaniu projektów i dokładanie do planu zasobów „wolnych” slotów. W efekcie od początku wiadomo, że zrobi się mniej projektów jednak szanse na ich powodzenie będą większe. Problemy w mniejszym stopniu występują w firmach, które mają działy realizacyjne bezpośrednio przypisane do produktu. Siłą rzeczy muszą one jednak zatrudniać stosunkowo więcej realizujących.

Wpis jest kontynuacją poprzedniego. Zainspirował mnie artykuł, który można znaleźć na stronach HBR. Dorzucam własne obserwacje. Wkrótce o tym, jakie są przyczyny takiego stanu rzeczy.