Conheça a Informant          RSS

Posts Tagged: metodologia


20
May 14

Entenda de vez o papel do Product Owner no SCRUM

Informant07.05Creditar o sucesso ou o fracasso de um projeto apenas à uma pessoa pode parecer errado, ou então conveniente, mas é algo comum em equipes que utilizam scrum no desenvolvimento dos seus projetos. Isso acontece por conta de uma figura fundamental: o product owner.

O sentimento de “posse” que toma conta de muitos POs é causado por conta do poder que ele exerce sobre as decisões importantes do projeto. Ao não perceber que ele deve servir como elo entre o cliente – ou usário final – e o time, acaba colocando em risco todo o desempenho do software, gerando ferramentas inúteis e desperdiçando tempo e recursos. Para entender o papel do product owner, suas atribuições, acertos e erros, acompanhe os tópicos a seguir:

Quem é o product owner

O product owner é responsável por gerenciar o backlog do projeto. Ainda que ele tenha ajuda de outros membros do time, como arquitetos, desenvolvedores, analistas de negócio, entre outros, a decisão final precisa ser tomada por ele. Da mesma forma, nenhuma alteração ao escopo do projeto deve ser tomada sem a presença e o consentimento do product owner. É claro que isso não significa que suas decisões não possam ser questionadas, apenas que todas elas devem ser compartilhadas com ele.

O product owner pode ser o próprio cliente, mas o mais indicado é que seja alguém do próprio time com um visão global do projeto, que entenda tanto do negócio do cliente, quanto do desenvolvimento e dos processos da empresa.

O que faz e o que deveria fazer o product owner

Segundo os guias de scrum, é papel do product owner registrar e ordenar com clareza os itens de backlog do projeto, garantir que todos do time estejam cientes e entendam os itens do backlog, garantir o valor do trabalho da equipe e, por fim, perceber se o MVP está entregando o valor esperado pelo cliente e comandar as melhorias contínuas em ciclos interativos.

Mais do que isso, o product owner deve perceber que ele tem um papel duplo para o sucesso do projeto: ao mesmo tempo que acompanha o cliente através da construção do software, também mantém o time trabalhando em prol das entregas. Em resumo, 50% do tempo de um product owner deve ser gasto para entender o negócio do cliente enquanto os outros 50% devem ser gastos passando esse conhecimento para o restante do time.

O que não fazer como product owner

O papel de conectar clientes e time pode fazer com que o product owner não saiba lidar com tanto poder, se isolando em meio a tomadas de decisão. Em geral, esse comportamento é fatal para o projeto.

O ideal em projetos que possuam um product owner destacado é que se faça reuniões semanais entre cliente e equipe desenvolvimento. Ainda que haja um líder, a tendência é que a tomada de decisões seja um fardo dividido entre todos. Um indicativo dessa mudança acontece quando o product owner deixar de falar no singular – eu – e passa a utilizar o plural – nós. Ainda que pareça algo banal, é fundamental que o PO entenda que todos vencem ou falham juntos.

Você é um product owner? Trabalha para um? Conte sua experiência para nós nos comentários abaixo.


09
May 14

Conheça a metodologia da Informant! Etapa 4

Chegamos ao fim da série de quatro posts sobre a metodologia de desenvolvimento de softwares da Informant. Durante a série, conseguimos expor como nosso time trabalha com o objetivo de construir uma ferramenta capaz de entregar a solução para o problema do cliente, dentro de prazo e custo saudável, utilizando o que há de mais pioneiro em tecnologia, design e planejamento.

Mas antes de terminar, vamos tratar de um ponto que é o principal desejo de todo empreendedor quando cria sua empresa: vê-la crescer e atrair cada vez mais usuários. Mesmo que esse estágio não pareça trabalho para uma fábrica de software, aqui na Informant temos a convicção de que podemos ser parceiros dos nossos clientes durante toda a vida útil do software. Assim, criamos uma metodologia que melhora a ferramenta e dá a ela combustível para avançar sempre em frente. Então, para encerrar, conheça os três pontos fundamentais para o crescimento:

Computação em nuvem

Atualmente quando um software é planejado através de metodologias ágeis e design thinking, ele também é pensado para estar disponível o máximo de tempo possível. Por estar disponível, é preciso entender que não significa apenas estar num servidor hospedado na nuvem – ao invés de servidores locais e seus emaranhados de cabos azuis – mas ser acessível a todos.

