Archiv der Kategorie: allgemein

Der Weg zum Meister – meine 10.000 Stunden als Entwickler

Ten thousand hours of practice is required to achieve the level of mastery associated with being a world-class expert — in anything.

Daniel Levitin

Die 10.000 Stunden Regel sollte jedem Entwickler (und auch jedem anderen) ein Begriff sein. Die Regel basiert ganz lose auf den Studien von Anders Ericcson und wurde hauptsächlich durch das Buch „Outliers“ von Malcolm Gladwell bekannt.

Die Regel ist nicht wissenschaftlich belegt sondern ist eher als Richtlinie zu verstehen und besagt, dass jeder der auf seinem Fachgebiet führend sein oder werden möchte, mindestens 10.000 Stunden „Deep bzw. Delibate Practice“ benötigt.

Was bedeutet Deep Practice?

Nehmen wir zum Beispielproduct_owner_rahmen Karl.

Karl ist Entwickler und das seit 10 Jahren. Karl ist aber niemand, der sich intensiv mit seiner Arbeit und seiner Tätigkeit identifiziert, sondern ein 09:00 – 17:00 Entwickler.

Karl ist auch niemand, der sich in seiner Freizeit mit neuen Themen, Programmiersprachen und Problemstellungen auseinandersetzt.

Karl macht seinen Job – gut und zufriedenstellend – aber nicht herausragend.

Man könnte jetzt annehmen, das Karl die 10.000 Stunden schon lange geknackt hat und als Meister seines Faches zählt.

Mal im Kopf überschlagen:

220 (grob Arbeitstage pro Jahr abzgl. Urlaub) * 8 (Stunden pro Tag) * 10 Jahre = 17.600 Stunden

So gerechnet müsste Karl also ein Superstar und ein Held in seinem Metier sein. Das was Karl aber tagtäglich macht ist keine Deliberate Practice sondern sein Tagewerk, und Tagewerk zählt nicht in die 10.000 Stunden Regel.

Was wäre wirkliche Praxis in Karls Job als Entwickler:

  • Auseinandersetzung mit komplexen Problemen, die neue Denkmuster erfordern
  • Neue Programmiersprachen, Konzepte und Ansätze erlernen und meistern
  • komplexe Algorithmen verstehen
  • Pair Programming und Auseinandersetzung mit Kollegen
  • Konzepte lehren und schulen
  • Fokussierung und Konzentration

Was zählt nur in Teilen:

  • Wiederholte und oft gelöste Aufgabenstellungen (sich wiederholende Aufgaben können für Routine sorgen, aber nur wenn Sie bewusst gelöst werden und nicht „automatisch“)

Was zählt gar nicht:

  • Fachfremde Aufgaben (Rechnungsstellung etc.)

Stellen wir die Rechnung also nochmals auf:

220 (grob Arbeitstage pro Jahr abzgl. Urlaub) * 4 (Stunden pro Tag) * 10 Jahre = 8.800 Stunden

Nehmen wir vereinfacht an, Karl verbringt pro Tag 4 Stunden mit echter Praxis für seine Arbeit. An manchen Tagen vielleicht weniger, an manchen Tagen mehr. Im Mittel könnte das stimmen. Das bedeutet, Karl hat bis dato 8.800 Stunden Praxis gesammelt. Im fehlen also noch genau 2.200 Stunden zum Meister.

Da potentiell die Möglichkeit zur Konzentration und Fokussierung abnimmt, je länger man im gleichen Job arbeitet,  wird auch die Praxis, die Karl pro Jahr sammeln kann abnehmen. Das bedeutet, es ist sehr fraglich, ob er jemals den Status eines Meisters erreichen kann (und vielleicht auch will).

Ich stelle die Rechnung mal grob für mich auf. Ich habe im Jahr 2002 angefangen, mich mit Programmiersprachen zu beschäftigen (ungefähr..).

