Wie wir Ideen für die Entwicklung unserer Produkte auswählen: Der Anbieter muss hören können...

In diesem Artikel teile ich meine Erfahrungen bei der Auswahl von Ideen zur Entwicklung der Funktionalität unserer Produkte und erkläre Ihnen, wie Sie die wichtigsten Entwicklungsvektoren beibehalten.

Wir entwickeln ein automatisiertes Abrechnungssystem (ACP) - Abrechnung. Begriff
Die Lebensdauer unseres Produkts beträgt 14 Jahre. In dieser Zeit hat sich das System von den ersten Versionen eines Industrietarifsystems zu einem modularen Komplex bestehend aus 18 sich ergänzenden Produkten entwickelt. Einer der wichtigsten Aspekte der Langlebigkeit von Programmen ist die ständige Weiterentwicklung. Und Entwicklung braucht Ideen.

Ideen

Quellen

Es gibt 5 Quellen:

1. Der Hauptfreund eines Entwicklers von Unternehmensinformationssystemen ist Client. Und der Kunde ist ein kollektives Bild von Entscheidungsträgern, Projektsponsoren, Eigentümern und Ausführenden von Prozessen, internen IT-Spezialisten, normalen Benutzern und einer großen Anzahl interessierter Personen in unterschiedlichem Maße. Es ist uns wichtig, dass jeder Vertreter des Kunden potenzieller Ideengeber ist. Im schlimmsten Fall erhalten wir nur negative Rückmeldungen zu Problemen im System. Im besten Fall gibt es auf der Seite des Kunden eine Person, die ständig Ideen für Verbesserungen liefert und strukturiert über die Bedürfnisse des Kunden informiert.
2. Unsere Vertriebsmitarbeiter und Account Manager sind die zweitwichtigste Quelle für Verbesserungsideen. Sie kommunizieren aktiv und umfassend mit Branchenvertretern und erhalten Anfragen potenzieller Kunden zu Abrechnungsfunktionen aus erster Hand. Verkäufer und Kunden müssen über alle wesentlichen Änderungen ihrer Funktionalität und die neuesten Updates der Software der Wettbewerber informiert sein und in der Lage sein, die Vor- und Nachteile verschiedener Lösungen zu begründen. Dies sind unsere Mitarbeiter, die als Erste spüren, ob einige Abrechnungsfunktionen zum De-facto-Standard werden, ohne die die Software nicht als vollständig betrachtet werden kann.
3. Produktinhaber — einer unserer Top-Manager oder ein sehr erfahrener Projektmanager. Behält die strategischen Ziele des Unternehmens im Auge und passt die Produktentwicklungspläne entsprechend an.
4. Architekt, eine Person, die die Fähigkeiten und Grenzen der gewählten/verwendeten Technologielösungen und deren Auswirkungen auf die Produktentwicklung versteht.
   Entwicklungs- und Testteams. Personen, die direkt an der Produktentwicklung beteiligt sind.

Klassifizierung von Anfragen

Wir erhalten Rohdaten aus Quellen – Briefe, Tickets, mündliche Anfragen. Alle
Einsprüche werden klassifiziert:

• Beratungen mit der Bedeutung „Wie macht man das?“, „Wie funktioniert es?“, „Warum funktioniert es nicht?“, „Ich verstehe nicht…“. Anfragen dieser Art gehen an die Level 1 Support Line. Es ist möglich, die Beratung auf andere Arten von Anfragen umzuschulen.
• Vorfälle mit der Bedeutung „Funktioniert nicht“ und „Fehler“. Wird von 2 und 3 Support-Hotlines bearbeitet. Sollten zeitnahe Korrekturen und die Veröffentlichung eines Patches erforderlich sein, können diese vom Support direkt in die Entwicklung übernommen werden. Es besteht die Möglichkeit, ihn als Änderungsantrag umzuklassifizieren und an das Backlog zu senden.
• Änderungs- und Weiterentwicklungswünsche. Sie gelangen in das Produkt-Backlog und umgehen die Support-Linien. Für sie gibt es jedoch ein gesondertes Verarbeitungsverfahren.