Quando um cliente está decidindo pela sua empresa ele não precisa o que você está fazendo para manter seu site no ar. Na verdade, ele quer poder acessar o sistema através do seu computador, mas também de um smartphone ou tablet com acesso móvel. Isso significa que sua ferramenta precisa estar disponível para todos a todo momento para que você possa atrair mais clientes e continuar crescendo.

Análise de engajamento

Mesmo com toda essa tração não significa que seu software seja perfeito. Ao longo do caminho é provável que novos clientes, com problemas diferentes, sugiram melhorias e incrementos. À medida que esses pedidos se tornam constantes é seu dever implementá-los. Não apenas para satisfazer os novos clientes e atrair mais, mas também para se posicionar um passo à frente da concorrência.

Implementar melhorias no software em busca de mais crescimento é um processo infinito. Ou seja, a empresa precisa monitorar e melhorar constantemente para manter-se na liderança. Um dos grandes erros das empresas que vão à falência é considerar a inovação algo desnecessário por estarem há muito tempo na frente. Muitas vezes, essa lentidão servirá de sinal para o seu concorrente lançar algo melhor e mais moderno.

Para que isso não aconteça e para que você possa construir um software alinhado com os objetivos da sua empresa, sem estourar prazos e orçamentos, procure nosso time e vamos colocar em prática tudo que tratamos nessa série de posts. Nossa metodologia funciona não apenas para novas ferramentas, mas para empresas que procuram melhorar seus processos através de um avanço tecnológico. Através da análise do problema, desenvolvimento da solução, métricas, engajamento e um total apoio ao cliente do início ao fim do processo.

Mais alguma dúvida? Vamos continuar o assunto nos comentários abaixo. Participe!


26
Apr 14

Conheça a metologia da Informant! Etapa 3

Metodologia Informant

No terceiro post da série sobre a metodologia de desenvolvimento de software que utilizamos na Informant vamos nos aprofundar na importância do acompanhamento das métricas e de como elas nos guiarão na busca de uma ferramenta muito mais completa e funcional.

Ao longo dos últimos dois posts,  falamos sobre como, em parceira com o cliente, conseguimos identificar o problema do usuário e, baseado nele, projetar um software que entregue a melhor solução dentro do orçamento e prevendo um retorno sobre o investimento. Através de metodologias de design thinking, user experience e desenvolvimento ágil, os sistemas que criamos surpreendem pela rapidez com que são lançados e pela confiabilidade de uso.

Para chegar neste ponto precisamos passar pela terceira etapa do processo com sucesso. Sem boas métricas, análises e acompanhamentos, corremos o risco de construir uma ferramenta pouco útil para o cliente, se transformando em prejuízo para a empresa. Assim, nos próximos parágrafos iremos explicar como as métricas são fundamentais para o desenvolvimento de software. Acompanhe:

A diferença entre métricas e feedbacks

Quando um software é lançado, mesmo em sua fase beta, conseguimos colher um grande volume de dados. Através de ferramentas de análise é possível medir todas as interações do usuário sem afetar a navegação ou a experiência de uso.

Por outro lado, é preciso diferenciar o que é métrica e o que é feedback nesse processo. Métricas são resultados vindos de uma grande porção de interações e servem para dar uma visão geral sobre o desempenho do software. Já feedbacks são gerados por usuários reais e são relevantes para correções pontuais, como uma funcionalidade que não esteja funcionando corretamente.

Ambos são importantes para as melhorias na ferramenta, mas devem fazer parte de estratégias diferentes. Métricas são mais fáceis de serem conseguidas; já feedbacks precisam ser incentivados.

Quais métricas são relevantes?

No meio de tanta informação é preciso saber separar o que é importante medir do que deve ser ignorado. Isso serve tanto para métricas, quanto para feedbacks dos usuários. Se seguirmos todas as métricas podemos cair na tentação de corrigir todos os aspectos do software, perdendo o foco do que realmente interessa: entregar uma solução simples, que resolva o problema do cliente.