2002 (grob jeden zweiten Tag eine Stunde) – (250 / 2 * 1)
2003 (grob jeden dritten Tag eine Stunde, da ich hier viel gearbeitet habe) – (250 / 3 * 1)
2004 (im Studium jeden Tag ca. eineinhalb Stunden inkl Wochenenden) – (250 * 1.5)
2005 – (im Studium jeden Tag ca. zweieinhalb Stunden inkl Wochenenden)(250 * 2.5)
2006 – (Praxissemester – hier habe ich ein halbes Jahr lang extrem viel gelernt und gearbeitet)
(125 * 6) + (125 * 2.5)
2007 – (Annahme, 3 Stunden Praxis pro Tag + 150 Extrastunden für die Abschlussarbeit) (250 * 3) + 150
2008 – (Studienabschluss und erstes grosses Projekt mit steiler Lernkurve) (125 * 5)  + (125 * 6)
2009 – (extrem viel gearbeitet und gelernt – Annahme 270 Arbeitstage) (270 * 6)
2010 – (einige neue Projekte, viele unterschiedliche Programmiersprachen und Werkzeuge) 270 * 6 + 100
2011 – 280 * 6
2012 – (großes neues Projekt, neues Team, Teamlead und Scrummaster) – 280 * 6
2013 (Selbstständigkeit)- 80 * 10

Die Rechnung ergibt also folgendes:

(250 / 2 * 1) + (250 / 3 * 1) + (250 * 1.5) + (250 * 2.5) + (125 * 6) + (125 * 2.5) + (250 * 3) + 150 + (125 * 5)  + (125 * 6) + (270 * 6) + 270 * 6 + 100 + 280 * 6 + 280 * 6 + 80 * 10 = ~12.000 Stunden Praxis in 10 Jahren.

(Natürlich ist die Rechnung komplett an den Haaren herbeigezogen, aber trotzdem interessant, wenn man mal so grob zusammenrechnet)

Das entspricht in etwa auch den Erfahrungen anderer Menschen, die sich mit dieser Regel befasst haben. Typischerweise braucht man 10 Jahre und ~10.000 Stunden Praxis, um gut in etwas zu werden ( ich behaupte jetzt einfach mal, dass ich in dem was ich mache ganz OK bin).

Es ist extrem interessant, wenn man sich weiter mit dem Thema Deliberate Practice beschäftigt. Hier sind einige Buchempfehlungen zum Thema:

 

Malcolm Gladwell – Outliers

Robert Greene – Mastery

Doug Lemov – Practice Perfect

Weitere Links:

10.000 Stunden Regel

Was ich so mache um auf meine 10.000 Stunden zu kommen

 

 

 

Meine Pläne für 2013

2013 steht direkt vor der Haustür.

2012 war bereits ein sehr ereignisreiches Jahr.

Ich habe Ende 2011 (Quasi aber fast schon 2012) geheiratet.Ich habe meinen Job als Software Consultant gekündigt und habe mich selbstständig gemacht. Ich biete IT Trainings und Consulting / Professionelle Software Entwicklung.

Bisher bin ich mit meiner Entscheidung mehr als zufrieden.

Ich habe 2012 extrem viel gelesen und gelernt.

Ich habe 2012 einige (aber nicht annähernd genug) Vorträge gehalten.

Ich habe 2012 für die Erstellung meiner HomePage einen Wicket-Port für PHP geschrieben (es fehlt noch so viel…)

Was aber ist für 2013 geplant?

So viele Vorträge wie möglich – Angefangen im Februar bei der JUG München.

Mindestens ein interessantes neues Projekt. Ich bin schon relativ lange in meinem jetzigen Projekt. Es wird Zeit für eine neue Herausforderung.

Wicket Port – Picket – erweitern um ein vollständiges Framework daraus zu machen.

Zertifizierung zum Spring Certified Professional, Oracle Certified JPA Developer.

Scala und Gradle produktiv einsetzen.

Das sind die Must-Haves. Natürlich sind auch unglaublich viele Themen wie jedes Jahr auf der Agenda.

Mindestens einen Code-Retreat besuchen.

Mindestens 3 Konferenzen besuchen.

Mindestens eine neue Sprache lernen (Vorschläge?)

Falls irgendwie möglich einmal Kanban in einem eingespielten Team erleben.

  • Agiles arbeiten
  • Clean Code
  • Software Craftmanship

Ich wünsche euch allen ein Frohes und erfolgreiches Jahr 2013. Ich hoffe, Ihr bleibt dem Blog auch unter der neuen Adresse weiterhin treu.

