Mês: março 2012

Afinal, está pronto ou não para entregar?

Postado em Atualizado em

“Se criarmos um preview da tela para auxiliar na configuração, não seria melhor? E se a gente criasse um novo passo indicando a situação atual do cadastro? E se tivéssemos uma lista múltipla ao invés de um combo na configuração? Mas essa relação 1 x N não precisa ser N x N?” Esses são alguns exemplos básicos de perguntas que muitos times enfrentam. Saber se a nova funcionalidade está realmente pronta para entrega ao cliente é uma dúvida enfrentada muitas vezes por muitas equipes de desenvolvimento.

A questão que precisamos entender é que as respostas não estão com a gente. Somente há uma resposta que deve ser avaliada e levada em consideração: a posição do cliente. É ele que deve dizer se o que foi feito agrega ou não ao seu negócio, se precisa de melhorias e ajustes, e se está contemplando sua necessidade ou não. É ele que tem o poder

O fato é que muitas vezes nossa visão sobre determinada funcionalidade não está de acordo com o seu uso efetivo. Na prática é que realmente vamos validar se o que foi feito ajuda ou não o cliente. Muitas vezes, o cliente não está preocupado com preview, wizards, telas de seleções múltiplas, entre outras coisas. O que o cliente realmente espera é que a funcionalidade atenda a sua necessidade e resolva o seu problema. É por isso que uma quantidade enorme de software desenvolvido nunca é utilizado, conforme pode ser visto no report do Standish Group abaixo.

Não estou dizendo com isso, que devemos esquecer as melhores práticas de desenvolvimento e os cuidados com a usabilidade do produto. Com certeza são questões muito importantes e que agregam ao produto, tornando seu uso melhor. Mas já vi softwares com uma usabilidade fantástica e com vários recursos avançados que foram um fracasso. E também vi softwares com interface bem simples e poucos recursos serem um sucesso absoluto.

O segredo muitas vezes está na simplicidade. Quanto mais simples e objetivo for para o usuário, melhor será sua experiência no uso do sistema. E se você está com dúvida em relação a qual padrão utilizar, e fica pensando se a tela ficará melhor do jeito X ou Y, sugiro que priorize a forma mais simples e fácil. Afinal de contas, você não tem a resposta certa mesmo. A resposta está sempre com o cliente.

Por isso é importante sempre ter a participação do cliente na construção do software. Ele ajudará a nortear o desenvolvimento, indicando o que agrega mais valor e como. Os feedbacks dos clientes são fundamentais para garantir o sucesso no desenvolvimento do produto. E quanto mais cedo o feedback, melhor. Essa é a grande vantagem de um desenvolvimento iterativo e incremental, sempre buscando o feedback do cliente e a melhoria do produto durante a sua elaboração, sem aguardar um retorno somente ao final de todo o desenvolvimento.

Afinal, está pronto ou não para entregar?

Além disso, não devemos ter medo de entregar uma parte do software, pensando que ainda falta muito a desenvolver. Temos que entregar sempre o mínimo possível que temos para ir agregando valor ao produto e buscando com isso feedback do cliente. Se com o mínimo já atende o cliente, então porque vamos realizar o resto? E se com o mínimo já percebemos que não estamos no caminho certo, porque vamos continuar nesse caminho? Pensar no MVP – Minimum Viable Product (falaremos mais sobre isso em outro post) e ir já realizando a prova prática dele, entregando ao cliente, é um ponto importante para descobrirmos realmente se está ou não está pronto.

Anúncios

Qual o momento certo para analisar uma nova funcionalidade?

Postado em Atualizado em

Fiz a análise completa de uma nova funcionalidade do sistema. Documentei os requisitos que serão criados e alterados. Montei o modelo do banco de dados. Quebrei a funcionalidade em pequenas tarefas e defini os critérios de aceitação para elas. Tudo que era previsto para iniciar o desenvolvimento da funcionalidade. E como foi a implementação? A funcionalidade ficou boa no produto? Não. Não foi desenvolvida. 😦

Você, analista de negócio, nunca passou por uma situação como essa? Situações onde a necessidade de um recurso novo no software era iminente, e no fim percebe-se que não era bem assim? O recurso precisava ser feito para “ontem“, mas após a análise completa, percebeu-se que não era tão prioritária assim, e existiam outras funcionalidades mais importantes para serem implementadas antes dessa.