Assim, é fundamental estabelecer uma métrica central para o software. Esta pode ser o número de cálculos que ele fará, ou a taxa de conversão de novos usuários. A partir disso é que as melhorias são decididas. Em relação aos feedbacks, não se deve fazer todas as correções e melhorias que os usuários solicitarem, apenas aquelas que se tornarem recorrentes. Ou seja, se algo está incomodando, mais de um usuários irá reclamar. Dessa forma, não perca tempo criando backlogs de reclamações, você saberá exatamente o que precisa ser melhorado no software.

Aprendendo e melhorando

A partir das métricas e feedbacks recebidos, as melhorias são listadas e implementadas. Com um pouco de tração já é possível lançar melhores versões do software em busca de mais usuários. Quando você chegar neste estágio seu software já estará pronto para escalar e se tornar lucrativo, mas isso não significa que nosso trabalho terminou! No próximo post falaremos sobre como a Informant pode te oferecer o combustível que falta para seu software decolar.

Continue acompanhando a série e deixe seu comentário abaixo! Até lá!


25
Apr 14

Conheça a metodologia da Informant! Etapa 2

Continuando a série de posts sobre a metodologia de desenvolvimento de software da Informant, hoje vamos falar sobre como nosso time é capaz de avançar com o seu projeto sem turbulências rumo ao resultado desejado.

Antes disso convém lembrar a importância que demos no início da nossa série em descobrir o problema da sua empresa ou do seu cliente antes de começar a construir uma nova ferramenta. O acúmulo de informação na primeira etapa servirá de base para o que será proposto a partir daqui. Aliadas, as duas fases trabalharão para que o retorno sobre o investimento seja o maior possível, dentro de um prazo saudável de desenvolvimento.

Assim, já com o problema claro, passamos para o estágio de validação de hipóteses, de construção do software e engajamento dos primeiros usuários. Acompanhe a continuação da série a seguir:

Validando hipóteses

O processo de validação de hipóteses é fundamental para o desenvolvimento de um software. É comum muitos clientes acreditarem que possuem, instintivamente, a melhor solução para os seus clientes, sem realmente testar suas deduções. Dessa forma acabam criando ferramentas que não serão úteis e menos ainda comerciais.

Um bom método para validar hipóteses é conversar com seus clientes para tentar entender se a solução que você está criando é realmente funcional para eles. Ou seja, se ela resolve o problema dele. Caso contrário, com os feedbacks recebidos é possível fazer melhorias até se encontrar a melhor solução. Faça uma pequena apresentação ou então simule o funcionamento do seu software para perceber a aceitação dos seus futuros usuários.

A partir dessa solução é que começamos o construção do software através da metodologia de desenvolvimento ágil.

A metodologia ágil

A metodologia de desenvolvimento ágil de software tem como objetivo garantir a satisfação do cliente entregando rapidamente e continuamente softwares funcionais. Na prática isso significa que nosso time irá entregar resultados quase que semanalmente (ao invés de em meses, como na indústria de software tradicional).

Esse tipo de desenvolvimento encoraja a participação do cliente para que o resultado final seja o melhor possível. Mesmo mudanças tardias de escopo são bem-vindas se essas se mostrarem necessárias para o objetivo do projeto. Prezando pela excelência técnica e simplicidade, a metodologia ágil de software diminui os riscos da implementação e maximiza o retorno sobre o que foi investido na ferramenta.

Para que a metodologia ágil seja um sucesso, é fundamental que haja confiança entre as partes. Do contrário perde-se agilidade na tomada de decisões em prol de um software melhor.

Engajamendo de early adopters

Com a ferramenta em fase de finalização é preciso colocar usuários reais para testá-la. O objetivos desses testes não é procurar por falhas – apesar de esse também ser um estágio importante – mas entender como eles irão se engajar com o software.

Os primeiro usuários – chamados de early adopters – costumam estar mais abertos a novidades e novos sistemas, sendo bons testadores para novas funcionalidades. A partir do feedback deles é que alterações e melhorias poderão ser feitas, mesmo após o lançamento da ferramenta. Aos poucos mais usuários são colocados para dentro do software, gerando mais dados e mais feedbacks. Essa medição e análise são alicerces para o sucesso do seu software, mas este será o assunto do nosso próximo post. Continue acompanhando a série e comente através do formulário abaixo.


23
Apr 14

Conheça a metologia da Informant! Etapa 1

A internet é o meio mais propício para inovar. A velocidade com que as coisas acontecem, são construídas, atraem usuários e faturam faz do virtual o melhor espaço para se testar ideias e novos projetos. Inclusive com pouco – ou nenhum – capital.

