Hallo! Mein Name ist Google gegen Apple, Microsoft & Facebook
Hier eine sehr schöne Aufstellung der Google-Produkte und jeweils dessen Konkurrenten bei den anderen großen Playern:
Apple
- Google’s Android is fighting with Apple’s iOS platform. It says a million new devices are being activated every day and there are 400 million Android devices out there.
- Google just launched Nexus 7 to essentially compete with Apple’s iPad and other tablets in the market.
- Google TV and Apple TV are in competition for the dollars and attention of connected-entertainment consumers.
- Google Drive vs iCloud.
- Google Maps versus Apple Maps.
- Google Wallet/Play versus the Apple iTunes platform.
- Google Books, Google Music and other Media versus iTunes and iBooks.
Microsoft
- Google’s Chrome OS is taking on Microsoft’s OS.
- Google Apps versus Microsoft Office Apps.
- Google Android versus Microsoft Windows 8 platform.
- Google Nexus 7 tablet versus Microsoft Surface tablet.
- Google Cloud will be competing for Microsoft’s Azure cloud and developer affections.
- Google Drive versus Microsoft Skydrive.
- Google Search versus Microsoft Bing.
Amazon
- Google Nexus 7 versus Amazon’s Kindle Fire.
- Google Android platform versus the Amazon Fork.
- Google Cloud wants to challenge Amazon Web Services.
- Google Wallet versus Amazon payment system.
- Google Books, Google Music and other media plays versus Amazon Music, Books and Media
- Google+ versus Facebook.
- Google messaging versus Facebook Messaging.
- Google Picasa versus Facebook Photos.
- Google Ad Platform versus Facebook Ad Platform.
- Google Search versus Facebook Social Discovery.
And there are some other companies Google is tussling with.
- Google Drive versus DropBox as a hub of mobile data and apps.
- Google Nexus Q versus Sonos.
- Google Local versus Yelp.
- Google Wallet versus Paypal, Square.
- Google Search versus Twitter.
- Google+ versus Twitter.
- Google’s YouTube versus others such as Hulu.
Einführung in Doctrine 2 ORM
Eine deutschsprachige Einführung in Doctrine 2 ORM von mir gibt es jetzt bei Slideshare.
Über das Internet, Hochtechnologien und den Fortschritt
Manchmal frage ich mich, ob wir seit der Erfindung des Internets und dessen Verbreitung, so wie wir es heute kennen, nicht eigentlich große Teile der Evolution erneut beschreiten. Conversion Optimierung ist da so ein Thema. Ich glaube, ich kenne keinen Supermarkt, der nicht so gestaltet ist, dass der Absatz durch geschickt platzierte Schokoriegel im Kassenbereich gefördert und die Kaufwahrscheinlichkeit durch optimierte Einkaufswege durch den Laden erhöht wird. Selbst der Spätkauf bei mir um die Ecke macht das so. Und das nicht erst seit gestern, sondern seit mindestens mal zehn Jahren. Das die Schachtel Kelloggs nicht in jenem Regalfach, das 5 Meter über dem Boden entfernt ist, aufgestellt wird, damit es auch Jemand kaufen kann, ist selbst für nicht-Fachleute einleuchtend. Das der Weg zur Kasse nicht durch Kartons vollgestellt, das Kassenband erwartungsgemäß funktioniert und meine EC-Karte auch tatsächlich vom Gerät gelesen wird, ist nicht minder logisch. Im Web nennen wir das dann “Usability Optimierung”, machen eine Wissenschaft draus und fühlen uns wie die Versteher der Welt. Streckenweise ist das alles schon sehr peinlich.
Heute in meinem RSS-Reader stolpere ich über den “Social Media Tipp des Tages: Hören Sie zu!”. Ach? Das ist ja mal ganz was Neues. Wenn man seinem Gesprächspartner auch mal zuhört, stellt sich eine gute Kommunikation ein. Ich glaube, dass gilt so ziemlich seit Menschengedenken. Aber gut, dass wir das im Web jetzt auch zur Kenntnis nehmen. Übrigens sind Ehrlichkeit, Aufrichtigkeit und ein angemessener Tonfall samt passender Wortwahl auch sehr hilfreich für den Aufbau von menschlichen Beziehungen. Damit habe ich dann jetzt meinen Beitrag dazu geleistet, dass wir als User gemeinsam mit dem Web weiter unseren Kinderschuhen entwachsen. Wahnsinn. Ich wüsste so gern, wie die Zeit kurz nach Erfindung des Telefons bzw. nach dessen initialer, flächendeckender Verbreitung wohl so war. Vermutlich haben sich alle Leute wie wild ständig angerufen, einfach nur des Anrufens wegen und weil man sich so gefreut hat, dass man jetzt auch auf diesem Wege mit einander kommunizieren konnte. Komisch, irgendwie erinnert mich das grad alles an Handys, SMS und an …. Facebook. Manchmal frage ich mich, ob das Web wirklich so eine Hochtechnologie ist, für die Viele sie halten und wie sie landläufig ja gerne wahrgenommen wird.
Was lernen wir daraus: Die “physische (Konsum-)Welt” ist für jeden Onliner mehr als einen flüchtigen Blick wert, auch, wenn Sie längst totgesagt ist. Außerdem sollten wir uns nicht für so wichtig nehmen. Auch wenn das Internet alles verändert, Vieles zum positiven, so ist die ganze Branche in vielen Bereichen weiterhin eine ganz kleine Nummer und wir müssen noch viel, viel lernen. Wir sollten viel selbstkritischer sein. Und weniger arrogant. Und bitte lasst uns auch mal damit aufhören, ständig dieses “Optimization” an jede Tätigkeit anzuhängen. Das klingt viel zu final, viel zu nach dem heiligen Gral. Ein Produkt ist niemals fertig. Die Conversion niemals optimal. Außer vielleicht wenn Sie bei 100% läge. Wenn jemand so ein Business hat, würde ich gerne mitmachen. Aber wir schweifen ab. Wie wäre es mit “Improvement”? Wäre das nicht viel treffender und inbesondere … ehrlicher? Ich verstehe ja auch nach wie vor nicht, wieso SEO eigentlich SEO heißt und wieso wir das nicht mal ändern.
68 Fragen, die ein Neu-CTO stellen sollte
Startet man als CTO (oder als “Lead Developer” oder “VP Engineering” oder “IT-Abteilungsleiter” oder …) in einem (Startup-)Unternehmen, dass bereits eine weile Bestand hat, so steht man in aller Regel nicht auf der “grünen Wiese“, sondern sieht sich zunächst einmal mit einer ganzen Reihe von gewachsenen Strukturen, Prozessen und Tools konfrontiert. Ganz im Sinne von Kanban, das eine Evolution zum Besseren einer radikalen Revolution des Status Quo vorzieht, sollte der Neu-CTO zunächst einmal all seine Energie darauf verwenden, die Ausgangssituation genau zu verstehen (übrigens auch dann, wenn er später nicht Kanban, sondern Scrum oder Wasserfall macht 
).
Ein paar wichtige Dinge noch vorab, die eigentlich immer Gültigkeit haben, aber besonders auch für Neu-CTOs gelten :
- In aller Regel setzt ein Unternehmen nicht die aktuellste Technik ein. Auch wenn man also immer gerne sofort “the latest & greatest” einsetzen möchte, so ist dies schlichtweg nicht immer möglich und auch nicht immer sinnvoll. Arrangieren Sie sich zunächst mit dem Status Quo. Wertschätzen Sie die Leistung des Teams und der Organisation, so weit mit den verfügbaren Mitteln gekommen zu sein. Reden Sie nicht am ersten Tag schlecht über die aktuelle Situation. Diese Einstellung bedeutet allerdings auf der anderen auch nicht, dass man einfach damit lebt und nichts zum Besseren verändern will. Natürlich wollen Sie das. Aber eben auf einem positiven Fundament. Sie wollten ja nicht gleich als Miesepeter und Besserwisser gelten.
- In aller Regel sind die Prozesse in einem Unternehmen nicht ideal. Auch wenn man also immer gerne sofort Alles automatisieren und optimieren will, so ist dies schlichtweg nicht immer möglich und auch nicht immer sinnvoll. Prozesse sind fast nie bewusst “engineered” (und selbst dann ist das ja keine Garantie für Qualität), sondern haben sich im Laufe der Zeit aus der Situation heraus so etabliert.
- In aller Regel sind die Produkte oder Dienstleistungen, die ein Unternehmen verkauft oder erbringt, nicht optimal. Eigentlich sind Sie das nie. Und wichtig ist insbesondere, dass man die Probleme nicht alle sofort und über Nacht beheben kann. Fast immer gibt es viel mehr Verbesserungsideen, als man direkt umsetzen kann. Auch mit offensichtlichen Problemen müssen Sie also mal eine Weile Leben können. Haben Sie ein wenig Geduld. Gleiches gilt übrigens auch für eingesetzte Tools. Auch die haben immer Ecken und Kanten. Es gibt immer etwas zu Verbessern.
- Andere Menschen haben andere Ansichten. Etwas, das Sie selbst für verrückt oder falsch halten, es ist es nicht zwangsläufig. Häufig haben Sie nur eine andere Sichtweise und vor allem andere Erfahrungen, die Sie zu diesem Urteil bringen. Seien Sie nicht zu schnell mit dem “in eine Schublade stecken” und verteufeln. In aller Regel existieren Dinge nicht vollkommen ohne Grund. Oftmals ist der eigentlich Grund nur nicht sofort ersichtlich, aber irgendjemand wird sich irgendwann irgendetwas dabei gedacht haben.
So, jetzt aber. Die folgende Aufstellung hat ganz bewusst keinen Anspruch auf Vollständigkeit sondern ist viel mehr mein persönliches “Logbuch“. Schaut man aus einer anderen Brille, so ergeben sich sicherlich zusätzliche oder andere Fragestellungung. Zudem habe ich administrative Themen des “Vorgesetzten-Daseins” nahzu vollständig ausgeklammert.
Team
- Wer sind die Mitarbeiter im eigenen Team?
- Wie ist die Aufbauorganisation im eigenen Team?
- Über welche Kenntnisse und Fertigkeiten verfügen die Mitarbeiter?
- Welche Rollen sind vorhanden?
- Sind aktuell Stellen zu besetzen oder sollen Stellen abgebaut werden?
Kontext & Umwelt
- Wer sind die internen Auftraggeber (Upstream)?
- Wie genau kommen die Aufträge in meinen Bereich?
- Für wen agiere ich intern als Auftraggeber (Downstream)?
- Wie genau stelle ich Aufträge nach “Downstream”?
- Mit welchen internen Dienstleistern wird zusammengearbeitet? Wie “exklusiv” ist der Zugriff?
- Mit welchen externen Dienstleistern wird zusammengearbeitet?
- Welche Vorschriften von öffentlichen Stellen finden Anwendung für den eigenen Bereich / die eigene Tätigkeit?
- Wie sehen die Eskalationsprozesse aus?
Leistungskatalog
- Welche Leistung werden von meinem Bereich erbracht?
- Gibt es definierte SLAs für die Leistungserbringung? Wenn ja, welche?
- Welche Prozesse zur Leistungserbringung existieren in meinem Bereich? Wer ist beteiligt?
- Wie gliedern sich die Prozesse des eigenen Bereichs in die übergreifenden Geschäftsprozesse ein? Wie sehen die Geschäftsprozesse von “Ende-zu-Ende” aus?
Systeme, Software & Architekturen
- Welche Anwendungen / Aspekte werden selbstständig entwickelt und betrieben?
- Welche Technologien werden dazu eingesetzt?
- Wie sieht das Domänen Model aus, in dessen Umfeld die Anwendungen eingesetzt werden?
- Wie sehen die Datenstrukturen aus?
- Wie und wann werden neuen Versionen released?
- Welche Verbindungen gibt es zwischen separaten internen Systemen? Wie sind diese realisiert?
- Welche externen Systeme (Standardlösungen) werden eingesetzt?
- Welche Verbindungen zu externen Systemen existieren? Welche Daten werden ausgetauscht, welche Funktionen bereitgestellt?
Tools
- Für welche Ausfgaben oder Prozesse werden Tools eingesetzt?
- Welche Tools werden eingesetzt?
- Wer ist verantwortlich für den Betrieb und die Wartung der einzelnen Tools?
- Welche Dokumentationssysteme gibt es?
- Wer ist für Aktualität der in Dokumentationen und Wikis vorgehaltenen Informationen verantwortlich?
IT-Infrastruktur
- Aus wechen Komponenten / Netzen besteht die Infrastruktur?
- Für welche Komponten wird die Wartung selbst durchgeführt, wofür Dienstleister eingesetzt?
- Gibt es Single Points Of Failures (SPOF) in der IT-Infrastruktur? Wenn ja, welche? Wird das Risiko aktuell bewusst eingegangen?
- Wie schnell kann der Betrieb nach Ausfalls eines SPOFs wieder hergestellt werden?
- Wo sind aktuell Kapazitätsflaschenhälse?
- Gibt es eine Test / Staging – Umgebung für Applikationen?
- Welche Zugangskontrollen sind implementiert?
- Wie steht es um die “Evergreens”? Datensicherung? Recovery? Security? Wie sind Abläufe, Notfallrufnummern und wer sind die handelnden Personen?
Projekte
- Welche Projekte werden derzeit bearbeitet?
- Wie ist in den laufenden Projekten der Status?
- Welche Projekte sind für die Zukunft geplant? Existiert eine Roadmap?
- Nach welche Kriterien werden Projekte priorisiert?
- Von wem werden Projekte priorisiert, wie werden Projekte finanziert?
- Welche Projekte wurden in der Vergangenheit durchgeführt und wie war deren Ergebnis?
Performance, Finanzen & KPIs
- Welches Budget ist eingeplant? Wie ist die aktuelle Soll/Ist – Situation?
- Mit welchen KPIs wird die Qualität und Quantität der Leistung vom zu verantwortenden Unternehmensbereich gemessen?
- An wen, in welchem Umfang und in welcher Form werden diese KPIs reported?
- Welche KPIs existieren für andere Unternehmensbereiche und wie wirken sich die eigenen KPIs auf ebenjene aus?
Außenwahrnemung & Kundenzufriedenheit
- Wie ist die gefühlte Außenwahrnumung des eigenen Bereichs?
- Wie ist es um die Kundenzufriedenheit Upstream und Downstream bestellt?
- Welche Situationen, Aussagen oder Probleme sind “typisch” für den eigenen Bereich?
Strategie
- Welcher Strategie folgt der zu verantwortenden Unternehmensbereich bis dato?
- Welche Strategie / Taktik wird vom Unternehmen verfolgt?
- Welche bekannten Probleme und Herausforderungen bestehen aktuell für den Bereich und das Unternehmen?
Excel-Vorlage für die Product Backlog Priorisierung und Releaseplanung
Für alle Product Owner, die noch nach einem pragmatischen Tool zur Release Planung und zur Unterstützung der Product Backlog Priorisierung suchen, stelle ich gerne meine Excel / Google Docs Product Roadmap – Vorlage zur Verfügung, die sich in den letzten Monaten für mich als hilfreich und praktikabel herausgestellt hat. Schauen wir uns Schritt für Schritt für Kernelemente der “Product Roadmap” an, damit Sie die Vorlage sofort produktiv einsetzen können.
Struktur
Grundsätzlich besteht das Template aus den 3 Kernelementen: “Theme Data”, “Scoring” und “Timetable” (von links nach rechts).
Theme Data
Die Spalten im Bereich “Theme Data” (links) bündeln alle Meta-Informationen zu einem Theme:
- ID: Eindeutiger und dauerhafter Schlüssel für ein Theme.
- Theme: Bezeichnung des Themes.
- Owner: Verwantwortlicher / Initiator und damit erster Ansprechpartner bei Fragen.
- Added: Datum, an dem die Initiative zum Backlog hinzugefügt wurde. Dies ist vor allem hilfreich, wenn man irgendwann mal das Backlog aufräumen und “Karteileichen” entfernen will.
An dieser Stelle ein paar zusätzliche Erklärungen: Ein Theme ist die Gruppierung von logisch zusammenhängenden User Stories. Ich arbeite auf der Ebene der Priorisierung und Releaseplanung nicht mit User Stories, sondern mit ebenjenen Themes und richte mich damit nach dem Empfehlungen von Mike Cohn. Ein Theme repräsentiert dabei in aller Regel ein MMF (Minimum Marketable Feature), auch, wenn letztendlich mehrere User Stories zu dessen Realisierung erforderlich sind. Schlussendlich macht die Bearbeitungsreihenfolge der User Stories innerhalb eines Themes keinen Unterschied mehr und ist stattdessen häufig von logischen Abhängigkeiten unter den Stories geprägt. Die einzelnen User Stories zu den Themes verwalten ich in anderen Systemen oder in einen anderen Tabellenblatt. Wichtig ist dabei nur, das die Verbindung von Themes und User Stories gegeben ist. Durch den Einsatz einer eindeutigen und dauerhaften ID für jedes Theme ist das ja allerdings kein Problem. Es wäre aber natürlich auch denkbar, die Vorlage direkt mit User Stories zu füllen. Fühlen Sie sich also frei, die Vorlage so zu verwenden, wie sie für sie zweckmäßig ist.
Scoring
Über das Scoring wird die Wichtigkeit eines Themes bestimmt und damit dessen Priorität und Position auf der Roadmap. Je wichtiger ein Theme, desto schneller wird es umgesetzt. Da der Scoring-Prozess etwas sehr individuelles ist, hier ein paar Fragen, die Sie zunächst für sich beantworten sollten:
- Welche Eigenschaften eines Themes haben Einfluss auf die Bewertung der Priorität? Ich verwende etwa die folgenden Eigenschaften nach denen alle Themes bewertet werden: “Strategic Fit”, “Revenue” und “Costs (oder: Aufwand)”.
- Welches Gewicht haben die Eigenschaften jeweils? Der Einfachheit halber bin ich dazu übergegangen, alle Eigenschaften mit dem gleichen Gewicht auszustatten. Das muss allerdings nicht so sein und Sie können die Gewichtung entsprechend problemlos in der Vorlage justieren.
- Welche Werte pro Eigenschaft sind möglich? Ich nutze, analog zum Vorgehen bei der Aufwandsschätzung von User Stories, die bekannte, an die Fibonnaci-Folge angelehnte Staffelung: 0, 1, 2, 3, 5, 8, 13 (und gelegentlich: 20). Sie können allerdings auch Werte von 1 bis 5 oder sonstige numerische Reihen Ihrer Wahl verwenden.
- Wer setzt die Bewertungen wann fest? Legen Sie als Product Owner die Bewertung alleine fest? Oder agieren Sie in einem komplexeren Umfeld und benötigen einen Product Council zur Bestimmtung der Prioritäten?
Das Scoring-Element lässt sich übrigens auch reduziert darstellen und gibt dann nur noch den errechneten Gesamtscore pro Theme aus. Das ist oftmals vollkommen ausreichen und gibt insb. dem Timetable mehr Platz auf dem Screen.
Timetable
Auf Basis der Kosten- /Aufwandsbewertung im Scoring können nun unter Berücksichtung der ermittelten Velocity des Realisierungsteams und einem auf diesem Wert definierten “Wechselkurs” für Theme Points und Story Points die einzelnen Initiativen auf die Zeitleiste projiziert werden. Im Timetable ist zudem markiert, welche Blöcke/Themes bereits erledigt sind (grün) und welche noch ausstehen (grau). Zusätzlich kann die aktuelle Kalenderwoche in der Spaltenüberschrift farblich hervorgehoben werden. Das erleichtert die tägliche Arbeit mit dem Dokument.