Que desperdício! Seguindo teorias do Lean, esse estoque gerado é um grande desperdício. Isso porque, com certeza, quando chegar o momento certo de desenvolver a funcionalidade, a análise terá que ser toda reavaliada, pois o contexto do software já mudou. Pode ser até que nunca surja o momento certo, e a análise realizada nunca vire uma funcionalidade em produção.

Mas você deve estar pensando: “Se o roadmap do produto (aguarde novo post sobre o assunto) está bem priorizado, isso não ocorre!” Sim, é verdade. Mas o ponto é que nem sempre é simples priorizar quais são os recursos mais importantes e que agregam mais valor ao produto. Muitas vezes, pressões externas interferem nessa percepção de valor e urgência. E isso ocorre principalmente quando há um grande número de funcionalidades para serem desenvolvidas no produto.

Mas o que fazer para evitar esses desperdícios e focar realmente no que interessa? Eu sempre procuro manter todas as requisições registradas em cartões – conceito 3C (aguarde mais sobre isso em novo post) com o mínimo possível para não esquecê-las. A partir disso, vou aumentando sua prioridade conforme elas são lembradas novamente. Cada vez que o recurso faz falta ou é solicitado por alguém, vou aumentando sua prioridade.

Além disso, quando realmente analiso uma funcionalidade nova, procuro questionar: “por que essa funcionalidade é mais importante que as demais que ainda ficarão no backlog? Nesse caso, cada time possuirá diferentes critérios para avaliação e priorização, como: necessidade do cliente, valor investido pelo cliente e pela empresa, retorno que o recurso trará para o produto, disponibilidade do time para desenvolver o requisito, entre outros.

Qual o momento certo para analisar uma nova funcionalidade?

Não existe regra exata para saber quando analisar a nova funcionalidade. Existem muitas variáveis a serem avaliadas. Mas o importante sempre é questionar mesmo. O conceito dos 5 porquês (assunto que falaremos mais em outro post) é interessante e pode ser aplicado nesses casos. Quanto mais porquês forem realizados, maior será a certeza de ter realizado a priorização correta, e que o momento é o adequado para realizar a análise e desenvolver a funcionalidade.

A Importância do Uso dos Indicadores (BSC)

Postado em Atualizado em

Todas as organizações possuem sua missão, visão, objetivos estratégicos e tudo mais que um bom planejamento estratégico define como regra para identificar onde a empresa quer chegar. Mas a pergunta é: “quem faz com que a empresa atinja tais objetivos?”

Com certeza são os colaboradores que farão com que as metas da empresa sejam ou não atingidas. São as pessoas que movem a empresa. Mas a questão principal é: “Será que todos sabem claramente o que precisam fazer para que a empresa atinja suas metas? O caminho está claro para todos?”

 

Para exemplificar a importância dessa comunicação, lembro de uma pequena história sobre caranguejos que ouvi há um tempo atrás em um curso que realizei. Essa metáfora com a vida organizacional relata que os caranguejos capturados no mangue ficam presos em um barbante solto no próprio mangue. Eles poderiam fugir se todos puxassem o barbante para o mesmo lado. Mas como não se falam, cada um puxa para um lado diferente e eles acabam ficando no mesmo lugar, sem conseguir escapar.

Para melhorar esse cenário confuso sobre a comunicação da empresa com seus colaboradores, há uma ferramenta importante que visa simplificar esse diálogo, orientando todas as pessoas a seguirem um caminho único. Essa ferramenta é o Balanced Scorecard (BSC), formado por indicadores em todas as áreas da empresa, interligados e balanceados, evitando comportamentos inadequados.

O processo mais complicado na construção do BSC é a escolha correta dos indicadores. Sempre deve ser avaliado se o comportamento gerado a partir do indicador é o adequado. Os indicadores não podem ser controladores de performance. Eles devem auxiliar no comportamento dos colaboradores para que todos busquem atingir os objetivos organizacionais. Não devem ser criadas medidas a fim de punir as pessoas e sim indicadores para auxiliar as pessoas nas tomadas de decisões.

A Importância do Uso dos Indicadores (BSC)

Para finalizar, lembro da famosa e verdadeira frase do Goldratt: “Diga como me medes e te direi como me comportarei. Se me medires de forma ilógica, não reclame de comportamento ilógico.”

Quer saber mais sobre o uMov.me Labs? Acesse o site http://umovme.cc e fique ligado nas novidades do blog.