Dienstag, 23. Juni 2015

Das Toyota-System: Lean und Kaizen. Einige Begrifflichkeiten.

Die Grundlagen von Lean sind weder irgendwelche Werkzeuge noch eine Vermeidung von Verschwendung.

Wakamatsu und Kondo, beide Experten bei Toyota, brachten es auf den Punkt:
Das Wesen des Toyota-Systems ist einfach; dass jeder einzelne Mitarbeiter die Gelegenheit hat, in seinen eigenen Arbeitsumfeld Probleme zu finden, diese zu lösen und Verbesserungen zu machen.

So "einfach" wie es auch klingt, so schwierig ist doch die Umsetzung.

Das Toyota-System kann man durch 2 Grundlagen kurz beschreiben:
  1. Kontinuierlich Verbessern, und
  2. Menschen respektieren.

Ständige Verbesserungen, -oft als Kaizen benannt- ist Toyotas Ansatz, das tägliche Geschäft zu führen. Nach dem Prinzip: "Alles in Frage stellen". Mit anderen Worten: "Stets denken".

Wichtiger aber als die tatsächlichen Verbesserungen, die die Mitarbeiter umsetzen (dürfen), ist der wahre Mehrwert das Schaffen einer Umgebung in der man ständig lernen kann; eine Umgebung, die nicht nur Änderungen akzeptiert, sondern sie geradezu fördert.
Eine solche Umgebung kann nur dort entstehen, wo man die Menschen ohne wenn und aber respektiert - daher ist dieser der 2. Grundsatz des Toyota-Systems.

Und an diesem 2. Grundsatz scheitert grundsätzlich die Mehrzahl von unserem "westlichen" Management.

Kaizen wird (oft) schlicht als "kontinuierliche Verbesserung" übersetzt. Das aber verwechselt die Bedeutung von "kontinuierlichen Verbesserung" und ist nicht mit dem wahren "Kaizen" deckungsgleich.
Es wird empfohlen, das japanische Wort Kaizen zu gebrauchen und sich dabei der wahren Bedeutung bewusst werden: Kaizen ist gleichzeitig gelebte Praxis und eine (persönliche) Einstellung.
Nicht einfach "stets verbessern"...


Cargo Cult (Cargo-Kultur)


Eine Cargo-Kultur sind Rituale, von einer (primitiven) Gesellschaft durchgeführt, die das Verhalten von nicht-native Besucher (oft aus Europa) nachahmt.

Analog dazu nennt man Cargo-Kultur-Prozesse solche, wo Rituale und Oberflächlichkeiten, ohne eingehendes Verständnis für die Hintergründe, praktiziert werden. (Oft vorzufinden bei vielen Organisationen, die "Agile Methoden" praktizieren, ohne sich mit der "agilen" Denkweise auseinander zu setzen -siehe "Scrum"-.)

Eine "Lean Cargo-Kultur" führt "lean" Werkzeuge (durch das Management) ein, ohne dass sich wirklich weder die Denkweise noch das Verhalten von Management oder gar der Mitarbeiter ändert.

Natürlich können sich beide nicht von heute auf morgen ändern, das braucht:
1. (eine lange) Zeit.
2. Maßnahmen, um die Mitarbeiter dahin zu führen (vom Management getragen).
Und sicher auch noch der Wille dazu und die Bereitschaft, Mitarbeiter gewähren zu lassen.

Nein... einfach ist das nicht.

Samstag, 13. Juni 2015

(Nicht so sehr) Lean Untersuchung der Lean-Prinzipien

Zunaechst sei angemerkt, dass die "Lean-Prinzipien" schon eine etwas längere Geschichte haben als die sogenannten "agilen".

Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".

"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."

Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)

Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.

Nun zu den Prinzipien.

Die sieben Prinzipien der Lean-Entwicklung:
  1. Verschwendung vermeiden (siehe weiter unten)
  2. Feedback einfordern (alle Teilnehmer einbeziehen - Kommunikation intensivieren)
  3. Spät entscheiden (sich so viel Zeit wie möglich nehmen: zum Denken und zum Planen)
  4. Schnell ausliefern (so schnell wie möglich die Entwicklung durchziehen, nachdem "entschieden" wurde)
  5. Team trägt Verantwortung (impliziert Selbst-Organisation...)
  6. "Integrität einbauen" ("stets" standardisieren, so wie ich es verstanden habe)
  7. Die Gesamtheit optimieren (Den gesamten Prozess verbessern)

Andere "Übersetzungen" postulieren:
  • Die Arbeiten gleich beim 1. Mal richtig machen (inhaltlich zum 1. Punkt: keine Verschwendung)
  • Den Arbeitern erlauben, Entscheidungen zu treffen (nicht nur "ganze Teams" sondern auch auf persönlicher Ebene)
  • Stets verbessern (inhaltlich zum 7. Punkt)
  • Lernen unterstützen (entfernt verwand mit dem 2. Punkt...)


Und hier die 7 Verschwendungen der SW-Entwicklung:

  • Überproduktion (Zusätzliche Funktionalität)
  • Inventur (Administration / Anforderungen)
  • Zusätzliche Produktionsschritte (Komplexität / Überfluss)
  • Bewegungen (Suche von Informationen)
  • Fehler (Bugs / Fehler in der SW / Tools mit )
  • Wartezeiten (Warten auf Entscheidungen / Warten auf Kunden-Feedback)
  • Transport (Schnittstellen / Workflow der Arbeit)


Hier die japanischen Begriffe für Verschwendung:

- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.


Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.

Samstag, 23. Mai 2015

Warum Scrum abbrennen soll (eine Übersetzung)


Why Scrum Should Basically Just Die In A Fire (hier nur ein Abzug)

Von: http://gilesbowkett.blogspot.de/2014/09/why-scrum-should-basically-just-die-in.html

(Ich empfehle das Original zu lesen!)


The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense.

Well-written text very often trumps face-to-face communication. You can refer to well-written text later, instead of relying on your memory. You can't produce well-written text unless you think carefully. Also, technically speaking, you can literally never produce good code in the first place unless you produce well-written text. [...]

In fact, GitHub itself was built without face-to-face communication. Basecamp was built without face-to-face communication as well. I'm not saying these people never met each other, but most of the work was done remote.  [...]. And face-to-face communication plays a minimal role in the majority of open source projects, which usually outperform commercial projects in terms of software quality.

In addition to defying logic and available evidence, both these Agile Manifesto principles (1) encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points.


Übersetzung (des Abzuges)

Das Agile Manifesto widerspricht auch die Standup des Scrum . Es besagt, dass "die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch". Um fair zu den Autoren zu sein muss man hier bemerken, dass dieses wurde im Jahr 2001 geschrieben, und zu dieser Zeit gab es noch kein git log. Bei den heutigen Tools, die für die verteilte Zusammenarbeit existieren, es diese Behauptung recht unglaubwürdig, und eben auch im Jahr 2001; musste man doch annehmen, die Autoren haben nie etwas von Linux gehört, wenn Sie wirklich richtig liegen sollten.

