Der Papageientaucher (Puffin auf Englisch) ist ein Profil, das als Leiter eines Entwicklerteams endlose Softwarefunktionen mit geringen oder keinen Auswirkungen auf das Geschäft, Kunden oder andere Mitarbeiter hat.
Ein PUFFIN – (Planet endlose Feature-Factory-Initiativen) wäre auf Spanisch gleichbedeutend mit endlosen Plänen für Feature-Initiativen.
Dieser Begriff der Profile setzt Kosten und keinen Nutzen voraus, zusätzlich zu einer großen Frustration der Teams, die keine Sichtbarkeit in der Organisation haben.
Der Begriff Feature Factory entstand, als ein befreundeter Softwareentwickler sich darüber beschwerte, dass er „nur in der Fabrik sitze, Features baue und sie an andere Entwickler ausliefere“.
Woher wissen Sie, ob Sie in einer Funktionsfabrik arbeiten? Es gibt klare Symptome, die es ermöglichen, diese Strukturen zu identifizieren.
- Sünde Metriken. Teams müssen die Auswirkungen ihrer Arbeit nicht messen. Oder, wenn eine Messung durchgeführt wird, wird sie isoliert vom Produktmanagementteam durchgeführt und selektiv geteilt. Es ist nicht bekannt, ob die durchgeführten Arbeiten korrekt funktionierten.
- Schneller Mix aus Teams und Projekten (auch bekannt als Team-Tetris). Statt sinnvoller und nachvollziehbarer Missionen oder Initiativen beschäftigen sich Teams mit Rollenzuweisungen und Projekten, ohne zu wissen warum oder wer wofür zuständig sein soll. Multitasking in allen Operationen und Überbeanspruchung von Ressourcen.
- Theater des Erfolgs rund um den „Versand“ mit wenig Diskussion über die Auswirkungen. Durch die Fragen, die sie stellt, kann viel über eine Organisation gesagt werden feiert.
- Seltene (erkannte) Ausfälle und verschrottete Arbeiten. Ohne bisherige Funktionen zu eliminieren oder wesentlich zu verbessern. Der primäre Erfolgsmaßstab sind die gelieferten Funktionen, nicht die gelieferten Ergebnisse. Arbeit wird selten angesichts von Daten und Lernen abgetan. Der Ausrüstung fehlt das nötige Maß, um Produktionsausfälle einzugestehen.
- Keine Verbindung zu Geschäftskennzahlen. Gespräche über Kunden- oder Geschäftsergebnisse finden nicht oder selten statt. Das Team ist nicht in der Lage, die Arbeit mit wichtigen Geschäfts- und Kundenzufriedenheitsmetriken in Verbindung zu bringen. Arbeit kann nicht mit l verbunden werdenoder erhebliches Geschäft.
- Keine Auswirkungsanalyse. Produktmanager überprüfen die Qualität von Produktentscheidungen nicht regelmäßig und vergleichen daher nicht den erwarteten Nutzen mit dem tatsächlich erzielten Nutzen. Die Entwickler haben "genehmigte Anforderungen", aber Produktmanager haben keine Ziele des Geschäfts. Als Key Performance Indicator werden nur Geschwindigkeit und Produktion berücksichtigt
- Besessenheit von Priorisierung. Es treten Diskrepanzen zwischen der Strenge der Priorisierung (Entscheidung, woran gearbeitet werden soll) und der Strenge der Validierung (Entscheidung, ob es tatsächlich das Richtige war, daran zu arbeiten) auf. Die Strenge der Priorisierung ist auf einzigartige Weise darauf ausgelegt, interne Agenden so zu mildern, dass sich die Menschen „sicher fühlen“. Es steckt viel Arbeit in der Entscheidung, an welchen Ideen gearbeitet werden soll, und lässt wenig Raum für ergebnisorientierte Anpassungen und Improvisationen. Roadmaps, Pläne, zeigen eine Liste von Funktionen, keine Schwerpunktbereiche und/oder Ergebnisse.
- keine Anpassungen. Sobald die Arbeit „erledigt“ ist (gemäß den Prinzipien von Entwicklungsmanagern), geht das Team sofort zum nächsten „Projekt“ über, sodass keine Zeit bleibt, mit qualitativen und quantitativen Daten zu iterieren, die zu Verbesserungen und Verbesserungsplänen führen.
- Kultur der Übertragung der Leistung. Das Team ist nicht direkt in die Forschung, Erforschung der zu bewältigenden Probleme/Herausforderungen oder Experimente und anschließende Validierung involviert. Sobald die Arbeit erledigt ist, hat der Entwickler wenig Kontakt mit Support, Kundenzufriedenheit und Geschäftsergebnissen.
- Tolle Paketsets. Ohne den Auftrag zum Experimentieren werden Funktionen in großen Funktionspaketen und nicht in inkrementellen Releases bereitgestellt. Wenn Methodik angewendet wird agil, es kann sein, dass immer noch in Sprints gearbeitet wird, aber am Ende jeder Lieferung nichts Neues beim Kunden ankommt.
- Suchen Sie im Voraus nach Einkommen. Es werden Funktionen implementiert, um neue einmalige Geschäfte abzuschließen. Obwohl dieser Ansatz nicht grundsätzlich falsch ist, sind die wirtschaftlichen Begründungen oft (bestenfalls) schwach und berücksichtigen nicht die nichtlineare Zunahme der Produktkomplexität (kurzfristige Vorteile, die später anfallen). ) . Auch hier wird die Idee verstärkt, dass Merkmale die Maßeinheit des Wertes sind. Bei Produktentscheidungen mangelt es an einer soliden wirtschaftlichen Vision und Strategie.
- „Sterne“-Projekte. Die ständige Bereitstellung neuer Funktionen überschattet andere Arten von notwendigen Initiativen. Reengineering, Kostenreduzierung und Wertschöpfungsarbeit sind wenig sichtbar. Die Konzentration auf diese Hauptfunktionen lenkt von Aufgaben über die Auswirkungen neuer Funktionen auf Benutzerfreundlichkeit, Wartbarkeit, Skalierbarkeit usw. ab.
