Aus dem Leben eines Freelancers - wie man - Delphi

Aus dem Leben eines Freelancers - wie
man Kunden glücklich macht
Delphi-Tage 2012
Dipl.-Inform. Ralf Mimoun
[email protected]
www.systemgilde.de
Inhalt
Einleitung................................................................................................................................................. 3
Background.......................................................................................................................................... 3
Worum geht es? .................................................................................................................................. 3
Und worum geht es nicht? .................................................................................................................. 3
Kernthemen............................................................................................................................................. 4
Servicegedanke ................................................................................................................................... 4
Die kaufmännische Seite ..................................................................................................................... 5
Expectation Management ................................................................................................................... 5
Woher bekommt man nur die Aufträge? ............................................................................................... 6
Wie sag ichs meinem Kunden? ............................................................................................................... 7
You have mail ...................................................................................................................................... 7
Das erste Treffen ................................................................................................................................. 7
Vertrag ist Vertrag ................................................................................................................................... 8
Mein Kunde! ............................................................................................................................................ 8
Alles hat ein Ende .................................................................................................................................... 9
Das böse Wort mit C ............................................................................................................................. 10
Meetings............................................................................................................................................ 10
Die dunkle Seite des Meetings .......................................................................................................... 11
Risiko und wie man es los wird ............................................................................................................. 12
Nur ein Überblick .................................................................................................................................. 13
Literatur ................................................................................................................................................. 14
Get to know me! ................................................................................................................................... 14
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
2
Einleitung
Background
Meine Erfahrungen stützen sich auf Projekte bei unterschiedlichsten Kunden. Ich habe allein, in Adhoc-Teams oder mit meinen Kollegen aus der Systemgilde GbR Software für in- und ausländische
Banken, Behörden, Groß- und Einzelhandel, Dienstleister und was es sonst so gibt geschrieben.
Einige Projekte hatten ein Budget von wenigen 1.000 Euro, andere liegen bei einer Million - allein für
die Softwareentwicklung.
Eigentlich bin ich ein Code Monkey - wenn man mich lässt. Es hat sich aber gezeigt dass irgendetwas
aus dem Bereich Projektmanagement immer an einem kleben bleibt. "Programmierer" passt also
nicht mehr als Tätigkeitsbeschreibung. Und deshalb ist es sinnvoll auch einmal die angrenzenden
Bereiche zu betrachten.
Worum geht es?
Ein glücklicher Kunde - das ist ein fast utopisches Ziel. Trotzdem ist es wert danach zu streben. Denn
ein glücklicher Kunde zahlt seine Rechnungen pünktlich, ist offener für notwendige
Budgetanpassungen und sorgt für laufende Aufträge. Und das ist das eigentliche Ziel: wenn man den
Künden zufrieden stellt braucht man sich um seine Auslastung weniger Sorgen zu machen, und auch
der Blick auf den Kontostand ist schmerzarm. Ich kann dabei natürlich nur aus meiner persönlichen
Erfahrung berichten. Das kann bei anderen abweichen, aber nach dem, was viele andere Freelancer
berichten, mit denen ich zusammen arbeite, treffen die meisten Punkte auf praktisch jeden zu.
Diese sind natürlich nicht neu, sondern wurden schon in zig Vorträgen, Artikeln und Büchern
durchgekaut. Aber vielleicht hilft es, wenn sie speziell für unsere Branche zusammen mit
Erfahrungen aus aktuellen Projekten zusammengefasst werden.
Der aktuelle durchschnittliche Stundensatz eines Code Monkeys liegt bei so 65,00 Euro. Das ist
schlicht zu wenig, ein Freelancer braucht eher 80,00 Euro pro Stunde. Bei 100,00 Euro macht die
Sache langsam Spaß, besonders wenn der Kunde direkt mehrere Monate bucht. Nur: wie kommt
man da hin?
Und worum geht es nicht?
Vieles kann hier nicht einmal angeschnitten werden:







Was tun bei Auftragsflaute?
Woher nimmt man gute Freie, wenn man Unterstützung braucht?
Wie verhält man sich gegenüber Internen und anderen Externen?
Wie identifiziert man Stakeholder, und welchen soll man es recht machen?
Sind Titel und Ausbildung von Bedeutung?
Wie rechnet man sinnvollerweise mit dem Kunden und den anderen im Team ab?
Was muss man bei mit ausländischen oder internationalen Kunden beachten?
Wenn Interesse besteht können wir gerne nach dem Vortrag darüber diskutieren.
Wer sich über Projektmanagement informieren will, hätte den Vortrag von Daniela Sefzig vor einer
Stunde besuchen sollen.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
3
Kernthemen
Im Endeffekt kann man praktisch die gesamte Arbeit für Kunden auf drei Punkte reduzieren:



