Parceiros de tecnologia e de produto
Para fornecedores de software e empresas de produto que precisam de uma equipa de engenharia a par da sua durante anos e não durante um sprint. Um módulo de que somos responsáveis de ponta a ponta, uma plataforma que ajudamos a operar ou uma segunda equipa que assume o roadmap que não consegue dotar de pessoas, com as mesmas pessoas a ficarem o tempo suficiente para aprender o domínio.
Diferente de comprar um projeto
Um projeto tem um fim, e tudo na forma como é dotado de pessoas decorre disso: as pessoas são alocadas, o domínio é aprendido o suficiente para concluir e o conhecimento sai com elas. Um produto não acaba. O que precisa de uma equipa externa é continuidade, interesse em que a arquitetura sobreviva aos próximos dois anos e pessoas que contrariem quando um atalho vai custar mais tarde mais do que poupa agora.
É essa a relação que esta página descreve. Do ponto de vista comercial, costuma ser uma equipa dedicada; o que a torna uma parceria é que respondemos por um resultado no produto da sua empresa e não por uma lista de tickets.
Aquilo de que normalmente somos responsáveis
Um módulo de que somos responsáveis de ponta a ponta
Uma parte delimitada do seu produto: a camada de integrações, a vertente de relatórios, a área de administração, o cliente mobile. Somos responsáveis por ela na sua base de código, segundo a sua arquitetura, e respondemos pelos seus defeitos e não por um número de tickets.
Uma segunda equipa no roadmap
Tudo o que sabe que deveria construir e não consegue dotar de pessoas. Uma equipa paralela a trabalhar nos seus repositórios e nos seus rituais, para que o roadmap avance em duas frentes em vez de ser repriorizado até restar uma.
A plataforma subjacente
Infraestrutura cloud declarada em Terraform, pipelines, ambientes, observabilidade, trabalho de base de dados e de segurança. A parte para a qual uma equipa de produto nunca tem tempo e cuja falta sente todas as semanas.
Fazer avançar um produto antigo
Um produto que vende, mas que deixou de ser alterável. Nove tomadas a cargo até agora, a mais antiga escrita em 2008, começando sempre por uma revisão só de leitura e uma lista escrita de riscos e não por uma proposta de reescrita.
O que faz uma parceria longa funcionar
Pessoas que ficam
Os projetos aqui duram anos e não sprints, e o conhecimento do domínio fica com as mesmas pessoas. O pior resultado para um parceiro é pagar duas vezes a mesma curva de aprendizagem.
A sua arquitetura, e não a nossa
Estamos habituados a assumir a tecnologia em que um produto já funciona, em vez de o orientar para aquilo que por acaso conhecemos. Uma equipa parceira que não para de propor uma reescrita é uma equipa parceira que deixou de ser útil.
Regras que sobrevivem a uma passagem de testemunho
Os testes seguem com a funcionalidade, a build termina com zero avisos, a segurança é negação por defeito e a infraestrutura é código. Código escrito assim é código que os seus próprios engenheiros conseguem assumir.
Uma fonte de verdade por facto
Os valores derivados são calculados uma só vez e consumidos em todo o lado. Num produto com várias equipas, a verdade duplicada é o bug que se descobre seis meses depois e que não se consegue explicar a um cliente.
Cobertura que é nossa, não faturada
A revisão da arquitetura, um segundo par de olhos nos pull requests e a cobertura durante licenças vêm da BigTree108 e não do seu orçamento.
A sua propriedade intelectual em todo o percurso
Cada especialista atribui o seu trabalho à empresa antes do acesso, e este é atribuído por sua vez à sua empresa, pelo que nada numa parceria longa complica a titularidade do produto.
Gerimos um produto nosso
Tudo o que usamos internamente, da contratação e do onboarding ao registo de horas, aos contratos e à faturação, é uma única plataforma na stack que oferecemos aos parceiros: .NET em Azure Functions, Angular, Azure SQL, Terraform. Não é uma peça de portefólio; é o sistema de que a empresa depende, e convivemos o tempo suficiente com as nossas próprias decisões de arquitetura para saber quais delas estavam erradas.
É esse o discernimento que um parceiro de produto realmente compra. O caso de estudo descreve o que faz e como é construído.
Como começa
Com algo pequeno e reversível. Um engenheiro numa parte delimitada do seu backlog, ou uma revisão só de leitura da parte do produto com que se sente menos à vontade, entregue como uma lista escrita de riscos por ordem de impacto na produção. Ambas são formas baratas de saber se lemos a sua base de código como gostaria que um parceiro a lesse.
A partir daí, a forma habitual é uma equipa dedicada que cresce com o roadmap. Se, a prazo, preferir ser dono da equipa por inteiro, o Build-Operate-Transfer são as mesmas pessoas com uma transferência prevista no contrato.
Precisa de uma segunda equipa no seu produto?
Envie o produto, a parte do roadmap que continua a derrapar e uma ligação para o repositório, se puder. Recebe as perguntas que ainda temos, uma abordagem e uma estimativa no prazo de um dia útil.