metodolodia ágil - Buildbox IT Solutions

Gerencie sua vida como um gerente de projetos

Por que você deveria gerenciar sua vida como um gerente de projetos?

by Buildboxon 29 agosto 2017in Desenvolvimento Ágil No comment

Cada vez mais as empresas estão adotando metodologias e ferramentas como Agile, Scrum e Kanban, que promovem uma produção rápida, iterativa e enxuta, para entregar mais rápido produtos de alta qualidade. Para atingirem esses ganhos, são utilizados métodos que se baseiam em uma comunicação face a face diária e workflows visuais. Desta forma, surge o seguinte questionamento: Esses métodos podem ajudar as equipes de trabalho a ficarem mais alinhadas, simplificar tarefas e atingir metas coletivas mais rapidamente, será que eles podem também ajudar as pessoas a serem mais produtivas em suas vidas pessoais? Em um artigo da Harvard Business Review, escrito por Dana Rousmaniere, foi levantada a questão de como a aplicação de metodologias e ferramentas de Gerenciamento de Projetos podem influenciar positivamente nossa vida pessoal. A autora do artigo, entrevistou Frank Saucier, um executivo e treinador Agile da empresa FreeStanding Agility, sobre como ele aplica esses métodos em sua vida. Veja um trecho editado da conversa: O que fez você decidir tentar algumas destas soluções de trabalho em sua casa? Grande parte do meu trabalho envolve treinamento de equipes para que elas obtenham maior desempenho e sejam auto-organizadas. Minha esposa e eu tivemos uma discussão sobre como nossa família de cinco pessoas é uma equipe e que através de abordagens semelhantes poderíamos nos beneficiar. Quais práticas de produtividade em específico você trouxe para sua casa e família? Frank então levanta algumas práticas utilizadas por ele e sua família:

Quadro visual

Eu utilizo uma abordagem do Personal Kanban para gerenciar o fluxo de meu trabalho e agenda doméstica. Como instrutor, treinador e consultor, existe uma boa mistura entre trabalho, cliente, casa e família, além de itens pessoais que estão constantemente em competição de minha atenção. O quadro me ajuda a controlar tudo e manter as coisas fluindo – a ideia é ser eficaz e estar focado na coisa certa no momento certo. O quadro se parece com isso:

Quando estamos ensinando as equipes sobre o trabalho “invisível” que é o desenvolvimento de software, o quadro Kanban na parede ajuda a tornar tudo mais visível. A parede se torna um guia para o trabalho e ajuda a desenvolver hábitos do que deve ser feito quando existe alguma anotação visivelmente presa em uma das coluna de afazeres (coluna “To Do”). Isso aplica-se bem em nossa casa. Usamos colunas como “A fazer” (“To Do”), “Fazendo” (“Doing”) e “Feito” (“Done”) – ou, as vezes, os dias da semana. Nós idealmente gostamos de ver o movimento das anotações ao longo do dia, desta forma temos o que é chamado de “fluxo”. Isso permite ver se de fato há progresso ou se algo está parado em alguma coluna (“A fazer” por exemplo). Os meus filhos adoram a abordagem tátil de fazer anotações e adiciona-las ao quadro. Por exemplo, eles podem colocar uma nota “Ir ao boliche” em nossa coluna de fim de semana. Isso ajuda toda a família a aprender incorporar novas ideias, negociar compromisso e se comunicar.

Reunião familiar

Quando usamos Scrum com as equipes no trabalho, muitas vezes elas estão em um ciclo de 2 a 3 semanas esperando, por “retrospectivas” para manter todos no caminho certo. Nossas reuniões familiares são muito parecidas com uma retrospectiva, onde conversamos sobre as coisas que são mais importantes para nós. Minha esposa e eu realizamos uma reunião familiar todo fim de semana com um modelo de agenda que inclui:

