Was die Messungen zu verwenden, um Ihre Prozesse verbessern?[geschlossen]

Question

Diese Frage wurde ursprünglich zur Frage "Welche KPIs Sie in einem software-Entwicklung-organisation".Leider scheint es, dass KPI ist ein vier-Buchstaben-Wort, und die unmittelbare Annahme ist, dass die KPIs sind immer falsch verwendet wird (Sie vielleicht?).

So habe ich hoffentlich verbesserte sich die Frage, um die zugrunde liegenden Ziele, die ich ursprünglich dachte, KPIs nützlich waren.Vorausgesetzt, Sie haben einige Verfahren, wie Sie (oder Ihre organisation) entwickelt software.Zweitens gehen davon aus, dass Sie (oder Ihr team) will besser werden bei der Entwicklung und Lieferung der software.Schließlich, davon ausgehen, dass eine der Möglichkeiten, Sie zu verbessern ist, indem Sie die Verfeinerung Ihrer Verfahren.

Gegeben alle diese, wie Sie wissen, ob Ihr Prozess Verfeinerungen haben eine positive Wirkung?Wenn diese sind KPIs, oder [SMART-Ziele](http://en.wikipedia.org/wiki/SMART_(project_management) bitte geben Sie einzelne oder Gruppen von KPIs/SMART-Ziele, die Sie gefunden haben, die wirksam sein.Wenn es ist ein anderer Mechanismus bitte erklären, was es ist.Endlich, denke ich-wenn Sie nicht denken, dass die Verbesserung der Prozesse ist eine nützliche Sache, ich denke, Sie können erklären, dass auch.

Die Bereiche der Verbesserung, die ich denke, wäre nützlich sind:Qualität, die Aktualität der Veröffentlichungen, Produktivität, Flexibilität.Wenn es sind andere Aspekte eines einzelnen oder ein team von Entwicklern, dann wäre interessant zu wissen.

Klarstellende Hinweise:

Die Frage ist nicht etwa, wie man am besten die Anpassung oder Veränderung, einen Prozess, oder was für eine gute Prozess-Verbesserung Prozess (sei es Kaizen, retrospektiven, etc.).Noch ist es über root-cause-Analyse oder andere Ansätze verwendet, um zu bestimmen, welche spezifischen Aspekte eines Prozesses verbessert werden sollten.

Die Verwendung von Maßnahmen, um zu bestimmen, wenn der Prozess Verbesserung erreicht wurde, sollte nicht verwechselt werden mit den Laufenden, wie es geschieht -, Prozess-Verbesserung.(Das ist eine gute Sache, aber es ist nicht, was die Frage!)

Die Prozess könnte alles sein;scrum, agile, extreme, Wasserfall, ad-hoc.Diese Frage ist nicht über Sie, welcher Prozess am besten für bestimmte Arten von software-Entwicklung, vielmehr ist es, wie zu verbessern, dass der Prozess im Laufe der Zeit.

Offensichtlich ist die spezifische Metrik hängt von der Prozess, der beteiligt ist, und die wahrgenommene problem, der versucht verbessert werden.Diese Frage ist einfach entworfen, um Beispiele für Metriken verwendet, das wäre natürlich umfassen eine Reihe unterschiedlicher Prozesse und Bereiche mit Verbesserungspotenzial.

Die Metrik muss nicht etwas sein, das verwendet wird alle die Zeit, zum Beispiel, es könnte nur verwendet werden, während die Prüfung, ob ein Prozess ändern funktioniert.(Für Beispiel, es könnte zu teuer sein - Zeit oder Geld klug zu Messen und verfolgen Sie jederzeit, damit Sie genau verfolgen, es wird optimieren die Prozess).

Es wird als eine Tatsache, dass, wenn die Umsetzung schlecht, die Verwendung von Metriken kann eine nachteilige Wirkung als Entwickler game system oder sonst.Es wird davon ausgegangen, dass die person, die Umsetzung des Prozesses ändern, ist sich dieses Problems bewusst und hat bereits wirksame Schritte, um ihn zu mindern.

Alle software-Organisationen unterschiedlich sind und wie passen Sie in Ihre Firma, so haben andere spezifische Dinge von Ihnen erwartet innerhalb der Firma, aber ich würde denken, dass die Produkt Qualität, Produktivität, Flexibilität und Aktualität-Versionen sind anwendbar auf die meisten-wenn nicht alle-Organisationen.(Offensichtlich mit unterschiedlicher Gewichtung, abhängig von der spezifischen organisation.)

Diese Frage hat nichts damit zu tun source lines of code!Insbesondere, ich bin nicht interessiert in Messung der Produktivität der Programmierer, vor allem in Bezug auf die SLOCs oder # von bugs behoben, oder andere naive Messungen.Ich bin interessiert in höher-Ebene Weg, ein team oder einzelne Maßnahmen zu deren Verbesserung.Ich bin nicht daran interessiert, mit einem einzigen KPI zu Messen, wer die Leistung.Ich bin Interesse an der Verwendung einer Reihe von KPIs zu Messen und zu verbessern mein team von software-Entwicklungsprozessen.

Ich weiß von horror-Geschichten über KPIs missbraucht und nicht unwirksam (Sie brauchen nicht zu suchen, sehr schwer zu finden), aber ich kann nicht glauben, dass niemand da draußen versucht kontinuierlich an einer Verbesserung Ihrer Prozesse, so muss es einige gute Beispiele für KPIs, die es gibt.

Ich weiß alles über die Nachteile, die eine vereinfachende Metriken, die angewendet werden, um die einzelnen software-Programmierer.Ich bin wirklich hoffend, um Beispiele für KPIs oder alternative Strategien, die Menschen gefunden haben, als nützlich, sondern als all die Gründe, warum darf ich nicht mit KPIs.

Ich bin hauptsächlich daran interessiert, Prozesse und Leistungen im Zusammenhang mit einer entwicklungspolitischen organisation in einem größeren Unternehmen, im Gegensatz zu einem software-Entwicklung Unternehmen als ganzes.Zum Beispiel, ein software-Unternehmen sollten sicherstellen, dass die Produkte haben die richtigen Funktionen für den Markt, aber in der Regel, die Produkt-management-Rolle, anstatt engineering.Und ja, es ist eine komplett andere Diskussion, wie, warum und in welchem Umfang sollten Ingenieure beteiligt in Produkt-management, aber das ist eine separate Diskussion.

Answer 1

Mit Abstand der beste einzelne Indikator "getestet-Funktionalität geliefert und akzeptiert".In der Agilen Welt, wir in der Regel Messen "Funktion" im Sinne von "user stories" aber es kann in jeder geeigneten form, wie lange, wie es ist die Messung der tatsächlichen Funktionalität geliefert und getestet, akzeptabel für die Kunden.

Die üblichen anderen Maßnahmen, wie SLOC, SLOC/Mitarbeiter-Stunden, usw., scheitern, weil der Charlie ' s Erstes Gesetz der Verwaltung, die:

Die Leute werden liefern, was Sie sind belohnt wird, zu liefern.

Richten Sie Ihre Maßnahmen, SLOC, und erhalten Sie viele SLOC.Verwenden SLOC/hr, erhalten Sie viele SLOC/ht.Geben Sie Boni, überstunden zu leisten, erhalten Sie viele überstunden.

Oh, und erinnern Sie die correlary auch:

Was die Leute ausgeben, ist das, was Sie denken, lohnend sein, um die liefern.

Wenn Sie nicht bekommen, was Sie wollen, Fragen Sie, warum es sich lohnt zu tun, die Dinge, die immer getan.

Answer 2

Wenn ich höre, Key Performance Indicator, bekomme ich ein wenig besorgt, weil in der Regel die nächste Sache ist die Verknüpfung von Leistung zu belohnen, und dann können Sie Leim sehr schnell.Ich bin immer daran erinnert, die software-Firma entschied sich für ein reward-system, um Fehler Befestigung - die Tester belohnt werden für das Auffinden von bugs und die Entwickler belohnt, die für das beheben von Fehlern.Die Entwicklung kam zum erliegen, als eine sofortige Schwarzmarkt gebildet, um die insertion zur Erkennung und Korrektur von Fehlern.

Ihre organisatorische KPIs sollten Kunden fokussiert.Je nach Typ des software-Produkts, das Sie verdienen, können Sie Messen es in die folgenden Möglichkeiten:

• Sales - - Ist Ihre Produkt treffen Kunden Anforderungen?Sie können in der Lage sein zu Messen, das in Bezug auf das Verhältnis von software-Präsentationen, um Verkäufe oder Besuche auf Ihrer Website kaufen Seite, um die tatsächlichen Käufen
• Qualität - Ist Ihr software-verständlich und zuverlässig?Wie viele support-Anrufe pro Kunde erhalten Sie pro Tag?Sind die Fragen, wie man etwas zu tun oder Fehler?
• Kunden Zufriedenheit - Wie zufrieden sind Ihre Kunden mit Ihrem Produkt?Befragen Sie Ihre Kunden und finden Sie heraus, was Sie tun könnte, um Ihre Zufriedenheit erhöhen dann die Umfrage später wieder, um herauszufinden, ob Sie haben sich verbessert.(Nicht verärgern Ihre Kunden viele Fragen stellt oder zu oft)

Ja, diese Indikatoren zu haben scheinen, nichts zu tun mit dem base-level-software-Metriken wie bugs gefunden und Zeilen code produziert.Jedoch, das problem mit bugs gefunden ist, dann haben Sie die Bewertung der schwere des bugs, und die Umgestaltung wird oft reduzieren Sie Ihre code-Zeilen.Aktualität nur darauf an, ob Sie die Anforderungen mit den Erwartungen Ihrer Kunden von pünktliche Lieferung.

Konzentrieren Sie sich auf die business-Ziele zu erreichen.Wenn Sie Kunden den Kauf Ihrer software, müssen Sie nicht viel Unterstützung zu verwenden es, und Sie sind glücklich, Ihr software-organisation erfolgreich ist.Keine Maßnahme Fehler erkannt, Zeitplan rutscht oder sonst was ist egal, wenn Sie nicht haben diese drei Dinge statt.

Wenn Ihr software-Projekt ist-wie die meisten da draußen, es wird zu spät sein, über budget, Schiff mit weniger Funktionen als vorgesehen und haben bugs.Don ' T beat yourself up, über diese Dinge mit Ihnen umzugehen und bewegen auf.Ja, Sie müssen bug-Datenbank, source control, Test-und mess-Projekt velocity-aber am Ende, wenn Sie nicht erfüllen die geschäftlichen Ergebnisse, dann können Sie nicht erfolgreich sein, unabhängig davon, wie Poliert und glänzend Ihr code ist und wie wenige bugs hat.

Update versuchen, zu Adresse die überarbeitete Frage

KPIs wie Sie Wunsch verwenden, Sie sind schwer bei der Lieferung eines immateriellen Produkts, ist oft auch ein bewegliches Ziel ist.Werden Ihre Kennzahlen in diesem Jahr auf eine Buchführung haben die gleiche Bedeutung, im nächsten Jahr, wenn Sie die Implementierung eines Dokumenten-management-system?

Nehmen wir als Beispiel einen Beruf, wo KPIs sind weit verbreitet - Rechtsanwälte.Messen von Juristen verwendet KPIs, z.B.:die Durchschnittliche Rechnung Arbeitsstunden pro Tag;fakturierten Stunden pro Monat;Alter der Schuldner ledger;Durchschnittsalter der nicht fakturierte arbeiten;Prozent der abgerechneten Gebühren abgeschrieben;und so weiter.Sollten Sie bemerken einen trend hier - all diese KPIs beziehen sich auf die Bereitschaft (oder nicht) des Kunden zu zahlen für die erbrachten Dienstleistungen.Dies ist der Letzte Schiedsrichter der Erfolg und das ist der Grund, warum ich vorgeschlagen (oben) einige Möglichkeiten, die Sie nutzen könnte diese Art der Messung als KPI für software-Unternehmen.

Wenn Sie versuchen, nach unten zu bekommen, mit KPIs, die nicht in Beziehung zu Ihrem Kunden Zahlungsbereitschaft für den Wert, den Sie bieten, dann sind wir runter, um Probleme mit dem, was wir Messen, wie Sie Messen und welche Unterschiede es bei der Messung oder was gemessen wird in diesem Jahr im Gegensatz zum letzten Jahr.

"US-Dollar gezahlt durch Kunden" hat einen festen Wert von Jahr zu Jahr - beliebige Metriken wie "Fehler in der software", "Aktualität release" und "Flexibilität" nicht zu einem bestimmten Wert und eine Erhöhung der KPI kann nicht haben eine direkte Beziehung zu den zugrunde liegenden Wert, der gemeint ist, um gemessen zu werden, indem Sie den KPI, wie "Fehler bedeutet geringere Qualität".

Zum Beispiel, nach der Columbia-Katastrophe, Erinnere ich mich an die Untersuchung team kam mit mehreren hundert Empfehlungen und Elemente untersucht werden.Habe diese neu entdeckte "Fehler" bedeutet das space shuttle hatte plötzlich viel weniger Qualität?Tatsächlich, nach der Untersuchung das space shuttle hatte mehr Qualität.So ein KPI um Fehler können leicht verzerrt werden von einem umfangreichen QA-Sitzung und mehr Fehler kann tatsächlich bedeuten, dass Ihre software hat eine höhere Qualität.

Produktivität in Bezug auf die Aktualität der Veröffentlichungen, ist leicht verzerrt durch kommerzielle Faktoren, wie eine client-werfen Geld auf Sie zu machen einige benutzerdefinierte Entwicklung für Sie.Ihre release-Zeitplan wird slip, aber Ihr Geschäft verbessern wird.

Wie für Flexibilität, ich kann nicht einmal raten, wie Sie das, wäre Vermessen, so etwas greifbares.

Über die einzige Messung, die ich mir denken kann, dass der Wert dieser Seite der Kunden wallet project velocity - wie viel haben wir uns schätzen, dass wir so tun würde letzten iteration/Zyklus/release ein und, wie viel haben wir eigentlich gemacht?Dann stecken Sie diese Figur in der zur Verfügung stehenden Zeit für die nächste iteration/cycle/release Schätzung, wie viel werden Sie wahrscheinlich in der Lage sein zu tun diese Zeit.Sie können die Anzeige der verbleibenden Zeit in einem burn-down-chart oder ähnlichem während der iteration.

Der rest kommt zu verarbeiten, die ich don T glaube, Sie können die pin nach unten, um KPIs.Alles, was Sie tun können, ist sicherzustellen, dass Ihre Entwickler wissen, was jeder tut (täglich Entwickler-meetings), Ihrem erweiterten team bekommt Eingang (wöchentlich oder vierzehntägig team-meetings), Sie verstehen, was war letztes mal, und was nicht (retrospektiven) und vor allem haben Sie transparente, effektive Kommunikation.

Leider, ich glaube nicht, dass es keine Magie KPIs wie Sie nach (aber übersehen Sie nicht die Bedeutung von Geld von Kunden als KPI).

Answer 3

Benno, ich bin Beantwortung Ihrer kommentieren, aber nicht genug Zeichen gibt es für die Antwort.

Dies hängt von dem problem, das Sie lösen möchten.Zum Beispiel angenommen, das Problem ist, dass die Zeit aus, wenn der Entwickler prüft den code, bis er tatsächlich in Serie zu lang erscheint.Dann erhalten Sie eine baseline-Messung, wie lange es nehmen wird.dann setzen Sie Sie in Ihre ändern, und Messen Sie anschließend für einen Zeitraum von Zeit zu sehen, wenn es nun weniger Zeit in Anspruch nimmt.Sie könnte auch überprüfen Sie, so etwas wie die Anzahl der Zeiten, die Lösung war entschlossen, nicht zur Arbeit und zurück gesendet für rework vor und nach sowie um sicherzustellen, dass die Lösung nicht schneller, aber geringerer Qualität.

Jetzt das problem bei diesen Messungen ist, dass es kann einige Zeit dauern zu sammeln genug Daten da einige Probleme nicht erneut auftreten, Häufig.In diesem Fall müssen Sie möglicherweise beginnen Sie, indem Sie sich auf subjektiven Daten, bis Sie können akkumulieren genug Daten, um zu wissen, ob die änderung gut war oder nicht.Aber frag nicht, ob etwas eine Verbesserung, bis die Benutzer daran gewöhnt haben.Die erste Woche oder zwei eine neue Prozess, werden Sie auf Widerstand treffen, sich zu ändern und somit schlechte subjektive Ergebnisse, wenn Sie Fragen zu früh.

Eine andere Sache, vorsichtig zu sein, ist, dass, wenn die Menschen wissen, die Sie Messen etwas, werden Sie Angst haben, dass Ihre persönliche Leistung wird gemessen und somit wird Spiel das system um gute Ergebnisse zu erzielen.Es ist oft am besten, wenn Sie können, nehmen Sie Messungen basierend auf einigen system bereits vorhanden (wir haben ein system, dass verwaltet Anforderungen für änderungen an der software, konnten wir die Datenbank Abfragen, um herauszufinden, historisch, wie viele Anfragen die Frist verpasst, wie viele wir wieder geöffnet, nachdem Sie geschlossen oder sind bezogen auf die letzten Anfragen etc., was die Zeit Unterschied zwischen Entwickler finishing code und verlagert die Produktion, etc.sind).Sie kann auch haben zu prüfen, Beseitigung von schweren Ausreißer, vor allem, wenn die Zeit umfasst den Zeitraum von der alten und neuen system.Zum Beispiel haben wir eine Anforderung, die wurde in der Qa für über 100 Tage nicht, weil es schlecht ist sondern weil die QS ein avaliability problem, und dieses ist die niedrigste Priorität, so behält er stieß immer höhere prioroity Arbeit.Dieses mal würde Sie nicht als wertvoll für die Messung der Verbesserung der Zeit, denn der Faktor Zeit, so lange nicht der Prozess, den Sie korrigieren möchten.Wenn Sie die graph-Daten, werden Sie leicht sehen, die Ausreißer, die vielleicht ausgenommen.

Answer 4

Stützen Sie Ihre KPIs in Bezug auf Kosten, Qualität und Zeitplan wäre ein guter Anfang.Überlegen Sie, was sind die Attribute für jedes diejenigen, die Sie Messen möchten.

Being able to split jede dieser Maßnahmen zu zeigen, die Kosten von Fehlern nützlich sein würde - viele bug-fix Aufwand spät im Projekt bedeutet Kosten - /Zeitplan blowout.Lage, Profil, welche Teile der Codebasis sind buggy, könnte helfen, für zusätzliche Tests und code neu schreibt - in der Regel 80% der Fehler werden in 20% des Codes.Zu wissen, wo das ist, damit Ihr team besser zu konzentrieren.

BEARBEITEN:Blick auf Maßnahmen wie die Kosten für Qualität (CoQ) und Kosten Schlechter Qualität (CoPQ).

Maßnahmen wie Produktivität sind immer schwer zu quantifizieren sind - zum Beispiel mit LOC/Tag führt zu einer Debatte darüber, was genau ist ein code?Es kann auch zu dumm, code-Formatierung, um eine "boost" - Produktivität, wenn die Entwickler nicht verstehen, warum diese Dinge sind, die verfolgt werden oder wahrnehmen als persönliche Messungen.Auch wenn LOC/Tag wird nicht gemessen an der Entwickler-Ebene, Sie können immer noch team-Rivalität führt zu dem gleichen Ergebnis.

EDIT:Es gibt einige gute Gespräche auf Steve McConnell ' s Construx website.[Ja, das ist der Steve McConnell Code Abgeschlossen Ruhm]

Answer 5

Kein Prozess wird verbessern, was Sie tun, außer eigentlich immer alle zusammen und herauszufinden, was funktioniert und was nicht funktioniert.Für das team, ich bin derzeit führend, und wir tun dies durch eine Reihe von Retrospektiven (von denen würde ich sehr empfehlen, dieses Buch).Die teams in der Regel wissen, welche Bereiche Sie verbessern möchten - der trick ist, geben Sie die Ermächtigung zu Messen und zu verbessern diese Dinge.

Ja, Sie brauchen sicher noch jemanden, der sich auf der Makro-Ebene.Wenn Sie sich eine Organisation wie Toyota, Sie haben einen Chief Engineer, überspannt die Linie zwischen business und Produktion (für die gute Erklärung, siehe Scott Bellware s blog post).In unserer Organisation haben wir jemand ähnlich - mein Chef war einer der ersten Entwickler von unsere Produkt vor fast 20 Jahren, und bleibt sehr aktiv in der tech-Seite, aber stark investiert in die Kunden-Seite.Mein job ist auch die teams als ganzes zu Verbesserungen vorschlagen.

Zu Messen, müssen wir zunächst sicherstellen, dass alle Verbesserungen, die wir anstreben, sind Dinge, die unsere teams können tatsächlich ändern, und verwenden Sie dann so etwas wie der SMART-Ziele so, dass jegliche Verbesserungen messbar sind.Wir haben ein Große, Sichtbare Wand was wir posten, die Hinweise aus der Retrospektive auf.Dies geschieht auch, wo wir halten unsere tägliche stand-ups, so es gibt uns auf das fokussieren, was Los ist.

Zum aufrollen-Statistiken für unsere executive-Sitzungen konzentrieren wir uns auf die code-Lieferung - nicht Zeilen code geliefert.Ich habe absichtlich trat das team aus der Messung in nebulöse Einheiten was bedeutet, dass wir nicht berichten, dass wir arbeiteten x Anzahl der Stunden oder Tage, oder was auch immer.Was Sie sehen, ist ein Trend Diagramm, wie gut liefern wir unsere features und wie wir Sie verbessern.Wir werden auch interessante Leckerbissen, wenn das team glaubt, dass Sie wollen, es zu teilen.

Der beste Teil über all dies ist, dass wir versuchen können, die Dinge für einen Monat, und dann überarbeiten Sie es nur 4 Wochen später.Dies schafft eine viel niedrigere Eintrittsbarriere für neue Dinge zu versuchen, da das team weiß, dass, wenn es ist Auswirkungen auf Sie, wir werden entweder kündigen Sie es sofort, oder wir werden überarbeiten und bessere Wege finden, bei der nächsten Retrospektive.

Der schlechte Teil ist, dass es nicht genau das, was Sie suchen.Es ist nicht eine Metrische oder eine Reihe von Kennzahlen, die wir kontinuierlich verfolgen.Wir beobachten trends zu allen Zeiten, und Messen Sie die diejenigen, die wir denken, sind interessant - aber nur für ein wenig, und nur, wenn das team Sie erreichen ein bestimmtes Ziel, weil von Ihnen.Aber im Allgemeinen bin ich sehr zufrieden mit, wie es funktioniert, und ich habe gesehen, eine deutliche Verbesserung der Beteiligung der teams an der Verbesserung des Prozesses.Wir sind nicht ganz Kaizen, aber wir bekommen jeden Tag besser.

Answer 6

Ich habe Prozessverbesserung Professionell für 14 Jahre.Hier ist mein Rat, aufhören zu versuchen, zu quantifizieren und zu beginnen, mit Menschen zu reden.Die Messung funktioniert gut für ein bestimmtes problem (sobald Sie wissen, die problem, Sie haben eine bessere Idee, was zu Messen ist) und für repeatble Prozesse wie die Herstellung.Ihre Leute genau wissen, wo die Problemzonen sind, so machen Sie Ihren Kunden und Anwendern (aus einer ganz anderen Perspektive).Flow chart (use industrial engineering Symbole nicht computer-Programmierung Symbole), die die tatsächlichen Prozess für Bereiche, in denen es Bedenken(nicht das, was wir vorgeben der Prozess ist, die Sie brauchen, um zu beobachten, sowie Fragen zu stellen).Sobald Sie sehen, die ganze Strömung der Prozess Aussehen für Verzögerungen, Bereiche, in denen die Arbeit wird dupliziert, Bereiche, in denen es unnötig ist-Prozess (in der Regel durch hinzufügen weiterer Schritte, um den Prozess zu Konto für menschliche Fehler, daher schaffen viele weitere mögliche Bereiche für menschliche Fehler).Frage die Notwendigkeit, für jeden Schritt, und ob es einen besseren Weg, dies zu tun jeden Schritt.Testen Sie mögliche änderungen und sehen Sie, wenn in der Tat sind Sie ein imporvement (zu viele Male, die Sie machen die situation noch schlimmer, nicht besser).Nicht unter allen Umständen nur sprechen Führungskräfte, wenn Sie ein Gefühl für Probleme oder wenn flow-charting.Sie erhalten nicht das wahre Bild und werden damit zu lösen das falsche problem.

Answer 7

Verständnis Abfall-und Wert-stream-mapping wird Ihnen zeigen, wo Sie brauchen, um Verbesserungen zu machen, und von diesem wissen, werden Sie lernen, was Sie brauchen, um zu Messen.Prinzipien des Lean-und Kanban-bewerben Sie sich hier.Verständnis Abfall-und es ist Auswirkungen auf die Herstellung von software wird starten Sie den bestimmten Pfad zu Verbesserung, die ist unvermeidlich spezifisch für Ihre Organisation.Sie können nicht nehmen Sie ein cookie-cutter-Ansatz.Lesen (oder hören) "Ziel" und "Lean Thinking" für mehr über diese wirklich erstaunliche und aufschlussreiche Perspektive von dem, was falsch ist und wie es zu beheben.

Answer 8

Die beste Verwendung für Key-Performance-Indikatoren für fahren (oder Lenkung, wenn Ihr es vorziehen).Für Kurs-Korrekturen in Echtzeit.

(Siehe Dashboards sind für das Fahren für mehr sabbeln über dieses sub-Thema.VORBEHALT:Ich bin der Autor von den blathering Artikel.)

Also, die Frage an Sie zurück ist:sind Sie versuchen, Leistung zu bewerten nach der Tat, wenn es ist zu spät, um etwas dagegen zu tun, oder sind Sie versuchen zu finden, KPIs, die Ihnen helfen können bleiben Sie auf Kurs?

Wenn die ehemaligen, jede Metrik-Ihre Organisation kümmert sich um (Anzahl der Fehler, Schiff-Datum Schlupf, Zeilen von code mit Kommentare, Kunden Rückkehr Prozentsätze, etc.) wird in Ordnung sein.Messen Weg und viel Glück besser, zwischen Versand der Produkte und upgrades ;-)