Ein gut geschriebener Text ist oft einfach besser als ein persönliches Gespräch. Ein Text kann jederzeit nachgelesen werden, anstatt dass man sich auf das eigene Gedächtnis verlässt. Man kann auch ein Text nicht schreiben ohne (genau) zu wissen, was man wirklich äußern will. Technisch gesehen, man kann auch nicht gut programmieren wenn man nicht richtig schreiben kann. [...]

Richtig ist es, dass GitHub selbst ohne persönliche Gespräche entwickelt wurde. Das Gleiche gilt für Basecamp. Ich behaupte nicht, das die Entwickler sich nie getroffen haben, doch die meiste Arbeit wurde aus der "Ferne" getan. [...]. Ebenfalls spielen persönliche Gespräche in den meisten Open-Source-Projekte eine untergeordnete Rolle. Und Open-Source-Projekte übertreffen in der Regel, in Bezug auf die Qualität der SW, kommerzielle Projekte.

Nich nur dass diese beide "agilen" Prinzipien (1) vorhandene Beweise und einfache Logik trotzen, sondern dass sie auch eine Art Kindergarten-Mentalität fördern. Ich habe noch nie gesehen, dass man Scrum bei Design, Buchhaltung oder Ein- und Verkauf benutzt: oberflächliche, Bilderbuch-ähnliche Vereinfachungen, wie die Sache mit den "Story Points" (Bewertung der 'Geschichten').


(1)
Als 2. Prinzip ist gemeint:
"business people and developers must work together."
Zu deutsch:
'Geschäftsleute und Entwickler müssen zusammenarbeiten.'

Die 1. angesprochene Prinzip war:
'die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch'.

Mittwoch, 13. Mai 2015

Agile Prinzipien: Schwammig. Schwach. Lahm.

From: http://www.agilemanifesto.org/principles.html
Principles behind the Agile Manifesto

We follow these principles:


1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -the art of maximizing the amount of work not done- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Mein Senf dazu:

Zu 1. Gut und wichtig ist es, den Kunden stets glauben zu lassen, man will sie zufriedenstellen. Ansonsten ist der Punkt eher schwammiges Wunschdenken.

Zu 2. Mehrarbeit zu begruessen zeugt eher von schwacher Denkweise. Es soll gelten: Aenderungen zu minimieren. Das soll auch der Kunde beherzigen. Je eher die Anforderungsaenderungen erscheinen desto besser, man soll diese ergo verlangen, ASAP, doch nicht "auch spaet im Projekt diese willkommen heiszen".

Zu 3. Schwacher Punkt. Es ist wichtig, dass das Ergebnis funktioniert, und zwar so gut wie moeglich. Das die SW lange vor Ende des Projekts "arbeitet", und auch diese (so) oft (wie moeglich) zu liefern... das kann kein wirkliches Ziel sein. Ziel ist das Endergebnis. Und darauf sollte man fokusieren.

Zu 4. Die Entwickler taeglich mit Meetings (oder was auch immer eine Zusammenarbeit bedeutet) mit "Business People" wuerde den Entwickler eher zu sehr ablenken, belasten. Eine enge Zusammenarbeit ist erwuenscht, doch "taeglich" ist uebertrieben. Die "Business People" sollen dem Entwickler jederzeit zur Verfuegung stehen. Nicht mehr und nicht weniger. "Taeglich" etwas zu erzwingen ist irgendwie besonders unflexibel.

Zu 5. Gute Idee. Ist das aber eine exklusive Eigenschaft des "Agilen" Entwickelns, oder eher eine allgemeine gute Idee ...?

Zu 6. Aber auch nicht immer. Ausnahmen existieren. Ich halte solche allgemenine generalisierneden Aussagen, fuerwahr, fuer eher unflexibel. Die Punkte 5 bis 7 sind eher allgemeine gute Praktiken, wurden aber sicher nicht von den Autoren des "agilen Manifests" "erfunden".

Zu 7. Es kommt darauf an, wie man "Fortschritt" definiert. Und was man genau messen will. Komplexitaet, z.B. -in Bezug auf Fortschritt-, sollte man anders messen. Diese Aussage ist in meinen Augen auch eher zu allgemen. Dieser Punkt auch eher unflexibel.

Zu 8. These ohne Beweis. Nur solange die Entwickler bezahlt werden, werden sie auch entwickeln. Ausserdem muessten die Entwickler auch die Taetigkeit als sinnvoll erachten. Diese Voraussetzungen basieren nicht auf "agilen Prinzipien".

Zu 9. Scheinbar waren die Schreiber des Manifests ab Punkt 8 schon etwas muede. Schoene Woerter, zusammenhaltslos aneinadergereiht. Nicht nur, dass die Folgerung, wie hier beschrieben, nicht ersichtlich ist; sondern vielmehr lassen sich zahlreiche Gegenbeispiele zu dieser Aussage finden.

Zu 10. Einfachheit ist schon (sehr) wichtig. Doch "essential" ? Na ja. Ausserdem ist "Einfachheit" ganz sicher nicht "die Kunst, die nicht verrichtete Arbeit zu maximieren". Im Gegenteil; oft muss man mehr Arbeit verrichten und ein System einfacher zu gestalten.

Zu 11. Ich halte dieses Prinzip auch wieder fuer schwach im Sinne des Denkens: Gute Architekturen werden von guten Architekten entwickelt. Gute Anforderungen werden von guten Requirement-Engineers geschrieben. Gutes Design wiederum von guten Designers erstellt. Diese Arbeiten haben mit einem Team eher wenig zu tun. Ziemlich egal wie sehr sich das Team "selbst organisiert".

Zu 12. Gutes Prinzip. Sehr gut sogar (richtung Kaizen). Doch... eine Exklusivitaet von agilen Teams...? Zweifle ich stark.

Mein Fazit zu dem Manifest:

Inhaltslos: Punkte 1, 5 und 9.
Unflexibel: Punkte 4, 6 und 7.
Folgerung unlogisch: Punkte 8 und 9.
Falsch: Punkte 2, 10 und 11.

Auch hier (wie bei http://www.agilemanifesto.org) sollte man stark (zum Besseren) ueberarbeiten.
Vom urspruenglichen Manifest wird wahrscheinlich kaum etwas uebrig bleiben.

To be done. Bei mir. Im Laufe dieses Jahres.
 :-)

Freitag, 3. April 2015

Agile heilige Kühe in Indien...


Frage: Warum sind die Inder so stark vertreten seit einigen Jahren (seit der Einführung der "agilen" Methoden) bei der Entwicklung von Software?