Um check-in de estados emocionais (bravo, triste, feliz, com medo). É importante fazer isso no início da reunião – o ponto é simplesmente conseguir ter pessoas presentes e ter espaço para dizer a elas o que se sente e por que.
Uma sessão para cada pessoa dar elogios para outras que eles apreciam. Isso ajuda a reforçar comportamentos positivos.
Uma sessão de tarefas, para que todos possamos colocar as coisas que precisam ser feitas em torno da casa e nos manter responsabilizados por elas a cada semana.
Listagem de problemas que precisamos discutir como uma família (por exemplo, as tarefas da última reunião não foram feitas, projetos da escola que as crianças estão trabalhando, as prioridades para a próxima semana, etc.)

Check-ins diários

Tentamos ter pelo menos dois check-ins durante o dia. No primeiro, tentamos jantar como uma família. Nos perguntamos sobre o que fizemos no dia, o que gostamos, erros que cometemos, etc. No segundo check-in eu e minha esposa, depois que as crianças estão na cama, vamos para a cozinha conversar sobre o nosso dia e o que está previsto para o próximo.

Planejamento Semanal

Toda Quinta-Feira, depois que as crianças estão na cama, minha esposa e eu nos encontramos na cozinha para falar sobre duas coisas: Os planos para o fim de semana e cronograma da semana seguinte, além disso falamos do que precisamos fazer para coordenar tudo isso.

Papel de Parede

Eu recentemente comecei um experimento usando uma imagem de fundo no meu computador que tem as seguintes áreas retangulares sobre ela: Para ler; Lendo; Em uso; Referência; Manter. Nesta imagem eu tenho uma área no centro que contém o meu ícone da lixeira. Eu movo os ícones para as respectivas áreas conforme eu vou trabalhando e vejo se organizando meus arquivos e marcadores de acordo com minha necessidade de interagir com eles irá me ajuda a ser mais eficiente. É uma experiência, mas ela já vem me ajudando a ser mais eficiente.

Plus / Delta

Eu também uso uma abordagem de feedback rápido chamada Plus/Delta. Ela é ideal para o final de um dia agitado, depois de um evento-chave, aulas ou eventos. Basicamente, basta pegar um pedaço de papel e desenhar uma linha vertical no meio. No topo da coluna da esquerda, eu coloco um sinal de mais (Plus) e no topo da coluna da direita, eu coloco o símbolo de menos (Delta) para representar as mudanças. Na coluna Plus, eu anoto todas as coisas que eu fiz e que correram bem. Na coluna Delta, eu anoto todas as coisas que eu faria de forma diferente em retrospectiva. É basicamente uma técnica de reflexão para a aprendizagem e encerramento rápido de algo.

Caixas de despesas

