Como um programador pode desenvolver um projeto dentro do tempo estimado?

Você é programador e chega para mais um dia de trabalho, dentre eles, estão atividades de solucionar problemas nos projetos que já estão em produção, tentando encontras as soluções mais práticas possíveis para se livrar dos problemas, ou então sua empresa é tão bem organizada e única no mundo, que tudo que constrói, dura para sempre. Quem dera, a grande realidade é que não é bem assim que tudo funciona.



Então chega um novo projeto para estimar, e você sem ter muitas informações sobre o mesmo, lhe perguntam para fazer a estimativa para entrega do item funcional.

Como então especificar e dizer qual o tempo necessário para desenvolver este projeto, desenvolvimento, análises e etc., sendo que muitas das vezes, esta estimativa tem que ser feita o quanto antes? E, se o projeto for grande, como é possível estimar o tempo certo de tudo isto?

A grande realidade é que: não há como. Impossível. A estimativa é simplesmente uma medida de sorte, e até grandes programadores no Google erram estas estimativas.

Certa vez, houve um projeto para o feedback do Google, e o programador falou que poderia reescrever o código desta plataforma em 2 a 3 semanas, com menos da metade de linhas de código existentes na plataforma na época, usando AngularJS. Passou 4 semanas, e ainda não havia finalizado, mas estava quase, e entregou o projeto com atraso.

Se até no Google as estimativas de desenvolvimento de um projeto não dão certo, então nós, meros mortais, como poderemos estimar corretamente o término do desenvolvimento de algo?

Mas, se for um projeto pequeno, como uma API rest por exemplo, isto passa a ser um pouco mais previsível.

Seguem algumas dicas para que você, programador, não importa a linguagem que utilize, tenha em mente dos seguintes tópicos para que possa conseguir desenvolver e entregar seu projeto no tempo estimado (assim espero):

1. Preste atenção no fluxo dos dados

Isto parece bem elementar, mas saber o que um sistema irá receber, por onde irá passar e tratar esta informação e a saída dele, é bem elementar. Ter isto bem organizado e bem claro, teremos uma ideia de tempo para desenvolvimento deste item.

Supondo que seja uma API Rest, veja se já possui modelo de dados, e toda sorte de mensagens de erro de retorno, para que não perca tempo inventando durante o projeto.

Aqui também seria o planejamento inicial, entender tudo o que precisará ser feito de fato.

2. Integração com o banco de dados

Veja se irá integrar com um banco de dados, ou vários. Tenha o levantamento de quantas tabelas precisarão ser acessadas, lidas, gravadas, para ter uma ideia do fluxo dos itens.

Inclua todos os mecanismos necessários neste fluxo, e tente imaginar quanto tempo irá levar para desenvolver, e, inclua um tempo maior caso haja problemas de conexão, instabilidades, ou problemas com componentes, como o OpenJPA, erros de entitys, daos, etc. Isto para Java, mas se for algo em ASP(.net), C# ou o que for, veja o framework de conexão com o banco.

Acredito que a conexão com o banco, é o principal elemento que deve ser pensado, e após ter ele funcional, o restante irá se resolver como um todo mais rapidamente.

3. Integração com serviços externos

Um erro bem comum é esperar que o serviço externo esteja disponível sempre, a hora que desejar. Mas não é bem assim. Por ser um serviço remoto, podem existir outros fatores de problemas, como falha de conexão, falha do tempo de resposta, e outros itens mais elementares como falha no certificado SSL, falhando a conexão com o mesmo (e não vale a pena tolerar erros de certificado, ou usar uma conexão sem criptografia e correr o risco disto entrar em produção e sair nos jornais, né!).

Se você já tem em mente tudo que fará com os dados entrantes, conexão com o banco, e conexão com os serviços, é hora de pensar nas próximas etapas.

4. Apresentação ao usuário

Após ter ideia do fluxo dos dados, ter o fluxo mapeado, conexões e tabelas, e quais serviços, tipos de conexão (SOAP, REST JSON?) e métodos que serão necessários para as conexões, agora é hora de começar a pensar no tempo gasto para a apresentação ao usuário da sua aplicação, ou seja, a interface.

Se for uma API Rest, a apresentação nada mais é que requerer os parâmetros em formato application/json corretos, no formato esperado.

