Um Framework Foda para você inovar.

Do MVP ao MARKET FIT sem grana.

Muitas pessoas falam a respeito de inovação. Mas o que realmente é inovação? Por que as empresas devem inovar? O que torna uma empresa inovadora?

Primeiramente devemos entender o que é inovação. Inovação vai muito além de criar um novo produto, ou ter uma ideia que vá mudar o negócio de sua empresa. Inovação pode ser a criação de um novo produto ou serviço, mas também pode ser a criação de novos modelos de negócios, entrar em novos mercados, novas formas de gestão, desenvolvimento de marca, criação de canais de distribuição, criação de plataformas tecnológicas, etc.

Inovação é transformar novas ideias (produto, processo, cliente, canal de distribuição, etc) em resultados. Além disso, a inovação deve estar alinhada com a estratégia da empresa, precisa ser induzida por ferramentas e metodologias específicas e ser um processo continuado e gerenciado.

Abaixo entrego todas as etapas do processo ágil inicial para você que não possui aquele budget inicial necessário e quer utilizar ferramentas práticas e acessíveis.

1. Cultura Antifrágil 

Desde o DAY 1 (ONE) é essencial que a cultura por trás da inovação que esteja sendo proposta esteja caracterizada e bem definida pelos Founders. São elas que darão sustentabilidade para as outras etapas que serão apresentadas no processo , elas que guiarão a dinâmica e o senso abstrato do PERFIL que os colaboradores vindouros terão que seguir, ser antifrágil , nesse caso, não é apenas ter uma estrutura de personificação resiliente, mas sim, inflexionar, aprender com os erros e transformar em ações corretivas, gerando uma sustentabilidade organizacional.

Tarefas a serem elaboradas

A. Com todos os ´´founders``(participantes) presentes, escreva o que eu chamo de ´´Pedra fundamental``, pode ser numa folha de papel, num quadro negro ( Sim, sou crunge) , aonde você achar conveniente, e escreva , deixe claro quais são os valores que vão nortear toda a operação daqui pra frente, importante ressaltar que os valores devem seguir as características dos próprios founders , portanto, TRANSPARÊNCIA, AGILIDADE, FOCO DO CLIENTE, etc, são valores que os próprios participantes tenham como SOFT SKILLS, para assim repassarem aos próximos entrantes do projeto, lembre-se, a PALAVRA move, mas o EXEMPLO arrasta.

2. Design Thinking

A primeira informação que deve ficar clara é que não é uma metodologia, mas uma abordagem. Isso porque, quando pensamos em método, criamos a expectativa de ter às mãos uma fórmula matemática que se aplique indistintamente em qualquer situação. Não é o caso.

É uma abordagem que busca a solução de problemas de forma coletiva e colaborativa, em uma perspectiva de empatia máxima com seus stakeholders (interessados). Em síntese, as pessoas são colocadas no centro de desenvolvimento do produto – não somente o consumidor final, mas todos os envolvidos na ideia (trabalhos em equipes multidisciplinares são comuns nesse conceito).

O processo consiste em tentar mapear e mesclar a experiência cultural, a visão de mundo e os processos inseridos na vida dos indivíduos, no intuito de obter uma visão mais completa na solução de problemas e, dessa forma, melhor identificar as barreiras e gerar alternativas viáveis para transpô-las. Não parte de premissas matemáticas, parte do levantamento das reais necessidades de seu consumidor; é uma abordagem preponderantemente “humana”, usada em qualquer área de negócio.

Assim, as etapas do Design Thinking podem, em geral, ser resumidas pelos seguintes passos:

1- Identificar onde encontrar oportunidades de inovação

“Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Ou se conhece a si, mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota. Mas, se não conhece nem o inimigo nem a si mesmo, perderá todas as batalhas”. Este é um trecho de “A Arte da Guerra”, do filósofo chinês Sun Tzu, e que diz muito sobre o ponto que estamos abordando.

