Ascenção ou completo fracasso? "Ganhei, ao contrário" na loteria do primeiro emprego como programador. O que fazer?
O post é gigante, então vou resumir: entrei em uma startup que tem muito potencial, mas
estamos sofrendo por sermos uma equipe de "estagiários senior", com um gestor que não entende nada de desenvolvimento de software.
- 1. O problema
- 2. Propostas para tentar "virar a chave"
- 3. Conclusão: O ponto de vista de um mero estagiário
1. O problema
Disclaimer: tudo o que foi apresentado é do ponto de vista de um mero estagiário que nunca trabalhou como programador. Estou aqui em busca da ajuda de pessoas com mais experiência na área
Bom. A situação é basicamente a do título.
Acabei de ingressar no primeiro emprego de TI, basicamente como estagiário desenvolvedor.
É uma empresa nova, basicamente com uma equipe de pessoas inexperientes (incluindo eu), e precisamos desenvolver portais do zero, com diversos módulos. Temos alguns problemas:
1.1. O gestor da equipe é uma pessoa não técnica:
Bom, talvez você pense "ah, mas isso é normal!". Não duvido que seja (até mesmo, por já ter ouvido histórias semelhantes). Mas e quando você junta uma pessoa que só entende, no máximo, de governança com uma equipe de pessoas inexperientes? Uma barreira enorme se cria na comunicação.
Além disso, também é um ex funcionário público. Isso em si não é um problema, o problema é achar que dá para tocar uma "startup" do mesmo jeito que se toca alguma corporação pública enorme. A consequência disso é que nossa equipe, sendo inexperiente, se encontra sem uma guia técnico real; logo, temos que nos virar para nos orientarmos, sendo que nessa primeira semana eu pude encontrar diversos problemas, bem como apontar algumas sugestões para trabalharmos ao longo das próximas semanas.
Levando em consideração o ponto anterior, vem possivelmente o maior dos problemas: Ele fez a equipe trabalhar basicamente durante um ano no modelo "Waterfall"; ou seja, pedia para desenvolver a versão "1.0" (ele não entende de versionamento) por completo para então apresentar, mas fica completamente obcecado com a parte de plajenamento, levando até 2 meses pra aprovar um mísero fluxograma (pra então depois permitir que a equipe comece a desenvolver).
Além disso, também havia basicamente alcoado cada membro da equipe 100% em um "produto". Então não havia pelo menos duas pessoas pra trabalhar em conjunto com alguma coisa, o que obviamente causa uma dependência absurda, ainda mais numa equipe inexperiente que não vai conseguir entregar excelentes produtos com agilidade, ainda mais trabalhando no modelo apresentado no ponto anterior.
Ele não conhece nadinha de desenvolvimento ágil. Ele disse que inicialmente havia tentado trabalhar com "salas ágeis", mas que deu errado. Aí ele disse que ficou nesse modelo que citei nos dois pontos anteriores, porque supostamente é mais ágil (praticamente nada de software foi entregue em 1 ano).
1.2. (Me repetindo de novo) Toda a equipe é inexperiente com desenvolvimento:
Basicamente, temos estagiários e uma cientista de dados (com um conhecimento incrível na área dela, por sinal). Na cabeça da gestão, e provavelmente também da diretoria, essa questão de níveis é bobagem e "um programador estagiário entrega a mesma coisa que um analista". Bom, obviamente quem ler esse post, sabe que não (por mais que seja complicado definir o nível de uma pessoa só pelo cargo).
Essa inexperiência, aliada dos problemas que listei em relação a gestão, causou muita lentidão para a equipe porque todos se encontravam muito perdidos em relação a como dar andamento em demandas tão complicadas.
1.3. A "infraestrutura" foi decida de forma totalmente arbitrária
Basicamente, pagaram um freelancer para fazer o site institucional da empresa. Nesse sentido, nem sei se culpo a pessoa que fez esse serviço, mas ela literalmente fez tudo com WordPress, e depois repassou o acesso à um administrador da empresa.
O problema do ponto anterior é: basicamente, a infraestrutura é uma hospedagem de WordPress, e no máximo permite rodar aplicações PHP, mas nada muito elaborado. Não sei nem se permite instalar um framework tipo Laravel, pois isso facilitaria (absurdamente?) o fluxo de desenvolvimento, pois a equipe e a gestão estavam quebrando cabeça pra fazer coisas que nem deveria perder tempo, tipo RBAC (que a maioria dos frameworks bons já fornece por pasdrão?), ao invés de focar nos problemas de negócio.
Outro problema com essa hospedagem é que, aparentemente, os domínios comerciais também estão nela. Ainda não sei se podemos usar eles para, por exemplo, associá-los a serviços rodando em outros lugares (até pelo custo dessa hospedagem + domínio, que parece não ser nada barato). Até se faz uso de cloud para algumas coisas, mas são basicamente para funções que rodam exporadicamente.
Levando em conta a limitação de plataforma e a inexperiência da equipe, temos uma barreira que é a própria linguagem em si. Não vindo aqui simplesmente para acusar o PHP puro de "puxadinho"; o ponto é que ninguém lá tem um domínio aceitável de PHP, e só estavam usando por conta de que simplesmente foi o "que foi passado" pra eles. No geral, a maioria conhece Python e Javascript, e eu conheço C# (além dessas duas aí).
Inicialmente, também haviam pagado por um CRM para utilizar somente uma funcionalidade dele, sendo que a mensalidade custa muito caro (tipo assim, 10x mais caro que uma VPS com 8GB de RAM, por exemplo); querem se livrar dela o quanto antes, só que é bem provável que por conta desse custo elevado, não queiram migrar aos poucos de plataforma, caso optássemos por não desenvolver com PHP (bom, até porque ainda não temos essa noção de quanto custaria).
1.4. A credibilidade da equipe já está ferida, e a equipe está insatisfeita com a gestão
Essa burocracia excessiva somente nas etapas do design de software causou uma tremenda lentidão, ao ponto de que basicamente a equipe tem 1 de 5 produtos funcionando hoje; A ausência de conhecimento técnico por parte da gestão é tão discrepante que ele simplesmente aceitou subir essa aplicação para prod. com um login em plaintext (não precisa dizer que isso acontece com mais frequência do que deveria; infelizmente, estou ciente)!
Essa lentidão causou um problema em via de mão dupla: a equipe se sente frustada pela demora e ausência de organização para gerir o andamento dos projetos, enquanto quem está acima está insatisfeito com a demora da equipe de TI em entregar os produtos. Nitidamente um problema nos dois lados da moeda.
Só que temos um problema que chama atenção aí: se um gestor leva dois meses só pra aprovar um diagrama "perfeito", por achar que consegue refinar cada mínimo detalhe só fazendo alguns fluxogramas (ainda mais sem ter a menor idéia do que é preciso usar de tecnologias para implementar!). Isso não é claramente um problema do modelo Waterfall, no qual o desenvolvimento ágil visa tanto combater? Não existe software perfeito, muito menos no papel, onde é fácil elencar o que um desenvolvedor tem que implementar (ainda mais tendo 0 conhecimento em desenvolvimento).
A consequência é que já sinto que a equipe se encontra bem ressentida, o que obviamente prejudica ainda mais a performance dela.
2. Propostas para tentar "virar a chave"
Bom, todo esse contexto que listei foi o que consegui perceber em 5 dias, conforme tanto a equipe quanto a gestão foram me apresentando. Uma vez que a equipe sentiu que não conseguiria simplesmente convencer a gestão, combinamos algumas coisas em paralelo (o que já não é algo saudável, mas não duvido que tenham motivo para fazer isso) para tentar evitar mais um ano de atrasos, bem como um desenvolvimento precário onde cada um se encontra isolado do outro.
2.1. Definir prioridades
Como tudo gira em torno de um acesso unificado a vários produtos, chegamos à conclusão que precisamos desenvolver um portal de acesso unificado, "para ontem". Mas por quê?
Inicialmente, estava-se trabalhando com a idéia de implementar a arquitetura de microsserviços (que eu particularmente acho uma péssima ideia, ao menos em uma equipe inexperiente). Por conta disso, cada um estava 100% dedicado à um módulo, dentro de todo o contexto que apresentei. Porém, estavam basicamente fazendo módulos sem a existência do portal, que inclusive culminou na história do produto que faz login em plaintext. Obivamente, um buraco de segurança digno de medalha "gohorse".
O problema estava no seguinte: apesar de cada um ter sido delegado como responsável por um produto (sozinho), aparentemente existe uma troca de "prioridades" frequente, no mínimo semanal. Na incapacidade por parte da gestão em definir prioridades, não há nem sinal de um portal de acesso, muito menos de uma versão concreta dos outros 4 dos 5 produtos. Isso acontecendo, porque se alguém parava de trabalhar naquele produto, ninguém mais estaria trabalhando nele.
Ora, se cada um trabalhava individualmente num produto, pode ficar até semanas sem tocar nele, mais ninguém trabalha nele e não existe ao menos um portal para inserí-los, como existe a possibilidade desses serviços se comunicarem? Tudo bem, sei que as APIs melhoram um pouco isso,
mas se não existe trabalho em conjunto, vai ser um trabalho impossível interligar essas coisas em um lugar só posteriormente.
Analisando isso, chegamos à conclusão listada abaixo, no ponto 2.2.
2.2. Chega desse papo de versão "1.0": vamos caminhar para a cultura DevOps
Acho que dado todo esse contexto, obviamente levar meses pra fazer algo completo e que pode simplesmente ser descartado é uma péssima ideia. Tudo isso custa tempo e, consequentemente, dinheiro (mesmo que hoje, a gestão e os sócios não consigam enxergar isso).
Ao invés disso, apresentei dois princípios básicos da cultura devops: a responsabilidade compartilhada e as pequenas entregas. Acho que nesse ponto aqui, todos sabemos que descartar o "desenho" de um software é mais barato do que descartar o software inteiro. Né?
Isso já estava e está acontecendo, dado que estou trabalhando lá apenas há uma semana.
Uma coisa é certa: não dá pra trabalhar do jeito que está, e toda a equipe sabe disso. Infelizmente, no geral a equipe não tinha a menor noção desses assuntos, principalmente por conta da "opinião forte" por parte da gestão. De tudo o que precisa ser mudado, realmente acredito que essa é a mudança que precisa ser feita "para ontem".
Uma vez que definimos, de maneira generalizada, o que é mais importante para que todo o resto dos produtos possa ser implementado, chegamos à conclusão de que devemos tentar executar esse desenvolvimento do portal de acesso, nesse estilo de trabalho, afim de apresentar o resultado e tentar convencer a gestão e os "stakeholders" de que esse é o único jeito viável de fazer alguma coisa sair do papel.
2.3. Queremos adotar uma stack a ser utilizada, mas não temos o discernimento para isso
Como o uso do PHP foi totalmente arbitrário e nem mesmo pensado, também chegamos à conclusão de que, provavlmente, talvez nós deveríamos trocar de stack. Conforme já apresentado, ninguém lá tem um longo tempo de estudo com PHP, e aparentemente toda tentativa desenvolver backends ou APIs foi em cima do PHP e de Python (esse segundo, somente no ambiente cloud).
Queremos decidir isso "de caso pensado", levando em conta principalmente a inexperiência e a necessidade de confiar em boas plataformas para prover funcionalidade comum (coisa que, no geral, sabemos que qualquer framework decente faz).
Mas tenho pra mim que o principal pode estar na linguagem, bem como na standard library da mesma. Sei que nesse sentido, PHP não tem a melhor das famas, mas não tenho o discernimento necessário para decidir para opinar sobre ele. Peço que opinem acerca disso.
Como todos na equipe conhecem Javascript ou Python, e elas serem praticamente indispensáveis (no front-end e em automações de CI/CD, por exemplo), também já estão em uso, eu acredito que sejam boas escolhas para desenvolvermos os produtos listados (o que está em prod hoje já usa Python). Nesse sentido, parecem boas opções, principalmente em sua curva de aprendizado.
Particularmente, pensei que opções como Java e C# que, apesar de trazerem uma complexidade maior para aprender, fornecem em troca uma quantidade abusrda de recursos padrão (de bibliotecas e de sintaxe), além de também terem bons frameworks estáveis e em uso pelo mercado (Spring, ASP.NET).
Particularmente, estudo programação há uns 3 anos e estou no terceiro semestre do curso de Ciência da Computação; e, na última metade desse tempo, estive estudando C#. Inclusive, até havia começando um grupo de estudos, conforme publiquei em Procurando estudantes de C#/.NET para desenvolver projetos em grupo
3. Conclusão: o ponto de vista de um mero estagiário
Não sei como vai soar para você que é experiente, mas tudo isso foi raciocínio que eu, que comecei meu primeiro emprego como programador há 1 semana atrás, pensei após esse curto período na empresa. Fora algumas automações em Python que desenvolvi em trabalhos administrativos, todo meu conhecimento é de estudos, sendo agora neste emprego onde devo aplicá-los com muita cautela.
Sinto que o pior problema é o de gestão; seja pela má comunicação, seja pela falta de qualificação mesmo. Não dá pra tocar uma equipe de TI só fazendo analogias rasas, muito menos sendo extremamente detalhista com planejamentos que tirariam o sono de qualquer engenheiro.
Se você leu até aqui, pelo desculpas pelo textão. Tentei ser o mais profissional e organizado, pois realmente me importo com o problema, e não sou do tipo que arrega pra problemas. Só me dou por satisfeito se resolver isso. E o principal: obrigado por ler até aqui ;)