Ich bin fest davon überzeugt und bin oft überrascht und enttäuscht, dass immer mehr Unternehmen funktionale Größenmaße implementieren.
Produktivität ist ein Konzept, das von Regierungen auf nationaler Ebene bis hin zu einzelnen Unternehmen breit diskutiert wird, in allen Branchen, in denen Waren hergestellt oder Dienstleistungen erbracht werden. Für die Zwecke dieser Diskussion, ich nehme Produktivität bezeichnet die Menge an Ressourcen, die für die Produktion einer Produktionseinheit verbraucht werden. Der Schlüssel hier ist, dass es einen Output gibt, der identifiziert und gezählt werden kann, um ihn mit der verwendeten Ressource zu vergleichen.
Unternehmensleiter und Leiter von Regierungsabteilungen verlangen regelmäßig, dass ihre Organisationen die Produktivität jedes Jahr verbessern, zum Beispiel, Mit der gleichen Menge an Ressourcen mehr Output oder mit weniger Ressourcen den gleichen Output erzeugen. Sie sind auch an der Leistung ihrer Organisation im Vergleich zu anderen vergleichbaren Unternehmen interessiert, mit denen sie konkurrieren.
Die IT-Branche ist nicht anders. Beispiele hierfür sind Dienstleistungsanbieter, die Wettbewerbsfähigkeit unter Beweis stellen müssen, um Aufträge zu gewinnen, Interne IT-Abteilungen müssen nachweisen, dass sie mit den ihnen zugewiesenen Budgets mehr für das Unternehmen leisten, und Finanzvorstände müssen sicherstellen, dass Outsourcing-Verträge dem Unternehmen echte Vorteile bringen, nicht nur ein günstigerer Arbeitslohn.
Im Bereich der Softwareentwicklung, Codezeilen wurden als Maß für die erzeugte Ausgabe verwendet, aber mit der Einführung moderner Entwicklungstechniken und -tools ist dies in den meisten modernen Umgebungen kein nützliches Maß mehr.
Eine nützlichere Technik besteht darin, den Output eines Softwareentwicklungsprojekts anhand der Menge an Funktionalität zu messen, die es dem Kunden bietet, unabhängig von der verwendeten Technologie/Plattform/Entwicklungsmethodik. Dazu benötigt man eine standardisierte, Wiederholbare Methode zur Identifizierung und Bewertung der gelieferten Geschäftsfunktionen und damit zur Ableitung eines numerischen Werts für die Größe der gelieferten Software.
Einige der wichtigsten Erkenntnisse aus der Implementierung von Functional Sizing sind::
Messen Sie, was Sie tun, und verbessern Sie es dann
- Wenn Sie nicht über eine Basislinie der aktuellen Leistung verfügen, wird es nicht möglich sein, ein Verbesserungsprogramm zu verwalten. Ich habe Manager mehrmals sagen hören: „Wir wollen die Produktivität steigern.“ 10% pro Jahr“, aber sie wussten nicht, wie hoch die aktuelle Leistung war. Ebenfalls, Sie müssen wissen, ob die aktuelle Leistung gut ist, durchschnittlich oder schlecht. Je nachdem wo man steht, Sie können verstehen, wenn Sie sich verbessern müssen, und wenn, Wie viel wäre realistisch?. Die ISBSG-Daten können Ihnen dabei helfen.
Verstehen Sie Ihre Daten und ergreifen Sie Maßnahmen.
- Messungen sind von geringem Wert, es sei denn, sie dienen dazu, Maßnahmen aufzuzeigen, die zur Verbesserung ergriffen werden können. Daher ist ein Prozess der „Ursachenanalyse“ erforderlich, um die Attribute/Faktoren/Ereignisse zu verstehen, die zur Leistung jedes einzelnen Projekts geführt haben.
- Seien Sie vorsichtig mit dem „dreibeinigen Schemel“ der Kosten, Qualität und Zeitplan. Sie sind alle voneinander abhängig und sollten nicht isoliert verwaltet werden.
Vorsicht vor Datenmissbrauch
- Ich habe es einmal gehört 2 Führungskräfte prahlen mit der Leistung ihrer IT-Abteilungen mithilfe von Hours/Function Point. Sie stammten von Unternehmen aus unterschiedlichen Branchen mit deutlich unterschiedlichen Geschäftsbereichen, sodass ein solcher Vergleich nahezu bedeutungslos ist
- Es besteht die Gefahr einer übermäßigen Vereinfachung. Denn Projekte, auch in ähnlichen Bereichen, wird zu unterschiedlichen Ergebnissen führen, Um die Ergebnisse richtig zu verstehen, sind einige grundlegende statistische Analysen erforderlich, die über reine Durchschnittswerte hinausgehen.
Zusammenhang mit Aufwand
- Die Verwendung der funktionalen Größe zur Messung der Produktivität oder zur Schätzung setzt voraus, dass eine ausreichende Korrelation zwischen der Größe und dem Aufwand besteht. Nicht alle Aufgaben erfordern einen direkt proportionalen Funktionsumfang, Daher müssen sie möglicherweise aus der Produktivitätsberechnung entfernt und separat behandelt werden
Stunden/FP oder $/FP
Einige definieren Produktivitätsaufwand/Ausgabeeinheit, während andere Kosten bevorzugen / Ausgabeeinheit. Jede Metrik hat ihren Wert, da oft ein Zusammenhang zwischen der Arbeitsquote und der Anzahl der Stunden besteht, die für die Erledigung einer Aufgabe benötigt werden. Ich empfehle, beides zu verwenden.
Mich würden Eure Erfahrungen interessieren (gut und schlecht) und insbesondere Gründe, warum Sie kein Functional Sizing implementiert haben. Bitte kontaktiere mich unter john.ogilvie@isbsg.org wenn Sie interessiert sind.
Über den Autor
John Ogilvie ist CEO der Internationale Gruppe für Software-Benchmarking-Standards.
Was Sie als das beschreiben “dreibeinger Hocker” der Kosten, Qualität und Zeitplan sind meiner Erfahrung nach der Grund, warum viele Messprogramme scheitern. Es gelingt ihnen nicht, die drei miteinander in Beziehung zu setzen und sie zu verwalten – oder noch schlimmer – nur in herrlicher Isolation kosten. Wenn Sie sich nur auf die Kosten konzentrieren, erhalten Sie möglicherweise eine sehr effiziente Softwareentwicklung, die nicht das liefert, was ein Unternehmen von seinem IT-Portfolio benötigt. Jedes Messprogramm sollte im Mittelpunkt stehen “die richtigen Sachen machen” Erste, vor dem Anschauen “Dinge richtig machen”. Das bedeutet Qualität an erster Stelle, dann planen und dann kosten. Ich habe viele Unternehmen kennengelernt, die es umgekehrt machen und dann scheitern.