Antwort: Weil bei der Software-Entwicklung so viele heiligen Kühe gibt!

Freitag, 27. März 2015

Wie "Agil" ist eigentlich "Agil"? Was kann man damit anfangen?

From: http://www.agilemanifesto.org

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:
1- Individuals and interactions over processes and tools
2- Working software over comprehensive documentation
3- Customer collaboration over contract negotiation
4- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.



Meine Gedanken zu den "Werten" des Manifestes:

1- Also, "agil" sind Individuen ohne Tools die wilde Interaktionen ohne wesentliche Prozessorientierung zu tun pflegen.

2- Das Ergebnis wird dann nicht unoft: "Unmaintable SW and uncomprehensive documentation". Also für die Katz, die Entwicklung...

3- Echt super, die Kunden werden geradezu ermuntert, ständig Änderungen und neue Funktionalitäten zu fördern!

4- Alles Andere als zielorientiert...

Daraus folgt, aus meiner Sicht: Das "Manifesto" ist noch nicht richtig anwendbar, ca 80% müsste noch korrekt überarbeitet werden.

Dazu, zu lesen (wenngleich nicht besonders informativ, sondern eher Gelaber/Textguss ohne wertvollem Inhalt): http://ronjeffries.com/xprog/articles/beyond-agile-new-principles/

Dienstag, 11. Dezember 2012

Meetings ohne Vorbereitung sind etwas fuer Unorganisierte

Es ist mir klar, dass ich schon radikale Meinungen habe... :-)
Ich moechte ein bisschen hier an dieser Stelle mein Hintergrund ansprechen, das koennte helfen, so hoffe ich jedenfalls, solche radikale Ansichten nachzuvollziehen.

1. Ich bin nun mal Deutscher (trotz oder gerade weil ich im Ausland aufgewachsen bin: ich bin naemlich in einem Deutschen Haushalt aufgewachsen, mit Deutscher Kultur. Ich bin von der Propaganda der Nachkriegszeit in Deutschland nicht in uebermass beeinflusst worden). Und als Deutscher  versuche ich auch immer alles richtig zu machen (deswegen vielleicht arbeite ich auch in erster Linie bei der Qualitaetssicherung).

2. Ich habe Mathematik studiert. Mathe ist doch ein Fach fuer Faule (bitte beachten Sie diese Aussage ganz genau!), fuer Leute die, wie ich, es vorziehen 5 Male zu denken bevor sie etwas tun, dafuer aber richtig. Mathematiker sind Menschen, welche die ganze Zeit versuchen Prozesse zu optimieren, Vorgaenge zu verbessern. Nicht, wie ein lieber Freund von mir behaupten wuerde, weil wir "Gutmenschen" sind, nein; aus Faulheit!

Aus diesem Hintergrund heraus wird es fuer jedermann/jedefrau so weit nachvollziehbar, hoffe ich zumindest, warum ich so denke wie ich denke.

Beschreibung des Ist-Zustandes: Es ist doch so, dass Vorgesetzte mit wenig Ahnung sehr schnell bei der Sache sind, Meetings aufzurufen. Meetings werden also vorgetragen von Personen mit wenig (oder gar keine) Vorbereitung und besucht von Menschen, die oft genug das vermeintlich erteilte Wissen von Meetings ueberhaupt nicht brauchen.
Damit sind Meeting Zeitfresser der uebelsten Sorte:
1. Es gibt Leute (keine Mathematiker ;-) die durch Meetings das Gefuehl kriegen, viel "gemacht" zu haben (mit kaum eine/eigene Anstrengung)
2. Meetings fressen Zeit von Menschen, die das zu ermittelnde Wissen brauchen, es aber unstrukturiert und unvollstaendig durch unvorbereitete Vortrage erhalten (sollen)
3. Fressen Zeit von Menschen, die nur ein Teil (wenn ueberhaupt) der Vortrages brauchen.

Hier einige eigene Gedanken, um Meetings ein Mindestmass an Nutzen einzuhauchen.

Check-Liste zur Verbesserung von Meetings
1. Vorbereiten: Ziel; Was genau ermittelt werden soll
2. Benoetigte Zeit genau festlegen (Zielzeit)
3. Vorbereitung der Teilnehmer (!) Stoff im Vorwege zusenden und Fragen den Teilnehmer vorbereiten lassen (und diesen Punkt hier ist der "Kasus Knaktus")
4. Am Besten die Fragen von Punkt 3. den Vortragenden mitteilen
5. Nacharbeit: Zusammenfassung des Vortrages mit FAQs an alle Teilnehmer zusenden
6. Bei jeder Teilnehmer definieren, warum er/sie teil nehmen soll (sonst keine Teilnahme!)

Es gibt natuerlich Meetings die wichtig sind, z.B. wenn eine Gruppe Designer und Entwickler Teile einer SW definieren muessen. Da hilft natuerlich die Check-Liste sehr, zwecks Definition, was genau das Ergebnis sein soll.

Ich kann mir schon vorstellen, dass ca 90 bis 95 % aller Meetings zwar notwendig sind, doch die Zeit kann man sicherlich halbieren: Ein einstuendiger Meeting kann in 10 Minuten gehalten werden, dazu kommen 15 Minuten Vorbereitung plus 5 Minuten Nacharbeit.

Nachtrag: 37Signals, eine Firma mit der ich keinerlei geschaeftlichen Verbindungen habe, teilt aber meine Meinung ueber Meetings (sie schreibt: Meetings are toxic).

Montag, 26. November 2012

Der Untergang des Titanics aus der Perspektive eines Qualitaetssicherers

Der Fall "Titanic" ist laengst untersucht in allen Einzelheiten.
Also mache ich es kurz nur mit einigen Gedanken aus der Perspektive der Qualitaetssicherung.

Welche waren die Ursachen fuer das Unglueck?
Warum mussten Menschen sterben?
Ganz knapp sind 2 Tatsachen dafuer zu nennen:
1. Das Schiff fuhr zu schnell
2. Es gab nicht genug Rettungsboote fuer alle Passagiere

