A partir dos anos 2000s, métodos ágeis para desenvolvimento de software começaram a emergir com grande força após o manifesto ágil. Com o passar do tempo, a prática de se realizar projetos focando na entrega, com agilidade e flexibilidade se disseminou e hoje já toma conta de grande parte dos times que criam não apenas software, mas diversos tipos de entrega.
Apesar disso, ainda há resistência em adotar práticas ágeis quando se deseja desenvolver um novo produto ou serviço. A metodologia de desenvolvimento pode até seguir tais práticas, mas a mentalidade por trás do trabalho permanece inalterada.
Não é incomum no mundo de desenvolvimento haver projetos de novos produtos e tecnologias englobando um conjunto muito grande de funcionalidades e funções definidas já na largada. Isso não significa que o projeto será um fracasso, mas assumir um compromisso muito grande desde o início, ainda com pouco conhecimento, reduz bastante suas chances de sucesso e aumenta o desperdício que inevitavelmente vai ocorrer durante uma execução.
É claro que a base para grandes investidas como essa têm suas motivações, e elas não podem ser negligenciadas, afinal estão intimamente ligadas aos desejos do cliente. Costumeiramente, um stakeholder procura grandes investidas porque deseja atingir um grande objetivo já tendo
uma estimativa do valor total de investimento necessário. Realizar pequenos investimentos podem o deixar inseguro do retorno que terá no futuro ou exigir esforços burocráticos que ele não está disposto a fazer. Em outros casos, há o desejo de se proteger do risco do desenvolvimento, garantido em contrato uma entrega que atenda a suas necessidades.
É importante entender que ao realizar um acordo de trabalho muito grande ou que permeie por um tempo longo, com incerteza inerente, o curso do desenvolvimento e da descoberta irá invariavelmente alterar o que precisa ser feito para se obter o resultado desejado. Por consequência, a estimativa inicial provavelmente estará errada, quase sempre com esforço necessário superior ao disponível, e atritos irão surgir.
Ao criar acordos de trabalho menores, dentro do contexto ágil, uma série de benefícios surgem naturalmente. A começar pela redução de riscos, para o executor, eventuais trabalhos extras serão absorvidos mais facilmente. Já para o stakeholder, decresce a quantidade de itens que terão de ser deixados de lado.
Outro ponto positivo é a flexibilidade: é muito mais fácil realizar pequenas alterações ou realizar novos acordos do que revisar um grande emaranhado de itens previamente acordados.
Além disso, acordos enxutos permitem um foco maior para se descobrir o tamanho real das atividades, afinal, menos itens a serem explorados pelos times reduzem as incertezas. Como resultado, as entregas de desenvolvimento irão gerar valor com maior celeridade, permitindo testes mais rápidos junto ao usuário final (prática recomendada pelo conceito da startup enxuta) e com maior facilidade de acompanhamento e controle pelo stakeholder.
Todo o contexto apresentado acima coloca frente a frente a necessidade de foco do agora do time de desenvolvimento contra a legítima demanda do stakeholder de ser saber o todo, então como resolver esse conflito de uma forma que atenda aos dois lados?
De início, é muito importante que o conjunto stakeholder e time de desenvolvimento tenha boas pessoas de produto que possam ajudar a esclarecer o todo. Existem metodologias que podem ajudar nesse processo, como o Lean Inception criado pelo Paulo Caroli ou o User Story Mapping formalizado pelo Jeff Petton. Processos como esses ajudam o stakeholder a entender melhor seu novo produto/processo/serviço e a priorizar o que o time deve atacar para atingir os primeiros objetivos.
Somente após a priorização os times poderão estimar adequadamente os esforços e formalizar o acordo de trabalho sobre o que é prioritário e com maior chance de sucesso. De forma complementar, o time pode estimar o esforço do todo para dar um norte ao stakeholder, mas ele não pode se apegar à estimativa hipotética, caso contrário irá cair nas mesmas armadilhas dos grandes acordos.
Em resumo, toda essa discussão trata de melhorar a vida de todos dentro da execução de projeto ou desenvolvimento de um produto ou serviço. Sendo assim, aos stakeholders, é importante entender que deve ser dado um passo de cada vez. Já aos desenvolvedores, entendam, sem uma visão do todo dificilmente um stakeholder irá embarcar em uma investida, ninguém vai até uma construtora contratar apenas uma fundação sem pensar no que virá depois.
Aqui na MMZtech nos preocupamos com a necessidade do stakeholder de vislumbrar o todo. Podemos auxiliar na construção dessa visão e torná-la realidade rapidamente aliando metodologias de gestão ágil e uma equipe de excelente capacidade técnica.
Tem uma ideia de produto ou problema a resolver? Fale conosco, nós podemos ajudá-lo a fazer acontecer.