Cerca de uma vez por trimestre, minha esposa e eu jogamos um jogo onde listamos todas as possíveis despesas que sabemos que estão chegando. Isso poderia ser qualquer coisa, desde o carro precisando de pneus novos, planos de férias, sapatos novos para as crianças, etc. Em seguida, colocamos os itens em uma folha de papel com quatro quadrantes: Grande importância, Baixa importância, Alto custo e Baixo custo. Isso nos ajuda a ficar alinhados e saber quais planos precisamos fazer para cumprir nossos objetivos. Isso parece muita coisa. Quanto tempo estas coisas consomem? É realmente muito rápido. A maior parte do tempo é investida na criação destes sistemas, mas você não tem que começar tudo de uma vez, pois é um processo que está destinado a ser passível de evolução. Todos os dias, eu olho para o que eu tenho no quadro Kanban e tomo decisões de última hora sobre o que realmente precisa ser feito – literalmente leva cinco minutos. O que leva mais tempo é parar para olhar todas as coisas que você não pode atuar. Sabendo que, se a tarefa não está no quadro, ela não será feita naquela semana e desta forma consigo priorizar demais atividades. Foi difícil obter o envolvimento da sua família com estas técnicas? Foi e ainda é, estamos tentando ensinar nossos filhos que a família prospera quando todos nós contribuímos e colaboramos. Isso definitivamente capacita as crianças para saber que as decisões não são apenas tomadas por acaso e isso estabelece uma base para bons hábitos organizacionais. Algumas coisas soam do tipo baixa tecnologia (low-tech). O que acontece quando você não está na frente da parede? Existem ferramentas digitais que funcionam tão bem quanto? Eu gosto de usar ferramentas de baixa tecnologia, porque é mais importante aprender bons hábitos do que a aprender a usar uma ferramenta. Dito isto, há uma abundância de formas digitais para fazer a mesma coisa – um bom exemplo disso é uma ferramenta chamada Trello, que é de certa forma um quadro Kanban online. Como o uso destas ferramentas mudou sua vida familiar? Houve um beneficio imediato vendo todas essas coisas dispostas em um só lugar. Quando vimos exatamente o quanto estava em nossa responsabilidade, isso nos obrigou a tomar decisões sobre o que valorizamos. Foi bom para ficarmos alinhados, com horários, coordenando a família e as próximas prioridades. Menos coisas dão errado agora. Como funciona a reunião? Pode ser difícil para crianças e jovens manterem o foco em uma reunião de família. Nós fazemos a nossa em 15 minutos ou menos, cobrimos a mesa com papel branco e colocamos nossas anotações, além disso sempre tentamos fazer uma atividade familiar no final da reunião. Será que o aumento da organização em casa afetou sua produtividade no trabalho? De fato ajudou a me concentrar nas coisas mais importantes. Em nosso dia a dia, temos tempo limitado e estamos sempre sendo bombardeados com distrações e coisas urgentes (que nem sempre são). Então, temos que ser bons em discernir quando aceitar ou não uma interrupção, o que significa conhecer o que é mais importante – em casa e no trabalho.

A Buildbox aplica técnicas e métodos ágeis nos projetos de seus clientes. Veja agora quais as vantagens e como a sua grande ideia pode sair papel! Envie seu contato para a Buildbox e uma especialista entrará em contato para fazer um entendimento da sua solução!

Fonte: Tradução livre e adaptada de “Project Manage Your Life” (Dana Rousmaniere – 10/02/2015) Harvard Business Review – https://hbr.org/2015/02/project-manage-your-life

Desenvolvimento Ágil | Como lançar sua ideia

by Buildboxon 25 agosto 2017in Desenvolvimento Ágil One comment

Muito se fala hoje em dia sobre Desenvolvimento Ágil, Scrum, Startup Enxuta e outros termos famosos no mundo do empreendedorismo. Metodologias que prometem um lançamento mais rápido no mercado, correções e melhorias contínuas, possibilidades de mudanças estratégicas durante o desenvolvimento e chances muito maiores de sucesso. No entanto, ao explicar para um novo empreendedor, ou até mesmo gerentes e diretores de grandes empresas, as vantagens destes métodos, muitos receios surgem rapidamente, e o principal é sempre o mesmo: “Como posso fechar um contrato com uma empresa de desenvolvimento sem definir em detalhes o que irei receber no final do projeto?” Se você se encaixa em um desses perfis, prometo que este post será bastante esclarecedor. Projetos ágeis, ao contrário do que muitos acreditam, possuem um escopo que define o que deve ser feito. Tal escopo existe antes de o projeto ser iniciado e continua a existir ao longo do projeto até que ele seja encerrado. Entretanto, ao contrário de modelos tradicionais de desenvolvimento, este escopo não é fixado em contrato. Ou seja, caso o empreendedor perceba a necessidade de fazer ajustes no escopo para que a solução leve em conta seu aprendizado ao longo do projeto, ou mudanças nas circunstâncias, ele pode. Em projetos ágeis, o escopo é revisado frequentemente para garantir que equipe dedique seus esforços ao que é mais prioritário em cada etapa do projeto. Como o escopo não é fixo, como você pode saber o que será entregue ao final do projeto, quanto será gasto e qual será o tempo total consumido? Para compreendermos essa questão, vamos começar tratando de um assunto fundamental: previsibilidade.

A ilusão da previsibilidade O que torna o contrato tradicional, de escopo fechado, tão atraente para o empreendedor? Ele acredita que contará com:

