The history of the transformation from product to project and vice versa (using the example of Goodness in the Moscow region)

Since the launch of Dobrodel in the Moscow region, exactly 5 years have passed. Over the past five years, a simple project has turned into a product. And the Government of the Moscow Region in the form of a simple non-exclusive license transferred it to the Ulyanovsk Region. Link to the news here . But let's see what happened a little earlier and discuss the cyclical nature and Zen Buddhism in product management.



As the director of a small IT company, I looked at the Our City portal, launched in 2011 by the Sobyanin team and at the RosYama portal of Navalny. I did not let go of the idea of ​​what can be done better. So the project of the AIST platform and the implementation project of the platform in Dubna “City 2.0” were born in our company. From AIST in 2014-2015, Virtue appeared. About ideology and technology, I would like to talk a little bit in this article and thereby demonstrate the project-product-project cycle.

"Our City" worked for the Moscow Government and made it possible to quickly solve communal problems, scattering appeals to senior officials. The RosYama portal threw problems at once to control bodies and other responsible departments.

Navalny went on a simple and affordable way. Take the application from the form and send it in the form of an e-mail to the department by official e-mail. Problems were solved, but the deadline was 30 days, and the solution often remained for these 30 days only on paper.

"Our city" has always worked much more efficiently. Since 2013, we have been supporting users of the Our City portal and understand the internal cuisine of this system. I still admire the architects of this system. There are so many interesting things under the hood that cannot be described. The frontal portal is rather the tip of the iceberg. Just to take and deploy it in the same Ulyanovsk region would not be realistic (at least in 2014). It would be necessary to build the entire infrastructure of Moscow. And we have no second Moscow in Russia.

In 2013, we started making a platform on Java Spring + PostgreSQL with a BPM engine and a GIS module (on the same PostgreSQL). We wanted to make an elegant midland solution so that it would be possible to quickly change the design and front to build a system similar to “Our City” in the regions. The main functions of the platform were: managing users, roles and rights, appeals, categories of appeals, their routing, business processes, there was also not a complicated geographic information module and integration management layer (both with the front portal and with external systems).



Everything was done around one main process of processing an application from a resident. So that he logs in, selects the type of problem and selects the point on the map where this problem is located and sends the appeal for consideration. Further, for each type of problem there was a business process for solving it. Moderators looked at the formal part. Using the GIS module, the contractor for this appeal and the regulatory body were determined. If, for example, there is no water in the house on Bogolyubova 45, then the management company “Udomdom-Dubna” undertook this appeal, executed it, and the resident accepted the result of the work. If the company failed to meet the deadline, then the appeal flew to the supervisory authority - the housing inspectorate.



It looked like the main screen, nothing more, went in, screamed and left. Further, notifications would arrive by mail and phone about a change in the status of the application.

The main idea of ​​this project was to exclude the administration from the routine process of processing complaints from residents. Everything should work like a clock by itself. After all, each problem has its own responsibility, and usually this is not the administration, even if it is urban property. All of these are contractors or management companies. And there are not so many controllers: 90% of city problems are controlled by the administration of technical supervision and housing inspection.



We tried to make the most convenient interface, easy and simple.

The pilot’s results of using the platform in Dubna were recognized as successful, we received the Governor's Prize “Our Moscow Region” in the Public Control nomination in 2014 and after that Dobrodel was launched in 2015. AIST was a platform and we wanted to sell it to other regions, we built it initially as a product. After the launch of Virtue, the platform dissolved in it. The level of tasks, requirements, integrations has increased several times. It came out that we did not even think about. Like, for example, a fast memory leak on Java under loads, or how to keep the management companies accountability card up to date. In the region, their borders are changing every day. But to maintain it manually is impossible.At that time, there were no automated means for discovering areas of responsibility, and as a result, Dobrodel turned from a router of calls to the municipal administration and its main goal, to reduce the routine for officials, was seriously transformed. Over these five years, the project has successfully developed under the leadership of the team of the Moscow region. I am sure that many problems have been resolved and now their experience can be successfully applied in other areas. And here is the product again. We catch Zen, everything is cyclical.

This was not the only approach to the projectile, now we are developing our AIOps platform for monitoring the performance of IT services and business processes, as well as automated incident management ( more about the MONQ platform here) First, we started making a simple dialer about incidents similar to PagerDuty for internal use (it was 2014), then it turned into a merger and megadashboard for collecting data from dozens of Zabbixes and a platform for controlling the launch of autotests to connect data on the functioning of business services through the eyes of users and data on the health of the infrastructure. We first started making the product, then we found the first serious customer and for 2 years turned into a project, 100% utilizing ourselves for the needs of this customer, then in 2017 we sold the first license to another customer, and finally became the product again. Then there were financial problems and we again went into project dependency, did serious refactoring, released new functionality, moved to another market segment and now we are again a product.The balance of the product project, in my opinion, is a very acute issue.

If interested, in the next article I can tell you how MONQ was born.