Fundamentos da análise de negócios | Andrei Adam | Skillshare
Pesquisar

Velocidade de reprodução


1.0x


  • 0.5x
  • 0.75x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 1.75x
  • 2x

Fundamentos da análise de negócios

teacher avatar Andrei Adam

Assista a este curso e milhares de outros

Tenha acesso ilimitado a todos os cursos
Oferecidos por líderes do setor e profissionais do mercado
Os temas incluem ilustração, design, fotografia e muito mais

Assista a este curso e milhares de outros

Tenha acesso ilimitado a todos os cursos
Oferecidos por líderes do setor e profissionais do mercado
Os temas incluem ilustração, design, fotografia e muito mais

Aulas neste curso

    • 1.

      Introdução

      2:24

    • 2.

      Produto um a um

      4:55

    • 3.

      Design Thinking

      7:08

    • 4.

      Ágil e SCRUM

      8:03

    • 5.

      Gestão de requisitos

      8:03

    • 6.

      Processo de refinamento

      9:34

    • 7.

      Gestão de backlog

      5:27

    • 8.

      Gestão de partes interessadas

      5:04

    • 9.

      O que é necessário para se tornar um (melhor) analisador de negócios

      8:41

  • --
  • Nível iniciante
  • Nível intermediário
  • Nível avançado
  • Todos os níveis

Gerado pela comunidade

O nível é determinado pela opinião da maioria dos estudantes que avaliaram este curso. Mostramos a recomendação do professor até que sejam coletadas as respostas de pelo menos 5 estudantes.

479

Estudantes

1

Projetos

Sobre este curso

Embarque em uma aventura de aprendizagem emocionante com nosso Crash Course on Business Analysis Fundamentals, especialmente concebido, e seu transporte para o mundo dinâmico do Desenvolvimento de Produto. Projetado como um curso simplificado, ele serve como uma porta de entrada dourada para adquirir e dominar as habilidades vitais necessárias em Business Analysis. Por meio de uma abordagem prática e imersiva, este curso garante que você navegue pelo campo vibrante e em constante evolução com requinte absoluto.

Prepare-se para um programa de estudos rico que desvenda os segredos por trás do desenvolvimento de produtos bem-sucedido. Desde a definição clara dos papéis intrincados até o domínio da arte de conceber estratégias inovadoras, este curso promete ser um tesouro de insights inestimáveis. Aprofunde-se para explorar estruturas essenciais e a arte matizada da gestão de partes interessadas enquanto se envolve em exercícios do mundo real que irão aprimorar suas habilidades recém-descobertas, transformando você em um analisador proficiente pronto para fazer progressos significativos na indústria.

Dê adeus ao labirinto de fontes confusas que antes pareciam infinitas e abrace de coração uma experiência de aprendizagem focada e prática criada para catapultar você para uma carreira promissora e gratificante. Juntos, embarcaremos nesta jornada transformadora, transformando suas aspirações em realidade tangível em meio ao movimentado cenário de negócios.

Junte-se a mim enquanto avançamos neste caminho emocionante, onde cada passo é um salto para realizar seus sonhos no mundo dos negócios em ritmo acelerado. Sua metamorfose em um analista de negócios experiente está apenas a um curso de distância. Vamos fazer isso acontecer, juntos!

Conheça seu professor

Teacher Profile Image

Andrei Adam

Professor

Hello, I'm Adam. I am an experienced Product Professional, practitioner and instructor with a rich background in various sectors, such as FinTech, Pharma, Banking, EdTech, Food Delivery, and Online Media. Leveraging my vast experience, I'm passionate about guiding aspiring professionals on their journey in product management, product ownership and business analysis. I believe in the transformative power of learning, and I'm committed to helping you unlock your potential and thrive in your chosen field. Join me as we explore the exciting world of business analysis together.

Visualizar o perfil completo

Level: All Levels

Nota do curso

As expectativas foram atingidas?
    Superou!
  • 0%
  • Sim
  • 0%
  • Um pouco
  • 0%
  • Não
  • 0%

Por que fazer parte da Skillshare?

Faça cursos premiados Skillshare Original

Cada curso possui aulas curtas e projetos práticos

Sua assinatura apoia os professores da Skillshare

Aprenda em qualquer lugar

Faça cursos em qualquer lugar com o aplicativo da Skillshare. Assista no avião, no metrô ou em qualquer lugar que funcione melhor para você, por streaming ou download.

Transcrições