Dessa forma, descobrir onde encontrar caminhos para inovar envolve conhecer a si mesmo e ao ambiente externo. Conhecer seus pontos fortes, as fragilidades da concorrência, as condições macroeconômicas, etc. E, além disso, análise SWOT, benchmarking, pesquisas de mercado e reuniões multidisciplinares te conduzirão às respostas para esse ponto.

2- Descobrir a Oportunidade de Inovação

Consequência direta do ponto anterior, aqui, pesquisas qualitativas e trabalho com soluções de Big Social Data podem indicar, muito além do setor, qual é, de fato, a oportunidade que o mercado desenha ao seu negócio.

3- Desenvolver a Oportunidade de Inovação (Produto ou Serviço)

O Design Thinking começa a tomar corpo nessa etapa. Aqui, iremos desenvolver o produto ou serviço partindo, não de pressuposições ou análises estatísticas frias (algo comum no mercado), mas a partir das necessidades e percepção de valor do cliente. Nesta etapa, poderemos lançar mão do Processo Heurístico para descobrir o diagnóstico e o Processo Criativo para gerar as possibilidades de produtos.

4- Testar as ideias — protótipos

Um MVP é uma bela dica do que se pode fazer nesse item. MVP (muito usado em startups) é a versão mais simples de um produto, que pode ser lançada em período de testes, para verificar, nesse meio tempo, se sua ideia realmente atinge as necessidades do seu consumidor final.

5- Implementar a solução

Após testes com respostas positivas acerca de seu produto, ele já está pronto para ser lançado “aos leões”. É importante entender que o processo de desenvolvimento do produto é contínuo e incremental, ou seja, sua ideia irá ser melhorada permanente através um processo de copartipação entre todos os seus stakeholders (clientes, fornecedores, colaboradores internos, etc.).

3- Scrum

A metodologia scrum funciona em fases simples e em ciclos. Antes de falarmos sobre o processo em si, é bom pontuar que existem muitos termos específicos do método, mas que são fáceis de entender e explicar para os profissionais envolvidos. 

Dividimos os passos para facilitar o entendimento do processo. 

• Passo 1: Ter uma visão total do projeto
• Passo 2: Dividir as funcionalidades
• Passo 3: Definir prioridades
• Passo 4: Dividir em ciclos
• Passo 5: Iniciar dos ciclos
• Passo 6: Revisão dos ciclos

Vamos aos detalhes!

Passo 1: Ter uma visão total do projeto

O Product Owner ou dono do projeto (explicaremos mais sobre o seu papel a seguir) precisa visualizar todo o projeto e o que se espera do produto final para a realização do planejamento. Basicamente, é necessário ter bem claro qual é o objetivo a ser atingido na finalização do projeto.

Passo 2: Dividir as funcionalidades

Nesse momento, o responsável pelo projeto precisa desmembrar cada conjunto de objetivos ou funcionalidade do produto, fazendo uma lista ou Product Backlog, como é chamada na metodologia scrum. Aqui é importante não deixar nenhuma demanda de fora, pois fará toda a diferença para a conclusão do projeto.

Passo 3: Definir prioridades 

Como em qualquer processo de gestão de projetos, é necessário definir prioridades sobre quais funcionalidades devem ser realizadas inicialmente e quais podem ficar para depois. Também é o Product Owner quem faz essa escolha, afinal é ele quem tem a total visão do que se espera do produto. 

Passo 4: Dividir em ciclos

Neste momento, é necessário dividir o projeto em ciclos, conhecidos como Sprints. Eles determinam o período que cada conjunto de atividades do Product Backlog tem para ser concluída. Não há uma regra, mas, geralmente, os sprints têm duração de duas a quatro semanas. É extremamente importante que esses prazos sejam cumpridos.

Passo 5: Iniciar os ciclos

