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.
warsztat_tomka

 

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.

DSC_0321

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).

DSC_0498

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).

DSC_0035

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!

➔ Wykorzystaj modelowanie biznesowe w swojej pracy - zobacz nasz Kurs Business Model Canvas z certyfikatem!

Dołącz do naszych czytelników

Dołącz do 1 700+ subskrybentów otrzymujących nasz cotygodniowy newsletter z inspiracjami do tworzenia coraz lepszych produktów i rozwoju swojej kariery.
Olga Springer
Head of Product w SentiOne. Związana z zarządzaniem produktami informatycznymi od początku kariery zawodowej. Zorientowana na skalowanie firmy i zwinny rozwój produktu. W SentiOne odpowiada za Roadmapę produktu i kluczowe projekty dla biznesu. Certyfikowany Professional Scrum Master i Prince2 Practitioner.

1 KOMENTARZ

  1. 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.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.