Wenn letzteres, wählen Sie Geschwindigkeit.Vorausgesetzt, Sie sind mit test-driven development (TDD) natürlich.

EDIT:also, es ist der ehemalige.Nun, hier ist, warum Sie wahrscheinlich kein Glück:

Angenommen, Sie entscheiden, dass "Qualität" am besten ist quantifiziert durch Messung der Anzahl der Fehler die von Kunden gemeldet, als Sie Ihre post-Prozess-KPI.Nehmen wir an, dass Sie mit TDD, und sagen, dass Ihr team erzielt Produkt #1 in 6 Monaten und nach 6 Monaten in das Feld, das Sie finden, dass Sie 10 Kunden gemeldeten bugs.So, jetzt, auf was genau werden Sie tun, verbessern Sie Ihren Prozess?Mehr testen?Test speziell für weitere Dinge wie die Ursachen der Fehler, die gemeldet wurden?Es scheint mir, dass Sie schon testen und wenn Fehler entdeckt werden - sei es durch den Kunden oder nicht - fügen Sie eine regression test für die bestimmte Fehler und zusätzliche unit-tests, um sicherzustellen, dass es keine mehr ähnliche bugs.In anderen Worten, Ihre post-Prozess-Verbesserung Antwort wird nichts anderes als ein in-Prozess-Verbesserung Antwort, so dass diese KPI ist wirklich keine bedeutende Hilfe bei der Verbesserung Ihrer Prozesse.Der Punkt ist, dass die Art und Weise verbessern Sie Ihren Prozess bleibt der gleiche, unabhängig davon, ob der Fehler entdeckt werden 6 Monate nach release, ein oder zwei Tage in der Codierung.So, während Sie könnte dies ein glänzendes KPI, um auf einen manager der Wand oder in einer Abteilung newsletter, wird es wirklich nicht ändern Ihre Prozess-Verbesserung-Mechanismen.(Und Vorsicht, zu viel Lager in dieser KPI, denn es kann Wild durch Faktoren beeinflusst, die außerhalb Ihrer Kontrolle!).In kurzen, zu wissen, die Anzahl der bugs nicht helfen, Sie zu verbessern.