Und... Warum war das Schif zu schnell?
War der Kapitaen leichtsinnig?
Es war doch seine letzte Fahrt. Alt genug war er also und Erfahrung soll man ihm nicht absprechen. Und schnell soll er gewesen sein weil er einen neuen Rekord aufstellen wollte. So wird es zumindest berichtet. Glauben soll man es nicht unbedingt (wo so viele Sachen, die berichtet werden, oft -sehr oft- gelogen oder bestenfalls erfunden sind). Doch Leichtsinn moechte ich ihm (aufgrund seines Berufslebens) nicht bescheinigen. Warum war er dann zu schnell?
Und warum gab es fuer alle Passagiere nicht genug Rettungsboote?
Auch leichtsinn?
Ja...
Eine Antwort die zu beide Fragen passt und noch dazu schoen geschichtlich belegt ist, ist die, dass das Schiff als unsinkbar galt.
Wenn man oft genug eine idiotische Aussage hoert, dann glaubt man am Ende langsam daran.
Sogar ein alter Kapitaen scheint daran geglaubt zu haben. Er haette es besser wissen, naemlich: Alles sinkt, wenn der Schaden bloss gross genug ist.
Alles. Holz- und Metalschiffe. Einruempfige und mehrruempfige Schiffe, alles.
Wenn der Glaube, dass das Schiff "unsinkbar" war, die Grundlage fuer den Leichtsinn zu gelten hat, dann wuerde ich behaupten, dass die Qualitaetssicherung ganz miserabel gegenueber der Werbung und den Slogansmachern versagt hat.
Die ernuechtende Qualitaetssicherung-Aussage "Alles sinkt wenn der Schaden gross genug ist" wurde ausser Acht gelassen, verdraengt durch die (falsche aber werbewirksame) Aussage "unser Schiff sinkt nicht". Und alle Menschen scheinen es geglaubt zu haben. Auch die, die das eigene Leben aufs Spiel gesetzt haben.

Heutzutage gibt es mehr Regel und Gesetze, Schiffe muessen genug Rettungsboote fuer alle haben. So etwas kann eigentlich nicht mehr vorkommen.
Doch das Problem liegt, meiner Ansicht nach, daran, dass Werbeslogans mehr "gewicht" haben als nuechterndes Ingenieurwissen... schlimmer noch, sie haben mehr gewicht sogar als jahrelanges Berufswissen oder gar schlichter Vernunft.
Oder liegt es eher daran, dass ueber die Werbung nicht nachgedacht wird?
Oder daran, dass, wenn eine Aussage oft genug wiederholt wird, diese geglaubt wird, ohne nachzudenken?
Und, was damals geschah, kann sich doch jederzeit wiederholen.
Nur weil man nicht ueberlegt...
Qualitaetssichern bedeutet ueberlegen. Haette doch damals geholfen, denke ich.

Sonntag, 4. November 2012

REQB Pruefung Foundation Level - Ein Erfahrungsbericht

Die Pruefung sehr geradeaus, sehr an das Syllabus angelehnt. Die ersten 22 Fragen sehr einfach zu beantworten, "Negationen" sind mir nicht aufgefallen.
Nur selten hatte ich Schwierigkeiten, Fragen zu beantworten. Allerdings bin ich ziemlich suspect der Pruefung gegenueber gewesen, weil ich schon bei der ISTQB FL mir ziemlich sicher war, dass es gut gelaufen war; ich hatte doch auf etwa 95% richtige Antworten in den Mock Exams aus dem Internet, zwar waren die Fragen etwas anders in der wahren Pruefung, doch schwieriger kamen sie mir ueberhaupt nicht vor. Nun hatte ich aber "nur" 2 mehr richtig, als notwendig, und damit eigentlich die Pruefung mit "gerade ausreichend" bestanden. Man kann dazu bemerken, dass ich schon seit gut 12 Jahre bei der Qualitaetssicherung arbeite und vielleicht mehr auf Erfahrung als auf Wissen gesetzt habe. Ausserdem hatte ich schon auch bemerkt, dass die gleiche Frage in verschiedenen Mock Exams teils als falsch teils als richtig bewertet wurde. Nichtdestotrotz bin ich mit dem Ergebnis (meine Leistung) der ISTQB FL eher unzufrieden. Aus dieser Erfahrung heraus habe ich auch die REQB sehr "ordentlich" vorbereitet. Ausserdem gibt es im Internet gar keine Mock Exams fuer REQB und sonst keine Muster, so dass ich ganz und gar auf das Syllabus und anderen theoretischen Informationen mich verlassen musste. Dadurch bedingt habe ich auch die Fragen bei der Pruefung sehr genau gelesen.

Bei der Frage wo ich sehr unsicher war: Welche IEEE Norm gilt fuer die Spezifikation von System Funktionalitaet.
Nur unsicher war ich mir bei der Frage; wenn man dabei ist, einer "Solution Spec" zu schreiben, genauer "detailed high level req", und man hat schon das System definiert, die low-level req. spezifiziert, dokumentiert und aneinander in Relation gebracht u.s.w.; was macht man als Naechstes?
- REQ Analysis
- Solution modellieren
- Solution festlegen

Im letzten Teil der Pruefung jedoch, genauer REQ Analysis (auch "Tools" ganz am Ende mit nur 3 Fragen) ist mir aufgefallen, dass viele, viele Fragen mit Negationen behaftet waren, in der Art:
"Welche Aussage gilt NICHT fuer XY (wenn XZ) ?"
Da sollte man schon etwas genauer die richtige Antwort (die falsche) markieren.

Mehr als Definitionen von SysML und UML sollte man nicht wissen; OK, die Charakteristiken der beiden und die Unterschiede zwischen den beiden sollte man schon wissen.
Eine Frage war wohl; was fuer ein UML Diagramm man waehlen wuerde um die Stationen eines Dokuments in einem Document-Management-System darzustellen.
Das Gleiche ueber Agile Methoden... eine Frage gab es, dabei mussste man schon wissen was ein Backlog ist und was nicht.

Summa summarum: Meines Erachtens nach, wenn man erst das Syllabus durcharbeitet, (spricht auch die Fehler des Syllabus erkennen und beseitigen, dann das Richtige und Wichtige verstehen), dazu erstmals und zusaetzlich die Grundlagen von verwandten Themen wie UML (Modellierung) und Entwicklungsmethoden (Agile Methoden) durchlesen, dann hat man eine gute Basis, die Pruefung zu schaffen.

Hier kann man neine eigene Ueberarbeitung des Syllabus runterladen: Ich hatte die englische Version bearbeitet, die Kommentare jedoch sind auf Deutsch:
http://www.scribd.com/doc/110113815/reqb-syllabus

Samstag, 27. Oktober 2012

Kurze Auslassung ueber "Agile Methoden"

Zurzeit leide ich unter die Ignoranz eines (oder mehrerer) einfaeltigen Manager(s), die irgendwie geglaubt haben muessetn, dass wenn etwas sich "agil" nennt, es auch irgendwie sein soll.
Nichts da. Pustekuchen.
Ja, "leiden"; ich habe naemlich eine nicht zu unterschaetzenden Schwierigkeit mit Zeitverlust und Unueberlegenheit.

Bei mir auf der Arbeit wurde so eine "agile" Methode vorgeschrieben. Und zwar die (von meiner Sicht der Sache heraus) schlimmste von allen: Scrum.
Scrum auf deutsch bedeutet "Gedraenge". Was daran gut sein soll, ist mir ein einziges Raetsel. Sowohl an einem echten "Gedraenge" als auch in der Art und Weise, wie diese "Methode" durchgefuehrt wird.

