W ubiegły weekend (18-20.03.16) mieliśmy przyjemność współorganizować Konferencję Inżynierii Oprogramowania beIT na Politechnice Gdańskiej. II edycja zdecydowanie skalą przebiła poprzednią (zauważyliśmy wzrost kluczowych wskaźników: liczba uczestników, organizatorów, prelegentów, warsztatów).
Przepych i świetna organizacja. Jednak najważniejszym wskaźnikiem sukcesu konferencji jest jej wysoki poziom merytoryczny. Wśród prelegentów w ramach 4 ścieżek pojawiły się rozpoznawalne nazwiska ekspertów (m. in. J. Żeliński, H. Wesołowska, M. Perendyk, M. Dąbrowski, T. Boiński, B. Drapella, A. Kugler, T. Tomaszewski) i nazwy firm (min. Blue Media, Spartez, Polska Press Internet, Lufthansa, Aiton Caldwell, JIT Solutions, AirHelp, Asseco Poland).
Również my – Product Crew (tj. autorzy tego bloga) stanęliśmy na wysokości zadania. Do organizacji ścieżki beProductManager podeszliśmy w stylu… produktowym. Wyznaczyliśmy sobie następujące cele:
- 50 nowych osób zapisanych na Newsletter,
- ruch na stronie www.productcrew.pl w trakcie trwania konferencji – 30 unikalnych odsłon,
- ocena każdego warsztatu minimum ⅘.
Osiągnęliśmy wszystkie z nich. Średnia ocena z warsztatów poprowadzonych przez Product Crew wynosi 4,5 / 5. Jesteśmy dumni!
Nasze warsztaty
Pierwszy warsztat w ramach ścieżki beProductManager poprowadził Tomek Tomaszewski, którego temat był następujący: “Jak zamienić pomysł w działający produkt?”. Przełożenie wizji na wartościowy produkt, z którego użytkownicy będą chcieli korzystać, to nieodłączna część pracy Product Managera. Podczas warsztatu uczestnicy poznali Lean Startup i jego kluczową technikę – tworzenie modelu biznesowego.
Kolejny warsztat dotyczył prototypowania: “Uwolnij swoje myśli. Protytypowanie w Axure”, który miałam przyjemność poprowadzić. Uczestnicy poznali podstawowe funkcjonalności narzędzia Axure, a także wcielili się w rolę Product Managera firmy AirBnB. Dowiedzieli się również czym jest konwersja, współczynnik odrzuceń, stawiali hipotezy i proponowali eksperymenty w celu zwiększenia tych wskaźników.
Trzeci warsztat, który został poprowadzony przez Igora Springer i Jakuba Mierzewskiego to: “Szacowanie zadań w zespołach zwinnych, a zarządzanie produktem.” Uczestnicy poznali trzy techniki szacowania, ich zastosowanie, wady i zalety (estymacja w godzinach, planning poker oraz team estimation game).
Naszą produktową wisienką na torcie był warsztat Joli Gadek pt.: “Jak mierzyć i optymalizować kluczowe wskaźniki produktu?” Podczas warsztatu Jola przedstawiła możliwości wyciągania danych z narzędzia Google Analitycs do stworzenia mierników AARRR (Acquisition, Activation, Retention, Referral, Revenue).
Round Tables
W ramach konferencji poprowadziliśmy również Round Tables (forma dyskusji akademickiej), podczas której poruszyliśmy następujące zagadnienia:
- Product Manager i role, z którymi współpracuje
- Idealny Product Owner
- Product Manager, a Project Manager
- Product Manager w relacji klient-dostawca
- Techniki badania użytkowników
Wyniki są jednak tak obszerne i ciekawe, że przedstawimy je Wam w kolejnym artykule!
Luźne przemyślenia
Na koniec podzielę się z Wami moimi luźnymi przemyśleniami odnośnie tego, co zobaczyłam i usłyszałam w trakcie tej konferencji:
- Moim zdaniem najlepszą prezentację w trakcie konferencji poprowadził Mirosław Dąbrowski. Agile to nie tylko Scrum. Istnieje wiele technik, a Scrum Masterowie jakkolwiek ich stanowisko się zwie w firmie powinni nieustannie się rozwijać, eksperymentować, poznawać nowe techniki i narzędzia. Polecam stronę Mirka, mnóstwo rewelacyjnych materiałów: http://miroslawdabrowski.com/agile-materials/
- Prowadzenie zespołu zdalnego to ciężki orzech do zgryzienia – bardzo podoba mi się pomysł Sparteza na stworzenie “Kodeksu współpracy” dla organizacji,
- Project Manager jako alternatywa dla Product Managera – ma prawo zadziałać, jednak mam wątpliwość co do tego, kto tak naprawdę będzie dbał o użytkownika i wskaźniki ważne dla biznesu, czy biznes w firmie pociągnie to bez wsparcia produktowców? Jeżeli ma dobry zarząd, a zakres obowiązków Project Managerów jest trochę “rozszerzony” może się udać. Rozumiem problemy z brakiem specjalistów na rynku. Dlatego właśnie ruszyliśmy z Product Crew (www.productcrew.pl),
- Nie zgadzam się na publiczne stwierdzenia typu “Programiści nie myślą, analitycy nie powinni dawać im szansy do myślenia, Broń boże nie wysyłaj programisty do klienta”, jednak zwinność i zmiany wynikające z dołu są mi wiele bardziej bliższe,
- Gratulacje dla Hani Kuczary i całego zespołu z Koła Zarządzanie IT. Świetna robota!
Warto obserwować fanpage Konferencji beIT: https://www.facebook.com/konferencjabeit/ by nie przegapić kolejnej edycji. Być może za rok, kolejny raz spotkamy się na ścieżce beProductManager? Zobaczymy co przyniesie czas!
Jeśli chodzi tekst o analitykach i programistach z wykładu, to chodziło raczej o to, żeby utrzymywać kierunek myślenia od ogółu do szczegółu, od potrzeby do rozwiązania. Żeby nie zaczynać myśleć rozwiązaniami i szczegółami, kiedy jeszcze potrzeba, cele i ogólne wymagania nie są znane i rozumiane.
Bardzo fajny efekt daje kontakt z klientem, kiedy można popatrzeć i posłuchać o co mu w ogóle chodzi, jakie ma problemy, potrzeby, na czym polega jego biznes i jak działa ta branża. I to dla wszystkich – programistów, testerów i osób w innych rolach.
Programiści, bazodanowcy mają tendencję do szybkiego przekładania tego co słyszą na konstrukcje programistyczne i bazodanowe, wokół których obracają się na co dzień. Nasiąkają swoją pracą. Tak samo jak analityk wszędzie widzi wymagania i procesy. Na wykładzie po prostu zostało dosadnie powiedziane, że kiedy wejdziemy w szczegóły, konstrukcje i algorytmy bagatelizując potrzeby, cele i wymagania, to możemy zabrnąć w karkołomne funkcjonalności i „work aroundy” z powodu pojawiających się rzekomo nowych wymagań klienta. Tymczasem nie zrozumieliśmy na początku jego biznesu.
Zmiany wynikające z dołu są wtedy fajne, kiedy mamy produkty, w których programiści siedzą i bardzo dobrze je znają i rozumieją. W projektach na zamówienie też często programiści, testerzy potrafią zaproponować rozwiązania lepsze niż wcześniej planowane.
Z drugiej strony mamy ruchy odgórne, strategiczne, kiedy ktoś ma pomysł na firmę, model biznesowy, planuje w jakich kierunkach ją rozwijać – usługami, produktami, grupami docelowymi, zmianami organizacyjnymi, przejmowaniem nowych rynków. Dla mnie to brzmi sensownie, żeby te decyzje były podejmowane też strategicznie, przez ludzi, którzy się w tym kształcili i zdobywali doświadczenie – są w tym ekspertami, tak samo jak programiści są ekspertami od rozwiązań IT.