Die Geschichte der Transformation vom Produkt zum Projekt und umgekehrt (am Beispiel der Güte in der Region Moskau)

Seit dem Start von Dobrodel in der Region Moskau sind genau 5 Jahre vergangen. In den letzten fünf Jahren hat sich aus einem einfachen Projekt ein Produkt entwickelt. Und die Regierung der Region Moskau übertrug sie in Form einer einfachen nicht ausschließlichen Lizenz an die Region Uljanowsk. Link zu den News hier . Aber lassen Sie uns sehen, was etwas früher passiert ist, und die zyklische Natur und den Zen-Buddhismus im Produktmanagement diskutieren.



Als Direktor eines kleinen IT-Unternehmens habe ich mir das 2011 vom Sobyanin-Team gestartete Our City-Portal und das RosYama-Portal von Navalny angesehen. Ich habe die Idee, was besser gemacht werden kann, nicht losgelassen. So wurden das Projekt der AIST-Plattform und das Implementierungsprojekt der Plattform in Dubna „City 2.0“ in unserem Unternehmen geboren. Von AIST in 2014-2015 erschien Tugend. Über Ideologie und Technologie möchte ich in diesem Artikel ein wenig sprechen und damit den Projekt-Produkt-Projekt-Zyklus demonstrieren.

"Unsere Stadt" arbeitete für die Moskauer Regierung und ermöglichte es, kommunale Probleme schnell zu lösen und Appelle an hochrangige Beamte zu verteilen. Das RosYama-Portal warf sofort Probleme auf, Kontrollstellen und andere zuständige Abteilungen zu kontrollieren.

Navalny ging einen einfachen und erschwinglichen Weg. Nehmen Sie den Antrag aus dem Formular und senden Sie ihn in Form einer E-Mail per offizieller E-Mail an die Abteilung. Probleme wurden gelöst, aber die Frist betrug 30 Tage, und die Lösung blieb für diese 30 Tage oft nur auf dem Papier.

"Unsere Stadt" hat immer viel effizienter gearbeitet. Seit 2013 unterstützen wir Nutzer des Our City-Portals und verstehen die interne Küche dieses Systems. Ich bewundere immer noch die Architekten dieses Systems. Es gibt so viele interessante Dinge unter der Haube, die nicht beschrieben werden können. Das Frontalportal ist eher die Spitze des Eisbergs. Es wäre nicht realistisch, es nur in derselben Region Uljanowsk zu nehmen und einzusetzen (zumindest 2014). Es wäre notwendig, die gesamte Infrastruktur Moskaus aufzubauen. Und wir haben kein zweites Moskau in Russland.

2013 haben wir begonnen, eine Plattform für Java Spring + PostgreSQL mit einer BPM-Engine und einem GIS-Modul (auf demselben PostgreSQL) zu erstellen. Wir wollten eine elegante Midland-Lösung entwickeln, damit Design und Front schnell geändert werden können, um ein System zu erstellen, das „Our City“ in den Regionen ähnelt. Die Hauptfunktionen der Plattform waren: Verwalten von Benutzern, Rollen und Rechten, Einsprüchen, Kategorien von Einsprüchen, deren Weiterleitung, Geschäftsprozessen, es gab auch kein kompliziertes Geoinformationsmodul und keine Integrationsverwaltungsschicht (sowohl mit dem Frontportal als auch mit externen Systemen).



Alles wurde um einen Hauptprozess der Bearbeitung eines Antrags von einem Bewohner gemacht. Damit er sich anmeldet, wählt er die Art des Problems aus und wählt den Punkt auf der Karte aus, an dem sich dieses Problem befindet, und sendet den Aufruf zur Prüfung. Darüber hinaus gab es für jede Art von Problem einen Geschäftsprozess zur Lösung. Die Moderatoren betrachteten den formalen Teil. Unter Verwendung des GIS-Moduls wurden der Auftragnehmer für diesen Einspruch und die Regulierungsbehörde ermittelt. Befindet sich beispielsweise kein Wasser im Haus auf Bogolyubova 45, hat die Verwaltungsgesellschaft „Udomdom-Dubna“ diesen Einspruch eingelegt, ausgeführt und der Bewohner hat das Ergebnis der Arbeiten akzeptiert. Wenn das Unternehmen die Frist nicht einhielt, wurde die Beschwerde an die Aufsichtsbehörde - die Wohnungsinspektion - weitergeleitet.



