Posts Tagged ‘Rollin’

Lesetipps April 2014

In der letzten Zeit sind wieder viele spannende Artikel in der Presse erschienen. Bei einigen dieser Artikel lohnt sich das Teilen in Form eines eigenen Blogbeitrages.

Daneben benutze ich regelmäßig Twitter, um wichtige Neuigkeiten zu meinen Themen zu sammeln und zu verteilen. In den weiterführenden Informationen ganz unten finden Sie die entsprechenden Links, um sich dort zu abonnieren.


Lesetipps Herbst 2013

Es haben sich wieder Artikel und Videobeiträge in meiner Inbox angesammelt, bei denen sich das Teilen lohnt.

Heute geht es um Neuigkeiten, Trends, und Ideen zu den Themen „Globalisierung“, „Interface Design“, und „Spieltheorie“.


Lesetipps Juni 2013

Derzeit stechen (neben der Flutkatastrophe natürlich) zwei Themen heraus: PRISM, und das neue iOS UI.

Einige der Neuigkeiten zu PRISM und zum neuen Clean Design Paradigma möchte ich heute kurz einführen. Sie finden die Links zu den erwähnten Artikeln ganz unten unter „Weiterführende Informationen“.


Lesetipps April 2013

Ich hoffe, daß Sie ein angenehmes Osterfest verbracht haben. Ich war noch ein paar Tage länger unterwegs. Sie kennen den Zustand nach dem Rückkehr aus dem Urlaub sicher selbst; zu solchen Gelegenheiten erwartet Einen eine prall gefüllte Mailbox mit manch interessanter Information.

Einige der interessanten Fundstücke und Neuigkeiten möchte ich heute mit Ihnen teilen. Sie finden die Links zu den erwähnten Artikeln ganz unten unter „Weiterführende Informationen“.


Lesetipps Februar 2013

Hinter den Kulissen habe ich die letzten paar Tage am Umbau meiner Blogs gearbeitet, die sich mit dem Thema Fotografie beschäftigen. In einigen Tagen werde ich sicher soweit sein, daß ich diese Änderungen life schalten werde.

Es haben sich währenddessen einige Kurzartikel angesammelt, bei denen sich eine Zusammenfassung lohnt.


Verteiltes Brainstorming – Tipps für die neuen Kollegen

Das heutige Thema will ich kurz halten. Neulich haben Kollegen angefangen, die gerade erst ausgelernt haben, und deshalb noch nicht geübt sind in den Techniken der Informationssammlung und Ideengenerierung. An solche jungen ProduktmanagerInnen wendet sich mein heutiger Artikel. Ich bespreche einen einfachen Prozess, um Kollegen in die Ideenfindung einzubinden.


Weniger Features sind oft mehr

In einem typischen Softwareprodukt werden viele Funktionen kaum benutzt. Ein Produkt mit weniger Features zu haben, wäre hier von Vorteil, sowohl was die Komplexität betrifft, als auch die Wartung der Software, und die Kosten.

Heute geht’s um des „minimal viable scope“ eines Produktes, als eine Möglichkeit, genau das zu entwickeln, was für den Markterfolg notwendig ist (und nicht mehr).


Innovation in einer globalen Welt

Ausgehend von den USA hat die Finanz- und Wirtschaftskrise gerade die industrialisierten Länder getroffen. Viele sich entwickelnde Länder, wie China, Indien, Brasilien sind daher auf dem Weg, wirtschaftlich aufzuschliessen.

Wie eine Untersuchung zeigt, führen die makroökonomischen Veränderungen auch zu Veränderungen auf einem anderen Gebiet. Es ändern sich nämlich auch die Käufergruppen für Produkte, und damit auch die Anforderungen, die diese Produkte erfüllen müssen.


Weniger kann mehr sein

Neulich habe ich über eine Designausstellung in Hamburg geschrieben, bei der es um designorientierte Firmen, wie Braun Elektrogeräte, Wega, oder Apple geht.

Kürzlich habe in einen Blogartikel gelesen, der für die Vereinfachung der Kommunikation und Präsentation wirbt, und sich im Grunde genommen die Frage stellt, warum einfache Präsentationen oft die Besten sind.