Custo previsível
Prazo previsível
Escopo previsível

Ou seja, acredita que sabe exatamente o que receberá, quando e por qual preço, o que é um cenário extremamente atrativo para qualquer um disposto a investir em um novo projeto! Olhando pelo lado da empresa que prestará o serviço de desenvolvimento, no caso, nosso lado, as perspectivas também são muito interessantes:

Receita previsível
Prazo previsível
Demanda previsível

Isto é, em teoria, saberíamos exatamente o que precisa ser feito, quanto iremos faturar com o projeto e quando estaremos livres para alocar a equipe em outra demanda. Bom, enfim, se é um cenário bom para o empreendedor e é bom para a empresa que desenvolverá o sistema, então onde está o problema? O problema está na Premissa da Previsibilidade, que se divide em duas:

1) O empreendedor sabe exatamente o que deseja no início do projeto.

Nos projetos de software (Aplicativos Android e iOS, Sites institucionais, Painéis Administrativos, Sistemas embarcados, e qualquer outro), o empreendedor tipicamente não sabe com exatidão como deseja que o software seja. O que ele sabe é o problema que tem em seu dia-a-dia e espera que o software o ajude, ou as ideias únicas que pretende colocar no mercado com seu nova solução. Isto é, ele sabe de forma geral O QUE o software deve fazer, e quais problemas deve resolver. E durante o projeto, é comum esta visão de negócio permanecer basicamente inalterada, com pouca ou nenhuma mudança. Por outro lado, o empreendedor precisa saber com bastante clareza que, quando falamos de software, para todo problema existem inúmeras maneiras de solucioná-lo. Por exemplo, uma grande empresa, com mais de 10 mil funcionários, gostaria de avaliar seus funcionários anualmente para que pudesse identificar deficiências de formação e solucioná-las através de treinamentos apropriados. Avaliar essa quantidade de pessoas leva à necessidade de construir um sistema e a empresa investe na contratação de uma Software House para desenvolvê-lo. Existem inúmeras formas e tecnologias que poderiam ser empregadas para construir um sistema desse gênero. Empreendedor e fornecedor podem acordar uma abordagem, traçando um escopo inicial e, ao longo do projeto, descobrir a possibilidade de simplificar ou facilitar partes do sistema fazendo algo que não havia sido previsto originalmente. Note que, neste caso, altera-se a forma de resolver o problema, mas este permanece inalterado ao longo de todo o projeto. Esperar que a visão de negócio, os problemas que devem ser resolvidos, isto é, O QUE o software deve fazer, se mantenham estáveis é algo razoável, pois é comum acontecer, mas esperar que a solução necessariamente seja a mesma imaginada originalmente, isto é, COMO o software deve atacar cada ponto, é pouco produtivo, porque raramente acontece.

A possibilidade de durante o desenvolvimento podermos aprender, aprimorar e realizar mudanças de abordagem é algo muito positivo. Diria mais, atualmente, no mundo extremamente dinâmico que vivemos, essa flexibilidade é vital para novos projetos!! Vital porque garantem que a solução estará continuamente sendo atualizada para gerar o máximo de valor para os usuário finais, além de poderem resultar em economia de dinheiro e tempo para o empreendedor, quanto para a empresa que faz o desenvolvimento.

Como se pode notar pelo exemplo, no início do projeto de software, o empreendedor e a equipe visualizam soluções que representam o escopo inicial do projeto. Ao longo do tempo, à medida que aprendem mais e avançam, é comum surgirem formas alternativas de resolver o problema, às vezes mais simples, mais rápidas de implementar ou com resultados mais expressivos. Se tais alternativas já fossem conhecidas desde o início do projeto, poderiam fazer parte do escopo original, mas como é comum que elas só sejam descobertas ao longo do projeto, é importante que possam ser incorporadas. Como o empreendedor aprende ao longo do projeto, ele naturalmente reavalia suas necessidades e prioridades e, portanto, altera o escopo para incorporar seu aprendizado. A visão do sistemas, e quais pontos precisam ser atacados pelo software (O QUE) permanece praticamente o mesmo, mas a forma de resolver cada ponto (COMO) está continuamente em evolução. Sendo assim, fica bastante claro que o escopo não é algo previsível, e fixá-lo freqüentemente se revela uma má idéia (veremos mais à frente o porquê).