Com os sprints definidos, a equipe planeja as tarefas de cada ciclo e define as prioridades na Sprint Planning Meeting (reunião de planejamento do sprint). Nela, todos os detalhes e funções serão divididos. Com essa decisão tomada, é a hora de iniciar os trabalhos. Quando um sprint começa a ser realizado, ele sai do Product Backlog e vai para o Sprint Backlog. 

Uma das principais características da metodologia scrum é o acompanhamento frequente dos ciclos. Diariamente, toda a equipe faz o Daily Scrum ou Daily Meet, no qual cada integrante da equipe diz o que realizou até o dia anterior, o que pretende fazer naquele dia e quais os obstáculos encontrados. 

Neste encontro diário, é possível que a equipe discuta alternativas para as tarefas e já corrija eventuais desafios do processo, evitando problemas maiores no futuro.

Passo 6: Revisão dos ciclos

Ao concluir o prazo para finalização de um Sprint, há uma reunião final (Sprint Retrospective) para revisar cada grupo de atividades e validar as funcionalidades. Neste momento, também se faz uma avaliação de eventuais desafios encontrados pelas equipes e que devem ser sanados antes do início do novo sprint. 

Todo esse processo se repete até que o produto seja concluído na sua versão final, com a realização de quantos sprints forem necessários. Não há um limite de sprints definido, sendo papel do Product Owner entender quantos são necessários para o seu projeto.

Equipe de gestão de projetos ágil: como funciona com o scrum?

Assim como em todo projeto ou organização, existe uma hierarquia na metodologia Scrum. Afinal, é necessário que haja um profissional no comando da equipe multidisciplinar que trabalhará no desenvolvimento do produto. 

Para o sucesso do projeto, é importante que a empresa e os membros da equipe entendam qual o seu papel. Explicamos um pouco mais sobre cada um dos papéis do scrum:

Product Owner

Ele é o líder ou gerente do projeto, ou seja, é o responsável pelo objetivo final do produto. Logo, possui um papel de liderança, tomará as principais decisões sobre o processo de desenvolvimento daquele projeto, sendo o principal responsável pelo sucesso na conclusão do produto.

Owner que será responsável por visualizar todo o projeto, dividir as funcionalidades e definir a ordem de prioridade de execução das demandas. 

Já o líder, é quem deve ser o motivador da equipe e explicar o que espera ao final daquele projeto concluído. Será esse profissional quem deve passar a filosofia Agile para todos os integrantes do grupo.  

Scrum master

Se o Product Owner é o responsável pelo projeto como um todo,  o Scrum Master é quem irá ajudar os demais integrantes da equipe a entenderem os princípios, valores e como funciona a metodologia Scrum. É uma das funções mais importantes para que o método tenha sucesso em uma organização. 

Ele também tem um papel de liderança, mas um pouco diferente do gestor do projeto, exercendo uma função de coach, pois deve auxiliar os membros do time a desenvolver sua maneira de utilizar a abordagem do Scrum. 

Lembre-se de que o Scrum Master não pode mudar as decisões do Product Owner, mas sim encontrar formas de ajudar a equipe a ter melhor desempenho para a conclusão de cada sprint. Quando o time encontrar um problema, é esse profissional também que vai atuar na solução do que pode estar atrapalhando o desenvolvimento do projeto. 

Em empresas que estão começando a aplicar a metodologia, contar com um Scrum master se torna ainda mais importante. 

Equipe de desenvolvimento

A equipe de desenvolvimento ou Scrum Team são todos os profissionais que formam a equipe responsável pela conclusão daquele projeto. Normalmente, forma-se um time multidisciplinar, pois a criação de um novo produto exige uma pluralidade de conhecimentos impossível de ser encontrada em apenas uma especialidade. 

Essa equipe deve seguir o que está previsto em cada sprint, seguindo as normas da empresa e a transparência do projeto, colaborando a cada Daily Scrum. Basicamente, funciona assim: o Scrum Team é orientado e apoiado pelo Scrum Master para realizar o que foi planejado pelo Product Owner. O objetivo final desse trabalho é a conclusão do projeto. 

