The Change Agent
Wer sich wie ich über die vielen Einträge in der Whitelist von Adblock ärgert (Quelle1, Quelle2) und ständig von Werbung zugemüllt wird, dem sei folgende Lösung ans Herz gelegt:
uBlock, das es für Chrome und Firefox gibt. In den Einstellungen müsst ihr noch diesen Haken setzen
Danach folgt ihr dieser Anleitung, damit ihr nicht von Seiten ausgeschlossen werdet, die uBlock erkennen.
Voila, endlich wieder Werbefrei. Funktioniert auch bei vielen Videos.
Für unsere IT-Consulting Firma (Ausgliederung der IT Abteilung) suchen wir in Karlsruhe oder Durlach nach Büroräumen. Nachfolgend unsere Wunschliste. Wenn jemand jemanden kennt, der jemanden kennt, dann würde ich den auch gerne kennen lernen :). Oder kurz: Für Hinweise wäre ich dankbar.
Dabei spielt es keine Rolle, ob es sich um einen Neubau handelt, bei welchem wir noch mitgestalten können, oder ob es fertig eingerichtet ist und sich nichts mehr ändern lässt. Wir haben nur sehr selten Kundenbesuch und benötigen keinen Empfangsbereich. Schön wäre Trockenbau, sodass wir ggf. die Raumaufteilung anpassen können.
must-haves:
nice-to-have:
Kontakt einfach über einen meiner Kanäle oder unter +497232-3655-555.
Die Grenze zwischen den Rollen im Entwicklungsprozess sind fließend. In meinem vorherigen Beitrag habe ich erläutert, wen ich mit welche Rolle betrauen würde und wie sich dadurch die Produktentwicklung um das 100-fache beschleunigen lässt.
Wer kann sich wie an der Lösung beteiligen?
In diesem Beitrag möchte ich meine Sicht darauf geben, bis zu welcher Stelle der Product Owner gefragt ist und wann die Arbeit des Entwicklers beginnt. Dazu greife ich das Beispiel aus diesem Video auf:
5*3 = 15
Stellen wir uns den Entwickler als Schüler in einer Matheklasse vor, die Multiplizieren lernen sollen. Der Business Analyst (BA) ist dabei der Lehrer, welcher den Schülern erklärt wie die Multiplikation funktioniert. Lediglich das Ergebnis zu nennen kann bei sehr trivialen Prozessen möglich sein. Da die wenigsten Prozesse in Unternehmen trivial sind, gehen wir davon aus, dass wir einer Erklärung bedürfen. Und genau an dieser Stelle scheiden sich häufig die Geister: In welche Tiefe muss der BA in das Problem einstigen und wie weit ins Detail bei dem Lösungsansatz gehen?
Klar ist: Der Lösungsansatz muss vom BA kommen, denn nur er weiß, wie er den Prozess gerne hätte bzw. wie er korrekt ist. Im obigen Beispiel muss der Lehrer den Schülern sagen, dass sich eine Multiplikation in eine Summe umformen lässt. Das kennen die Schüler bereits. Der Lehrer würde ihnen also sagen:
5*3 = 5+5+5 = 15
Leider ist das falsch. Nicht das Ergebnis, aber der Rechenweg.
5*3 = 5+5+5 = 15
Denn der korrekte Rechenweg lautet:
5*3 = 3+3+3+3+3 = 15
Leider reicht es bei Prozessen nur selten, wenn lediglich das Ergebnis korrekt ist, denn die Zwischenergebnisse können auch weiterverwendet werden. Außerdem ist nicht gesagt, dass für alle möglichen Werte das Ergebnis immer stimmt.
Wir waren uns einig, dass der Rechenweg vom BA kommen muss. Macht es dann Sinn, dass der Entwickler diesen validieren und ggf. zig Testrechnungen durchführen muss, um die Richtigkeit zu gewährleisten? Würden das die Schüler der imaginären Schulklasse machen? Können diese überhaupt alle etwaige Abzweigungen/Konstellationen kennen. Was wäre, wenn wir von irrationalen Zahlen sprechen würden? Die sind den Schülern noch gar nicht bekannt. Aber wie sollten sie dann eine Testrechnung mit selbigen machen? Wenn als nächstes auf dem Lehrplan die Division stünde, welche in eine Multiplikation umgeformt werden kann, wären die Schüler dann in der Lage den Rechenweg dahingehend zu validieren, dass er später auch bei Divisionen funktioniert?
Ich bin der Meinung, dass dem nicht so ist und daher der BA sich entsprechend darum kümmern muss. Dagegen spricht ebenfalls, dass es im Sender-Empfänger-Modell immer zu Problemen kommen kann. Wenn ich beim Schach von einem Spielfeld rede, meine ich dann das gesamte Brett oder eines der 64 Felder? Je früher es dabei zu Missverständnissen kommt, desto weiter bewegt man sich von der Lösung weg. Denn wenn der BA nur kontrolliert, ob das Ergebnis 15 ist, dann könnte im Untergrund auch einfach 5+10 gerechnet worden sein.
Selbst kleine Ungenauigkeiten können in der Praxis grobe Probleme machen. Ob ich einen Rabatt entweder auf jede einzelne Position einer Rechnung anwende und dann summiere oder ob ich den Rabatt auf gesamte Rechnung anwende und dann auf die einzelnen Positionen verteile, ist ein großer Unterschied. In bestimmten Fällen können so Rundungsfehler entstehen, die am Schluss das Ergebnis verändern. Wenn ich zuerst 10% abziehe und dann wieder 10% dazu rechne, dann kommt eben nicht der ursprüngliche Betrag heraus.
Mit diesen Details müssen sich aus meiner Sicht die Business Analysten beschäftigen. In technische Lösungen einzusteigen, verlangt niemand. Genauso wenig erwarte ich, dass alles immer zu 100% durchdacht werden kann. Ich schließe auch nicht aus, dass die Entwickler Vorschläge für bessere Lösungen geben. Aber wenn es um die fachliche Problemanalyse und das Entwickeln eines Lösungsansatzes geht, dann ist das die Kernaufgabe der BAs.
Wie seht ihr das? Sind bei euch die Aufgaben klar getrennt? Funktioniert das bei euch? Oder übernehmen bei euch die Entwickler die Rolle Business Analysten?
Vorweg: Die Zahl 100 ist frei erfunden, aber jetzt, wo du schon mal da bist, kannst du trotzdem weiterlesen und am Ende gerne einen Kommentar hinterlassen.
Rollen bei der Softwareentwicklung
Während Konzerne ganze Teams von Business Analysten mit entsprechendem akademischem Background haben, sind kleine und mittelständische Unternehmen (KMUs) weniger breit aufgestellt. Das trifft genauso auf die Größe des Entwicklerteams zu: Dedizierte Software-Architekten und Development Leads gibt es nur selten. Das rechte Bild zeigt einige der Rollen im Entwicklungsprozess von Software (aus diesem hervorragenden Video von Pluralsight entnommen). Deshalb gilt es zu analysieren, wer im Unternehmen welche Kompetenzen besitzt und wo es zu Engpässen kommt. Die Grenzen der Rollenübergänge sind aufgrund der fehlenden dedizierten Rollenbesetzung fließend und werden deshalb häufig von mehreren Personen übernommen.
Das trifft speziell auf die Rolle des Business Analysten zu. Während Wikipedia eine lange Liste von Aufgaben für diesen definiert, will ich meine Sicht – oder besser meine Vision – darlegen, auf welchen Personenkreis die Aufgaben in KMUs aufgeteilt werden müssen. Denn wenn diese Rolle im Unternehmen sinnvoll implementiert wird, ergibt sich ein gewaltiges Optimierungspotential. Generell muss das aber unternehmensspezifisch nach Kompetenzen und Verfügbarkeiten der Mitarbeiter geregelt werden. Diese gilt es kontinuierlich weiterzuentwickeln.
Fachexperten (in der Grafik Subject Matter Expert genannt) sind die eigentlichen Anwender des jeweiligen Geschäftsprozesses. Will man also wissen, wie das Versenden eines Packstückes abläuft und wo es dabei zu Problemen kommt, dann wäre der Lagerist der richtige Ansprechpartner. Deshalb sollte er es auch sein, der den Prozess im Unternehmenswiki festhält. Ein Wiki deshalb, weil es sich einfach nutzen lässt und einige wenige Regeln genügen, um es erfolgreich mit Inhalten zu füllen. Außerdem ist es die Grundlage, um neben dem Prozess Know How weiteres Inselwissen zu erfassen.
Die Koordination, den Überblick über Domänengrenzen hinweg, die Konsolidierung der Informationen und das Überführen von Anwenderwünschen siedle ich beim Produktverantwortlichen (Product Owner bei Scrum) an. Mit steigender Kompetenz und mit steigendem Wissen der Anwender können selbige immer mehr Verantwortung und Aufgaben übernehmen, z.B. das Formulieren der eigenen Wünsche in das Issue Tracking System (Backlog in Scrum). Der Product Owner wird dann stärker zum Koordinator, der das Big Picture und die Vision vorantreibt, der eher in Innovationen statt Evolutionen denkt und der Anforderungen (Achtung: Wunsch != Anforderung) noch besser herausarbeitet. In dem Zuge sind Akzeptanzkriterien zu nennen. Eines könnte lauten:
Wenn eine Rechnung abgeschlossen wird,
Und zu guter Letzt kommen wir noch auf den Entwickler zu sprechen: Je weniger er in die Ausarbeitung von Anforderungen, fachlichen Lösungsansätzen und Modellierungen stecken muss, desto mehr Zeit kann er in gute Softwarearchitektur stecken. Und eine gute Architektur ist der Schlüssel für gute, adaptive und skalierbare Produkte. Die Grenze, wo die Aufgaben des Product Owners aufhören und die des Entwickler anfangen, ziehe ich an der Stelle, wo es einer entsprechenden Ausbildung bedarf – und sei es nur 1. Semester Informatik im Rahmen des BWL-Studiums. Ob der Datentyp Integer werden soll oder ob eine Enum die bessere Wahl für eine Auswahlliste ist, das entscheidet der Entwickler. Bei Fragen nach gültigen Wertebereichen, z.B. ob als Gewicht für einen Artikel 0 Kg zulässig sind, das kann der Produktverantwortliche mit steigender Kompetenz früher oder später gleich mitgeben. Hier bedarf es aber immer der sorgfältigen Prüfung des Entwicklers, dem sich solche Fragen naturgemäß eher erschließen. Hingegen ist der Product Owner immer für das Entwerfen der fachlichen Lösungsansätze verantwortlich, denn nur er hat den Überblick über den Geschäftsprozess und wie dieser mit anderen Prozessen interagiert. Für ein konkretes Beispiel kannst du diesen Beitrag lesen.
Anwender sollte man in den Produktentwicklungsprozess einbinden. Mit steigender Erfahrung können sie mehr Aufgaben übernehmen und helfen, die Entwicklung zu beschleunigen und das Produkt noch besser zu machen. Transparenz, größere Akzeptanz, besseres Verständnis und die Reduzierung von Inselwissen sind nur einige wichtige Nebeneffekte. Ein Feature, sei es noch so gut, welches aufgrund von Ablehnung nicht genutzt wird, ist wertlos. Ein Prozess, egal wie gut durchdacht er ist, um den aber herumgearbeitet wird, produziert mehr Probleme als dass er löst.
Im Gegenzug kann der Produktverantwortliche mehr Zeit in Innovationen und bessere Anforderungen stecken, die zu besserer Softwarearchitektur und niedrigeren Entwicklungskosten führen. Das Ergebnis ist eine schnellere Entwicklung eines passgenaueren Produkts mit weniger Fehlern und höherer Qualität.
Der Entwickler wiederrum kann sich auf eine solide Infrastruktur konzentrieren, die zum Einen schnelle und einfache Anpassungen ermöglicht, zum Anderen entsteht Zeit für das Automatisieren von regelmäßigen Abläufen. Durch automatisierte Tests (durch gute Akzeptanzkriterien) lässt sich das Gros der Arbeit der Tester übernehmen (siehe Rolle in der Grafik oben). Ein Continuous Deployment System macht händisches Deployment überflüssig. Trainings reduzieren sich auf ein Minimum, weil die Fachabteilung von Anfang an in die Prozessumsetzung eingebunden wurde.
Wie haltet ihr das bei euch? Schreibt mir eure Erfahrungen in die Kommentare. Wie weit die Transformation bei heco fortgeschritten ist, erzähle ich in diesem Beitrag (Link folgt noch).
Wir nehmen wie immer gerne Feedback mit. Gregor und Johannes könnt ihr über die in den Show Notes verlinkten Webseiten kontaktieren. Ich bin sicher, dass Input für das Buch gerne aufgenommen und ggf. eingefügt wird.
Aus aktuellem Anlass (Workshop am devspace2015) das Video zu Docker, in welchem Alexander Zeitler uns in einer Live Demo das Ökosystem vorstellt.
Durch Klicken gelangt ihr zum Video.
In meinem Video zu 60 Minuten mit der Pfadfinderregel war ich noch die Lösung zu Castle.Windsor schuldig. In diesem Webcast zeige ich wie die CollectionResolver-Funktionalität genutzt werden kann, um nachträglich hinzugefügte Implementierungen automatisch im Container zu registrieren.
Dadurch kann das OCP vollständig eingehalten werden, da lediglich eine neue Klasse hinzugefügt werden und der restliche Code nicht angefasst werden muss. Den Code habe ich hier zur Verfügung gestellt. Fragen und Feedback einfach in die Kommentare.
| public class Installer : IWindsorInstaller | |
| { | |
| /// <summary> | |
| /// Performs the installation in the <see cref="T:Castle.Windsor.IWindsorContainer" />. | |
| /// </summary> | |
| /// <param name="container">The container.</param> | |
| /// <param name="store">The configuration store.</param> | |
| public void Install(IWindsorContainer container, IConfigurationStore store) | |
| { | |
| container.Kernel.Resolver.AddSubResolver(new Castle.MicroKernel.Resolvers.SpecializedResolvers.CollectionResolver(container.Kernel)); | |
| container.Register(Components().ToArray()); | |
| } | |
| private static IEnumerable<IRegistration> Components() | |
| { | |
| //have a look at https://github.com/castleproject/Windsor/blob/master/docs/registering-components-by-conventions.md | |
| yield return Classes //non abstract classes; you could also use Types.* for more choices | |
| .FromThisAssembly() //should be clear | |
| .IncludeNonPublicTypes() //since my implementations are internal, only the interface is public | |
| .BasedOn<IFoo>() //every class that implements this interface | |
| .WithService.Base() //also possible: .WithServiceFromInterface() | |
| .LifestyleTransient(); | |
| yield return Component | |
| .For<IBar>() | |
| .ImplementedBy<Bar>() | |
| .LifestyleTransient(); | |
| } | |
| } |
Durch Klicken auf das Bild geht es zum Video
Was ist damit gemeint? Gemäß der Pfadfinderregel soll ein Entwickler Code immer besser hinterlassen, als er ihn vorgefunden hat. Clean Code oder guter Code ist häufig dann erreicht, wenn das Mindestmaß an essentiellen Code Prinzipien umgesetzt ist. Das sind die sogenannten SOLID Principles. Jedoch ist guter Code kein Selbstzweck, sondern dient dem größeren Ziel der Wirtschaftlichkeit.
Im folgenden Video zeige ich an einem Praxisbeispiel, wie ich bei einem bestehendem, eher unwichtigem Projekt vorgegangen bin. Timeboxed in 1h so viel refaktorisieren und den Code verbessern wie möglich. Dabei gehe ich auf Prinzipien wie DRY und OCP ein und zeige Techniken wie DI, sowie Tools wie den IoC Container Castle Windsor.
Feedback nehme ich wie immer gerne mit. Wenn ihr mehr von solchen Videos sehen wollt, schreibt mir das in die Kommentare, damit ich weiß: Hier lohnt es sich mehr zu machen.
Durch Klicken auf das Bild geht es zum Video
Wer keine Post mehr von Xing erhalten will, muss die Option in seinen Einstellungen deaktivieren, da diese automatisch aktiviert ist. Ruft dazu diesen Link auf oder geht – eingeloggt in eurem Profil – rechts oben auf „Einstellungen, Rechnungen & Konten“ (Zahnrad), dann auf das Reiter Benachrichtigungen und ganz unten gibt es die Option
An meine im Profil hinterlegten Adressen
unter dem Oberpunkt
Angebote und Informationen per Post
welche ihr deaktivieren müsst (siehe Screenshot). Ich empfehle euch generell regelmäßig in die Einstellungen eurer Social Media Konten wie Facebook, Twitter und Co. zu schauen, da neue Einstellungen häufig so voreingestellt sind, dass sie sich negativ auf die Privatsphäre und den Datenschutz auswirken.
Beispielsweise könnt ihr in diesem Beitrag nachschauen, wie ihr auf Facebook eure Daten für Werbetreibende sperrt. Über den Tag Datenschutz findet ihr weitere Hilfestellungen unterschiedlichster Art.
Nachdem ich im vorherigen Beitrag Beispiele zur Abgrenzung des fachlichen Konzepts Kunde gegeben habe, möchte ich in dem folgenden Video erklären, wie die Fachabteilung zu guter Software beitragen kann. Denn wenn fachliche Konzept klar abgegrenzt werden, fallen viele technische Probleme automatisch weg.
Der Klick aufs Bild führt zu dem Video in meinem YouTube Channel. Unten auf dem Zahnrad könnt ihr die Auflösung hochsetzen.
Video mit der Erklärung für die Fachabteilung woher die technischen Probleme bei der Vermengungen von fachlichen Konzepten kommen.
Die Entwickler müssen genau hinhören, was mit manchen Begriffen gemeint ist. (Quelle: Fotolia)
Im vorherigen Artikel habe ich erläutert, wie der Domänenbegriff Kunde in unterschiedlichen Bedeutungen verwendet wird. In diesem Post mache ich einige Vorschläge, welche zeigen, wie es sich besser machen lässt.
Der Kunde im Verkauf ist die Person, die meine Produkte kauft. Er ist also der Käufer.
Im Support ist der Kunde derjenige, der meine Produkte bedient und sich bei Fragen zur Bedienung an den Support wendet. Da könnten vielleicht Anwender oder Nutzer als Begriffe in Frage kommen.
Im Rechnungswesen ist der Kunde derjenige, der mir Geld für meine Produkte schuldet und die Schuld dann hoffentlich begleicht. Schuld => Debit => Debitor. Oder alternativ Kontoinhaber. Das wiederum könnte aber zur Verwechslung mit den Lieferanten führen, die natürlich auch Kontoinhaber sind. Also nehmen wir besser Debitor.
Im Versand oder im Lager geht es darum die Produkte an einen Empfänger auszuliefern. Wir benötigen die Adresse, um das Paket, das die Ware erhält, zu adressieren. Also Empfänger, Adressat, Warenempfänger – man hat die freie Auswahl.
Das Marketing hat unter anderem die Ziele, die Neukundenakquise mit Werbemaßnahmen anzukurbeln, gleichzeitig aber die Kundenbindung zu festigen. Also wie wäre es mit Neukunde und Bestandskunde. Alternativ potentieller Kunde oder – für manche Branchen denkbar – Kandidat.
Fazit
Es muss nicht immer schwer sein gute Domänenbegriffe zu finden, die klar ausdrücken, worum es sich bei dem Konzept handelt. Oftmals genügt es sich die Domäne, in der der Begriff verwendet wird, anzuschauen und zu umschreiben, was der Begriff ausdrücken soll. Mit der Erfahrung wird das für den Fachexperten ganz selbstverständlich und ihm springen förmlich schlechte Benennungen ins Gesicht (schon mal über das Konzept der ‚Benutzer‘ nachgedacht?).
In meinem nächsten Artikel kommen wir zu der spannenden Frage, woher die technischen Probleme bei Vermengungen von Bedeutungen kommen.
Jede Fachabteilung spricht von dem sogenannten Kunden (Quelle: Fotolia)
Heute war ein Meeting mit dem Rechnungswesen. Sie wollen eine Änderung, um einfacher die Kontodaten unserer Kunden ändern zu können. Letzte Woche sollte unser Kampagnen-Tool fürs Marketing dahingehend erweitert werden, dass sich detaillierter Informationen zu den Kunden sammeln lassen. Und nächste Woche, so wurde mir gesagt, soll ich mit dem Verkauf sprechen, um in den Gutschriften für Kunden einen Passus zu ergänzen.
Ups, was ist da los? Alle Welt spricht von dem ‚Kunde‘. Aber ist dabei immer der gleiche Kunde gemeint? Also natürlich ist es dieselbe Firma bzw. Person, aber ist auch das gleiche Konzept gemeint? Oder anders gefragt: Würde das Rechnungswesen Informationen über die Kundenbeziehungen ändern oder würde der Versand Änderungen an Gutschriften durchführen? Wohl eher nicht. Benötigt denn der Kundenservice in seiner Oberfläche Informationen wie die Bankverbindung oder muss das Rechnungswesen die abonnierten Mailinglisten des Kunden sehen können? Ups, da war es wieder: Der Kunde.
Mit diesem Artikel soll der Einstieg in eine kleine Serie gemacht werden, in der ich erkläre, warum sich viele Probleme mit der Anwendung bereits dadurch vermeiden lassen, dass die Fachabteilung bei Domänenbegriffen respektive -konzepten genauer abgrenzt und explizit macht, was sie meint.
Beispielsweise wirkt sich das, auch wenn es der Anwender nicht glauben mag, stark auf die Geschwindigkeit und die Skalierbarkeit des Programms aus. Gleichfalls ist die Erweiterbarkeit und die Entwicklungsgeschwindigkeit davon betroffen. Oder die Usability. Genauso die Sicherheit und die Fehleranfälligkeit. Ganz schön viel, was die nicht differenzierte Betrachtung eines Kunden ausmachen kann oder?
Im nächsten Teil erläutere ich Beispiele, die zeigen: Hey, das ist gar nicht so schwer eine klare Unterscheidung zu machen.
Ich möchte auf diesem Weg Werbung für eine Veranstaltung machen, die ich sehr schätze und an der ich seit mehreren Jahren teilnehme: Der .NET Open Space Süd.
Der #NOSSUED 2015 findet vom Samstag, 18. Juli 2015, 09:00 Uhr – Sonntag, 19. Juli 2015, 16:00 Uhr in Karlsruhe statt. Zur Anmeldung geht es hier.
Meine Berichte und Live Interviews findet ihr unter dem Tag Open Space. Einen Artikel zum Open Space Format hat die dotnetpro freundlicherweise freigegeben.
NET Open Space Süd in Karlsruhe
Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.
Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).
An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.
Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.
Vorbereitung ist alles
Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?
Evolvierbarkeit
Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.
Schnelles Feedback
Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.
Leerlauf vermeiden
Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.
Fazit
Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.
Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.
Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.
Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.
Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.
Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.
Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.
Ist dir das auch schon passiert,
Wenngleich es sehr viele Lösungen im Netz gibt, sind nur wenige davon für den weniger geübten Anwender geeignet. Die Firma MetaCtrl bietet für Android entsprechende Apps an, womit sich Verzeichnisse auf dem Smartphone automatisiert in den eigenen Cloudspeicher synchronisieren lassen. Nutzt du also Dropbox, OneDrive, Google Drive oder Box ohnehin schon, so ist das eine einfache Lösung. Exemplarisch möchte ich das für Dropbox zeigen:
Die zugehörige App heißt Dropsync (für andere Cloud Dienste findest du die zugehörigen Apps hier). Die App einfach installieren und starten. Dann musst du der App Zugriff auf Dropbox gewähren. Dazu einfach das vorausgewählte Dropbox Konto anklicken und zulassen.
Als nächstes kannst du dann ein Verzeichnis zur Synchronisation auswählen. Angefangen beim lokalen Verzeichnis, was logischerweise ‘WhatsApp’ heißt. Danach musst du das Verzeichnis in der Dropbox auswählen, wohin die Daten gespeichert werden sollen. Am besten kurz ein neues Verzeichnis anlegen, das du auch WhatsApp nennen kannst. Nun muss nur noch die Synchronisationsmethode ausgewählt würden. Ich würde “nur Uploads” vorschlagen. Was das genau bedeutet, könnt ihr in der App nachlesen.
Der Vorteil ist, dass damit jederzeit lokal Bilder und Videos gelöscht werden können, diese aber weiterhin in der Cloud bleiben. Außerdem ist im lokalen WhatsApp Verzeichnis auch die benötige Datei, welche für eine Wiederherstellung auf einem anderen Handy benötigt wird.
Das Wiederherstellen ist im Übrigens sehr einfach. Auf dem neuen Handy ebenfalls die App installieren, das WhatsApp Verzeichnis in der Dropbox als Quelle auswählen und lokal ein WhatsApp Verzeichnis erstellen. Als Methode wählst du dann “nur Downloads”. Nachdem das Verzeichnis vollständig synchronisiert wurde, kannst du WhatsApp auf dem Smartphone installieren. Beim ersten Starten wird dein Konto erkannt und eingelesen. Voila, alle Daten wieder da. Jetzt solltest du aber nicht vergessen die Synchronisationsmethode wieder auf “nur Uploads” zu stellen.
Am Ende habe ich noch mehrere wichtige Hinweise:
Mein Laptop ist vollständig mit TrueCrypt verschlüsselt. Jedoch konnte die zweite Partition, welche mit genau dem gleichen Passwort verschlüsselt wurde, nicht geladen. Stattdessen erhielt ich folgende Fehlermeldung:
Hintergrund ist der, dass ich ein deutsches Tastaturlayout verwende. Nachdem ich mehrere Methoden, wie sie im Netz zu finden sind, vergeblich durchführte, nahm ich eine Abkürzung und stellte einfach das Passwort um. Ab jetzt nutze ich nur noch Zeichen, die sowohl auf der englischen als auch der deutschen Tastatur gleich sind. Stichwort y/z und Konsorten.
Das Ändern des Kennworts ging übrigens in wenigen Sekunden, sodass ihr nicht wie bei der initialen Encryption mehrere Stunden für den Vorgang veranschlagen müsst.
Microsoft und die Medien-IT-Initiative Pforzheim veranstalten im Mai ein TechCamp in Pforzheim. Die Veranstaltungen sind kostenlos, jedoch ist für jeden Tag eine Anmeldung notwendig. Hier findet ihr die direkten Links zu Anmeldung.
Aufgrund meiner Erfahrung (1,2,3) kann ich speziell den Hackathon in Pforzheim empfehlen. Der ist jedes Mal eine tolle Sache. Danke an Petra von der Medialesson GmbH, die mich darauf aufmerksam gemacht hat.
Nach meinem ersten Beitrag über Telefonwerbung will ich euch jetzt die Vorlage zur Erwiderung von E-Mail-Werbung geben. Dabei spreche ich in erster Linie von Werbung wie sie z.B. von einem Fitnessstudio oder einer Versicherung kommen kann. Offensichtliche Spam- oder Phising Mails, wie sie für Viagra typisch sind (auf diese sollte man generell nicht antworten, weil es sonst nur noch mehr werden), sind ebenso wenig gemeint wie Newsletter. Bei letzteren muss nach aktueller Gesetzeslage immer auch ein Abmelde-Link mitgeschickt werden, der in der Regel ganz am Ende der E-Mail und in kleiner Schrift (häufig ‚Newsletter abbestellen‘) zu finden ist. Sollte dies nicht der Fall sein, ist das klar rechtswidrig.
Ich möchte abschließend noch darauf hinweisen, dass ich weder Jurist noch Datenschutzbeauftragter bin und es sich hierbei lediglich um eine Hilfestellung als Privatperson handelt. Holt euch also im Zweifelsfall bei entsprechenden Stellen Hilfe dazu.
Ich möchte Sie darauf hinweisen, dass ich von Ihnen keinerlei Werbung erhalten möchte. Ihre E-Mail war zudem rechtlich nicht erlaubt, da Ihnen keine (ausdrückliche) Zustimmung meinerseits vorlag. Ihre Werbung wird demnach, gemäß §7 Abs. 2 Nr. 3 UWG, als unzumutbare Belästigung angesehen.
Hiermit fordere ich Sie auf, wie im § 19 BDSG Abs. 1 vorgesehen, mir mitzuteilen, welche Daten Sie über mich gespeichert haben, aus welcher Quelle Sie diese Daten haben und an wen Sie diese Daten weitergegeben haben.
Des Weiteren erwarte ich, dass gemäß § 20 BDSG Abs. 2 meine Daten gelöscht werden. Wenn dies aufgrund eines Gesetzes nicht möglich ist, sind die Daten zu sperren (vgl. §20 BDSG Abs. 3).
Aus den gegebenen Gründen bitte ich Sie deshalb, mir jegliche Art von Werbung (E-Mail, Telefon, Post) nicht mehr zu schicken und mich aus Ihrem System zu entfernen.
Es gibt dedizierte Listen im Internet, in welche man sich eintragen kann, um von den Werbetreibenden nicht adressiert zu werden. Jedoch werden diese Verzeichnisse nicht sonderlich beachtet. In einem späteren Beiträge werde ich dazu einen Link veröffentlichen.
In den folgenden Tagen werde ich Vorlagen für schriftliche Erwiderungen auf Werbung jeglicher Art veröffentlichen. Dazu gehören ungewünschte E-Mails, Anrufe und Briefe sowohl im privaten als auch im beruflichen Umfeld.
Heute starte ich mit Telefonwerbung im privaten Umfeld. Wenn z.B. jemand bei euch zuhause anruft um ein Gewinnspiel zu bewerben, ohne dass eine Einwilligung eurerseits vorliegt, dann könnt den folgenden Text verwenden.
Ich möchte abschließend noch darauf hinweisen, dass ich weder Jurist noch Datenschutzbeauftragter bin und es sich hierbei lediglich um eine Hilfestellung als Privatperson handelt. Holt euch also im Zweifelsfall bei entsprechenden Stellen Hilfe dazu.
Ich möchte Sie darauf hinweisen, dass ich von Ihnen keinerlei Werbung erhalten möchte. Ihr Anruf war zudem rechtlich nicht erlaubt, da Ihnen keine (ausdrückliche) Zustimmung meinerseits vorlag und Ihr Anruf demnach, gemäß §7 Abs. 2 UWG, als unzumutbare Belästigung angesehen wird.
Hiermit fordere ich Sie auf, wie im § 19 BDSG Abs. 1 vorgesehen, mir mitzuteilen, welche Daten Sie über mich gespeichert haben, aus welcher Quelle Sie diese Daten haben und an wen Sie diese Daten weitergegeben haben.
Des Weiteren erwarte ich, dass, gemäß § 20 BDSG Abs. 2, meine Daten gelöscht werden. Wenn dies aufgrund eines Gesetzes nicht möglich ist, sind die Daten zu sperren (vgl. §20 BDSG Abs. 3).
Aus den gegebenen Gründen bitte ich Sie deshalb, mir jegliche Art von Werbung (E-Mail, Telefon, Post) nicht mehr zu schicken und mich aus Ihrem System zu entfernen.
Aktualisierung vom 11.04.2015:
Ausgerechnet heute bin ich in der News-App von ZDF auf folgende Meldung gestoßen (siehe Screenshot). Im Anschluss an die Blogserie werde ich deshalb noch einen weiteren Artikel mit Anlaufstellen veröffentlichen, für den Fall, dass die Unternehmen die Werbung nicht unterlassen. Sieht man sich die hohe Zahl schriftliche Beschwerden an, wird deutlich, dass das Thema durchaus Anklang findet. Wenn – subjektiv aus meiner Sicht geschätzt – nur jeder 10 Verbraucher eine Nachricht an die Bundesnetzagentur schreibt, so sprechen wir von über 250.000 Werbeanrufen.
In einem Online Interview habe ich Daniel Marbach zur Zukunft des Open Source BDD Frameworks MSpec befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden nicht vorab abgesprochen, um ein authentisches statt ein werbelastiges Gesprächs zu führen.
Auf das Bild klicken um zum Video zu gelangen
An dieser Stelle möchte ich noch die Community aufrufen sich an der Weiterentwicklung zu beteiligen. Open Source Projekte leben von freiwilligen Helfern und Daniel macht da eine sehr gute Arbeit und ein tolles Produkt!
Fragen
Show Notes
Am 18. März wird mir Daniel Marbach ein Video Interview zu dem BDD-Framework Machine.Specifications geben. Ein kleiner Vorgeschmack gefällig?
Wodurch hebt sich MSpec von anderen BDD-Frameworks ab?
oder
Welche Features sind gerade in der Pipeline?
oder
Welche anderen Frameworks ergänzen MSpec gut?
Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die Richtung des Gesprächs mitgestalten, indem ihr mir rechtzeitig eure Fragen in die Kommentare postet.
In einem Online Interview habe ich Tilman Börner über die digitale Zukunft der dotnetpro und die Anforderungen an potentielle Autoren befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden vorab nicht abgesprochen, um eine Gesprächsatmosphäre zu schaffen, wie sie bei einer Kaffeepause üblich ist.
Danke nochmal Tilman!
Fragen
Show Notes
In unserer IT Administration führen wir regelmäßige Retrospektiven durch. Das ermöglichte es uns Kategorien von Problem zu identifizieren, wie sie auf dem Bild zu sehen sind.
Die Systemadministration ist von Natur aus ein stark vom Tagesgeschäft abhängiges Umfeld mit viel Klein-Klein-Arbeit. Der Anwender ruft an, meldet PC Probleme (Spezifisches hört man selten), der Kollege unterbricht seine eigentliche Tätigkeit wie z.B. die Vorbereitung einer größeren Umstellung und kümmert sich um die Nöten des besorgten Anrufers. Kaum zurück und wieder in die Umstellung vertieft, kommt eine E-Mail, dass die Druckertoner leer sind. Erneut gilt es die aktuelle Arbeit zu unterbrechen.
Darüber hinaus laufen natürlich immer Projekte mit anderen Abteilungen oder Externen (Telekommunikationsanbieter, Dienstleister, etc.), die voran getrieben werden müssen. Selbst der Entwickler-Kollege aus der selben Abteilung ruft an und möchte einen neuen Testserver aufgesetzt bekommen – am besten vorgestern versteht sich.
Kurzum: Ein reges Tagesgeschäft parallel zu großen Projekten und das alles im Umfeld von unterschiedlichen Stakeholdern. So wie es auch in Marketingabteilungen oder Zentralen der Fall ist.
Nüchtern betrachtet handelt es sich um eine Warteschlangensystem. Da Menschen nicht gut darin sind viele Dinge parallel zu machen, vermuten wir hierin eine der Ursachen: Zu viele Dinge werden gleichzeitig erledigt. Außerdem stehen wir Dritten skeptisch gegenüber, welche uns rein gefühlsmäßig ausbremsen. Bei den Telekommunikationsanbietern können wir indes von einer Tatsache sprechen…Darüber hinaus meinen wir diverse weitere Hindernisse erkannt zu haben, die den Arbeitsfluss immer wieder stören.
Um weil wir uns gerne verbessern möchten, eine zu große Umstellung auf einmal eher scheuen und der Evidenz der Vermutung den Vortritt geben möchten, haben wir uns entschieden Kanban einzuführen. Auf einen Nenner gebracht liegen dem 3 Prinzipien und 5 Praktiken zu Grunde.
Prinzipien:
Praktiken:
Alle Regeln werden penibel eingehalten, jedoch ist die erste Regel alle Regeln abzuschaffen, die nicht mehr funktionieren.
Über die ersten Ergebnisse werde ich demnächst berichten. Falls jemand schon gute Erfahrungen primär im Administrationsumfeld gemacht hat, dann würde ich mich über Input freuen. Gerne auch aus der Softwareentwicklung.
Am 12. März werde ich mit Tilman Börner ein Online Interview führen. Die Fragen beziehen sich natürlich primär auf die dotnetpro. Ein kleiner Vorgeschmack gefällig?
Kann jeder einfach Autor werden und einen Artikel schreiben?
oder
Wann können wir mit einer Kindle Ausgabe rechnen?
oder
Welche Änderungen sind dieses Jahr nach dem Design Relaunch noch zu erwarten?
Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die Richtung des Gesprächs mitgestalten, indem ihr bis zum 11 März eure Fragen in die Kommentare postet.
Es braucht keine Retrospektiven und dedizierte Kaizen Phasen; schließlich hat das vorher auch alles geklappt und die Verbesserungen haben sich genauso eingestellt.
Aussagen wie diese hört jeder Change Agent früher oder später. Ich will gar nicht abstreiten, dass in jedem Unternehmen mehr oder weniger kontinuierlich optimiert wird. Jedoch geht durch das passive Verhalten viel Potential verloren. Das kann jeder ganz einfach kontrollieren. Der geneigte Leser soll dazu für einen kurzen Zeitraum – beispielsweise 2 Monate – jede Idee protokollieren, welche von Kollegen mit “das müssen wir mal machen” oder “das sollten wir demnächst angehen” kommentiert wird. Im Anschluss ist zu prüfen, was tatsächlich umgesetzt wurde. Ich wäre überrascht, wenn bereits 5% fertig sind. Wohlgemerkt fertig umgesetzt, nicht nur angefangen und wieder liegen gelassen. Ganz im Sinne von stop starting, start finishing. Bereits die Definition von Kaizen drückt das aus:
“Kaizen […] bezeichnet ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht.” – Wikipedia
Es handelt sich um ein methodisches Konzept. Eine Methode ist ein systematisches Verfahren. Laissez faire im Kontext von Verbesserungen kann aber nicht systematisch sein. Passive Kaizen-Kultur ist also ein Widerspruch.
Ein klarer Indikator für ungenutztes Potential, ist das wiederholte Auftreten des gleichen Problems. Der erste Gedanke, der einem dann kommt, ist: Mist, das wollten wir doch mal machen (siehe Aussage oben). Das können häufig kleine Dinge wie eine fehlende Fahrzeugpoolverwaltung oder eine Verwaltung für die ohnehin nicht gerade reichlichen Besprechungsräume sein. Aber auch komplexere Themen wie die hohe Informationsflut im Zeitalter der Wissensarbeit. Schon mal über eine SharePoint Dokumentenbibliothek oder ein Wikisystem nachgedacht? Und wenn ja, auch realisiert?
Unabhängig von den Implementations-Phasen solcher Ideen/Lösungen, gehören zu einer soliden Kaizen-Kultur auch Retrospektiven. Selbstverständlich werden hier wieder Stimmen laut, die behaupten, dass ich mir doch keine Zeit reservieren muss, in welcher ich reflektiere und nach Verbesserungsmöglichkeiten suche. Das ist leider eine ähnliche Floskel wie:
Wir brauchen keine Mitarbeitergespräche. Wir reden regelmäßig miteinander.
Wer sich aber mit den Themen intensiv beschäftigt und ganz darauf einlässt, stellt einen großen Unterschied fest. Persönlich habe ich sogar den Eindruck, dass durch kurze, oberflächliche Problemanalyse Lösungen entwickelt werden, die das Symptom kaschieren, nicht aber aber die Ursache beheben. Als Change Agent hat sich in dem Fall die sokratische Methode bewährt. Stelle solange W-Fragen (Warum, Wer, Was) bis – wie Goethe sagt – des Pudels Kern gefunden ist.
Der Leser kann sich dazu kurz in Erinnerung rufen wie es bei der Zulassungsstelle bei einer Ummeldung abläuft. An dem einen Schalter beantragt man die Anmeldung. Mit dem Papier geht man an den Schalter neben an. Natürlich muss dort wieder angestanden werden. Nach einer meist längeren Wartezeit wird dort das alte Schild vernichtet und das neue ausgegeben. Damit läuft man wieder an den ersten Schalter und nach noch längerer Wartezeit erhält man dann endlich die Papiere.
Wenn ich jetzt danach frage, wie sich der Prozess optimieren lässt, dann kommt ohne lange Überlegung die Antwort: Na indem am Schalter schneller gearbeitet oder mehr Personal eingestellt wird. Überstunden wären ebenfalls möglich. Das sind zwar alles Optionen, allerdings lange nicht die besten, da diese nur sehr beschränkt skalieren und teuer sind. Vielleicht ist das der Grund, warum bis heute die meisten Kfz Halter sich einen halben Tag Urlaub für das Ummelden nehmen müssen. Eine mathematisch nachweislich bessere Antwort gibt es hier.
Fazit
Keine Frage: Es braucht kleine, kontinuierliche Verbesserungen, damit die Unternehmen diese verdauen können. Evolution statt Revolution (manchmal auch letzteres!). Aber Evolution im Schneckentempo gleicht eher einem Rückschritt, weil die anderen schneller voran kommen. Wer jeden Tag 30 Minuten ins Fitnessstudio geht und sonntags ruht, hat am Ende der Woche auch 3 Stunden trainiert. Und genauso wie Trainings als feste Termine eingeplant werden müssen, bedarf es auch fester Zeiten für Retrospektiven und die Umsetzung der daraus resultierenden Ergebnisse.
Und wenn der Leser immer noch motiviert ist, dann kann er gerne einen Kommentar hinterlassen, ob in seinem Unternehmen bereits Kaizen an der Tagesordnung ist oder nicht und warum respektive warum nicht.
Social Media ist nur ein Trend
Ich bin vor einigen Monaten aus unserer Social Media Gruppe (meine früheren Berichte zu unserer Arbeit) ausgetreten. Nicht weil ich darin keinen Sinn mehr gesehen oder weil ich nichts mehr hätte beisteuern können. Vielmehr liegen meine Stärken mehr darin Ideen zu entwickeln und einzuführen, als diese bis zum Schluss zu begleiten. Schluss bedeutet hierbei bis die letzten Kollegen „überzeugt“ wurden. Die Autorinnen Rising Linda und Mary Lynn sprechen in ihrem tollen Buch Fearless Change von sogenannten “Innovators” und “Early Adopters” (einen Einführungs-Podcast dazu gibt es hier). Mit Laggers werden übrigens Persönlichkeitstypen bezeichnet, die nicht zu überzeugen sind. Dazwischen reihen sich die Early Majority und Late Majority ein.
Nachdem vor kurzem die Gruppe überein kam sich aufzulösen, sprach mich eine Kollegin an. Sie ist der Meinung, dass viele Ideen respektive Ansätze dabei sind, bei denen es sich lohnt diese weiterzuführen. Zum Beispiel unsere Textwerkstätten. Sie wollte wissen, wie ich über die Entscheidung denke und ob ich einen Vorschlag hätte, um die Gruppe neu auszurichten. Vor allem da sich die bisherigen Ergebnisse sehen lassen konnten und sie die Art der interdisziplinären Kollaboration im Vergleich zur (homogenen) Abteilungsarbeit spannend fand.
Nun wird der ein oder andere Leser vermutlich denken: Das war doch klar. Social Media und Unternehmen passen nicht zusammen. Das ist ein vorübergehender Trend, den jeder früher oder später abhaken muss!
Halte an deinen Zielen fest, bleibe dabei aber flexibel
Mein Sicht darauf war dann doch eine andere, was ich meiner Kollegin wie folgt erklärt habe: Das Ende der Social Media Gruppe ist lediglich dem Namen und der Beschränkung auf eine festgelegte Personengruppe geschuldet. Die Idee dahinter hat längst bei uns Wurzeln geschlagen. Denn inzwischen machen wir unternehmensweite Open Spaces, bei denen die “Lehrer” und “Schüler” Rollen kontinuierlich wechseln und die Agenda von allen Mitarbeitern mitbestimmt wird. Am Vormittag erzählt noch der Kollege aus Berlin umfassend über ein neues Produkt und die Kollegin aus Nürnberg hört zu, am Nachmittag werden die Rollen getauscht und die Kollegin referiert über Werkstoffe und deren Einsatzszenarien.
Die Meetings unserer Marketing- & Einkaufs-Abteilung sind inzwischen für alle geöffnet. Durch gezielte Einladungen abteilungsfremder Kollegen soll das gefördert werden. Themen- und Projektvorschläge werden in den Wochen zuvor von allen Mitarbeitern im Wiki zusammengetragen. Jedem „Stakeholder“ ist freigestellt Input zu liefern.
Ein weiteres Beispiel ist unser Arbeitsplatztausch, bei dem jeder Mitarbeiter mindestens 1x jährlich in eine andere Abteilung wechselt, um über den eigenen Tellerrand hinaus zu schauen. Und natürlich schreibt der Kollege seinen Erfahrungsbericht in unseren Corporate Blog. Stephan ist übrigens kein Mitglied der Social Media Gruppe! Damit ist er einer von vielen, die bereits gebloggt haben.
Mir fallen auf Anhieb noch viele weitere Ausprägungen ein, doch unser Erfolg zeigt sich meiner Meinung nach am besten darin, dass ich kürzlich beim Vorbeigehen nicht umhin kam zu hören, wie der Einkaufsleiter in Nöttingen am Telefon einer Kollegin aus Frankfurt wie selbstverständlich mitteilte: “Das kannst du alles im Wiki nachlesen und dann ggf. ergänzen”. Dass der Einkaufsleiter noch ein paar Wochen zuvor seine Mitarbeiterin – selbige ist Teil der Social Media Gruppe und daher bestens geschult im Umgang mit dem Wiki – gefragt hat wie der Inhalt einzupflegen ist, brachte mich dann doch zum Schmunzeln. Mit einem Video zur Integration der Wiki-Inhalte in unser Warenwirtschaftssystem habe ich die Vernetzung bei uns bereits illustriert.
Neben einigen weiteren Beispielen wies ich meine Kollegin noch darauf hin, dass sie selbst erst kürzlich gegenüber dem Vorgesetzten den Wunsch geäußert hat in ihrer Abteilung regelmäßige Retrospektiven zur Verbesserung der Prozesse umzusetzen. Ebenfalls ein Ansatz, den wir bei der Social Media Gruppe einsetzten.
Quelle: http://pixabay.com/de/baum-struktur-netzwerke-internet-200795/
Fazit:
Nur diejenigen, die Social Media nicht auf Werkzeuge wie Facebook und Twitter reduzieren, sondern die Ansätze und Gedanken dahinter verstehen, können das der Sache inhärente Potential nutzen. Die Schulungs-Agenda sollte eben nicht mehr nur vom Abteilungsleiter definiert oder Geschäftsprozesse durch die Geschäftsleitung festgelegt werden. Stattdessen muss sich eine Kultur etablieren, bei der die Fähigkeiten aller genutzt werden und das Wissen der Masse kontinuierlich geteilt wird. Dadurch entsteht eine Lernkultur, bei der Informationen nach Belieben beigesteuert und herausgezogen werden können. Social Media ist insofern auch keine neue Idee, jedoch sind inzwischen viele digitale – teils populäre, teils weniger bekannte – Werkzeuge auf dem Markt. Mit dem inzwischen signifikanten und noch weiter steigenden Anteil der sogenannten Wissensarbeit ist nicht mehr die Frage, ob man auf den Zug aufspringen sollte. Die Herausforderung liegt darin die passenden Werkzeuge zu evaluieren und eine entsprechende Unternehmenskultur zu etablieren. Denn wer nicht mit der Zeit geht, geht mit der Zeit.
Wie stehts bei euch um Change Management, Social Media und Innovationen? Welche Werkzeuge nutzt ihr? Seid ihr schon auf einem guten Weg oder springt ihr gar nicht auf den Zug auf?
In einem Online Interview habe ich Ralf Westphal und Stefan Lieser, die Gründer der Clean Code Developer School, zum Thema Clean Code befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden nicht vorab abgesprochen, um eine Gesprächsatmosphäre zu schaffen, wie es sie bei einer Kaffeepause gibt.
Es war ein toller Gedankenaustausch. Danke nochmal ihr zwei!
Zum Video
Fragen
Für die Zukunft sind weitere Interviews geplant:
Falls ihr noch Ideen habt, dann schreibt sie in die Kommentare.
Am 22.1. werde ich abends ein Online Interview mit den Clean Code Koryphäen Ralf Westphal und Stefan Lieser führen. Die Fragen werden thematisch weit gestreut sein. Ein kleiner Vorgeschmack gefällig?
Macht Clean Code Sinn, wenn die Kollegen nicht mitziehen?
oder
Community vs. Freizeit: Wie ist das vereinbar?
oder
Woher weiß ich, wann ich es mit Clean Code übertreibe?
Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die die Richtung des Gesprächs mitgestalten, indem ihr bis ca. 15 Uhr eure Fragen in die Kommentare postet.
Situation:
Ihr kauft ein Samsung Galaxy Handy und erhaltet 50 GB Dropbox Speicherplatz dazu. Wie das geht, habe ich in diesem Beitrag geschrieben. Nach 2 Jahren läuft die Aktion aus. Kein Problem denkt ihr, weil mit der Vertragsverlängerung ein neues Smartphone von Samsung kommt, welches ebenfalls den Dropbox Deal beigefügt hat. Dem ist leider nicht so, wie ihr der Antwort des Supports entnehmen könnt. Wenn es euch aber nichts ausmacht eine weitere E-Mail-Adresse zu verwenden, könnt ihr die Einschränkung umgehen.
Meldung
[…]die Dropbox-Speicherplatzaktion im Rahmen Ihres Samsung-Geräts ist abgelaufen. Ihr Speicherplatzkontingent wurde automatisch auf 7 GB gesetzt. Wenn Ihr Speicherlimit von 7 GB überschritten ist, können Sie keine neuen Fotos, Videos und Dokumente mehr in Ihrer Dropbox speichern.[…]
Frage an den Support
[…]ich habe inzwischen ein neues Samsung Handy gekauft (Note 3), welches ebenfalls über einen entsprechenden Deal verfügt, jedoch kann ich den Speicherplatz nicht wieder aufladen. Woran liegt das?[…]
Antwort des Supports
[…]Leider können wir den Bonus-Speicherplatz einer Aktion nur einmal gutschreiben, damit Aktionspreise derselben Art nicht auf einem Konto angehäuft werden. Wenn Sie also bereits eine Aktion genutzt haben, kann keine weitere beansprucht werden.
Sonderaktionen sind aber auf Freunde oder Verwandte übertragbar. Dazu brauchen sich diese einfach von Ihrem die Teilnahmebedingungen erfüllenden Gerät aus in ihrem eigenen Konto anzumelden.
Bitte entschuldigen Sie eventuelle Unannehmlichkeiten. Bei weiteren Fragen stehe ich Ihnen gerne zur Verfügung.[…]
Uli Armbruster 