2) A empresa de desenvolvimento é capaz de estimar com perfeição e entregar o sistema no dia combinado.

Supondo que o empreendedor realmente soubesse tudo o que quisesse e como seria cada detalhes da solução, não mudando nem um mínimo detalhe ao longo do desenvolvimento, bastaria que a empresa contratada fizesse uma boa estimativa para que a previsibilidade sobre o escopo e as demais variáveis do projeto fosse viável. Entretanto, para que a estimativa fosse minimamente acertada, seria preciso que o empreendedor comunicasse todos os detalhes do sistema para a equipe e que a mesma compreendesse tudo perfeitamente. Isso é difícil devido a pelo menos dois problemas sérios:

O empreendedor normalmente não conta todos os detalhes, até porque não os conhece. Em qualquer sistema que tenha mais que uma meia dúzia de funcionalidades, a quantidade de detalhes tende a ser extremamente elevada. Sistemas são complexos, porque existem muitas combinações que podem gerar os mais diversos tipos de comportamentos, muitos dos quais inesperados. Estes detalhes, inúmeros dos quais não serão ditos pelo empreendedor, fazem grande diferença no custo e no prazo do desenvolvimento. Portanto, não sabê-los antecipadamente torna o esforço de estimar o sistema bastante limitado.
Ainda que o empreendedor apresentasse todos os detalhes seria preciso que a equipe compreendesse tudo corretamente. Como as especificações dos projetos costumam ser expressas de forma escrita, a equipe pode interpretar o que lê das mais diversas formas, o que dá margem para que ela erre feio na estimativa simplesmente por ter interpretado incorretamente os requisitos.

Por tudo o que foi dito, e ao contrário do que muitos gostariam de acreditar, previsibilidade normalmente não passa de uma ilusão na área de software. O empreendedor acaba se convencendo que acredita na proposta e o fornecedor também se convence que acredita naquilo que está propondo. Todos estamos habituados a ver que os projetos simplesmente não saem como o previsto e estatísticas, como as produzidas pelo Standish Group (Chaos Report 2015), vem confirmando isso há décadas. Então, o que fazer?

Que tipo de previsibilidade podemos esperar? Em desenvolvimento de software, é importante que empreendedores e desenvolvedores compreendam que:

Previsibilidade de escopo é inviável na maior parte dos casos
Escopo fixo, ao invés de representar previsibilidade, prejudica os envolvidos, especialmente o empreendedor

O primeiro ponto já comentamos, então passemos para o segundo. Quando o empreendedor opta por um escopo fixo, está apostando que não aprenderá nada ao longo do projeto e que nada diferente ocorrerá em seus processos de negócio. Raramente isso é verdade. O empreendedor aprende e as empresas convivem cada vez mais com ambientes de negócio que avançam com rapidez e demandam mudanças em seus projetos de software. Portanto, optar por um escopo fixo significa correr um risco, bem elevado, de que o software final não atenda às reais necessidades do empreendedor e de seus usuários finais. Embora isso já seja suficientemente grave, não é tudo. Segundo as estatísticas do Standish Group, mais de 60% das funcionalidades de um software comercial típico jamais são utilizadas quando colocadas em produção. Ou seja, se a equipe de desenvolvimento produzir exatamente o que está no escopo original, ela provavelmente estará produzindo uma grande quantidade de funcionalidades que jamais serão usadas. Em outras palavras, mais de 60% do investimento poderá ser jogado fora porque não irá gerar nenhum valor, por não ser usado. De fato, a melhor forma de administrar um projeto de software é rever permanentemente as prioridades e assegurar que apenas funcionalidades essenciais, isto é, que serão usadas de verdade, sejam colocadas no sistema. Só é possível saber quais são estas funcionalidades ao longo do desenvolvimento, enquanto o empreendedor aprende com o software que está sendo construído, especialmente quando o desenvolvimento é iterativo, como no caso do Scrum. Ser iterativo significa receber um software funcionando a cada final de iteração, o que permite utilizar as funcionalidades, aprender com elas e rever que funcionalidades ainda poderão trazer valor para o projeto com base no feedback concreto daquelas já implementadas. Perder essa oportunidade, fixando um escopo no início, é extremamente prejudicial para o próprio empreendedor.

