Als ZIP, PPTX herunterladen
Hochgeladen vonHartmuth Gieldanowski
Design slashdiscussion hgieldanowski.key
Das Dokument beschreibt Methoden zur Agilität in Projekten, insbesondere im IT-Bereich, und betont die Bedeutung von Benutzererfahrung (UX) und iterative Prozesse. Es werden Strategien zur Verbesserung der Teamarbeit durch Workshops, Visualisierungstechniken und kontinuierliches Evaluieren vorgestellt. Zudem wird auf die Notwendigkeit hingewiesen, Dienstleistungen an Kundenbedürfnisse anzupassen und dabei Geduld sowie das passende Werkzeug zu verwenden.
Design slashdiscussion hgieldanowski.key
- 1. HOW TO MAKEA DINOSAUR AGILE 1
- 2. 2 Releases 6 OE’s 10 Quartiere 30 Programme 400 Projekt-Ma. 1.2 Mio. Kunden Online Schwergewicht 2
- 3.
- 4. Emotionalität! Begeisterung! Customer iUsability Experience Productmanager 4
- 5. ..übrigens - wir ..und einfach arbeiten jetzt mit 5 alles mit IT guy - mach das Design Agenturen HTÄML5, ganze zusammen.. Mo’bile und “emotionaler”.. KLOUD! und.. Klar, wir machen YAY! einfach jetzt Web 2.0 Apple-like! ..und Usability- Tests gibt’s am Schluss auch! Productmanager IT Guy 5
- 6. meet... HERMES! Studie Grobspezifikation Detailspezifikation Re ali sie run g 6
- 7. Der Schmerz mitHermes Kostenschätzung = Erfahrung ua! nbe i A ie n .. ch Teufel steckt im Detail Mei nS Planung Zentral = “Weakest Link” Kostendächer IREB - nid immer net’ 7
- 8. “Katholische Agilität”? ..in nomine Budgetplanung agilis..!! Ressourcenplanung Hierarchien Kultur Setzt unternehmensweiten Change voraus! 8
- 9. UX und UCD- Uiiii Ig Oo’ Apple! Apple! Apple! Usability ist ein Test Personas = Kent und Barby Was für Daten? Systematik? Holistik? Motto: Projekt zu Ende dann ab in die Ferien. 9
- 10. Wie man einemDinosaurier das fliegen beibringt 1. Wasserfall > Iteration 2. Sitzungen > Workshops n, 3. Grosser Happen > kleine Bissen se e r, ei t l t öt A g o de n 4. Vorstellen > Visualisieren A elt th 5. Glauben > Evaluieren Al tm 6. (Ab)Liefern > Verbessern 10
- 11. 1. Wasserfall zuIteration 2 Zeitbox Typen mind the size Planbar Ramp-Up Box (field) Iterationen Box (carrot) Gefühl für Iteration ent wickeln 11
- 12. 2. Sitzungen zuWORKshops Ankerpunkte der Iteration Ziele Planbarkeit * 23 Rhythmus Kollaboration ent wickeln 12
- 13. 3. Grosses Problemzu kleinen Happen Baseline Anforderungskatalog Personas (mit GMV gepimpt) Szenarios und Storymaps Stories Depth follows Breath Holistische Sicht weise trainieren 13
- 14. 4.Visualisieren, visualisieren, visualisieren Papier / Whiteboard Wireframes Visuellen Design Mocks Ausführbaren Prototypen Produktionscode Lernen Ideen zu visualisieren 14
- 15. 5. Evaluieren, evaluieren,testen Alles und immer evaluieren Lieber zu früh als zu spät Mit Endkunden Testen als Datenerhebung Evaluieren Teil der täglichen Denke 15
- 16. 6. Projekt endetnicht mit dem Deployment Fehler Changes Verbesserungen Fehlende Funktionalität @SwissRequirementsDay 2011 Maximum value for cost == natural end of project Erik Simmons, Intel Das Ende - ist der Anfang! 16
- 17. Argumentarium (Auszug) Planbarkeit WYWIWYG Reviews, Feedbacks Stakeholder-Involvement ROI, Gesamtkosten Erwartungskonformität Spass.. 17
- 18. Wo das geradeläuft 3 unterschiedliche Projekte Unterschiedlicher Umfang Unterschiedliche Komplexität Interne und Externe Mitarbeiter 18
- 19. Was wir erreichenwollen Projekte erfolgreich einführen Erfahrungen sammeln -> Proof Common Ground schaffen Auf dem Radar auftauchen UCD / UX etablieren ...dem Dino einen “Schubs” geben 19
- 20. Was wir bishergelernt haben Customize! Methodenrucksack Das richtige Werkzeug für das Problem Kompetenzaufbau Geduld -> Change <- Geduld 20
- 21. "What the customerdemands is last year's model, cheaper. To find out what the customer needs you have to understand what the customer is doing as well as he understands it. Then you build what he needs and you educate him to the fact that he needs it." Nicholas DeWolf Inventor of the ON! Computer 21
- 22. @hgieldanowski gieldanowski.ch --311076.5 22
Hinweis der Redaktion
- #2 Hardy Gieldanowski\nHappy to be here. \nHands on Erfahrung aus aktuellen Projekten bei PF.\nMotivation : Eigeninteresse als BA - Schnittstelle zwischen Fach und it. Dort wo auch UX/UCD Experten sitzen sollten\n\nErste 8 slides ist - dann der laufende Versuch...\n \n
- #3 Pf ein gro&#xDF;er Dino\n400 Ma in Projekten involviert, Ohne externe\nOEs \nKomplexe Architektur. Viele Stakeholder.\n1.2 Mio. Online Kunde - der Absatz und kommunikationskanal schlechthin f&#xFC;r pf -> nur 37 Filialen (PF.) \n
- #4 Der Dino fletscht seine Z&#xE4;hne....\nDesign mal weggelassen: Wie kann auf diesem Kanal schneller, kosteng&#xFC;nstiger eine vollst&#xE4;ndige "Filiale" werden? F&#xFC;r 2.5 Mio Kunden , Potential?\n\nProduktmanager stehen vor grossen Herausforderungen.\nNat&#xFC;rlich machen die sich Gedanken, und holen sich auch externe consultants...\n
- #5 Wie lassen sich diese Schlagworte richtig fassen - denn auch vorstellen.\nEmotionalit&#xE4;t - Begeisterung. Unterschiedliche Vorstellungen..\nHaben /sammeln viele Ideen. \nExterne zb Adobe propagieren CEM als neuen holygrail. \nUnd immer schwingt auch Apple als unbegreiflich und doch erstrebenswertes Ziel.. \n
- #6 Klassische wenn auch &#xFC;berspitzte Situation.\nStarke Hierarchien und Arbeitsteilungen verhindern auch Synergien (5 Agenturen - will noch jemand??)\nIT konzentriert sich auf das was sie k&#xF6;nnen - Technologie - vielfach daher alles technologiezentriert.\n\nDaneben kommt noch das metoden Korset...\n
- #7 Hermes PF als projektmethode. Wasserfall f&#xFC;r everyfall... In den Phasen Studie, grob und detailkonzept wird die Anwendung spezifiziert..\nRealisierung ist Freestyle...\nWas ist der Schmerz mit Hermes?\n
- #8 Kostensch&#xE4;tzungen basieren auf Erfahrungen (overestimation biase) und nicht auf Anforderungen\nDetails werden nicht fr&#xFC;hzeitig genug ber&#xFC;cksichtigt\nPlanungen/-sicherheit: ist schwierig da vorhandene Skills und notwendiges Know-how (Aufbau) nicht ber&#xFC;cksichtigt werden\nKostend&#xE4;cher: Pauschal(reisen) Aufwendungen von Externen sind schwierig zu steuern, respektive ein Mgt. von Lieferobjekt und Kosten ist praktisch unm&#xF6;glich\nAnforderungen nach IREB sind theoretisch ok, praktisch aber nicht &#x201C;bewertbar&#x201D;\n\nK&#xF6;nnte Scrum et al die L&#xF6;sung sein?\n
- #9 Hat man ausprobiert mehr schlecht als recht denn:\nSetzt andere Kostenplanung voraus\nSetzt andere Ressourcenplanung voraus\nSetzt andere Hierarchien voraus\n\nMuss von gaaaanz oben kommen -> erfordert MAJOR Change der Kultur und Unternehmung\n\nJa aber wie steht es denn mit UX ucd generell? \n
- #10 sprich &#x201C;das was Apple&#x201D; macht wird als &#x201C;weToo&#x201D; betrachtet.\nUsability ist ein &#x201C;Test&#x201D;, am Schluss\nPersonas sind &#x201C;Puppen&#x201D; -> Barby und Kent -> f&#xFC;r die Website -> wir haben &#x201C;auch welche&#x201D;.\nDatengrundlagen werden kaum systematisch genutzt um Anforderungsherleitungen und Verifikationen zu machen -> oder schlichtweg ignoriert.\n-Systematische, aber auch holistische Denkweise ist kaum verbreitet\nDas Motto wenn man so will ist das Zuende bringen des Projektes - dann gehts ab in die Ferien. Etwas philosophisch Das man der Berg erklommen hat ist wichtiger als das erklimmen.\n
- #11 Der Versuch - Iterativ, Inkrementell\nWasserfall zu Iteration\nSitzungen zu Workshops\nGrosses Problem in kleine Happen\nVisualisieren, visualisieren, visualisieren\nTesten, testen, testen\nProjekt endet nicht mit dem Deployment\n
- #12 Zeitboxen in Anlehnung an SCRUM\n2 Typen: Ramp-ups und eigentliche Iteration\n Nicht zu gross und nicht zu klein -> 4 Wochen\n &#x201C;Planbare Gr&#xF6;sse&#x201D;\n Ich weiss ob ich n&#xE4;chsten Monat Ferien habe oder nicht\n Ich weiss das aber nicht in zwei Monaten..\n \nKleiner Ramp-Up -> Organisatorisches, Grunds&#xE4;tzliches (IA, Personas, etc.)\nInterationen bestehend aus Konzept, Spezifikation, Implementation, Test\n\nZiel: Menschen haben &#x201C;Probleme&#x201D; mit sich wiederholenden Zyklen - man will was &#x201C;abschliessen&#x201D;, weglegen, &#x201C;Er&#x201D;-ledigen. Schwierig f&#xFC;r menschen etwas immer wieder zu verfeinern.\n
- #13 Sitzungen zu Workshops\n\nWorkshops als Ankerpunkte der Iteration\nPlanbarkeit rund um die 23 anderen Projekte der Mitglieder...\n2 W&#xF6;chentlicher Rhythmus - wir wollen den Marathon auch zu Ende laufen\nWorkshops haben klare Ziele innerhalb der Zeitboxen\n\nZiel: Menschen k&#xF6;nnen/kennen kollaborative Arbeitsweisen zuwenig - meistens haben sie das letzte mal wirklich an was &#x201C;neuem&#x201D; mit anderen zusammen in der Schule gearbeitet...\n
- #14 Aufteilen der Komplexit&#xE4;t mit bestehenden Mitteln\nAK nach IREB priorisieren (baseline)\nPersonas (f&#xFC;r wen machen wir es) mit GMV gepimpt\nSzenarios und Storymaps um die Kontexte und die grunds&#xE4;tzlichen &#x201C;Stolpersteine&#x201D; zu identifizieren\nStories um das &#x201C;Prozessdenken&#x201D; zu spiegeln -> Diskussion Definition von Szenario, Stories ist noch interessant - Literatur auch nicht immer konsistent.\nDepth follows Breath\n
- #15 Von Papier/Whiteboard scribbles an den Workshops zu\nWireframes mit Balsamiq zu\nVisuellen Design Mocks zu\nAusf&#xFC;hrbaren Prototypen -> Produktionscode\n
- #16 Zwischen (m&#xF6;glichst) allen Detaillierungsstufen UX Evaluationen\nUX Evals mit Endkunden bereits mit den ersten Designmocks geplant\nTesten nach Einf&#xFC;hrung f&#xFC;r Datenerhebung\nInjera (Ethiopische Nationalgericht) auch ein langes Evaluieren\n
- #17 Es gibt immer offene Fehler\nBereits erkannt Verbesserungen\nNoch nicht umgesetzte Funktionalit&#xE4;ten\n
- #18 Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You &#x201C;Work&#x201D; Is What You Get\n2, respektive 4 w&#xF6;chentliche &#x201C;reviews&#x201D;\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und &#x201C;Ertragskontrolle&#x201D; vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen k&#xF6;nnen fr&#xFC;her und konkreter &#x201C;abgeholt&#x201D; werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
- #19 Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You &#x201C;Work&#x201D; Is What You Get\n2, respektive 4 w&#xF6;chentliche &#x201C;reviews&#x201D;\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und &#x201C;Ertragskontrolle&#x201D; vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen k&#xF6;nnen fr&#xFC;her und konkreter &#x201C;abgeholt&#x201D; werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
- #20 Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You &#x201C;Work&#x201D; Is What You Get\n2, respektive 4 w&#xF6;chentliche &#x201C;reviews&#x201D;\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und &#x201C;Ertragskontrolle&#x201D; vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen k&#xF6;nnen fr&#xFC;her und konkreter &#x201C;abgeholt&#x201D; werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
- #21 Methodenanpassungen immer n&#xF6;tig\nBedienen aus dem Methodenrucksack\nDas richtige Werkzeug f&#xFC;r das Problem\nKontinuierlicher Kompetenzaufbau aller Beteiligten - Lernen macht spass und tut gar nicht weh! Echt!\nGeduld haben - Grosse Organisationen k&#xF6;nnen sich nicht so rasch &#xE4;ndern - wenn kein externer Druck da ist.\n
- #22 Nicholas DeWolf (July 12, 1928 &#x2013; April 16, 2006) was co-founder of Teradyne, a Boston, Massachusetts-based manufacturer of automatic test equipment. He founded the company in 1960 with Alex d&#x2019;Arbeloff, a classmate at MIT.[1][2]\nHe was born in Philadelphia and he graduated with an S.B. in EECS from MIT in 1948.[3]\nDuring his eleven years as CEO of Teradyne, DeWolf is credited with designing more than 300 semiconductor and other test systems, including the J259, the world's first computer-operated integrated circuit tester.[4]\nAfter leaving Teradyne in 1971, DeWolf moved to Aspen, Colorado, where in 1979, he teamed with artist Travis Fulton to create Aspen's "dancing fountain".[5] DeWolf also designed a computer system without hard disks or fans; this system (the ON! computer) booted up in seconds, a much faster time than even the computers of today.[citation needed]\n
- #23 \n