Servicegedanke
Alles hat auch eine kaufmännische Seite
Expectation Management
Eine Nebenwirkung des Consultant-Daseins: alles wird dreigeteilt. Aber zumindest wird es heute
keine Powerpointfolien geben.
Servicegedanke
Wir produzieren nichts. Was wir erstellen wird niemand in tausend Jahren ausgraben. Und in
spätestens 20 Jahren wird es obsolet sein. Eigentlich ist es ein Wunder dass wir überhaupt Kunden
haben.
Das Geheimnis: praktisch kein Kunde zahlt für Codezeilen. Er zahlt, weil wir ihm dabei helfen ein
Problem zu lösen. Wir bieten eine Dienstleistung an, einen Service. Das sollte uns bei jedem
Kundenkontakt und bei jedem Programm, an dem wir schreiben klar sein.
Was daraus folgt geht vielen Programmierern (und anfangs auch mir) gehörig gegen den Strich. Viele
von uns sind nicht gerade erpicht auf durchgehende menschliche Gesellschaft und wollen lieber der
Maschine sagen was sie tun soll. Das sind denkbar schlechte Voraussetzungen für einen
Dienstleister, der regelmäßig mit anderen Menschen über kritische Projekte diskutieren muss.
Aber wir müssen aus unserer Haut raus. Ein Beispiel aus dem Alltag: ein Benutzer kommt auf einen
zu, eine Funktion arbeitet nicht so wie gewünscht. Alle schriftlichen Anforderungen sind eigentlich
erfüllt, man hat bei der letzten Besprechung das Ganze nochmal festgeklopft, den Formalitäten
wurde Genüge getan. Der Benutzer ist trotzdem nicht glücklich. Und er weiß, dass er gerade einen
schlechten Stand hat. Als Dienstleister gibt es nur eine richtige Reaktion: man geht auf den Benutzer
zu. Man bittet um 5 Sekunden Zeit, schreibt seine Zeile Code fertig und fragt, wie man helfen kann.
Schließlich muss sich etwas so gravierend geändert haben, dass eine Anforderung über den Haufen
geworfen wird, und wir wären blöd nicht zu versuchen den Grund zu verstehen.
Gleiches gilt bei Meetings: wenn der Kunde möchte, dass man an einem Meeting teilnimmt, dann
wird er dafür seine Gründe haben. Da wir als Externe keine politische Position haben, gibt es dort
nur eine sinnvolle Verhaltensweise: man bietet aktiv sein Wissen und seine Dienste jedem an, der sie
benötigen könnte (dazu unten mehr).
Das darf natürlich nicht in Anbiederung ausarten. Der Kunde muss merken dass man das Projekt
vorantreiben und nicht primär seine Auftragsbücher füllen will. Dass das eine zum anderen führen
kann ist eine andere Geschichte.
Natürlich kostet das Zeit. Diese Zeit haben wir jedoch schon bei der Auftragsbesprechung, bei der
Aufstellung der Zeitpläne oder bei unserem Angebot einkalkuliert. Wenn das nicht genügt haben wir
immer noch den Slack. Und wenn man merkt, dass kurzfristige Anfragen, Änderungswünsche und
Meetings überhand nehmen könnten, muss der Projektverantwortliche informiert werden. Dieser
muss entscheiden wie die Ressource "Freelancer" eingesetzt werden soll. Nur er kann entweder das
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
4
Budget erhöhen oder dafür sorgen dass man wieder zum Programmieren kommt. Der jeweilige
Benutzer, der mit einem akuten Problem zu uns kommt ist dafür genauso der falsche
Ansprechpartner wie die Teilnehmer einer Besprechung.
Die kaufmännische Seite
Machen wir uns nichts vor: wir arbeiten wegen des Geldes. Keine Weihnachtskarte, keine Flasche
Wein zum Geburtstag und keine Party nach erfolgreichem Projektabschluss zahlen unsere Miete.
Natürlich ist Anerkennung toll. Keiner will für einen Kunden arbeiten der durchweg grantelt und am
Ende nur leidlich zufrieden ist, obwohl man wirklich gute Arbeit geleistet hat. Ein glücklicher Kunde
gibt immer entsprechendes Feedback. Wer das nicht sucht und auch genießt hat wahrscheinlich den
falschen Job gewählt. Es gilt, aus dieser Zufriedenheit ein vernünftiges Einkommen zu generieren.
Aber nicht immer hat der Kunde Recht. Oft genug wird er Anforderungen haben die in die falsche
Richtung führen. Er wird tagelang über Dinge diskutieren die eigentlich klar sind. Man schreibt Code,
der später wieder teuer entfernt oder massiv umgeschrieben werden muss.
Natürlich ist es unsere Pflicht die unserer Meinung nach bessere Lösung zu beschreiben. Und wenn
etwas nach Zwischenlösung und Pflaster aussieht, nennen wir den zu erwarteten Mehraufwand.
Aber es ist nicht Aufgabe des Externen zu entscheiden ob etwas wie vom Kunden gewünscht
implementiert wird, oder ob die der eigenen Meinung nach "richtige" Lösung gewählt wird.
Offensichtlich braucht der Kunde "seine" Implementation zur Entscheidungsfindung. So einfach
verkauft man selten Manntage, also freuen wir uns einfach über die inoffizielle Budgeterhöhung.
Denn wenn man frühzeitig offen die Kosten kommuniziert kann man später nicht gebissen werden.
Auch wenn es einen bei der Programmierung wurmt - man arbeitet im Sinne des Kunden. Und
manchmal kann es sogar vorkommen, dass der Kunde letztendlich doch Recht hat.
Expectation Management
Das Hohe Lied auf den Kunden und seine Anforderungen kann auch zu Missklang führen. Wer offen
für Anfragen, Änderungswünsche und Erweiterungen ist, wird schnell merken, dass dem Kunden
nicht immer klar ist was das bedeutet. Dabei kann man zwischen dem Gesamtbudget und der
kurzfristigen Projektplanung unterscheiden.
Man merkt schnell wenn ein Kunde die Bäume in den Himmel wachsen lässt. Hier noch ein Feature,
da ein weiterer Import, und ein halbes Dutzend Buzzwords sollen auch noch schnell eingebaut
werden. Das kostet - und das muss man dem Kunden klipp und klar sagen. Es geht nicht darum
Arbeit abzublocken. Im Gegenteil: man will und muss zeigen, dass man die Arbeit ernst nimmt. Dazu
gehört, dass man sie plant und im Budget berücksichtigt. Ansonsten ist das Gezeter kurz vor Ende
des Projekts groß. Wo sind denn nur die ganzen tollen Ideen geblieben? Die müssen unbedingt noch
rein, und ein weiteres Release in einem halben Jahr geht gar nicht!
Ähnlich sieht es bei der täglichen Arbeit aus. Wenn eine kleine Änderung gewünscht wird kann es ja
wirklich sein, dass sie klein ist. Also mit allem mindestens drei Stunden benötigt, bis sie testbar ist:
Anfrage dokumentieren, Requirements anpassen, Implementation, White Box Testing, Unit Tests,
Kontrolle, Freigabe an Tester. Dazu die Kommunikation, und schon ist ein halber Tag weg. Wenn
gerade anderes pressiert muss man dem Kunden sagen dass er nicht immer alles sofort haben kann außer er ändert die Prioritäten.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
5
Diese Fälle sollte man so früh wie möglich abfangen. Egal ob Besprechung oder Anfrage per Mail: als
erstes sollte man mitteilen, dass man sich die Punkte anschaut und eine erste Abschätzung
zusammen stellt. Wenn etwas offensichtlich aufwendig wird, sollte man das direkt ankündigen. Dann
ist schon mal der erste Druck raus, alle haben ein wenig Zeit um Abstand zu gewinnen. Und keiner
wundert sich warum die kleine nette Funktion, die man so toll fand, auf einmal 12 Manntage kosten
soll.
Es geht also nicht darum die Erwartungen künstlich zu drücken, sondern sie auf ein realistisches Maß
zu bringen. Denn wenn wir das leisten was man erwarten kann und darf, dann sind wir einen guten
Schritt weiter zum glücklichen Kunden.
Nebenbei: alles was nicht aktuell realisierbar ist sollte beim Kunden schnellstmöglich auf die
"Wunschliste". Man kann bei erneuten Anfragen darauf verweisen. Und wenn dokumentiert ist was
die Benutzer noch brauchen, dann wird das in der Regel auch bestellt. Ansonsten kann das schnell in
Vergessenheit geraten.
Woher bekommt man nur die Aufträge?
Gute Frage, sie greift aber zu kurz. Eigentlich muss man fragen: woher weiß der Kunde in spe, dass es
mich gibt?
Es geht darum seinen Bekanntheitsgrad zu erhöhen. Das bedeutet nicht, dass man sich auf Teufel
komm raus "vernetzt", sondern dass der eigene Name direkt mit einer gewissen Qualität verbunden
wird. Denn: noch nie hat eine Xing-Nachricht irgendwo, irgendwann einen Auftrag gebracht. Also:
Get to know me!
Hier einige Möglichkeiten, die meiner Erfahrung nach zu Aufträgen führen:





