Produkt, a nie projekt!
•Download as PPTX, PDF•
0 likes•651 views
Dlaczego zespół jest najlepszym projektantem, gdy tylko otrzyma odpowiednie narzędzia? Informacje o: - budowie motywacji to tworzenia rzeczy lepiej - współpracy między designerami a developerami - opis narzędzia do wybierania celów - NOC Prezentacja z Product Camp 2015
Recommended
Recommended
More Related Content
Featured
Featured (20)
Produkt, a nie projekt!
- 1. Radosław Taraszka Produkt, nie projekt! W poszukiwaniu motywacji do robienia rzeczy lepiej
- 4. Radosław Taraszka Kolaboracja w zespole WSPÓŁPRACA!
- 5. Radosław Taraszka 1/30 Na 30 developerów przypada 1 projektant
- 6. Radosław Taraszka Ale co z tą motywacją?
- 7. Radosław Taraszka Każde ciało trwa w swym stanie spoczynku lub ruchu prostoliniowego jednostajnego, jeżeli siły przyłożone nie zmuszą ciała do zmiany tego stanu. I zasada Dynamiki Newtona Ludzie podobnie - nie zmieniają sytuacji, w której się znajdują dopóki nie wpłynie na nich stymulant.
- 8. Radosław Taraszka Zmiana ruchu jest proporcjonalna do przyłożonej siły poruszającej i odbywa się w kierunku prostej, wzdłuż której siła jest przyłożona. II zasada Dynamiki Newtona Działanie człowiek wynika z rodzaju, kierunku oraz siły bodźca, który na niego wpłynął. Stąd też właściwa motywacaj determinuje dalsze działania.
- 9. Radosław Taraszka Input -> Designer -> Output Rola projektanta w procesie
- 10. Radosław Taraszka Input -> Designer -> Output Rola projektanta w procesie Source file -> Compiler -> Executable
- 11. Radosław Taraszka Input -> Designer -> Output Rola projektanta w procesie Source file -> Compiler -> Executable
- 12. Radosław Taraszka Projektant jako katalizator
- 14. Radosław Taraszka Jak my to robimy
- 15. Radosław Taraszka Nie zamykaj się w piwnicy - Zbierz dane. - Zaprezentuj je. - Zacznij dyskusję.
- 17. Radosław Taraszka Narzędzie Określana Celów
- 20. Radosław Taraszka Zapisanie rozwiązań Spisanie rozwiązań do problemu głównego (na etapie CJM odwołujemy się zarówno do problemów jak również potencjalnych rozwiązań)
- 22. Radosław Taraszka Określenie znaczenia W przypadku tego projektu brało w nim udział 5 osób. Każda osoba miała możliwość oddania maksymalnie 3 głosów (jeden na konkretne rozwiązanie) z uzasadnieniem, dlaczego uważają, że to rozwiązanie jest ważne. Jak widać każda z osób w zespole oddała głos na rozwiązanie nr 1, ale również inne rozwiązania zostały uznane za dość istotne (2, 5, 6)
- 24. Radosław Taraszka Określenie złożności Wewnątrz znajduje się podział na dwie kolumny: - ocena skomplikowania designu - ocena skomplikowania developmentu Skala ocen wynosi od 1-5 (1 - bardzo łatwe, 5 - super trudne). Najpierw estymują designerzy, a następnie developerzy. W przypadku problemu nr 6 zaistniał problem braku dostatecznej ilości danych (rozwiązanie może być super proste, ale również niezwykle złożone - potrzeba więcej danych)
- 26. Radosław Taraszka Określenie opłacalności Tutaj należy zastosować wzór: (Złożoność designu + Złożoność Developmentu) - Znaczenie = Opłacalność I tak w przypadku rozwiązania nr 1 będzie to wyglądało następująco: (4+3)-5 = 2. Co ważne najbardziej opłacalne są projekty, których wynik opłacalności jest jak najbliżej zera.
- 27. Radosław Taraszka Wybranie projektów do dalszej pracy
- 28. Radosław Taraszka Wybranie projektów do dalszej pracy W zespole wybraliśmy rozwiązanie nr1, które charakteryzuje się dużym znaczeniem i chociaż jego przygotowanie jest dość skomplikowane, to dalej wyróżnia się dużą opłacalnością. Dodatkowo uznaliśmy, że dalej powinniśmy pracować nad rozwiązaniem nr 6, ponieważ mimo iż brakuje nam danych (duży rozrzut), to jego opłacalność może być niezwykle wysoka. Na tą chwilę jednak nie jesteśmy w stanie ocenić, czy uda nam się znaleźć wystarczająco opłacalne rozwiązanie.
- 30. Radosław Taraszka Zapraszam do kontaktu radoslaw.taraszka@gmail.com
Editor's Notes
- Słowa wtrącenia Geneza wyboru tego tematu: - kolega Sławomir Pawęska, developer, który wyraził istotę podejścia to tworzenia produktu lepiej niż ktokolwiek inny - wystąpienie Izy Mościchowskiej o budowaniu zaangażowana zespołu z WUD Kraków 2014 - wywiady z klientami UXPin - Nie będę mówił o motywowaniu samego siebie - nie jestem coachem - Benchmarking. Benchmarking everywere! (nie żebym miał coś do sprawdzania jak się ma konkurencja, czy projekty podobne, ale na Boga - z umiarem!)
- Od czego tu zacząć? Problem wybrania kierunku rozpoczęcia prac Problem startu projektu, jego złożoności powinien być znany zespołowi tak samo jak ciąg logiczny prowadzący do wybrania problemu dla zespołu i jego rozwiązania świadomość ograniczeń
- Czy zespół jest na pokładzie w końcu, czy zespół wierzy w obrany cel? czy wierzy, że wybrane do tego środki są skuteczne? czy wie jaki jest plan i czynniki mierzalne? Zespół to najlepszy papierek lakmusowy to sprawdzenia, czy hipoteza nie jest zła/zbyt abstrakcyjna (na tym etapie warto podjąć ryzyko, gdy opłacalność wydaje się wysoka). Praca z zespołem pozwala na znalezienie argumentów o kontynuowaniu projektu lub jego zmianie/porzuceniu
- To developerzy mogą pracować z projektantami? Wyniki cust devów - każdy Manager Designu szuka narzędzi wspierających współpracę i spójność. Współpraca między zespołami, a w szczególności między Designerami a Developerami jest postrzegana jako Święty Grall za którego można wysłać krucjatę w poszukiwaniu narzędzia idealnego do budowania tego elementu. *Spójność teamy w Google mają prawo pracować nad czym im się żywnie podoba, co powoduje, że czasem kilka teamów pracuje nad podobnym problemem, a wyniki prac się kanibalizują Współpraca - potrzeba zwiększenia współpracy między działami designu potrzeba zwiększenia pracy w zespołach projektowych współpraca na lini designer-developerz (1/30))
- Stosunek liczby projektantów do developerów w większości dużych firm developerskich.
- No dobra, dobra, ale co to ma wspólnego z motywacją? Co wspólnego z tym ma kolaboracja Większość z Menadżerów dostrzega tutaj furtkę w zwiększeniu przepływu danych między zespołami oraz częściami zespołów, która bezpośrednio wpływa na motywację do tworzenia lepszych produktów. Dzięki przepływowi danych projektanci/developerzy pracują ze świadomością pewnego ciągu przyczynowo-skutkowego, który bierze się od momentu rozpoznania problemu pierwotnego przez zespół. Współpraca -> budowanie świadomości -> Motywacja do budowanie lepszych produktów
- - Vivek Mehrotra - Motywacja na podstawie praw dynamiki Newtona - Proste odniesienie do zasad fizyki (o których wszyscy się uczyliśmy)
- Kierunek i siła przyłożenia bodźca.
- Rola projektanta w zespole - połączenie styku designu, biznesu i technologii - w zespołach projektowych projektant poza dostarczaniem wireframów (co jest danymi) jest również odpowiedzialny za utrzymywanie celu projektu Input - rozmowa z menadżerami (stakeholderami) zbieranie danych analitycznych badania z użytkownikami analiza porównawcza
- Designer jak computer compiler Designer wybranie właściwych danych wejściowych analiza danych wejściowych wyciągnięcie wniosków z danych wyjściowych moderator dyskusji o problemie i poszukiwaniu rozwiązań wybór narzędzi warsztatowych zasada przekonywania
- Przygotowanie danych w formie, która zobrazuje: - pierwotny problem - ciąg przyczynowo-skutkowy znaczenie problemu dla produktu/usługi Dopiero potem: przygotowanie spójnych materiałów umożliwiających pracę reszcie zespołu (flows, wireframes, prorotypes, specyfikacje, BMC, etc.) wsparcie rozwiązywania problemów projektowych “Emergency support” - wszystko co jest wątpliwe/niejasne należy rozstrzygnąć z udziałem osoby, która przygotowała materiały
- Projektant jest osobą odpowiedzialną za odpowiednie: - wybranie siły przyłożenia - kierunku przyłożenia
- Projektant pomaga w przepływie danych i prezentuje dane w formie zdatnej do dalszej pracy - Model pracy nad projektowanie - Przeniesienie ciężar z projektanta na zespół, a projektant jako moderator/wytworzyciel artefaktów (wireframy, prorotypy, etc.)
- Ważne jest wiedzieć, czego można chwycić się na samym początku.
- Ważne jest wiedzieć, czego można chwycić się na samym początku - wybranie siły przyłożenia - kierunku przyłożenia
- Prezentacja naszego narzędzia do opracowywani opłacalności Podkreślam, że to się dzieje po przesianiu danych i dyskusji nad danymi NOC - Narzędzia Oceniania Celów
- Stan tablicy po przeprowadzeniu warsztatu. Dwa rozwiązanie wybrane jako elementy do dalszej pracy (1 i 6)
- Sposób określenia celów dowolny i zależny od rodzaju problemu, czasu, ograniczeń, ale również preferencji zespołu Customer Journey Map Określenie punktów styków oraz głównych problemów Zamapowanie możliwych rozwiązań
- Spisanie rozwiązań do problemu głównego (na etapie CJM odwołujemy się zarówno do problemów jak również potencjalnych rozwiązań)
- Spisanie rozwiązań do problemu głównego (na etapie CJM odwołujemy się zarówno do problemów jak również potencjalnych rozwiązań)
- Ocean znaczenie rozwiązania. W przypadku tego projektu brało w nim udział 5 osób. Każda osoba miała możliwość oddania maksymalnie 3 głosów (jeden na konkretne rozwiązanie) z uzasadnieniem, dlaczego uważają, że to rozwiązanie jest ważne. Jak widać każda z osób w zespole oddała głos na rozwiązanie nr 1, ale również inne rozwiązania zostały uznane za dość istotne (2, 5, 6)
- Ocean znaczenie rozwiązania. W przypadku tego projektu brało w nim udział 5 osób. Każda osoba miała możliwość oddania maksymalnie 3 głosów (jeden na konkretne rozwiązanie) z uzasadnieniem, dlaczego uważają, że to rozwiązanie jest ważne. Jak widać każda z osób w zespole oddała głos na rozwiązanie nr 1, ale również inne rozwiązania zostały uznane za dość istotne (2, 5, 6)
- Ocena skomplikowania. Wewnątrz tej kolumny znajduje się podział na dwie kolumny: - ocena skomplikowania designu - ocena skomplikowania developmentu Skala ocen wynosi od 1-5 (1 - bardzo łatwe, 5 - super trudne). Najpierw estymują designerzy, a następnie developerzy. W przypadku problemu nr 6 zaistniał problem braku dostatecznej ilości danych (rozwiązanie może być super proste, ale również niezwykle złożone - potrzeba więcej danych)
- Ocena skomplikowania. Wewnątrz tej kolumny znajduje się podział na dwie kolumny: - ocena skomplikowania designu - ocena skomplikowania developmentu Skala ocen wynosi od 1-5 (1 - bardzo łatwe, 5 - super trudne). Najpierw estymują designerzy, a następnie developerzy. W przypadku problemu nr 6 zaistniał problem braku dostatecznej ilości danych (rozwiązanie może być super proste, ale również niezwykle złożone - potrzeba więcej danych)
- Ocena opłacalności Tutaj należy zastosować wzór: (Złożoność designu + Złożoność Developmentu) - Znaczenie = Opłacalność I tak w przypadku rozwiązania nr 1 będzie to wyglądało następująco: (4+3)-5 = 2. Co ważne najbardziej opłacalne są projekty, których wynik opłacalności jest jak najbliżej zera.
- Ocena opłacalności Tutaj należy zastosować wzór: (Złożoność designu + Złożoność Developmentu) - Znaczenie = Opłacalność I tak w przypadku rozwiązania nr 1 będzie to wyglądało następująco: (4+3)-5 = 2. Co ważne najbardziej opłacalne są projekty, których wynik opłacalności jest jak najbliżej zera.
- Wybór rozwiązań W zespole wybraliśmy rozwiązanie nr1, które charakteryzuje się dużym znaczeniem i chociaż jego przygotowanie jest dość skomplikowane, to dalej wyróżnia się dużą opłacalnością. Dodatkowo uznaliśmy, że dalej powinniśmy pracować nad rozwiązaniem nr 6, ponieważ mimo iż brakuje nam danych (duży rozrzut), to jego opłacalność może być niezwykle wysoka. Na tą chwilę jednak nie jesteśmy w stanie ocenić, czy uda nam się znaleźć wystarczająco opłacalne rozwiązanie.
- Wybór rozwiązań W zespole wybraliśmy rozwiązanie nr1, które charakteryzuje się dużym znaczeniem i chociaż jego przygotowanie jest dość skomplikowane, to dalej wyróżnia się dużą opłacalnością. Dodatkowo uznaliśmy, że dalej powinniśmy pracować nad rozwiązaniem nr 6, ponieważ mimo iż brakuje nam danych (duży rozrzut), to jego opłacalność może być niezwykle wysoka. Na tą chwilę jednak nie jesteśmy w stanie ocenić, czy uda nam się znaleźć wystarczająco opłacalne rozwiązanie.
- Mam głębokie przekonanie, że bliska współpraca z zespołem, projektowanie idei procesu, czy interfejsu z zespołem pozwala uzyskać kilka rzeczy: utrzymać świadomość problemy pierwotnego zgłębić złożoność problemu z różnych stron udział każdej części zespołu od początku procesu przez co zrozumienie/zaangażowanie i motywacja jest na zupełnie innym poziomie W końcu pozwala nam na utrzymaniu przez proces głównego czynnika - motywacji do wytworzenia lepszego produktu
- radoslaw.taraszka@gmail.com