Zunaechst ist auffallend, dass gewoehnliche Dinger bei den Scrum-Propheten mit anderen Namen genannt werden. So gibte es "Sprint" fuer Etappen, Backlog fuer Beschreibungen und das mieseste von allem sind die User Stories. Die gesamte beschriebene "Methode" ist eine Zwangsjacke (de Benutzung des Wortes "Methode" ist weitgehend verfehlt): Man wird gezwungen, anstatt Funktionalitaet, Wuensche bzw Beduerfnisse aus der Sicht eines Benutzers ganz knapp zu (be)schreiben. Ein Beispiel? Bitte schoen: "Als Kranfahrer moechte ich eine Software, was mir die taeglichen Berichte schreibt". Warum abweichende Namen fuer die Sachen? Eine logische Erklaerung gibt's nicht, wahrscheinlich will man irgendwie versuchen, mit positiven Begriffen die Untauglichkeit der "Methode" zu vertuschen.

Ganz wichtig dabei ist, dass der "Kunde" ganz eng mit den Entwicklern zusammenarbeiten muss. In unserem Fall muesste der Kranfahrer jede 2 oder 3 Tage bei den Entwicklern den Fortschritt der Arbeit kontrollieren, sonst wurde am Ende eines "Sprints"... doch nichts Brauchbares rauskommen.
Es ist natuerlich klar, dass ohne genaue Produktbeschreibung die Anwesenheit von Kranfuehrern und Chirurgen und Diplomaten sogar vonnoeten ist, um die SW schreiben zu koennen.

Stoerend wirken sich auch die vorgeschriebenen taeglichen Scrum-Meetings. Diese reissen die Entwickler von der Arbeit weg, und dann wird -alle zusammen stehend- Produktdesign in Mikrosteps gemacht. Ein Scrum-Meeting sollte nicht mehr als 15 Minuten dauern, bei uns dauern sie mindestens 15 Minuten, 1 oder 2 Male in der Woche etwa 30 Minuten, naemlich dann, wenn einen groesseren Step oder Aenderung in dem Design vollzogen werden muss. Nach dem Meeting ist es stets muehsam, sich der abgebrochenen Aufgabe wieder zu widmen. Meine Meinung? Scrum ist fuer ganz besonders Faule, die nicht schreiben koennen und in den Tag hinein zu leben pflegen.
Eine nicht so bescheuerte aber dafuer fast noch zeitraubender Sache -weil uneffizient (sogar mit den taeglichen Scrum-Meetigs verglichen!)-, sind die monatlichen Sprint-Meetings, wo jeder Entwickler selbst, aber in Beisammensein von allen, den Scrummaster schreiben laesst, was er so zu tun beabsichtigt fuer den kommenden Sprint. Dauert etwa 2 Stunden einmal pro Monat bei uns.

Die Scrum "Methode" ist wohl mit einer grossen Anzahl an Meetings versehen, wohl die vielen Studien ignorierend, die schon vor etlichen Jahren herausgefunden haben, was fuer ein Zeitverlust die Meetings darstellen. Ich schaetze, dass mehr als "ignorierend" gilt "Ignoranz": Das Lesen ist keine Staerke der "Gedraenge"-Apostel.

Der Grundgedanke der agilen Methoden, die sich selbst verwaltenden, organisierenden Entwicklerteams ist an sich nicht falsch. Mit Intelligenz angewendet duerften sie sicherlich gute Ergebnisse liefern. Doch, wenn man die Methoden unreflektiert implementiert, dabei es sich auch um eine der "agilen" (ich lache und heule gleichzeitig) Methoden handelt, die am unflexibelsten ist, mit gezwungen vorgeschriebenen Massnahmen... so sollte man eigentlich nicht ueberrascht sein, wenn die Ergebnisse eher ernuechternd wirken.

Es wird zwar behauptet, dass mit Hilfe der Sprints die Produktivitaet steigt (trotz haufenweise unnoetigen Meetings) weil in kuerzeren Etappen "brauchbare Produkte" erzeugt werden (z.B. Prototypen, ungetestete Module, getestete nicht integrierten Module, usw usf). Tja... Wunschdenken ist maechtig. Und ich bestreite nicht einmal (warum sollte ich?), dass die Effektivitaet steigt... leider sinkt dafuer die Effizienz um so mehr.
Bei uns ist nun der Geschaeftsfuehrer Scrummaster geworden. Macht er ganz gut; er laesst sich nicht merken, ob ihm die "Methode" nervt. Vielleicht glaubt er daran, er muesste naemlich; das ist sein Job...

Sicher gibt es Faelle, wo eine Scrummethode gut angewendet werden kann. Doch es sollte genau abgewogen werden, welche Vor- und Nachteile damit verbunden sind. Das blinde Anwenden eine Methode ohne Pruefung, ohne Anpassung, wenn sogar, wie in unserem Falle, einige der "zu empfehlen bei" nicht gegeben sind... das ist alles andere als durchdacht.
Zu empfehlen hierzu sind die Artikel und Buecher bei oose.de
Lesen hilft...

Samstag, 20. Oktober 2012

Was ist falsch mit Power Point?

