Verfahrensmodell für. Web-Projekte

Transkript

1 Verfahrensmodell für Web-Projekte

2 Verfahren: Web-Projekt-Kreislauf 1. Ziel 6. Messen 2. Audit 5. Umsetzung 3. Konzeption 4. Planung Web-Projekte

3 Wenn alle durcheinander reden Web 1.0 Social Web Media 2.0 Social Multi Media Sided Broadcast Dialog (Rückkanal) Konversation (Vernetzung) Websites werden dynamisch

4 Der rote Faden zum erfolgreichen Projekt 1. Ziele im Internet 2. Analyse Trends & Umfeld 3. Benutzerrollen und Personas 4. Benutzerverhalten 5. Inhalte und Funktionen 6. Prozesse & Verfahren 7. UX Design 8. Rechtssicherheit 9. Systemarchitektur und Entwicklungsumgebung 10. Planung und Umsetzung 11. Ressourcen Web-Projekte

5 Web-Projekt: Schritt 1 Ziel setzen (Vision)

6 Was wollen wir im Internet erreichen? Ziele

7 Hypothese "Eine Hypothese (altgriechisch ὑπόθεσις, hypóthesis = Unterstellung, Voraussetzung, Grundlage ) ist eine Aussage, der Gültigkeit unterstellt wird, die aber nicht bewiesen oder verifiziert ist." Quelle: Wikipedia Ziele

8 Bis zum < > will <Organisation> über das Internet <Benutzer> in den <relevanten Zielgruppen> <direkt kennenlernen> und diese im Dialog <schnell zugänglich, einfach bedienbar und optisch ansprechend> mit Informationen und Diensten zu <Angebote> versorgen, um <Motiv> zu erreichen. Ziele

9 Projektziele richtig planen Ein gutes Ziel ist S pecific M A R T easurable ttainable elevant ime-based Ziele

10 Web-Projekt: Schritt 2 Analyse Bedarf erkennen

11 Was sind andere Angebote im Internet?

12 Komplexes Beispiel: Flughafen ETIS / EDMO (?) Potenzielle Konkurrenten Bedrohung durch neue Konkurrenten Airlines Lieferanten Verhandlungsstärke der Lieferanten EDJA EDDF EDDN Rivalität unter bestehenden Unternehmen EDMA Verhandlungsmacht der Kunden Retail Kunden Infrastruktur / Partner Bedrohung durch Ersatzprodukte und -dienste Ersatzprodukte Bahn, Fernbusreisen, Individualverkehr (Auto), Videokonferenzen und Online-Meetings (Google Hangouts etc.) PAXe Verändertes Medien- nutzungsverhalten Analyse

13 Audit des Status quo bei anderen und eigener Website

14 Website Audit Analyse

15 Web Response messen

16 Analyse

17 Zusammenfassung der Analyse (Beispiel: SWOT)

18 Interne Analyse Stärken Download-Bereich (Software/Dokumente) Umfangreiche Trainings und Schulungen Mehrsprachigkeit Innovative Verfahren Hoher Service- und Qualitätsanspruch Differenzierung vom (online/offline) Registrierung einfach Schwächen Viele Funktionen ohne Mehrwert Usability/Navigation Nummern statt Namen Kein Dialog im Web Fehlende Daten/ Informationen Keine Speicherung von Bürgerdaten Datenpflege System-Zoo Analyse

19 Externe Analyse Chancen Dialog im Web Bekanntheit des Angebots Produktsuche undinformationen entsprechen den Bürgerbedürfnissen Eigene Behörde wird Benchmark Verbesserung der Bürgerbeziehung/ Zufriedenheit Problem bei den Wurzeln packen Risiken Heterogene Anforderungen der Zielgruppen Informationsstrategie anderer ist bürgerfreundlicher als unsere Fehlendes Know-how Seifenblasenproduktion Mega-Projekt; Perfektionismus Datenmissbrauch Hohe Erwartungshaltung der Benutzer Analyse

