Beiträge gettagt mit An meiner Wand

23 Dinge #0: Menschen

17. Jan

Verfasst von schst unter IT Management

Keine Kommentare

Artikel der Serie "23 Dinge"

  1. 23 Dinge über Software-Entwicklung in Teams
  2. 23 Dinge #0: Menschen

Bevor ich über 23 Dinge blogge, möchte ich noch einen Artikel voran stellen, der die folgenden Artikel meiner Serie in einen entsprechenden Kontext setzt. Sie bekommen hier sozusagen einen Tipp, wie Sie die folgenden Tipps anwenden sollten.

Beginnen möchte ich mit einem Yogiism von Dale „Yogi” Berra, einem der erfolgreichsten Baseball-Spieler der US-Major League:

„In theory, there is no difference between theory and practice. In practice, there is.”

Frei übersetzt bedeutet dies so viel wie:

„In der Theorie sind Theorie und Praxis das selbe, in der Praxis sind sie es nicht.”

Meine 23 Dinge, die Sie über Software-Entwicklung ins Teams wissen sollten, entspringen zwar meiner praktischen Erfahrung, aber in diesem Blog werden sie auf Theorien reduziert. Die Tipps haben mir in den Teams, in denen ich bereits gearbeitet habe (sowohl in geschäftlichen, als auch im Open Source Umfeld), wertvolle Dienste geleistet. Das bedeutet jedoch nicht zwangsläufig, dass diese Tipps sklavisch bei Ihnen angewendet werden sollten. Manche Tipps müssen vielleicht an ihr Umfeld angepasst werden, andere funktionieren in Ihrem Umfeld überhaupt nicht.

Sobald Sie von Teamarbeit sprechen, sollten Sie nicht vergessen, dass es dabei auch immer um Menschen geht. Die Menschen sollten immer im Mittelpunkt Ihrer Bemühungen stehen, denn sie sind es, die Ihr Team formen und am Ende die Software produzieren.

Und Menschen sind nun mal verschieden. Also sind auch Teams verschieden und werden nicht genau gleich auf die Tipps in dieser Artikelserie reagieren. Achten Sie also beim Umsetzen der Tipps darauf, dass Ihnen nicht der Fehler auf diesem Poster passiert:

Conformity - It's the one who is different, that get's left out in the cold.

Schätzen Sie die Unterschiedlichkeit Ihres Teams und wenn ein Tipp nicht zu Ihnen oder Ihrem Team passt, dann passen Sie ihn an. Dieses Poster hängt im Büro übrigens auch in DIN A1 an meiner Wand, um mich und andere jeden Tag daran zu erinnern.

Vorheriger Artikel der Serie
, ,

An meiner Wand – mit Amilio

10. Jan

Verfasst von schst unter Web

Keine Kommentare

Nils Langner von phphatesme.com bietet mit amilio einen neuen Service an, mit dem man sich mit ein paar Klicks (und dem Ausfüllen von fünf Feldern) kleine Motivationsposter erstellen kann.

In Anlehnung an mein Posting „Don’t assume”, hat Herr Nils gleich noch ein Poster erstellt, das ab Montag mein altes Poster ablösen wird:

Wer sich wundert, dass das Zitat von meinem abweicht: In diesem Poster wird das Originalzitat verwendet, ich hatte das für mein Posting ein bißchen abgewandelt, da es auch in dieser Form an meiner Wand steht.

,

Denk positiv!

07. Jan

Verfasst von schst unter IT Management

1 Kommentar

Unter dem Tag „An meiner Wand” publiziere ich Weisheiten, die mir so wichtig sind, dass sie bei mir im Büro an der Wand hängen. Heute habe ich allerdings eine Weisheit, die nicht an meiner Wand hängt, sondern, die auf einem kleinen Zettel steht, den ich immer in der Innentasche meines Jacketts mit mir rumtrage.

Denk positiv, Du Idiot!