Alles.
Ueber die Manager, die mittels PoPo (Power-Point) managen, habe ich mich schon frueher geaeussert.
Nun ist es dazu gekommen, dass ich in den letzten Wochen auf der Arbeit alte Kursunterlagen durchgegangen bin. Es sind der Art, dass "Folien" auf der Wand geschmissen werden, die in paar Begriffe beinhalten, und dann wird vom Vortragende in etwas abgewandelte Form den Inhalt wiederholt, waehrend die Zuhoerer gegen das Einschlafen kaempfen.
Mir hat diese Form des Unterrichts schon immer gestoert.
Gruend: Der Kampf gegen das Einschlafen ist dermassen ermuedend, dass man sich nicht auf die unsinnigen Folien konzentrieren kann.
Es gibt natuerlich viele andere Gruende, so z.B. kann sein, dass der Vortragende selbst den Stoff nur von Folien kennt (oder zumindest kriegt man allzuoft diesen Eindruck), kann also nichts dazu beitragen. Oder die Folien sind eine zusammenhangslose Anreihung von Woerter (sehr oft sogar ist diese Variante vorzufinden). Oder
Doch, wo liegt das Problem mit PoPo und die bunten Folien auf die Wand?
Zunaechst ist es positiv, dass der Vortragende (oder eine andere Person) eine huebsche Vorbereitung durchgefuehrt hat. Das spart doch Zeit. Man moechte annehmen, dass die Effektivitaet steigen duerfte.
Warum habe ich zumindest immer den Eindruck, nach so einem Kampf gegen das Einschlafen, dass so gut wie nichts haengengeblieben ist?
Hier einige Gedanken dazu:
1. Ich halte es fuer falsch, zu versuchen Wissen in vorgefertigten vordefinierten "Templates" zu bringen. Entweder ist man ein Genie und man kriegt es irgendwie doch fertig, trotz bunte Formgestaltung, Begriffssalat und Uebersichtslosigkeit, Wissen zu vermitteln, oder man ist hoffnungslos verwirrt in aufgezwungenen Schablonen. Der Sinn eines Vortrages ist Wissen zu vermitteln, dieser Ziel verfehlt man, wenn man PoPo benutzt.
2. Bedingt duch die vorgegebene Formatierung, so meine Einschaetzung, ist es schwierig einen "roten Faden" zu (be)folgen. Zumindest fuer den Zuhoerer, ist es nicht einfach aufgrund der Reihe an Begriffen, den Zusammenhanng und damit den "roten Faden" zu folgen. Da ist der Vortragende gefragt, diese fehlende Verbindung deutlich zu machen. Hier brauchen wir wieder den "Genie", der sich dies bewusst ist und nicht einfach den Inhalt der Folien mit anderen Woertern (so weit durchfuehrbar) wiedergibt.
3. Und es gibt noch einen Punkt, der zwar nicht immer auftreten soll, den ich jedoch auch noch ausfuehren will, weil... der kommt schon mehr als oft genug vor: Manglende Uebersicht bzw Eingliederung. Ist das nicht einleuchtend? Klar, ich werde etwas ausfuehrlicher erklaeren, was ich meine. Wenn man mitten im Vortrag eine Folie mit mehr oder minder viele Begriffe darauf hat und der Vortragende sich Muehe gibt zu erklaeren, was diese bedeuten und ggf. wie sie zusammenhaengen (bei den Besseren...) ist fuer der Zuhoerer oft gar nicht klar, zu welcher Ueberschrift diese Folien gehoeren. M.a.W. wo sie sich eingliedern.

Fazit: Sicher sind PoPo Folien ein Fortschritt und eine grosse Hilfe bei vielen Vortraegen, vor allem wenn man bunte Bilder hat und vor dem Auftraggeber den erfolgreichen Abschluss von Projektteilen naeher beibringen will. Ich halte jedoch die Benutzung von PoPo Folien zur Wissensvermittlung fuer schlichtweg falsch. Je komplexer das Wissen, desto ungeeigneter sind PoPo Folien.

Samstag, 13. Oktober 2012

Das war 2011 (verspaetet)

In nachhinein betrachtet; es war kein gutes Jahr.
Aber, ganz kurz das Jahr ueberblickt:
Ich bin die 200, die 300 und die 400 Km Brevets in Oslo gefahren.
Bei der 600 Km war ich erkaeltet, bin also nicht gefahren. Um PBP (Paris-Brest-Paris) zu fahren muss man alle 4 Brevets beendet haben, als Qualifizierung.
Ich haette noch die Chance gehabt in Schweden die 600 zu fahren. Auch von der Osloer Abteilung wurde einen Nachbrevet organisiert, um zu qualifizieren. Ich aber beschloss mich nicht unter Zwang zu stellen und bin nicht gefahren. Mein Hintergedanken war doch, dass, wenn ich es nicht unter "normalen" Zustaende es schaffe, dann ist es "Schicksal", Zwang wuerde nur kontraproduktiv sein, am Ende wuerde etwas brechen. Als habe ich PBP fuer dieses Jahr abgeschrieben.
Nun aber lag Trondheim-Oslo (T-O) noch vor der Tuer. Mein lieber Freund AB hatte abgesagt, nachdem ihm die Frau die Ohren heiss gesprochen hatte, T-O nicht zu fahren. Also ich alleine. Und ich hatte geplant, am Freitag nachts zu starten und ueber Nacht zu fahren, 2 Stunden zu schlafen und das ganze in etwa 24 Stunden zu schaffen. Nun war das mit dem Schlafen im ABs Auto geplant, vorausgesetzt natuerlich die Frau faehrt es. Das ging also nicht mehr... Ich halte aber an dem originalen Plan fest. Auch ans Ankommen am Samstag gegen Mitternacht.
Nach einigen Zwischen-Hindernisse (AF hatte vergessen, mich/uns anzumelden,also starte ich unter "falschen" Namen nach Telefonat mit dem Kollege,der nicht zu fahren beabsichtigte). Zeitaenderung, da ich angebe innerhalb 24 Stunden ankommen zu wollen, starte ich also gegen 23 Uhr. Ich kann leider tagsueber nicht schlafen, wie ich geplant (erhofft?) hatte. Also muede starte ich: Kalt ueber Nacht, ich schlafe etwas bei dem 2. Stopp -ein Krog nach etwa 80 Km, genauer weiss ich es nicht, es sind die Raststaette fuer die "Nachtfahrer"-. Weiter geht es. Ich bin aber nicht motiviert, werde in der Ebene auch etwas langsam und merke, dass es schwierig wird, gegen Mitternacht anzukommen wie ich es geplant hatte. Beschliesse aufzugeben, in Lillehammer werde ich im Auto einsteigen. Das tue ich auch. Nur sind wir mit dem Auto erst gegen 1 oder 2 Uhr morgens in Oslo angekommen. Da haette ich doch auch mit dem Rad die Strecke gefahren und sogar frueher da gewesen. Na gut. Einmal sollte man auch T-O aufgegeben haben.
Das war also nicht gut: Fuer PBP nicht qualifiziert und T-O aufgegeben.
Und mein Auto wurde geklaut. In Oktober. Geklaut und versaut; die Armleuchte, die das Auto geklaut hat, hat den Feuerloescher im Auto entleert. Damit ist die Kiste kaum noch etwas Wert, Teil der Elektrik ausgefallen, und ich habe kein Vertrauen mehr in das Auto.
Doch es gab noch mehr, was im Jahr 2011 schief lief. Meine Liebste sollte Grossvater in Kanada besuchen um Enkelkind vorzufuehren. Flugtickets gekauft. Visum nicht bekommen. Nicht nur nicht bekommen, die kanadische Botschaft hat es verschlampt, mir das (von mir faelschlich) bezahlte Geld zurueckzubezahlen. Die kanadische Botschaft in Deutschland funktioniert nicht: Geld nicht zurueckbezahlt, ueber Email nicht erreichbar, keine Antwort auf meine Emails. Nichts. Ich mag die Sachen beim Namen zu nennen; die kanadische Botschaft ist ein Saftladen. Und was noch schlimmer ist, ist das ich das Gefuehl bekommen habe, dass die Botschaft es auf das Geld abgesehen hat. Schwer zu glauben, aber vom Benehmen her, ist das Veruntreuung von Gelder.
Ueberhaupt waren sie interessiert, dass man Geld bezahlt, und Trotz Einladung vom Bruder (kanadischer Staatsbuerger), dass die eine eingetragene Firma besitzt, dass sie ein geregeltes Einkommen und Familie und Rente hier hat, wollte man ihr das Visum nicht erteilen. Leider muss ich das Land Kanada nach seiner Behoerde im Ausland beurteilen. Diebe. Bis heute, etwa 12 Monate nach dem Vorfall, ... Schweigen in den Stuben...
Doch das war leider nur Geldverlust, dadurch gelernt, dass Kanada als eine Bande Betrueger zu betrachten ist.
Aber das Schlimmste kommt am Ende des Jahres. Ich plane, im naechsten Jahr (2012) die Marathon in Berlin zu laufen und beginne dafuer mit einem strikten Training, werde ziemlich fit und bin sehr motiviert (nicht mehr Rad zu fahren) zu laufen. Doch Anfang November habe ich einen Unfall mit dem Fahrrad, der 2. Tag nach der Zeitumstellung, von der Arbeit zurueck nach Hause, wache ich im Krankenhaus nach ca. 4 Stunden Bewusstlosigkeit. Angeblich habe ich einen "Fussgaenger" ueberfahren. Oslo ist bergisch und es war auf eine Bergab-Strecke, mit 1 Meter Radstreifen rechts von der Strasse, breit und gut sichtbar, ich schaetze ich hatte sicher mehr als 40km/h. Irgendein Idiot ist quer ueber die Strasse gelaufen (keine Zebrastreifen oder Ampel), wie die Leute es hier zu tun pflegen. Wahrscheinlich hat der Schwachsinniger sogar geguckt, aber kein Auto gesehen (Rad uebersehen, es war leider 2 Tage nach Zeitumstellung und damit ploetzlich fuer die "Tageszeit" dunkel).
Als die Polizei die "Ermittlungen" abgeschlossen hatte, ist, wie immer, nichts passiert. Beim Auto haben sie gesagt, sie haetten nicht genug Leute, um die Arbeit zu erledigen. Beim Unfall, dass, wenn ich es wuensche, kann ich mir die Akten angucken, bevor sie archiviert wird. Es ist mir schon klar, dass egal was passiert, es wird nichts passieren.
In mir, nach 4,5 Jahre Leben in Norwegen, gedeiht der Gedanke, Norwegen den Norwegen zu belassen. Ich bin und bleibe, nicht nur ein Auslaender, sondern vielmehr ein Fremder, da ich mich an dieser Schlamperei nicht anpassen moechte.
Was der Arbeit angeht, so ist das ein anderer Kapitel.