"Beziehungen", Empfehlungen, Personaldienstleister bringen ziemlich unerwartet Aufträge
Bekanntheit (Internet/Foren, was früher bei Newsgroups einfacher), siehe auch Delphi-Tage.
Präsent zu sein ist immer hilfreich.
Die Webpräsenz sorgt nicht dafür, dass man gefunden wird. Aber jeder potenzielle Kunde
wird sich meine Webseite ansehen, bevor er mir die erste Mail schreibt. Die wenigsten
halten ihre Webseite immer aktuell, aber sie sollte zumindest ansprechend aussehen.
Auch mal was "Riskantes" wagen, z.B. User Groups gründen und Treffen organisieren. Die
Resonanz ist meist viel besser als erhofft. Und die Wirkung ist beachtlich: man wird in der
"Szene" bekannt, man arbeitet viel mit Anbietern zusammen, und man lernt jede Menge
(schon wieder drei Punkte).
Visitenkarten verteilen funktioniert!
Natürlich gibt es auch Methoden, die meiner Erfahrung nach nicht funktionieren:


Werbeschreiben, Mailaktionen: Meiner Meinung nach macht es keinen Unterschied ob man
die Schreiben selbst verfasst oder das einem Profi überlässt. Die Erfolgsquote liegt zu oft bei
Null.
Nur auf die Akquise durch andere hoffen: Als Einzelkämpfer ist das tödlich, aber auch im
Team sollte jeder versuchen Aufträge zu akquirieren.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
6
Wie sag ichs meinem Kunden?
Kommunikation ist vielleicht der wichtigste Faktor bei unserer Arbeit. Wenn wir nicht wissen wie wir
mit dem Kunden reden sollen, dann werden wir nicht erfahren was er sich wünscht. Und noch
schlimmer: der Kunde wird davon ausgehen dass wir das Projekt zu seiner Zufriedenheit stemmen
können und gibt uns keinen Auftrag.
You have mail
Praktisch immer wird man zuerst per Mail, manchmal per Telefon Kontakt aufnehmen. Der erste
Kundenkontakt ähnelt stark einem Bewerbungsgespräch. Dem entsprechend sollte man sich
unbedingt informieren was der mögliche Kunde denn überhaupt macht und mit wem man es dort zu
tun hat.
Wichtig ist dass man verbindlich ist. Jemanden der nur Allgemeinplätze von sich gibt und entweder
behauptet dass alles kein Problem sei (oder, noch schlimmer, dass alles unwahrscheinlich aufwendig
und kaum abschätzbar ist), wird so schnell nichts mehr vom Kunden hören. Also: was kann man?
Was kann man definitiv nicht? Wobei man das Können etwas ausweiten kann, wenn u.a. gute
Kenntnisse in MS SQL gewünscht werden, hilft oft normales SQL-Knowhow + Google.
Wenn man jedoch von einem Bereich wirklich keine Ahnung hat, muss man sich fragen ob man den
Auftrag wirklich leisten kann. Manchmal kann man sich mit Kollegen behelfen. Nur ist und bleibt
man Ansprechpartner für den Kunden, und irgendwann merkt er, dass man von der Materie nicht
viel versteht. Da ist es besser die Anfrage mit warmen Worten weiterzuleiten.
Ganz wichtig: nicht überlasten! Mehr als 2 Projekte parallel kann man pro Person einfach nicht
stemmen, und die sind oft schon zu viel. Das Privatleben leidet, die Qualität sowieso, und wenn man
Pech hat ist man zwei Kunden gleichzeitig los.
Das erste Treffen
Zunächst zur "Ausstattung". Wer bei einer Bank vorstellig wird sollte nicht in Jeans und T-Shirt
auftauchen. Und bei einem Zementwerk kommt ein Anzug nicht immer gut an. Ja, es schmerzt vielen
sich dem Kunden entsprechend zu verkleiden. Dazu gehört interessanterweise auch die technische
Ausstattung: bitte keine Gamermaschine mitbringen, ebenso kein Notebook, das schon aus dem
Leim gegangen ist.
Ein Treffen ist immer mit Kosten verbunden: man investiert Zeit, Benzin, Fahrscheine. Man sollte
lieber nicht fragen ob man das erstattet bekommt. Das sind normale Akquisekosten.
Man trifft sich mit dem Kunden um zu überzeugen, aber besonders um ihm zuzuhören. Jeder Auftrag
hat immer eine Vorgeschichte. Die meisten Kunden haben jemanden, der für sie entwickelt - aber
warum will er für dieses Projekt jemand anderen? Warum redet er gerade mit mir? Handelt es sich
um ein problematisches Projekt, ist der Kunde nicht ganz einfach, ist kein Budget da, gibt es
besonderen Zeitdruck? Wenn man Glück hat geht es um die eigene, einzigartige Expertise. Fast
immer wird es einem der Kunde verraten - wenn man ihn reden lässt!
Noch ein einfacher Tipp für das eigene Auftreten: langsam reden. Und beim ersten Termin sollte
man es vermeiden, feste Aussagen a la "das kann man problemlos soundso machen, kostet x Tage"
zu machen. Wenn es so einfach wäre, wäre es schon lange erledigt.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
7
Das alles sorgt für ein gutes Bauchgefühl, für Vertrauen beim Kunden. Und das ist fast wichtiger als
die Qualität der abgelieferten Arbeit - der Kunde wird niemals zufrieden sein solange er sich nicht
verstanden fühlt.
Vertrag ist Vertrag
Wenn alles klappt kommt es zum Zweitwichtigsten: der Vertrag (das Wichtigste ist die pünktlich
bezahlte Rechnung). Die wichtigsten dabei Punkte sind banal, werden aber trotzdem immer wieder
gern übersehen:





Was soll gemacht werden?
Wie viel wird gezahlt?
Was passiert bei Problemen?
Wer trägt welche Risiken
Wie werden weitergehende Anforderungen vergütet?
Es bleibt nie bei dem, was anfangs geplant war. Der Umfang eines Auftrags nimmt immer zu. Der
Kunde sieht erst mit der Entwicklung was noch alles geht und sinnvoll ist. Es kommen weitere
Stakeholder ins Spiel, deren Wünsche man berücksichtigen muss. Und je länger ein Projekt dauert,
desto wahrscheinlicher ist es, dass externe Faktoren Änderungen notwendig machen. Das hat aber
auch eine gute Seite: wenn ein Projekt lange genug läuft, läuft es praktisch ewig.
Bei allem, was nicht sonnenklar ist, sollte man einen Anwalt konsultieren: Schadenersatzklauseln,
NDAs, Wartungsverträge. Wer es noch nicht getan hat sollte den Versicherungsvertreter seiner Wahl
besuchen: eine Haftpflichtversicherung ist meist eine gute Idee. Ebenso die Gründung einer GmbH.
Beides ist nicht wasserdicht, kann aber helfen.
Wenn es ums Geld geht wird es heikel. Sätze sind meist all-in, also mit allen Spesen. Deshalb sollte
man seinen Satz nicht zu niedrig ansetzen! Es kommt auf den Bereich an, bei Banken sind 100 Euro/h
kein Problem, bei kleinen Mittelständlern können 60 schon zu viel sein. Man muss entscheiden ob
man den Auftrag für den Preis erledigen kann. Denn auch wenn 60 Euro wenig sind: wenn es sich nur
um ein paar Stunden im Monat handelt ist es immer noch ein netter Zuverdienst. Man weiß nie was
sich daraus ergibt
Was jedoch gar nicht geht: Arbeit ohne Geld. Jeder ist wohl schon gefragt worden, ob er nicht ein
ganz simples Programm für ein ganz tolles Projekt schreiben will. Eine Idee die noch keiner hatte,
und wir werden alle reich! Das gibt es in verschiedenen Variationen: marginale Bezahlung jetzt mit
x% Umsatzanteil irgendwann später, Aussicht auf Aktienoptionen für eine Firma die es fast schon
irgendwie gibt und ähnliches. Das geht in 99 von 100 Fällen total schief. Wer es schafft im Leben bei
100 solcher Ideen mitzumachen ohne zu verhungern hat eine reelle Chance. Der Rest sollte die
Finger davon lassen.
Mein Kunde!
Wenn man schon in der glücklichen Lage ist einen Kunden zu haben, möchte man ihn gerne
möglichst lang halten.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
8
Ein Kunde hat einen Auftrag, weil er ein Problem hat. Deshalb ist der Kunde meist glücklich, wenn er
das Problem, für das er einen engagiert, aus den Füßen hat. Diese Erwartung sollte man wenn
möglich erfüllen: nur fragen wenn nötig, aber dann sofort und mit den Details, die der Kunde für
seine Entscheidung braucht.
Außerdem sollte man nicht jeden Unsinn sofort berechnen. Das kann man besser bei dem nächsten
größeren Posten mit drauflegen. Dazu gehört auch, dass man Kosten frühzeitig kommuniziert. Oft
muss Budget dafür her, das der Ansprechpartner organisieren muss. Wenn man da noch die
Kleinigkeiten der letzten Wochen anspricht können die mit ins Budget. Das ist unproblematischer für
den Kunden und erspart dem eigenen Ansprechpartner meist viel Papierkram. Dabei ist
Fingerspitzengefühl gefragt: der eine Kunde ist über eine solche flexible Abrechnung froh und
honoriert das - der nächste versucht das auszunutzen und vergisst liebend gern diese "Kleinigkeiten".
Was nie zu kurz kommen darf ist die Qualität. Also: Liefern, liefern, liefern. Fehler müssen sofort
berichtigt werden, dafür gibt es madExcept und Konsorten. Wenn möglich sollte man das von selbst
erledigen, und den Kunden direkt vor und nach Fehlerberichtigung informieren. Jeder macht Fehler,
aber wer die lasch handhabt oder gar totschweigt hat verloren. Ob man Fehlerberichtigungen
berechnet bleibt jedem freigestellt.
Ebenso sollte man verbindliche Endtermine für einzelne Funktionen, an denen man gerade arbeitet,
nennen. Meist hat man die sowieso schon grob implementiert (zumindest mache ich das so, nennen
wir es "Machbarkeitsstudien"), es fehlen noch Feinschliff und Tests. Wenn es fertig ist, sollte man es
direkt der entsprechenden Person mitteilen, wenn es die Situation zulässt face to face. Tue Gutes
und rede darüber!
Wenn größere Änderungen oder Erweiterungen anstehen ist das eine gute Gelegenheit um eigene
Ideen einzubringen. Umstellung auf XE3 (64 Bit ist sehr oft ein Marketingfaktor für den Kunden),
modernere UI (da reicht es oft z.B. DevExpress-Grids upzudaten), erweiterte Analysefunktionen
(Pivotansichten an Datenmenge hängen usw.), es gibt viel was dem Kunden nützen würde wenn es
denn kennt. Das hilft beiden Seiten. Man kann auf Folgeaufträge hoffen, denn je schneller etwas
Neues drin ist, desto schneller kommen neue Anforderungen und Wünsche. Und der Kunde hat eine
bessere Anwendung und nicht nur dasselbe, nur durch einen anderen Compiler gejagt.
Wenn sich der zufriedene Kunde 3, 4 Monate nicht gemeldet hat, sollte man ihn anrufen (keine
Mail). Läuft alles? Funktionieren die neuen Erweiterungen? Fast immer kommt etwas a la "alles
bestens, nur mit der neuen Schnittstelle X gibt es Probleme, da könnte man..." oder "Die Benutzer
sind glücklich, manchmal hätten sie gern eine Auswertung der letzten 4 Wochen neben einer des
aktuellen Monats" und ähnliches. Etwas besseres kann nicht passieren: man hat wieder einen
Auftrag, der Kunde ist froh dass er die kleinen schwelenden Problemchen los ist, und die Anwender
fühlen sich ernst genommen.
Alles hat ein Ende
Viele Verträge laufen einfach aus. Die Software wurde eingeführt und tut das, was sie soll. Aber
damit ist das Projekt meistens noch nicht abgeschlossen - jede Software lebt.
In dem Fall, dass ein Projekt wirklich endet, sollte man möglichst sofort analysieren woran es liegt:
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
9



