Wer sind unsere Kunden für das Newssystem?
10. Juni 2009 Roland
- Erstellen eines Newssystems
- Akteure im Newssystem
- Newssystem Anwendungsfälle für den Systemadministrator
- Newssystem Anwendungsfälle für den Editor
- Newssystem Anwendungsfälle Zusammenfassung
- Newssystem Anwendungsfälle Webuser
- Anwendungsfall Add Category
- Anwendungsfall Add Editor to Category
- Anwendungsfall Change Editor
- Nebenläufigkeiten beim Editieren von Newseinträgen
- Anwendungsfall Create Editor
- Anwendungsfall Delete Category
- Anwendungsfall Delete Editor
- Anwendungsfall Edit Category
- Anwendungsfall Remove Editor From Category
- Anwendungsfall Show Editors
- Anwendungsfall Show Categories
- Anwendungsfall Add Image to Newsentry
- Anwendungsfall Create Newsentry
- Anwendungsfall Delete Image
- Anwendungsfall Delete Newsentry
- Anwendungsfall Edit Image Data
- Anwendungsfall Edit Newsentry
- Anwendungsfall Navigate in Newslist
- Anwendungsfall Remove Image from Newsentry
- Anwendungsfall Search Image
- Anwendungsfall Search News
- Anwendungsfall Set Presentation Times
- Anwendungsfall Upload Image
- Anwendungsfall Navigate Archive News Shortentries
- Anwendungsfall Navigate Shortentries
- Anwendungsfall Show Archive Newsentry
- Anwendungsfall Show Newsentry
- Anwendungsfall Show Shortentries
- Aufbereiten der bisherigen Anwendungsfälle
- Technische Anwendungsfälle
- Nebenläufigkeiten beim Lesen von Newseinträgen
- Lasst uns mal über Performancemessung reden
- Erste Gedanken zum Backup und Restore für unser Newssystem
- Zwischenschicht zur Performancemessung einbauen
- Performancemessungen ein- und ausschalten
- Performance Messung auf dem Server durchführen
- Newssytem Daten Modellieren
- Anwender Aktionen loggen
- Geschäftsmodelle erkennen
- ImageModel Beschreibung
- Installierbarkeit des Newssystems
- Housekeeping im Newssystem
- Anwendungsfall SearchNotUsedImages
- UserModel Beschreibung
- Meldungsverwaltung und Severity Bestimmung im Newssystem
- UserModelFactory
- Einsatz eines Frameworks für die Erstellung des Newssystems
- Ist das Newssystem einfach nur eine View auf eine Blogsoftware?
- Factory- und Adapter Pattern für die Erweiterung von WordPress
- Wieso will ich das Newssystem nicht als WordPress Plugin erstellen?
- Newssystem gesundschrumpfen
- Wer sind unsere Kunden für das Newssystem?
- Requirements für Newssystem erfassen
- Rahmenbedingungen für das Newssystem
- Entscheidung wie das Newssystem jetzt umgesetzt werden soll
- Welche Tools können wir zur Anforderungsverwaltung einsetzen?
- Verwalten der Anforderungen
- Namensänderungen im Newssystem Modell
- Ein Tool für die Anforderungen
- Komponenten die im ersten Sprint umgesetzt werden sollen
- Auf der Suche nach einem Tool um Anforderungen zu erfassen
- Security fummelt man am Besten gleich in die Architektur hinein
- Security Komponenten Klassendiagramm
- wie schrumpft man das System Gesund?
Dirk hat sinnvollerweise nachgefragt wer eigentlich unser Newssystem kaufen soll.
Ich habe da im Kommentar so lapidar gesagt, dass Ute, Jozo und ich die Kunden sind.
Im Prinzip stimmt das auch.
Ute hat bei miradlo im Moment eine kleine Eigenkonstruktion im Einsatz mit der unsere Kunden ihre News verwalten können.
Die Kunden sind voll glücklich, da dass Newssystem wirklich minimal ist und nur das macht, was ein Newssystem machen soll.
Es generiert News.
Wenn wir das Newssystem jetzt “in Groß” bauen, dann soll es einfach ein bisschen Mächtiger sein und ein wenig einfacher zum Verwenden sein.
Ute und ich wollen also das neue Newssystem für weitere Kunden, aber auch für die bestehenden Kunden einsetzen.
Vermutlich werden wir bei den bestehenden Kunden kein großes Geld damit verdienen, ihnen aber ein angenehmes Update liefern. Damit sind die Kunden mehr zufrieden und kaufen eventuell ein paar mehr Dienste bei miradlo.
Außerdem werden sie vielleicht miradlo weiterempfehlen und so ist es eine schöne Werbemaßnahme so ein Tool zu bauen.
Ganz nebenbei lernt Jozo, Ute, die Menschen die hier mitmachen und ich eine ganze Menge.
Jeder soll das Teil nachher einsetzen können. Also so ein bisschen Open Source Gedanke gelle?
Deshalb möchte ich im Moment die Definition, wer unsere Kunden sind, so festlegen:
miradlo, und somit Ute, ist Hauptkunde da wir das Bedürfnis haben ein etwas passenderes Newssystem für unsere Kunden anbieten zu können.
Dirk ist auch Kunde da du, lieber Dirk, ja im Moment so fleißig mitmachst und somit die Gestaltung des Systems mitbestimmst.
Der Entscheid, was in das System reinkommt und was nicht, wird von miradlo gefällt. Wir werden auf alle Fälle die Wünsche von Dirk, und falls noch weitere Personen sich einklinken auch deren Wünsche, mit einbauen.
Klingt das gut?
Was haltet ihr davon?
Wäre das für unser Newssystem eine passende Stakeholder Analyse oder habe ich alles voll falsch verstanden?
Der Beitrag wurde
am Mittwoch, den 10. Juni 2009 um 00:28 Uhr veröffentlicht
und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=1418
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed![]()
Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.