Warum das Team verantwortlich ist – immer

Im letzten Artikel habe ich um ein kleines Lächeln gebeten.

Heute geht es zurück zum Ernst des Lebens, denn wir Entwickler haben eine Aufgabe zu erfüllen. Wir machen das aber üblicherweise nicht allein, sondern hinter jedem Entwickler steht hoffentlich ein schlagkräftiges Team.

Gerade wir Agilisten haben hier sehr viel Glück, denn kaum einer hat jemals vom Ein-Mann-Scrum-Team gehört. Auch interessant wäre, wie die WIP-Limits in eine Ein-Mann-Kanban-Team gesetzt werden?:)

Was bedeutet es aber, im Team zu arbeiten?

Hat man hierdurch weniger Verantwortung? Kann man sich in der „Masse“ verstecken? Machts jemand anders?

Definitv nein.

Es gibt einen schönen Spruch, dessen Autor ich leider nicht kenne:

„Wenn der Blinde den Lahmen trägt, kommen sie beide fort.“

Wenn ein Team arbeitet hat es genau zwei Möglichkeiten – entweder das Team arbeitet vereint auf ein Ziel hin – dann sind die meisten Teams kaum zu stoppen. Oder das Team behindert sich selbst (Neid, Misgunst, Misstrauen), dann sind sie nicht schneller oder besser als ein Einzelner Entwickler.

Das Team trägt die Verantwortung, Features, Produkte, Bugfixes bis dorthin zu bringen, wo sie dem Kunden echten Mehrwert generieren – Produktion.

Nicht ein einzelner Entwickler („Wer hat diesen Bug eingebaut?“, „Ich bin für die Service-Schicht verantwortlich“), sondern das Team ist verantwortlich. Kommen Bugs ins System hat das Team versagt – fehlende Code-Reviews, fehlende Kommunikation oder einfach nur Faulheit.

Andererseits gibt es im Team keine Super-Heros – das Team sorgt dafür, dass das Know-How verteilt wird (ist nicht immer einfach, fällt mir auch manchmal schwer), so dass mit jedem Feature mindestens ein Entwickler etwas lernt.

So entwickelt das Team im Lauf der Zeit eine Kaizen-Kultur und entwickelt unglaubliche Schlagkraft.

Das Team ist verantwortlich – immer.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum Freundlichkeit professionell ist

Im letzten Artikel habe ich darüber philosophiert, warum ein Entwickler kein Scrummaster und ein Scrummaster kein Entwickler ist.

Eine weitere wichtige Lektion die ich gelernt habe ist, man sollte immer Lächeln, egal was passiert. Vor allem als Scrummaster gerät man oft zwischen die Fronten, muss Probleme beseitigen, muss kommunizieren.

Es gibt einen schönen Spruch von Phyllis Diller:

A smile is a curve that sets everything straight.

Egal was passiert, jedes Problem lässt sich leichter mit Freundlichkeit lösen als mit Agression, Argumentation und Druck.

Ein Buch, das hier wirklich schöne Einblicke bietet (auch wenn der Titel ein wenig seltsam anmutet) ist dieses:

Dieses Buch hat mir wirklich nochmal die Augen geöffnet, und ich empfehle es jedem Scrummaster (und auch jedem Teammitglied), einfach mal zu lesen. Es geht nicht darum, Freunde oder so etwas zu finden, sondern dieses Buch erklärt sehr schön und anschaulich, warum es so wichtig ist, jederzeit freundlich zu bleiben, weil man dadurch nur gewinnen kann.

Lächeln ist professionell 🙂


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum Scrummaster keine Entwickler und Entwickler keine Scrummaster sind (gleichzeitig)

Im letzten Artikel habe ich darüber philosophiert, warum Unit Tests so unglaublich wichtig sind.

Heute möchte ich erklären, warum meiner Ansicht nach Scrummaster niemals Entwickler und Entwickler niemals Scrummaster sein sollten, gleichzeitig.

Ich bin in der glücklichen Situtation, dass ich schon seit langer Zeit in einem interessanten Projekt in einem agilen Umfeld arbeiten kann. In meinem jetzigen Projekt habe ich eine Doppelrolle inne. Ich bin sowohl Entwickler als auch Scrummaster. Leider ist kein Budget für einen dedizierten Scrummaster vorhanden.