Höhere Mächte: Gesetzesänderungen, Verkauf der Firma an einen größeren Laden mit
eigener IT, OHL hat auf SAP umgestellt und lässt alles einen überteuerten Consultantladen
erledigen usw.
Stress mit Kunden / Ansprechpartner: In dem Fall sollte man alles versuchen das würdig
hinter sich zu bringen, und lieber ein Zugeständnis mehr als zu wenig machen. Am Ende
kommen einige auf wunderliche Gedanken, die uns richtig Geld und Zeit kosten. Wenn alles
nicht hilft sollte man den Briefverkehr schnellstmöglich einem Anwalt übergeben. Sonst
besteht die Gefahr dass man sich das eine oder anderen Mal den Tag verdirbt.
Software ist obsolet wegen technischer Neuerung.
Solange es eine gute Beziehung zum Kunden geht sollte man frühzeitig darauf reagieren: man kann
anbieten beim Übergang zu helfen, bei Fragen beratend zu helfen, oder mit dem erworbenen
Knowhow eine "Gap Analysis" zu erstellen. Das hat alles wenig mit Codeschreiben zu tun - einfacher
kann man keine teuren Consultantstunden verkaufen. Und es ist auch noch sinnvoll für den Kunden.
Schließlich steckt in dem existierenden System jede Menge Knowhow, und oft hat der Kunde die
berechtigte Sorge dass es bei einer Umstellung verloren geht.
Wenn man Erfolgschancen sieht und die Zeit hat, kann man mit einem halben Tag Aufwand einen
ansehnlichen Prototyp hinsetzen und den vorführen. Wenn das noch vor der wirklichen
Entscheidungsphase geschieht, setzt man selbst die Maßstäbe und gibt praktisch vor, welche
Anforderungen an das neue System gestellt werden. Dann haben "die da oben" eine gute
Gelegenheit einen Auftrag (an uns!) frühzeitig zu vergeben, mit minimalem Risiko. Denn so billig
können sie selten Häkchen setzen.
Das böse Wort mit C
Consultant! Kaum jemand weiß die Arbeit zu würdigen, die Berater in Powerpoint-Folien, Excel und
Meilenprogramme stecken.
Aber auch wenn man es nicht glauben mag: sogar in dieser Gruppe gibt es wirklich fähige Leute. Und
es hilft, wenn man zumindest vom "Rang" auf gleicher Höhe ist. Ich persönlich habe mehr von guten
Beratern gelernt als von Delphi-Cracks. Und der größte Vorteil, wenn man beim Kunden als
Consultant gilt oder zumindest so abgerechnet wird: der Stundensatz ist meist merklich höher.
Meetings
Meetings werden als das angestammte Biotop eines Consultants angesehen: ein Dutzend Menschen
vertrödeln ihre Lebenszeit und schreiben sich danach Memos, wie produktiv sie doch waren. Dabei
sind Meetings besonders eins: GUT!
Bei einem normalen Meeting wird kaum Neues auf den Tisch kommen. Das sollte man auch selbst
beherzigen: wenn etwas im Meeting besprochen werden soll, sollte man es mindestens einen Tag
vorher auf die Agenda setzen (lassen). Ansonsten haben die anderen keine Zeit zu reagieren und
kommen sich wie der letzte Depp vor. Was bei einem Meeting normalerweise so passiert:



Es wird wenig ausdiskutiert
Es wird viel "entschieden", also festgeklopft, was vorher schon meistens klar war
Es werden einige Aufgaben verteilt
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
10

Das beliebte Blame Game
Was ist daran nun so toll? Das bringt uns zurück auf die drei Punkte vom Anfang:



Die kaufmännische Seite: ein Meeting belegt mit allem Drum und Dran zwei Stunden der
eigenen Arbeitszeit. Die der Kunde bezahlt.
Expectation Management: Man weiß in welche Richtung es geht und kann frühzeitig
Erwartungen dämpfen. Nicht dass man nicht liefern will, aber wie immer werden z.B. einige
Funktionen als trivial angesehen, die einfach nicht ins Konzept passen. Anderes wiederum
kann man oft schnell liefern, was der Gruppe Kopfschmerzen bereitet.
Servicegedanke: Zum Ende eines Meetings werden oft Aufgaben verteilt, um Informationen
für den nächsten Termin zu sammeln. Man sollte unbedingt eine der Aufgaben übernehmen,
wenn es geht ungefragt. Man erweist sich als Team Player und hat schon wieder einige
Stunden Arbeit.
Das hört sich an wie Zeitschinderei. Aber man sollte immer daran denken: der Kunde bestimmt, was
sinnvoll ist, nicht man selbst. Wenn er einen in einem Meeting sitzen haben will ist es seine
Entscheidung. Man kann natürlich darauf hinweisen dass man dort der eigenen Meinung nach nicht
viel beitragen kann, aber das letzte Wort hat der Kunde.
Die dunkle Seite des Meetings
Nun noch zu einem ganz bösen Teil eines Meetings. Es kommt mit etwas Glück nur sehr selten vor,
aber man sollte unbedingt damit umgehen können: das Blame Game. Es gibt zwei Ursachen (wenn
man denn selbst keinen Unsinn gebaut hat): Politics oder gerissene Limits (Budget, Zeit,
Funktionsumfang).
Politics fallen nicht in den Aufgabenbereich eines Freelancers! Man bekommt natürlich einiges mit,
hat aber praktisch kein Standing. Wenn möglich sollten man mit dem Projektleiter oder einem
anderen (inoffiziell) Verantwortlichen von der "richtigen" Seite besprechen. Es ist deren Aufgabe das
abzufangen. Wenn sie es nicht wollen oder können muss man da eben durch.
Wenn es irgendwie an einem selbst hängen könnte, dass Limits gerissen wurden, sollte man
Gegenargumente suchen, die keinem schaden: "X konnte wegen größerem Umfang bei
Jahresabschluss und Krankheitsfällen in der Abteilung die Planung nicht wie zunächst gedacht
durchführen, aber wir sind gemeinsam dran", "Die Servererweiterung A kam erst letzte Woche, wir
sind seitdem an den Tests dran", "Die letzte Version sorgte für etwas mehr Informationsbedarf, das
mussten wir kurzfristig abdecken".
Außerdem sollten man die tief hängenden Früchte ernten: Was kann man schnell für Tests bereit
stellen, welche Doku kann man fix fertig bekommen, allgemein: wo kann man mit wenigen Stunden
viele Häkchen setzen?
Natürlich hat das meist wenig mit dem Fortschritt der Softwareentwicklung zu tun. Und natürlich
kann man sich auf die Hinterbeine stellen und feststellen, dass das alles Unsinn ist und man selbst
schon längst fertig wäre, wenn man hier nicht sitzen und so einen Blödsinn anhören müsst. Und
natürlich packt man dann sein Notebook ein und sieht den Kunden nie wieder.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
11
Wenn ein Blame Game bevorsteht sollte man sich unbedingt vorbereiten! Dann ist es möglich dem
Ganzen den Wind aus den Segeln zu nehmen bevor der Sturm losgeht. Also: was genau wird
kritisiert? Wen betrifft es? Wer steht auf welcher Seite, wer hat politische und wer fachliche
Gründe? Es braucht etwas Fingerspitzengefühl um die Informationen zu bekommen und die
entsprechenden Leute im Vorfeld passend anzusprechen. Die Gratwanderung die Politics zu
verstehen, sich jedoch nicht in diese einzumischen, ist ein besonderes Vergnügen.
Am Anfang eines Meetings geht es meist um den aktuellen Stand. Das ist für denjenigen, der einem
an die Kandare fahren will, existenziell: erst wenn etwas offiziell in Verzug ist, darf man darauf
herumreiten. Das sollte man nutzen, man hat sich schließlich vorbereitet. Man kann die fertigen
Teile kurz anreißen, ebenso dass es ein wenig länger gedauert hat wegen o.g. Argumenten. Man
kann dabei zusehen, wie das Thema an Substanz verliert. Wenn dann der Blamer die Liste mit den
unangenehmen Punkten durchgeht wird er immer wieder mal "aber das ist jetzt ja geklärt" sagen
müssen.
Ganz einfach sind diese Situationen nicht. Man sollte auch nicht versuchen die ganze Schuld
abzuwälzen. Ein kleines mea culpa schadet nicht, aber es sollte sich auf einen Nebenkriegsschauplatz
beschränken. Man muss schließlich noch einige Zeit zusammen arbeiten.
Und was ist, wenn man wirklich in die Tonne gegriffen hat? Meiner Meinung nach sollte man das
schnellstmöglich dem Verantwortlichen mitteilen. Wenn man versucht das alles noch hinzubiegen
(was sowieso nie klappt) oder das erst bei einem Meeting bekannt gibt, hat man ein wirkliches
Problem. Man hat wertvolle Zeit verstreichen lassen, die man hätte nutzen können um den Impact
zu minimieren. Das sind gute Argumente für den Kunden es das nächste Mal (oder schon morgen)
mit einem anderen zu versuchen.
Risiko und wie man es los wird
Softwareprojekte sind gespickt mit Risiken. Kann man die Stakeholder zufrieden stellen? Reicht das
Budget? Gibt es unverhoffte Krankheitsfälle, Kündigungen, Schwangerschaften? Gelten die heutigen
Anforderungen auch noch morgen? Nur weil man als Externer unter Sachkosten abgerechnet wird
heißt das nicht, dass einen Risiken kalt lassen können. Im Gegenteil!