Dieser soll mich regelmäßig dran erinnern, beim Auftreten eines Problems, positiv zu denken, anstatt mich auf den negativen Aspekt zu fokussieren. Beispiele für solche Situationen, in denen ich oft zum negativen Aspekt tendiere, bis mich mein Jackett umstimmt, sind:

  • Ein Bug ist aufgetreten. Statt eine Lösung zu suchen, hält man sich mit der Klärung der Schuldfrage auf.
  • Ein Kunde ist mit dem gelieferten Ergebnis, das genau den Anforderungen entspricht, nicht zufrieden. Statt einen Kompromiss zwischen neuen Anforderungen und Umsetzbarkeit zu suchen, wird darüber diskutiert, dass alle Anforderungen korrekt umgesetzt wurden. Das macht den Kunden unglücklich und mein Glück ist nun mal eng mit dem Glück des Kunden verbunden.
  • Eine Schnittstelle wird nicht rechtzeitig und wie vereinbart geliefert. Statt nach einer Lösung zu suchen, wie die weitere Zeitplanung eines unverschiebbaren Projektes noch eingehalten werden kann, wird darüber diskutiert, warum es zur Verschiebung kam und dass dadurch der unverschiebbare Zieltermin eben doch verschoben werden muss.

Nüchtern und objektiv betrachtet, wissen wir alle, wie man sich in solchen Situationen verhalten muss, um das Beste daraus zu machen. Befinde ich mich aber subjektiv und emotional in einer solchen Situation, bedarf es oft eines Außenstehenden, der mich daran erinnert, wie ich mich eigentlich verhalten möchte. Dieser Außenstehende bin ich durch meinen Zettel selbst, eben nur mit einer Erinnerung aus der Vergangenheit.

Dank gebührt hierbei auch Stefan Schopohl, der „Denk positiv, Du Idiot!” für mich gestaltet, ausgedruckt und ausgeschnitten hat, nachdem ich immer nur davon geredet habe.

Don’t assume!

05. Jan

Verfasst von schst unter IT Management

1 Kommentar

Manche Weisheiten sind so einfach, dass man sie immer wieder vergisst. Aus diesem Grund hänge ich mir solche gerne bei mir im Büro an die Wand, damit ich regelmäßig mit der Nase drauf gestoßen werden.

In regelmäßigen (oder wahrscheinlich eher unregelmäßgen) Abständen werde ich diese jetzt auch in meinem Blog posten. Ihr findet diese Artikel dann alle unter dem Tag „An meiner Wand”. Den Anfang macht heute die folgende Weisheit von Oscar Wilde:

Don’t assume – it makes an «ass» of «u» and «me».

Auf den ersten Blick klingt das in der Software-Entwicklung etwas seltsam, da wir alle wissen, dass in kaum einem Software-Entwicklungsprojekt immer alle Anforderungen klar auf dem Tisch liegen. Dabei bleibt uns als Entwicklern oft nichts anderes übrig, als Annahmen zu treffen.

Wichtig ist aber, dass man sich in solchen Moment bewusst sein muss, wo man nur Annahmen trifft. Sonst macht man ganz plötzlich Annahmen, von denen man annimmt, dass es Fakten sind. Und nichts ist schlimmer, als Annahmen über Annahmen zu treffen.

Und genau da beginnt das Problem. Sie treffen Entscheidungen auf Basis von Fakten, die nur in Ihrer Vorstellung existieren. Typische Annahmen, die zu Problemen führen sind:

  • „Ich denke nicht, dass der Kunde diese Anforderung nochmal ändern wird. Die ist in Stein gemeißelt.”
  • „Unsere Applikation ist so langsam, weil wir Datenbank XXX verwenden, wir müssen stattdessen die Datenbank YYY einsetzen.”

Während die erste Annahme dazu führt, dass Sie dem Kunden Flexibilität nehmen, investieren Sie bei der zweiten Annahme Zeit und Aufwand in eine Optimierung, die unter Umständen unnötig ist. Damit landen Sie nämlich bei Premature Optimization, und darüber hat Donald Knuth mal gesagt:

Premature optimization is the root of all evil.

Bevor Sie also annehmen, dass ein Kunde eine Anforderung in Stein gemeißelt hat und darauf hin eine Architektur-Entscheidung treffen, sprechen Sie doch lieber mit dem Kunden darüber. Erklären Sie ihm zur Not auch, welche Vor- und Nachteile hat, wenn er genau diese Anforderung unumstößlich festlegt und Ihnen damit eine bestimmte Architekturentscheidung ermöglicht.

Und bevor Sie annehmen zu wissen, wo das Performance-Problem Ihrer Anwendung liegt, fragen Sie doch einfach einen Profiler und stützen Ihre Entscheidungen auf Fakten.

, , , ,