em Produtos

Um homem entra numa alfaiataria para fazer um orçamento. Ele precisa de um traje completo, mas ele gostaria que o profissional utilizasse o material (tecidos, linhas) que ele já possui. Contudo, não sabe dizer qual o formato do material e qual a metragem, se as cores combinam com o traje que ele deseja, quanto tempo levaria para transportar o material para a loja, se está limpo e disponível para o começo do trabalho. Para melhorar, avisa que outra pessoa está trabalhando em outro traje, compartilhando esse mesmo material e que não podem conflitar.

– E então, em quanto tempo é entregue e quanto vai me custar?

Parece bem confuso vendo dessa forma e provavelmente você que está lendo não saberia nem por onde começar esse orçamento, certo? Porém, em desenvolvimento de software isso é mais comum que se imagina. E os clientes não entendem porque é tão difícil passar uma estimativa, se temos tantas informações sobre o que é preciso fazer.

Difícil, mas não impossível. Se as informações estão vagas, podemos utilizar o que temos, tentar buscar mais, não falar em datas fixas, etc. Aqui vão algumas dicas de como lidar com uma situação dessas.

Para começo de conversa, sem pressão

É importante nesse momento não ceder às pressões que normalmente acompanham essas solicitações. E não é exatamente culpa ou maldade do solicitante, é bem provável que ele também esteja sob pressão para passar um prazo, para fazer orçamentos trimestrais, semestrais, etc. Então, o primeiro passo é manter a calma e focar no objetivo.

Apresente ao cliente a falta de visibilidade atual e o quanto isso impacta numa previsão, qualquer que seja. Mostre todos os pontos obscuros da solicitação antes de fazer qualquer tipo de estudo e tente clarificá-los. Se não há como fazê-lo, não há como nem começar, certo?

A seguir, faça uma lista de definições que o time precisa para poder seguir. Não basta apenas saber qual o ambiente, tecnologias utilizadas, quais são os sistemas vizinhos que podem ser impactados, mas também de onde serão extraídos os dados a serem exibidos, qual a frequência de consulta desses dados, qual o volume de transações, períodos de carga máxima e mínima – enfim – a maior quantidade de informações possível, sem precisar entrar no nível de detalhes (discutir telas, campos, fluxo interno de informações, por exemplo).

Junto com o time, revise o que foi pedido e todas as informações que foram fornecidas. É suficiente para um previsão mais macro? O time se sente confortável em assumir uma data com uma margem de erro baixa? Caso contrário, cave mais.

Se existem possibilidades de bloqueio, liste-as

Por mais informações que seja possível descobrir, há sempre fatores que são externos ao desenvolvimento. Isso é muito comum em ambientes mistos em que existam aplicações vizinhas, rotinas de segurança, burocracias nos deploys, regras de acesso muito estritas, limitações de budget para infra, etc. Liste absolutamente tudo o que conseguir!

O cliente precisa estar ciente dos riscos envolvidos e das possibilidades de fatores externos interferirem na entrega. Se o time não dá visibilidade para que os riscos possam ser mitigados o quanto antes, não vai colar puxar essa carta da manga quando o projeto estiver atrasando. Claro, imprevistos acontecem em qualquer lugar – e sem aviso, óbvio, mas devemos levantar tudo o que é sabido que pode atrapalhar antes do primeiro hello world.

Não esqueça de considerar afastamentos previstos no time. Férias, feriados, licenças, tudo o que for já previsto, deve ser listado com uma solução elencada, pois vai impactar no projeto – a depender do tempo previsto, pode impactar bastante.

Nada é escrito em pedra, mas pode calcificar

Por mais que sua previsão não seja exata, por mais que as possibilidades de dar problema sejam elencadas e ajustadas com o cliente, ao passar uma data você será cobrado por ela. Então, esteja bem seguro e alinhado com o time ao passar a estimativa, deixe sempre muito claro sobre possíveis atrasos e se for possível estime uma margem de erro.

Claro, uma pequena margem de segurança também é recomendável, mas sem exageros. Além disso, revise o plano constantemente e ao menor sinal de problemas na previsão, alerte o cliente.

Uma última dica: bastante cuidado com estimativas muito distantes. O cenário pode mudar com o tempo e todo o levantamento feito se tornar inválido. Tente sempre revalidar o planejamento com a proximidade do início do projeto.

  1. “Então, esteja *bem seguro* e alinhado com o time ao passar a estimativa, *deixe sempre muito claro sobre possíveis atrasos e se for possível estime uma margem de erro.*
    *Claro, uma pequena margem de segurança também é recomendável, mas sem exageros.* Além disso, revise o plano constantemente e ao menor sinal de problemas na previsão, alerte o cliente.”

    Não sinto que fica muito acionável assim, Manu.

    Acho que um dos segredos de reduzir riscos e incertezas é estabelecido pelos tamanho das entregas e intervalos de datas entre entregas que são acordadas entre quem entrega e quem receberá e tomará valor…
    Quanto menores e frequentes, mais visíveis/tangíveis/entregáveis em fluxo contínuo, melhores parecerão alinhadas às expectativas ou qualquer desalinhamento ou mudança será detectado junto com o cliente…

    Fazer a estimativa em si, como citado no trecho acima, não resolve o problema…
    Aliás, acho que muito comum uma data de expectativa já estar previamente definida/esperada.

    Se for pra “estimar”, buscaria esta linha no planejamento: “- Que valor pretendemos entregar na próxima semana?”
    E sempre checar “O que podemos enxugar para garantir o mínimo incremento suficiente na direção de entregar o valor esperado pelo cliente”?

    2 cents ou -2 cents
    =P

    • Idealmente, conseguimos convencer o cliente/chefe de que estimativas e ciclos mais curtos são mais precisos (e são) e saudáveis. Infelizmente nem sempre conseguimos tanto. Há casos e casos. Eu já fico feliz em ter que dar (pre)visibilidade para 3 meses ao invés de 1 ano, como acontece muito no mercado. Quanto mais distante, mais sujeito a mudanças de cenário, prioridades, riscos, falhas de integração com outros projetos, etc.

      Mas esse é um tema muito bacana para ser abordado em outro post, valeu :). Já pro backlog.

  2. Muito bacana o artigo Manuel. É legal ver esta empatia com o cliente, e entender que algumas vezes ele precisa de uma estimativa, e que temos que ajudá-lo da melhor forma possível nisso.

    Um ponto que eu adicionaria: é possível que o pedido do cliente seja muito complexo, e no momento que se levante a lista de coisas que precisam ser definidas, chegue-se à uma lista gigantesca. Neste momento, vale a pena um passo atrás, e se comprometer somente com um subconjunto (as calças, por exemplo). E, caso não seja possível dar uma estimativa com o qual o time se sinta confortável, sugiro o bom e velho “não” – infelizmente, em muitos casos isso não é uma opção, pois quem prometeu não é quem vai entregar e tals – mas isso já é uma outra história 🙂

    • Exato, Ale. O importante é que todo mundo fique ciente dos riscos e formas de mitigá-los. Esse levantamento inicial pode até servir de insumos para que o solicitante “desprometa” o que havia prometido no escuro 😉

      Valeu pelo comentário.

Os comentários estão encerrados.