Últimas notícias do evento
TDC 2015 Porto Alegre
E mais uma vez chegamos a uma nova edição do The Developers Conferente (TDC) em Porto Alegre. O evento ocorre entre os dias 24 e 26 de setembro. Esse ano estou participando mais uma vez como palestrante na trilha Análise de Negócios. Sempre é um prazer compartilhar minhas experiências com a comunidade, gerando muito networking, troca de reflexões e conhecimentos dentro da comunidade de análise de negócios.
O tema escolhido esse ano sempre gera polêmica: estimativa de software. É uma questão que sempre é discutida entre diferentes times e projetos. Afinal de contas, qual é a melhor forma de estimar o esforço de trabalho do time? Story point, use case points, horas, ou algum outro método que você trabalhe? O método que você utiliza está gerando o resultado esperado? Está acertando em suas estimativas?
Essas são algumas proposições que pretendo levar a palestra para reflexão entre todos. E abordar questões como ritmo de trabalho, produção puxada, entrega contínua e comprometimento do time. Pretendo abordar como devemos encarar a estimativa evitando frustrações do time e principalmente do cliente.
Segue abaixo a apresentação. Participe da palestra, que irá ocorrer no dia 25/09/2015 por volta de 10:35 na Stadium, que é aberta para todas as trilhas. Leve suas dúvidas e compartilhe comigo suas experiências em estimativas de software.
Agile Brazil 2014
Esse ano de 2014 está sendo um ano muito especial para mim. Foi o ano que comecei a palestrar em eventos, mostrando um pouco do meu trabalho e o que eu acredito que realmente agrega no desenvolvimento de software, utilizando a análise de negócios e os métodos ágeis como pilares fundamentais para a construção de um software eficaz.
Iniciei palestrando no The Developers Conference (TDC) em Florianópolis. Depois fui palestrante e coordenador da trilha Análise de Negócios no TDC em Porto Alegre, conforme já relatado nesse blog. E é com muito orgulho que palestro também esse ano no maior evento de métodos ágeis do Brasil, o Agile Brazil 2014, que ocorre em Florianópolis.
Estarei palestrando na próxima quinta (06/11) juntamente com meu amigo Rafael Helm, falando um pouco sobre os desafios da gestão de roadmap de produto em equipes ágeis.
Estou muito feliz e ansioso pela participação nesse grande evento, que já está com lotação máxima de inscrições. Com certeza teremos muita troca de experiências bacanas por lá. É uma forma de recarregar as baterias e seguir lutando pelas causas que acreditamos no desenvolvimento de software.
Para finalizar, fica a dica para quem acredita em seu trabalho e tem o objetivo de palestrar em algum evento. Não tenho medo. Lute pelos seus objetivos. Prepare-se na sua empresa, em casa, ou em algum evento menor. Mas não deixe seu sonho morrer. Com certeza, você irá verificar que aprende muito mesmo palestrando em eventos.
TDC 2014 Porto Alegre
Há eventos que realmente valem a pena participar. São eventos sérios e bem organizados e que sempre possuem conteúdo de qualidade. Um desses eventos é o The Develepers Conference (TDC), organizado pela Globalcode em parceria com coordenadores interessados em diversas áreas da TI. Esse evento chega a sua segunda edição em Porto Alegre em 2014, entre os dias 16 e 18 de outubro.
O objetivo desse post é falar um pouco sobre a trilha que tenho a honra de coordenar esse ano, juntamente com a Diana Correia. Trata-se da trilha Análise de Negócios constituída por grandes palestrantes, que com certeza, irão agregar muito conhecimento a todos. Tenho certeza que teremos um dia intenso com muita troca de experiências, networking e uma profunda imersão em diversas áreas e temas ligados à Análise de Negócios.
Participei em 2013 do TDC de Florianópolis e Porto Alegre, acompanhando as palestras e agregando conhecimento. Esse ano já participei do TDC de Florianópolis como palestrante, conforme já relatado nesse blog. E em Porto Alegre estarei palestrando novamente e auxiliando na organização da trilha. É um grande prazer estar dividindo minhas experiências com todos. Com certeza, não existe melhor forma de aprender e fortalecer o conhecimento, que estar compartilhando vivências passadas, dividindo conquistas, problemas e frustrações enfrentadas.
Segue acima minha apresentação no TDC 2014 Porto Alegre. Durante a apresentação quis ressaltar alguns dilemas enfrentados por analistas ágeis. Isso ocorre porque seguimos os fundamentos ágeis, dentro do possível, mas muitas vezes trabalhamos em áreas de apoio, buscando facilitar o andamento do trabalho, removendo impedimentos, negociando contratos, prazos, custos, entre outras ações com menos importância segundo o manifesto ágil.
Caso tenham alguma dúvida, sugestão ou crítica, entrem em contato comigo. Vocês podem me encontrar em diversas redes sociais (http://about.me/eschenatto). Como agilista, considero o feedback fundamental para o crescimento.
Seja o cliente de seu produto
A proximidade com seu cliente, buscando feedbacks frequentes são fundamentais para o bom andamento de um 
projeto e evolução de um produto. Bom, isso deve estar muito claro para todos e não ser novidade para ninguém. Porém, o objetivo desse post é indicar que devemos ir um pouco mais além do que só receber feedback do cliente. Precisamos, de fato, sentir a dor que ele está sentindo.
Mas como assim sentir a dor do cliente? O que isso significa? Bem, acredito ser fundamental para uma evolução eficiente de um produto o uso interno dele, pela equipe que o vende e principalmente o desenvolve. Muitas empresas acabam desenvolvendo o produto e não o usam efetivamente no dia a dia. Apenas fazem testes, montam ambientes de demonstração e se baseiam na percepção dos clientes. Mas nem sempre isso é suficiente.
Já vivenciei situações que os colaboradores da empresa não conheciam as funcionalidades do produto. Isso porque não o usavam efetivamente. Se você desenvolve software, também já deve ter vivenciado isso. Principalmente quando no desenvolvimento há diferentes tecnologias e módulos, e pessoas que não trabalham em todas as áreas. Acabam surgindo ilhas de conhecimento, não tendo uma visão sistêmica de todo o produto. Isso é um perigo e pode gerar um produto com ótimas funcionalidades isoladas e que não se comunicam adequadamente entre si.
Em experiências passadas, percebo que algumas vezes o feedback negativo do cliente parece exagerado pela equipe interna. Parecemos pais que não gostam quando outras pessoas falam mal de seus filhos. Porém, ao visualizar exatamente o cenário do cliente, utilizando o sistema, percebe-se que não houve exagero algum. Nesse momento, temos que guardar um pouco do nosso orgulho e perceber que realmente há lacunas no produto, e que ele, de fato, precisa ser melhorado.
Utilizar o produto que você desenvolve parece um pouco óbvio, não é? Mas nem sempre é. Por exemplo, se você desenvolve uma solução de mobilidade para Windows Phone e ninguém da equipe possui um smartphone com esse sistema operacional? E se você utiliza o produto, mas não realiza a integração via arquivos ou API com outro sistema? E se você desenvolve uma solução específica para farmácias? Perceba que nem sempre é simples utilizar realmente todos os recursos do seu sistema.
Mas eu insisto. Dentro do possível, crie situações onde sua equipe utilize o produto no cotidiano. Uma utilização real, onde necessita de dados reais e regras de negócio bem mapeadas no sistema. Você, mais do que ninguém, conhece o produto que você desenvolve e sua empresa. Pense numa forma de adaptar um ao outro. Isso irá gerar uma maior visão sistêmica do produto, entendendo as intersecções entre módulos e tecnologias. Irá também antecipar possíveis problemas ou lacunas no produto que precisem ser ajustadas. Seja você o primeiro cliente de seu produto.
TDC 2014 Florianópolis
Estive por um longo período afastado do blog, sem postar nada. O que aconteceu nesse período? Muitas coisas, com certeza. Vários novos assuntos surgiram e mudanças ocorreram na minha vida, e na própria análise de negócios. Durante esse período, infelizmente acabei perdendo o hábito de postar aqui no blog Análise Ágil de Negócio.
O que me
levou a retomar o blog? Bem, já tinha esse projeto pessoal e estava postergando, por N motivos. Porém, a participação no TDC 2014 Florianópolis me fez refletir que já tinha passado a hora de fazer isso. O tempo estava passando e eu perdendo a oportunidade de realizar essa troca de aprendizado entre todos.
Conforme citado acima, participei no TDC 2014 Florianópolis pela primeira vez como palestrante. Foi uma experiência incrível, onde aprendi muito. Eu e meu colega Rafael Helm palestramos na trilha Análise de Negócios. Nossa palestra “Os desafios na gestão de roadmap de produto em equipes ágeis”, contou de forma breve como realizamos a gestão de roadmap de produto na uMov.me. Buscamos explicar como buscamos gerar maior alinhamento entre a equipe de desenvolvimento e a estratégia da organização. Falamos sobre priorização, estimativa, planejamento e entrega das funcionalidades, entre outros pontos fundamentais para atingirmos os objetivos definidos para o produto.
Vale destacar a qualidade do evento, que como sempre é excelente. Boas trilhas, ótimas palestras e uma organização impecável. Com certeza vale o investimento de ir até Florianópolis e obter um grande volume de conhecimento em poucos dias. Estive lá entre os dias 16 e 18 de maio, e tive o privilégio de ter acesso a ótimos materiais nas trilhas Análise de Negócios, Agile e Management 3.0. Buscarei falar mais sobre os assuntos abordados no evento nos próximos posts do blog.
O fato de ter estado no evento, e ter acompanhado inúmeros temas relevantes para compartilhamento e estudo, me fizeram sair da inércia. 🙂 Há muito conteúdo para estudar e compartilhar com todos, buscando uma troca maior de conhecimento e experiências vividas. Inclusive já estou preparando submissões para novos eventos ainda esse ano, como Agile Brazil 2014 (submissões já abertas) e TDC 2014 Porto Alegre. Acredito que devemos buscar um aprendizado constante, uma atitude e um desafio novo a cada dia. E palestrar para os profissionais qualificados que se encontram nesses eventos, compartilhando um pouco das minhas experiências vividas, é uma aprendizado enorme e uma grande m0tivação para seguir desempenhando o meu papel da melhor forma possível.
Fique ligado nos posts e novidades do blog. Estarei postando no mínimo 2 vezes por mês, buscando incluir um conteúdo variado sobre análise de negócio, passando um pouco de experiências enfrentadas na análise e temas ligados diretamente a área. Conto com a colaboração de vocês para comentarem e levantarem novos assuntos para discussão.
A importância do uso de CRM
Depois de um longo tempo de inatividade do blog, estou retomando as atividades colocando meu ponto de vista diante de questões relacionadas a análise de negócio. Aproveitando minha participação no evento TTLabs Summit, realizado na empresa que trabalho, falarei um pouco sobre CRM aplicado em software-houses.
Normalmente, as empresas buscam sempre aumentar seu faturamento e lucro buscando novos clientes. O que não é errado, sem dúvida. O problema é que, muitas vezes, elas esquecem de seus clientes atuais. As organizações não percebem que o custo para a aquisição de novos clientes é muito maior. A venda de novos produtos e serviços para clientes atuais satisfeitos pode gerar um grande incremento no faturamento da empresa.
Para isso, o uso de uma boa ferramenta de CRM pode auxiliar muito as organizações. Além disso, é importante ampliar o conhecimento sobre os clientes a fim de categorizar os mesmos. Clientes com maior influência no mercado e com maior poder de investimento devem receber uma atenção especial. É um erro considerar que todos os clientes possuem o mesmo grau de importância e devem ser tratados na mesma forma. Clientes diferentes devem ser tratados de forma diferente. Cada um possui sua cultura, seu conhecimento sobre o produto, sua forma de comunicação.
O objetivo principal de uma ferramenta de CRM é conhecer melhor os seus clientes. Dar a atenção devida para cada um, de acordo com sua real necessidade. A partir disso, deve-se buscar o relacionamento com o cliente como um diferencial competitivo da organização. Entender de forma rápida e precisa o que cada cliente necessita, geralmente não é algo simples para as organizações. Principalmente em software-houses, onde os clientes normalmente possuem um conhecimento limitado sobre o processo de desenvolvimento de software. E isso se agrava ainda mais, se o cliente não possui uma área de TI bem estruturada.
É importante categorizar os clientes, para que em um atendimento todos possam saber de forma rápida qual seu grau de importância para a empresa, qual é o potencial de compra de novos produtos e serviços, e principalmente, seu poder de influência sobre o mercado, baseado em seu relacionamento e proximidade com outros clientes.
Não estou defendendo que clientes com uma classificação de menor relevância devem ser desconsiderados e distratados. Muito longe disso. Todos clientes são importantes. Só que clientes que agregam menos valor a empresa, não devem receber uma atenção maior que um grande cliente, considerado fundamental para a organização. É uma questão de alinhamento da operação com a estratégia, e uma forma de aumentar os esforços no mais relevante. Diante de uma situação onde deve ser dado retorno para mais de um cliente, sugiro que busque primeiro retornar para a mais relevante, e depois para o cliente com menor relevância. Claro que sempre respeitando o SLA de atendimento da organização.
Sendo assim, analisando o cotidiano de empresas desenvolvedoras de software, criei uma sugestão de metodologia para implantação de CRM, com algumas categorias de clientes e informações que devem ser coletadas em uma ferramenta de CRM. Esses dados podem ser conferidos no vídeo e/ou na apresentação que estão mais abaixo.
Buscar categorizar os clientes por:
- Número de contatos (chamados) realizados
- Geração de receita
- Inadimplência
- Maior conhecimento ou melhor utilização de seus sistemas
- Maior visibilidade para seus softwares perante outras organizações
Informações que devem ser armazenadas no CRM:
- Recursos, módulos ou programas que os clientes utilizam
- Pessoas que utilizam o sistema e seus níveis de conhecimento sobre o sistema
- Regras pré-estabelecidas pelo cliente, assim como particularidades no uso do sistema
- Treinamentos realizados (com dados sobre quem fez e quando)
- Reclamações dos clientes
- Problemas solucionados
- Ações pendentes com data e responsável pela próxima ação/retorn
Quer saber mais sobre o uMov.me Labs? Acesse o site http://umovme.cc e fique ligado nas novidades do blog.
Qual o nível de conhecimento técnico que um analista deve ter?
A cada dia que passa nos deparamos com novas tecnologias no desenvolvimento de software. Surge uma nova versão do sistema operacional ou browser, um novo banco de dados, um novo smartphone ou tablet, um novo framework ou padrão de desenvolvimento, e assim por diante. Isso sem falar em novas regras de negócio, modelos administrativos, ferramentas de modelagem, indicadores de desempenho, etc. Ou seja, estamos sempre correndo atrás da máquina. Quanto mais estudamos, mais nos deparamos com coisas novas e percebemos que de fato sabemos pouco diante da imensidão do mundo de TI.
A partir disso, muitas vezes me questiono: “Quanto de conhecimento técnico eu preciso saber? Qual o nível mínimo de conhecimento que eu preciso?” Acredito que essa seja uma questão recorrente para muitos analistas de negócio, pois geralmente focamos nas regras de negócio, nas ferramentas de especificação de requisitos, gestão de demandas e outras atividades mais administrativas e menos técnicas. Com isso, em algumas especificações de requisitos a falta desse conhecimento técnico mais apurado sobre alguns assuntos, dificulta na especificação e passagem da necessidade para a equipe de desenvolvedores.
Torna-se muito mais simples a passagem da necessidade para um desenvolvedor quando realmente sabemos o que ele pode fazer. Não ficamos imaginando e pedindo o impossível e focamos realmente no que é viável. Além disso, a linguagem utilizada é muito mais direta e objetiva, facilitando muito a comunicação e compreensão das coisas tanto pelo desenvolvedor quanto pelo analista. Mas para isso acontecer, ambos devem estar com um nível semelhante de conhecimento.
O problema todo é que é muito difícil acompanhar a evolução técnica. Naturalmente, o analista acaba se distanciando da parte técnica e focando em questões mais de negócio mesmo. Para acompanhar tudo de forma efetiva, seria necessário trabalhar 24 horas por dia e 7 dias por semana. E não tenho certeza se conseguiríamos mesmo assim. Não podemos querer abraçar o mundo. Temos que entender que cada função possui suas atribuições principais. É do jogo mesmo. Um time de futebol não pode ser composto por 11 goleiros. Precisa ter também os zagueiros, laterais, meias e atacantes. Cada um com sua função e onde produz melhor. Mas o objetivo final é que o time vença. E no desenvolvimento de software é a mesma coisa.
Acredito que os analistas de negócio não devem abandonar totalmente a questão técnica. Devemos acompanhar vídeos, blogs e sites de referências para que estejamos cientes sobre o que há no mercado e as tendências que estão surgindo. Devemos utilizar redes sociais e ferramentas que nos mantenham “antenados” sobre as tecnologias existentes. Mas não precisamos saber fazer ou sermos especialistas nisso. Saber que existe e onde buscar se for necessário, já é um grande caminho. Ter experiência no passado como desenvolvedor também é algo saudável para entender as dificuldades e problemas enfrentados na geração de código-fonte.
Mas acima do conhecimento técnico que o analista deve ter, deve existir confiança e humildade no time. Se o analista não conhece detalhes técnicos, mas sabe que o time pode apoiar e ajudar na especificação, não deve exitar em pedir ajuda e especificar a necessidade em conjunto com a equipe técnica. O contrário também é verdadeiro. Ou seja, se a equipe técnica tem dúvida sobre regras de negócio ou como mapear um critério de aceitação ou modelagem no banco de dados, também deve sempre buscar apoio no analista. Ser humilde e reconhecer que há pessoas mais qualificadas para apoiá-lo é algo fundamental. E sempre pensar no coletivo e não no individualismo. Não queremos heróis e sim times coesos capazes de atingir os objetivos esperados.
A importância de ver o todo
Em qualquer organização há muitas pessoas e muitos meios para efetuar a comunicação. A comunicação eficaz entre todos, sempre é um desafio constante na análise de negócio. Conseguir buscar as informações e repassar de uma pessoa para outra, e entre os setores da empresa de forma clara e objetiva, é praticamente uma arte. Precisamos conhecer bem as pessoas e saber como abordá-las para que elas recebam as informações da melhor forma. Por isso que a Programação Neurolinguística (PNL) está sendo tão procurada por analistas de negócio. Muitas vezes, precisamos ser mais “psicólogos” que analistas mesmo.
Isso deve-se ao fato de cada pessoa possuir a sua própria percepção sobre seu trabalho. O setor de vendas, por exemplo, valoriza mais seu trabalho e considera fundamental, pois é através dele que entram os clientes e o dinheiro das vendas. Já o setor de compras considera seu trabalho essencial para adquirir bons preços, produtos e condições de pagamento para melhorar o fluxo de caixa. E o setor financeiro que cuida do caixa da empresa? A produção, por sua vez, considera que leva a empresa nas costas, já que é responsável por desenvolvedor o produto ou serviço com qualidade. Mas afinal, existe algum setor mais importante que outro? É claro que NÃO.
É muito natural que cada pessoa e setor considere o seu trabalho bem importante, pois sempre buscamos a valorização de nosso trabalho. Mas não podemos considerar que o que fazemos é mais importante que o trabalho de outra pessoa ou setor. Em uma organização as coisas somente acontecem quando o todo funciona bem. Não adianta a produção fazer tudo de forma rápida e perfeita e não ter vendas. Também não adianta ter vendas e não conseguir produzir, ou vender com prejuízo devido a uma negociação mal feita com o fornecedor. Sempre o todo tem que estar bem alinhado.
Dessa forma, considero fundamental que na análise de negócio sempre seja buscada uma visão mais ampla. Muitas vezes, por estarmos mais próximos de uma área, como desenvolvimento por exemplo, acabamos deixando nossa visão mais míope, mais limitada e não enxergando a empresa como um organismo mais complexo e cheio de conexões internas que levam para um resultado maior. A visão mais restrita nos tira a percepção de valor sobre algumas tarefas que devem ser implementadas.
Temos somente que ter cuidado para não nos envolvermos com tudo na empresa, buscando ser especialista em todas as áreas, e nos tornarmos assim super heróis. Sempre temos que ver o todo, mas sabendo que não seremos especialistas em tudo. Cada área possui sua experiência e conhecimento natural, e somente devemos apoiar esses setores entendendo a sua importância e suas necessidades na organização.
Mas também deve ser salientada a importância de sempre recebermos o contexto mais amplo para execução de algumas atividades. Recebermos uma tarefa para execução sem entendermos o real valor dela não é nada saudável. Temos que entender e acreditar no que está sendo feito. Fazer somente porque a direção da empresa quer, ou porque a equipe de desenvolvimento acha importante, não é a melhor saída. Sempre temos que parar, nos afastar um pouco do problema e buscar visualizar o todo. A partir desse ponto, estaremos aptos para tomarmos a decisão mais acertada.
Você confia nas pessoas do seu time?
Lendo o post “Não quero gerentes, mas pessoas capazes de gerenciar” do Daniel Wildt que é muito bom e está em linha com o que acredito também, veio a inspiração para esse novo post. 😉 Falarei um pouco sobre confiança. Sim, confiança. Assunto não técnico, mas que tem muito a ver com análise de negócio, relações entre pessoas de um time, liderança e trabalho em equipe.
Delegar responsabilidades não é algo simples. É importante saber delegar. Passar uma tarefa a alguém e esperar que ela faça exatamente o que você faria não é a forma adequada. Muito pelo contrário. É um sinal claro de desconfiança. As pessoas sempre farão diferente do que você faria. Isso é natural, pois cada pessoa é diferente com seu conhecimento, habilidade e atitude (CHA). Se você quer que as coisas sejam exatamente como você espera, o melhor é que você mesmo faça. Caso contrário, a chance de frustração é bem grande.
Além disso, encontrar as pessoas que possuem a aptidão e perfil adequado para desenvolver algumas funções também é delicado. Devemos conhecer as pessoas e saber o que cada pessoa do time é capaz de executar. Cobrar algo de alguém que não tem o perfil adequado, com certeza é um tiro do pé. A relação de confiança da pessoa com o restante do time ficará abalada, pois a execução da tarefa não se dará de forma adequada, já que o perfil da pessoa não é o adequado para tal execução.
O mais importante de tudo é confiar nas pessoas do time. O que quero dizer com isso? Quero dizer que devemos passar uma tarefa para a pessoa e ter certeza que ela dará um jeito de resolver. Se ela não conseguir resolver, ela deverá avisar. Mas não devemos ficar cobrando se está indo ou não, ou como fez. Se delegou a tarefa, e deixou claro o que deve ser feito, não deve se preocupar como ela será feita. Importante é que o objetivo seja alcançado. E a pessoa deve ser responsável o suficiente para executar a tarefa e dar feedback a fim de continuar tendo a confiança do líder e de todo o time. Isso faz com que o time seja auto gerenciável, sem necessidade de cobranças e controles excessivos.
Quem não passou por situações onde o gerente ou diretor ficou cobrando as coisas diariamente, semanalmente ou mensalmente? Isso na minha visão, é total falta de confiança no time ou nas pessoas. Claro que o time deve dar retorno sobre o andamento da tarefa. Mas muitas vezes, nem consegue iniciar a execução, que já vem outra cobrança. Um time somente cresce quando há confiança. Se o líder não confia no time, não serão criadas novas lideranças e não irá ocorrer crescimento individual. O mesmo serve para a confiança entre as próprias pessoas do time. Com a desconfiança entre as pessoas, irão surgir “heróis” que sempre ficarão com as tarefas mais difíceis e irão se tornar gargalos, não propiciando o crescimento das demais pessoas através do repasse de conhecimento.
A confiança é a base de qualquer relação. E é sobre esse pilar que devemos construir o relacionamento entre as pessoas do time. Lendo o livro Transformando Suor em Ouro do Bernardinho, que sem dúvida nenhuma é um grande líder, podemos tirar algumas lições importantes que devem ser aplicadas nos times:
– Deve-se sempre fomentar as lideranças no time
– Nunca esquecer que a vaidade é inimiga do espírito de equipe
– Buscar o “brilho da vitória” no olhar das pessoas do time
– Combater o desperdício do talento. É fundamental conhecer as pessoas para motivá-las
– Quanto mais o gestor mostrar que acredita no potencial das pessoas do time e se dedicar a elas, maior será a produtividade
Para finalizar, reforço a necessidade de aumentar cada vez mais a confiança entre as pessoas do time. Cada pessoa deverá ser responsável por suas atividades de acordo com sua aptidão. Mas para conquistar a confiança de todos, é necessária muita responsabilidade sobre as tarefas executadas.
Afinal, está pronto ou não para entregar?
“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.
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álise Ágil de Negócio 