Risiken müssen kommuniziert werden, das ist schon moralischer Verpflichtung. Wer Mitglied
des IEEE ist hat das sogar unterschrieben.
Begründete Zweifel an Projekterfolg sollte man sehr früh informell weitergeben.
Wenn darauf nicht entsprechend reagiert wird, sollte man sich formell äußern, und dann
nicht zu spät. Man will nicht beim nächsten Meeting auseinander genommen werden.
Wenn man ein Risiko per Mail meldet: genügend Empfänger, auch genügend hoch angesetzt.
Alternativ kann man auch altmodisch ein Fax senden.
Man sollte schon die mögliche Reaktion des Kunden einplanen:



Ignoranz. Was solls, das ist die Entscheidung des Kunden, man ist die Verantwortung los.
Panik. Dann ist man eben den Auftrag los, unter Umständen mit Problemen und finanziellen
Verlusten. Aber je eher, desto billiger, und das wird sowieso nichts mehr.
Realismus. Neue Prioritäten, wenn nötig Anpassung des Zeitplans und/oder des Budgets.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
12
Neben den wirklich sinnvollen Vorteilen hat ein Risikomanagement auch wieder "weiche"
Auswirkungen. Man wirkt verantwortungsvoll, committed, nicht wie einer der das Ding gegen die
Wand fahren lässt. Man ist ein Teil des Teams, und trotzdem nimmt man auch mal etwas in die
Hand, wenn es nötig ist. So jemandem gibt man gern weitere Aufträge.
Man darf aber den wichtigsten Punkt niemals vergessen: die Entscheidung liegt immer beim Kunden!
Besonders als Freelancer hat man wenig Einblick in die Interna und die politischen Verhältnisse. Auch
wenn alle mit einem zusammen arbeiten, hat man immer den Duft des zu gut bezahlten
Springinsfeld an sich, der nicht alles wissen muss. Und dem man auch nicht alles sagt.
Nur ein Überblick
Natürlich ist das Thema "Kundenbeziehung" weit komplexer als es hier geschildert werden kann.
Jeder Kunde ist anders, und jeder muss anders angesprochen werden. Während man bei einem
Projekt praktisch jeder Freiheit hat muss man sich beim nächsten an ein enges formales Korsett
halten. Wenn man jedoch seine Rolle in dem Spiel kennt und den Gegenüber als Mensch ernst
nimmt, kann man die meisten Probleme umgehen. Aber egal um welchen Kunden es geht: wenn
man sich nur auf sein Spezialgebiet stürzt und nicht aktiv auf den Kunden zugeht wird man ihn kaum
zufriedenstellen können.
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
13
Literatur
Folgende Literatur möchte ich jedem ans Herz legen, der seine Kunden glücklich machen will:
The Secrets of Consulting. A Guide to Getting and Giving Advice Successfully
Gerald M. Weinberg
EAN 978-0932633019
More Secrets of Consulting: The Consultant's Tool Kit
Gerald M. Weinberg
EAN 978-0932633521
Mastering the Requirements Process: Getting Requirements Right
Suzanne Robertson, James Robertson
EAN 978-0321815743
Death March
Edward Yourdon
EAN 978-0131436350
Slack: Getting Past Burn-out, Busywork, and the Myth of Total Efficiency
Tom DeMarco
EAN 978-0932633613
Software Estimation: Demystifying the Black Art
Steve McConnell
EAN 978-0735605350
Raving Fans: A Revolutionary Approach To Customer Service
Ken Blanchard, Sheldon Bowles
EAN 978-0688123161
Get to know me!
Das muss auch sein: wer Unterstützung bei einem Projekt sucht, kann sich gerne an uns wenden:
http://www.systemgilde.de. Steht ein Death March-Projekt an und es fehlt die eigene Expertise
dies erfolgreich zu Ende zu führen? Wird technisches Projektmanagement benötigt? Gibt es
Beratungsbedarf wegen internationaler Kunden? Fehlt die Zeit für eine Machbarkeitsanalyse? Oder
werden einfach Code Monkeys benötigt, weil man selbst ausgelastet ist? Wir können all das leisten,
und noch mehr!
Aus dem Leben eines Freelancers - wie man Kunden glücklich macht
14