Mas isso não significa que as coisas aconteçam sem o mínimo de organização ou métodos. A máxima de que “faça e eles virão” já não funciona tão bem quanto há algum tempo, quando a concorrência não era tão grande e os produtos e serviços digitais tão bons. Na prática, isso significa que sua empresa ainda encontrará espaço para inovar, mas precisará seguir algumas metodologias para amadurecer suas ideias e produtos.

E é sobre essas metodologias, que norteiam o trabalho da Informant, que iremos nos aprofundar numa série de quatro posts. Começamos hoje com algumas definições sobre as vantagens de entender o seu problema no desenvolvimento de um novo produto. Acompanhe:

Entendendo o problema do seu cliente

A metodologia que adotamos na Informant tem como foco a satisfação do cliente. Utilizamos métodos e tecnologias para o desenvolvimento de software de acordo com o que há de mais moderno atualmente. Através de desenvolvimento ágil conseguimos reduzir os riscos, aumentar o engajamento e, principalmente, maximizar o retorno sobre o investimento.

O primeiro passo nessa jornada é entender profundamente o problema do cliente. Isso significa mapear sua base de usuários, as soluções que já oferece, o mercado, as soluções que o mercado oferece e, com esses dados, tentar criar um software que não apenas resolve o problema, mas que também seja capaz de ser inovador e escalável de acordo com os interesses da empresa.

Esse primeiro passo é tão importante que pode definir o sucesso de toda a ferramenta, já que sem ele há chances de se criar um software sem utilidade para a empresa ou para os clientes dela.

Vantagens de uma solução adequada

Mapear as necessidades do cliente com a aplicação fará com que o sistema tenha um aproveitamento maior, aumentando o retorno sobre o investimento e diminuindo a necessidade de correções e melhorias.

Outra vantagem importante é ganho de tempo. Muitas vezes um cliente não sabe exatamente o que procura para sua empresa, ou por não entender seu problema ou por não saber comunicá-lo à fábrica de software. Quando se tem um metodologia focada em descobrir esse problema – e sua devida solução – é possível economizar tempo tanto no planejamento quanto na implementação do sistema.

Com todas essas informações cria-se um protótipo através de metodologias de design thinking, user experience e mínimo produto viável. Tudo para otimizar o desenvolvimento da ferramenta, reduzir o risco e aumentar o faturamento. Essa metodologia tem como ponto forte o teste constante. Ou seja, lado a lado com o cliente o software é melhorado e otimizado. Na prática quer dizer que sua empresa terá um pouco mais de trabalho para acompanhar o nascimento do software. Por outro lado, terá um sistema muito mais útil para os objetivos do negócio.

Nos próximos posts iremos falar sobre validação de hipóteses, métricas, aprendizado e como avançar sempre. Acompanhe nossa série e participe opinando através dos comentários abaixo!

 


04
Jun 10

Informant estará no Agile Brazil 2010

Buscando evoluir nossos conhecimentos em Métodos Ágeis de Desenvolvimento de Software, a Informant participará do Ágile Brazil 2010, uma conferência nacional sem fins lucrativos organizada por representantes das principais comunidades ágeis brasileiras. O evento tem como objetivo promover a comunicação e a colaboração entre seus integrantes visando à disseminação coordenada da cultura Ágil por todo o país

O Ágile Brazil 2010 acontecerá no campus central da PUCRS, em Porto Alegre, de 22 a 25 de Junho. Contará com cursos, apresentação de trabalhos e relatos de experiência provenientes de várias regiões do país.

Como keynotes, teremos a oportunidade de ouvir Martin Fowler, cientista chefe da ThoughtWorks, Philippe Kruchten, professor da UBC em Vancouver (Canadá) e conhecido também por ter liderado a equipe do RUP na Rational Software, e Klaus Wuestefeld, pioneiro de Programação Extrema no Brasil. Além deles, David Hussman, vencedor do Gordon Pask Award em 2009, também participará como convidado especial ministrando um curso e apresentando uma palestra no evento.

No evento a Informant será representada pelo Eduardo Kruger, Líder de Desenvolvimento, que trará na bagagem muita informação para ser compartilhada com todos nós.

Saiba mais sobre o evento em http://www.agilebrazil.com/