Saltar para o conteúdo principal
FAQ

Perguntas frequentes

Está agrupado por serviço, porque é normalmente como a malta cá chega. Vais ao que te interessa, ignoras o resto. Se a tua pergunta não estiver aqui, manda mensagem pelo contacto e respondemos a sério.

Desenvolvimento de produto

Engenheiros seniores a levar um produto da ideia até algo que os utilizadores abrem mesmo. Discovery, construção, shipping, manutenção.

O que é que o desenvolvimento de produto na Alongside inclui?

Quase todo o caminho. Uma equipa pequena de engenheiros seniores e design, normalmente quatro a seis pessoas, começa com discovery e depois constrói em ciclos curtos. Fazemos front end, back end, a parte chata de DevOps que mantém aquilo de pé. Se já tens alguma coisa internamente, entramos ao lado. Não trabalhamos numa ilha.

Como corre uma colaboração e quanto tempo demora?

A maioria das builds anda entre três e nove meses, conforme o scope e a clareza dos requisitos. As primeiras semanas são discovery e um plano. Depois demos quinzenais, software a funcionar e estado honesto. Tentamos manter isto chato no bom sentido. Nada de heróis na sexta à noite.

O que acontece depois do lançamento? Perdemos a equipa?

Escolhes. Alguns clientes ficam com uma squad pequena em retainer para continuar a lançar. Outros querem um handover limpo para a equipa interna assumir. Escrevemos o README como se alguém tivesse de o ler numa segunda feira, porque é isso que costuma acontecer. Sem conhecimento escondido, sem código refém.

Reforço de equipa

Os nossos engenheiros seniores a juntarem se à tua equipa, não o contrário. Mesmas standups, mesmo repo, mesmas code reviews.

Em que é que isto difere do outsourcing clássico?

O outsourcing tende a acontecer atrás de uma parede. Fazemos o contrário. As tuas ferramentas, o teu board, os teus rituais. As pessoas aparecem nas vossas standups, fazem push no vosso repo, apanham comentários em PRs como toda a gente. Não tens um PM no meio a traduzir tudo. Tens engenheiros.

Conseguem cobrir timezones dos EUA a partir de Portugal?

Sim, dentro do razoável. A maior parte da equipa sobrepõe quatro a seis horas com a costa leste dos EUA, menos com a oeste. Com clientes na Europa há sobreposição de dia inteiro. Somos diretos sobre os timezones que uma pessoa consegue cobrir à vontade, para ninguém fingir que está acordado às três da manhã.

Que seniores são mesmo as pessoas que mandam?

A maioria dos engenheiros em augmentation tem mais de oito anos de carreira. Não porque fica giro no site. É porque júnior mais codebase nova mais equipa nova é uma combinação má. Se precisas de uma stack específica ou de um perfil específico (um staff engineer, alguém que já fez payments), dizemos logo. Nada de trocar a meio.

Consultoria técnica

Alguém que já viu muita arquitetura, muito tech debt e muitas decisões maradas, disponível numa cadência saudável.

Quando faz sentido trazer advisory?

Quando estás prestes a tomar uma decisão difícil de desfazer. Arquitetura nova, trocar de base de dados, separar um monólito, escolher cloud, contratar o primeiro VP interno. Às vezes só querem uma segunda opinião porque o CTO está esticado. Tudo razões válidas.

Na prática, como é o dia a dia?

Normalmente uma sessão semanal ou quinzenal com os leads técnicos, mais perguntas async no Slack. Lemos o código, participamos nas reviews de arquitetura, sinalizamos riscos e metemos o importante por escrito para não se perder. Não gerimos a tua equipa. Ficamos ao lado de quem gere.

Em que é que isto difere de uma auditoria de código completa?

A auditoria é um mergulho num ponto específico no tempo. O advisory é contínuo e mais conversado. A auditoria é um check up. O advisory é ter um bom médico ao telefone. Muitos clientes fazem os dois. Um diz onde estás, o outro ajuda a não cair de um penhasco no próximo trimestre.

Desenvolvimento de MVP

MVPs rápidos, com forma de produção. Polido o suficiente para demo, estrutura o suficiente para não atirar fora em três meses.

Qual é a velocidade realista para um MVP?

Quatro a oito semanas é o realista para a maioria das ideias, assumindo que sabes mais ou menos o que queres e decides depressa. Dez semanas se o domínio for confuso. Quem te vende um MVP em duas semanas está a vender uma demo, não um produto. Dizemos qual se aplica ao teu caso.

Como equilibram velocidade e não criar tech debt?

Cortamos scope, não qualidade. Menos funcionalidades, mas auth, observabilidade básica, um modelo de dados decente e um deploy que não é fita cola. Uma feature dá sempre para acrescentar. Arrancar uma fundação podre três meses depois é a parte que mata startups.

O que acontece depois do MVP?

Dois caminhos típicos. Ficamos para a próxima fase (o mais comum) ou contratas pessoas internas e ajudamos no onboarding. Em qualquer dos casos, deixamos docs, uma sessão de handover e uma lista curta do que atacaríamos a seguir. Sem drama, sem código refém.

Auditoria e revisão de código

Um olhar independente sobre o teu código. Segurança, performance, tech debt, e o que atacar primeiro.

O que é que uma auditoria de código inclui?

Quatro ângulos, normalmente. Riscos de segurança, gargalos de performance, tech debt e onde magoa a sério, e DX (este repo é suportável). Lemos o código, corremos ferramentas, falamos com os teus engenheiros. As conclusões ficam num relatório com severidade e esforço estimado.

Quanto tempo leva e quem tem de estar envolvido?

Normalmente uma a duas semanas, conforme o tamanho do codebase. Precisamos de acesso de leitura ao repo, uma intro curta de alguém que conhece o sistema e uma ou duas calls quando batemos em coisa esquisita. Os teus engenheiros não têm de tomar conta de nós. É meio que essa a ideia.

O que é que saímos com a mão?

Um relatório escrito que um founder não técnico consegue ler e um engenheiro consegue agir. Problemas ordenados por severidade e esforço, mais um roadmap de 30, 60, 90 dias. Sem enchimento, sem PDFs de 80 páginas que ninguém lê. Se quiseres ajuda a executar depois, ajudamos. Se não, o relatório vale por si.

Consultoria de escalabilidade

Para equipas que já passaram a fase scrappy. Org design, processos, infra, contratação, cultura. O que parte quando cresces depressa.

Quando é que consultoria de escalabilidade ajuda mesmo?

A partir dos dez engenheiros, mais ou menos, quando os hábitos antigos começam a ranger. Os deploys abrandam, contratação parece aleatória, decisões de arquitetura acontecem no Slack e mais lado nenhum. Se estás aí ou quase, é boa altura. Se ainda são cinco pessoas, o que precisas é de lançar.

Isto é sobre pessoas ou sobre infraestrutura?

Normalmente os dois, e estão mais ligados do que parece. Um pipeline de deploy frágil é muitas vezes problema de gestão. Uma equipa sempre em burnout é muitas vezes problema de arquitetura. Olhamos para estrutura da organização, on call, processo de contratação e o lado da infra (CI, observabilidade, resposta a incidentes). Puxas um fio, vem tudo atrás.

Que outputs concretos saem disto?

Coisas tangíveis. Um plano de contratação, uma topologia de equipa revista, uma lista curta de investimentos de infra com custos aproximados e uma rotação de on call que não castiga sempre os mesmos três. Mais sessões semanais enquanto as mudanças acontecem. Se não se consegue medir num trimestre, provavelmente não devíamos estar a fazê lo.

Próximos passos

Explore serviços, trabalhos ou entre em contacto.