In diesem Artikel werde ich meine Erfahrungen bei der Auswahl von Ideen zur Entwicklung der Funktionalität unserer Produkte teilen und Ihnen erklären, wie Sie die wichtigsten Entwicklungsvektoren beibehalten.
Wir entwickeln ein automatisiertes Abrechnungssystem (ASR) - die Abrechnung. Laufzeit
Die Lebensdauer unseres Produkts beträgt 14 Jahre. In dieser Zeit hat sich das System von den ersten Versionen der Industrietarifierung zu einem modularen Komplex entwickelt, der aus 18 Produkten besteht, die sich gegenseitig ergänzen. Einer der wichtigsten Aspekte einer langen Lebensdauer von Programmen ist die kontinuierliche Weiterentwicklung. Und für die Entwicklung werden Ideen benötigt.
Ideen
Quellen
Es gibt 5 Quellen:
- Der Hauptfreund des Entwicklers von Unternehmensinformationssystemen ist der Kunde . Und der Kunde ist ein kollektives Bild von Entscheidungsträgern, Projektsponsoren, Prozessverantwortlichen und Führungskräften, IT-Spezialisten, normalen Benutzern und einer großen Anzahl unterschiedlich interessierter Personen. Für uns ist es wichtig, dass jeder Vertreter des Kunden potenziell ein Lieferant von Ideen ist. Im schlimmsten Fall erhalten wir nur negative Rückmeldungen zu Problemen im System. Bestenfalls gibt es auf Kundenseite eine Person, die eine ständige Quelle für Verbesserungsvorschläge ist und strukturierte Informationen über die Bedürfnisse des Kunden liefert.
- Unsere Verkäufer und Kundenbetreuer sind die zweitwichtigste Quelle für Verbesserungsvorschläge. Sie kommunizieren viel mit Branchenvertretern und erhalten aktiv Anfragen aus erster Hand nach Abrechnungsfunktionen von potenziellen Kunden. Verkäufer und Kunden müssen sich aller wesentlichen Änderungen ihrer Funktionalität und der neuesten Software-Updates der Wettbewerber bewusst sein, um die Vor- und Nachteile verschiedener Lösungen rechtfertigen zu können. Es sind diese unsere Mitarbeiter, die als erste das Gefühl haben, dass einige Abrechnungsfunktionen zu einem De-facto-Standard werden, ohne den die Software nicht als vollständig angesehen werden kann.
- Der Product Owner ist einer unserer Top-Manager oder ein sehr erfahrener Projektmanager. Er berücksichtigt die strategischen Ziele des Unternehmens und passt die Pläne für die Produktentwicklung entsprechend an.
- Ein Architekt , eine Person, die die Möglichkeiten und Grenzen der ausgewählten / verwendeten technologischen Lösungen und ihre Auswirkungen auf die Produktentwicklung versteht.
Entwicklung, Testteams. Menschen, die direkt an der Produktentwicklung beteiligt sind.
Einstufung von Rechtsbehelfen
Aus Quellen erhalten wir Rohdaten - Briefe, Tickets, mündliche Anfragen. Alle
Beschwerden werden klassifiziert:
- Konsultationen mit der Bedeutung von "Wie geht das?", "Wie funktioniert es?", "Warum funktioniert es nicht?", "Ich verstehe nicht ...". Diese Art von Anruf geht an die Level 1 Support Line. Mögliche Neuqualifizierung der Konsultation bei anderen Arten von Anträgen.
- Vorfälle mit der Bedeutung von "Funktioniert nicht" und "Fehler". Behandelt von 2 und 3 Support Lines. Bei Bedarf kann eine schnelle Korrektur und Freigabe des Patches vom Support sofort auf die Entwicklung übertragen werden. Es ist möglich, eine Änderungsanforderung erneut zu trainieren und an das Backlog zu senden.
- Änderungs- und Entwicklungswünsche . Gehen Sie unter Umgehung der Support-Zeilen in das Produkt-Backlog. Für sie gibt es jedoch ein separates Verarbeitungsverfahren.
Es gibt solche Statistiken über Beschwerden - unmittelbar nach der Veröffentlichung steigt die Anzahl der Beschwerden für kurze Zeit um 10-15%. Außerdem kommt es zu Anrufausbrüchen, wenn ein neuer Client mit einer großen Anzahl von Benutzern zu unseren Cloud-Diensten kommt. Die Menschen lernen, die neuen Funktionen von Software zu nutzen, sie brauchen Beratung. Selbst ein kleiner Kunde zu Beginn der Arbeit im System verbrennt leicht mehr als 100 Stunden Konsultationen pro Monat. Daher behalten wir uns bei der Verbindung eines neuen Kunden immer Zeit für erste Konsultationen vor. Oft heben wir sogar einen bestimmten Spezialisten hervor. Die Mietkosten zahlen diese Arbeitskosten natürlich nicht zurück, aber im Laufe der Zeit wird die Situation ausgeglichen. Die Anpassungszeit beträgt in der Regel 1 bis 3 Monate, dann wird der Beratungsbedarf deutlich reduziert.
Bisher haben wir selbstgeschriebene Lösungen zum Speichern von Anrufen verwendet. Aber allmählich auf Atlassian Produkte umgestellt. Zuerst haben wir die Entwicklung entwickelt, um die Arbeit an Agile und dann den Support zu vereinfachen. Jetzt leben alle kritischen Prozesse in Jira SD und werden von verschiedenen Plugins für Jira plus Confluence bereitgestellt. Selbstgeschriebene Lösungen blieben nur für Prozesse, die für die Aktivitäten des Unternehmens nicht kritisch waren. Es stellte sich heraus, dass unsere Aufgaben jetzt übergreifend sind und zwischen Support und Entwicklung übertragen werden können, ohne von einem System zum anderen zu springen.
Aus diesem Paket können wir Daten zu allen Aufgaben, geplanten und tatsächlichen Arbeitskosten abrufen, verschiedene Tarifoptionen für Kunden verwenden und Dokumentationen für interne Bedürfnisse erstellen und Kunden Bericht erstatten.
Änderungsanforderungsverarbeitung
Typischerweise kommen solche Anforderungen in Form von funktionalen Anforderungen. Unser Analyst untersucht die Anfrage, generiert eine Spezifikation und einen ToR auf höchster Ebene. Sie gibt die Spezifikation und die Arbeitserklärung an die Person weiter, die diesen Antrag auf Genehmigung gestellt hat. Wir müssen sicher sein, dass wir mit dem Kunden dieselbe Sprache sprechen.
Nachdem der Kunde die Bestätigung erhalten hat, dass wir uns richtig verstanden haben, schreibt er die Anfrage in das Product Backlog.
Produktmanagement
Der Rückstand sammelt eingehende Änderungs- und Entwicklungsanforderungen. Alle sechs Monate wird ein technischer Rat einberufen, der sich aus einem Direktor, Managern für Wartung, Entwicklung, Vertrieb und Systemarchitekten zusammensetzt. Im Diskussionsformat analysiert und priorisiert das Board Anwendungen aus dem Backlog und koordiniert 5 Entwicklungsaufgaben für die Implementierung in der nächsten Version.
Tatsächlich reagiert der technische Rat auf die Anforderungen der Branche und des Marktes unter Berücksichtigung der in den Anträgen erfassten Anforderungen. Alles, was wenig relevant ist, bleibt im Rückstand und erreicht nicht die Entwicklung.
Klassifizierung von Änderungswünschen und Finanzen
Entwicklung ist teuer. Daher werden wir Ihnen umgehend mitteilen, welche Optionen wir haben können, wenn die Änderungsanforderung von einem Kunden und nicht von einem Mitarbeiter stammt.
Änderungsanforderungen werden wie folgt klassifiziert: Branchenanforderungen oder individuelle Merkmale des Unternehmens; erhebliche Menge an neuen Funktionen oder kleinen Korrekturen. Kleine Korrekturen und individuelle Anfragen werden ohne Schnickschnack bearbeitet. Einzelne Anfragen werden für einen bestimmten Kunden im Rahmen der Projektarbeit mit ihm berechnet und umgesetzt.
Wenn dies kein massiver Bedarf der Branche ist 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 eine solche Anfrage vom Kunden eingeht, können wir die Kosten für die Entwicklung des Moduls übernehmen, dem Kunden das Modul kostenlos oder mit Teilzahlung zur Verfügung stellen und das Modul zum öffentlichen Verkauf anbieten. Der Kunde übernimmt in einer solchen Situation einen Teil der methodischen Belastung und führt im Wesentlichen die Pilotimplementierung des Moduls durch.
Wenn dies ein massiver Bedarf der Branche ist, kann die Entscheidung getroffen werden, neue Funktionen in das Basisprodukt aufzunehmen. Die Kosten in diesem Fall liegen vollständig bei uns und die neue Funktionalität erscheint in der aktuellen Version der Programme.
Alte Kunden erhalten ein Update.
Es kann auch sein, dass mehrere Kunden einen ähnlichen Bedarf haben, aber es zieht kein Massenprodukt an. In diesem Fall können wir die Spezifikation an diese Kunden senden und anbieten, die Entwicklungskosten zwischen ihnen zu teilen. Dadurch gewinnt jeder: Kunden erhalten die Implementierung der Funktionalität zu geringen Kosten, wir bereichern das Produkt, nach einer Weile können die verbleibenden Marktteilnehmer auch die Funktionalität für ihre Nutzung erhalten.
Devops
Die Entwicklung bereitet zwei Hauptversionen pro Jahr vor. In jeder Version ist Zeit für die Ausführung von 5 Aufgaben reserviert, die vom Technischen Rat erhalten wurden. Daher vergessen wir für die Flüssigkeit nie die Entwicklung des Produkts.
Jede Version besteht eine entsprechende Reihe von Tests und Dokumentationen. Darüber hinaus wird diese Version in der Testumgebung des entsprechenden Kunden installiert, der seinerseits alles akribisch überprüft und erst danach in die Produktion übersetzt wird.
Zusätzlich zum Release-System gibt es ein Format für schnelle Fehlerbehebungen, damit Clients sechs Monate lang nicht mit Fehlern leben. Mit diesem Zwischenformat können Sie schnell auf Vorfälle erster Priorität reagieren und die deklarierte SLA erfüllen.
All dies gilt in erster Linie für den Unternehmenssektor und für On-Premise-Lösungen. Für Cloud-Services, die sich auf das SMB-Segment konzentrieren, gibt es für Kunden keine derart breiten Möglichkeiten, sich an der Entwicklung des Produkts zu beteiligen. Das Leasingformat für KMU schlägt dies nicht einmal vor. Anstelle einer Änderungsanforderung in Form klarer Anforderungen der Unternehmenspartei finden Sie hier nur das übliche Feedback und die Wünsche für den Service. 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 gesamten Systems widersprechen.