A história da transformação de produto em projeto e vice-versa (usando o exemplo de Bondade na região de Moscou)

Desde o lançamento do Dobrodel na região de Moscou, exatamente 5 anos se passaram. Nos últimos cinco anos, um projeto simples se transformou em um produto. E o governo da região de Moscou, sob a forma de uma licença simples e não exclusiva, a transferiu para a região de Ulyanovsk. Link para as notícias aqui . Mas vamos ver o que aconteceu um pouco antes e discutir a natureza cíclica e o zen-budismo no gerenciamento de produtos.



Como diretor de uma pequena empresa de TI, observei o portal Our City, lançado em 2011 pela equipe Sobyanin e o portal RosYama de Navalny. Não deixei de lado a ideia do que pode ser feito melhor. Assim, o projeto da plataforma AIST e o projeto de implementação da plataforma em Dubna “City 2.0” nasceram em nossa empresa. Do AIST em 2014-2015, o Virtue apareceu. Sobre ideologia e tecnologia, gostaria de falar um pouco neste artigo e, assim, demonstrar o ciclo projeto-produto-projeto.

"Nossa cidade" trabalhou para o governo de Moscou e tornou possível resolver rapidamente problemas comunitários, espalhando apelos a altos funcionários. O portal RosYama lançou problemas ao mesmo tempo para controlar órgãos e outros departamentos responsáveis.

Navalny seguiu um caminho simples e acessível. Pegue a inscrição no formulário e envie-a em forma de carta eletrônica para o departamento por e-mail oficial. Os problemas foram resolvidos, mas o prazo final era de 30 dias, e a solução geralmente permanecia nesses 30 dias apenas em papel.

"Nossa cidade" sempre trabalhou com muito mais eficiência. Desde 2013, apoiamos os usuários do portal Our City e compreendemos a culinária interna desse sistema. Ainda admiro os arquitetos desse sistema. Há tantas coisas interessantes sob o capô que não podem ser descritas. O portal frontal é mais a ponta do iceberg. Apenas levá-lo e implantá-lo na mesma região de Ulyanovsk não seria realista (pelo menos em 2014). Seria necessário construir toda a infraestrutura de Moscou. E não temos segunda Moscou na Rússia.

Em 2013, começamos a criar uma plataforma em Java Spring + PostgreSQL com um mecanismo de BPM e um módulo GIS (no mesmo PostgreSQL). Queríamos criar uma solução elegante para a região central, para que fosse possível mudar rapidamente o design e a frente para criar um sistema semelhante ao “Nossa Cidade” nas regiões. As principais funções da plataforma foram: gerenciamento de usuários, funções e direitos, recursos, categorias de recursos, roteamento, processos de negócios, também não havia um módulo de informações geográficas complicado e uma camada de gerenciamento de integração (tanto no portal frontal quanto nos sistemas externos).



Tudo foi feito em torno de um processo principal de processamento de um aplicativo de um residente. Para que ele efetue login, selecione o tipo de problema e o ponto no mapa em que esse problema está localizado e envia a apelação para consideração. Além disso, para cada tipo de problema, havia um processo de negócios para resolvê-lo. Os moderadores analisaram a parte formal. Usando o módulo GIS, o contratado para esse recurso e o órgão regulador foram determinados. Se, por exemplo, não houver água na casa em Bogolyubova 45, a empresa administradora “House-Dubna” aceitou o apelo, o executou e o residente aceitou o resultado do trabalho. Se a empresa não cumprir o prazo, o recurso foi encaminhado para a autoridade supervisora ​​- a inspeção da habitação.



Parecia que a tela principal, nada mais, entrou, gritou e saiu. Além disso, as notificações chegariam por correio e telefone sobre uma alteração no status do aplicativo.

A idéia principal desse projeto era excluir a administração do processo rotineiro de processar reclamações dos moradores. Tudo deve funcionar como um relógio por si só. Afinal, cada problema tem sua própria responsabilidade e, geralmente, essa não é a administração, mesmo que seja propriedade urbana. Todos estes são contratados ou empresas de gestão. E não há muitos controladores: 90% dos problemas da cidade são controlados pela administração da supervisão técnica e da inspeção da moradia.



Tentamos fazer a interface mais conveniente, fácil e simples.

Os resultados do piloto de usar a plataforma em Dubna foram reconhecidos como bem-sucedidos, recebemos o prêmio Governor "Our Moscow Region" na nomeação para Controle Público em 2014 e depois que o Dobrodel foi lançado em 2015. O AIST era uma plataforma e queríamos vendê-lo para outras regiões, construímos inicialmente como um produto. Após o lançamento do Virtue, a plataforma se dissolveu nele. O nível de tarefas, requisitos, integrações aumentou várias vezes. Acabou que nem pensávamos. Como, por exemplo, um rápido vazamento de memória no Java sob cargas ou como manter o cartão de responsabilidade das empresas de gerenciamento atualizado. Na região, suas fronteiras estão mudando todos os dias. Mas mantê-lo manualmente é impossível.Naquela época, não havia meios automatizados para descobrir áreas de responsabilidade e, como resultado, a Dobrodel passou de um roteador de chamadas para a administração municipal e seu principal objetivo, reduzir a rotina dos funcionários, foi seriamente transformado. Nestes cinco anos, o projeto foi desenvolvido com sucesso sob a liderança da equipe da região de Moscou. Estou certo de que muitos problemas foram resolvidos e agora sua experiência pode ser aplicada com sucesso em outras áreas. E aqui está o produto novamente. Pegamos o Zen, tudo é cíclico.

Essa não foi a única abordagem para o projétil, agora estamos desenvolvendo nossa plataforma AIOps para monitorar o desempenho dos serviços de TI e processos de negócios, bem como o gerenciamento automatizado de incidentes ( mais sobre a plataforma MONQ aqui) Primeiro, começamos a fazer um discador simples sobre incidentes semelhantes ao PagerDuty para uso interno (era 2014), depois transformou-se em uma fusão e um megadashboard para coletar dados de dezenas de Zabbixes e uma plataforma para controlar o lançamento de autotestes para conectar dados sobre o funcionamento dos serviços de negócios através dos olhos dos usuários e dados sobre a saúde da infraestrutura. Começamos a fabricar o produto, depois encontramos o primeiro cliente sério e por 2 anos nos transformamos em um projeto, 100% nos utilizando para as necessidades desse cliente; em 2017, vendemos a primeira licença para outro cliente e finalmente nos tornamos o produto novamente. Houve problemas financeiros e voltamos a depender do projeto, refatoramos seriamente, lançamos novas funcionalidades, mudamos para outro segmento de mercado e agora somos novamente um produto.O saldo do projeto do produto, na minha opinião, é uma questão muito aguda.

Se estiver interessado, no próximo artigo, posso dizer como nasceu o MONQ.