Você quer pastel ou um software ?

Imagine o cenário: um prazo mínimo, uma equipe enxuta, uma grande demanda e a enorme necessidade de mudança do negócio. Imaginou? É, eu sei. Também já tive pesadelos com isso.

Profissionais de desenvolvimento normalmente estão acostumados a mensurar ou a negociar seus prazos, o que, convenhamos, é muito mais confortável. Surge a demanda, é estimado ou negociado um prazo de entrega da feature e no fim todos ficam satisfeitos. Esse é o melhor dos mundos, não é? Infelizmente, as coisas não são sempre assim. Em alguns casos (ou seriam muitos casos?), os prazos são impostos pelo negócio. Não ocorre uma estimativa ou negociação, simplesmente é informada a necessidade, e as demandas normalmente são para ontem. Aí, meus amigos, não é fácil para ninguém.

Fluxograma_GoHorse

Tudo muda muito rápido, o mundo muda muito rápido e você tem que entregar tudo muito rápido. Horas extras de trabalho, poucas horas de sono, profissionais estressados e, claro, entregas nem sempre bem sucedidas, aumentando o cu$to do desenvolvimento do software.

Na correria para cumprir um prazo imposto pelo negócio, somos tentados a abandonar as boas práticas que aplicamos no dia a dia e a deixar o falecido goHorse, que as equipes tanto lutaram para extinguir, ressuscitar.

Isso posto, reforça-se a necessidade de uma maior proximidade da empresa com as equipes de desenvolvimento para que entendam como as coisas funcionam lá pelas bandas daquela gente “estranha” viciada em café.

Para o cliente que demandou o desenvolvimento, ter esse entendimento facilita na hora de solicitar uma mudança. É importante que haja um comprometimento com o produto que está sendo desenvolvido. O cliente deve, de fato, tomar posse do seu produto e exercer seu papel no processo. E, para os profissionais, cada vez mais vemos o aumento da necessidade do domínio do negócio por parte das equipes para que possam entregar produtos que realmente agreguem valor.

Ter um grande desenvolvimento pela frente com um prazo ínfimo causa preocupação, mas não pode causar desespero. Às vezes, o bicho é menos feio quando enfrentado com calma. Mas, para se ter calma em uma situação assim, é fundamental uma equipe experiente, focada e comprometida, um correto planejamento das features aplicando-se a técnica de divisão e conquista, uma metodologia de desenvolvimento consistente, madura e adaptada {a sua realidade, e o envolvimento real do cliente.

Não caia na tentação de abandonar as boas práticas por causa de uma demanda. Seja fiel ao que você acredita e tanto batalhou para que funcionasse. Ao final da entrega, faça uma retrospectiva para um balanço do que deu certo e o que deu errado durante esse desenvolvimento e dê os feedbacks com honestidade.

Na prática, para o profissional estar diante do cenário aqui discutido não é prazeroso, muito menos um estímulo para prosseguir desenvolvendo, mas é algo que deve ser encarado e discutido para que se possa melhorar. Não pode haver acomodação. Eu sei que muitas das vezes é difícil explicar ao cliente o seu papel no processo de desenvolvimento, mas isso é de suma importância para que ele entenda que desenvolver software não é como fazer caldo de cana, que fica pronto em poucos minutos.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s