Pergunta:  Rodamos uma Lean Inceptyion. Porém, como tínhamos uma limitação de apenas 2 dias para a Inception, tivemos que deixá-la ainda mais enxuta =D e não fizemos por exemplo a seção de Entendendo os Trade-offs e aceleramos algumas atividades.

Depois de alguns meses de projeto, identificamos a falta de definição de requisitos transversais, como por exemplo quais browsers deveríamos priorizar (já que acessibilidade é a maior prioridade), qual o nível de segurança que deveríamos levar em conta, resolução de tela, métricas, etc.

Dessa forma gostaria de ler sua opinião sobre o caso! Onde erramos? O que poderíamos ter feito melhor para evitar essa definição tardia? Ou isso é natural e foi Ok de ter ocorrido?

Resposta: Então, requisitos cross-funcionais… assunto difícil e super importante.

A inception tem como resultado os MVPs e as funcionalidades a serem construídas, ou seja, requisitos funcionais. Mas mesmo mantendo o foco em requisitos funcionais, a sequencia de atividades contempla espaço e fomenta a importante conversa e decisões sobre requisitos cross-funcionais.

Esses são os três momentos da inception enxuta onde questões de requisitos cross-funcionais geralmente são levantadas.

  1. Entendendo os trade-offs

Essa atividade ajuda com uma conversa inicial, onde todos acabam falando e indicando qual dos requisitos cross-funcionais são os mais importantes para o produto em questão.

Se não fizer tal atividade, ou conduzir tal conversa, vai ficar subentendido de que todos requisitos cross-funcionais são importantes.

Ou seja, depois da inception você sempre vai ouvir um “sim” como resposta.

“Sim, segurança é muito importante.”

“Sim, rodar em todos os browsers é muito importante.”

“Sim, escalabilidade é muito importante.”

“Sim, performance é muito importante.”

“Sim…”

  1. Calculando tempo, esforço e custo

Nesse momento da inception, algumas features (de amostragem) são detalhadas a nível de tarefas.

O facilitador da inception vai fomentar esse detalhamento: “me diz tudo que tem de ser feito para esta feature”

Esse é outro momento em que podem surgir os requisitos cross-funcionais.

“olha, isso tem de funcionar em todos os browsers.”

“olha, esse login tem de ter segurança máxima.”

“olha…”

Mas que bom que isso aconteceu. Pois agora tudo está sendo registrado como tarefa, e contabilizado (esforço, tempo e custo) pelo time.

Isso vai evitar surpresas na fase de criação do produto, pois o time já contabilizou a famosa conversa: “olha mas tem de ter isso, e aquilo, e aquilo outro…”

  1. MVP Canvas

O MVP Canvas possui algumas sessões onde requisitos cross-funcionais podem (e devem) aparecer. São elas:

  • personas e plataformas – para quais plataformas? Mobile-only? Web? Todos os browsers?,
  • funcionalidades – eu já vi requisitos cross-funcionais aparecer nessa sessão (exemplo: criar script automático para testar a lista de browsers homologados),
  • resultado esperado – requisito cross-funcional pode (e deve dado sua importância) estar descrito como resultado esperado,
  • métricas para validar hipóteses do negócio – que métrica está relacionada ao requisito cross-funcional (em resultado esperado), e
  • custo e cronograma – o custo e a data de entrega do MVP deve levar em conta o requisito cross-funcional. Essa conta deve estar aparente a todos.

 

Ok, agora o conselho mais difícil de todos… Já vi isso acontecer antes. Infelizmente as vezes tentamos enxugar demais. Daí, os requisitos cross-funcionais acabam sendo negligenciados. Eu sei que é difícil, mas precisamos mostrar a importância da inception, e do valor desses poucos e importantes dias de entendimento e alinhamento sobre o produto.

Inscreva-se no próximo treinamento do livro Lean Inception.