Poucos encontram uma saída, alguns não a veem, mesmo que a encontrem, e muitos nem a procuram.
De Alice no país das maravilhas
O artigo levanta as seguintes perguntas.
- Sobre a inconsistência dos componentes da fórmula de terceirização 'Scrum + Preço Fixo'.
- Um possível erro (causa raiz) que precede a escolha errada da ferramenta Scrum.
- Sobre uma situação em que realmente existe uma questão de combinar Scrum e Preço Fixo, o que requer uma análise profunda e trade-offs para resolvê-lo.
O artigo aborda um ponto muito controverso que não tem um ponto de vista inequívoco e é objeto de discussões intermináveis. Portanto, ao ler, lembre-se de que sua opinião pode não coincidir com a apresentada, mas isso não significa que um de nós esteja absolutamente certo, assim como o fato de alguém estar errado.
Como mencionado no artigo “Como iniciar o pseudo-Scrum na terceirização” , em um grande número de projetos de terceirização, cujas equipes combinam (ou talvez deseje) Scrum e Preço Fixo, o ciclo de vida do projeto (LC) não é identificado corretamente. Essa. cometeu um erro ao escolher entre um ciclo de vida incremental ou flexível iterativo. E, como resultado, a ferramenta de gerenciamento errada foi escolhida - a estrutura do Scrum. E já uma conseqüência dessa escolha é o surgimento de vários problemas, conclusões erradas sobre Agile, Scrum e tentativas (da palavra "tortura"?) Para combinar esses dois conceitos mutuamente exclusivos.
Mutuamente exclusivos ?!
Agora eu discuto.
Supõe-se que o leitor esteja mais familiarizado com os materiais do artigo acima.
Scrum + Fixed Price – , ?
, , .Ao concluir um contrato para a prestação de serviços de terceirização, o cliente quase sempre insiste em um Preço Fixo (esquema turnkey). Seu desejo é fixar o escopo do produto (ou a quantidade de trabalho), ver o orçamento, os prazos. Ele quer ver o que está "comprando". Os clientes raramente concordam com o Time & Material.
“ ”
Assim, o ponto principal: a necessidade do cliente deve ser fixada no contrato e a necessidade do prestador de serviços de cumprir as obrigações do contrato e garantir que os parâmetros permaneçam inalterados com um erro previsível (devido a algum grau de incerteza e riscos nos estágios de vendas e conclusão do contrato) após o início do desenvolvimento. A questão da redução do grau de incerteza e riscos é a questão da viabilidade e qualidade da fase Descoberta (pré-venda, diagnóstico) em relação ao escopo do produto.
É bastante óbvio que, se consertarmos algo (garantimos ao cliente nos termos do contrato), devemos planejá-lo e gerenciá-lo de forma a garantir o cumprimento de nossas obrigações. Essa. gerenciar o plano (ou as características fixas do triângulo do projeto).
O Preço Fixo simplesmente obriga a priorizar o gerenciamento do plano. Caso contrário, por que devemos consertar algo, sabendo antecipadamente que isso mudará e realmente não planejamos gerenciá-lo? Para assinar apenas um contrato? Um erro crítico nos processos de vendas estabelecidos: nós o corrigimos, sabendo antecipadamente que vamos mudar, apenas para assinar um contrato!
Por que nós vamos mudar? Porque Scrum é sempre sobre incerteza e seu resultado - mudança. É sobre a prioridade do gerenciamento de mudanças. E é possível que eles apareçam após o primeiro sprint. Por quê?
Uma digressão sobre os possíveis motivos da mudança
Qual poderia ser o motivo da mudança? Por exemplo, pode estar em uma fase de descoberta mal conduzida (pré-venda, diagnóstico) em uma situação em que o escopo do produto pode ser definido até certo ponto (por exemplo, consulte a cláusula 3 do estudo de caso no artigo ), mas para que por alguma razão, isso não foi feito. Nesse caso, esse é um problema de fase e processos internos, e não o motivo da escolha do Scrum para um contrato de Preço Fixo, um ciclo de vida flexível em vez de um iterativo para compensar o erro cometido.
Embora, para ser sincero, observe que nas vendas (atividades de pré-venda de analistas de negócios) na terceirização (uma das fases mais problemáticas do ponto de vista do escopo do produto!), Nem tudo é tão simples quanto em uma loja quando um produto acabado com propriedades específicas é comprado (funcionalidade). E a fase de descoberta é uma atividade difícil de vender de analistas de negócios e equipes. Mas minimizar a incerteza em um grau ou outro e avaliar riscos é uma das principais tarefas de um processo de vendas bem construído. Assim como a formação de um entendimento no cliente sobre a necessidade e importância dessas atividades (pode ser muito difícil!). Mas para isso, há um número suficiente de técnicas e ferramentas. E tudo se resume à questão da qualidade dos serviços prestados, e não à venda de um "porco na cutucada".
Outro motivo pode ser a incapacidade de determinar o escopo e a visão do produto no momento atual (por exemplo, consulte a página 2 do estudo de caso no artigo ). E esta é realmente uma situação muito difícil e desfavorável para ambas as partes, quando surge uma séria contradição e levanta a questão da combinação de Scrum e Preço Fixo na prestação de serviços de terceirização. Requer uma análise cuidadosa, ações adicionais para formar um entendimento abrangente do cliente (muitas vezes técnica e ideologicamente distante das realidades dos processos de desenvolvimento) sobre possíveis dificuldades e riscos e a busca por soluções de compromisso.
Então, por que o Scrum é escolhido? Para gerenciar alterações que, por exemplo, surgem como resultado de uma fase de descoberta conduzida incorretamente (pré-venda, diagnóstico) ou quando o escopo do produto não pode ser determinado nessa fase? No primeiro caso, na minha opinião, isso está errado. No segundo caso, é difícil de implementar com preço fixo.
A terceira opção possível para escolher o Scrum como uma ferramenta ágil, um ciclo de vida flexível em vez de incremental iterativo em uma situação em que o escopo do produto é elaborado e corrigido na fase de descoberta (pré-venda, diagnóstico) e no contrato - preço fixo, também não é racional na minha opinião: por que escolher uma ferramenta para gerenciar mudanças (fora de foco é claramente uma coisa mais prioritária - um plano), quando sua probabilidade é minimizada?
Retorne à idéia principal do artigo.
Mas digamos que o Scrum seja escolhido. Novamente, Scrum é uma ferramenta de gerenciamento de mudanças, quando o grau de incerteza pode ser reduzido apenas no processo e somente ao usar abordagens apropriadas. E esse declínio é o resultado desse processo.
Mas o contrato de preço fixo dá prioridade ao gerenciamento do plano!
Assim, a 'fórmula' 'Scrum + Preço Fixo' é transformada em 'gerenciamento de mudanças + gerenciamento de planos simultaneamente'. A tarefa do gerente é gerenciar, em graus variados, o plano e as alterações, mas só pode haver uma prioridade: o plano ou as alterações.
O gerenciamento de planos ou o gerenciamento de mudanças é um tipo de axioma incorporado nos fundamentos da gestão e da análise de negócios. Isso se reflete nos manuais básicos (e não apenas) para gerentes (PMBOK) e analistas de negócios (BABOK). E a classificação do ciclo de vida (e sua identificação em relação a projetos específicos) se baseia nele: há um ciclo de vida projetado para gerenciar o plano (por exemplo, Waterfall, iterativo incremental (IID)) e flexível, Agile para gerenciamento de mudanças. A escolha do ciclo de vida (e subsequentemente das ferramentas) é baseada no que é priorizado no gerenciamento.
O ciclo de vida flexível é um tipo de ciclo de vida incremental iterativo para projetos com certas características / características dominantes (uma lista de perguntas de verificação é fornecida no artigo acima), permitindo que você o identifique como um ciclo de vida separado e "direcione todos os esforços" para alterar o gerenciamento. Esses recursos podem ser atribuídos: a impossibilidade de "aqui e agora" alcançar um certo grau de certeza do escopo do produto (o mais importante!), A busca de uma solução de negócios (ou a sua rápida entrega ao negócio para gerar feedback) que irá "disparar", a formação de uma lista de funções-chave product (Key Features), iterações curtas, variabilidade, experimento, construção gradual de funcionalidades, retrospectivas, melhorando não apenas o produto, mas também os processos, a fim de obter a melhor versão do produto. É possível, nessas condições, obter estimativas adequadas do orçamento e dos termos?
O diabo está em apenas um detalhe, ou ... é tudo sobre o escopo do produto
Tudo tem sua própria moralidade, você só precisa encontrá-la!
De Alice no país das maravilhas
O que você pode dizer sobre a certeza (a capacidade de estabelecê-la) em relação ao escopo e visão do produto no estágio de vendas, na fase Discovery, no início do projeto de terceirização?
Se o escopo do produto não puder ser definido, avaliado, corrigido devido às razões da singularidade do produto, à ideia de uma partida, incerteza quanto à eficácia das decisões de negócios tomadas (a necessidade de encontrá-las) e a dificuldade de determinar as principais funções do produto, a presença de hipóteses que requerem verificação etc. ... (veja novamente o ponto 2 do estudo de caso aqui ), então, é claro, a estrutura do Scrum é a ferramenta mais adequada.
No entanto, para a terceirização, essa situação é significativamente complicada pelo desejo do cliente de usar o esquema de preço fixo ao concluir um contrato e aparece de maneira desfavorável para ambas as partes. Até certo ponto, com algumas suposições, é possível alcançar um compromisso na contratação e gerenciamento de um projeto. É importante formar o entendimento correto e as expectativas corretas do cliente (investidor), avaliar os riscos, considerar, se possível, outros esquemas de interação financeira e, no processo de implementação do projeto, trabalhar constantemente com a lealdade do cliente, etc. Não vou me aprofundar na questão, pois ela está além do escopo do artigo.
Na terceirização, na maioria das vezes a questão reside principalmente na condução competente da fase de descoberta (pré-venda, diagnóstico) em relação ao escopo do produto e à escolha do ciclo de vida correto. E se Agile e Scrum forem escolhidos em uma situação em que o Escopo do Produto possa ser corrigido (e ainda mais quando isso não for feito por algum motivo no prazo, com a expectativa / suposição de seu desenvolvimento no futuro) e, ao mesmo tempo, no contrato - Preço Fixo, na minha opinião, está sendo cometido um erro que põe em dúvida o resultado positivo do projeto.
Agradecimentos para sua atenção!