De maneira geral, entende-se que a equipe de desenvolvimento deve ser formada por poucos profissionais e com focos específicos.

4. Kanban

O Kanban é uma estrutura popular usada para implementar o desenvolvimento de software ágil e de devops. Ele precisa de comunicação de capacidade em tempo real e transparência total de trabalho. Os itens de trabalho ganham representação visual em um quadro kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento.

O Kanban é muito proeminente entre as equipes de software ágil e de DevOps de hoje, mas essa metodologia de trabalho remonta a mais de 50 anos. No fim dos anos 1940, a Toyota começou a otimizar seus processos de engenharia com base no mesmo modelo que os supermercados usavam para abastecer suas prateleiras. Os supermercados abastecem apenas a quantidade de produtos suficiente para atender à demanda dos consumidores, uma prática que otimiza o fluxo entre o supermercado e o consumidor. Como os níveis de estoque correspondem a padrões de consumo, o supermercado ganha uma eficiência significativa na gestão de estoques, reduzindo a quantidade excessiva de produtos a ser mantida a qualquer momento. Mesmo assim, o supermercado ainda consegue garantir que determinado produto do qual um consumidor precisa esteja sempre no estoque.

Quando a Toyota aplicou esse mesmo sistema em seu chão de fábrica, o objetivo era alinhar melhor seus níveis enormes de estoque com o consumo real de materiais. Para comunicar níveis de capacidade em tempo real no chão de fábrica (e aos fornecedores), os trabalhadores passavam um cartão, ou "kanban", entre as equipes. Quando um contêiner de materiais usados na linha de produção era esvaziado, um kanban era passado para o depósito, descrevendo o material que era necessário, a quantidade exata dessa material e assim por diante. O depósito contava com um novo contêiner desse material em espera, o qual era enviado para o chão de fábrica, que, por sua vez , enviava seu próprio kanban para o fornecedor. O fornecedor também tinha um contêiner desse material particular em espera, que deveria ser enviado para o depósito. Embora a tecnologia de sinalização desse processo tenha evoluído desde a década de 1940, esse mesmo processo de fabricação "just in time" (ou JIT) continua no centro do processo.

Kanban para equipes de software

Hoje, as equipes ágeis de desenvolvimento de softrware são capazes de aproveitar esses mesmos princípios do JIT, combinando a quantia do trabalho em andamento (WIP) com a capacidade da equipe. Isso proporciona às equipes opções de planejamento mais flexíveis, saída mais rápida, foco mais claro e transparência ao longo do ciclo de desenvolvimento.

Embora os princípios centrais da estrutura sejam atemporais e aplicáveis a quase todas as indústrias, as equipes de desenvolvimento de software encontraram um sucesso especial com a prática ágil. Isso ocorre, em parte, porque as equipes de software podem começar a praticar com pouca ou nenhuma sobrecarga, uma vez que entendem os princípios básicos. Ao contrário da implementação do Kanban no chão de fábrica, que envolveria mudanças nos processos físicos e a adição de materiais substanciais, as únicas coisas físicas que as equipes de software precisam são um quadro e cartões, que podem até mesmo ser virtuais.

Quadros do Kanban

O trabalho de todas as equipes Kanban gira em torno de um quadro do kanban, uma ferramenta usada para visualizar o trabalho e otimizar o fluxo do trabalho entre a equipe. Embora os quadros físicos sejam populares entre algumas equipes, os quadros virtuais são um recurso crucial em qualquer ferramenta de desenvolvimento ágil de software para sua rastreabilidade, colaboração mais fácil e acessibilidade de vários locais.

