Od programisty do Inwestora ("Przyszłość w IT", Wrocław, 2013)

689 views

Published on

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
689
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Who are we?
  • Wojna
  • Manager z pejczem
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Holandia
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Projektowanie, Kodowanie, Testowanie
  • Who are we?
  • Scrumboard
  • Moo chart
  • Feniks
  • Kontrakt
  • Zderzenie z murem
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Zderzenie z murem
  • Zderzenie z murem
  • Sales material
  • Sales material
  • Sales material
  • A3 navigator
  • Sales material
  • Sales material
  • Sales material
  • Sales material
  • Sales material
  • Zderzenie z murem
  • Who are we?
  • Who are we?
  • Najczęściej wykorzystywany sposób tworzenia produktówProdukt stworzony w oderwaniu od klientaWeryfikacja założeń biznesowych następuje na etapie uruchomienia produktuInwestujemy środki w realizacje produktu na podstawie własnych hipotez
  • Who are we?
  • Who are we?
  • Who are we?
  • Humans
  • Who are we?
  • Who are we?
  • Who are we?
  • Rynek
  • 1. Klient ma PROBLEM (zidentyfikowaliśmy/założyliśmy hipotezę)2.    Klient jest ŚWIADOMY ISTNIENIA PROBLEMU (w rozmowie wspomina ten fakt).3.    Klient AKTYWNIE POSZUKUJE ROZWIĄZANIA (nie reaguje jedynie na oznaki problemu [typowe „gaszenie pożarów”]).4.    Klient PRÓBOWAŁ STWORZYĆ ROZWIĄZANIE WEWNĄTRZ SWOJEJ FIRMY Z ISTNIEJĄCYCH ELEMENTÓW.5.    Klient POSIADA BUDŻET (LUB JEST W STANIE GO ZEBRAĆ) DO ROZWIĄZANIA PROBLEMU (wie ile problem kosztuje firmę i jest w stanie podać budżet jaki chciałby wydać na rozwiązanie go).
  • Piramida
  • Product development
  • Product development
  • Piramida
  • Piramida
  • Babillon tower
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Who are we?
  • Od programisty do Inwestora ("Przyszłość w IT", Wrocław, 2013)

    1. 1. Od Programisty Do Inwestora (Agile, Lean, Lean Startup) Marcin Kokott http://twitter.com/MKoko tt kokott.marcin@gmail.co m
    2. 2. IT dzisiaj jest jednym z najszybciej zmieniających się rynków Dasz radę utrzymać się w czołówce?
    3. 3. W korporacjach toczy się wojna
    4. 4. Marzenia są miażdżone przez terminy, koszty oraz…
    5. 5. Ciągłe gaszenie pożarów
    6. 6. Oraz wszechobecny śmiercionośny stres!!!
    7. 7. Nie żebym sam nie szukał adrenaliny 
    8. 8. Grudzień 2008
    9. 9. Byłem programistą odnoszącym sukcesy…
    10. 10. Czułem się prawie niezwyciężony
    11. 11. Pewnego dnia odebrałem telefon…
    12. 12. Dostałem szansę wkroczenia w zupełnie inny świat (prawie dosłownie)
    13. 13. …który okazał się piekłem już od pierwszego dnia
    14. 14. W dodatku w dziwnym języku i kulturze…
    15. 15. Co ty byś zrobił na moim miejscu?
    16. 16. Poczułem się przytłoczony…
    17. 17. …ale zdecydowałem się jednak walczyć
    18. 18. 1. Agile Software Developmen t
    19. 19. Rozdzieliliśmy cały projekt na małe części Sprint #1 Sprint #2 Sprint #3 … 1 Potentially shippable product Potentially shippable product Potentially shippable product Task TaskTask SprintSprint backlog Product backlog
    20. 20. • ”Nie mamy tyle czasu by aż na tyle być wciągniętym do projektu” Project preparation Project execution Extended prj. execution Acceptance and support Involvement Time (project lifecycle) Requirement definition First acceptance and more requirement definition and clarification Acceptance testing, Rework and error corrections Lack of involvement in execution causes longer delivery and huge rework later Project preparation Project execution Acceptance and support Involvement Time (project lifecycle) High level requirement definition Final acceptance Just-in-time req. refinement, demo and acceptance Rework and error corrections Agile project Traditional project … Złamaliśmy błędne założenia kierowników i klientów
    21. 21. Każda była małym projektem
    22. 22. Wymagania przepisaliśmy z punktu widzenia klienta
    23. 23. Wprowadziliśmy zarządzanie wizualne
    24. 24. Nawet ukazując nastroje
    25. 25. W krótkim czasie zmieniliśmy projekt z popiołów w Feniksa
    26. 26. Jednak nie pasowaliśmy do systemu…
    27. 27. Poczułem się jakbym uderzył w mur…
    28. 28. … jednak zacząłem szukać rozwiązań
    29. 29. 10 krajów, 3 kontynenty, 30 projektów i 3 „LEPSZE” strategie później…
    30. 30. 2. Lean
    31. 31. Nauczyłem się, że większość problemu pochodzi z systemu a nie ludzi ”94% problemów pochodzi z systemu, 6% przez ludzi” System Człowiek
    32. 32. „Powinniśmy pracować nad procesami a nie wynikami procesów” W. Edwards Deming
    33. 33. „Większość procesów składa się w 90% z marnotrawstwa (ang. Waste) a jedynie w 10% z pracy dodającej wartość końcową” Jeffrey K. Liker
    34. 34. Zauważyłem, że cały wysiłek poświęcaliśmy na mały procent całości…
    35. 35. „Wszystko co robimy to obserwowanie czasu od momentu kiedy dostaniemy zamówienie od klienta do momentu kiedy nam za to zapłaci, skupiając się na redukowaniu wszystkiego co nie dodaje wartości klientowi” Taiichi Ohno
    36. 36. Każdy jednak widział system w inny sposób…
    37. 37. Nagle mogłem przejrzeć na oczy Ass. to IA (CCB) Classifi cation 1 week Req. Spec Requeste 20 m Cust. contact Decision to cont. (Sol. Arch.) Cust. contact Ballpark estimate (Impl. Arch.) Approved (Sol. Arch.) Agreed by cust. Des. Spec. and cost estimate Cust. contact Agreed by cust. Des. Spec Release agreed by cust. Des. Spec Assig. to Sol. Arch. Break down Tech. Spec. and impl. Review Rework Dev Test (DS) Rework Test Spec. Test Case created Regres sion test System/ Performa nce/install Tests Bug fix (REQUESTE) Bug fix (JIRA) Bug fix (JIRA) Customer Testing 1 d 1 h 1 week 2 w 20 m 1 week 2 d 1 day 2 h 5 h 2 weeks 4 d 2 weeks 3 h 2 months 1 w 3 weeks Iter. backlog 1 month 1 d 40 h 2 d 4 h 1 d 8 h 1 h Wait for test 1 month 1 d 1 h 2 d 1 d 2 h 4 h
    38. 38. 38 Improvement dev by 200% means: • Lead time (Value added) • 100 hours -> 88 hours • But still clock time… • 7 months to… 6 months 28 days and 4 hours!!!!
    39. 39. Potrzebowałem systematycznego podejścia (Warsztaty Kaizen) C X  C (1) Wypracowanie wspólnego celu i mapowanie strumienia Powód Powód Powód C X  C ! ! ! ! ! (2) Wizualizacja odczuwanych problemów (3) Rozpoznanie prawdziwych przyczyn (4) Planowanie rozwiązań i kroków Kaizen
    40. 40. Pokazując prawdziwe przyczyny (Analiza Przyczyn) Estimates are often too optimistic Estimates are forced upfront without proof of concept Fixed priced contract with customers Higher cost per feature than estimated Productivity is slower than estimated Constant obstacles in development Concrete scope is promised to customers Low ROI More items to be delivered than possible Strong push to teams to deliver faster Cheap&dirty solution often wins Defect software at output HardToMaintain software at output A lot of maintenance work High maintenance costs Teams over- commit themselves Demotivated team members
    41. 41. …a wyniki i rozwiązania śledzone przez podejście A3 Go & See Value Stream Map 5x Why? Plan-Do-Check-Act Kaizen Empower people No change without measure Flow Reduce waste
    42. 42. Uproszczone do granic
    43. 43. …które później wspomagałem coachingiem Różnica = Problem Standard Aktualna sytuacja
    44. 44. …które później wspomagałem coachingiem Aktualny stan Wizja Następny stan docelowy Przeszkody 12 3 4 Zrozumied Pokonad Teraz < 3 Miesiące 1-2 Lata
    45. 45. Dzięki temu stworzyliśmy nowe kontrakty Agile
    46. 46. Ale również potrafiliśmy się przy tym bawić 
    47. 47. Jednak dalej czułem że walczę z wiatrakami
    48. 48. Potrzebowałem zmiany… oraz większej adrenaliny
    49. 49. 3. Startups
    50. 50. Na 10 startup’ów tylko 2 odniosą sukces…
    51. 51. Znane podejście było po prostu za wolne… Koncepcja/ Pomysł Stworzenie produktu Testowanie Uruchom / sprzedaż
    52. 52. Jaka jest różnica pomiędzy zwykłym projektem a startup’em?
    53. 53. …i nauka przychodziła za późno
    54. 54. Tymczasowa
    55. 55. Organizacja ludzi
    56. 56. Szukająca
    57. 57. Esktremalna niepewność
    58. 58. Lean Startup „Temporary organization used to search for a repeatable and scalable business model” „A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty” Eric Ries Steve Blank
    59. 59. Poznałem fakt, że klienci mogą być różni…
    60. 60. …oraz na różnym poziomie świadomości Problem istnieje Wie o problemie Aktywnie szuka rozwiązania Próbował znaleźd rozwiązanie Wie ile może za to zapłacid 1. 2. 3. 4. 5.
    61. 61. Których można znaleźć nawet przed rozpoczęciem prac nad produktem
    62. 62. I jest to powtarzalny i przewidywalny proces
    63. 63. I jest to powtarzalny i przewidywalny proces
    64. 64. Spotkanie I: Dopasowanie problemu i rozwiązania
    65. 65. Spotkanie II: Dopasowanie rozwiązania i funkcjonalności
    66. 66. 67 Rok 1958 Chester Carlson
    67. 67. 68
    68. 68. Mierzyliśmy nasz postęp przez liczbę założeń sprawdzonych na rynku 1 12 3 4 5 5 6 7
    69. 69. I praktycznie wpadliśmy w każdą lukę… gdyby nie PIVOT’y
    70. 70. Odpowiedzi są poza biurem
    71. 71. „Żaden model biznesowy nie przeżył kontaktu z rzeczywistością”
    72. 72. Nasz też nie…
    73. 73. …ale to właśnie sprawiło, że odnajdujemy kolejne właściwe tory …już 3 raz 
    74. 74. Większa prędkośd (Agile) Lean Lean Startup + Business Model Canvas
    75. 75. „Innowacja odróżnia lidera od tych co podążają” Steve Jobs
    76. 76. „Bądź sobą. Wszystkie inne role są już obsadzone”
    77. 77. Od Programisty Do Inwestora (Agile, Lean, Lean Startup) Marcin Kokott http://twitter.com/MKoko tt kokott.marcin@gmail.co m

    ×