Bom, afinal, o que é um contrato de escopo negociável? É um contrato que se baseia na premissa (bastante realista) de que não existe previsibilidade sobre o que será feito no software. Embora seja possível haver previsibilidade em relação aos gastos e ao tempo. Como se poderá observar, é também uma forma de alinhar os interesses do empreendedor e da empresa que irá desenvolver o software. Existem quatro variáveis essenciais que precisam ser abordadas em qualquer contrato de desenvolvimento:

Custo
Prazo
Escopo
Qualidade

O tradicional contrato de escopo fixo determina claramente qual será o custo, o prazo e o escopo. A qualidade pode até ser abordada, mas normalmente é sacrificada assim que o prazo aperta. Já o contrato de escopo negociável segue outro caminho. Visto que as quatro variáveis são conflitantes até certo ponto, não é possível fixar todas elas. Uma alternativa é fixar:

Custo
Prazo
Qualidade

Assim, permite-se que o escopo absorva as incertezas do projeto. Neste caso, o empreendedor continua sabendo o quanto irá gastar, bem como quanto tempo o projeto irá durar. O que ele não sabe com exatidão é o que irá receber, isto é, COMO o software abordará cada um dos problemas a serem corrigidos. Mas, na verdade, se pararmos bem para pensar, o empreendedor já não sabia disso no caso do contrato de escopo fixo, ele apenas tinha a ilusão de saber, a ilusão da previsibilidade do escopo. Portanto, ele não perde absolutamente nada e adicionalmente estamos assumindo uma relação contratual mais honesta e realista. Por sua vez, a qualidade pode ser tratada no contrato determinando que o projeto seja desenvolvido utilizando práticas que assegurem elevados padrões de qualidade, tais como:

Desenvolvimento Orientado a Testes
Programação em Par
Refatoração
Código Coletivo
Desenvolvimento Iterativo
Integração Contínua

As práticas de Desenvolvimento Ágil são organizadas de modo a assegurar que as prioridades sejam respeitadas e revistas periodicamente, bem como altos padrões de qualidade sejam mantidos. Desenvolvendo software de forma iterativa, ou seja, entregando mais funcionalidades a cada Sprint (períodos variando de 2 a 4 semanas), o empreendedor tem inúmeras oportunidades de rever as prioridades, bem como avaliar o trabalho da equipe. Isso permite que ele aprenda ao longo do projeto, incorpore o seu aprendizado ao sistema e decida o que tem valor ou não e, portanto, deve ser implementado ou não. Esta decisão é o que permite que ele atinja a data alvo com um software que tenha, no mínimo, as funcionalidades que mais irão gerar valor para ele. Isto é, se não for possível desenvolver todas as funcionalidades, queremos assegurar que as funcionalidades que ficarem de fora do sistema sejam aquelas que produziriam menos valor, porque as mais valiosas já são implementadas no início do projeto. Esta filosofia costuma ser mais valiosa para o empreendedor, porque ao final ele tem um software que atende às suas necessidades e prioridades reais e não as que ele achava que tinha no início do projeto.