Ich fühle mich gar nicht als Kunde, ich bin immer nur Lieferant
Tja so schnell kanns gehen gelle?
Bin ich mit einverstanden
Wenn wir mal von grossen Projekten einige Stufen zurückgehen, bleiben drei Gruppen, die sich über das Produkt einig werden müssen.
1. Fachabteilung oder Business (vertreten durch Ute)
2. Entwicklung oder Development (vertreten durch Dich)
3. Betrieb oder Operations (vertreten durch mich)
Du stehst zwischen 1. und 3. im wirklichen Sinn.
Die Fachabteilung versucht die eierlegende Wollmilchsau zu bekommen, stösst aber irgendwo an Budgetgrenzen.
Die Entwicklung versucht so viel wie möglich für die Fachabteilung zu implementieren, so lange es das Budget zulässt, der Code wartbar bleibt und versucht die Randbedingungen des Betriebs zu erfüllen, um einen reibungslosen Ablauf zu sichern.
Der Betrieb bemüht sich, Forderungen nach Schlankheit und Sicherheit durchzusetzen und den Aufwand für Backup und Restore möglichst klein zu halten.
Die Fachabteilung hat immer das Problem, dass sie vorher nicht genau weiß, was nachher gebraucht wird. Kunde #1 will es so, Kunde #2 lieber anders.
Deshalb immer der Wunsch nach möglichst viel Konfigurierbarkeit.
Andererseits hätte ich gern gestern eine schnell realisierte Lösung.
Klar, das passt nicht und ist unmöglich.
Beispielsweise das Thema Bild zur News, das ist ja der Hauptgrund, warum wir über ein neues Newssystem nachdenken.
Habe ich jemand, der zu jeder News genau ein Bild möchte und jedesmal auch ein anderes Bild dafür nutzen möchte?
Ist dieser Kunde jemand, bei dem eine Person an einem Rechner dieses Bild einbindet?
Oder habe ich mal mit, mal ohne Bild, häufig dasselbe Bild mehrfach?
Habe ich einen Kunden, z.B. einen Verein, bei dem die Menschen, die News einstellen regelmäßig wechseln?
Wenn ich diese Fragen sicher mit je nur einer Variante beantworten könnte, dann wäre es einfach.
Aber genau das geht nicht, sprich Entwicklung und Betrieb wollen von mir die klare Antwort. Ich muss dann entscheiden, worauf ich tatsächlich bereit bin zu verzichten, um eine Lösung in Zeit und Budget zu bekommen.
Genau darum geht es.
Im Zweifel hilft auch eine Umfrage bei den bestehenden Kunden.
Ansonsten ist die Frage, wie viel Zeitaufwand (oder Geld) in ein “Konfigurationswerkzeug” gesteckt werden soll, wenn es nur fünf Mal verwendet wird. Lohnt sich dann vielleicht eher eine kundenspezifische Konfiguration auszuliefern?
Ich muss die beiden Links noch eben loswerden, weil sie gerade wirklich gut passen:
http://www.projectcartoon.com/cartoon/3439
(Interessant – ausser den Lachern zwischendurch – ist das erste und das letzte Bild, in dem Zwiespalt sind wir gerade).
Und der ist auch nicht schlecht:
http://pm-blog.com/2007/04/20/der-tagtagliche-projektwahnsinn/
Hallo Dirk, hallo Ute,
ich denke wenn man mit einer Methode wie SCRUM vorgeht, kann man während der Projektlaufzeit die Fachabteilungsfragen beantworten.
Man baut ja nicht alles auf einmal…
Bei Projektmanagement-Methoden bist Du der Experte. Für mich ist SCRUM für solch ein kleines Projekt Overkill. Das gilt auch für Prince2 (meinen Favoriten).
Ich habe die Erfahrung gemacht, dass Projekte ohne klare Anforderung entweder nie fertig werden oder zu einem “Wünsch Dir was” verkommen.
Dass der Kunde vor der Abnahme noch Änderungswünsche hat, ist der Regelfall, den man auch einplanen sollte.
Naja,
SCRUM muss nicht dick sein.
Ich möchte auch nur “SCRUM like” vorgehen.
Das bedeutet, dass wir einfach definieren was wir in der nächsten Zeit liefern wollen und dann “hopp der Bese!”
Ansonsten passiert, was du so richtig sagst: “Wünsch dir was” und werde nicht fertig.
Das möchte ich vermeiden.
Vor allem, weil wir ja nicht unbedingt vollzeit an diesem Projektchen arbeiten.
Soviel ich weiss, sind wir alle irgendwie woanders gut ausgelastet
Ausgelastet? Ich habe mich gerade von zwei langjährigen Aufgaben trennen müssen …
Du Armer!
Wenn es dir langweilig wird, dann darfst du gerne hier in Winterthur vorbei kommen
Wir haben noch ein wenig was zu tun…
Dieser Philosophie kann ich zustimmen