Warum ist das ein Problem?

Jeder Entwickler im Team hat bestimmte Vorstellungen, wie das Projekt zu Laufen hat, wie neue Funktionalität implementiert werden soll und wie generell gearbeitet wird. Ich bin zusätzlich so etwas, wie der Technical Lead des Projektes. Ich kümmere mich um Architektur, Qualität und Kommunikation (immer zusammen mit dem Team natürlich).

Ein Scrummaster hingegen sollte keine eigenen Interessen verfolgen,  sondern das primäre Interesse des Scrummasters sollte sein, das Team in jeder Hinsicht zu unterstützen und generell voranzubringen.

In einer Doppelrolle ist das sehr schwierig bis hin zu unmöglich.

Bestes Beispiel ist die Retrospektive, die nach jedem Sprint durchgeführt wird.

In der Retrospektive reflektiert das Team über den Vergangenen Sprint, über Dinge die gut und Dinge die weniger gut gelaufen sind. Die Retrospektive dient dem Team als Gesprächsplattform, um Themen in ungezwungener Atmosphäre auf den Tisch zu bringen und zu diskutieren.

Idealerweise durchläuft eine Retrospektive die folgenden Phasen:

  1. Begrüssung
  2. Rahmen schaffen
  3. Daten sammeln
  4. Aktionen identifizieren
  5. Verabschiedung

Die einfachste Variante für Punkt 3 (das Herz der Retrospektive) sind beispielsweise folgende Aufgabenstellung:

  • Identifiziere 3 Punkte, die sehr gut gelaufen sind, die wie unbedingt beibehalten sollten
  • Identifiziere 3 Punkte, die verbesserungswürdig sind.

In der letzten Retrospektive bei uns im Team war ich wieder in der schwierigen Situation, sowohl Entwickler als auch Scrummaster zu sein.
Jedes Teammitglied hat einige Punkte auf Post-Its Notes notiert. Von mir kam der Punkt:

Meiner Ansicht nach haben wir zu viele Stories gleichzeitig in Bearbeitung.

Ein Punkt, der mir sehr auf der Seele brennt, und den ich unbedingt ändern möchte. Dieser Punkt ist im Team jedoch nicht auf Gegenliebe gestossen, da hier dieser Eindruck nicht unbedingt vorhanden ist.

Was mache ich jetzt als Scrummaster/Entwickler?

Als Scrummaster würde ich den Punkt zwar aufnehmen, evtl auch darüber diskutieren aber wenn der Konsens im Team klar dahin tendiert, dass dies kein Problem darstellt würden daraus wahrscheinlich keine Aktionspunkte entstehen.

Ich als Entwickler weiß, dass wir zu viele Stories in Bearbeitung haben und weniger Stories viel schneller dazu führen würden, dass Dinge wirklich abgeschlossen, lauffähig und in einem Produktivumgebung landen.

Beharre ich jetzt auf meinem Standpunkt und ignoriere meine Scrummaster-Rolle?

Akzeptiere ich meine Rolle als Scrummaster und schlucke meinen Entwicklerstolz herunter?

Die Doppelrolle als Scrummaster/Entwickler ist mehr als suboptimal. Am besten ist es, einen Scrummaster aus einem der anderen Teams (sofern vorhanden) zu bitten, die Leitung der Retrospektive zu übernehmen. Dann könnte ich meine Rolle als  Scrummaster für die Retrospektive vergessen und mich voll und ganz auf die Entwicklerseite und eine erfolgreiche Retrospektive konzentrieren.

Habt ihr damit Erfahrung?

 


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum Unit-Tests so wichtig sind

Im letzten Artikel habe ich darüber philosophiert, warum ich Softwareentwickler geworden bin.

Heute philosophiere ich darüber, warum Qualität gerade in unserem Beruf so unglaublich wichtig ist.

Was ist Qualität überhaupt? Was meinen wir damit?

Software die funktioniert? Selbstverständlich.
Software die wartbar ist? unbedingt!
Software die einfach zu verstehen ist? Auf jedenfall!