1. Introdução: Olá aí. Meu nome é Adam. Eu sou um gerente de produto e eu estive no mundo do produto por algum tempo agora, vem desenvolvendo produtos em várias indústrias diferentes e introduzindo as pessoas ao mundo do produto abaixo da linha. É um mundo excitante. E o que o torna tão interessante é a diversidade, o conhecimento que baseia as interações, esse sentimento de conclusão que você obtém com cada recurso novo. Então, cada trabalho dos seus sonhos é analistas de negócios, proprietário do produto ou gerente de produto, mas você não tem idéia do que se trata, então tenha certeza de que você veio ao lugar certo. Se você já entrou neste reino mágico do produto, mas você ainda é novo nele. E você poderia usar um empurrão suave do que eu estou aqui para oferecer orientação com apenas a quantidade certa de inflamação de qualidade para aumentar sua confiança, temperado com dicas e truques, bem como um par de exercícios para fazer o motor funcionar. Vamos falar sobre o ciclo de vida de desenvolvimento de produtos e como envolver nossas cabeças em torno de todas as questões. Estaremos falando sobre papéis e responsabilidades e como escolher cuidadosamente o que desejava. Vamos mergulhar profundamente no gerenciamento de requisitos da estrutura e processo de refinamento de volta o gerenciamento de partes interessadas de login, mas também projetar formas de trabalho e autogerenciamento de pensamento. E no final, também teremos um gostinho do conjunto de habilidades tanto quanto para descobrir o que é preciso para chegar lá e não usar esse produto. Talvez você já tenha tentado digerir horas e horas de vídeos. Você deve ter lido milhares de palavras tentando descobrir o que é a gestão de produtos. Isso significa que você já se comprometeu com essa alteração. Tudo o que você precisa fazer agora é assumir esse compromisso com apenas um passo adiante e você tem o seu avanço. E há muitos cursos incríveis por aí, cada um deles focado em vários tópicos de gerenciamento de produtos. Este, no entanto, é o único curso que irá apresentá-lo ao mundo do produto e irá manter a porta aberta para você enquanto você se familiarizar plenamente com a terminologia e os conceitos e as formas de trabalhar, você vai entender do que se trata. Você não vai mais ficar confuso ou sobrecarregado, e você finalmente vai encontrá-lo ao seu alcance para fazer a mudança de carreira que você sempre sonhou com eles. Estou aqui para lhe oferecer uma visita guiada do que significa ser uma pessoa de produtos. E para os exercícios práticos que vamos passar. Você também terá um gostinho de como se sente ao gerenciar um produto. Desde táticas à estratégia. Tudo bem, vamos fazer isso. 2. Capítulo 1: Produto One-on-One a um: Em nossa primeira sessão, falaremos sobre o produto, um primeiro passo individual para o mundo do produto. Como seria o produto? Os dicionários de negócios definiram produtos como bens, ideias, métodos, inflamação, objetos ou serviços criados como resultado de um processo e que servem a uma necessidade específica. Portanto, um produto tem uma combinação de atributos tangíveis e intangíveis. Estes são os benefícios, os recursos. Por exemplo, quando você quiser comprar um carro, você pode considerar atributos tangíveis, como tamanho e cor, número de portas e assim por diante. Isso significa que você está procurando um produto com base em seus atributos tangíveis. Por outro lado, você também pode considerar atributos intangíveis, como preço, qualidade e pontuações de teste de segurança. Então, o que é um produto afinal? Bem, qualquer coisa pode ser um produto de uma caneta ou um telefone para um livro, ou uma festa de aniversário, ou mesmo uma pessoa que eu para mim, tornou-se meu próprio produto pessoal quando eu mudei de banco para desenvolvimento de produtos de software, Eu tive que adquirir novas habilidades e também mudar de forma e melhorar a forma como mostrou meu perfil no mercado. Mas por que você acha que precisamos de desenvolvimento de produtos? Precisávamos melhorar a qualidade e agregar valor para os clientes. Precisávamos melhorar o desempenho e reduzir os custos. Precisamos de desenvolvimento de produtos porque a melhoria contínua é vital para qualquer negócio. É o que está nos mantendo à frente do jogo, estão formando e fornecendo a melhor experiência do cliente. Centrado no cliente é sempre uma boa atitude, pois assim nunca perderemos o foco do que é realmente importante. E sem clientes, não há produto. Então, quem poderia gerenciar um produto? Bem, verdade seja dita, qualquer um pode gerenciar um produto e todos os envolvidos no ciclo de vida de desenvolvimento do produto certamente podem se juntar com ideias e feedback. Mas geralmente a pessoa responsável por isso é o gerente do produto ou proprietário do produto, dependendo do modelo organizacional. Mas, às vezes, pode ser um analista de negócios ou você pode ter todas essas funções trabalhando juntas durante todo o ciclo de vida de desenvolvimento do produto. De qualquer forma, se vamos falar sobre a pessoa por trás do papel, então há mais do que parece. Catherine, ex-proprietária do produto , é Shutterstock, reduziu a seis categorias. Você tem proprietários de produtos obcecados com taxas de conversão e análises são aqueles que gostam de mergulhar profundamente em jornadas de usuários e fluxos de negócios. Como os outros são viciados em redes sociais e redes. Enquanto alguns de nós são incríveis, bons serviços de construção, se dados e algoritmos são a sua coisa, então você tem seu lugar especial. E você é igualmente especial. Se você está focado no celular. Resumindo, não existe tal coisa como um proprietário de produto universal. Se você é um empregador, então depende do que exatamente é que você está procurando. Considerando que se você é o proprietário do produto real, então você só precisa prestar atenção aos seus pontos fortes, suas paixões e fraquezas, para que você vá para o trabalho que melhor lhe convier. Como devemos gerenciar um produto? O papel do proprietário do produto não soa doce no papel e assustador para. Você é o rei da estrada a caminho da produção, o líder final e o especialista da indústria. Mas, na verdade, ser proprietário de um produto não é sobre ser a voz mais importante. Não se trata de gerar sozinho um IDF do outro. Não se trata de ser designer ou programador ou tudo isso de uma vez. Ser um proprietário de produto é tudo sobre ser a voz do cliente. Trata-se de facilitar o trabalho em equipe, alcançar a comunicação, liderar e orientar as pessoas ao longo da jornada do produto. Trata-se de ser positivo e deficiente. É sobre tomar decisões no local com apenas um punhado de informações. Tudo isso e muito mais. Aqui está um exercício para você. Demore 15 minutos para chegar a uma ideia de produto e destacar suas principais características. Não complique isso demais. Não se trata da ideia em si. Não é suposto ser único ou um segundo classificado no Prémio Nobel. Trata-se de configurar um ponto de partida para todos os exercícios subsequentes ao longo do curso. Então podemos ser um smartwatch, ou um aplicativo, ou um brinquedo, ou um carro, ou um livro. Então, basicamente qualquer coisa, apenas certifique-se de especificar suas características gerais. Como, por exemplo, eu quero criar um relógio inteligente para pessoas com deficiência visual para que possam acessar facilmente feeds de notícias, conteúdo de mídia social, cor, inflamação, se e transporte público na íntegra. No final do curso, você terá passado por todas as etapas do desenvolvimento do produto. E este é o seu ponto de partida. Boa sorte, e nos vemos em nossa próxima sessão, quando falaremos sobre design thinking como uma maneira incrivelmente criativa de projetar um produto. Começando pela empatia. 3. Pensando no design: Olá e bem-vindo de volta. Nesta sessão, falaremos sobre como projetar as coisas do seu caminho. Poderíamos usar um guia, um manifesto de cinco passos para o sucesso. E talvez já tenhamos esse conhecimento enterrado bem dentro de uma pilha de inflamação. E tudo o que precisamos fazer é reorganizar as peças do quebra-cabeça para que tudo faça sentido. Então aqui está o que está em tendência. Pensamento de design. Design thinking é um processo. Como uma técnica e, em última análise um processo cognitivo destinado a criar e eficientemente dar vida a um produto. E o conceito de design thinking remonta à década de 1960, e nasceu como uma mistura de técnicas de criatividade e métodos de design como Divergência, Convergência, prototipagem e sustentabilidade. É uma abordagem centrada no homem, que significa que, em oposição a uma abordagem centrada no cliente, onde falamos sobre facilidade de uso, melhoria de fluxos, interfaces amigáveis ao usuário. Com o pensamento de design, falamos sobre desejos, necessidades, sentimentos e valor agregado. Tudo começa com empatia. empatia é a nossa capacidade de nos reposicionarmos para que possamos entrar nas profundezas do que outra pessoa está experimentando. Portanto, precisamos prestar atenção ao que a outra pessoa diz, faz, pensa e sente. Embora possa ser bastante fácil com ações e palavras, precisamos de um olho atento para detalhes e observação cuidadosa quando se trata de pensamentos e sentimentos. Então, se o produto que pretendemos criar é um smartwatch para pessoas com deficiência visual, por exemplo. Então podemos pensar em nossos potenciais clientes, caminhar uma milha em seus sapatos e tentar mergulhar profundamente em seus medos, frustrações e obstáculos, mas também em seus desejos e necessidades. Teríamos então de definir. Foi aqui que começamos a trabalhar com todas as informações que reunimos na fase anterior. Podemos, portanto, identificar e definir os problemas através da análise de factos e dados recolhidos até agora. Compreender as causas e os efeitos, definindo adequadamente os problemas e, em seguida, explicando os problemas. Por que precisamos explicar os problemas? Porque essa é a prova final de que os problemas foram completamente compreendidos. Podemos então proceder à identificação e definição da solução. E podemos fazer isso compilando uma lista de possíveis soluções, testando as soluções e validando-as, então podemos definir de forma abrangente a solução adequada e atribuir sua implementação. O terceiro passo no design thinking é sobre a geração de ideias. Jogou a mesa. Amy e eu quero dizer, absolutamente qualquer idéia que passa pela sua cabeça nesta fase, é tudo sobre gerar idéias. Isso não importa. Não importa em tudo, se é bom ou ruim ou se é a pior idéia de sempre, vai cuidar disso mais tarde. Tudo o que importa agora é gerar tantas ideias quanto possível sem quaisquer restrições, análises ou comparação de qualquer tipo. Então pense fora da caixa abaixo em idéias dos outros. Mantenha-se focado no assunto. E b Visual, ir para idéias selvagens e ir para a quantidade. Protótipo é o que precisamos fazer a seguir. Este é sobre a produção da versão lite do produto, um que não é muito caro. E estamos numa fase experimental. O objetivo aqui é identificar a solução mais adequada. E como chegamos lá? Pode testar e testar novamente investigando, melhorando e testando uma e outra vez até que tenhamos uma idéia melhor da solução para o problema e o produto. O teste é o estágio final. Há testes rigorosos acontecendo aqui. E o objetivo é testar completamente o produto completo, considerando a solução ideal como foi identificada durante o estágio anterior. Então testamos o produto, avaliamos a solução, geramos novas ideias e refinamos ou redefinimos o problema. Isso leva a um processo iterativo porque é isso que o pensamento de design é. Você não abaixa o lápis assim que os testes passarem. Testando, o produto vai nos ensinar mais sobre os clientes e vai gerar novas idéias. teste também pode redefinir o problema em si. Então você vê, este não é o fim da linha. Esta não é apenas uma simples receita de cinco passos para o produto perfeito. Isto é mais do que isso. Aqui está o seu exercício para o dia. Você surgiu anteriormente com uma idéia de produto. E você também destacou suas principais características. Agora é hora de simpatizar. Pense em seus clientes e ande uma milha no lugar deles, identifique seus pontos problemáticos, suas necessidades. Então você precisa definir o que eles estão tropeçando, destacar os problemas e definir a solução adequada para cada problema específico. E agora venha com idéias. Não existe essa coisa de má ideia. Então vá em frente e, em seguida, comece a classificar suas idéias e identificar as que melhor se adequam ao seu propósito. Em seguida, categorize-os corretamente, agrupando-os sob os recursos correspondentes que você identificou anteriormente. Mas deixem-me dar-vos um exemplo. Se eu fosse criar um smartwatch para pessoas com deficiência visual, como eu disse, meus recursos de alto nível seriam os seguintes. Notícias, mídias sociais, cor, inflamação, clima e transporte público. Por que eu precisaria chamar inflamação, por exemplo, para estar disponível no meu smartwatch braille. Porque como cliente, seria um pouco mais difícil para mim parar, possivelmente no meio de uma calçada lotada e acessar recurso particular do meu telefone que me diria exatamente isso. Então, esse recurso me permitiria acessar essa informação muito mais facilmente. Agora, como exatamente isso deveria estar funcionando? Bem, as seguintes ideias podem ser adequadas para este recurso. Mostraria o nome ou o número de telefone da pessoa que está me ligando. Ele mostraria opções para pegar ou rejeitar esse carvão. Ele iria exibir uma opção para chamar de volta e assim por diante. Algumas dessas idéias podem ser boas, algumas delas podem ser ótimas, outras podem ser completamente inúteis. Eu os resolveria mais tarde de qualquer maneira. Então, para os produtos I, eu escolheria apenas uma ou duas dessas idéias, depois testá-las e analisar os resultados, em seguida, prosseguir com o processo. Porque, como eu disse, design thinking é um processo iterativo. E isso é apenas a beleza disso porque traz eficiência através de passos claramente definidos que nos permitem concentrar em uma coisa de cada vez. Assim, permitindo-nos trazer as melhores ideias e as melhores soluções, o melhor produto para as necessidades dos nossos clientes. Boa sorte e vejo você em nossa próxima sessão quando você vai descobrir que o senso comum deve ser sua arma de escolha ao ter que escolher entre uma ampla gama de frameworks e metodologias. 4. Agile e SCRUM: Olá e bem-vindo de volta. Nesta sessão, falaremos do senso comum como arma de escolha. Bland, construir, testar, rever, implantar. Esta é uma cachoeira, e normalmente passa por um longo processo de planejamento seguido pela criação do produto e, em seguida, testando o produto, revisando e, eventualmente, implantando o produto. Neste ponto, você pode acabar trazendo o produto errado para o mercado se demanda do mercado ou tecnologia tiver mudado desde que o plano original foi desenvolvido. Alguns dos problemas desta abordagem são que o planejamento deve ser feito antes de qualquer trabalho começar. Então, na maioria das vezes o planejamento é feito sem entender completamente o projeto durante as etapas de desenvolvimento, muitas vezes as coisas são enviadas de volta para a fase de desenvolvimento, caso em que o projeto precisa começar de novo ou desenvolvedores criticados por não entender o plano e assim por diante. Então, muitos passos para trás e fazendo mais. Isso significa muito tempo antes que você possa tirar o produto da porta. Com Scrum. Por outro lado, o processo é dividido em pedaços menores. Primeiro, fazemos apenas cegueira suficiente para começar a construir o conjunto mínimo de recursos. Então construímos o que foi planejado. Nós testamos, revisamos e preparamos para ser lançado. Quando esse ciclo estiver concluído, acabamos com um produto potencialmente enviado. Este processo é repetido uma e outra vez dentro de um período de uma a três semanas. E o processo é repetido uma e outra vez. Você, portanto, acaba com ciclos de lançamento incrementais chamados sprints. Às vezes, você pode acabar enviando seu produto após o segundo sprint ou o terceiro, ou o quarto, ou mais tarde. Mas você acaba por enviar o produto dos valores e os princípios do desenvolvimento de software Agile são compostos em um chamado manifesto. Aqui vai, indivíduos e interações sobre processos e ferramentas. Isto significa que a ligação dessa comunicação através de todos os meios necessários é mais importante do que seguir um procedimento específico. tempos passo a passo mudam. As pessoas mudam a forma como interagimos. Portanto, mantenha-se atualizado e adapte o software de trabalho sobre documentação abrangente. O que isso significa é que ele funciona na minha máquina nunca foi bom o suficiente. Podemos ter o guia de integração mais requintado, mas é tudo em vão. Se a chamada de API receber um retorno ao remetente, colaboração com o cliente sobre negociação de contrato, todos precisarão da rede de segurança. Todos temos um no lugar, mas ainda assim não saímos de lá. Trabalhamos juntos, nos comunicamos, colocamos a mensagem em toda a mesa com precisão e em tempo hábil. Mesmo que, por vezes, o vento sopra a rede de segurança um pouco para o lado, respondendo à mudança ao longo de um plano. Eu, por exemplo, considero isso o coração da mentalidade ágil. Você constrói um plano e então algo acontece e o projeto está em perigo. O que você faz? O que mais importa para você neste momento? Eu diria que é do melhor interesse de todos abster-se, adaptar-se, ajustar o plano para que ele acomode a mudança. Mantenha o objetivo final à vista e seja ágil. No Agile Scrum, há três funções principais que são necessárias para que a estrutura funcione bem. O proprietário do produto é a pessoa responsável pela definição dos recursos necessários para o produto. O mestre scrum é um líder servo para a equipe, responsável por proteger a equipe e o processo, executar as reuniões e manter as coisas indo. A equipe pode ser composta por desenvolvedores, testadores, pilotos, qualquer outra pessoa que ajuda a construir o produto. Todas essas pessoas trabalham e trabalham juntas para tirar o produto da porta. Há também três artefatos ou documentos, digamos, que são usados no Agile Scrum, o backlog do produto. É aqui que os proprietários de produtos criam uma lista priorizada de recursos conhecidos como histórias de usuários que podem entrar no produto. Isso menos evolui e muda a prioridade a cada sprint. Então temos as histórias de usuários, que são uma maneira de descrever o conjunto de recursos. Eles geralmente são escritos de tal forma que eles fazem sentido para qualquer um que lê-los. Como cliente. Preciso de algo. Então, e aqui temos o propósito. A razão pela qual esta forma de frasear a história do usuário permite que o proprietário do produto especifique a quantidade certa de detalhes para que a equipe possa estimar o tamanho da tarefa. As histórias de usuários de maior prioridade vão para o backlog sprint. Estes são estimados para o tamanho e estão comprometidos com para o próximo sprint. Por último, mas não menos importante, temos os gráficos de burndown que mostram o progresso durante o sprint e a conclusão das tarefas no backlog sprint. Estes gráficos devem aproximar-se de 0 pontos à medida que o trabalho está sendo concluído. Também temos algumas cerimônias que compõem Scrum. Temos esta sessão de refinamento de impressão, que é onde o proprietário do produto, mestre scrum e a equipe se reúnem para discutir as histórias dos usuários e estimar seus tamanhos relativos. Isso geralmente acontece uma ou duas vezes por sprint. Dependendo das necessidades. Planejamento Sprint é o que acontece uma vez por sprint no início. E é quando o proprietário do produto, scrum master, e a equipe, todos eles precisam rever as histórias do usuário, como eles foram previamente estimados e organizados no sprint backlog pelo proprietário do produto de acordo com sua prioridade. O scrum diário é uma breve reunião de stand up onde a equipe discute o que eles concluíram desde a reunião anterior, o que eles estão trabalhando, e qualquer coisa que possa ser bloqueada ou exigir resistência. E então temos essa pré-visualização de impressão e retrospectiva, que ocorrem no final do sprint. É aqui que a equipe demonstra o trabalho concluído para o proprietário do produto e para várias partes interessadas. E, em seguida, a equipe discute o que eles podem fazer para melhorar o processo no futuro. Pode ser feito como um só, mas geralmente as pessoas preferem tê-los como duas reuniões completamente separadas. E eu não poderia concordar mais porque permite que você se concentre em uma coisa de cada vez. Além de outras partes interessadas podem participar da sessão de demonstração. Considerando que a retrospectiva é só para a equipe. Mas Agile é mais do que apenas uma estrutura. É um estado de espírito. Não se trata apenas de remover impedimentos, mas também de ensinar e orientar. Não se trata apenas de facilitação, mas também de coaching. Então você vê que há muito mais em ser ágil do que simplesmente seguir um conjunto específico de regras. Não importa o papel que você tem no universo de gerenciamento de produtos, será bom para você abraçar a agilidade em todas as suas formas. Seu único perigo de se tornar um profissional melhor. Lá, um colega, uma pessoa melhor. E desde que estamos falando sobre essa abordagem de migalhas como parte desse universo Ágil. Espero que este seja um momento tão bom como qualquer outro para mencionar que não existe um quadro perfeito. Não há métricas padronizadas adequadas para cada negócio, para cada necessidade, para cada equipe. Portanto, personalize, evolua e cresça e atinja a maturidade da sua organização. Mas faça isso do seu jeito. Encontre seu próprio caminho. Siga seu próprio curso natural. Boa sorte e nos vemos em nossa próxima sessão, quando falaremos sobre gerenciamento de requisitos. 5. Capítulo 4: gerenciamento de requisitos: Olá e bem-vindo de volta. Nesta sessão, falaremos sobre gerenciamento de requisitos. Então, o que é o gerenciamento de requisitos? Bem, em primeiro lugar, trata-se de reunir informações. Como? Bem, você pode fazer isso de várias maneiras diferentes, dependendo do contexto. Você pode analisar documentos. Você pode organizar um grupo de foco, ou pode entrevistar pessoas, workshops de brainstorming ou engenharia reversa. Ou você pode configurar uma pesquisa. Estas são apenas um par de técnicas comumente usadas para reunir requisitos. Então, o que mais lhe convier e você pode combiná-los de acordo com suas necessidades. Não há receita especial, mas tenha em mente que o objetivo principal aqui é entender claramente os requisitos. Lembre-se que com o pensamento de design, tivemos que explicar os problemas a alguém uma vez que os identificamos como uma prova final do fato de que os problemas não foram completamente compreendidos. Bem, isso é bastante semelhante porque aprendemos em nossas sessões anteriores que durante a reunião de refinamento, o proprietário do produto explica os requisitos de cada história de usuário para que os membros da equipe possam entender o negócio necessidade, estimar o esforço necessário para atender a essa necessidade, e levantar questões. Se algo não estiver claro, que o proprietário do produto pode responder no local ou tomar isso como um ponto de ação e voltar com esclarecimentos para a equipe para que eles possam estimar a vontade, o desejo de rapidamente e completamente entender um negócio específico ou uma situação de negócio específico é conhecido como perspicácia de negócios. O que isso significa é que também é necessário compreender o contexto que arrisca as oportunidades, basicamente, tudo o que está relacionado ao assunto, tornando-se assim um especialista em matéria de assunto. Tal proprietário de produto é um ativo valioso para qualquer organização Agile. E já que mencionei os riscos, eles precisam ser identificados desde o início. Quando um projeto é iniciado. Além disso, os riscos são identificados, depois avaliados e incorporados durante a fase de planeamento do projecto. Eles são controlados ao longo das etapas de execução e revisados ao fechar o projeto. Tenha em mente que ao avaliar o risco, precisamos identificar o proprietário do risco, a probabilidade. Ou seja, qual é a probabilidade de o que é marcado como um risco acontecer de fato? A gravidade do impacto e as soluções de mitigação. Quando ele está falando sobre requisitos, também precisamos enfatizar sobre como esses requisitos ainda a ser apresentados para a equipe, usa histórias, que é a convenção de nomenclatura. As histórias de usuários são basicamente a base intermediária entre as partes interessadas da empresa e a equipe, entre a necessidade comercial e sua realização técnica. Histórias de usuários são a linguagem que o proprietário do produto usa para conectar a comunicação e traduzir as informações de um lado para o outro. E o que faz uma boa história. Esse bom cenário ou dois. Porque se você seguir o caminho do desenvolvimento conduzido pelo comportamento, o que eu não hesitaria em recomendar. E, em seguida, como proprietário de um produto, você precisará dividir cada história de usuário em vários cenários. Por quê? Porque esses cenários serão estendidos e transformados em testes automatizados, o que ajudará a escrever o código real. O comportamento das funcionalidades, a ideia principal quando se trata de ser DDS, é centrado no cliente. Portanto, é muito mais fácil para desenvolvedores e testadores andar no lugar do cliente. Os cenários são escritos em uma linguagem facilmente legível. Diz que os cenários estão escritos como tal. Eles podem ser facilmente compreendidos por todas as partes interessadas. Esse método também reduz o risco de acabar com uma parte da funcionalidade que não passa no teste de aceitação do usuário UAT. Quanto à eficiência dos critérios de aceitação, aprendemos em uma sessão anterior que ele precisa ter um título claro e começar com uma estrutura específica para definir seu propósito. Como cliente, preciso de algo para que seja qual for o motivo. Mas também precisamos construir os cenários de que eu estava falando. Os cenários seguem uma estrutura específica também. Em primeiro lugar, cada cenário também tem seu próprio título para definir exatamente o que precisa ser feito para essa peça específica de implementação. Em seguida, ele também tem uma estrutura específica dada, que é o pré-requisito, quando, que é o gatilho, e então qual é o comportamento esperado. Hoje, tenho outro exercício para você. Até agora você já tem uma lista de recursos de alto nível para o seu produto, mas você também tem uma lista de ideias agrupadas em cada recurso correspondente. Estas serão suas histórias de usuários. Aqui está o que eu quero que você faça. Em primeiro lugar, priorize seus recursos de alto nível. E então grande idéia de cada vez e definir as histórias de usuários. E estes devem cada um ter um título e a seguinte estrutura como um i1. E para que E por último, mas não menos importante, comece a escrever os critérios de aceitação completos para suas histórias de usuários usando o modelo de desenvolvimento orientado por comportamento. Isto significa que cada história do usuário terá pelo menos um cenário após o dado quando então estrutura. Deixe-me dar-lhe um exemplo. Eu disse anteriormente que iria construir um smartwatch para pessoas com deficiência visual. E uma das minhas características de alto nível seria a inflamação da cor. Então eu tive algumas idéias sobre como exatamente isso deve estar funcionando. Uma das ideias que considero viável é o fato de que, uma vez que recebo um telefonema, o smartwatch exibirá o nome da cor. Então aqui está como seria minha história de usuário. O título seria, exibir o nome da cor. Quando um telefonema é recebido, então a estrutura seria, como cliente, eu quero saber o nome da pessoa que está me ligando que eu possa decidir se devo pegar esse carvão ou não. Agora, o primeiro cenário seria intitulado nome de cor de exibição e a estrutura do primeiro cenário seria, dado que o smartwatch é emparelhado com um telefone quando uma chamada telefônica é recebida. E então o smartwatch exibe o nome da cor. Este é o cenário do caso feliz. Também precisamos escrever um cenário para quando não houver armazenamento as informações sobre a cor. Este seria o nosso segundo cenário intitulado número de telefone de exibição se o nome não estiver disponível. E a estrutura seria dada que o smartwatch está emparelhado com um telefone. Quando uma chamada telefônica for recebida e a cor e a mira estiverem indisponíveis, exiba o número de telefone em vez disso. Então você pode ver que o dado é o pré-requisito. O quando é o gatilho, enquanto então é o resultado esperado. Vamos lidar com a opção de tomar ou rejeitar a chamada em uma história de usuário completamente separada. Porque as histórias de usuários devem ser pequenas e podem ser entregues em um sprint. E a equipe irá então pegar seus cenários, estendê-los, se necessário, e criar os testes automatizados e assim por diante. Mas a idéia é que as histórias de usuários que são estruturadas dessa forma, soam como histórias com palavras reais, frases em inglês simples. E isso os torna muito mais fáceis de entender para profissionais e técnicos. E boa sorte. E nos vemos em nossa próxima sessão quando falarmos sobre o processo de refinamento. 6. Capítulo 5: processo de refinamento: Olá e bem-vindo de volta. Nesta sessão vamos falar sobre o processo de refinamento. Mapeamento da história. Consiste em ordenar histórias de usuários ao longo de duas dimensões independentes. O mapa organiza atividades do usuário ao longo do eixo horizontal em ordem aproximada de prioridade ou a ordem na qual você descreveria atividades para explicar o comportamento do sistema. E no eixo vertical, representa uma sofisticação crescente da implementação. Dado um mapa de história tão organizado, a primeira linha horizontal representa uma versão nua, mas utilizável do produto. Trabalhar através de linhas sucessivas traz funcionalidade adicional para o produto. Então, anteriormente tivemos esse estágio quando criamos ideias que acabaram por ser transformadas em histórias de usuários. Este mapa é feito das mesmas idéias exatas. E devemos construir um mapa antes de nos aprofundarmos na definição dos critérios de aceitação reais das histórias dos usuários. Por quê? Porque à medida que avançamos e construímos o mapa, também podemos definir um novo usuário histórias ou redefinir alguns que já foram criados. Assim, a fim de evitar o trabalho descartável e permitir que nos concentremos no que é realmente importante em cada etapa. Primeiro de tudo, precisamos construir o mapa. Uma vez que o mapa é finalizado, adicionamos todos os itens ao Product Backlog, que é basicamente uma lista ordenada de tudo o que é conhecido por ser necessário para o produto. É a única fonte de verdade para os requisitos. E o proprietário do produto é geralmente o responsável pelo backlog do produto, incluindo sua disponibilidade de conteúdo e pedidos. Assim que tivermos todos os itens organizados e priorizados no backlog do produto, precisamos configurar sessões de refinamento. Estas são as reuniões em que o proprietário do produto apresenta os requisitos de negócios e a equipe responde a todas as perguntas, toma pontos de ação para voltar com respostas, se necessário, e obter estimativas da equipe. As histórias dos usuários são estimadas de acordo com sua complexidade e geralmente são estimadas em pontos de história. Quando temos uma nova equipe, geralmente escolhemos uma história de usuário que tenha sido trabalhada por essa equipe. E sua estimativa servirá como referência. Tem que ser um tamanho mediano um, geralmente estimado um três pontos de história para que se vai ter menos complexos, podemos ir tão baixo quanto dois ou um ponto de história. Considerando que se tivermos mais complexos, podemos ir tão alto quanto cinco ou oito pontos de história, 13 pontos de história ou maiores usos histórias devem ser evitados porque geralmente eles não são entregáveis em um único sprint de duas semanas. Então, à medida que o tempo passa, a equipe evolui, a linha de base pode mudar a história do usuário que costumava valer pontos de três andares, talvez avaliada em um ponto da história depois de alguns meses trabalhando juntos. Esta é exatamente a mesma razão pela qual as estimativas fornecidas por uma equipe não podem ser comparadas com as estimativas de qualquer outra equipe. Então você vê, Planning Poker é uma técnica para estimar, usado principalmente para estimar a complexidade ou o tamanho relativo dos objetivos de desenvolvimento. No planejamento do poker, os membros do grupo fazem estimativas por cartas numeradas de culpa viradas para baixo na mesa em vez de falá-los em voz alta. Os números fazem parte da sequência de Fibonacci. Geralmente usamos 1, 2, 3, 5, 8 e 13. Na pior das hipóteses. Qualquer coisa maior do que isso, definitivamente deve ser quebrado em pedaços menores de requisitos. Assim, os cartões são então revisados e as estimativas são discutidas. Ao esconder os números, cada indivíduo do grupo usará seu melhor julgamento para avaliar os requisitos sem ser influenciado por qualquer outro membro da equipe. Um aspecto muito importante é que as histórias dos usuários devem ser claramente compreendidas antes de sua estimativa. Portanto, se houver quaisquer perguntas pendentes, essa equipe não irá estimar. Isso é porque provavelmente a resposta que eles estão esperando meu impacto severamente na estimativa. E também, se tivermos grandes diferenças entre as estimativas, significa que alguns dos membros da equipe deram e estimativa de três, e outros dão uma estimativa de oito. Devemos realizar algumas discussões para entender por que a grande diferença. Talvez alguns dos membros sejam novos na equipe. Assim, seu grau de incerteza é maior. Ou talvez haja algo que foi mal entendido. E ao discutir todos esses aspectos que levaram a essa estimativa, temos a chance de alcançar um terreno comum. Então basicamente fornece estimativas semelhantes. Mas estimar e se comprometer com uma história de usuário específica não significa que estamos lá ainda no mundo Agile. E assim como em qualquer outro mundo, estabelecer as expectativas certas é de extrema importância. Para isso, no que diz respeito às histórias dos usuários, devemos definir a definição de pronto e a definição de feito. A definição de pronto é uma lista compilada pela equipe. Uma lista que contém os critérios que uma história de usuário deve atender a fim de ser levado para o sprint e comprometido quatro. Isso significa que, se qualquer uma das condições especificadas no Oriente Médio não for cumprida, todos estarão cientes de que a história do usuário não será tomada e trabalhada durante o próximo sprint. A definição de pronto pode ser diferente de uma equipe para outra de acordo com sua experiência, dependendo de quanto tempo eles estão trabalhando juntos e assim por diante. Permitam-me que vos dê um exemplo de tal conjunto de acordos. As especificações têm de ser claramente definidas. Não há histórias de usuário bloqueadas. Não há dependências entre histórias de usuários ou dependências de terceiros. A estimativa não excede 13 pontos de história. Desenhos e traduções estão prontos e disponíveis, se aplicável. Um conjunto semelhante de acordos é definido para estabelecer quando uma história de usuário pode ser considerada feita e pode ser fechada? Aqui está um exemplo. Todos os testes passaram. O código foi revisado, a documentação foi atualizada e os critérios de aceitação foram atendidos. E, claro, o teste de aceitação do usuário foi realizado, ou UAT, como é mais comumente conhecido. E, portanto, a história do usuário foi aceita pelo proprietário do produto. E como mencionamos o UAT, e esse é o estágio final quando o proprietário do produto verifica se o requisito, o recurso foi implementado conforme solicitado e conforme descrito nos critérios de aceitação. O UAT falha, então o proprietário do produto se recusa a aceitar a história do usuário e o recurso volta ao desenvolvimento para atualizar o código e os testes, se necessário, que os critérios de aceitação sejam atendidos. Então, como você pode ver, o proprietário do produto tem uma grande responsabilidade ao definir os critérios de aceitação. E deve ser feito adequadamente desde o início. Caso contrário, o tempo e o dinheiro serão perdidos, enquanto a frustração entrará facilmente e sequestrará a harmonia dentro da equipe. Então aqui está um exercício para o dia. Em nossa sessão anterior, você definiu um conjunto de histórias de usuários. Agora é hora de começar a estimar. Use seu melhor julgamento para estimar cada uma dessas histórias de usuários. E para fazer isso, pense em termos de complexidade. Por exemplo, ao idealizar sobre meu próprio produto, o smartwatch para pessoas com deficiência visual, eu disse que algumas das funcionalidades seriam exibir o nome ou o número de telefone da pessoa que está me ligando, exibir informações meteorológicas, informações de transporte público exibidas. Então o primeiro deve ser bastante direto. Eu diria que em algum lugar em torno de cinco pontos da história para exibir informações meteorológicas que talvez envolvam uma integração de provedores terceirizados. Não tenho certeza sobre isso. Então eu poderia estimar em 13 pontos de história porque o grau de incerteza é muito maior, ou eu colocaria em um pico de cinco pontos de história primeiro. Isso significaria uma investigação programada para identificar a abordagem técnica mais adequada. E o pico seria seguido pela história de implementação real, que definitivamente teria uma estimativa muito mais precisa. Quanto à informação sobre transportes públicos, isso seria definitivamente um auxílio ou 13 pontos de história. Pense em localização, dados e certificações em tempo real e assim por diante. Talvez este valesse a pena dividir em vários itens menores para que cada um deles possa ser entregue dentro de um único sprint. Então vá em frente, comece a estimar. E boa sorte. Vemo-nos na nossa próxima sessão, quando falarmos sobre a gestão de pendências. 7. Capítulo 6: gerenciamento de backlog: Olá e bem-vindo de volta. Nesta sessão, falaremos sobre gerenciamento de backlog. Falamos ou sessões anteriores sobre backlog e o que isso significa. Então, temos backlog do produto, sprint backlog, itens que são claros e têm uma alta prioridade. Eles são os primeiros a fazer isso do backlog do produto para o sprint backlog. Para que possam ser trabalhados. Um item é priorizado em relação a outros, dependendo do seu valor comercial. E seu valor comercial geralmente está relacionado a quanto dinheiro ele trará e quanto tempo após o lançamento. Mas também é valioso para os negócios não perder sua licença por uma instância. Assim, você vê que o valor comercial é determinado por meio um raciocínio instruído e considera aspectos como custo versus benefício, tempo de entrada no mercado, vinculações legais ou regulamentos de conformidade e assim por diante. Mas uma decisão deve ser tomada. E uma vez tomada a decisão de priorizar, então temos uma estrutura. Itens de alta prioridade terão requisitos detalhados e estarão mais perto do funil de backlog sprint. Os itens de baixa prioridade terão requisitos difusos e de alto nível e estarão no backlog do produto. Ainda no cerne da nossa decisão de priorizar, há sempre o cliente e as suas necessidades. Esse é o aspecto mais importante. E só se passarmos por esse estágio podemos pensar em quanto dinheiro isso trará? Onde se a competição está nos forçando a seguir em frente. A decisão de priorizar também pode ser influenciada pelo nosso relacionamento com nossos parceiros, ou por último, mas não menos importante, pelos riscos que ela detém, mas os riscos também devem ser incorporados no planejamento. Portanto, mitigação de risco em Scrum envolve flexibilidade de adicionar ou modificar requisitos são feedback regular e transparência, que garante a definição de um alto grau de consciência e também a criação das expectativas certas não dimensão uma abordagem de entrega iterativa que reduz o risco de investimento, gestão de risco em Scrum , por outro lado, envolve identificar o risco, analisar a gravidade do impacto, priorizar riscos com base na exposição, criação de planos de ação e acompanhamento acompanhados de acompanhamento para garantir a mitigação dos riscos. Há, no entanto, um tipo diferente de risco que vem com cada linha de código. Quando uma alteração é iniciada em uma base de código, muitas vezes há a necessidade de fazer outras alterações coordenadas ao mesmo tempo em outras partes da base de código, as alterações necessárias que não são concluídas são consideradas que deve ser pago em algum momento no futuro. Assim, para que a equipe seja capaz de manter um nível consistente de qualidade e liberação. Após o lançamento, precisamos ter certeza de que podemos enviar recursos limpos e arrumados. Aqui está o que você pode fazer para garantir um nível tão alto de qualidade. Você pode redefinir a definição de feito. Equipes ágeis definidas como você está pronto para lançar, que significa que os desenvolvedores não começarão a trabalhar em uma nova história até que este item atual esteja praticamente nas mãos dos clientes. Para acelerar as coisas ao longo das técnicas de uso, como fluxo de trabalho de ramificação de recursos, é teste automatizado e integração contínua em todo o ciclo de vida do desenvolvimento. Prevenir a dívida técnica é o que permite que o desenvolvimento seja ágil a longo prazo também. A ramificação mestre com conjuntos baseados em código deve estar sempre pronta para ser enviada. Essa é a prioridade número um, o proprietário do produto tem o poder de concentrar primeiro a equipe do trabalho mais valioso, em vez de reduzir o escopo do lançamento do que comprometer a qualidade. Dívida técnica é a diferença entre o que foi prometido no que foi realmente entregue. Você pode priorizar a dívida técnica e o planejamento sprint como um trabalho de recurso normal. E vamos nos educar sobre os verdadeiros custos da dívida técnica. Desde que aprendemos uma coisa ou duas sobre gerenciamento de backlog e desde já temos tudo o que precisamos de nossas sessões anteriores, Vamos fazer o exercício de hoje sobre organização ou backlog. Nós já temos nossos recursos e as histórias de usuários por baixo, certo? E nós também estimamos cada um deles. Então agora vamos apenas organizar todos esses itens no quadro de acordo com seu valor comercial. Uma vez que você tem isso no lugar, você também deve definir o seu MVP, seja, o seu produto mínimo viável, que é de fato um conjunto central de funcionalidades que você pode colocar com confiança na frente do cliente. Tudo o que é deixado de lado, dissociado do MVB que pode ser agrupado em uma fase subsequente. Que desta forma você traz algo para o cliente em um curto espaço de tempo. Você pode então construir sobre o que você já tem em produção. Os clientes estão entusiasmados com cada novo recurso que você adiciona ao produto. Sem mencionar que você também melhora suas taxas de retenção de clientes. Então vá planejar, priorizar e definir seu MVP e boa sorte, e vê-lo em nossa próxima sessão quando estaremos falando sobre gerenciamento de partes interessadas. 8. Capítulo 7: gerenciamento de partes interessadas: Olá e bem-vindo de volta. Nesta sessão, falaremos sobre a gestão das partes interessadas. O que é uma parte interessada e quem pode ser ganho? Uma parte interessada é um indivíduo, um grupo ou uma organização que é impactado pelo resultado de um projeto. Uma parte interessada também pode ser qualquer pessoa que possa impactar o próprio projeto. As partes interessadas têm interesse no sucesso do projeto e podem ser de dentro ou de fora da organização que está patrocinando o projeto. As partes interessadas podem ter uma influência positiva ou negativa no projeto. Podemos dividi-los em quatro categorias diferentes. No núcleo, temos os patrocinadores ou os proprietários da exigência. Eles são os únicos que, em última análise, carregam a responsabilidade pelo sucesso do projeto. No círculo mais amplo, temos então a equipe de desenvolvimento, aqueles que vêm com a solução técnica e que se certifica de que a implementação é realizada corretamente. Se avançarmos mais um passo no terceiro círculo, encontraremos o grupo de referência, pessoas que asseguram que tudo funciona corretamente, que nada mais foi afetado pela mudança. Ou se tiver, eles certificam-se de que tudo está alinhado. E no último círculo do seu mapa de partes interessadas, você encontrará seus clientes, os usuários finais do seu produto. Há os beneficiários de todo o esforço que foi colocado no processo de desenvolvimento do produto. Também podemos mapear nossas partes interessadas usando uma tabela de dois eixos. O nosso eixo vertical é aquele que ilustra o poder das partes interessadas. Enquanto o eixo horizontal representará o seu nível de interesse. Então, o que temos que fazer primeiro é identificar quem são as nossas partes interessadas. Precisamos então descobrir seu poder, sua influência e interesse para que saibamos em quem devemos nos concentrar. Mais adiante, precisamos de desenvolver uma boa compreensão das partes interessadas mais importantes, para que saibamos como é provável que elas respondam e como podemos ganhar o seu apoio. Como orientações gerais, só precisamos monitorar como deixar as partes interessadas que têm um baixo nível de poder, mas também um baixo nível de interesses. À medida que os interesses das partes interessadas aumentam, temos de os manter informados e respeitar os seus interesses. Quando lidamos com partes interessadas que têm um baixo nível de interesse, mas eles têm uma posição poderosa dentro da empresa. Precisará manter estes satisfeitos e atender às suas necessidades. O ponto central do nosso mapa de partes interessadas, vamos destacar aqueles que estão altamente interessados no projeto e também têm uma grande quantidade de poder. Essas são as partes interessadas que precisamos gerenciar de perto e manter engajados em todos os momentos quando falamos de poder, seja sobre um projeto ou um assunto pessoal, podemos definitivamente identificar vários tipos diferentes de poder. Podemos ter um poder legítimo baseado na posição de alguém dentro da empresa. Ou podemos ter Bauer baseado em experiência, habilidades especializadas , ou conhecimento. Há então o poder baseado na recompensa. Quando alguém tem a capacidade de distribuir algo que os outros valorizam. Há também um tipo de poder burocrático ou carismático. Então, você vê, nós precisamos prestar atenção para ouvir e descobrir ativamente nossos stakeholders para identificá-los adequadamente e abordá-los de uma maneira que melhor se adapte às suas necessidades e expectativas. Tudo isso é necessário se quisermos ter certeza que chegaremos ao resultado desejado do projeto. E ao fazer isso, também estamos construindo um relacionamento com nossas partes interessadas e estamos facilitando as interações futuras, portanto, eliminando muitas barreiras de comunicação e suavizando ou caminhando para o sucesso. Que tal isso para o exercício de hoje? Pense no seu produto, pense nas partes interessadas, identifique-as e, em seguida, execute uma análise de poder versus interesse. E, em seguida, crie seu próprio mapa de partes interessadas e posicione-os apropriadamente no mapa. É um bom exercício e excluímos o tempo todo com cada novo projeto. Isso ajuda trazendo clareza com um impacto direto na comunicação. Porque saberemos quem abordar quando e especialmente como fazê-lo para que possamos chegar a acordo sobre os resultados e garantir o sucesso do nosso projeto. E boa sorte com seu mapeamento de partes interessadas e vê-lo em nossa próxima sessão, quando falaremos sobre o conjunto de habilidades, o que é preciso para ser uma pessoa de produto excepcional, e como isso terá uma influência positiva em seu A vida também. 9. O que é necessário para se tornar um analista de negócios (melhor): Olá e bem-vindo de volta. Nesta sessão, teremos um gostinho deste conjunto de habilidades. O que é preciso para ser uma excelente pessoa do produto? Bem, você sabe, assim como no futebol ou engenharia ou nas artes, ou você é talhado para isso ou você está se esforçando, aprendendo, construindo sobre o que você aprendeu e então aprendendo um pouco mais. Mas, idealmente, é preciso talento ou paixão e muito trabalho duro e dedicação para chegar lá. Então inove e comece com você mesmo. A inovação é uma mistura de desejabilidade, viabilidade e viabilidade. Assim, como parte do processo de inovação, as seguintes perguntas devem encontrar suas respostas desde o início. É real? Existe um mercado para este produto? Existe uma verdadeira necessidade no mercado? Posso ganhar? Analisar o ambiente competitivo? Sua proposta é competitiva? Vale a pena? Temos estimativas realistas de vendas e receitas? Os custos do produto são aceitáveis? Nosso dos custos de desenvolvimento acessível? Bem, se você tem todas as suas respostas, então você tem seu coração no lugar certo. Agora vamos ver o que você precisa fazer para colocar sua mente no lugar certo. E para isso, vamos falar sobre mentalidade. A mentalidade é um conjunto de pressupostos, métodos ou notações mantidos por uma ou mais pessoas ou grupos de pessoas. Ou, em outras palavras, é a forma como sua mente é treinada para trabalhar. Estas são a maneira que você é usado para avaliar um ato ou reagir em várias circunstâncias, cada momento, dia após dia. É a maneira como você vê a própria vida. Desejo. Existem basicamente dois tipos principais de mentalidade. Há mentalidade fixa e mentalidade de crescimento. E as diferenças entre os dois ganham vida quando se tem que lidar com desafios, obstáculos, com esforço ou crítica, ou mesmo com o sucesso dos outros. Assim, você pode optar por evitar desafios ou abraçá-los, assim como você pode optar por desistir quando tropeçar um obstáculo ou persistir e encontrar uma maneira de superá-lo. É o mesmo com esforço. Você pode optar por olhar para ele como sendo infrutífero. Ou você pode optar por considerá-lo como o seu caminho para o domínio. Aprenda com as críticas, ou simplesmente ignore-as. Sinta-se ameaçado pelo sucesso dos outros, ou escolha aprender uma lição valiosa com ele. Com cada encontro, é a sua escolha, é a sua visão, seu presente e o futuro que molda. Então escolha sabiamente, reformule, mude a perspectiva e descubra a si mesmo e trabalhe consigo mesmo em direção a uma mentalidade saudável e ao futuro gratificante. A autoconsciência emocional e a autogestão também têm uma enorme contribuição para o sucesso na forma mudando nossa mentalidade. E isso porque a inteligência emocional é basicamente nossa capacidade de reconhecer nossas próprias emoções e as dos outros, discernir entre sentimentos diferentes e rotulá-los apropriadamente, usar formação emocional para guiar pensamento e comportamento, e gerenciar ou ajustar emoções para se adaptar a ambientes ou para alcançar nossos objetivos. A adaptabilidade, por exemplo, é prova de uma autogestão emocional eficaz, enquanto a empatia é um indicador da nossa consciência social. Se chegarmos ao treinamento ou mentoria isso é mais um componente de inteligência emocional. É a capacidade de gerenciamento de relacionamento que nos permite interagir com um alto nível de profissionalismo e conscientização. E a inteligência emocional está no coração de um processo ideal de mapeamento mental. Um processo em que precisamos evitar bloqueios para capturar ideias e descobrir insights, ou para revelar padrões. Mas só podemos fazer isso eficazmente com uma certa distância mental e parando para nos examinar. Tão criticamente. Mapeamento mental é sobre criatividade. Planejamento, produtividade e processo eficaz de mapeamento mental podem melhorar a colaboração e, portanto, aumentar os benefícios. mapeamento mental incentiva a flexibilidade e gera resultados claros. Os mapas mentais são visualmente orientados e permitem um fluxo livre de ideias. E por último, mas não menos importante, mapear a mente é divertido. Nem sequer se sente como trabalhar, mesmo que as realizações estejam muito além das expectativas. Portanto, não importa se você está trabalhando no desenvolvimento de um produto de software ou se você é um escritor, não importa se você é um pai, um professor ou um aluno. Quem quer que seja, e o que precisar, limpe a confusão e comece a mapear a mente. Eu posso garantir que você vai se divertir muito e você vai se surpreender com o resultado. Eu não mencionei anteriormente o conceito de re-enquadramento. Bem, enquadrar é o processo de pensamento que as pessoas usam para definir uma situação e decidir como vão lidar com isso. Enquanto reformular está fazendo isso de novo de uma maneira diferente. Por exemplo, decidir que um conflito pode ser abordado de forma positiva e não negativa. Então, reformular é basicamente ver uma situação específica de uma perspectiva diferente. E isso pode ser tremendamente útil na resolução de problemas, tomada de decisões e aprendizagem. Fazemos isso o tempo todo, por exemplo, em reuniões retrospectivas. Em vez de nos perguntarmos o que deu errado nas últimas semanas, perguntamos: o que podemos fazer melhor? O que podemos melhorar dessa forma? Vamos evitar nos concentrar no impacto negativo e, em vez disso, criar ideias para melhorar. Portanto, não só a atitude fica muito mais positiva, mas o resultado também é muito mais útil. Você também pode abster-se criando uma persona. Personas são personagens fictícios, e você geralmente os cria com base em sua pesquisa, a fim de representar os diferentes tipos de clientes que podem usar seu serviço ou seu produto. A criação de personas ajudará você a entender as necessidades, as experiências, os comportamentos e as metas de seus clientes . Então o que acontece é que criar personas pode ajudá-lo a sair de si mesmo. Ele pode ajudá-lo a reconhecer que pessoas diferentes têm necessidades e expectativas diferentes. E também pode ajudá-lo a se identificar com o cliente para o qual você está projetando, ou com a pessoa à sua frente ao lidar com uma conversa difícil. Então não se esqueça, aponte para uma mentalidade saudável. Eduque sua inteligência emocional, redefina seu caminho através do processo de inovação e use a persona para caminhar uma milha na pele do cliente. boa notícia é que você já fez a maioria dessas coisas agora. Tudo que você precisa fazer agora é se exercitar. Faça isso o tempo todo e você vai apenas encontrar-se um dia fazendo tudo naturalmente sem um esforço e definitivamente apreciando a cada passo do caminho. E se estiver com disposição para um último exercício, gostaria de convidá-lo a construir um protótipo do seu produto. Imagine que você vai vender seu produto em uma loja de varejo. Então, o que você precisa fazer é pegar uma caixa de sapatos e projetar o produto que seus clientes vão comprar. Certo? Detalhes e recursos que ajudarão você a vender o produto. Corte imagens de jornais e coloque-as na caixa. Dê o seu melhor para garantir um produto altamente atraente pronto para ser vendido. E como sem clientes não há nenhum produto, tente vender seu produto de caixa de sapatos para alguém. O processo de venda garante que você esteja focado nos benefícios, enquanto o espaço limitado na caixa força a priorização dos recursos do seu produto. Espero que não tenha uma multidão difícil, mas de qualquer forma, será um excelente exercício. Boa sorte, e obrigado por se juntar a mim nesta maravilhosa jornada para o mundo do produto.