🤘🏾 🌻 ♈️ Inicialização dentro da corporação 👨🏽‍🤝‍👨🏻 🏴󠁧󠁢󠁷󠁬󠁳󠁿 🤹🏽

Olá, meu nome é Andrey Vanin e estou desenvolvendo e lançando produtos de corretagem e fintech. Hoje faz exatamente um ano que trabalho na BCS, onde, em uma equipe de oito pessoas, estamos desenvolvendo o projeto fintarget.ru.

Abaixo está uma (não) grande história sobre como implementar uma startup em uma grande empresa, lançá-la no mercado e, ao mesmo tempo, não queimar entre toneladas de memorandos e aprovações.

imagem

Introdução

Esqueça todos os manifestos do Agile e crie um ambiente de trabalho confortável, se você deseja obter resultados. No gerenciamento de projetos sem esperança, não é a presença do escritório da PlayStation e os rituais obrigatórios de scrum que vêm à tona, mas as ambições e a motivação pessoal da equipe.

Se seu desenvolvedor quiser ser o melhor, ele não jogará air hockey e não se importará se houver uma sala de descanso no escritório (há um spoiler). Se o seu projeto deseja obter respeito, ele aprenderá a andar de cabeça para baixo e resolver qualquer problema, seja outro trabalho inconcebível substituir uma cadeira quebrada ou a necessidade de coordenar um processo que não existe.

Se o fornecedor front-end tiver uma hipoteca pendente, ofereça a ele uma opção - PS4 ou mais um bônus no mesmo valor. Sua tarefa não é ser babá no projeto, mas garantir o resultado de forma que a equipe e o cliente estejam satisfeitos. Mesmo que não seja possível.

Em suas marcas

Entrei para a empresa no início de abril de 2019. Dois desenvolvedores estavam no escritório, um cliente e meio gerente de projetos que nunca haviam se envolvido em projetos de desenvolvimento. Tivemos que desenvolver rapidamente um sistema do zero, o que eles tentaram fazer três ou quatro vezes antes, mas em cinco anos ninguém conseguiu trazer um produto sensato e fácil de usar ao mercado.

Na minha mesa havia uma impressão de uma apresentação de cinco slides - como tudo ficará bem, como ficará, arquitetura teórica, quanto dinheiro deve trazer e quanto dinheiro será necessário. E nem uma palavra sobre o produto, nem uma única menção de unidades relacionadas, nem um único processo e compreensão de como tudo isso deve decolar.

Mas o prazo foi anunciado - a ser lançado em setembro. E nos sentamos para trabalhar.

Pivô duplo

A primeira versão do produto implicava a criação de uma infraestrutura interna sem sua própria solução front-end. Supunha-se que o produto fosse apresentado na prateleira do aplicativo móvel, e meus dois desenvolvedores suportariam apenas o back-end e a logística dos fluxos de informações. Essa abordagem garantiu o fracasso do projeto já em junho, pois, na direção paralela dos negócios, a equipe de aplicativos passou por mudanças significativas e sua carteira de pedidos até o final do ano foi muito nebulosa. E decidimos criar um produto MVP na frente da web atual da empresa. Essa foi a primeira vez.

A solução mais simples nessa situação é terceirizar o designer UX e o designer de layout, desenhar layouts de lápis, obter o design e desenvolvê-lo. Mas apenas startups independentes podem. Somos uma startup dentro de uma grande empresa, onde o designer não pode pagar em dinheiro, e todo o trabalho da frente deve ser feito através da coordenação com marketing e advogados. Foi mais difícil, mas não interrompeu o desenvolvimento do kernel, então entramos no marketing.

imagem

Quase imediatamente, surgiu o problema de estratificação do quadro geral - o marketing não sabia o que estávamos fazendo tecnicamente e os desenvolvedores não entendiam como tudo deveria parecer. Antes das férias de maio, abrimos a confluência e nos sentamos para descrever as telas.

Até meados de maio, um entendimento detalhado de como o produto deveria funcionar existia apenas na minha cabeça e em cerca de cinquenta páginas descrevendo os algoritmos e as telas. Era um grande risco (o truque foi feito por profissionais! Não repita - é perigoso!), Mas ao mesmo tempo cada membro da equipe sabia o que fazer e foi carregado com o trabalho com dois meses de antecedência.