E o que fazer se o empreendedor contratar uma equipe inadequada para o projeto? Em qualquer contrato, independente do tipo, existe o risco de que a equipe não corresponda às expectativas do empreendedor. É importante que o empreendedor conheça a capacidade real da equipe o quanto antes e, com base na sua observação, possa decidir se deseja ou não continuar com ela. Em contratos de escopo fixo, especialmente em projetos tradicionais com desenvolvimento sequencial, o empreendedor só saberá se fez uma boa escolha após o projeto já ter avançado muito, pois o código demora a ser produzido, portanto, o feedback demora a aparecer. No Desenvolvimento Ágil, o empreendedor começa a receber funcionalidades prontas e pode utilizá-las já ao final da primeira Sprint. Tendo ainda mais funcionalidades, na Sprint seguinte e assim sucessivamente. Isto fornece inúmeras oportunidades para avaliar e decidir se deseja ou não continuar com a equipe, o que ajuda a administrar o risco do projeto. Sendo assim, na prática, primeiramente, antes mesmo do projeto começar, é preciso estimar o tempo necessário e a quantidade de pessoas a serem alocadas na equipe. Para isso, pode-se fazer um levantamento inicial de funcionalidades como em qualquer projeto. Não existe mágica neste sentido. A empresa que fará o desenvolvimento e o empreendedor terão que conversar sobre a visão do que o futuro sistema deverá fazer e quais serão suas funcionalidades. Com base nisso, pode-se estimar o número de pessoas recomendável, bem como o prazo desejado. O custo do projeto naturalmente é proporcional à quantidade de tempo e pessoas alocadas ao projeto. Neste momento, ninguém tem certeza se todas as funcionalidades imaginadas no escopo original estarão prontas no prazo combinado, pois nem ao menos sabemos se serão todas estas as funcionalidades que serão desenvolvidas ou se elas serão modificadas ao longo do tempo. Portanto, ao invés de buscar previsibilidade e uma estimativa perfeita, o que se espera neste momento é identificar valores que sejam razoáveis, tanto para o tempo, quanto para o custo e o número de pessoas. Feito isso, o contrato para este modelo Ágil de projeto poderia seguir o exemplo a abaixo:

O projeto terá a duração de oito meses, sendo 8 Sprints de 4 semanas. A equipe terá seis desenvolvedores ao custo de R$ 15 mil/mês. empreendedor e equipe devem discutir as funcionalidades a serem desenvolvidas ao início de cada Sprint. Caberá à equipe de desenvolvimento indicar o número de funcionalidades possível de serem entregues por Sprint. Os pagamentos serão mensais e o contrato é revisado a cada dois meses, quando o empreendedor tem a opção de permanecer com a equipe de desenvolvimento ou encerrar o projeto sem ônus.

Portanto, voltando à pergunta inicial, o que o empreendedor pode fazer se a equipe começar a produzir pouco ou com má qualidade? O contrato é simples. Indica quantas pessoas serão alocadas, por quanto tempo e qual o custo delas por mês. Parece ser basicamente um contrato de locação de mão-de-obra com pagamento baseado em utilização de horas. Mas não é, pois há um detalhe fundamental para se compreender a filosofia deste modelo de contratação: o empreendedor tem opções de saída. Isto é, de tempos em tempos, o empreendedor pode cancelar o contrato sem nenhum ônus, ou seja, sem ter que pagar multas contratuais. Neste exemplo, ao final dos primeiros dois meses, o empreendedor já terá recebido um software relativo a duas Sprints. Ou seja, terá tido duas oportunidade de utilizar o trabalho concreto produzido pelos desenvolvedores. Isso representa informação suficiente para saber se a equipe está caminhando com um ritmo adequado ou não. Sendo assim, ao longo de todo o projeto, a cada dois meses, o empreendedor pode decidir se mantém ou troca a equipe de desenvolvimento.

Infelizmente, errar na contratação de uma equipe é mais comum do que se imagina. Entretanto, o pior é quando erros como esses são descobertos tardiamente, quando o custo de repará-los é muito elevado. Errar é natural e é uma possibilidade que todo empreendedor deve enfrentar e não temer, pois aprendemos e evoluímos com os erros. O que devemos temer é levar tempo demais para descobrir que erramos. Isso é o que o desenvolvimento Ágil e o contrato de escopo negociável procuram evitar.