Da gute „designorientierte“ Produkte sich durch Einfachheit auszeichnen, will ich mich heute der Frage stellen, wie man einfache Produkte erschafft, indem den „Ansatz des bewussten Verzichts“ verfolgt.


Wer genau hat es verbockt? HP und die Rolle des Entwicklungs-Know-How

Der Spiegel hat neulich in seinem Artikel → Wer hat’s verbockt? HP! mehr über die Hintergründe geschrieben, die hinter Hewlett Packard’s jüngster Entscheidung stehen, das Segment der mobilen Geräte einzustellen.

Der Vorgang, und der Artikel sind ein gutes Beispiel für die Frage, wie Produkte so gestaltet werden, daß sie im Wettbewerb zu anderen Produkten erfolgreich sind.


Die größten Fehler der Existenzgründer und das Requirementsengineering

Im Spiegel werden die größten Fehler besprochen, die Existenzgründer machen können. Mindestens zwei dieser Fehler haben mit dem Aufgabengebiet des klassischen Produktmanagements zu tun. Darum geht’s heute.


Planning Poker und Magic Estimation

Eine wichtige Aufgabe des Produktowners ist es dafür zu sorgen, daß das Team eine angemessene Anzahl von Aufgaben erhält: Nicht zuviel, und nicht zuwenig.

Da der Aufwand eines Entwicklungsprojekts oft nicht einfach einzuschätzen ist, und einem vielfach die notwendigen (kompletten) Informationen fehlen, sind Verfahren notwendig, mit denen man den Backlog schnell abschätzen kann, obwohl die Genauigkeit fehlt.


Requirement versus Specification

Apple hat neulich ein neues iPhone präsentiert, das von der Fachwelt zerrissen wurde. Im Gegensatz dazu ist das Smartphone jedoch von den Konsumenten sehr gut aufgenommen worden. Fragt sich, welche Rückschlüsse aus dieser Fehleinschätzung abgeleitet werden können.

Gerade heute war die übliche Frage mal wieder ein Thema, die da lautet „Was sollen Anforderungen, Spezifikationen, und Design-Dokumente leisten, und wer liefert sie?“. Heute will ich kurz auf die Rolle von Kundenwünschen, und auf die Rolle der Entwicklungsabteilung und damit auf das Thema „Spezifikationen“ eingehen.


Fokussieren eines Scrum Teams

Ich denke mal, daß es häufiger vorkommt, daß ein Scrum Team nicht für ein komplettes Produkt verantwortlich ist, sondern Teilbereiche der gesamten Funktionalität verantwortet. Auch ist es sicherlich nicht unnormal, daß ein Team mehr als einen Stakeholder unterstützen muss oder komplexe Technologien verwendet, oder Funktionalitäten in unterschiedlichen Releases unterstützt.

Unter solchen Rahmenbedingungen stellt sich die Frage, was der Produktowner tun kann, damit ein Team nicht in mehrere Teilgruppen zerfällt die dann auch noch unterschiedlich spezialisiert sind.


User Stories und Use Cases

Im Rahmen der userzentrierten Entwicklung konzentriert man sich auf die Situation des Anwenders; schliesslich soll die neue Anwendung den Bedürfnissen dieses Anwenders dienen.

Da ja nicht jedes Teammitglied mit den Anwendern jedes Detail mündlich klären kann, ist es notwendig, die Situation des Nutzers nachvollziehbar zu dokumentieren. Heute haben wir einige Zeit über die begriffliche Abgrenzung der beiden Themenkreise „Use Case“ und „User Story“ gesprochen. Beide Konzepte leisten wertvolle, jedoch unterschiedliche Dienste in der Softwareentwicklung.


Design Pyramide

In seinem Artikel → The Design Pyramid schreibt Philip Haine über die Frage, wie Forschung, Vision und Design zusammenpassen müssen, damit fundamental neue Produkte entstehen. In seinem Artikel geht er auch auf die Entwurfsmuster ein, die hinter jedem guten, und erfolgreichen Produkt stehen. Darum geht es mir heute.


