.
Historie – was bleibt nennt sich Erfahrung
Wie am Blog vermutlich schon zu erkennen, bin ich Softwareentwickler 🙂 1999 schloss ich mein Studium in Richtung Informatik ab und stieg in die Entwicklung von Client-Server Anwendungen ein. Eingesetzte Technologien waren Oracle, Powerbuilder und Java. Der Softwareentwicklungsprozess in den Firmen orientierte stets am V-Modell. Dieses war in der Praxis deutlich umfangreicher als die wenigen Aspekte die wir im Studium betrachtet hatten.
In den Jahren nach 2000 waren dann Audits total angesagt. Jede Firma wollte ihre Zertifizierung nach ISO-9001. Die Firma brauchte plötzlich Geschäftsziele und jeder Mitarbeiter musste diese kennen. Hinzu kam eine nach bestimmten Kriterien angelegte Dokumentation und die Verwaltung von Quellkode in Versionskontrollsystemen. Letzteres war für mich nie ein Thema, da es im Open Source Bereich eine bewährte Praxis darstellt. Die normale Projektdokumentation die so anfiel empfand ich ebenfalls als sehr nützlich. Ich legte mir stets zu jedem Projekt eine Klemmmappe an. Da ich häufig auch zeitgleich an mehreren Projekten arbeitete, benötigte ich noch einen Plasteordner mit Register. Dieser enhielt stets die aktuellen Dokumente (in Arbeit befindlichen) je Projekt.
Gegen 2004 hatten es dann endlich die Beraterfirmen geschafft die kleinen und mittleren Unternehmen vollständig in Beschlag zu nehmen. Jede der mittelständischen Firmen die ich kannte, began damals mit Dingen wie den Folgenden.
Direktversicherungen – Die Firma schloss plötzlich Direktversicherungsverträge ab und machte diese Ihren Mitarbeitern schmackhaft. Die Nachteile waren klar: 5 Jahre Arbeitgeberbindung, da sonst die erworbenen Anrechte verloren gingen. Außerdem im Falle der Insolvenz gehört die Versicherung der Firma und geht in die Konkursmasse ein (jedenfalls im gesetzlichen Normalfall ohne abweichende Regelungen). Beim Arbeitgeberwechsel wird es schwierig, da der nächste Arbeitgeber vermutlich eine andere Direktversicherung besitzt und die des Arbeitnehmers nicht übernimmt. Ergo bis zur Rente zig verschiedene Versicherungen und in keiner lange genug eingezahlt um genügend heraus zu bekommen.
Risikomanagement – Als es in der Branche kränkelte und alle Firmen merkten, dass es kaum noch Geld für neue Projekte gab wurde Risikomanagement interessant. Wieder kamen Berater und wieder gab es Schulungen. In diesen wurden dann für teures Geld Binsenweisheiten vermittelt wie: „Der Vorstand darf nicht zusammen in den Urlaub fahren und wenn dann nicht mit dem gleichen Flug“, „Jedes Risiko ist auch immer eine Chance“, … Das ganze war gut ausgearbeitet, auf viele Module verteilt, ein schöne Geldmaschine für die Beraterfirmen. Welches Management achtet jetzt noch auf all diese dort gelernten Weisheiten?
Festpreisprojekte – Weil es kaum noch Geld gab aber die Unternehmen weiter Aufträge brauchten wurden nur noch Festpreisprojekte abgeschlossen. Gut für die Kunden – schlecht für die IT-Firmen? Nein, auch schlecht für den Kunden! Denn wie lief so ein Festpreisprojekt ab? Der Chef kam vom Kunden, im Gepäck viele lose Vorstellungen von dem was er dem Kunden demnächst gern anbieten möchte und mit einer Priorisierung wie es der Kunde gern hätte. Jetzt brauchte er noch ein bis zwei Tage um seine eigenen Prioritäten zu vergeben (Man hätte von einem priorisierten Backlog reden können – wenn das damals INN gewesen wäre). Im wöchentlichen Meeting wurde dann das Gesamtpaket den Entwicklern erklärt. Was will der Kunde haben, was braucht er dringend und wie können wir das leisten. In den Tagen danach wurden die einzelnen Projekte (aus dem Backlog) den jeweiligen Entwickler näher gebracht. Hierbei wurde der Leistungsumfang, die Zeitschiene und die grobe technologische Umsetzung besprochen. Kurz vor Beginn des Projektes vereinbarte der Entwickler einen Termin beim Kunden, sprach die Anforderungen durch, gab keine Zusicherung die der Chef nicht wollte und achtete auf die Umsetzbarkeit sowie auf den vom Chef abgesteckten Rahmen. Dann ging es zurück an den Schreibtisch und ans grobe Design. Wieviel Fenster werde ich brauchen? Wieviele DB Schemata sind betroffen? Arbeite ich auf Tabellen oder auf Views. Wie sollen die Masken im groben aussehen? Wie läuft das Deployment ab? Wo kann ich entwickeln – in der eigenen Firma oder beim Kunden? Wieviel Zeit werde ich brauchen? Wie stehen die anderen Projekte aktuell – gibt es Verzögerungen die ich noch ausgleichen muss? Das ganze dem Chef kurz vorgestellt, der Knackpunkt war immer der Zeitplan – hier war stets das Scotty-Prinzip gefragt. Chef ich kann das in 2 Monaten abliefern, vom Zeitplan her ist das für den Kunden auch ok. In den 2 Monaten kosten sie mir Gehaltsmäßig mehr als der Kunde für das Projekt ingesamt bezahlt. Ok, Chef ich versuch es in einem Monat zu schaffen.
Die Projekte wurden dann zum Termin (einen Monat) fertig oder umschreiben wir es lieber wie folgt. Es wurde so programmiert, dass man sich bei der Abnahme darauf zurückziehen konnte, dass alle geforderten Anforderungen soweit erfüllt sind. Hier und da sind halt noch ein paar Nacharbeiten zu tun. Diese Nacharbeiten und die unfertigen Teile welche erst bei tieferen Tests auffallen wurden dann noch in einem 2. Monat nachgearbeitet. Die Stimmung des Chefs war dann immer davon abhängig ob es bezahlte Nacharbeiten waren und falls nicht ob wenigstens ein Folgeprojekt dabei herausgesprungen ist. Die Krönung wäre ein echtes Projekt gewesen aber zu der Zeit gab es alles nur zum Festpreis 😉
Gegen 2006 war auch die Krise in der Branche langsam wieder überwunden und schon lag der Fokus auf ganz anderen Punkten. Viele Berater erkannten ihre Chance und gingen mal richtig ins Gericht mit den vergangenen Jahren. Was dabei herauskam nannte sich Kundenorientierung.
Kundenorientierung – Ja man redete uns ein, die Entwickler wären nicht Kundenorientiert genug und das müsse sich jetzt ändern. Dann kamen viele Schulungen mit vielen Powerpoints und schicken Bulletpoints. Bei den Entwicklern wurden zwar offene Türen eingerannt, denn sie wollten schon immer möglichst alles so umsetzen wie es der Kunde wollte. Leider gab es dabei einige Hemmnisse wie Zeit, Budget und Chefs die diese Spielereien jetzt gar nicht für sinnvoll hielten oder der Meinung waren, dass man dem Kunden nicht alles liefern darf sondern auch beratend/erzieherisch als Entwickler tätig sein muss. Letzterem stimme ich sogar zu, unter der Prämisse, dass die Benutzbarkeit der Anwendung nicht darunter leidet. Doch diese Hemmnisse erschienen nicht in den gelobten Powerpoints. Hier waren es immer die Entwickler die in an den Haaren herbeigezogenen Beispielen gegen die Kundenorientierung arbeiteten. Das ging eine Weile so – dann war wieder Ruhe. Kein Wort mehr von Kundenorientierung. Ja, genau! Es gab etwas Neues 🙂
Serviceorientierung – Jetzt war es endlich soweit. Das Management zog die Schlussfolgerung, dass die Bedürfnisse des Kunden wohl am besten durch einen besseren Service zu erfüllen seien. Nun wurde es unfreiwillig komisch. Offensichtlich war es das erste Mal passiert, dass die Beraterfirmen zugleich auf verschiedene Strategien gesetzt hatten (Sonst schienen sich die Berater weltweit immer einig gewesen zu sein :-). Serviceorientierung wurde einerseits hinsichtlich der Kundenorientierung gesehen und ging in Richtung Einführung von ITIL oder CMMI. Andererseits ging es um die Umgestaltung der Unternehmen hinsichtlich der angebotenen Services und deren Schnitt, also Richtung SOA. Das Thema war also kurze Zeit brandaktuell. Es gab richtig gute Schulungen dazu. Darin gab es richtig interessante Aussagen (aus dem Gedächnis rekonstruiert): „Ein ESB ist nebensächlich, Tools überhaupt sind nachrangig zu werten, SOA lässt sich auch ohne Tools durchführen“, „SOA ist nicht nur eine Technologie, SOA ist vielmehr eine Art und Weise ein Unternehmen zu organisieren“, „Wir wollen unsere Prozesse standardisieren um uns mit Konkurrenten vergleichen zu können“. Das Thema stand nur kurze Zeit im Fokus, verblieb aber im Hintergrund ehe es später als SOA wieder auftauchte.
Prozessorientierung – Endlich war dem Management klar, was diese Softwareentwicklung so teuer machte. Da war Kollege A mit seinem fachlichen und technischen Wissen sowie seiner spezifischen Erfahrung, welche er durch seinen spezifischen Lebensweg erworben hatte. Und da war Kollege B mit einem anderen fachlichen und technischen Wissen und einer anderen spezifischen Erfahrung. B war Vertretung von A und wenn A fehlte blieben dennoch Dinge unbearbeitet und wenn B fehlte war es genauso mit A. Woran lag das? Natürlich das Unternehmen brauchte Prozesse – Arbeitsprozesse! Was heisst die haben wir und die laufen auch, das kann ja gar nicht sein. Wo ist der Single Point of Service? Wo sind die allseits beliebten Workflow-Engines? Was heißt die gibt es nicht? Wieso haben wir eigentlich noch nicht auf ITIL oder CMMI umgestellt und unsere Prozesse standardisiert? Dann wären die Entwickler austauschbar und ein Kunde könnte von jedem zur vollsten Zufriedenheit bedient werden. Außerdem erfordern standardisierte Prozesse auch nicht den Einsatz hochqualifizierter Fachkräfte – zumindest nicht an jeder Stelle.
Das Ergebnis waren standardisierte Prozesse und die Aussage: „ITIL hat nicht versprochen die Prozesse zu beschleunigen sondern sie zu standardisieren. Das kann in speziellen Fällen auch bedeuten, dass es auch mal langsamer werden kann“. Nur gut, das dieses Vorgehen nicht mehr unter dem Begriff Kundenorientierung läuft. Aber gut, es waren ja ohnehin die Entwickler welche die Kundenorientierung nicht verstanden haben. Wenn ich als Entwickler früher einen Fehler gemeldet bekam, habe ich mich gleich daran gesetzt ihn zu analysieren um eine Aussage zu treffen woran es liegt, wie ein Workaround dazu aussieht und bis wann ich es beheben kann. Nach der ITIL Einführung schaue ich mir den Incident an, identifiziere die fehlenden Informationen, fordere diese durch Rückgabe des Tickets vom Ersteller ein und wende mich ohne schlechtes Gewissen der Bearbeitung des nächsten Tickets zu. Früher hätte sich mir dabei der Magen umgedreht. Doch wie heisst es so schön „Der Mensch ist ein Gewohnheitstier“ und „Der Mensch wird geprägt durch seine Umgebung“. Insofern ist ITIL schon etwas prägend. By the way – ITIL ist für den Betrieb erfunden wurden liebes Management – naja egal.
SOA – Endlich mal was für Entwickler. Die wollen doch ohnehin immer diese Spielereien, jetzt können sie mal Webservices bauen, das wird sie motivieren. Nachdem das Thema lange in den Hintergrund getreten war taucht es nun wieder auf. Jetzt werden die Services implementiert. Wie kam es dazu? Na zunächst sind offensichtlich umfangreiche Analysen gelaufen welchen ESB von welchem Anbieter man nehmen könne. Brauchen wir den? Wenn wir die Prozesse nach Belieben verschalten wollen ja. Wollen wir das? Nein! Achso.
Also SOA ist schon notwendig, auch aus meiner Sicht. Mit ihr bekommen wir die Chance festzulegen welche Kollegen/Abteilung/Projekte/Verfahren als Master für welche Daten fungieren. Dann ist endlich auch klar wer nur liest und wer nur schreibt genauso wie wer welche Daten zu halten hat und wer welche Daten weiter zu leiten hat. Doch die ersten Dinge haben wir uns schon verbaut. Wir haben uns auf den ESB Hersteller festgelegt und wir sprechen nur noch von Webservices obgleich eine SOA auch RMI als Service sieht. So gibt es bei den ersten Planungen Probleme mit der Performance (schon auf dem Papier). Um diese zu lösen schicken Imperator-Entscheidungen dann Workarounds ins Rennen auf die wir langfristig lieber verzichtet hätten.
Scrum – Dieser Punkt war die eigentliche Motivation für den vorliegenden Artikel und er wird jetzt nur noch kurz angerissen. Aber gut ich kann ja noch ein paar Artikel dazu schreiben 😉
Ja seit kurzem bin ich in einer Firma in der agile Arbeitsweisen vom Management eingeführt wurden. Die Entwickler sollen Spass bei der Arbeit haben, man wolle die Motivation steigern und man will effektiver und effizienter werden. In meinen Worten: Man möchte, dass sich die Entwickler mit den Arbeiten befassen die für die Erfüllung der Kundenwünsche notwendig sind und mit keinen anderen Dingen. Weiterhin will man, dass sie diese Arbeiten mit möglichst geringen Aufwänden und in hoher Qualität durchführen. Nachdem die agilen Arbeitsweisen bereits seit 10 Jahren ein Schattendasein fristeten und der Hype in Deutschland nun auch groß genug war, hat er also auch meinen Arbeitgeber erreicht. Nein ich stehe dem Ganzen nicht ablehnend gegenüber – im Gegenteil. Ich war und bin stets offen für neue Ideen. Allerdings übe ich mich anfangs immer in Zurückhaltung von Euphorie, da ich schon zu viele Allheilmittel nach einer Weile verpuffen sehen habe. Was für mich dabei besonders unbefriedigend ist, meist hinterlässt die Nachbetrachtung eines Beraters über ein am Boden liegendes Allheilmittel den Nachgeschmack – der Entwickler war Schuld, er hat’s versaut. Immer so auf der Art: „Das hätte super geklappt, wenn da nicht die Menschen wären …“. Zudem wie wir Scrum leben, welche Probleme und Nichtprobleme wir damit haben, will ich heute nichts sagen. In späteren Artikeln werde ich mich dazu gewiss äußern. Nur soviel: Ich bin dabei, ich bin am lernen und ja auch für mich gestaltet sich der Einstieg nicht einfach. Ähnliche Eindrücke scheinen andere Entwickler auch gemacht zu haben. Ich bin gespannt wohin mich die Reise führt.
Die Lehren, die ich zog
Nachdem ich nun im super Kurzdurchlauf meine berufliche Laufbahn auf die durchlebten Höhepunkte der Arbeitsmethoden oder Managementstrategien reduziert habe, möchte ich zusammenfassend sagen was ich daraus gelernt habe.
Persönliche Arbeitsweise – Diese vielen verschiedenen Kursänderungen im Management haben zu vielen Weiterbildungen teils in Form von Schulungen, teils in Form von Mitarbeitergesprächen geführt. Mit jedem Kurswechsel musste ich mich beschäftigen ob ich wollte oder nicht. Aus jeder gerade aktuellen Strategie habe ich versucht meine Vorteile zu ziehen. Meist gab es irgendwelche Arbeitsweisen die vorgestellt wurden oder Beispiele zu Arbeitsweisen aus denen man etwas für sich herausziehen konnte. Häufig wurden auch bekannte Arbeitsweisen zum x.ten Mal erläutert. Letzteres ist aber auch nicht schlecht. Schließlich dringt es so schneller ins Langzeitgedächtnis ein und außerdem sieht man, dass die Meinung immer noch aktuell ist – man ist also auf der sicheren Seite wenn man die Arbeitsweise beherzigt. So habe ich letztlich meine persönliche Arbeitsweise stets verbessern können. Zusätzlich zu den betrieblichen Denkansätzen kamen dann noch die Methoden „Simplify your life“ und „Getting things done“ aus denen ich viele Methoden in meine persönliche Arbeitsweise übernehmen konnte. Man muss aber auch sagen, dass erfahrungsgemäß keine Methode vollständig anwendbar ist. Meist mussten Teile weggelassen oder an das bestehende Umfeld angepasst werden. Auch für zukünftige Methoden wäre meine Erwartungshaltung nicht, dass ich diese ohne Tailoring übernehmen kann – das wäre Illusion. Gerade die agilen Methoden bringen eine große Menge an neuen Ansätzen mit. Hier kann ein großer Fundus für das private Leben abgeschöpft werden, egal ob die Projekte zum Schluß laufen oder nicht. Was allen Methoden bislang gemeinsam ist. Das Thema Ablage wird oft als Randthema gestriffen aber nicht wirklich herzhaft erfasst. Ablagesysteme spielen aber bei der Selbstorganisation aus meiner Sicht eine zentrale Rolle. Meist werden vorhandene Krücken aus dem Betrieb genutzt (in der Regel unlogisch gegliederte Dateisysteme mit magischer Berechtigungsverteilung). Das beste Ablagesystem welches ich bislang kennengelernt habe, ist dies aus „Simplify your life“ – eine Karteikartenablage im Rollcontainer. Bislang das praktischte System für mich. Leider ist meine Arbeitsumgebung inzwischen soweit standardisiert, dass auch die Rollcontainer standardisiert sind. Ein Fach mit Karteikarten gehört leider nicht zur Ausstattung und lässt sich auch nicht bestellen. Auch selber kaufen stellt keine Lösung dar, da es damit wieder andere Probleme gibt.
Die Kuh die durchs Dorf getrieben wird – Ja inzwischen bin ich der Meinung, dass Softwareentwicklung teilweise mit Mode vergleichbar ist. Manche Klamotte ist nach 10 Jahren durchaus wieder modern, obgleich dann natürlich unter einem anderen Namen. So ist es auch in der Softwareentwicklung, wobei hier die Periode von 10 auf etwa 1 Jahr zu reduzieren ist. Seit der Softwarekrise sind die grundlegenden Probleme der Softwareentwicklung bekannt (Beweisbarkeit der Terminiertheit und Korrektheit von Programmen sowie die Zusicherung von deterministischem Verhalten). Grundlegende Lösungsansätze sind auch klar. Beweisen lässt sich alles, es ist nur eine Frage des Aufwandes. Wenn ich also zu jeder Zeile Quellkode noch 3 Zeilen logischer Ausdrücke hinzupacke und bestimmte Rahmenbedingungen herstelle würde sich evtl. sogar die Terminiertheit beweisen lassen (Endlosschleife oder dauert es nur länger). Die Kunst besteht also darin bestimmte Effekte mit möglichst geringen Aufwand zu erzielen. Dazu gibt es klassische Methoden. Dann gibt es Varianten dieser klassischen Methoden. Dann gibt es Kombinationen der Vorgenannten. Zu guter Letzt entsteht jedes Jahr eine Neue, mit neuem Namen mit neuen Hoffnungen, mit neuen Versprechungen und am Ende meist mit der gleichen Enttäuschung wie bei der Letzten. Nein das ist keine pessimistische Einstellung sondern ein Naturgesetz. Entweder ich habe komplexe Programme oder ich habe komplexe Spezifikationen oder ich habe beides. Wenn ich die Korrektheit ein komplexes Programmes sicherstellen will, benötige ich komplexe Beschreibungen des Programmverhaltens. Wenn ich die Korrektheit beweisen will würde die Spezifikation der Neuprogrammierung einer Anwendung auf anderem abstrakten Niveau und mit anderen Mitteln gleichkommen. Der Aufwand muss aber der Gleiche sein, da es um das gleiche Verhalten geht. Von daher könnten diversifizierende Testverfahren tatsächlich eine preisgünstigste Methode in der Softwareentwicklung darstellen. Lass einfach 2 agile Teams unabhängig und räumlich getrennt von einander das gleiche Programm bauen und vergleiche die Ausgaben beider Programme. Unterschiedliche Ausgaben deuten auf unklare Anforderungen und fehlerhafte Umsetzung.
Was ich sagen will ist, ich habe mich daran gewöhnt das wir in unserer Branche den neuen Technologien, neuen Produktversionen und neuen Trends nur so nach hecheln. Ich kann damit leben und teilweise damit umgehen. Was ich daran nicht mag ist, dass die Evangelisten der neuen Technologie immer so tun als seien alle Anderen die ewig Gestrigen, die Dummen, die die keine Ahnung haben und sich sperren oder das ganze neue Projekt unterwandern und boykottieren wollen.
Die Erfahrung die ich hieraus gezogen habe ist ganz einfach: Spring auf jedes neue Thema auf wenn man es von Dir erwartet. Knie Dich rein, interessier Dich dafür. Eigne Dir an was sinnvoll ist und über nimm es in Deinen persönlichen Arbeitsstil. Überdenke Deine bisherige Arbeitsweisen kritisch, hinterfrage das Neue Thema kritisch aber stoppe keine Deiner langfristigen Aktivitäten um dem Neuen Thema Priorität einzuräumen.
Gute Arbeit leisten – Auf dem letzten Treffen der Nürnberger Agilisten hat es mich wirklich entsetzt wieviele Menschen der Meinung sind, dass viele Entwickler nur Ihren Job machen wollen, kein Interesse an einer persönlichen Weiterentwicklung haben und Änderungen in der Firma eher unflexibel gegenüber stehen. Vielleicht war das auch die unterbewusste Motivation den Artikel zu schreiben. Jedenfalls bin ich anderer Meinung. Ich glaube das alle Entwickler gute Arbeit leisten wollen. Ich glaube aber auch, dass jeder Mensch andere Fähigkeiten und Bedürfnisse hat und so auch jeder Entwickler. Diese müssen im Arbeitsumfeld Berücksichtigung finden, sonst ist die Zusammenarbeit nicht fruchtbar. Viele Menschen sind sich ihrer Fähigkeiten und Bedürfnisse auch gar nicht sicher. Diese müssen dann zunächst identifiziert werden. Auch die Vorstellungen und Ansichten über Gut und Schlecht sind stark unterschiedlich. Meist hängen sie von der persönlichen Entwicklung, den persönlichen Erfahrungen und dem Umfeld oder anderen Dingen ab.
Beispielsweise die Vorstellung über guten Kode. Was ist guter Kode? Wie sieht ein guter Kommentar aus? Da gibt es Entwickler die 10 Finger blind schreiben können und für die beliebig lange Bezeichner und Texte kein Problem darstellen. Auf der anderen Seite die – ich nenne sie gern C Programmierer – welche alles möglichst auf einen Buchstaben reduzieren. Dann gibt es die Verfechter des Fluent-Interface. Doch was ist nun wirklich guter Kode? Der mit einem super ausführlichen JavaDoc Kommentar, möglichst noch mit HTML Tags um dem Leser gleich die Möglichkeit des Verzweigens zu geben oder der ohne JavaDoc bei dem sich aus der Verkettung der Aufrufe das Verhalten erschließt? Sowie sie hierzu zwei Antworten erhalten sollten sie davon ausgehen, dass auch die Antwort die nicht Ihrer Ansicht entspricht wohl durchaus begründet ist. An dieser Stelle würde ich mir viel mehr Erfahrungsaustausch unter den Entwicklern wünschen. Doch diesem muss vom Arbeitgeber auch Zeitbudget eingeräumt werden. Stammtische oder OpenSpace Veranstaltungen empfinde ich hierbei als äußerst geeignet. Doch wie läuft es in der Praxis? Zur Community of Praxis sprechen vor dem Team immer nur diese selbst ernannten Gurus und stellen sich hin und sagen wie was gemacht werden soll. Die Anderen, denen das Präsentieren nicht so liegt, werden sich hüten hier aktiv zu werden. Warum nicht einfach mal ein Kodestück aus der Versionskontrolle festlegen (z.B. Person.java Zeile 130 – 140 aus r205) und beim nächsten Treffen durchsprechen. Bis dahin kann sich jeder mit dem Kode befassen und Argumente dafür und dagegen sammeln. Das bringt aus meiner Sicht viel mehr als die monotonen Wiederholungen von „Mache dies so und mach das so“. Auch Katas halte ich für einen guten Weg seine Fertigkeiten zu festigen. In der Arbeitswelt aber nicht im Team als Dojo. Da kommt zu viel Konkurrenz ins Spiel. Dojos per Internet sind kein Problem im Gegenteil, diese können auch sehr fruchtbar sein.
Ein ähnliches Thema habe ich bereits in meinem Artikel Industrielle Softwareproduktion behandelt, dieser könnte sie auch interessieren 🙂
Da es vermutlich nicht schwer fällt, meinen aktuellen Arbeitgeber zu ermitteln, möchte ich vorsichtshalber folgendes Statement anbringen:
Die hier im Blog und speziell in diesem Artikel vorgenommenen Behauptungen, Argumentationen, Meinungen und ähnliches sind rein meine persönlichen. Sie sind weder mit meinem Arbeitgeber abgesprochen, noch von ihm bewertet noch stellen sie dessen Meinung, Behauptungen, etc. dar.
FunThomas Blog (de) 