Donnerstag, 31. Dezember 2009

Das war 2009

Im letzten Winter lag es viel Schnee in Oslo. In den letzten 2 Jahren hatte ich nich so viel Schnee gesehen und war etwas ueberrascht das es so viel Schnee fiel. Gefragt habe ich auch an einer eher alten Person, die meinte aber, frueher lag viel mehr Schnee in Oslo. Und in diesem Winter bis jetzt fiel auch viel Schnee, die ganzen Weihnachtage hat es geschneit und seit dieser Woche scheint die Sonne, es ist kalt, so um die -13 bis -19 Grad aber es ist schoen.
In Januar hatten wir genug zu tun auf der Arbeit aber wurde gesagt, dass keine Folgeauftraege kamen, die Krise rammte auch meinen Arbeitgeber. Ab Februar sind wir dann 4 Mitarbeiter in "Permisjon" gegangen, das ist eine Art Arbeitslosigkeit wo der Staat 70% des Lohns bezahlt (und das ist alles) aber die Firma ist gezwungen den Mitarbeiter wieder zu beschaeftigen wenn wieder Arbeit da ist.
Ich habe also begonnen wieder ernst Arbeit zu suchen, hatte sogar einen Vorstellungstermin in Bronnoysund (ca 4500 Einwohner, etwa 10% arbeitet bei den "Registern" wo ich vorstellig wurde) und in Stord bei einer jungen dynamischen Firma, die haetten mich genommen aber ich wolle nicht wirklich, die Arbeit war aus meiner Sicht eine Einbahnstrasse mit M$ Produke, aber sonst war die Arbeitssuche ziemlich muehsam, ich bekam nur Absagen, was ziemlich frustrierend war, so dass ich sogar angefangen hatte, mich in der Schweiz zu bewerben.
In dieser Zeit habe ich auch 3 Buecher geschrieben (1. Die Bewerbungsunterlagen, 2. Das Vorstellungsgespraech Teil 1 und 3. Das Vorstellungsgespraech Teil 2: Zu finden sind diese Buecher unter www.ruynk.de). Darueber hinaus hatte ich mein "Toshiko" Programm (ein Dokument Management System mit Workflow-Funktionalitaet -DMS mit WMS-) fast zu Ende, und auch die automatisierten Tests sind schon fast zu ende geschrieben worden... Toshiko (bedeutet achtsames, aufmerksames Kind) ist aber schon einsatzbereit. Zu finden unter www.tsubame.de (Tsubame ist dann die Dachorganisation fuer die Programme). Zurzeit bin ich damit beschaeftigt ein KM Programm zu schreiben (KM steht fuer Knowledge Management), mit Name Chikako (bedeutet Kind des Wissens). Chikako ist eigentlich nicht so unfangreich wie Toshiko, geplat hatte ich eigentlich andere Programme zu schreiben (ein PLM -Product Lifecycle Management- und ein CRM -Customer Relationship Management-), doch zum Schluss beschloss ich Chikako zu schreiben, weil es sich eher auf die Schiene der "Dokumentation" befindet... PMS und CRM werde ich dann aber auf jeden Fall spaeter fertig machen. Versprochen an alle meinen jetzigen und zukuenftigen Kunden!
In diesen freien Monaten der "Permisjon" bin ich dann ab und an schon beim Joggen und mit dem Rad frueh schon auf die Strasse gewesen, das Wetter nach dem Winter voller Schnee war schon akzeptabel gut. 2 Wochen bin ich auch in Deutschland gewesen (Maerz); in MLN Baeume fallen lassen und in Brandenburg ein bisschen Rad gefahren (sehr viel Gegenwind!). Nach dieser nicht guten und auch nicht gruendlichen Vorbereitung, aber mit viel Freizeit, und da das Wetter dieses Jahr relativ gut war, plante ich alle 4 Brevets zu fahren. Gefahren bin ich dann nur die 200, die 300 und die 400 Km. Bei 30 und 40 mil (wie man hier sagt: 1 Mil sind 10 Km) waren wir nur zu dritt unterwegs: Die Berichte sind unter www.ruynk.de auch zu lesen, erspare mir an dieser Stelle die Details.
Als ich die 600 haette fahren sollen, hatte ich eine Besprechung in meiner Firma und sollte ausgerechnet dann die Woche darauf wieder mit der Arbeit anfangen. Da ich auch nicht mental richtig in Form war, habe an die 600-er nicht Teil genommen. Statdessen habe ich den Platz von GH bei der Styrkeproeven eingenommen und die 540 Km gefahren; ein Bericht hierzu ist auch bei www.ruynk.de zu lesen.
Zurueck zur Arbeit, war aber immer noch nicht richtig genug Arbeit zu tun; dermassen, dass ich mindestens eine Woche damit beschaeftigt wurde, Raeumlichkeiten in der Firma zu bemalen. Nun hatte ich schon aber Vorstellungsgespraeche bei einer Firma laufen. Mittlerweile nahm ich die Vorstellungen gar nicht mehr so richtig ernst. Eine Zeit meinte ich: "Ich gehe halt Kaffee trinken hin". Nun steht in meinen Buechern (tja, theoretisch bin ich immer auf die richtige Hoehe), man soll bei den Vorstellungen keinen Kaffee trinken. Also auch nicht bei dieser Firma. Ich weiss, dass ich nach dem, was ich selber geschrieben, vieles auch falsch gemacht habe. Ich nahm das Ganze auch nicht mehr so schrecklich ernst. Trotzdem habe ich einen Jobangebot von der Firma bekommen, habe den Vertrag unterschrieben und bei der alten Firma gekundigt. Fuer die alte Firma also ein schlechtes Geschaeft; die haben mich zurueckgeholt und etwa 2 Monate spaeter war ich wieder weg.
Frei, Urlaub von der alten Firma: Lade vom Netz viele Buecher runter und lese, lese Tag und die halbe Nacht, dusche jede 2 Tage, gehe Einkaufen auch nur 2 oder 3 Mal in der Woche. Lese und lese und lese; ueber 20 Buecher habe ich in dieser Zeit durch (einige davon sind nur wenige Seite lang, andere ueberfliege ich weil das Meiste mir schon bekannt ist). Dann fange ich in der neue Firma an. Der Arbeitsweg ist 15 Km eine Richtung, zu lange um mit dem Fahrrad zu fahren, wie ich es frueher bei ca 8,5 Km gemacht habe: Zur alten Firma ging es auch regelmaessig bergab hin, so dass ich nicht allzu verschwitzt ankam, hier haette ich mehrere Strecken mit Steigung -wir sind nun mal in Oslo- also fahre ich mit dem Auto. Im November einige Woche mit dem Bus, plane aber jetzt in Januar wieder Bus zu fahren: Die Fahrzeit ist nur ca 10 Minuten laenger, ich muss aber kein Eis kratzen, laufe nicht die Gefahr einen Unfall zu haben bei glatter Strasse und vom Preis ist es ungefaehr das Gleiche. Nachteil mit dem Bus ist aber, dass er viele Kurven faehrt und mir wird manchmal uebel wenn ich auf einem Buch z.B. gucke.
Der Vollstaendigkeit halber muss ich noch erwaehnen, dass ich eine Zahnwurzelinfektion hatte; Penizillin bekam, Ende September operiert wurde. In der letzten Haelfte des Jahes (nach der Styrkeproeven und die Zahninfektion) kaum Sport gemacht. Kein Unfall, keine nennenswerte Verletzung, kaum neue Kunden weil nicht beworben, da ich mich auf Tsubame konzentrieren wollte. 2 Notebooks gekauft um vom Internet Daten runterzuladen (mehrere GB habe ich auf diese Weise mit wertvollen Daten aus DACH gewonnen). Gefastet habe ich auch, aber mit einer unglaublichen Geschwindigkeit wieder auf das alte Gewicht zurueck gegangen; schneller als runter bin ich wieder auf das Ursprungsgewicht angekommen. Und eine neue Geschaeftsidee: Tsubame Seminar og Trening (Computer Seminare; so neu ist das gar nicht, das ist was ich zuletzt auch in Deutschland zum Weiterkommen ausgedacht hatte, ist aber nicht zum tragen gekommen weil andere Prioritaeten, und die Arbeit stand auch noch dazwischen). Auch die Idee fuer noch einige Buecher steht in meinem Kopf.. nur die Zeit ist nicht da... und es ist fraglich ob es sich lohnt Buecher zu schreiben, da die Einnahmen sind weniger als nur bescheiden. Leider ist es ein schoenes Gefuehl ein Buch zu Ende zu schreiben und dass es Menschen gibt, die es lesen und davon einen Nutzden haben... Daer denke ich, irgendwann doch mir die Zeit frei nehmen und die Buecher zu schreiben.
Tja, das war 2009. Wird 2010 auch so bewegt? Wir werden sehen. "Vi får se", auf norwegisch.