O projeto fumou, coordenando a próxima versão da arquitetura e a interação dos sistemas, o líder da equipe entrou e começou a escolher o código, e o terceiro desenvolvedor (contratado comigo no mesmo dia) quase um mês entendeu os mecanismos de integração. E essa foi a parte mais difícil. A empresa possui duas dúzias de sistemas, dos quais seis precisávamos integrar.
Em algum momento, ficou claro que o líder da equipe indicado não se encaixava no ritmo da equipe e precisava ser substituído. O segundo desenvolvedor assumiu o seu lugar e, para a vaga, contratamos um programador com experiência em um candidato a ciências físicas. Olhando para o futuro, direi que isso nos salvou.

No entanto, quase imediatamente ficou óbvio que também não poderíamos nos encaixar no circuito interno da Web, e o cliente concordou com a única solução de economia naquele momento - criamos nossa própria frente de produto baseada na Web com nossa equipe de marca e suporte. Dentro do departamento, anunciamos apressadamente uma competição pelo nome do produto e, finalmente, escolhemos a opção que foi dublada desde o início, já que havia um bom domínio no meu cofrinho pessoal e não havia nada melhor para todos votar e criativo. Então a marca fintarget.ru apareceu. E essa foi a segunda vez, chave.

Sobre a equipe

Milhões de livros sobre gerenciamento de desenvolvimento fornecem modelos de trabalho em equipe e processos padrão, esquecendo que cada equipe é única e requer uma abordagem individual.

Muitos fatores podem influenciar o trabalho e a comunicação em uma equipe: idade, estado civil e até preferências musicais. No entanto, quase nunca os produtos prestam atenção a isso e, em regra, se concentram em fatores colaterais - a localização e o tamanho da mesa, as persianas nas janelas, fones de ouvido com ventilação e outras pequenas coisas que "não são irritantes".

As estrelas se uniram e conseguimos encontrar uma cadeia de relacionamentos em que todos e todos sempre tinham algo para conversar além de trabalho. E quando você constrói a comunicação - você pode lidar com calma com a distribuição de papéis.

No estágio dos processos da equipe de depuração, formamos um esquema híbrido que não se encaixa em nenhum dos modelos existentes.

Primeiro , abandonamos o analista. Absolutamente. O papel do analista é distribuído entre o líder da equipe e o proprietário do produto, e os detalhes dos processos são modernizados e corrigidos durante o teste do serviço. Essa é a melhoria contínua do produto que os proponentes do Edge adoram falar.

Em segundo lugar, apagamos a linha entre os poderes do gerente de produto na pessoa do cliente e o proprietário do produto. Dois funcionários desempenham duas funções on-line, sem delimitar a autoridade e sem medo de responsabilidade na tomada de decisões. Foi especialmente interessante assistir aos desenvolvedores que viram como o proprietário e o gerente discutiram com voz rouca sobre o CJM ou o layout da página. A propósito, isso influenciou bastante o envolvimento da equipe.

Em terceiro lugar , no estágio de desenvolvimento do kernel, abandonamos completamente os sprints com uma carteira pendente e usamos uma abordagem iterativa baseada no refinamento e na adição de funcionalidade durante o desenvolvimento. Lembre-se de como as imagens jpeg foram carregadas no navegador no início do século? É da mesma maneira que desenvolvemos o núcleo do produto.

Quarto, delimitamos estritamente a funcionalidade dos desenvolvedores. Um desenvolvedor de microsserviço separado foi alocado para cada setor, responsável apenas por seu segmento. Temos cinco desses segmentos no projeto: integração com sistemas internos, integração com sistemas de intercâmbio, algoritmos de produtos de kernel, OpenAPI e a frente.

E quinto , todos os recursos do gerente de projetos de nosso departamento que tínhamos visavam apenas gerenciar equipes externas responsáveis por finalizar os sistemas com os quais precisávamos integrar e implementar todos os procedimentos para coordenar e integrar uma startup na infraestrutura da empresa.

Esse herói do projeto por três meses passou mais de uma centena e meia de serviços diferentes, descreveu e documentou uma dúzia de novos processos, e foi ele quem, na prática, refutou a teoria popular da impossibilidade de fazer startups em grandes empresas.