Iterações a cada Sprint permitem descobrir cedo se o emprendedor errou na contratação. Contratos de escopo negociável permitem reverter uma contratação inadequada cedo, ainda no início do projeto, quando poucos recursos foram investidos. Assim ajuda a administrar o risco do empreendedor, além de alinhar objetivos.

Alinhando interesses! Parcerias de sucesso são aquelas que são boas para ambos os lados! No exemplo de contrato apresentado, ao começar um projeto, a equipe de desenvolvimento só terá garantia do faturamento dos primeiros dois meses, pois ao final desse tempo o empreendedor pode encerrar a parceria se não estiver satisfeito. Portanto, como naturalmente desejamos participar do projeto nos outros seis meses subseqüentes, temos todas as razões para nos esforçarmos ao máximo para fazer um excelente trabalho, com agilidade e qualidade, visando a manutenção da parceria até a entrega final. Por outro lado, não temos nenhuma razão para rejeitar as mudanças propostas pelo empreendedor, porque o escopo não está fixado e o pagamento não está atrelado a ele. Sendo assim, o empreendedor pode alterar funcionalidades ao longo do projeto sem que isso afete a capacidade da equipe de cumprir o contrato. Os interesses ficam alinhados. Todos querem um trabalho que atenda da melhor forma possível às necessidades do empreendedor e de seus usuários finais porque isso beneficiará tanto a equipe de desenvolvimento quanto o empreendedor. No modelo de contrato tradicional, onde o escopo é fixado, alterações sugeridas pelo empreendedor tendem a gerar custos extras elevados, pois, como o escopo é fixado no contrato, mudanças efetuadas nele afetam a capacidade da equipe de cumprir o contrato. Sendo assim, é comum que em contratos deste tipo muitas vezes, e infelizmente, levem empreendedores e desenvolvedores a se tornarem adversários em um jogo no qual o empreendedor tenta maximizar a quantidade de funcionalidades que recebe e os desenvolvedores tentem minimizar o esforço e as funcionalidades. Além disso, tais contratos tendem a ser mais caros, pois as equipes de desenvolvimento prevêem que os empreendedores farão alterações no escopo e, por isso, adicionam esse risco em suas estimativas de esforço.

Por fim, CONFIANÇA! No contrato de escopo negociável a empresa que faz o desenvolvimento fica relativamente vulnerável pelo fato de o empreendedor ter o direito de suspender o contrato após os primeiros dois meses se não estiver gostando do trabalho, e o grande ponto de virada para essa instabilidade é a confiança que será gerada no processo. O Desenvolvimento Ágil recomenda que o empreendedor participe do desenvolvimento e isso é essencial para a boa evolução do projeto. Se o mesmo estiver envolvido no dia-a-dia do projeto, conhecerá melhor o trabalho da equipe, seu ritmo, seus pontos fortes, seu empenho e comprometimento. Ou seja, a equipe estando realmente dedicada a fazer um bom trabalho ele conseguirá notar isso. E não existe nada mais poderoso para estabelecer uma relação de confiança entre empreendedor e desenvolvedores que aproximar ambas as partes tanto quanto possível e criar um histórico de credibilidade. Isso ocorre naturalmente quando a equipe de desenvolvimento entrega consistentemente as funcionalidades acordadas em cada Sprint.

Conclusão O desenvolvimento ágil com contratos de escopo negociável é, definitivamente, a primeira decisão certeira que novos empreendedores precisam tomar para buscarem chances muito maiores de sucesso em seus projetos. Esse modelo garantirá:

Flexibilidade para aprendizado evolutivo durante o desenvolvimento
Desenvolvimento de funcionalidades que realmente gerem valor para os clientes
Ajustes estratégicos de percurso de forma muita rápida
Agilidade na entrega e validação do projeto no mercado
Correções contínuas na solução
Projetos mais baratos, sem margem de risco devido a mudanças de escopo
Errar é uma possibilidade, mas erre rápido. Acompanhamento e validação contínua da performance da equipe de desenvolvimento.