Independentemente de o quadro de uma equipe ser físico ou digital, sua função é assegurar que o trabalho da equipe seja visualizado, que seu fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos. Um quadro básico do Kanban tem um fluxo de trabalho de três etapas: "To Do", "In Progress" e "Done" (a fazer, em andamento e feito). No entanto, dependendo do tamanho, da estrutura e dos objetivos da equipe, o fluxo de trabalho pode ser mapeado para atender ao processo exclusivo de qualquer equipe específica.

A metodologia Kanban depende da transparência total do trabalho e da comunicação de capacidades em tempo real. Portanto, o painel Kanban deve ser visto como a única fonte de verdade para o trabalho da equipe.

Cartões Kanban

Em japonês, kanban é traduzido literalmente como "sinal visual." Para as equipes Kanban, cada item de trabalho é representado como um cartão separado no quadro.

A principal finalidade de representar o trabalho como um cartão no quadro do Kanban é permitir que os membros da equipe acompanhem seu andamento por meio do fluxo de trabalho e de uma maneira altamente visual. Os cartões Kanban apresentam informações cruciais sobre determinado item de trabalho, dando visibilidade total à equipe sobre quem é o responsável por ele, uma breve descrição da tarefa sendo feita, qual a estimativa de tempo para essa parte do trabalho e assim por diante. Muitas vezes, os cartões nos quadros virtuais do Kanban também apresentarão capturas de tela e outros detalhes técnicos valiosos para o destinatário. Ao permitir que os membros da equipe visualizem não só a situação de cada item de trabalho a qualquer momento, mas também todos os detalhes associados, garante-se maior foco, total rastreabilidade e identificação rápida de bloqueadores e dependências.

Os benefícios do Kanban

O Kanban é uma das metodologias de desenvolvimento de software mais populares adotadas por equipes ágeis atualmente. Ele oferece várias vantagens adicionais para o planejamento e a transferência de tarefas para equipes de todos os tamanhos.

Flexibilidade de planejamento

Uma equipe Kanban concentra-se apenas no trabalho ativo em andamento. Depois que a equipe conclui um item de trabalho, ela remove o próximo item de trabalho do topo do backlog. O proprietário do produto é livre para priorizar o trabalho na lista de pendências sem interromper a equipe, porque qualquer alteração fora dos itens de trabalho atuais não impactam a equipe. Contanto que o proprietário do produto mantenha os itens de trabalho mais importantes no topo da lista de pendências, a equipe de desenvolvimento tem certeza de que está retornando o valor máximo para a empresa. Portanto, não há necessidade das iterações de extensão fixa que você encontra no scrum.

DICA PROFISSIONAL:

Proprietários de produtos experientes sempre se envolvem com a equipe de desenvolvimento ao levarem em consideração as mudanças na lista de pendências. Por exemplo, se as histórias dos usuários 1 a 6 estão na lista de pendências, a estimativa da história do usuário 6 pode ser baseada na conclusão das histórias dos usuários 1 a 5. É sempre uma boa prática confirmar as mudanças com a equipe de engenharia para garantir que não haja surpresas.

Tempos de ciclos reduzidos

O tempo de ciclo é uma métrica-chave para as equipes Kanban. O tempo de ciclo é a quantidade de tempo que uma unidade de trabalho leva para passar pelo fluxo de trabalho da equipe desde o momento que o trabalho é iniciado até o seu envio. Ao otimizar o tempo de ciclo, a equipe pode prever com confiança a entrega do trabalho futuro.

A sobreposição de conjuntos de habilidades leva a tempos de ciclo menores. Quando apenas uma pessoa detém um conjunto de habilidades, ela se torna um gargalo no fluxo de trabalho. Dessa forma, as equipes empregam as melhores práticas básicas, como revisão de código e ajuda em mentoria, para disseminar o conhecimento. Habilidades compartilhadas significam que os membros da equipe podem assumir um trabalho heterogêneo, o que otimiza ainda mais o tempo de ciclo. Isso também significa que, se houver um backup do trabalho, toda a equipe pode se mover para que o processo flua perfeitamente outra vez. Por exemplo, o teste não é feito apenas por engenheiros de controle de qualidade. Os desenvolvedores também o fazem.

