[quote=MarkKnopfler]
E outra, quando se fala em princípios, “agregar valor” e etc., só se pensa em satisfazer ao cliente e nunca a resguardar o prestador de serviços contra abusos cometidos por este. A velha cultura do “o cliente sempre tem razão”. O Cliente é o Princípio e o Fim![/quote]
Eu queria comentar esta ideia de que “agregar valor” significa satisfazer o cliente e isso significa não resguardar o desenvolvedor. Não.
Agregar valor apenas significa que o cliente é que decide o que ele quer e que o desenvolvedor não será preguiçoso ou displicente. A qualidade do produto do ponto vista técnico é obrigatória e não é discutível. Mas a qualidade do produto do ponto de vista de quem o uso, do ponto de vista de mercado , digamos, do ponto de vista externo, é também responsabilidade do cliente. Agregar Valor significa que na hora de decidir entre incluir a funcionalidade A ou B, o desempate é por aquela que adicionar mais valor. O que significa “valor” ? e o que significa “mais valor” ? depende do cliente. É por isso que a figura do cara que decide do ponto de vista do negocio/cliente e não do desenvolvimento é importante. É vital. Todas as metodologias ágeis de uma forma ou outra têm esta figura normalmente chamada de Product Owner (Dono do produto). É importante notar que o cara é dono do produto, não do código, ou da técnica. Em tese o PO tem informações de outras fontes (por exemplo, equipe de UX e QA, mas tb dos stakeholders) sobre o que é tem mais valor e menos. O valor é subjectivo ao cliente, mas a decisão é concreta. Identificar o PO do projeto é a coisa mais importante, e mais difícil, porque normalmente as pessoas não tem este perfil. Mas é um principio importante e temos que ser conscientes disso, e portanto tentar encontrar essa pessoa. Essa pessoa tem que ser alguém na empresa do cliente, não na sua.
Este principio cria um outra dinâmica com o cliente. É o cliente que tem a responsabilidade de pedir e decidir, não o desenvolvedor. Quando vc inverte a responsabilidade e a dá para o cliente, duas coisas podem acontecer. Ele entende que o poder é dele o usa, ou ele não entende e prefere que vc decida. No segundo caso, ha que pensar se vale a pena continuar.
Outra coisa que eu queria comentar é o modelo de negócios. Esta subentendido na sua historia que o cliente pediu A, B e C e depois ele adiciona D, E, e F e pede que o preço seja o mesmo que por A,B,C.
O problema é o seguinte vc está usando um modelo fechado, ele está usando um modelo aberto. A diretiva é , não lute contra o modelo aberto. O seu cliente sempre usará o modelo aberto. Então se protega disso, já à partida assumindo que não é apenas A, B e C que será necessário. Como fazer isto ? Bom, não ha uma resposta universal ainda. Existem vários modelos de contrato ágil para ajudar, mas não sei qual é melhor.
Aqui alguma coisas pode ser feitas. A primeira é ter o bom senso de não acreditar no cliente, no sentido que sempre que ele usar palavras como “é só isso” , “é sempre assim” , “nunca vai mudar”, e coisas finais do tipo, desconfie. Explore essas frases. Elas escondem normalmente exceções que são importantes. Leve o raciocinio do cliente a chegar no ponto onde ele admite que pode haver uma exceção ou onde ele admite que se essa execção um dia acontecer, precisará de outro software diferente. No caso do frete, pro exemplo, começa por ser nacional. Vc pergunta “mas e exportações ?” ele responde “nunca fazemos”. E vc fala “E no dia que quiserem fazer ?” e o cara responde “ai precisamos de outro software” ou pode ser assim.Vc pergunta “mas e exportações ?” ele responde “nunca fazemos”. E vc fala “nunca fizeram ?” . Ele responde ah!, já aconteceu, mas fizemos por fora do sistema". Ai vc pergunta “então isso não será uma feature ?” e ele diz , "não. Isto é errado. Foi certo até ele admitir que existiu a exceção, mas levá-lo a concluir que a feature não será necessária é errado. A feature existe, então ela será necessária. A questão é : com que prioridade ? O sugerido é que coloque a feature no backlog e lhe dê prioridade minima. Desta forma vc não se irá enganar e deixa aberta a opção para depois.
Como cobrar por isto ?
O modelo atual é cobrar por tempo. Basicamente o tempo é que gera o custo no projeto. Portanto, o primeiro passo é criar um backlog rico. Isto significa que todas as ideias , mesmo as que não serão feitas agora, estão lá. Fixe um tempo para os cliclos. Vc cota esse backlog (existem várias técnicas) vc coloca uma margem de erro. e isso lhe dá uma ideia de quantos ciclos de tempo são necessários. E isso lhe diz o custo. Do custo vc acha o preço e é isso que vc cobra. Ai vc divide em 3 fatias. 3 versões. A versão A tem como objetivo provar que o sistema funciona. Vc joga um monte de cosias básicas (tipo cadastro e tal) e uma ou duas coisas mais avançadas que tenham valor. Ou seja o cliente irá lhe dizer o que mais lhe interessa. Mas ele tem que se comprometer com isso. A versão A tem um tempo maior porque existe um trabalho de infra que tem que ser feito tb. Durante este processo as features irão aparecer e desaparecer. Vc pode postergar para a próxima versão, ou trazer da versão seguinte para agora, etc… O ponto é que vc tem um plano o cliente tem a possibilidade de brincar com as peças como ele quiser (com algumas restrições sensatas. ). O valor aqui é que o cliente sabe se ficar patinando o dinheiro tá indo embora. Ele lhe está pagado para fazer as coisas, mas as decisões de negocio são dele.
Agora vc vai dizer que o cliente não vai nessa. bom, ai é que está. Quando o cara vier lhe pedir um sistema “simples” o tamanho do backlog vai lhe mostrar a ele , que não é tão simples. Vc explica as regras com antecedência. Algumas podem até estar em contrato. E ai deixa ele decidir. Vc não está enganando a ele , nem a si. Ele deve ficar consciente que pode pedir mais coisas, mas isso irá ocupar o espaço de outra coisa que ele já pediu. Ele que tem que fazer o trade-off.
Não estamos falando que vc deve ser subserviente. Estamos dizendo que vc deve dar a escolha ao cliente. Dá-lhe a responsabilidade. Normalmente as pessoas são capazes da usar. Assim , os abusos dele irão se refletir nele mesmo, não em si.