SSNiF (Stakeholder, Situation, Need, Feature) Analyse

Gerade in der Entwurfsphase einer Software hat man auf der einen Seite die Wünsche der „Kunden“. Auf der anderen Seite stehen die einzelnen Realisierungen. Die Analysemethode, um die es heute geht, hilft dabei die Produktanforderungen, und die Featureentwicklung zusammenzubringen.

Die Stakeholder-Stituation-Need-Feature Analyse kann dabei auf verschiedenen Leveln angewendet werden, und sie hilft sowohl bei der Strukturierung, als auch bei der Qualitätsprüfung der Produktanforderungen.


Think Like an Innovator – Vier Strategien, die Innovationen hervorbringen

Jeff Dyer hat zusammen mit Co-Autoren ein neues Buch mit dem Titel The Innovators DNA geschrieben. In dem Vorstellungsvideo geht er auf die Faktoren ein, die eine innovative Firma auszeichnen. Auf dem Sandblog habe ich zu einem der Faktoren weiterführende Tipps erhalten.

Heute liefere ich einige Ideen, die Ihnen dabei helfen können, eine innovativere Firma zu werden.


Spezifikationen und Testing

Meine bisherigen Blogbeiträge zum Thema „Qualität von Spezifikationen und Anforderungen“ gehören zu den meistgelesenen Artikeln. Heute habe ich mich mit dem Thema „Testen von Software“ befaßt, und mir insbesondere den Certified Tester – Foundation Level Syllabus angesehen, der vom→ ISTQB (International Software Testing Qualifications Board herausgegeben wird.

Dort stehen einige interessante Informationen über die Qualität von Spezifikationen, auf die ich heute kurz eingehen will.


Creation Spaces – Einrichtung

Heute habe ich in der Washington Post einen Artikel von John Hagel, John Seely Brown, and Lang Davison des Deloitte Center for the Edge gelesen, der sich um Creation Spaces dreht.

Nachdem ich neulich über Creation Spaces generell geschrieben habe, möchte ich hier ein paar Hinweise zur Einrichtung und zum Betrieb solcher Creation Spaces geben.


Interessante Twitterbeiträge

Twitter ist eine unerschöpfliche Quelle für Informationen und fremde Artikel. In diesem Post werde ich kurz einige zusammenfassen.


Was tun wenn man mehr Anforderungen hat, als Zeit….?

Wenn Sie ein umfangreiches und erfolgreiches Produkt betreuen, kennen Sie sicherlich den Zustand, daß Sie (…..und damit Ihr agiles Team…) mehr Anforderungen erhalten, als Sie jemals werden abarbeiten können. Wenn Sie schon länger Ihr Produkt betreuen, wissen Sie auch, wie problematisch Anforderungen sein können, die unkontrolliert in das Produkt hineinwandern.


Requirements Tools – A New Study by Forrester

Und zwar hat Forrester Research eine neue Studie über den Markt für Softwaretools herausgebracht, mit denen man Anforderungen erhebt, verwaltet, und bewertet.

Sie kennen das Problem ganz besonders, wenn Sie Software anbieten, die besonders umfangreich ist. Dann erreichen Sie – getreu dem Motto „der Appetit kommt beim Essen“ – relativ schnell viele Verbesserungsvorschläge, Bugbeschreibungen, oder Erweiterungswünsche. Um Ihre (agilen) Teams richtig versorgen zu können, benötigen Sie einige Informationen über die Requirements, und den jeweiligen Use Case.


10 Punkte für den Projekterfolg

Wie in der Fachliteratur zu lesen ist, gehört das richtige Anforderungsmanagement zu einem der wichtigsten Einflussgrößen für den Projekterfolg. So gehen konservative Schätzungen davon aus, dass circa 30 – 50% des Entwicklungsaufwandes für Fehlerbehebung, Nacharbeiten, oder andere Aktivitäten aufgewendet wird, die nicht wertschöpfend sind. Hier geht es um 10 Punkte, die diese Kostentreiber einzugrenzen helfen.