Em uma estrutura Kanban, é responsabilidade de toda a equipe assegurar que o trabalho esteja avançando perfeitamente pelo processo.

Menos gargalos

Ser multitarefas mata a eficiência. Quanto mais itens de trabalho em curso em um determinado momento, mais troca de contexto, o que dificulta o caminho para a conclusão. É por isso que um dos princípios básicos do Kanban é limitar a quantidade de tarefas em andamento (WIP, Work in Progress). Esse recurso limita gargalos e backups em destaques no processo da equipe devido à falta de foco, pessoas ou conjunto de habilidades.

Por exemplo, uma equipe de software típica pode ter quatro estados de fluxo de trabalho: "A fazer", "Em andamento", "Análise de código" e "Concluído". Eles poderiam optar por definir um limite WIP de 2 para o estado de análise de código. Pode parecer um limite baixo, mas tem um bom motivo: muitas vezes os desenvolvedores preferem escrever um código novo em vez de gastar o tempo revendo o trabalho de outra pessoa. Um limite baixo encoraja a equipe a prestar atenção especial aos problemas no estado de análise e a analisar o trabalho de outros antes de criar suas próprias análises de código. Assim, o tempo total de ciclo é reduzido.

Métricas visuais

Um dos valores centrais é um foco robusto na melhoria continua da eficiência e eficácia da equipe com cada iteração do trabalho. Os gráficos fornecem um mecanismo visual para as equipes garantirem a continuidade da melhoria. Quando a equipe pode ver os dados, é mais fácil detectar os gargalos no processo e removê-los. Dois relatórios comuns usados pelas equipes Kanban são os de gráficos de controle e os de diagramas de fluxo cumulativos.

Um gráfico de controle mostra o tempo de ciclo para cada problema, bem como uma média contínua para a equipe.

DICA PROFISSIONAL:

O objetivo da equipe é reduzir o período de tempo que um item leva para passar por todo o processo. Ver a queda do tempo médio do ciclo no gráfico de controle é um indicador de sucesso.

Um diagrama de fluxo cumulativo mostra o número de itens em cada estado. A equipe pode detectar bloqueios com facilidade vendo o número de aumento de itens em qualquer estado determinado. Os itens em estados intermediários, como "Em andamento" ou "Em revisão", ainda não foram enviados para clientes e um bloqueio nesses estados pode aumentar a probabilidade de conflitos de integração em massa quando o trabalho for incorporado a montante.

Scrum vs. Kanban

Kanban e scrum compartilham alguns dos mesmos conceitos, mas têm diferentes abordagens. Eles não devem ser confundidos um com o outro.

Sprints regulares com extensão fixa (2 semanas)

Fluxo contínuoMetodologia de versõesNo final de cada sprint, se aprovado pelo proprietário do produtoEntrega contínua ou a critério da equipeFunçõesProprietário do produto, mestre scrum, equipe de desenvolvimentoSem funções existentes. Algumas equipes recorrerem à ajuda de um agile coach.Principais métricasVelocidadeTempo de cicloFilosofia de mudançaAs equipes devem se esforçar para não fazer alterações na previsão de sprint durante o sprint. Ao fazer isso, o aprendizado em torno da estimativa fica comprometido.Mudanças podem ocorrer a qualquer momento

Algumas equipes misturaram os ideais do Kanban e Scrum para formar o "Scrumban." Eles tomam os sprints de extensão fixa e as funções a partir do Scrum e focam nos limites de trabalho em andamento e no tempo de ciclo a partir do Kanban. 

Sugestões de ferramentas para utilizar :

-TRELLO ---- JIRA- --- ATLASSIAN ---- QUADRO NEGRO INLOCO .

Aplicando esses conceitos , provavelmente suas chances de decolar aquela projeto inovador irão aumentar bastante.

By Mauro fernando .