(Es gibt eine weitere Gefahr, die man hier Häufig nicht nur in der Wirtschaft sondern auch in das Militär, und das ist die illusion, dass die post-mortem-Analyse ergab wertvolle Informationen, damit die Lektionen gelernt, post-mortem sind energisch angewendet, um das nächste Projekt, das ist wahrscheinlich nicht das gleiche wie das Letzte Projekt.Dies ist bekannt als "Kampfhunde" der Letzte Krieg".)

Angenommen, die Zahl der Kunden, Rücksendungen/Rückerstattungen ist Ihre KPI der Wahl für die "Qualität" - ob diese Zahl ist 5, was sagt Sie?Die spezifischen Gründe, warum Kunden verlangten eine Rückerstattung kann einige Anzeichen von Qualität Probleme ("zu langsam", "nicht interface mit XYZ-system", etc.), aber die bloße Anzahl von solchen Vorfällen sagen Sie nichts.Eine Abweichung gegen eine erwartete Rendite Prozentsatz könnte Ihnen sagen, ob die Qualität verbessert, aber wieder die Anzahl nicht helfen, Sie zu verbessern.Sie benötigen mehr Informationen als die Anzahl können geben Sie.

Also für "die Aktualität der Veröffentlichungen", was die Messung angemessen wäre?Anzahl der Tage von Schiff Datum Schlupf?Prozent überrannt basierend auf der ursprünglichen Schätzungen? Es spielt keine Rolle,,, weil wieder die zahlen werden nicht helfen, Sie zu verbessern.

Wenn Sie Messen können, "Produktivität", nachdem das Produkt fertig ist, dann kann man wohl Messen, während sich das Produkt entwickelt wird (z.B.Geschwindigkeit), der Unterschied ist, dass die Produktivität weniger als erwartet, während der Entwicklung verbessert werden kann sofort, während insgesamt die Produktivität Zahl gemessen, nachdem die Entwicklung abgeschlossen ist, ist zu gross, zu durchschnittlich, um verwendet werden zu können.Man konnte nur Ahnen, warum Sie war niedriger als erwartet, 6 Monate später...

Ich habe keine Ahnung wie man das Messen könnte "Flexibilität", das klingt wie marketing-Fachsprache ;-)

Ich hoffe, ich habe nicht schlug der Nagel zu hart oder zu weit, aber ich glaube nicht, dass es etwas gibt, nützlich Sie können Messen Sie nach-der-Tatsache, dass man nicht Messen kann, während in progress.Und es gibt eine Menge von after-the-fact-Messungen, die nutzlos sind ohne die Kenntnis der Ursachen.

Answer 9

Sie erhalten viele Ideen über KPIs und Beispiele Dashboards am http://www.dashboardzone.com

Es hat kpis durch die Industrie-und Funktionsbereichen.