Essa abordagem nos permitiu planejar o pool de tarefas, corrigir todos os requisitos para o MVP e, como um todo, quando ficou claro que o mecanismo funcionava, eu, como iniciante, saía de férias quase com calma. Era julho e, como está escrito em um famoso romance de gerenciamento de projetos, quando todos os processos são definidos, tarefas e prazos são conhecidos, basta prestar atenção.

No dia primeiro de agosto, montamos o kernel do sistema, quase todo o trabalho preparatório foi concluído, a versão beta do OpenAPI foi montada, a frente foi desenhada e montada e ainda havia uma semana para polir os algoritmos e aguardar o front-end funcionar, que era "apenas para" coletar tudo Este é um MVP em funcionamento.

Árvores de eventos

É possível coletar a infraestrutura do projeto de inicialização em um ciclo de teste fechado, o quanto você quiser, mas o projeto nunca decolará sem a integração com os principais sistemas da empresa. Esse é o principal problema do trabalho de startups nas empresas: mais de 80% dos projetos morrem sem encontrar a oportunidade de integrar e cumprir todos os requisitos e regulamentos corporativos.

Existem vários sistemas no ramo de corretagem: sistemas de negociação e contabilidade, barramentos de integração, CRM, um catálogo de serviços e uma dúzia de outros sistemas e mecanismos que são estritamente regulamentados e controlados pelos serviços de segurança da informação.
A integração sem exagero foi o teste mais sério para o projeto e a equipe, e tivemos que matar um total de cerca de três homens-mês de trabalho nele.

Um papel fundamental nesse processo foi desempenhado pela regra “primeiro quebre todas as regras”. Iniciamos vários cenários de integração paralela de uma só vez - desde o mais oficial (através do Project Passport, coordenando a arquitetura, criando um circuito de teste e transferindo todas as instruções para a política e suporte à liberação) até o mais não oficial - desenvolvemos no circuito de combate, fechado por fora e testamos o sistema por conta própria contas de corretagem.

Os detalhes desta história merecem um artigo separado, mas a chave que foi alcançada consiste em vários pontos:

. « – – crm– – – – », , ,
- « - », « » .
A abordagem de teste no "pré-produto" multiplicou o envolvimento dos desenvolvedores, tornou possível testar o UX na prática antes mesmo de o produto ser lançado para o mundo exterior e, o mais importante para o projeto, depurar a operação correta dos algoritmos do sistema no mercado real e nos dados do cliente.

E o mais importante - nunca considere perder tempo em processos paralelos durante a integração. Como nos orçamentos de publicidade, você ainda nunca sabe qual metade do orçamento gastou em vão. Apenas construa uma árvore de opções e inicie os processos: alguns ramos desaparecerão por si mesmos como desesperados, outros se fundirão em um e, quando um deles levar você ao resultado, será apenas o seu Caminho do Campeão. Porque em outro projeto, o mesmo cenário pode não funcionar.

imagem

Qual é o resultado

O MVP de trabalho do projeto foi montado no final de agosto, em paralelo, foi implementada uma versão do emulador para credenciar o programa na NAUFOR e foram escritas cento e cinquenta páginas de documentação de suporte para registro de software. As primeiras transações reais no sistema aos gritos de alegria da equipe ocorreram em 31 de agosto. As alterações legais nos documentos da empresa e nos regulamentos do cliente entraram em vigor em 1º de setembro e, antes do credenciamento do sistema, tivemos tempo para depurar e lamber as interfaces.

No MVP, não tínhamos contas em moeda, nem futuros, nem mesmo nossa própria conta de corretagem, mas a tarefa principal foi concluída - a infraestrutura foi implementada, o pré-produto se tornou um produto, o serviço para os clientes foi implementado.

Em 17 de setembro, o software Fintarget foi adicionado ao registro de programas de acompanhamento automático credenciados e no dia seguinte vimos os primeiros clientes se conectando ao sistema. Ainda havia muito trabalho para expandir a funcionalidade e levar o MVP ao estado de um produto completo e autossuficiente, mas essa é uma história completamente diferente e menos interessante: lançamentos, sprints, backlogs e análises de clientes sem fim.