Transparenz erhöhen bei einem Webprojekt
Ich habe eine interessante Anfrage erhalten, und ich bin mir nicht ganz sicher wie man das Problem am besten lösen kann. Vielleicht könnt ihr ja einige Tipps geben, was man da machen kann.
Die Situation ist folgende: Der Auftraggeber hat ein Webseitenprojekt in Auftrag gegeben bei einer Internetagentur, aus Mangel an Wissen über IT-Projekte wurde der Vertrag nicht besonders straff gestaltet, viele Dinge wurden nicht spezifiziert, der Hauptgegenstand war ein Click-Dummy und einige kleine Listen mit Dingen, die umgesetzt werden sollen. Es wurde ebenso kein Zeitplan/Meilensteine festgelegt, mündlich wurden Versprechungen wie „Ende April ist es fertig“ gemacht. Nun ist es Mitte Juni, die öffentlich sichtbare Webseite ist unter einer Testdomain ansehbar (ca. 15 Seiten mit 2-3 Formularen und etwas Javascript). Der HTML/CSS/Javascript-Code sieht soweit gut aus. Mehr kann man allerdings noch nicht sehen.
Zum Projekt gehört auch ein „eingeloggter Bereich“ sowie eine Anbindung an einen Zahlungsdienstleister und an ein Transportunternehmen, und die Internetagentur hält den Auftraggeber nun seit mehreren Wochen hin, dass der Rest der Webseite nun noch nicht fertig ist da die Schnittstellen noch nicht fertig sind. Da nichts im Vertrag festgelegt ist gibt es Aussagen der Internetagentur wie „Da hätten Sie sich drum kümmern müssen dass die Schnittstelle bei den Dienstleistern eingerichtet wird“, und es wird versucht, Geld nachzufordern. Die Spannung und der Ärger steigt also langsam an.
Und nun die Frage: Was kann der Auftraggeber machen, um die Webseite nun endlich fertig zu bekommen, bzw. erstmal herauszufinden, wie weit denn nun der Fortschritt ist? Hätte die Internetagentur auch zum eigenen Schutz auf mehr Details und einen strafferen Vertrag bestehen müssen? Kann man nachträglich noch einen verbindlichen Zeitplan festlegen? Kann der Auftraggeber nun irgendwie Transparenz erhalten und Zwischenergebnisse der Schnittstellen und des Admin-Bereichs fordern, oder hat er nur ein Recht auf das Endergebnis, das „irgendwann geliefert wird“? Was würdet ihr tun?
Ich würde sagen: Beide Seiten haben Fehler gemacht. Der Auftraggeber dahingehend, dass er sich keinen Anwalt für die Vertragsaufsetzung hinzugezogen hat, der Auftragnehmer dahingehend, dass sie so keine Seriösität zeigen und es selbst wenn es jetzt vielleicht keine rechtlichen Konsequenzen hat, durchaus massive Nachteile durch den schlechten Ruf nach sich ziehen kann.
Auch mündlich geschlossene Verträge sind rechtswirksam. Theoretisch könnte der Auftraggeber den Auftragnehmer vors Gericht ziehen – mangels Beweisen aber würde Aussage gegen Aussage stehen.
Lösung ist eigentlich einfach: Neuer Vertrag mit festen Bedingungen, abgesichert durch einen mit solchen Verträgen vertrauten Anwalt.
Aber so einfach ists nicht, wenn sich eine der Parteien unvernünftig zeigt. Was ja nicht selten der Fall ist…
Schwierige Situation.
Patrick
19 Jun 11 at 19:04
Hallo Michael,
sofort die Sourcen einfordern und die Zusammen arbeit beenden. Durch Bewertung eines Externen (evtl. Sachverständigen) könnte man sich evtl. auf einen Vergleich einlassen. Je besser die eigenen Karten, weil irgendwo was schriftliches, desto weniger wird es kosten.
Auf keinen Fall die Nachforderungen annehmen. Das würde sich evtl. bei einer anwaltlichen oder gerichtlichen Auseinandersetzung sehr negativ äußern.
Abhaken, lernen und nicht mehr den erst besten und billigsten Dienstleister nehmen.
Grüße,
Nico
Nico
19 Jun 11 at 19:14
Sourcen fordern und mit Hilfe eines vertrauten Fachmanns den Status fest stellen. Dann soweit flicken, dass es online gehen kann und schon währenddessen jemanden finden, der die weitere Betreuung übernimmt.
Wenn nachträglich Gelder gefordert werden für Sachen, die schon im Preis drin sein sollten, dann sollte man hellhörig werden. Sowas kann mal passieren, aber dann sollte man als Auftragnehmer so ehrlich sein und sofort darauf hinweisen und nicht erst warten bis der Zug abgefahren ist.
Oliver
19 Jun 11 at 20:30
Hallo,
eine wichtige Frage ist: wieviel Geld ist bereits geflossen?
Ich würde (als Kunde) wie folgt vorgehen:
– alle Mails, Briefe, Chatprotokolle usw. archivieren
– die Gespräche über den Umfang der Seite und gemachte Zusagen wahrheitsgemäß schriftlich zusammenfassen und der Agentur mit Fristsetzung zur Korrektur geben. Damit hat man zumindest ansatzweise eine nachvollziehbare und beweisbare Grundlage geschaffen
– Die Internetagentur um Herausgabe der geleisteten Arbeiten im Quellcode oder FTP-Zugang mit Fristsetzung – ggf. im Umfang der bisher gezahlten Beträge.
– Entweder man verträgt sich und schließt auf der Basis der so gewonnenen Erkenntnisse ein Pflichtenheft für die verbleibenden Leistungen oder die herausgegebenen Daten werden an eine neue Agentur übergeben, die dann die Arbeiten beendet.
Aus meiner Erfahrung ist bereits der zweite Schritt sehr heilsam, da sich beide Parteien über das Gewesene Gedanken machen müssen und es unterschreiben müssen.
Thomas
Thomas
19 Jun 11 at 20:56
Sehe ich leider so wie der Satz den viele Werkstätten zu hören bekommen „Machen sie das Auto TÜV-fertig.“ Soll was bedeuten? Lediglich sicherheitsrelevante Mängel beseitigen? Oder Auto aufpolieren und den Auspuff von innen putzen?
Das Problem in so einer Situation ist das, dass meistens ein Laie (Kunde) auf einen Experten (Auftragnehmer) trifft. Woher soll der Kunde wissen das er Schnittstellen irgendwo bereitstellen muss? Wie soll der Kunde den Umfang abschätzen können? Wie beurteilen könne ob der Zeitplan durch Schludrigkeit oder aus Gründen überschritten wurde?
Im Grunde genommen gibt es für den Kunden in so einer Situation nur eins: Lehrgeld zahlen und einen besseren suchen.
Ob die Agentur alle Sourcen raus rückt dürfte fraglich sein. Zum einen kann sie behaupten das es keine weiteren gibt. Zum anderen wird sie nur das raus geben was sie bezahlt bekommt. Im Zweifellsfall also nichts.
Hier kann nur ein Anwalt weiter helfen. Und das ist im Großen und Ganzen auch der einzige (vernünftige) Tipp den man geben kann.
Für die Zukunft sollte man sich einen unabhängigen Berater hinzuziehen. Das kann auch der IT-Student sein dem man 100-200 Euro für ein paar gute Ratschläge in die Hand gibt. Eine zweite, unabhängige Meinung ist in jeden Fall nicht verkehrt.
Ralf
19 Jun 11 at 23:36
Die Beschreibung der Situation ist mir zu sehr von der Sicht des Auftraggebers gefärbt und noch zu farblos, als dass ich mich auf eine Seite schlagen möchte.
<<Zum Projekt gehört auch ein “eingeloggter Bereich”
Wie soll das Einloggen geschehen? Gibt es eine Definition und Erreichbarkeit der Datenbasis und die Agentur hat nichts geliefert oder hat der Auftraggeber bisher nur den Wunsch aber keine Daten geliefert? Aus Deiner Beschreibung geht nicht hervor, ob die Agentur alle Daten hat, um das überhaupt umsetzen zu können.
<<eine Anbindung an einen Zahlungsdienstleister und an ein Transportunternehmen
Gibt es die Schnittstellen samt Dokumentation oder sind diese noch in Planung und für den Dienstleister nicht testbar und damit programmierbar?
Wenn die eingeplanten Schnittstellen zum Zahlungsdienstleister und Transportunternehmen tatsächlich nicht zur Verfügung stehen, kann die Agentur herzlich wenig dafür. Man kann nur etwas anbinden was auch existiert und ausreichend dokumentiert ist.
Des weiteren habe ich auch schon Auftraggeber erlebt, die absichtlich nicht näher spezifizieren, um den Dienstleister später leichter unter Druck setzen und damit nachträglich den Preis drücken zu können. Sich "dumm zu stellen" ist in Chef-Etagen ein beliebtes Mittel um die Verantwortung an andere abzuwälzen, die sich zu Aussagen und Versprechungen hinreißen lassen.
Oder aber es wird zugesichert, dass Informationen und Material zeitnah geliefert wird, was in der Praxis dann aber nicht passiert. Das verhärtet die Fronten recht schnell – der Auftraggeber ist verärgert, weil er nicht das bekommt, was er sich vorgstellt hat und der Dienstleister sieht keine Basis für eine fruchtbare Zusammenarbeit.
Hier hilft eventuell das offene Gespräch und/oder eine Umstellung auf agiles Projektmanagement, was den Kunden zum einen mehr in die Pflicht nimmt, ihm aber andererseits auch neue Methoden der Projektsteuerung eröffnet.
<<Was würdet ihr tun?
Ich würde als Auftraggeber klar das Gespräch mit dem Dienstleister suchen und fragen, wo genau es hakt und wie man das abstellen kann, um das gemeinsame Ziel möglichst doch noch zu erreichen. Dabei sind Vorwürfe wenig zielführend. Erst wenn sich dann immer noch keine Lösung abzeichnet, würde ich die bisher erarbeiteten Sourcen einfordern und gegebenenfalls die Rechnung wegen nicht erfüllter Arbeitsleistung kürzen.
Gruß, Daniel
DSB
20 Jun 11 at 00:08
Seh’s wie viele Vorredner – um ein Gespräch führt nichts herum.
Ich bevorzuge Agenturen, die in ihre Arbeit Einblick bieten, z.B. durch kollaborative Projektmanagementsoftware. Über einen Kundenzugang sieht man sofort, wie weit das eigene Projekt schon ist und wieviel Zeit hineingeflossen ist. So lassen sich Missverständnisse leichter klären bzw. entstehen erst gar nicht, und auf Abweichungen vom geplanten Projektverlauf kann rascher auch von Kundenseite reagiert werden.
Tanja Handl
20 Jun 11 at 11:03
@Daniel:
Ich weiß zwar auch nicht mehr als in dem Artikel steht, gehe jedoch bei „Zahlungsdienstleister und Transportunternehmen“ davon aus das es sich um größere Unternehmen handelt die bereits entsprechende Schnittstellen bereit stellen. Und in der Regel gibt es auch entsprechende Dokumentationen und manchmal auf Anfrage auch Testzugänge für Entwickler.
Als Agentur einen Fertigstellungstermin versprechen wenn nicht alle Daten,Zugänge und Unterlagen vorliegen, halte ich ein wenig fahrlässig. Sicherlich kommt es immer mal wieder vor das z.B. Grafik von einem Grafiker und nicht von der Agentur geliefert werden. Aber gerade dann sollte man sich mit Zusagen und Deadlines arg zurück halten.
Auf der anderen Seite, aus der Sicht der Agentur, würde ich mal sagen das man als Programmierer auch mal einen Auftrag zurück geben sollte. Wenn Material nicht kommt, Spezifizierungen sich ständig ändern, der Kunde ständig irgendwo Preise drücken will, dann sollte man sich mal Gedanken darüber machen was wirtschaftlicher ist. Sich auf unabsehbare Zeit mit einem Kunden rum ärgern oder sich lieber von diesen Kunden zu trennen. Andauernde Auseinandersetzungen mit einem Kunden bedeuten letzten Endes auch nur verschwendete Zeit und damit Geld das zum Fenster raus fliegt. Diese Zeit kann man schließlich keinem Kunden in Rechnung stellen.
Ralf
20 Jun 11 at 18:20
Es ist in der Tat nach wie vor problematisch das viele Freelancer, Agenturen und Auftraggeber keine vernünftigen Verträge und Pflichtenhefte abschließen. Projekte können sich wärend der Laufzeit ändern, dass ist klar. Aber trotzdem sollte man vorher vereinbaren was man für welches Geld bekommt.
Ich würde dringend mit der gesamten existierenden Kommunikation (emails etc.) zu einem Anwalt gehen und eine Erstberatung machen. Kann in Berlin gerne jemanden empfehlen.
Im Rahmen dessen aus der Gesamtkommunikation mal eine Art Pflichtenheft ableiten und dann überprüfen inwieiweit diese Arbeiten bisher erledigt wurden und ob noch zuarbeit von der Auftraggeberseite aussteht. Solange die nicht vorliegt, kann man nämlich auch schlecht Nacherfüllung fordern.
Und dann den Sachstand in einem persönlichen Gespräch mit der Agentur klären und gemeinschaftliche Lösungswege suchen.
In dem Gespräch merkt man dann schon recht schnell ob die Agentur Lösungen anbieten kann und will oder ob Sie sich vll. selbst mit dem Projekt übernommen hat und ihr einfach die Skills fehlen um z.b. die Schnittstellen zu programmieren.
Nach dem Gespräch eine schriftliche Vereinbarung über den weiteren Verlauf oder Abbruch des Projekts anfertigen und ggf. eine neue Agentur suchen.
Von der Freelancer Seite betrachtet, kann ich dazu auch nur immer wieder einen Vortrag bei Creative Mornings SFC empfehlen: http://webcrowd.net/2011/06/06/fck-you-pay-me/
Ivo
20 Jun 11 at 22:34
Stimme DSB voll zu.
Ich finde die Beschreibung der Situation auch etwas farblos und mit dem Unterton des betrogenen Auftraggebers. Auch ich kenne aus Erfahrung die anderen Version: der Auftraggeber streicht 90% der Features (Volltextsuche, ach das braucht man nicht), es wird auch alles vertraglich festgehalten, alle Funktionen der Webseite wurden erfasst und beschrieben. Dennoch wird die Abnahme verweigert, da z.B eine Suche doch zum Standard gehört und wir hätten ihn schlecht beraten und arglistig getäuscht. Klar, der Kunde gehört zur der Sorte die auch gleich mit dem Anwalt drohen – wenn man alles schriftlich hat reicht ein Hinweis darauf und die Tonart ändert sich schnell wieder 😉
Meine Erfahrung sagt: Diese Kunden gibt es und wird es immer geben. Die gibt es auch in jedem Bereich.
Dennoch ist der erste Fehler eigentlich schon bei den ersten Gesprächen passiert, weil wir den Kunden falsch eingeschätzt haben und uns dadurch schon haben beeinflussen lassen. Beim Schreiben des Angebots hat die Routine – glücklicherweise – doch wieder gesiegt und wir haben unser detailliertes Standardverfahren (genaue Beschreibung der Funktionen, Zeitfenster zur Umsetzung bestimmter Teilbereiche, Grundlagen der Kalkulation wie Std-Sätze etc., wann ein Mehraufwand angezeigt wird … und so weiter) ins Angebot geschrieben. Auch das wollte der Kunde eigentlich nicht, „Schreib mir das doch kurz per Mail, dann kann ich es später noch auf dem iPhone lesen“).
Leute lasst euch nicht auf diese Alles-Easy-Alles-kein-Problem-Geschichten ein – bleibt seriös und ziel-orientiert (auch wenn andere Beteiligte alles locker sehen). Schreibt bei Besprechungen alle besprochenen und gegebenenfalls alle Definierten Punkte mit und erstellt ein Protokoll des Meetings. (Ich bewundere keine Superhirne die auch bei einem 6-Std-Meeting nicht mitschreiben brauchen 😉 Und nie vergessen: Ein gerichtliches Verfahren zieht sich über Jahre – das kürzeste dauerte bei uns etwa 18 Monate.
Nicht immer ist es die böse Agentur, manchmal kann es auch ein Drittanbieter sein, der ein Projekt zum wanken bringt.
Grundsätzlich gehen wir immer (so ungefähr) nach folgenden Punkten vor – klar gibt es auch hier Ausnahmen, aber Menschenkenntnis und eine gute Nase habe noch nie geschadet 😉
1. Erst mal miteinander sprechen, wenn man seine Hausaufgaben gemacht hat, ist man eigentlich auf der sicheren Seite und kann mit Argumenten auch einen möglichen Mehraufwand erklären.
2. Erneut genaue Ziele und Fristen … definieren und aufschreiben gegenzeichnen (lassen) !!! – manchmal ist es auch besser in Kleinigkeiten nachzugeben und das Projekt doch noch ohne Anwälte abzuschließen.
Wenn der Kunde ein weitere Zusammenarbeit nicht möchte, ist es manchmal besser sich einfach seine Arbeitszeit bezahlen zu lassen und den Kunden gehen zu lassen.
Aber diese Schritte haben hier schon einige festgehalten.
Gruß, chris
s
chris
20 Jun 11 at 23:21
Vielen Dank an euch alle, viele wichtige Dinge sind angesprochen worden.
Ja, in diesem Fall kenne ich nur die eine Seite und habe auch nur diese erläutert bekommen. Es hat mittlerweile ein weiteres Gespräch mit der Internetagentur gegeben, und Ende der Woche soll es einen Systemtest geben, ein Ende ist in Sicht. Woran die Verzögerung nun wirklich gelegen hat wird man wahrscheinlich nicht herausbekommen, vielleicht war es ja auch einfach ein Engpass beim Personal da ein höherpriorisiertes Projekt dazwischengekommen ist, wer weiß.
Auf den Kosten durch die wochenlange Verzögerung wird der Auftraggeber wohl sitzen bleiben und es als Lehrgeld verbuchen müssen. Wenn es wichtig ist dass ein Projekt pünktlich fertiggestellt wird, sollte man diesen wichtigen Fakt unbedingt schriftlich festhalten. Auch sollte bei allen Projekten die über Hobby-Webseiten hinausgehen und wo viel Geld fließt ein Lastenheft (+Pflichtenheft) erstellt werden, auch wenn es 5 oder 10 Stunden Aufwand kostet, es kann einem viel Zeit und Ärger am Ende sparen wenn es darum geht was nun gemacht werden sollte und was nicht, man hat außerdem schon die meisten Punkte für die Abnahmeprüfung parat, so kann es für beide Seiten keine bösen Überraschungen geben.
Michael Kliewe
20 Jun 11 at 23:58
Dies ist ein gutes Beispiel für eine Situation, die mit agilem Projektmanagement, wie z.B. Scrum, gar nicht entstehen kann. Das alte Wasserfall-Modell (Lastenheft, Dienstleister programmiert, am Ende Abnahme nach viel Diskussionen) passt aus meiner Sicht einfach nicht zur Entwicklung von schnelllebiger Software im Webbereich.
Deshalb bin ich froh, dass wir, wann immer der Kunde mitspielt, auf Scrum setzen. Hier stellt der Kunden einen Product-Owner, der Prioritäten setzt, Aufgaben umpriorisieren kann und stets über alles Bescheid weiß, weil er der Teil des Prozesses ist und ihn maßgeblich steuert. Die hier beschriebenen Schmerzen kenne ich glücklicherweise kaum noch. 😉
Gruß, Daniel
DSB
21 Jun 11 at 10:33
Tja, ich finde da hat die Agentur allerdings schon recht – externe Schnittstellen sind ein häufiger Streitfall.
Was die machen können ist die API-Beschreibung für die Schnittstellen anzufordern und das dann bei den Partnern in Auftrag zu geben. Das ist ganz klar ein Versäumnis der Projektleitung – sowohl beim Kunden als auch beim Dienstleister. Der Kunde hätte es wissen, aber der Dienstleister ihn auch erinnern können.
Ich stimme der Einschätzung zu – auf den Kosten wird er sitzen bleiben.
@DSB Oh doch, diese Situation entsteht dauernd in einem agilen Scrum-Team. Weil viele zwar behaupten Scrum zu machen aber gar keine Ahnung davon haben.
Scrum ist die perfekte Ausrede alles auf’s Projektteam abzuschieben. Anforderungen werden gar nicht erst erhoben. Wäre doch Aufgabe der Developer – wenn die nicht nachfragen: Pech gehabt. Müssen sie eben Überstunden machen.
Product-Owner? Kann keine Prioritäten setzen – dazu müsste er wie man den Business-Value bestimmt. Oder User-Stories so schreibt, dass man sie auch testen kann.
Business-Analysten und Projektmanager werden als Product-Owner eingesetzt – ohne Schulung in Requirements Engineering. Diese Aufgabe bleibt dann am Entwicklungsteam hängen: welche das aber gar nicht leisten kann.
Das Problem setzt schon vor Scrum an. Beim Kunden ist ein VERKÄUFER und verkauft ein Produkt, dass er nicht hat zu einem politisch motivierten Preis und einem politisch motivierten Liefertermin und zu keinem Zeitpunkt wird ein Techniker konsultiert und die Frage gestellt, ob das überhaupt machbar ist. Der Verkäufer bekommt eine Provision pro Vertragsabschluss, ist nicht Teil des Teams und kann für ein Scheitern des Projektes nicht zur Verantwortung gezogen werden. Da liegt der Hase im Pfeffer.
Daran ändert sich auch mit Scrum nichts. Man kann in Scrum sogar mit Festpreisen problemlos arbeiten. Vorausgesetzt: man macht das Projekt nicht schon im Verkauf kaputt bevor es überhaupt begonnen hat.
Ich arbeite mit meinen Auftraggebern auch nach Scrum mit Festpreisen: nach Budgetsystem. Kunde überweist einen festen Betrag für ein festes Feature-Set, kann die Features im Rahmen des Budgets aber beliebig umbauen. Droht er sein Budget zu übersteigen, bekommt er eine Warnung. Dann stockt er entweder auf oder streicht seine Features zusammen. Geld welches er nicht verbraucht, wird gutgeschrieben und später verrechnet. Funktioniert prima.
Einige machen es auch mit gemischten Modellen: Wasserfall + Stundensatz für Dinge außerhalb des Pflichtenheftes. Intern kann man das wieder auf Budgets und Business-Value umrechnen. Etwas mehr Arbeit, aber klappt prima mit Scrum.
Das Kernargument für Festpreis ist: in großen Firmen kann man aus verwaltungstechnischen Gründen keine flexiblen Preise vereinbaren, da für jede Ausgabe ein Budget beantragt werden muss und dieser Antrag darf nur X Prozent Abweichung vom Endpreis enthalten. Deswegen funktioniert das mit dem Budgetsystem für diese Kunden so gut. Das ist genau ihr Ding. Man landet auch immer bei exakt 100% Budgetausschöpfung und der Projektleiter muss sich gegenüber der Rechnungsabteilung nie rechtfertigen.
So etwas ist auch wunderbarer Stoff für eine Schulung. Ich mache ja solche Dinge immer wieder mal. 😉
Tom
22 Jun 11 at 10:40
@DSB & Tim:
Reden wir doch mal über Meister Röhrich (Gas-Wasser-Scheisse Röhrich) der jetzt auf de Idee gekommen ist gebrauchte aber neuwertige Schnüffelstücke online zu verkaufen.
Für den ist Scrum eine neue Modedroge und ein Project Owner ein Holländischer Käseverkäufer. Das ist doch die Klientel mit der man am schnellsten Probleme bekommt. Die wissen zwar was eine Webseite ist, jedoch in den seltensten Fällen was da alles dahinter steckt oder was man dafür so alles benötigt. Bei dieser Kundschaft diskutiert man sich meistens den Mund fusselig weil man als Webworker sich gedacht hatte die wissen schon was die wollen.
Ralf
22 Jun 11 at 19:17
@Tom
Ich kann Deine geschilderten Beobachtungen in meiner Praxis nicht nachvollziehen.
<<Scrum ist die perfekte Ausrede alles auf’s Projektteam abzuschieben
So etwas besprechen und lösen wir im regelmäßigen Sprint-Planning und -Review. Wenn hier dauerhaft so ein Eindruck im Team herrscht, dann macht der Scrum Master etwas falsch. Das ist ein Impediment, was auf Produktivität und Motivation drückt und unbedingt beseitigt werden muss.
<<Product-Owner? Kann keine Prioritäten setzen
Der Product Owner verfolgt und trägt seine Produktvision in das Team und ist verantwortlich für das Projekt. Wenn er den Business Value nicht kennt und darauf aufbauend die Prioritäten setzen kann, wer dann? Deine Erfahrung kann ich aus meiner Praxis ganz und gar nicht nachvollziehen.
<<Oder User-Stories so schreibt, dass man sie auch testen kann.
Das Team hilft dem PO Storys so zu schreiben, dass es damit arbeiten kann und erhebt lautstarken Protest wenn eine Story nicht testbar oder die Defintion of Ready nicht erfüllt ist. Das ist sicherlich anfangs ein Lernprozess, pendelt sich aber recht schnell ein.
Für mich klingt Deine Beschreibung so, als würdest du Scrum mit einem Kunden machen, der seine Aufgabe im Projekt nicht richtig wahrnimmt und nicht gegensteuern, was Aufgabe des Scrum Masters ist.
@Ralf
Meister Röhrich wird sicherlich nicht den Etat haben einen komplett neuen Online-Shop bauen zu lassen. Eher wird er ein bestehendes System nutzen wollen und gegebenfalsl die Optik anpassen lassen. in dem Fall würde ich nicht mit Scrum arbeiten, sondern eher mit Pflichtenheft arbeiten wollen. Generell funktioniert Scrum nur mit Kunden, die sich auf das agile Konzept einlassen und dieses stützen. Einen Product Owner für das Projekt zu stellen, bedeutet, dass dieser Mitarbeiter einen Full-Time Job hat und vollständig aus dem Tagesgeschäft rausgezogen werden muss. Das kann ein Kleinunternehmer sicherlich nicht verkraften.
Bei solchen Kleinprojekten wäre der Erkärungs-Overhead aus meiner Sicht auch zu hoch und steht in keinem vernünftigen Verhältnis zum Nutzen mehr. Scrum ist kein Allheilmittel für jedes Projekt. Aber da, wo es geht und Software im Team entstehen soll, ist es sehr effektiv.
DSB
28 Jun 11 at 10:31
@DSB:
Da stimme ich dir voll und ganz zu. Nur lesen wir doch noch mal kurz im Beitrag nach:
[…] aus Mangel an Wissen über IT-Projekte […] … […] ca. 15 Seiten mit 2-3 Formularen und etwas Javascript […]
Warum wirft man bei solch einer Projektbeschreibung Begriffe wie Scrum in die Diskussion? Weil man gerade irgendwas dazu sagen will? Oder weil man nichts anderes kennt?
Ich denke mal das Kunden wie Meister Röhrich die Brot&Butter-Kunden für die meisten Webworker sind. Und ich erlebe es selber immer wieder das selbst Begriffe wie Pflichtenheft für die Kunden nahezu gänzlich unbekannt sind.
Ich mache das ganze nur nebenbei, von daher kenne ich Sätze wie „Warum wurde das mit Javascript umgesetzt? Ich habe mir sagen lassen Ajax sei viel besser“ nur zu gut. Deswegen nehme ich mir meistens die Zeit und erkläre alle Abläufe Schritt für Schritt. Man kommt sich zwar vor wie im Internet-Kindergarten, es erspart mir aber etliche Diskussionen.
Aber auch ein sehr enger Kontakt, nach Möglichkeit täglich, erspart viele Diskussionen und umfangreiche Änderungswünsche. Ebenso dem Kunden so oft wie möglich die Fortschritte zu zeigen. Also nicht erst 10 oder 20 Seiten erstellen und dann dem Kunden sagen „Dat isset.“, sondern viele kleine Schritte und jeden einzeln abnehmen lassen.
Im professionellen Umfeld sind das wohl eher Normalitäten. Aber dort entstehen auch eher selten solche Probleme wie im Artikel beschrieben.
Ralf
28 Jun 11 at 18:46
<<Warum wirft man bei solch einer Projektbeschreibung Begriffe wie Scrum in die Diskussion?
Achte auf den Zeitpunkt.
Nachdem die Situation geklärt war und es klar war, dass der Auftraggeber Lehrgeld bezahlen muss, ging es darum, solche Situationen künftig zu vermeiden. Da habe ich eine Möglichkeit in die Diskussion geworfen. Ich dachte immer, dass Diskussionen von den Anregungen der Beteiligten leben. 🙂
Deine durchaus trolligen Nachsätze überlese ich jetzt einfach mal.
DSB
28 Jun 11 at 19:20
Das ist in etwa genau die Beratung mit der die meisten Projekte vor die Wand fahren. Anstatt darauf zu hören was gesagt/geschrieben/gewünscht wird, wird einfach ein Hype-Thema wie z.B. Scrum in den Raum geworfen und dem Kunden als Nonplsultra verkauft.
Solche Situationen wie sie im Artikel beschrieben sind werden durch Scrum eben nicht vermieden da Scrum hier ganz und gar unpassend ist. Man hätte genauso gut Yoga vorschlagen können mit dem Argument das Yoga-Themen bisher jede Diskussion bereichert haben.
Die „trolligen Nachsätze“ sind die Beschäftigung mit dem Problem/der Situation anstatt ein Ego-Trip durch 0815-Agenturgeschwafel.
Ralf
28 Jun 11 at 22:29
Du solltest mal einen Kommunikations-Workshop besuchen. Bei Dir lässt sich gut beobachten, dass das, was der Sender gesagt hat, sich ziemlich von dem unterscheidet, was beim Empfänger ankommt.
Ich habe mich klar positioniert und nicht behauptet, dass Scrum ein Allheilmittel ist. Offensichtlich verstehst Du mich aber so, als wenn ich nur ausschließlich und immer auf Scrum setze und alles andere nicht gelten lasse. Das habe ich nicht gesagt.
Mir ist eine weitere Diskussion mit Dir zu unergiebig, da Du Deine eigene Erfahrung gemischt mit einem übersteigerten Ego (viele machen Scrum falsch, Internet-Kindergarten, …) über die Möglichkeit stellst, dass andere positive Erfahrungen gemacht haben können. Auf meine Anmerkungen, was eventuell schief gelaufen sein könnte, bist Du nicht eingegangen. Stattdessen legst Du eine durchweg negative Ausdrucksweise an den Tag, die immer hart an der Grenze zur persönlichen Beleidigung steht.
So macht mir Erfahrungsaustausch und diskutieren keinen Spaß. Mach’s gut Troll. 😉
DSB
28 Jun 11 at 23:00