20 Workshop in der Praxis Analyse

21 3. Schritt Auswertung Analyse

22 Auswertung SWOT-Analyse Beantwortung folgender Fragen: Welche Stärken passen zu welchen Chancen? Welchen Risiken können wir mit welchen Stärken begegnen? Wo können aus Schwächen Chancen entstehen? Wo befinden sich unsere Schwächen Wie können wir uns vor Risiken schützen??? Analyse

23 Fazit SWOT-Analyse Stärken und Chancen Hoher Service- und Qualitätsanspruch führt zur Differenzierung und zum Benchmark (online/offline) in der Branche. Stärken und Risiken Das umfangreiche Informationsangebot wird durch zielgruppenspezifische Funktionalität angegangen. Schwächen und Chancen Mangelhaft implementierte Prozesse zur Datenpflege, Datenlücken und fehlende Schnittstellen zwischen den Systemen können durch die Neustrukturierung mithilfe von modernster IT-Architektur und Definition von Zuständigkeiten behoben werden. Schutz vor Risiken Durch eine klare Projektstruktur und Verwendung agiler Projektmethoden kann der Produktion eines Megaprojekts vorgebeugt werden. Analyse

24 Web-Projekt: Schritt 3 Personas User Role Modeling

25 Mit wem wollen wir kommunizieren? (Benutzer)

26 Entwicklung von Personas Web-Konzept

27 Schule Referendarin Direktor Lehrerin Klassensprecher Schulsprecher Eltern Schüler Oberstufe Redakteur Schülerzeitung Grundschüler Web-Konzept

28 Konto oder Lebenslage Web-Konzept

29 Mit User Role Modeling schnell zu Personas Mit wem wollen wir kommunizieren? Personalisieren Persona-isieren Ein Mensch hat mehrere Rollen Web-Konzept

30 Beispiel: Flughafen Web-Konzept

31 Web-Projekt: Schritt 4 Benutzerverhalten Web Activity Cycles

32 Start Ziel 1 Großer Schritt Viele kleine Schritte 2 Benutzerverhalten

33 Hilfsmittel: Web Acticity Cycle Empfehlung Start Zufriedenheit Vergleich Bewertung Feedback Ziel Post During Pre Verfahren & Informationen Aufmerksamkeit Interesse Lösung Idee und Nutzen Wunsch Beratung Beantragung Benutzerverhalten

34 Beispiel: Verfahren Veranstaltung Ideen Pool Firmen-Events Feiern Formate Vertrieb Start Veranstaltung planen Share Media Collateral Trade Shows Sales Call Website Search Engine Landing Page Social Media Blog Kongresse Meetings Tagungen Seminare Klein-Messen Product Launch Empfehlung Aufmerksamkeit Keywords / Tags HTML Referenz Cross/up post pre Konzept Interesse Organisation Formate SEO PDF Video Bericht Bewertung Kontakt Print Schema Ziel Erfolgreiche Veranstaltung during Buchung Dokumentation Vorbereitung MQL Logistik Abbau Durchführung Logistik Aufbau Reinigung Hinweise Veranstalter Ansprechpartner Contact Hinweise Besucher Sicherheit Agentur Vertrieb Benutzerverhalten

35 Beispiel: Web Activity Cycle Benutzerverhalten

36 Überlegungen... Motive und Ziele? Was MUSS die Rolle wissen? Was ist der nächste Schritt? Wie kann man die Rolle wertschätzen? Welche Medien? Wann? Welche Endgeräte? Wann? Weiterempfehlungen? Benutzerverhalten

37 Noch etwas komplexer Dependant Cycle Sub-Cycle Brüche Vorwärts oder rückwärts Benutzerverhalten

38 Web-Projekt: Schritt 5 Inhalte und Funktionen Schnittstellen zu Verfahren, ÖA (Classic) und Marketing

39 Web-Projekt: Schritt 6 UX Design Responsive