Es sah aus wie der Hauptbildschirm, nichts weiter, ging hinein, schrie und ging. Außerdem würden Benachrichtigungen per Post und Telefon über eine Änderung des Status der Anwendung eingehen.

Die Hauptidee dieses Projekts war es, die Verwaltung vom routinemäßigen Prozess der Bearbeitung von Beschwerden von Anwohnern auszuschließen. Alles sollte wie eine Uhr für sich funktionieren. Schließlich hat jedes Problem seine eigene Verantwortung, und in der Regel ist dies nicht die Verwaltung, auch wenn es sich um städtisches Eigentum handelt. All dies sind Auftragnehmer oder Verwaltungsgesellschaften. Und es gibt nicht so viele Kontrolleure: 90% der Stadtprobleme werden von der Verwaltung der technischen Aufsicht und der Wohnungsinspektion kontrolliert.



Wir haben versucht, die bequemste Oberfläche einfach und unkompliziert zu gestalten.

Die Ergebnisse des Piloten bei der Nutzung der Plattform in Dubna wurden als erfolgreich anerkannt. Wir erhielten 2014 den Gouverneurspreis „Unsere Region Moskau“ bei der Nominierung für die öffentliche Kontrolle und danach wurde Dobrodel 2015 gestartet. AIST war eine Plattform und wir wollten sie an andere Regionen verkaufen. Wir haben sie zunächst als Produkt gebaut. Nach dem Start von Virtue löste sich die Plattform darin auf. Das Niveau der Aufgaben, Anforderungen und Integrationen hat sich mehrfach erhöht. Es stellte sich heraus, dass wir nicht einmal darüber nachgedacht haben. Wie zum Beispiel ein schneller Speicherverlust unter Java unter Last oder wie man die Verantwortlichkeitskarte der Verwaltungsgesellschaften auf dem neuesten Stand hält. In der Region ändern sich ihre Grenzen jeden Tag. Eine manuelle Wartung ist jedoch nicht möglich.Zu dieser Zeit gab es keine automatisierten Mittel, um Verantwortungsbereiche zu entdecken, und infolgedessen wandte sich Dobrodel von einem Anrufrouter an die Stadtverwaltung, und sein Hauptziel, die Routine für Beamte zu reduzieren, wurde ernsthaft verändert. In diesen fünf Jahren hat sich das Projekt unter der Leitung des Teams der Region Moskau erfolgreich entwickelt. Ich bin sicher, dass viele Probleme gelöst wurden und ihre Erfahrungen nun erfolgreich in anderen Bereichen angewendet werden können. Und hier ist wieder das Produkt. Wir fangen Zen, alles ist zyklisch.

Dies war nicht der einzige Ansatz für das Projektil. Jetzt entwickeln wir unsere AIOps-Plattform zur Überwachung der Leistung von IT-Services und Geschäftsprozessen sowie zum automatisierten Incident Management ( mehr zur MONQ-Plattform hier) Zuerst haben wir damit begonnen, einen einfachen Dialer für Vorfälle ähnlich wie PagerDuty für den internen Gebrauch zu erstellen (es war 2014), dann wurde daraus eine Fusion und ein Megadashboard zum Sammeln von Daten aus Dutzenden von Zabbixes und eine Plattform zum Steuern des Starts von Autotests, um Daten über die Funktionsweise von Geschäftsdiensten zu verbinden durch die Augen der Benutzer und Daten über den Zustand der Infrastruktur. Wir haben zuerst mit der Herstellung des Produkts begonnen, dann den ersten ernsthaften Kunden gefunden und uns 2 Jahre lang in ein Projekt verwandelt, das sich zu 100% für die Bedürfnisse dieses Kunden einsetzt. 2017 haben wir die erste Lizenz an einen anderen Kunden verkauft und sind schließlich wieder das Produkt geworden. Dann gab es finanzielle Probleme und wir gingen wieder in die Projektabhängigkeit, nahmen ernsthafte Umgestaltungen vor, veröffentlichten neue Funktionen, wechselten in ein anderes Marktsegment und jetzt sind wir wieder ein Produkt.Die Ausgewogenheit des Produktprojekts ist meiner Meinung nach ein sehr akutes Problem.

Bei Interesse kann ich Ihnen im nächsten Artikel sagen, wie MONQ geboren wurde.