An der Internet Expo im Jahre 2001 hielt ich den Vortrag über Projekt Management bei Internet Projekten. Der Vortrag ist unverändert hochgeladen inkl. den “weltweiten” Namics-Standorten aus der betrunkenen Zeit (Internet Bubble.)
4. Augenmerk auf die Systementwicklung
Strategie Analyse Konzeption Implemen- Roll-Out Betrieb Aus- Weiter-
tierung wertung entwicklung
Prozess-Organisation
Marketing
Management
Technik
„Endlich hacken ;-)“
5. Anwendungstypen
» Internet- resp. Webanwendungen werden
häufig noch mit „Webseiten“ verwechselt.
» Zahlreiche Webanwendungen sind heute
unternehmenskritisch.
» Teilweise Ablösung von hocheffizienten aber
proprietären SW-Clients mit Benutzungs-
schnittstellen in Webbrowser.
» Anforderungen bei der Projektumsetzung sind
je nach Anwendungstyp gigantisch anders.
7. Anwendungstyp:
Statische Website
» Merkmale
– Statische Seiten (HTML,
JavaScript etc.) und
wenig serverseitige
Logik.
– Geringe Wartung,
sporadische
Weiterentwicklung.
– Information und evt.
Web-Server
Interaktion.
– Webmaster jongliert.
– Hosting irgendwo.
8. Anwendungstyp:
Dynamische Website (Webanwendung)
» Merkmale
– Teils statische teils dynamisch
erzeugte Webseiten.
– Bereiche werden online
gepflegt, koordinierte
Weiterentwicklung.
Firewall – Integration eines Content
Management Systems (CMS)
Load Balancer und/oder kleiner Anwendungen
(AWP).
Web-Server Web-Server – Unternehmensweit verankert.
Information, Interaktion und evt.
CMS / AWP CMS / AWP Transaktion.
– Hohe Verfügbarkeit und (evt.)
Sicherheit, leistungsfähiges
Hosting.
9. Anwendungstyp:
Dynamische Website (Webanwendung)
» Merkmale
Dispatcher
– Eigene und fremd erstellte
Seitenelemente werden
Partner dynamisch gemischt.
– Komplexe Weiterentwicklung
Cashing als Managementaufgabe,
Stdby Partnermanagement.
Country
Firewall / LB – Synchrone und asynchrone
Integration unterschiedlichster
Web-Server Bank Content Anwendungen.
– Hochgradig integriertes
Middleware / Application Bus Informationssystem.
CRM ERP PPS Pymt Pricing
– Verteiltes System mit höchster
Verfügbarkeit und
Skalierbarkeit, individuelles
Bank Marktpl. Hosting/Homing.
10. Webprojekte: Was ist speziell?
» Ist weder Printkampagne noch eine SAP
Implementation…
» Hohe Durchdringung und Auswirkung.
» Sehr häufig kurze Zeitpläne.
» Fast alle SW ist unreif (beta, beta, beta).
» Und…
11. Webprojekte:
Integration vom Kompetenzen
Consulting
Interdisziplinäre
Teams:
» Integration
unterschiedlichster
Kompetenzen und
Charakteren
» Andere Wertesystem
» Andere Sprache
» Andere nonverbale
Kommunikation
Technology Design
13. Achtung!
» Wir befinden uns in der Implementierung und gehen
davon aus, die früheren Phasenresultate existieren in
guter Qualität;-)
14. Top 10 Mistakes (die ersten fünf)
» Das Budget ist nicht wichtig, wir brauchen die Site.
» Ein Zeitplan ist dank dem iterativen Vorgehen
überflüssig.
» Für die Zustimmung der Geschäftsleitung sorgen wir
uns intern im Rahmen unseres üblichen Reportings.
» Für die Spezifikation des Systems fragen Sie mich
einfach sobald die etwas brauchen; Ich bin kein Fan von
Dokumentationen.
» Inhalt haben wir mehr als genug -- auch in vier
Sprachen.
15. Top 10 Mistakes (der Rest)
» Seventh Party Syndrome.
» Den Inhalt und die Sitesuche haben wir mit der CMS-
Software TopQuarkFettPro im Griff.
» Wegen dem Termin haben wir noch ein paar
Programmierer dazugenommen.
» Ich will keine Usabilitytests durch Endbenutzer, die
nehmen uns und nur den Drive. Unser IT-Leiter testet
die Sache persönlich.
» Zum Glück gehen wir in zwei Wochen live, dann läuft
der Karren endlich und die Sache ist vorbei.
16. Budget
Ein definiertes Budget und dessen dauernde
Überwachung schaffen Vertrauen.
» Das Budget ist nicht das Sparschwein für die
Dienstleister aber ein wichtiges Planungs- und
Kontrollinstrument.
» Unterschiede zu anderen Projekten (z.B. Werbung oder
IT) erzeugen oft Misstrauen.
» Frühzeitige Zuordnung des Budgets zu Arbeitsschritten,
Ressourcen und Personen.
» Einigkeit über die Struktur der Rapportierung und dem
Modus der Verrechnung.
17. Budget: Aufwand-Verlauf Plan und Ist
Plan
Aufwand
Ist
Beginn
Umsetzung Testing
Review
Kick-off
Live- Zeit
Schaltung
19. Zeitplan
Der Zeitplan ist das zentrale Instrument zur
Projektkommunikation und -steuerung.
» Kein Projektvorgehen entbindet von der Erstellung eines
Zeitplans (Szenarien).
» Der Zeitplan dient vor allem auch der Ressourcen-
allokation und der Abstimmung mit externen Partnern.
» Er erlaubt die Konsistenzprüfung mit anderen
Planungsinstrumenten und gehört dauernd angepasst.
» Es gibt nie zu viele Meilensteine.
20. Zeitplan: Ein A4 Blatt für alle Beteiligten
Eindeutige
Tasks mit ID
Wer
Meilensteine:
Inkl. Builds etc.
Ferien
21. Zeitplan: Iterationen
1. B » Iteration erlaubt Durchspielen
R des „ganzen“ Ablaufs.
A
I » Eine Iteration dauert 4 bis 6
T Wochen.
2. B D
R » Am Ende wird über die Reife
A des Phasenproduktes
I entschieden.
T
3. B D
R
A
I
T
D
22. Unterstützung der Geschäftsleitung
Je umfassender ein Projekt ist, desto wichtiger
ist die dauernde Präsenz eines GL-Mitgliedes.
» Projekttyp ist meist neuartig und sehr IT-lastig.
» Kenntnisstand der GL ist sehr wichtig für die Qualität der
Entscheide.
» Ein Webprojekt hat häufig einen massiven Einfluss auf
bestehende Prozesse und Strukturen.
» Bestehende Richtlinien tragen den neuen Technologien
selten Rechung (z.B. Security, oder
Arbeitsplatzsoftware).
23. Spezifikation
Die Anforderungsdefinition der zentralen
Projektaspekte ist zwingend.
» Spezifikationsdokumente sind nicht Prosatext in dicken
Bundesordnern.
» Konsensfindung sowohl auf Kundenseite wie auch im
interdisziplinären Projektteam passiert weder per Zufall
noch mündlich.
» Webprojekte sind Weltmeister in dauernden marginalen
Änderungen.
25. Spezifikation: Consulting
Marktanteil erhöhen Kunden-
Durchgehendes Design Preis Neue Zielgruppen befragung
G estaltung/ Belohnung für Branchenführer
2-Sprachigkeit
O pass
berfläche Internetkauf
Internet-
Marktbearbeitung zu neuen
Zugang
Kunde hat auch S
Frischer Auftritt
Leader wie C
bei Banken
S im Internet Marktsegmenten
Internet-Adresse Nr. für den Kunden
Offerten Neukundenanmeldung
Beschleunigung
Auskunft Lieferzeit Auftragsbearbeitung
Kundenbindung Bestellsystem Unterstützung
Kundenbindung Innovatives Auftrags- von G eschäfts-
Image
Persönliche R
Beziehung zum
ückmeldung an
den Kunden
information
transaktionen
Unternehmen Prozessunterstützung
Bestell- Verfügbarkei
schaffen transparenz ts-abfragen
Nicht nur verkaufen, Wettbewerb Preisinfo
Schnell- auch beraten Link zu CD-ROM
service
Support 24h- Unterlagen
Nutzinhalt/
Flexiblere Lieferbedingungen hotline bestellen Interaktivität
Einkauftrends
Bestellzeiten
E-Mail-
Ansprechpartner Neue Produkte Sortiment Finanzauskunft
Vorstellung der
Fundgrube Infor über
Auskunfs- Effizienter Firma
Veranstaltungen
Dienst bestellen
wie Messen Diskussions-
forum
Kunden selbständig
untereinander
kommunizieren
lassen
Prozessübersicht Beispiel AG
08.08.2000
Draft V 0.8, E1B1
Einkauf Vertrieb Auftragserfassung
Kunde akquirieren
«system»
«system»
ERP-System
«department» CRM-System
Vertrieb Rahmenvertrag entwerfen
[nicht einverstanden]
«business process» Rahmenvertrag prüfen
Verkauf
[einverstanden]
«department»
Auftragserfassung «customer»
Einkauf
Rahmenvertrag unterzeichnen
«business process»
Herstellung
«department»
Produktion Bedarf ermitteln Beschaffung vorschlagen
«business process»
Auslieferung «customer»
Wareneingang
Lieferanten auswählen [nicht erfolgreich]
«department»
Logistik Artikelauswahl Auftrag akquirieren
«precondition»
{Bonität des Kunden muss bereits überprüft sein.}
[erfolgreich]
«third party»
Spediteur Auftrag erteilen
Auftrag entgegennehmen
Auftrag erfassen
«business process»
After Sales
Auftrag bestätigen
«department» «customer»
Kundendienst Anwender
Prozessablauf "Verkauf"
8.8.2000
Draft V0.1, E1B1
«system»
CRM-System
27. Spezifikation: Arbeit mit Prototypen
Strategie, Vision und Grobkonzept Usablity
Richtlinien
Design UI and IT
Vorstudie
Navigation
IT
CI/CD HTML Proto 1
Prototyp
Usablity
Test
Konzeption
Design IT
HTML Proto 2
Iteration Prototyp
Usablity
Test
Review IT
HTML Proto 3
Design Prototyp
Implementation
29. Honey, I've Shrunk the Content
Mediengerechte Inhalte in guter Qualität sind
sehr aufwändig in der Erstellung.
» Leute die gute Text/Inhalte für online Medien verfassen
sind sehr selten.
» Häufig werden bestimmte Daten erstmals Kunden
gezeigt (Bsp. Auftragszusatztexte)
» Der Dienstleister (die Agentur) kann die Inhalte nicht
selbst verfassen ;-(
» Budget ist schon aufgebraucht.
30. Seventh Party Syndrome
Grosse IT-lastige Projekte brauchen viele Third
Parties – „Ich bin nicht schuld“
» Glasklar definierte Verantwortlichkeiten.
» Regelmässige und straff geführte Reviews.
» Sonst verbringen alle nur noch ihre Zeit damit, gut
Argumente dafür zu suchen, dass der andere Schuld ist.
31. Tools
„A fool with a tool is still a fool“.
» Weder die SW noch ein Werkzeug nimmt inhaltliche
Arbeit ab.
» Finden auf einer Site ist Sache der (guten) Struktur,
Sprache, Konsistenz und Design (und nicht Search
Engine).
» Ein CMS ermöglicht die verteilte Inhaltspflege, macht
aber weder Autoren noch Inhaltsverantwortliche
Arbeitslos.
» Etc.
32. Add (no) manpower
Das optimale Team hat so wenig Leute zu 100%
wie nur möglich.
» Geschwindigkeitsgewinn mit mehr Leuten setzt die
Teilbarkeit der Aufgabe voraus.
» Percentage Paradoxon: N Leute kommunizieren mit n-1
Leuten…
– 10 mal 30% ist nicht gleich 300%.
– Es macht keinen Sinn das gewünschte Projektteam in
20%-Commitment-Einheiten zusammenzukratzen.
33. QS/Testing
Qualität entsteht nicht durch Prüfung ist aber
das Resultat der Arbeitsweise alle Beteiligten.
» Qualität entsteht nicht bei der Q-Abteilung aber ist eine
Arbeitseinstellung.
» Häufige Reviews, Tests, Prüfungen v.a. aber auch
Arbeitsmethodik, Techniken u.s.w.
» Geplante Tests werden nicht wegen einer Verzögerung
im Zeitplan ausgelassen.
» Kein Projekt ist so geheim dass nicht (extern) getestet
werden kann.
34. QS/Testing: Min. drei Kaskaden
Programmierumfeld
development „Non Standard“
Publikation: Manuel
Testumfeld, Inhaltserfassung
staging „Identisch“ live
Versionierung Publikation: Automatisiert, wiederholbar
Rollback
Produktionsumfeld
live Skaliert, sicher, etc.
35. Endlich Live
Mit der Live-Schaltung des Webprojektes endet
das Projekt nicht; Es beginnt der Betrieb.
» Der Betrieb einer anspruchsvollen Webpräsenz kann
deutlich aufwändiger sein als dessen Bau.
» Keine exotischen I*Irgendwas-Abteilung aber integriert
die Unternehmensprozesse.
» Going Live
– Schulung und interne Information
– Unternehmenskommunikation (intern und extern)
– Webannouncement
– Nachzügler
– Feedbackprozesse
37. Immer mitnehmen ;-)
» Voraussetzungen schaffen (Wissen, Kultur, Budget,
Sponsoring).
» Klare und durch alle getragene Vision.
» Spezifikation.
» Eine „Buchhalter“ der Zeit und Ressourcen plant und
kontrolliert.
» Interdisziplinäre Teams mit wenig sehr guten Leuten
bilden.
» Kurze Iterationen für sämtliche Arbeitsprozesse.
» Standards einspielen (v.a. Integration und QS).
39. Referenzen
» The Mythical Man-Month : Essays on Software
Engineering. Frederick P., Jr. Brooks.
» Collaborative Web Development: Strategies and Best
Practices for Web Teams. Jessica R. Burdman.
» Projektmanagement mit dem Rational Unified Process.
Gerhard Versteegen.
» Rapid Development: Taming Wild Software Schedules.
Steve C McConnell
40. Vielen Dank für Ihre Aufmerksamkeit
juerg.stuker@namics.com
Frankfurt, Genf, Konstanz, Lausanne, Los Angeles, Milano, San Francisco, St.Gallen, Zug, Zürich
info@namics.com www.namics.com team–based net solutions
Hinweis der Redaktion
Gute Strategie Integration
Testanforderungen: Wann hat ein Modul den Test bestanden? Verantwortung über Testprozess Was soll genau getestet werden? (Funktionalitäten, Design) Funktionalitäten der Testprozeduren sind festzuhalten Alle Testergebnisse sind nach Versionen geordnet zu archivieren Prozeduren zur Evaluation der Testdaten erstellen.