Es gibt Statistiken zu Anfragen: Unmittelbar nach der Veröffentlichung steigt die Anzahl der Anfragen kurzfristig um 10-15 %. Es kommt auch zu einem Anstieg der Anfragen, wenn ein neuer Kunde mit einer großen Anzahl von Benutzern zu unseren Cloud-Diensten kommt. Menschen lernen, neue Softwarefunktionen zu nutzen, sie brauchen Rat. Selbst ein kleiner Kunde verbrennt, wenn er mit der Arbeit im System beginnt, leicht mehr als 100 Beratungsstunden pro Monat. Deshalb reservieren wir bei der Anbindung eines neuen Kunden immer Zeit für Erstgespräche. Oftmals wählen wir sogar einen bestimmten Spezialisten aus. Der Mietpreis deckt diese Arbeitskosten natürlich nicht ab, aber mit der Zeit gleicht sich die Situation aus. Die Eingewöhnungszeit beträgt in der Regel 1 bis 3 Monate, danach ist der Beratungsbedarf deutlich geringer.

Bisher nutzten wir selbstgeschriebene Lösungen zur Speicherung von Anfragen. Aber wir sind nach und nach auf Atlassian-Produkte umgestiegen. Zuerst haben wir die Entwicklung verlagert, um das Agile-Arbeiten zu erleichtern, dann den Support. Jetzt leben alle kritischen Prozesse in Jira SD und werden durch verschiedene Plugins für Jira sowie Confluence unterstützt. Selbstgeschriebene Lösungen blieben nur für Prozesse übrig, die für die Unternehmensaktivitäten nicht kritisch waren. Es stellt sich heraus, dass unsere Aufgaben nun bereichsübergreifend sind und zwischen Support und Entwicklung übertragen werden können, ohne von einem System zum anderen zu springen.

Über diesen Link können wir Daten zu allen Aufgaben, geplanten und tatsächlichen Arbeitskosten abrufen, verschiedene Preisoptionen für Kunden nutzen und Dokumentationen für interne Bedürfnisse und Berichte an Kunden erstellen.

Bearbeitung von Änderungswünschen

Typischerweise kommen solche Anfragen in Form von Funktionalitätsanforderungen. Unser Analyst untersucht die Anfrage, erstellt eine Spezifikation und technische Spezifikationen auf höchstem Niveau. Übergibt die Spezifikation und die technischen Spezifikationen an die Person, die diese Anfrage zur Genehmigung eingereicht hat – wir müssen sicherstellen, dass wir mit dem Kunden die gleiche Sprache sprechen.

Nachdem der Analyst vom Kunden die Bestätigung erhalten hat, dass wir uns richtig verstanden haben, trägt er die Anfrage in das Product Backlog ein.

Produktfunktionalitätsmanagement

Im Backlog werden eingehende Änderungs- und Entwicklungsanfragen gesammelt. Der technische Rat, bestehend aus dem Direktor, den Leitern Support, Entwicklung, Vertrieb und dem Systemarchitekten, trifft sich alle sechs Monate. In einem Diskussionsformat analysiert und priorisiert der Rat Anwendungen aus dem Backlog und einigt sich auf 5 Entwicklungsaufgaben zur Umsetzung im nächsten Release.

Tatsächlich reagiert der Technische Rat auf Branchen- und Marktanforderungen, indem er die in den Anwendungen zum Ausdruck gebrachten Bedürfnisse überprüft. Alles, was wenig relevant ist, bleibt im Backlog und gelangt nicht in die Entwicklung.

Klassifizierung von Änderungswünschen und Finanzen

