Design slashdiscussion hgieldanowski.key

206 Aufrufe

Veröffentlicht am

Veröffentlicht in: Business
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
206
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 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
  • Pf ein groß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ür pf -> nur 37 Filialen (PF.) \n
  • Der Dino fletscht seine Zähne....\nDesign mal weggelassen: Wie kann auf diesem Kanal schneller, kostengünstiger eine vollständige "Filiale" werden? Für 2.5 Mio Kunden , Potential?\n\nProduktmanager stehen vor grossen Herausforderungen.\nNatürlich machen die sich Gedanken, und holen sich auch externe consultants...\n
  • Wie lassen sich diese Schlagworte richtig fassen - denn auch vorstellen.\nEmotionalitä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
  • Klassische wenn auch überspitzte Situation.\nStarke Hierarchien und Arbeitsteilungen verhindern auch Synergien (5 Agenturen - will noch jemand??)\nIT konzentriert sich auf das was sie können - Technologie - vielfach daher alles technologiezentriert.\n\nDaneben kommt noch das metoden Korset...\n
  • Hermes PF als projektmethode. Wasserfall für everyfall... In den Phasen Studie, grob und detailkonzept wird die Anwendung spezifiziert..\nRealisierung ist Freestyle...\nWas ist der Schmerz mit Hermes?\n
  • Kostenschätzungen basieren auf Erfahrungen (overestimation biase) und nicht auf Anforderungen\nDetails werden nicht frühzeitig genug berücksichtigt\nPlanungen/-sicherheit: ist schwierig da vorhandene Skills und notwendiges Know-how (Aufbau) nicht berücksichtigt werden\nKostendächer: Pauschal(reisen) Aufwendungen von Externen sind schwierig zu steuern, respektive ein Mgt. von Lieferobjekt und Kosten ist praktisch unmöglich\nAnforderungen nach IREB sind theoretisch ok, praktisch aber nicht “bewertbar”\n\nKönnte Scrum et al die Lösung sein?\n
  • 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
  • sprich “das was Apple” macht wird als “weToo” betrachtet.\nUsability ist ein “Test”, am Schluss\nPersonas sind “Puppen” -> Barby und Kent -> für die Website -> wir haben “auch welche”.\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
  • 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
  • Zeitboxen in Anlehnung an SCRUM\n2 Typen: Ramp-ups und eigentliche Iteration\n Nicht zu gross und nicht zu klein -> 4 Wochen\n “Planbare Grösse”\n Ich weiss ob ich nächsten Monat Ferien habe oder nicht\n Ich weiss das aber nicht in zwei Monaten..\n \nKleiner Ramp-Up -> Organisatorisches, Grundsätzliches (IA, Personas, etc.)\nInterationen bestehend aus Konzept, Spezifikation, Implementation, Test\n\nZiel: Menschen haben “Probleme” mit sich wiederholenden Zyklen - man will was “abschliessen”, weglegen, “Er”-ledigen. Schwierig für menschen etwas immer wieder zu verfeinern.\n
  • Sitzungen zu Workshops\n\nWorkshops als Ankerpunkte der Iteration\nPlanbarkeit rund um die 23 anderen Projekte der Mitglieder...\n2 Wöchentlicher Rhythmus - wir wollen den Marathon auch zu Ende laufen\nWorkshops haben klare Ziele innerhalb der Zeitboxen\n\nZiel: Menschen können/kennen kollaborative Arbeitsweisen zuwenig - meistens haben sie das letzte mal wirklich an was “neuem” mit anderen zusammen in der Schule gearbeitet...\n
  • Aufteilen der Komplexität mit bestehenden Mitteln\nAK nach IREB priorisieren (baseline)\nPersonas (für wen machen wir es) mit GMV gepimpt\nSzenarios und Storymaps um die Kontexte und die grundsätzlichen “Stolpersteine” zu identifizieren\nStories um das “Prozessdenken” zu spiegeln -> Diskussion Definition von Szenario, Stories ist noch interessant - Literatur auch nicht immer konsistent.\nDepth follows Breath\n
  • Von Papier/Whiteboard scribbles an den Workshops zu\nWireframes mit Balsamiq zu\nVisuellen Design Mocks zu\nAusführbaren Prototypen -> Produktionscode\n
  • Zwischen (möglichst) allen Detaillierungsstufen UX Evaluationen\nUX Evals mit Endkunden bereits mit den ersten Designmocks geplant\nTesten nach Einführung für Datenerhebung\nInjera (Ethiopische Nationalgericht) auch ein langes Evaluieren\n
  • Es gibt immer offene Fehler\nBereits erkannt Verbesserungen\nNoch nicht umgesetzte Funktionalitäten\n
  • Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You “Work” Is What You Get\n2, respektive 4 wöchentliche “reviews”\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und “Ertragskontrolle” vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen können früher und konkreter “abgeholt” werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
  • Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You “Work” Is What You Get\n2, respektive 4 wöchentliche “reviews”\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und “Ertragskontrolle” vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen können früher und konkreter “abgeholt” werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
  • Argumentarium\n\nPlanbarkeit operativ besser - Ressourcen, Geld \nWhat You “Work” Is What You Get\n2, respektive 4 wöchentliche “reviews”\nStakeholder, respektive Vertreter end-to-end involviert\nKosten und “Ertragskontrolle” vorhanden, Gesamtkosten (hoffentlich) tiefer\nErwartungen können früher und konkreter “abgeholt” werden - es wird eine gemeinsame Erwartungshaltung aufgebaut - No expectation - no disapointment.\nSpass - Erfolgreich arbeiten macht spass!\n
  • Methodenanpassungen immer nötig\nBedienen aus dem Methodenrucksack\nDas richtige Werkzeug für das Problem\nKontinuierlicher Kompetenzaufbau aller Beteiligten - Lernen macht spass und tut gar nicht weh! Echt!\nGeduld haben - Grosse Organisationen können sich nicht so rasch ändern - wenn kein externer Druck da ist.\n
  • Nicholas DeWolf (July 12, 1928 – 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’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
  • \n
  • Design slashdiscussion hgieldanowski.key

    1. 1. HOW TO MAKE A DINOSAUR AGILE 1
    2. 2. 2 Releases6 OE’s10 Quartiere30 Programme400 Projekt-Ma.1.2 Mio. Kunden OnlineSchwergewicht 2
    3. 3. 3
    4. 4. Emotionalität! Begeisterung! CustomeriUsability Experience Productmanager 4
    5. 5. ..übrigens - wir ..und einfach arbeiten jetzt mit 5 alles mitIT 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. 6. meet... HERMES!Studie Grobspezifikation Detailspezifikation Re ali sie run g 6
    7. 7. Der Schmerz mit Hermes 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. 8. “Katholische Agilität”? ..in nomine Budgetplanung agilis..!! Ressourcenplanung Hierarchien KulturSetzt unternehmensweiten Changevoraus! 8
    9. 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 abin die Ferien. 9
    10. 10. Wie man einem Dinosaurier dasfliegen beibringt1. Wasserfall > Iteration2. Sitzungen > Workshops n,3. Grosser Happen > kleine Bissen se e r, ei t l t öt A g o de n4. Vorstellen > Visualisieren A elt th5. Glauben > Evaluieren Al tm6. (Ab)Liefern > Verbessern 10
    11. 11. 1. Wasserfall zu Iteration 2 Zeitbox Typen mind the size Planbar Ramp-Up Box (field) Iterationen Box (carrot) Gefühl für Iteration ent wickeln 11
    12. 12. 2. Sitzungen zu WORKshops Ankerpunkte der Iteration Ziele Planbarkeit * 23 Rhythmus Kollaboration ent wickeln 12
    13. 13. 3. Grosses Problem zu kleinenHappen Baseline Anforderungskatalog Personas (mit GMV gepimpt) Szenarios und Storymaps Stories Depth follows Breath Holistische Sicht weise trainieren 13
    14. 14. 4.Visualisieren, visualisieren,visualisieren Papier / Whiteboard Wireframes Visuellen Design Mocks Ausführbaren Prototypen Produktionscode Lernen Ideen zu visualisieren 14
    15. 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. 16. 6. Projekt endet nicht mit demDeployment 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. 17. Argumentarium (Auszug) Planbarkeit WYWIWYG Reviews, Feedbacks Stakeholder-Involvement ROI, Gesamtkosten Erwartungskonformität Spass.. 17
    18. 18. Wo das gerade läuft 3 unterschiedliche Projekte Unterschiedlicher Umfang Unterschiedliche Komplexität Interne und Externe Mitarbeiter 18
    19. 19. Was wir erreichen wollen Projekte erfolgreich einführen Erfahrungen sammeln -> Proof Common Ground schaffen Auf dem Radar auftauchen UCD / UX etablieren ...dem Dino einen “Schubs” geben 19
    20. 20. Was wir bisher gelernt haben Customize! Methodenrucksack Das richtige Werkzeug für das Problem Kompetenzaufbau Geduld -> Change <- Geduld 20
    21. 21. "What the customer demands is last years 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! Computer21
    22. 22. @hgieldanowski gieldanowski.ch--311076.5 22

    ×