La historia de la transformación de producto a proyecto y viceversa (utilizando el ejemplo de la bondad en la región de Moscú)

Desde el lanzamiento de Dobrodel en la región de Moscú, han pasado exactamente 5 años. En los últimos cinco años, un proyecto simple se ha convertido en un producto. Y el Gobierno de la Región de Moscú en forma de una simple licencia no exclusiva lo transfirió a la Región de Uliánovsk. Enlace a las noticias aquí . Pero veamos qué sucedió un poco antes y discutamos la naturaleza cíclica y el budismo zen en la gestión de productos.



Como director de una pequeña empresa de TI, miré el portal Our City, lanzado en 2011 por el equipo de Sobyanin y el portal RosYama de Navalny. No abandoné la idea de lo que se puede hacer mejor. Entonces, el proyecto de la plataforma AIST y el proyecto de implementación de la plataforma en Dubna "City 2.0" nacieron en nuestra empresa. De AIST en 2014-2015, apareció Virtue. Sobre ideología y tecnología, me gustaría hablar un poco en este artículo y demostrar así el ciclo proyecto-producto-proyecto.

"Nuestra Ciudad" trabajó para el Gobierno de Moscú e hizo posible resolver rápidamente los problemas comunales, dispersando los llamamientos a los altos funcionarios. El portal RosYama arrojó problemas a la vez para controlar organismos y otros departamentos responsables.

Navalny siguió un camino simple y asequible. Tome la solicitud del formulario y envíela en forma de correo electrónico al departamento por correo electrónico oficial. Los problemas se resolvieron, pero la fecha límite era de 30 días, y la solución a menudo permaneció durante estos 30 días solo en papel.

"Nuestra ciudad" siempre ha trabajado de manera mucho más eficiente. Desde 2013, hemos estado apoyando a los usuarios del portal Our City y entendemos la cocina interna de este sistema. Todavía admiro a los arquitectos de este sistema. Hay tantas cosas interesantes debajo del capó que no se pueden describir. El portal frontal es más bien la punta del iceberg. Solo tomarlo y desplegarlo en la misma región de Ulyanovsk no sería realista (al menos en 2014). Sería necesario construir toda la infraestructura de Moscú. Y no tenemos un segundo Moscú en Rusia.

En 2013, comenzamos a hacer una plataforma en Java Spring + PostgreSQL con un motor BPM y un módulo SIG (en el mismo PostgreSQL). Queríamos hacer una solución elegante de midland para que fuera posible cambiar rápidamente el diseño y el frente para construir un sistema similar a "Nuestra Ciudad" en las regiones. Las funciones principales de la plataforma fueron: administrar usuarios, roles y derechos, apelaciones, categorías de apelaciones, su enrutamiento, procesos comerciales, tampoco había un módulo de información geográfica complicado y una capa de administración de integración (tanto con el portal frontal como con los sistemas externos).



Todo se hizo en torno a un proceso principal de procesamiento de una solicitud de un residente. Para que inicie sesión, seleccione el tipo de problema y seleccione el punto en el mapa donde se encuentra este problema y envíe la apelación para su consideración. Además, para cada tipo de problema había un proceso comercial para resolverlo. Los moderadores miraron la parte formal. Utilizando el módulo SIG, se determinaron el contratista para esta apelación y el organismo regulador. Si, por ejemplo, no hay agua en la casa en Bogolyubova 45, entonces la compañía administradora “Udomdom-Dubna” realizó esta apelación, la llevó a cabo y el residente aceptó el resultado del trabajo. Si la compañía no cumplió con la fecha límite, la apelación voló a la autoridad supervisora: la inspección de la vivienda.



Parecía que la pantalla principal, nada más, entró, gritó y se fue. Además, las notificaciones llegarían por correo y teléfono sobre un cambio en el estado de la aplicación.

La idea principal de este proyecto era excluir a la administración del proceso rutinario de procesamiento de quejas de los residentes. Todo debería funcionar como un reloj por sí mismo. Después de todo, cada problema tiene su propia responsabilidad y, por lo general, esta no es la administración, incluso si es propiedad urbana. Todos estos son contratistas o empresas de gestión. Y no hay tantos controladores: el 90% de los problemas de la ciudad están controlados por la administración de supervisión técnica e inspección de viviendas.



Intentamos hacer la interfaz más conveniente, fácil y simple.

Los resultados del piloto de usar la plataforma en Dubna fueron reconocidos como exitosos, recibimos el Premio del Gobernador "Nuestra Región de Moscú" en la nominación de Control Público en 2014 y luego de que Dobrodel se lanzó en 2015. AIST era una plataforma y queríamos venderlo a otras regiones, lo creamos inicialmente como un producto. Después del lanzamiento de Virtue, la plataforma se disolvió en ella. El nivel de tareas, requisitos, integraciones ha aumentado varias veces. Resultó que ni siquiera pensamos. Como, por ejemplo, una pérdida rápida de memoria en Java bajo cargas, o cómo mantener actualizada la tarjeta de responsabilidad de las empresas de gestión. En la región, sus fronteras cambian todos los días. Pero mantenerlo manualmente es imposible.En ese momento, no había medios automatizados para descubrir áreas de responsabilidad, y como resultado, Dobrodel pasó de un enrutador de llamadas a la administración municipal y su objetivo principal, reducir la rutina para los funcionarios, se transformó seriamente. Durante estos cinco años, el proyecto se ha desarrollado con éxito bajo el liderazgo del equipo de la región de Moscú. Estoy seguro de que se han resuelto muchos problemas y ahora su experiencia se puede aplicar con éxito en otras áreas. Y aquí está el producto nuevamente. Capturamos Zen, todo es cíclico.

Este no fue el único enfoque para el proyectil, ahora estamos desarrollando nuestra plataforma AIOps para monitorear el desempeño de los servicios de TI y los procesos comerciales, así como la gestión automatizada de incidentes ( más información sobre la plataforma MONQ aquí) Primero, comenzamos a hacer un marcador simple sobre incidentes similares a PagerDuty para uso interno (era 2014), luego se convirtió en una fusión y un megadohboard para recopilar datos de docenas de Zabbixes y una plataforma para controlar el lanzamiento de pruebas automáticas para conectar datos sobre el funcionamiento de los servicios comerciales a través de los ojos de los usuarios y los datos sobre el estado de la infraestructura. Primero comenzamos a fabricar el producto, luego encontramos al primer cliente serio y durante 2 años nos convertimos en un proyecto, utilizándonos al 100% para las necesidades de este cliente, luego en 2017 vendimos la primera licencia a otro cliente y finalmente volvimos a ser el producto. Luego hubo problemas financieros y volvimos a depender del proyecto, realizamos una refactorización seria, lanzamos una nueva funcionalidad, nos mudamos a otro segmento de mercado y ahora somos nuevamente un producto.El balance del proyecto del producto, en mi opinión, es un problema muy agudo.

Si está interesado, en el próximo artículo puedo decirle cómo nació MONQ.