Se for uma aplicação Web, convém saber se irá precisar desenvolver o front-end, ou mensurar o tamanho do trabalho para adaptar layouts desenvolvidos por agências que fazem um html geralmente inútil para adaptar em layouts de alguns tipos de sistemas. Se a agência for fazer este trabalho de adaptação, melhor, mesmo assim poderá gastar um tempo explicando como funciona sua aplicação para que a outra parte possa entender como integrar.

Trabalhamos com cenários híbridos, linguagens de server-side de toda sorte de tipos e maneiras que o ideal era ter apenas uma camada de API Rest para os serviços de back-side, e um .html totalmente funcional por si só com esta API, mas nem sempre é assim que funciona.

Se for integrar com plataformas de CMS, o usuário quer estar apto a clicar em "editar" e conseguir visualmente editar o conteúdo, e geralmente este trabalho de integrar o html a algum template, não é nada simples. (Joomla, Drupal, Wordpress, ou plataformas proprietárias como OpenText Portal/Vignette/WEM ou Sharepoint).

5. Documentação

Muito elementar em vários cenários, mas necessário para conhecimento de próximas equipes que irão atuar com as informações necessárias.

A passagem de conhecimento se torna uma norma obrigatória, e ter uma documentação seguindo no mínimo o mesmo fluxo destas dicas, ajudará alguém entender como funciona a aplicação em si.

Calculando o tempo

Com todas estas informações, pense mais ou menos em quanto tempo irá integrar com o banco de dados, e os serviços, e se possível, já inicie um projeto draft ou veja modelos na internet de quão complexo pode ser estas tarefas, assim como se tem domínio sobre o framework utilizado, para evitar problemas no meio do caminho.

Assim que houver uma estimativa, sempre tente conseguir algum tempo além para tarefas de validação das entradas.

Não pegue o valor que chega do usuário e jogue direto no banco de dados, trate-o primeiramente. Veja se aceita nulo, brancos, ou se tem espaços no início e final, e etc. Se for dados de telefone, faça uso de regex ou outras formas de validar estes números, garantindo integridade dos dados para a base de dados não ficar cheia de anomalias.

Você precisa ter este tempo para validação, sempre, e não pode dispensá-lo de qualquer maneira, pois isto pode colocar em risco a qualidade do desenvolvimento do seu projeto.

Se precisar criar a base de dados, não esqueça das regras de normalização essenciais para estruturar os dados da melhor forma possível. Entidades fracas, fortes, devem ser mapeadas, e tabelas com mapa de dados sempre devem ser separadas, e seus valores devem ser, ao meu ver, populados pela instalação da sua aplicação no primeiro uso.

Montando as tarefas

Com todas as informações, e alguns drafts de projetos realizados para entender talvez o tamanho da bagunça, crie etapas, tarefas, e coloque uma quantidade de horas para cada etapa.

Tarefas como: 

1. Desenvolver a estrutura do projeto: 4 horas.

2. Desenvolver a camada de acesso ao banco: 4 horas.

3. Levantar os serviços WSDL e realizar testes via SoapUI: 8 horas.

(e etc...)

Contemplando a estimativa

Um dos grandes problemas dos programadores, é o foco. Por vezes, não é culpa do programador, mas de outras pessoas que o distraem tirando o foco com outras perguntas e atividades do dia a dia. Portanto, ter foco, é elementar. Use fone de ouvido, escute alguma música que goste, e concentre-se na atividade central, pois ter tudo em mente, faz tudo andar mais rápido. Músicas com ritmo mais acelerado, para alguns podem ajudar. Outros dizem que sem música, conseguem se concentrar mais fácil. Veja qual é a melhor opção.

Tente conseguir cumprir as etapas mais difíceis dentro do prazo estimado, para conseguir mais tempo no final para etapas de validação, e organização do código.

Isto seria algumas dicas para um programador conseguir desenvolver um projeto, ao meu ver, algo pequeno, como algo pontual para complementar algum projeto já existente, já que grandes projetos, devem envolver mais pessoas, e gastarem mais tempo de planejamento para que tudo venha dar certo.

Conclusão

Para projetos pequenos, estas dicas podem lhe ajudar a desenvolver o que precisa, conseguindo atender o tempo no prazo estimado.

Para projetos grandes, praticamente o planejamento e a estimativa, gastam 40% do tempo de todo o projeto. Ter menos tempo que isto, pode significar um aumento do tempo não previsto no final, perdendo prazos ao cliente. Planejar, é essencial para qualquer projeto, não só de sistemas.