Entwicklung ist teuer. Deshalb teilen wir Ihnen umgehend mit, welche Möglichkeiten wir haben, wenn der Änderungswunsch von einem Kunden und nicht von einem Mitarbeiter kommt.

Wir klassifizieren Änderungswünsche wie folgt: Branchenbedarf oder individuelle Merkmale des Unternehmens; eine erhebliche Menge neuer Funktionen oder eine kleinere Korrektur. Kleinere Reparaturen und individuelle Wünsche werden ohne viel Schnickschnack bearbeitet. Im Rahmen der Projektarbeit mit ihm werden individuelle Wünsche für einen konkreten Kunden kalkuliert und umgesetzt.

Wenn es sich hierbei nicht um einen massiven Branchenbedarf handelt und der Funktionsumfang groß ist, kann die Entscheidung getroffen werden, ein neues separates Modul zu entwickeln, das zusätzlich zur Hauptfunktionalität verkauft wird. Wenn ein solcher Antrag von einem Kunden eingeht, können wir die Kosten für die Entwicklung des Moduls übernehmen, dem Kunden das Modul kostenlos oder gegen Teilzahlung zur Verfügung stellen und das Modul selbst zum Verkauf anbieten. In einer solchen Situation übernimmt der Kunde einen Teil der methodischen Belastung und führt im Wesentlichen eine Pilotimplementierung des Moduls bei sich selbst durch.

Wenn es sich hierbei um einen massiven Branchenbedarf handelt, kann die Entscheidung getroffen werden, neue Funktionen in das Basisprodukt aufzunehmen. Die Kosten gehen in diesem Fall vollständig zu unseren Lasten und die neue Funktionalität erscheint in der aktuellen Version der Programme.
Altkunden erhalten ein Update.

Es kann auch sein, dass mehrere Kunden ein ähnliches Bedürfnis haben, es sich aber nicht um ein Massenprodukt handelt. In diesem Fall können wir die Spezifikation an diese Kunden senden und anbieten, die Entwicklungskosten zwischen ihnen aufzuteilen. Am Ende gewinnen alle: Kunden erhalten Funktionalität zu geringen Kosten, wir bereichern das Produkt und nach einiger Zeit können auch andere Marktteilnehmer die Funktionalität für ihre Nutzung erhalten.

DevOps

Die Entwicklung bereitet zwei Hauptveröffentlichungen pro Jahr vor. In jeder Veröffentlichung ist Zeit für die Umsetzung von 5 vom Technischen Rat erhaltenen Aufgaben reserviert. Deshalb vergessen wir im Alltag nie die Produktentwicklung.

Jede Version durchläuft eine entsprechende Reihe von Tests und Dokumentationen. Anschließend wird dieses Release in der Testumgebung des entsprechenden Kunden installiert, der wiederum alles akribisch prüft und erst danach das Release in die Produktion überführt.

Zusätzlich zum Release-System gibt es ein Format für schnelle Fehlerbehebungen, damit Kunden nicht sechs Monate lang mit Fehlern leben müssen. Dieses Zwischenformat ermöglicht es Ihnen, schnell auf Vorfälle erster Priorität zu reagieren und die angegebenen SLAs zu erfüllen.

All das gilt vor allem für den Unternehmensbereich und On-Premise-Lösungen. Bei Cloud-Diensten, die sich an das KMU-Segment richten, gibt es keine derart breiten Möglichkeiten für Kunden, sich an der Produktentwicklung zu beteiligen. Das SMB-Mietformat geht davon nicht einmal aus. Anstelle eines Änderungswunsches in Form klarer Anforderungen seitens der Unternehmenspartei gibt es hier nur gewöhnliche Rückmeldungen und Wünsche zur Leistung. Wir versuchen zuzuhören, aber das Produkt ist riesig und der Wunsch eines Kunden, etwas Vertrautes aus seinem alten historischen System mitzubringen, kann der Entwicklungsstrategie des Systems als Ganzes widersprechen.

Source: habr.com