Meine Besten Wuensche an alle Leser fuer 2010 !!! :-)

Mittwoch, 8. April 2009

Opportunity

Because the word problem has been banned in business-speak, all problems have become opportunities. This means many opportunities are problems. There is a limit to how many opportunities I can solve. Interesting and strategic opportunities really scare me.

Sonntag, 5. April 2009

Soziale Netzwerke - Pendeln zwischen Banalitaet und Exhibitionismus

Was bewegt Menschen eigentlich dazu, sich in einem sogenannten Soziale Netzwerke zu praesentieren?

Freunde? Wenn ich meine Freunde nur ueber diese Netze treffen wuerde, wuerde ich mich fuer ziemlich... ja, 'sozial abgeschottet' betrachten.
Soll eine Kommunikation zwischen -echten- Freunden die Ausnahme sein? Dann ist aber eine liebe, persoenliche Email viel mehr Wert als diese kurze Meldungen. Wollen die sozialen Netwerkern angeben, dass sie so wenig Zeit haben, dass sie nicht einmal dazu kommen eine Email zu schreiben? Sehr schlechte Freunde dann, wenn sie keine Zeit fuer die echte Freunde haben.

Mich zu praesentieren? Fuer wem? Wofuer? Interessant waere es, wenn ich da geschaeftliche Kontakte erhalten(/knuepfen wuerde. Meine Erfahrung nach ist das eher eine (GROSSE) Ausnahme...

Es gibt Leute, die das fuer Exhibitionismus halten.

http://www.bwlzweinull.de/index.php/2009/02/27/twitter-hype/
http://fieser-admin.de/social-networks/soziale-netzwerke-teil-1-definition/

Ich glaube nicht mal, dass das Exhibitionismus ist... fuer mich ist das einfach eine traurige Banalitaet, von Menschen, die ihre Zeit so wenig Wert ist, dass sie diese bei so etwas Ueberfluessiges verplempen...