40 Benutzerakzeptanz als Ziel Usability Maus, Finger, Sprache, Wireframes Responsive, Seitentypen, Widgets, Creative Designs Key Visuals, Typografie, Mock-ups, Landing Pages Content, CTAs, UX Design

41 Frameworks nutzen UX Design

42 Web-Projekt: Schritt 7 Verfahren Datenbanken und Dokumente Online Marketing

43 Prozesse definieren und automatisieren Closed-Loop Keine Medienbrüche Keine Systembrüche Bearbeitungsstatus Automatisierung Benachrichtigungen Verfahren 43

44 Web-Projekt: Schritt 8 Datensicherheit Datenschutz

45 Web-Projekt: Schritt 9 Systemarchitektur Entwicklungsprozess Frameworks

46 MVC - Model View Controller Presentation Logic Interfaces & Access Processing & Workflow View Controller Data Database & Storage Model

47 Ruby on Rails Framework für Web-Anwendungen Web-Application-Framework Open Source 65k+ GEMs Bessere Code-Struktur Model-View-Controller (MVC) Integrierte Tests Sprache } Ruby on Rails { Framework Skalierbar Share-Nothing Opinionated Software Convention over configuration

48 Ruby on Rails im Vergleich Punkte 110 Ergebnisvollständigkeit (Entwicklungszeit) der Lösungen 82, ,5 0 Java JavaScript Perl PHP Ruby Punkte 24 Robustheit der Lösungen Java JavaScript Perl PHP Ruby Effektivität im Entwicklungsprozess (hier: Automated Tests) Punkte Java JavaScript Perl PHP Ruby Quelle: Freie Universität Berlin in Zusammenarbeit mit Heise Verlag (ix) und OSBF, Results Oktober 2011

49 Web-Projekt: Schritt 10 Projekt-Management Planung und Umsetzung

50 88%...aller Projekte verlaufen nicht, wie ursprünglich geplant. Nicht nur Flughäfen, Bahnhöfe oder Philharmonien. Web-Konzept

51 Zur Erinnerung Ein gutes Ziel ist S pecific M A R T easurable ttainable elevant ime-based Web-Konzept

52 Web Activity Cycle nutzen Web-Konzept

53 Projektziele richtig planen Mit User Stories zur Zielklarheit Als <Benutzerrolle> verfüge ich <Funktion>, um <Nutzen> zu erreichen Sammlung im Backlog Web-Konzept

54 Projektziele richtig planen Prioritäten werden in M o S C o W must hould ould on't bestimmt Web-Konzept

55 Projektziele richtig planen 1 Risiko 3 2 Nutzen Web-Konzept

56 Projektziele richtig umsetzen Backlog Sprint Backlog 2-4 Wochen pre post Product Priorität Story Nutzen Risiko 1 Ziel Ziel Ziel Ziel Ziel Pläne sind nichts, Planung ist alles. Web-Konzept

57 Zeitplan Q3/2015 Q/ Beispiel Web-Konzept

58 Projektziele formulieren Das optimale Team 3-5 Personen Pair-Programming Web-Konzept

59 Projektumsetzung Produktstrukturplan Online- Aktivitäten Basissystem Mobile Online- Marketing Zielgruppen Content Werbung-/ PR Rahmen- bedingungen Technik Design Content- Altbestand Templates Kontakt- Datenbank User Role 1 Social Media U Strategie CMS Usability Templates Mobile Content Kampagnen- Management User Role 2 SEM/SEO Erfahrung en Relaunch Portal-/ Website Creative Design SEO- Strukturen Registrierung/ Lead Generierung User Role 3 Adveritising Rechtssicherheit Betriebsumgebung Landing Pages Migration Anfrage- Management User Role 4 Public Relations IT-Standards XHTML/CSS HTML5 Newsletter/ E- Mail-Marketing User Role 5 Interne Prozesse Corporate Design Altbestan d HTML5 Tracking/ Analytics/ Reports Interne Prozesse 3rd Party Systeme 3rd Party Systeme Beispiel Web-Konzept

60 Projekte umsetzen

61 Projektmanagement kann jeder. Oder doch nicht? Wenn man Projektmanagement macht, dann muss allen klar sein, was damit gemeint ist. Wer hat welche Rolle in dem Projekt? Welche Aufgaben hat die Rolle? Welche Dokumente sollten vorhanden sein? Welche Meetings sollten abgehalten werden? Was wird in den Meetings besprochen? Methode vor dem Projekt bestimmen. Bestimmung des Projektverantwortlichen beim Kunden (Produkt Owner) Methode während des Projekts einhalten. Bestimmung der Team Member Bestimmung eines Scrum Masters Spielraum für Ad-hoc-Action (<10%)

62 Was ist ein mittleres Projekt? Mehrere Team-Mitglieder aber nur ein Team Bsp.: 2 bis 6 Mitglieder Unterschiedliche Dienstleistungen notwendig Bsp.: Programmierung, Design, Konzept, Admin Einmalige Ausführung Bsp.: Relaunch der Website oder Einrichtung ecrm Ausführungszeitraum unterjährig Bsp.: 3 Wochen bis 4 Monate Aufwand über mehrere, zusammenhängende Tage Bsp.: 10 bis 150 Tage Aufwandschätzung

63 SCRUM Product-Backlog Sprint-Backlog Sprint Software Quelle: "Der Scrum-Prozess" Wikipedia lauffähig, inkrementrell verbessert

64 Zusammenfassung Scrum Rollen Prozess Meetings Dokumente Product Owner: PO setzt Prioritäten Kunde vorheriger Sprint Produkt Backlog Inkrement aktueller Sprint (ca. vier Wochen) Rahmenbedingungen Planung Moderation: SM, alle nehmen teil, 1/2-2 Tage Input: Produkt Backlog und Rahmenbedingungen Output: Sprint Ziel und Sprint Backlog Ablauf: PO zeigt Ziel und Top-Prioritäten T schätzt den Aufwand, nimmt die priorisierten Anforderungen entgegen und erstellt detaillierte Einträge im Sprint Backlog Produkt Backlog Liste der Anforderungen & Probleme Verantwortung: PO Jeder kann Einträge hinzufügen Nur PO priorisiert Sprint Ziel Zusammenfassung in einem Satz durch PO Muss von PO und T akzeptiert werden Scrum Master: SM managed Prozess entfernt Blockaden Infopark Team Members: T entwickeln Ergebnis/Produkt Infopark Planung vorheriger Tag (8h) aktueller Tag (8h) Status Arbeit nächster Tag (8h) Review Produkt Backlog Sprint Ziel Sprint Backlog Problemliste Ergebnis/ Produkt Burndown Chart Inkrement Status Moderation: SM, alle nehmen teil, 15 Min. PO ist nur Beobachter und Antwortet auf kurze Frage von T T: Berichten kurz den Status und aktualisiert das Sprint Burndown Chart - Was habe ich gestern gemacht? - Was mache ich heute? - Welche Probleme gibt es? SM aktualisiert Problemliste Review Moderation: SM, alle nehmen teil, 2-3 Std. Format: Informativ und informell Ablauf: - Demo & Diskussion des Inkrements - PO akzeptiert oder lehnt Inkrement ab - SM kündigt nächstes Planungs-Meeting an Retrospektive Moderation: SM, nur T (kein PO), 2-3 Std. Ablauf: - T berichten über Erfolge und Probleme - T diskutieren Verbesserungen im Ablauf Sprint Backlog Je Eintrag des Product Backlog eine Liste der damit verbundenen Aufgaben. Verantwortung: T Tägliches Update von Status & Schätzung durch T Nur T führt Veränderungen durch PO darf das Ziel nicht ändern Problemliste Liste der aktuellen Hindernisse: technische oder organisatorische Blockaden, offene Entscheidungen Verantwortung: SM, tägliches Update Burndown Chart Produkt & Sprint Visualisiert den Fortschritt und die Geschwindigkeit des Teams, tägliches Update Akzeptanzkriterien Testen ob Anforderungen erfüllt sind Muss von PO und T akzeptiert werden Stakeholder: SH beobachten und beraten Kunde nächster Sprint Produkt Backlog Inkrement Rahmenbedingungen Abbruch (selten) Einberufung durch SM, wenn T berichten das Sprint-Ziel nicht erreichen zu können Ablauf: Analyse der Umstände und Lösung Inkrement Nutzbares Ergebnis am Ende des Sprints Entspricht Anforderungen und Tests Öffentliche Informationen Scrum Dokumente und andere Dokumente für Transparenz gegenüber SH

65 Was macht der Produkt Owner? Als Auftraggeber vertritt er die fachliche Sicht, stellt Anforderungen, beurteilt die Umsetzung im Hinblick auf Funktionalität, Usability und Performance. Wie macht er das? Pflege des Product Backlogs vertritt die fachliche Auftraggeberseite und somit sämtliche Stakeholder priorisiert das Produkt Backlog so, dass der Business Value des Produkts maximal wird und die Möglichkeit früher Releases von Kernfunktionalität besteht, um einen schnellen Return on Investment zu erreichen wohnt nach Möglichkeit den Daily Scrums bei, um sich (passiv) zu informieren steht für Rückfragen des Teams bereit Was macht er nicht? Rolle des Chefs für das Team übernehmen Daily Scrums moderieren oder ungefragt dort reden Während des Sprints den Sprint Backlog beeinflussen (Zusatzanforderungen, Streichung von Aufgaben etc.) im Projekt als Team Member (z.b. Entwickler, Software-Architekt) mitarbeiten (Interessenkonflikt!) versuchen, gleichzeitig den ScrumMaster zu mimen (Interessenkonflikt!) seine Aufgabe nur zu Beginn und am Ende der Sprints wahrnehmen

66 Was macht der Scrum Master? Als Moderator des Prozesses sorgt er für einen zielgerichteten Prozess, für Dynamik aber nicht für Chaos und insbesondere für die Einhaltung der Regeln. Wie macht er das? trägt Verantwortung für den Scrum- Prozess und dessen korrekte Umsetzung ist ein Vermittler und Unterstützer (Facilitator) strebt maximalen Nutzen und ständige Optimierung an beseitigt Probleme und Hinternisse (!) mahnt offene Entscheidungen an sorgt für Informationsfluss zwischen Product Owner und Team moderiert Meetings hat die Aktualität der Dokumente im Blick schützt das Team vor unberechtigten Eingriffen während des Sprints Was macht er nicht? Rolle des Chefs für das Team übernehmen das Projekt in dem Sinne leiten, dass er ansagt, wer welche Arbeit auf welche Weise zu erledigen hat Doppelfunktion als Team Member oder Product Owner übernehmen (Interessenkonflikte!)

67 Web-Projekt: Schritt 10 Ressourcen-Planung

68 Project Asset Management Infrastruktur Tools Methode Finanzen Zeit Ziele

69 Tipps zum Vorgehen

70 Step-by-Step 1. Audit 2. Zukunftstag 3. Interviews 4. Workshops für Personas & Customer Journey 5. Usability & Creative Designs 6. Ergebnis-Präsentation 7. Konzept 8. Ausschreibungsunterlagen Web-

71 Checkliste Web-Projekt 1 2 Konzept Vorlage 3 4 Präsentationen Plan Web-

72 Ergebnis Leitungsebene überzeugt Projekt-Status erreicht Bedarf erzeugt Dringlichkeit dargestellt Mittel freigegeben Beschaffung gestartet Web-

73 Ihre Fragen Q&A

74 Vielen Dank für Ihre Aufmerksamkeit Bernd Völcker Tel twitter.com/infopark youtube.com/infoparkag Infopark AG Kitzingstraße 15 D Berlin