Wie aber bekommen wir Qualität in unsere Softwaresysteme, oder besser gesagt, wie nicht?

Es gibt einen schöne Urban-Legend von einem Entwickler aus einem Projekt, in dem ich gearbeitet habe. Dieser Entwickler (wohlgemerkt Senior-Entwickler mit Erfahrung) hat sich strikt geweigert, Unit-Tests für seinen Code zu schreiben. Begründung: Mein Code ist auch ohne Tests gut genug.

Setzen, 6, Thema verfehlt und Konzept nicht verstanden.

Warum schreiben wir Unit-Tests und warum ist es so wichtig? Nicht um sicherzustellen, dass der Code funktioniert, das bekommen die meisten Entwickler (ja die meisten, nicht alle) auch ohne Unit-Tests hin.

Wir schreiben Unit-Tests um sicherzustellen, dass neue Änderungen im System nicht die bereits vorhandene Funktionalität kaputt machen. Unit-Tests sind unser Sicherheitsnetz, der doppelte Boden, der Fallschirm wenns Ernst wird.

Ein Beispiel:

Kürzlich habe ich ein ziemlich umfangreiches Refactoring an einer Serviceklasse durchgeführt. Diese Serviceklasse abstrahiert das Laden verschiedener Kundentypen von verschiedenen Backends und bietet einen einheitlichen View auf Kundendaten für die Applikation.

In dieser Klasse war haufenweise Code der folgenden Art zu finden (in Dummy-Code):

public Kunde ladeKunde(KundenId id){
if(kundentyp ist KundenTyp A){
Lade Kunde von Backend A und mappe in das einheitliche User-Modell
} else if(kundentyp ist KundenTyp B){
 ...
}
}

public Status schreibeKunde(KundenId id){
if(kundentyp ist KundenTyp A){
Mappe in das Backendmodell und schreibe Kundendaten
} else if(kundentyp ist KundenTyp B){
...
}
}

Diese Klasse war zwar hässlich und schwer zu verstehen, ABER komplett Unit getestet. Ohne Unit-Tests hätte sich weder ich noch ein anderer an diese Klasse rangetraut. Das Interface dieses Services war und ist sehr einfach (in Dummy-Code).

public interface Kundenservice {
    public Kunde ladeKunde(KundenId kunde) throws KundenDatenException
    public Status speichereKunde(Kunde kunde) throws KundenDatenException
}

Alle Unit-Tests haben sich an die wichtige Konvention gehalten, dass sie keine Internas der Implementierung testen, sondern nur gegen das Interface, also im Prinzip nur gegen die beiden Methoden.
Ein Unit-Test für diesen Service sah ungefähr so aus (in Dummy-Code mit Mockito-Mocks)


@Mock
private CustomerServiceKundenTypeA typAService;
@Mock
private CustomerServiceKundenTypB typBService;
@InjectMocks
private KundenService testee;

@Before
public void setUp(){
   testee = new KundenServiceImpl();
   //injeziere Mockito-Mocks in testee 
}

@Test
public void ladeKundenTypA(){
   KundenId kundenId = KundenId.alsTypA(4711);
   Kunden kunde = testee.ladeKunde(kundenId);
   //verifiziere dass CustomerServiceKundenTypeA ladeKunde aufgerufen wurde
   //verifiziere geladene Kundendaten 
}

Diese Tests gab es für jeden Kundentypen, für jede mögliche Konstellation und sogar Fehlerfälle, immer gegen das Interface getestet. Ein Traum.

Was war zu tun?

Ich habe die komplette Logik aus dem Kundenservice extrahiert und eigene CustomerTypeHandler implementiert.

public interface CustomerTypeHandler {
   public Kunde ladeKunde(KundenId kundenId);
   public Status speichereKunde(Kunde kunde);
   public boolean accepts(KundenId);
}

Fast lle if-else-Konstrukte aus dem Kundenservice konnten direkt gelöscht werden, der Kundenservice dient fortan nur noch als Facade für die CustomerTypeHandler und kümmert sich nur noch darum, den korrekten Handler zu finden. Beispiel:

public Kunde ladeKunde(KundenId kundenId){
  for(CustomerTypeHandler handler : handlers){
     if(handler.accepts(kundenId)){
         return handler.ladeKunde(kundenId);
     }
  }
}

Das schöne ist, dass sich an der Schnittstelle des Kundenservice nichts geändert hat, es handelt sich also beinahe um ein Bilderbuch-Refactoring. Wir ändern die interne Funktionsweise, ohne die Schnittstelle anzufassen.
Nach dem Refactoring waren alle Tests, die vorher grün waren auch weiterhin grün.
Es war also nicht einmal nötig, das Portal hochzufahren um sicherzustellen, dass alles noch wie zuvor funktioniert.

Im Nachgang wurden dann die Tests auf die einzelnen CustomerTypeHandler verteilt, und der Kundenservice selbst testet nur noch, dass der korrekte TypeHandler getriggert wird.

Ohne Unit-Tests wäre diese Refactoring gefährlich bis sogar unmöglich gewesen, ohne jeden möglichen Fall manuell nachzutesten.

Leider mache ich nach wie vor bei vielen Entwicklern die Erfahrung, dass die Wichtigkeit von Unit-Tests nicht verstanden wird. Und jedesmal wenn ich frage, ob für neue Funktionalität Unit-Tests geschrieben wurden sehe ich rollende Augen und genervte Blicke.

Software ohne Unit-Tests ist unprofessionell, dann könnte auch ein Automobilhersteller Autos ohne Crash-Tests ausliefern. Kann funktionieren, ist aber reine Glückssache. Und daran gibt es nichts zu rütteln.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Warum ich Entwickler geworden bin

Beinahe ausschließlich jeder in meinem Bekanntenkreis ist der festen Ansicht, dass mein Job darin besteht, tagtäglich nicht mehr funktionierende PCs zu reparieren und wieder verkehrstüchtig zu machen.Deswegen antworte ich auf die Frage, was ich denn beruflich mache grundsätzlich , dass ich Entwickler bin, denn alles andere hat unweigerlich eine Antwort der folgenden Art zur Folge:

„Ach, super, ich hab da ein Problem mit meinem PC, nämlich…“

Erstaunlicherweise besteht mein Job nicht darin, PCs zu reparieren, ganz und gar nicht.

Ich löse Probleme, und zwar die Probleme meiner Kunden. Das Schöne dabei ist, ich löse die Probleme nicht nur, sondern ich löse diese Probleme elegant.

Am interessantesten dabei ist allerdings, dass viele Kunden oft gar nicht genau wissen, für welches Problem eine Lösung gefunden werden muss. Der Job eines Entwicklers besteht darin, durch Kommunikation, Fragen, Analysen so lange nachzubohren, bis man zum Kern der Problemstellung vorgestossen ist.

Ein Beispiel:

Der Kunde wünscht sich, dass tagtägliche Excel-Reports von Einkäufen in einem Online-Shop generiert und per E-Mail an einen Verteiler geschickt werden sollen.

Entwickler A setzt sich hin,  implementiert das Ganze in 1-2 Tagen und stellt anschließend die Rechnung.

Entwickler B fragt, warum dieser Export gebraucht wird. Es stellt sich heraus, dass aus diesen Excel-Sheets manuell Statistiken für die Geschäftsführer-Ebene erstellt werden. Der Kern des Problems ist also nicht, einen einfachen Report zu generieren, sondern das eigentliche Problem, dass es zu Lösen gilt ist, wie man von manuellen Prozessen weg kommt und die Reports direkt aus den täglichen Einkäufen generieren kann.

In diesem einfachen Beispiel lässt sich ein echter Mehrwert für den Kunden generieren, wenn man nur versucht, zu verstehen, was gebraucht wird.

Mein Lieblingssatz (der schon x-fach zitiert wurde) ist von Henry Ford:

„Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie sich schnellere Pferde gewünscht“.

Das bedeutet nicht, dass wir als Softwareentwickler nicht das tun sollen, was die Kunden möchten. Ganz und gar nicht, aber es ist mein Job, für das Geld was mir bezahlt wird die bestmögliche Lösung zu finden, auch für Probleme die vielleicht erst noch identifiziert werden müssen.

Und genau aus diesem Grund bin ich Softwareentwickler.