Uso do Analytics para obter informações do Application Insights

Neste post vamos abordar o Analytics, ferramenta de pesquisa e consulta avançada do Application Insights. Como já fizemos a configuração do Visual Studio ou VSTS com o App Insights, você só precisa extrair as informações desejáveis, tais como desempenho, disponibilidade, falha e uso da aplicação.

O passo inicial é acessar o Portal Azure > Visão Geral > Análise (Analytics), conforme a imagem abaixo.

analytics-app-insights

Crie uma nova query, clicando no símbolo de +. Veja que as tabelas estão disponíveis no canto esquerdo da tela:

  • Traces | customEvents | pageViews | requests | dependencies | exceptions | availabilityResults | customMetrics | performanceCounters | browserTimings

Uma boa consulta para iniciar as análises na ferramenta é descobrir quantas solicitações a aplicação recebeu em diferentes métodos nos últimos 2 dias.

analytics-query

No nosso exemplo, trabalhamos com a tabela requests e a condição de analisar os registros dos últimos 2 dias. A função de grupo pelo name é para agrupar pelo nome da requisição feita. A renderização pode ser em gráfico como o piechart.

Outro exemplo é sobre o uso da aplicação. A tabela pageViews é utilizada para demonstrar isso. Também podemos projetar graficamente a informação com render.

pageViews
| where timestamp > ago(20d)
| summarize dcount(user_Id) by bin(timestamp, 1d)
| render timechart

A ferramenta dispõe das guias (TABLE | CHART) para trabalhar com as informações em tabelas (com filtros avançados) ou gráficos.

This slideshow requires JavaScript.

Quer conhecer mais sobre as queries e sintaxes? Veja mais detalhes sobre Analytics no Docs da Microsoft.

Plataformas Digitais: Criando produtos e validando hipóteses no mercado com foco UX (experiência do usuário)

Arquivo PDF: 2018 1 Estrutura do TCC – ARTIGO CIENTÍFICO – Leonardo Matsumota

RESUMO
Este trabalho aborda a aplicação das técnicas Lean Inception, Lean UX e Agile (Scrum) para criar um modelo de experimentação enxuto e contínuo afim de validar hipóteses de produtos no mercado. As principais fases da Lean Inception são: escrever a visão do produto, o produto é/não é/faz/não faz, descrever as personas, features, revisão técnica e de negócio, exibir as jornadas de usuário, priorizar as features e construir o MVP Canvas. Com a determinação dos MVPs – features para o sistema de admissão de candidatos, o desenvolvimento do sistema dar-se-á com o uso do Scrum (framework ágil), trabalhando com ciclos adaptativos de forma iterativa e incremental. Este planejamento e inspeção frequentes visam reduzir as incertezas e riscos do projeto, devido a adequação de escopo e frequente validação das entregas. Por fim, utilizamos a Lean UX (user experience) como guia para o processo de experiência do usuário, ajustando o sistema de acordo com o aprendizado obtido com as técnicas Vision, Framing, and Outcomes; Collaborative Design, etc.

Palavras-chave:  MVP. Métodos Ágeis. UX. Lean Inception. Design Thinking.

ABSTRACT
This paper approach the use of Lean Inception, Lean UX and Agile (Scrum) to create a lean and continuous experimentation model to validate product hypotheses in the market. The main phases of Lean Inception are: writing the product vision, the product is / is / does / does not, describe the personas, features, technical and business review, display user journeys, prioritize the features and build the MVP Canvas. With the determination of the MVPs – features for the candidate in admission system, the development of the system will be through the use of Scrum (agile framework), working with adaptive cycles in an iterative and incremental way. This frequent planning and inspection is intended to reduce project uncertainties and risks, due to the suitability of scope and frequent validation of deliveries. Finally, we use the Lean UX (user experience) as a guide to the user experience process, adjusting the system according to the learning achieved with the techniques Vision, Framing, and Outcomes; Collaborative Design, etc.

Keywords:  MVP. Agile. UX. Lean Inception. Design Thinking.

 

INTRODUÇÃO

Com a evolução tecnológica acelerada e a transformação digital nos negócios, os usuários encontram cada vez mais opções de produtos disponíveis e ferramentas que auxiliam na hora da compra, como por exemplo, a avaliação de outros usuários.

Porém, com menos tempo e fidelidade às marcas, os usuários deparam com um alto volume de conteúdo na web, que precisam de relevância para conquistá-los e assim propiciar uma boa experiência ao longo da jornada de compra naquela plataforma. É necessário mostrar o seu valor para o consumidor!

E para isso, as empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores. A horizontalização auxilia neste aprendizado sobre o consumo, pois os usuários fornecem informações para a empresa, criando uma relação com os produtos e os serviços que adquire.

O Marketing 4.0 destaca a humanização da marca, o marketing de conteúdo, a experiência omnichannel e a estratégia dos 5 A’s – estratégia de exposição da empresa, desde a atenção até a advocacia da marca (KOTLER, Philip). Veja o modelo proposto na Figura 1.

5As
Figura 1 – 5A’s
Fonte: http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/

Outro ponto é adotar um modelo extremamente dinâmico para criar produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.

Entre as principais vantagens do MVP:

  • Reduzir riscos de mercado, pois os investimentos vão de acordo com a aceitação dos usuários
  • Validação de hipóteses
  • Experimentação e aprendizado
  • Geração de valor acelerada
  • Avaliar a escalabilidade do produto

O modelo Build-Measure-Learn Feedback Loop é uma efetiva abordagem para desenvolvimento de startup, melhorando continuamente a criação de produtos, serviços e ideias com ótimo custo-benefício (RIES, Eric).

A figura 2 demonstra o ciclo de criação e teste de hipóteses, começando pequeno para clientes potenciais, medindo suas reações e aprendendo com os resultados. O objetivo é evoluir o produto para entregar exatamente o valor esperado para o cliente.

lean-startupFigura 2 – Build-Measure-Learn Feedback Loop
Fonte: http://theleanstartup.com/principles

E como ter uma abordagem criativa para criação de produtos? O Design Thinking busca de forma colaborativa (pessoas colocadas no centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco é em necessidades do mercado, e não em pressuposições estatísticas.

A abordagem Double Diamond no DT auxilia a compreender os clientes e seus problemas, utilizando dois diferentes tipos de pensamento:

  • Divergente: pensamento amplo, considerando qualquer ideia.
  • Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.

design-thinking.pngFigura 3The Double Diamond
Fonte: https://medium.com/seek-blog/

Boa parte das soluções em plataformas digitais consideram o desenvolvimento de software para construir o produto ou estruturar o suporte do negócio. Operar em nível avançado com práticas DevOps habilita o processo de entrega contínua de valor aos usuários e mantém os ambientes de produção mais estáveis, provendo credibilidade a marca.

Já a governança destes projetos com métodos ágeis, enfatiza a criação de times disciplinados focados em maximizar o valor para o cliente. O modelo ágil difere do tradicional por trabalhar com processos empíricos, realizando uma pequena quantidade de trabalho para adquirir experiência (iteração). Utiliza-se ciclos adaptativos de forma iterativa e incremental.

O processo empírico planeja frequentemente e JIT (just in time). Há inspeção frequente dos resultados. O planejamento tradicional usa técnicas para determinar prazo e custo no início do projeto, porém em um sistema adaptativo complexo, conforme o cone da incerteza (figura 4), quanto mais cedo, maiores são as incertezas.

cone-incertezaFigura 4 – Cone da Incerteza
Fonte: https://agilemomentum.files.wordpress.com/

 

1   Validação de hipóteses

 Lean Inception

A Lean Inception é utilizada para os times que precisam desenvolver iterativamente um MVP, escolhendo as funcionalidades que tenham valor aos usuários, com base em premissas obtidas em testes. É uma técnica que corrobora o entendimento do que é preciso para criar um produto de sucesso (CAROLI, 2017).

Não substitui sessões de ideação, pesquisa de clientes, revisão de arquitetura ou análise de competitividade. Aplicável a grandes projetos, trabalha orientada a Lean, com iterações e testes, descobrindo funcionalidades que tenham valor aos usuários. Em pequenas organizações, como startups, utilize para validar ideias com MVPs e evoluir para um produto de software.

1.1.1 Write the product vision
Esta atividade auxilia a definir colaborativamente a visão do produto, que é a essência do valor de negócio do produto e a mensagem convincente aos usuários.

  1. Escreva o template de visão do produto em um quadro branco ou flipchart para que o time veja facilmente.
  2. Divida o time em grupos menores e peça que todos preencham os slots disponíveis.
  3. Junte o resultado de cada grupo e consolide as informações.

O roteiro de criação da visão do produto:
For [final client],
whose [problem that needs to be solved],
the [name of the product]
is a [product category]
that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference].

product-vision.pngFigura 5Product Vision

1.1.2 The product is – Is not – Does – Does not
Explicar o produto descrevendo o que ele não é facilita a exploração e entendimento do que será criado. Esta atividade ajuda a explicar o produto, formando um consenso sobre o produto faz e o que ele não faz.

  1. Divida o flipchart em quatro áreas: Is / Is not / Does / Does not.
  2. Escreva o nome do produto acima dos quadrantes
  3. Incentive os participantes a descreverem o produto com post-its­ nas áreas correspondentes.
  4. Leia e agrupe anotações similares.

product-is-is-notFigura 6The product is – is not – does – does not

1.1.3 Describe the Personas
A persona representa o usuário no sistema, descrevendo seu papel e necessidades. Nosso propósito é criar uma representação realística do usuário, ajudando a descrever as funcionalidades do ponto de vista de quem terá interação com o produto final.

  1. Divida o time em pares ou trios. Entregue um template de personas para cada grupo.
  2. Peça que cada grupo crie uma persona, utilizando o template como referência.
  3. Cada grupo apresenta suas personas para o time inteiro.
  4. Divida novamente o time em diferentes grupos e repita os passos acima.

É importante realizar esta atividade em grupo, repetindo quantas vezes necessário. Se há a criação de muitas personas, podemos combinar e priorizá-las. Os stakeholders que conhecem os objetivos do projeto devem participar ativamente de tudo isso, auxiliando o time a identificar as personas e revisando suas descrições.

persona-AFigura 7Describe the persona A

persona-BFigura 8 – Describe the persona B

1.1.4 Discover the Features
Descreve a interação do usuário com o produto (da forma mais simples possível) ou algumas ações que o produto deve realizar.

  1. Colocar os objetivos do produto como títulos de coluna em um feature canvas único. Priorizar os objetivos da esquerda para a direita, de cima para baixo.
  2. Colocar as personas como títulos de linhas, priorizando de cima para baixo.
  3. Todos devem sugerir funcionalidades e colocá-las nas discussões. Utilize as personas e os objetivos para guiarem a discussão. A principal questão é: “o que o produto precisa fazer para que esta persona alcance seu objetivo”.

discover-features.pngFigura 9Discover the features

* embora o canvas pareça uma matriz, não necessariamente teremos uma funcionalidade para cada combinação de objetivo e persona. Podemos ter várias funcionalidades para uma persona atingir um objetivo específico. Também ter personas que não precisam de uma funcionalidade para um determinado objetivo.

1.1.5. Technical and Business Review
É feita uma avaliação das features em termos de esforço, valor e incerteza. Utilizaremos o canvas que desenvolvemos durante a sessão Discover the Features. Para o esforço e valor do negócio, anotamos as features utilizando marcações na escala de um, dois ou três.

effort-business-valueFigura 10Effort and business value
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html

technical-review.png
Figura 11Technical and business review

Classificamos a feature considerando aspectos técnicos de desenvolvimento (technical certainty) e aceitação do negócio (business agreement). Combinamos as duas classificações de acordo com o nível de incerteza: vermelho (alto), amarelo (médio) e verde (baixo). Se a feature estiver na parte inferior esquerda da tabela, marque com um “X”, pois não é aplicável ao MVP.

technical-certaintyFigura 12Business Agreement x Technical Certainty
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html

business-agreeement-technical-certainty.pngFigura 13Business Agreement x Technical Certainty (Admission)

1.1.6 Show the User Journeys
Descreve a sequência de passos que o usuário percorre para atingir seu objetivo. Algum destes passos representam pontos de contato com o produto, demonstrando como o usuário interage com ele. O time levanta questões e alternativas sobre os desejos dos usuários e capacidades do produto.

  1. Selecione a persona
  2. Identifique um objetivo para esta persona.
  3. Escreva em post-it­ e coloque no topo à esquerda do
  4. Defina o ponto de partida e coloque em post-it­ no canvas. Questões de apoio: Como a persona começa seu dia? O que desperta a vontade de atingir seus objetivos?
  5. Descreva cada passo em sequência no post-it e coloque no canvas. Continue planejando os passos até a persona atingir seu objetivo.

user-journeyFigura 14User journey

1.1.7 Display Features in Journeys
Neste ponto temos uma lista de features que o produto deve ter, e as jornadas do usuário indicam como serão as interações com o produto. Integraremos então as duas perspectivas. Coloque as principais jornadas e features visíveis e lado a lado. Faça cada jornada, e para cada etapa, registre as features de que precisa.

features-in-journey.pngFigura 15Features in journey

Algumas jornadas estão faltando features: para isso, criamos cartões de feature, marcando o esforço, valor e incerteza. Algumas features não estão mapeadas na jornada: devemos desafiá-las, realmente precisamos se não participam das jornadas de nossos usuários?

1.1.8 Sequence the Features
Agora temos condições de trabalhar no primeiro MVP e nas iterações seguintes. Fazemos isso, definindo a Features Sequencer.

  1. Crie a Features Sequencer template (geralmente um flipchart com linhas numeradas)
  2. Explique as regras da Features Sequencer *
  3. Lembre todos do objetivo da atividade: definir a sequência de entrega das features do produto. O objetivo do MVP é aprender a cada iteração construindo um MVP que permitirá testar se o business case é efetivo.
  4. Todos devem colocar feature cards no sequencer, movendo eles enquanto exploramos as opções, até chegarmos a um acordo.
  5. O resultado mostra as features para cada iteração do MVP.

* as regras são: uma linha contém no máximo três features; uma linha não pode ter mais de uma feature com cartão vermelho (alta incerteza); cada linha deve ter ao menos um cartão verde (baixa incerteza); a contagem do esforço não pode adicionar mais que 5 Es; a contagem do valor deve somar pelo menos 4 $.

sequence-features.pngFigura 16Sequence the features

1.1.9 Build the MVP Canvas
Agora temos todo o conhecimento para construir o artefato final (MVP canvas) em cada iteração do MVP que definimos em Sequence the Features. O princípio é design centrado no usuário, considerando usuários e suas jornadas. Devemos trabalhar em ações que melhorem ou simplifiquem suas vidas e desenvolvendo hipóteses que podem testar o MVP.

  1. Visão do MVP: o que estamos tentando aprender?
  2. Declaração de resultado: o que acreditamos que este MVP irá alcançar? O que esperamos aprender?
  3. Métrica para validação de hipóteses de negócio: como você sabe quando pivotar e quando perseverar? O que determina sucesso ou falha? Quais dados devemos coletar?
  4. Personas e Plataformas: identificamos um grupo menor de personas que estaremos focando nesta iteração.
  5. Jornadas: revisão dos resultados de Show the User Journeys e Display Features in Journey.
  6. Features: relacionar as features para o MVP.
  7. Custos e prazos: em relação as features do MVP.

mvp-i.pngFigura 17 – MVP I

mvp-ii.pngFigura 18 – MVP II

 

2 UX (USER EXPERIENCE)

Utilizamos o Lean UX (user experience) como guia para o processo de experiência do usuário. Trata-se de uma evolução do design do produto, com intensa colaboração e cross-functional. O shared understanding é o engajamento contínuo do time para falar sobre o que funciona (não apenas documentos e features), obtendo feedbacks do mercado. Devemos mensurar o que funciona, aprender e ajustar.

Em geral, Lean UX aborda três frentes:

  • Facilita o entendimento como uma mudança de processo para designers
  • É um mindset que nos permite abordar o trabalho de novas formas
  • Também é um pensamento sobre gerenciamento de software

Entre os princípios do Lean UX estão:

  • Cross-Functional Teams: várias disciplinas envolvidas na criação do produto.
  • Small, dedicated, colocated: manter os times pequenos (até 10 pessoas) dedicados a um projeto para melhorar a comunicação, foco e ambiente de trabalho.
  • Progress = Outcomes, not Output: features e serviços são outputs; atingir os objetivos de negócio são outcomes.
  • ProblemFocused Teams: atribuição de um time, que ao invés de trabalhar em features, ficará dedicado a resolução do problema. Desperta o senso de ownership.
  • Small Batch Size: mantém o inventário baixo e de alta qualidade. Evita um grande inventário de ideias não testadas e não implementadas.
  • Continuous Discovery: processo contínuo de engajamento do usuário durante o processo de design e desenvolvimento.
  • GOOB – The new user-centricity: “getting out of the building” significa que as respostas devem ser buscadas fora do escritório, em marketplace, por exemplo.
  • Shared understanding: conhecimento evoluído (do coletivo) sobre o ambiente, produto e usuários.
  • Anti-pattern: Rockstars, Gurus and Ninjas: Lean UX defende a mentalidade baseada em time. Evite perfis que possam afastar a colaboração.
  • Externalizing your work: utilize quadros, lembretes, etc. para manter um ambiente propício a ideias e inspiração de outras pessoas.
  • Making over analysis: há mais valor em criar a primeira versão de uma ideia do que dedicar metade de um dia debatendo em reuniões.
  • Learning over Growth: foco em aprendizado primeiro; escalar em segundo.
  • Permission to fail: para encontrar a solução do negócio, o time precisa experimentar ideias. Muitas destas ideias irão falhar, por isso crie a cultura da experimentação.
  • Getting out of the deliverables business: documentos não resolvem o problema do usuário, bons produtos sim. O time deve estar focado em trabalhar nas features com maior impacto para os usuários, medindo a reação do mercado em relação a qualidade do produto.

A área de Vision, Framing, and Outcomes descreve como mudamos radicalmente a forma de trabalho, tendo como objetivo a criação de outcomes, e não somente entregáveis. Para isso, algumas ferramentas são utilizadas na confirmação da hipótese, tais como Business Assumptions Worksheet, Hypotheses (utilização do roteiro para confirmação da hipótese), Subhypotheses (quebra da hipótese em partes menores), Outcomes, Personas (uso da Proto-Personas e Persona Format para moldar quem estará utilizando) e Features.

O Collaborative Design aborda o processo de design com técnicas familiares, mas com ênfase no trabalho colaborativo. O objetivo inicial é a velocidade, priorizando o aprendizado e o uso do MVP como ferramenta chave. Entre as principais técnicas estão: Design Studio (coloca o time cross-functional para trabalhar juntos e visualizar potenciais soluções para o problema) e Style Guides (accessible, continually improved e actionable).  

Em MVPs and Experiments, os experimentos são utilizados para validar hipóteses no mercado e criar produtos baseado no aprendizado. E assim trabalhar na criação do MVP com ou sem protótipos. Com protótipos, existe o low-fidelity para expor ao time o senso de como o produto deve funcionar. Já mid and high-fidelity possuem mais detalhes e testam designs em nível de interação, visual e conteúdo similar a experiência do produto final.

Por fim, o Feedback and Research trabalha com inputs dos usuários (contínuos feedbacks) que contribuem para o processo de design, incorporando a iterações de produtos. As principais técnicas são: pesquisa contínua (Continuous Discovery) e colaborativa (Collaborative Discovery), artefatos de teste (Sketches), incorporar a opinião do usuário no ciclo Lean UX (static wireframes, mockups, prototypes), uso de testes A/B e reconciliar feedback de diferentes fontes.

 

3 GERENCIAMENTO ÁGIL

Embora o Lean UX tenha uma recomendação de integração com o Agile, vamos trabalhar com as práticas do framework ágil Scrum para execução do backlog e validação dos produtos que serão desenvolvidos com base nas técnicas citadas anteriormente. O Scrum é fundamentado no empirismo, empregando uma abordagem iterativa e incremental para melhorar a previsibilidade e controle de riscos.

Teremos quatro eventos formais para inspeção e adaptação da Sprint: Planning, daily, review e retrospective. O time será composto do time de desenvolvimento, Product Owner (PO) e Scrum Master (SM). O PO é o responsável por gerenciar o backlog do produto, enquanto o SM é um servo-líder para o time e o time de desenvolvimento realiza o trabalho de entregar uma versão usável do produto (incremento).

A Sprint é um time-boxed de dez dias úteis (em nosso caso) de trabalho para entregar a versão incremental potencialmente utilizável do produto. A Sprint Planning é a reunião colaborativa, que define o backlog a ser feito na Sprint. A Daily possui apenas 15 minutos e serve como inspeção do trabalho desde o dia anterior e o trabalho a ser feito até a próxima Daily.

A Review, executada no final da Sprint, promove a colaboração para identificar ajustes no backlog do produto. E a Retrospective inspeciona o próprio time e cria um plano de melhorias a serem aplicadas na próxima Sprint.

Sendo assim, o backlog do produto relaciona tudo que o produto deve ter, os itens selecionados para a Sprint junto ao plano para entregar o incremento do produto e atingir o objetivo da Sprint são chamados de backlog da Sprint. Por fim, o incremento representa todos os itens completados nas Sprints.

As práticas como burndown e burnup são representações usadas para prever o progresso. Embora muito úteis, não substituem a importância do empirismo e das reuniões mencionadas que contribuem para a inspeção e adaptação do projeto.

 

4 CONSIDERAÇÕES FINAIS

A competitividade no mercado digital propõe inúmeros desafios as empresas que precisam adotar um modelo dinâmico de criação produtos, entregando valor ao usuário e uma boa experiência nesta jornada de compra. Neste estudo, avaliamos as técnicas Lean Inception, Lean UX e Agile (Scrum), com o propósito de criar MVPs (Produto Mínimo Viável) e validar hipóteses no mercado. A experimentação e o aprendizado serviram como direcionadores de investimentos no negócio.

As três técnicas em conjunto contribuíram para criar um modelo de experimentação enxuto e contínuo, trabalhando desde a concepção do produto Admission (sistema de captação de candidatos para converter em matriculas) até a implementação de novas funcionalidades em produção. Escrevemos então a visão do produto, o que ele é e o que ele não é, as personas, jornadas, features e priorizamos de acordo com o valor para o negócio e dificuldade técnica.

Considerando a UX (experiência do usuário) e os feedbacks como imprescindíveis para aprender e ajustar a criação, mudança ou adequação de produtos. O gerenciamento ágil efetiva o time-to-market e o produto idealizado é executado em Sprints (time box de 2 semanas), conforme priorização do backlog. O backlog possui as atividades necessárias para desenvolvimento do produto acordado nas sessões. As reuniões diárias (dailys), retrospectiva, review e a demo são utilizadas para inspecionar o progresso do desenvolvimento e ajustes necessários.

 

REFERÊNCIAS

CAROLI, Paulo. Direto ao ponto: criando produtos de forma enxuta, 2015.

Design Thinking: ferramenta de inovação para empreendedores. Disponível em: <https://endeavor.org.br/tecnologia/design-thinking-inovacao/>. Acesso em: 19 jun. 2018.

Design Thinking 101 –  The Double Diamond Approach. Disponível em: <https://medium.com/seek-blog/design-thinking-101-the-double-diamond-approach-ii-4c0ce62f64c7>. Acesso em: 19 jun. 2018.

GOTHELF, Jeff; SEIDEN, Josh; Lean UX: Applying Lean Principles to Improve User Experience.

Lean Inception. Disponível em: <https://martinfowler.com/articles/lean-inception/>. Acesso em: 07 mai. 2018.

Marketing 4.0: do Tradicional ao Digital, passo a passo. Disponível em: <https://novaescolademarketing.com.br/marketing/marketing-4-0/>. Acesso em: 13 mai. 2018.

Marketing 4.0 – Oportunidades e Tendências. Kotler 2017. Disponível em: <http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/>. Acesso em: 15 mai. 2018.

Metodologias Ágeis. Disponível em: <https://agilemomentum.wordpress.com/>. Acesso em: 25 jun. 2018.

MVP: entenda as principais vantagens ao utilizá-lo. Disponível em: <http://blog.justdigital.com.br/mvp-entenda-as-principais-vantagens-ao-utiliza-lo/>. Acesso em 23 mai. 2018.

MVP: guia completo do Produto Viável Mínimo. Disponível em: <https://saiadolugar.com.br/mvp/>. Acesso em: 24 mai. 2018.

MVP: O que é e como fazer o produto mínimo viável? Disponível em: <https://conteudo.startse.com.br/para-startups/isabella/mvp-produto-minimo-viavel/>. Acesso em 24 mai. 2018.

RIES, Eric. Lean Startup. Crown Publishing Group, 2011.

Scrum.org. Disponível em: <https://www.scrum.org/>. Acesso em: 02 jul. 2018.

The Differences: Lean Startup vs Agile Methodology. Disponível em: <https://cabforward.com/the-differences-between-lean-startup-and-agile-methodology/>. Acesso em: 14 jun. 2018.

The Lean Startup. Disponível em <http://theleanstartup.com/principles>. Acesso em 11 jun. 2018.

UX Canvas. Disponível em: <https://ucdc.therectangles.com/#why>. Acesso em: 22 mai. 2018.

Integração de work items – Application Insights e VSTS

Vimos em posts anteriores as principais vantagens do Application Insights ao monitorar suas aplicações. Também vimos como fazer a integração com o VSTS e acompanhar os indicadores em seus Dashboards.

Agora vamos configurar o Application Insights no Portal Azure para trabalhar diretamente com os Work Items do VSTS. Acesse o diretório do Application Insights > Configurações > Itens de Trabalho (Work Items). Digite a URL da conta do VSTS, o projeto (System.TeamProject) e a área (System.AreaPath).

app-insights-work-item.png

Aceite os termos de autorização do AppInsights a ter acesso na conta do VSTS para ler, criar e atualizar Work Items.

Há duas formas de criar Work Items no App Insights: detecção proativa e instâncias individuais de atividades (ex: exceptionsfailures, requests, etc.). Veja que na área de Investigar > Falhas, com a opção de Drill into, podemos ver detalhes da transação de ponta a ponta.

app-insights-falha

E assim, criar um novo Work Item já associado aquela falha específica.

app-insights-new-wi

No VSTS vemos que o Work Item foi criado (tipo Bug) para ser corrigido pelo time de desenvolvimento.

app-insights-wi-vsts

 

 

Free Developer Offers – Visual Studio Code em seu time de desenvolvimento

Além de oferecer o Visual Studio Community (IDE para criar aplicativos não corporativos), Visual Studio Team Services, a Microsoft também disponibiliza o Visual Studio Code, um editor gratuito, código aberto e que pode ser executado em qualquer lugar. O download pode ser feito em Free Developer Offers.

A instalação é bem rápida, sem customizações e pode ser executada em Windows, macOS e Linux. Há suporte built-in para JavaScript, TypeScript  e Node.js, além de extensões para linguagens C#, C++, Java, PHP, Python e Runtime (.Net e Unity).

visual-studio-code

Entre os principais recursos nativos do editor:

IntelliSense
Inclui o sistema inteligente de autocomplete (do código-fonte), informações de parâmetros e listas de membros. Veja mais em IntelliSense.

visual-studio-code-intellisense

Debbuging
Permite depurar a aplicação, adicionar breakpoints e identificar valores na call stack. Auxilia você a editar, compilar e debug loop com o built-in debugger.

Pode exigir a instalação da extensão para a linguagem do seu desenvolvimento. Veja um pouco mais em Debugging in Visual Studio Code.

vs-code-c#.png

vs-code-debug

Integração com Git
Embora o VS Code permita trabalhar com vários SCM Providers, o Git é uma ótima recomendação para controle de versão, gerenciando commits, repositórios, branchesmerges diffs. Conheça mais sobre o suporte em Using Version Control in VS Code.

Resultado de imagem para visual studio code git


Outros recursos e plugins interessantes

Visual Studio com máquina virtual (VM) no Azure

No Portal Azure, você consegue subir rapidamente uma VM (máquina virtual) pré-configurada para ser o ambiente de desenvolvimento de seu time. Entre as principais vantagens estão: o uso de versões recentes do Visual Studio, recursos instalados e imagens para replicar com facilidade a criação de novas máquinas. Veja mais em Imagens do visual Studio no Azure.

Também recomendo a leitura sobre a Visão geral das máquinas virtuais do Windows no Azure para melhor compreensão das configurações e recursos.

Conecte-se então no Portal Azure, e escolha criar um novo recurso Windows Server 2016 VM.

azure-vm-01

O passo seguinte é a configuração do nome da máquina, tipo do disco, usuário, senha e grupo de recursos.

azure-vm-02

Escolha as configurações da máquina de acordo com a sua necessidade. Veja o número de IOPs, vCPUs, Memória (GB de RAM) e SSD Local para trabalhar com os recursos adequados ao seu ambiente.

azure-vm-03

A etapa 3 permite configurar a zona de disponibilidade, discos gerenciados, recursos de rede, extensões e monitoramento.

azure-vm-05

E por fim, a última etapa demonstra um resumo das configurações e a confirmação para criar a máquina virtual.

azure-vm-04

Pronto! A máquina virtual estará disponível nos serviços da Azure – Computação > Máquinas Virtuais. O acesso pode ser feito via RDP ou SSH.

azure-maquina-virtualazure-maquina-virtual

Azure Application Insights com VSTS

Já falamos no post anterior sobre os benefícios e configurações do Azure Application Insights para monitorar e detectar problemas nas suas aplicações. Que tal visualizar tudo isso no próprio VSTS?

Começamos com o download e instalação do Widget do Azure Application Insights no Marketplace do Visual Studio.

vsts-app-insights

Em seguida, adicione os dois widgets do Application Insights na área de Dashboards do VSTS:

  • Azure Application Insights Chart
  • Azure Application Insights Metrics

vsts-widget-app-insights

Para configurar o gráfico e a métrica, você precisa gerar seu API Key e Application ID no Portal Azure – Acesso da API, deixando a opção “Ler Telemetria” habilitada.

azure-api

Pronto! Agora forneça a API Key e Application Id e escolha a métrica que deseja monitorar. Há inúmeras métricas como Availability | Events | Exceptions | Failed requests | Page views | Process CPU | Processor time | Server requests | Sessions | Test duration | Users.

vsts-widget-app-insights-configuration

 

Microsoft Azure – Trabalhando com Application Insights e VSTS

Application Insights é um excelente recurso para monitorar suas aplicações na Web e garantir a disponibilidade e o desempenho esperado. Está disponível como serviço APM (Application Performance Management) no Portal da Azure e pode trabalhar com diversas plataformas. Os principais aspectos são:

  • Gerenciamento do desempenho de aplicações
  • Análises instantâneas e geração de Dashboards
  • Detecta problemas e exceções de desempenho
  • Trabalha com .Net, Java, Ruby, Python, PHP, Node.js e outras linguagens
  • Possui machine learning para análise dos dados coletados
  • A Microsoft disponibiliza SDKs para incluir as bibliotecas do seu projeto
  • Integra-se com seus projetos DevOps
  • Monitora também sites hospedados em servidores próprios (não somente na Azure)

app-insights-overview

O pacote de instrumentação é instalado e configurado em seus aplicativos, trabalhando com o Application Insights. Estes dados de telemetria são enviados ao Portal, que permite analisar:

Aplicação

  • Desempenho: solicitações, recursos de CPU, rede, aplicativo que prejudicou o desempenho, etc. Permite em tempo real com o Live Metrics.
  • Disponibilidade e falhas: em caso de exceções ou solicitações com falha. Também há verificação se um contador de desempenho ficar fora do intervalo previsto
  • Mapa da aplicação: desenho automático dos componentes da aplicação

Usuários

  • Uso: verifica como os usuários estão utilizando os recursos
  • User flow e funnels: determina a conversão e fluxo percorrido pelos usuários

 

Application Insights
Ao criar um novo projeto web, deixe habilitada a opção Application Insights e escolha o template que será utilizado no desenvolvimento da aplicação.

vs-new-projectvs-novo-projeto

Em ReferencesManage NuGet Packages instale o pacote do Application Insights (Microsoft.ApplicationInsights).

vs-app-insights.png

Em seguida, crie um novo diretório de Application Insights na Azure, configurando Nome, Tipo de Aplicativo, Assinatura, Grupo de Recursos e Localização.

azure-application-insights-novo-diretorio

Veja que na página inicial (visão geral) estará disponível a Chave de Instrumentação e os gráficos de análise da aplicação. Copie a chave e insira na Tag <InstrumentationKey> do arquivo web.config do ApplicationInsights.config.

azure-application-insights-overviewvs-web-config* em novas versão do Visual Studio, estes diretórios já são criados automaticamente na Azure.

A partir de agora sua aplicação já estará enviando dados para o Portal e assim visualizar o monitoramento dos principais eventos.

app-insights-overview

Nos próximos posts falaremos mais sobre:

 

BSP Business Dynamics – overview teórico

Finalizei ontem (23/07/2018) o curso Certificate em Business Dynamics da BSP  (Business School São Paulo) e valeu muito a pena este um ano de dedicação em disciplinas direcionadas a visão estratégica, negócios e empresarial.

bsp

Decidi compartilhar os principais conceitos discutidos no curso e que vão ser incorporados de alguma forma na minha trajetória profissional.

 

Inteligência Competitiva

  • Inteligência empresarial (anos 70) – Mercado (após 70) – Competitiva (após 2000)
  • Ambientes: macroambiente e microambiente
  • 9 tipos de inteligência (Emocional – Daniel Goleman – uma das principais)
  • Processo de tomada de decisão e conceito Puzzle
    • The Art of Choosing – Sheena Iyengar
  • Racionalidade limitada – A Behavioral Model of Rational Choice – Herbert A. Simon
  • Modelo mental
    • Learn by doing
    • Livro rápido e devagar – duas formas de pensar – Daniel Kahneman
  • Visões: framing, excesso de confiança, ancoragem e ajustamento, aumento irracional de comprometimento e representatividade
  • Sistemas e recursos de IC
  • Visão analítica (cada parte influencia o todo) e Visão sistêmica (o todo influenciado por cada parte)

9-tipos-ic.png

 

Ambiente Econômico Global

  • 2015: inflação – regime de metas baixando juros; redução de preço da energia insustentável e preço do petróleo na IMP e EXP; falta de infraestrutura
  • Economia brasileira: 65% em serviços de baixa tecnologia
  • PIB: crédito pessoal e commodities – aumento do PIB insustentável (2013 e 2014) – associou a capacidade de crescimento com a capacidade de endividamento.
    • Emprego: inflação de salários
  • Selic: juros alto reflete em mais dinheiro no mercado financeiro (mercado de especulação); menos em negócios e investimentos
  • Salário mínimo: quando baixo exerce o desestimulo na produção pelo baixo poder de compra
  • Cadeia Global de Valor: atividades necessárias a produção e entrega do produto ao cliente
  • Mercado da China: calçados, vestuário e têxteis, automóveis, equipamentos e capacidade energia solar e eólica.
    • Soberania econômica – rota da seda terrestre e marítima
  • Praga Negra: regiões com alta produção de petróleo e concentram muito da renda do país
  • 4ª Revolução Industrial (Klaus Schwab) e geopolítica

energia-eolica

 

Liderança

  • Administrando a mudança
  • O grande desafio da mudança
  • Administração do tempo
    • Lei dos ritmos biológicos
    • Lei de Parkinson – distribuição do trabalho varia em função do tempo disponível e não do tempo necessário
  • Liderança positiva
  • Livro Considerando todas as coisas: “O errado é errado mesmo que todo mundo esteja fazendo. E o certo é certo mesmo que ninguém esteja fazendo”.

  • Transformando o ambiente de trabalho: resultados excepcionais, positividade e virtuosidade
  • Filme Estrelas além do tempo

  • MKT 4.0: Pessoa > Cliente; Sociedade > Mercado
  • Competências Interpessoais – delegação (tarefa certa para a pessoa certa

Image result for roda da vida(roda da vida – avaliação pessoal para conhecer-te a ti mesmo)

 

Balanced Scorecard
Conjunto de indicadores atrelados a estratégia da empresa.

  • Tipos de decisão: instantânea, significante e estratégia
  • Tomada de decisão
  • 4 perspectivas do BSC: financeiro, processos internos, cliente, aprendizado e crescimento
  • Mapas estratégicos: itens do BSC em relação de causa e efeito
  • Etapas do BSC
  • Construção do BSC

 

Gestão de Negócios

  • Mindset Agile
    • Features: 45% nunca utilizado; 19% raramente; 13% frequentemente e 7% sempre utilizado
  • Produção empurrada x produção puxada
  • Business Model Canvas
  • Management 3.0
  • MVP: objetivo do negócio – resolver o problema do negócio
  • SAFe: Scaled Agile Framework
  • Portfolio – Program – Coordination – Time
  • Estratégia da empresa em trabalhar com produtos (produtização)
  • OKR
  • Design Thinking

 

Teoria das Organizações

  • Triple Bottom Line
    • Will Schutz: relação entre autoestima e Triple Bottom Line
  • Leitura Deepak Chopra: as pessoas sempre gostam de algo que fariam até de graça
  • Edgar Schein / Fischer & Fleury: cultura organizacional
  • Cultura, subcultura e contracultura
  • Mecanismos da revaloração da Cultura Corporativa
  • Dimensões culturais – Hofstede – 1. Distância do poder (baixa x alta) 2. Coletivismo x individualismo 3. Feminilidade x Masculinidade 4. Incerteza x Controle
  • Os 3 imperativos para se tornar um grande líder – Linda Hill e Kent Lineback – 1. Gerenciar a si mesmo 2. Gerenciar sua rede de relações 3. Gerenciar seu time
  • Feedback
    • de reconhecimento: manutenção do comportamento
    • de aprimoramento: desenvolvimento do comportamento
  • Autoestima – Albert Badura
  • Modelo liderança situacional – Ken Blanchard

IE

 

Estratégia Empresarial

  • Modelo de negócio
    • Hipótese
    • 3 dimensões: mercadologia, econômica-financeira e social
  • Mintzberg: 5 P’s da estratégia (Plano/Pretexto/Padrão/Posição/Perspectiva)
  • Fator de eficiência e X-Efficiency Factor – Liebenstein
  • Estratégias competitivas de Porter x stuck in the middle
  • Análise do ambiente interno
    • Cadeia de valor Porter
    • Capacitações (Fujimoto) – estáticas, de melhoria e evolucionárias
  • Análise do ambiente externo
    • Abordagem de Horton
      • Mobilização de insumos ou pré-foresight
      • Visões de futuro ou foresight
      • Decisão e ação, ou Pós-Foresight
    • Os 9 pontos de Naisbitt para antecipar o futuro
  • Construindo o futuro
    • Modelo TAIDA de análise de cenários (Tracking | Analysing | Imaging | Deciding | Acting)

avaliacao-ideias

 

Empreendedorismo

  • Reter atenção; mindfulness (atenção plena)
  • Rocket pitch
  • Intraempreendedorismo
  • Pesquisa GEM (Global Entrepreneurship Monitor) Sebrae
  • Institucional void: onde a organização não faz bem feito; há uma oportunidade
  • Burn rate: budget para testar e validar produtos
  • Inovação
    • Spin-off
    • Aquisições
    • Renovação estratégica
    • Modelo de negócio
  • Venture Capital x Private Equity
  • Lógica Casual: meios para atingir objetivos pré-definidos
  • Lógical Effectual (effectuation): imaginação de novos fins possíveis a partir de meios disponíveis
  • Modelo Tradicional x Modelo Dinâmico Effectuation
    • Os 5 princípios

canvas-modelo-negocios

 

Habilitando notificações no VSTS – Build, Code, Extension, Release e Work

As notificações podem auxiliar os colaboradores da empresa a monitorar os principais eventos do ciclo de vida aplicação. Quando bem configuradas, são verdadeiros watchdogs para manter os owners de cada área heads up com seus processos.

Por exemplo, notificar o SM ou Desenvolver sobre a mudança em um Work Item, ou notificar o CM quando um Build falhar.

O primeiro passo é configurar a notificação individual ou para o time do projeto. Na imagem abaixo, acesse no VSTS Notification Settings para configurar a notificação individual:

vsts-notification-settings

Para configurar notificações para o time do projeto, acesse o VSTS Project Settings > Notifications.

vsts-notifications-team

Veja que as configurações de notificação – individual ou time de projeto, podem ser feitas nos eventos de Build, Code (Git ou TFVC), Extension, Release e Work. E então, uma falha na Build, a conclusão do deployment, alterações de pull request, entre outros, podem ser notificados por e-mail, conforme habilitação.

vsts-notifications

Para visualizar os critérios e configurações das notificações, utilize a opção View.

vsts-notifications-view

Para criar uma nova notificação, acesse New Subscription. No exemplo abaixo, configuramos a categoria Work, e o evento de criação do Work Item, ou seja, a cada novo Work Item, haverá uma notificação por e-mail.

vsts-notifications-new

Em seguida, configuramos os critérios de disparo da notificação.

vsts-notifications-new-criteria

 

Gestão de contratos em projetos ágeis

No contexto de gerenciamento de projetos ágil, temos algumas questões a serem respondidas quando estabelecemos um contrato (ou relação de confiança) com o parceiro (fornecedor) que participará do projeto:

  • Os dois lados possuem uma visão clara dos princípios do Manifesto Ágil?
    manifesto-agil
  • Como serão os critérios de aceitação das entregas? Considerando que o modelo adaptativo propicia flexibilidade em mudanças e priorização de requisitos
    Resultado de imagem para tripla restrição agile
  • A cobrança será por Sprint ou valor entregue? Conseguimos definir o preço inicial do projeto? A definição do baseline, escopo do produto, user stories e entrega, etc. 

Sim, é possível criar contratos que atendam este modelo de colaboração e confiança. O fornecedor precisa considerar um modus operandi que entregue valor com antecedência e frequência. O cliente é o direcionador com feedbacks, colaboração e facilitação. Algumas técnicas de contratação, recomendadas pelo ACP (Agile Practice Guide – PMI) podem formalizar essa dinâmica: 

  • Estrutura de várias camadasflexibilidade em diferentes aspectos – itens fixos (ex.: garantias, arbitragem) podem ser bloqueados em um contrato mestre; as outras partes com itens sujeitos a alterações (ex.: taxas de serviços, descrições de produtos) em um cronograma de serviços, referenciados no contrato principal.
  • Enfatize o valor entregue: estruture os marcos e os termos de pagamento com base em resultados orientados por valor, a fim de aumentar a agilidade do projeto.
  • Aumentos de preços fixosdecompor o escopo em microdeliverables de preço fixo, como histórias de usuários. Para o cliente, isso dá mais controle sobre como o dinheiro é gasto. Para o fornecedor, ele limita o risco financeiro de excesso de compromisso para um único recurso ou entregável.
  • Tempo e materiais não excedentes: limite o orçamento total a um montante fixo. Isso permite que o cliente incorpore novas idéias para o projeto (não planejado originalmente), gerenciando a capacidade e substituindo o trabalho original por um novo trabalho.
  • Tempo e materiais graduadosrisco financeiro compartilhado. Como os critérios de qualidade fazem parte do que é feito, o fornecedor pode ser recompensado com uma taxa horária maior quando a entrega for anterior ao prazo contratado. Por outro lado, o fornecedor sofreria uma redução tarifária para entrega tardia.
  • Opção de cancelamento antecipado“dinheiro para nada” permite que o cliente encerre o projeto antecipadamente. Por exemplo, se os itens restantes do backlog não atingirão mais as expectativas do ROI, o fornecedor pode rescindir o contrato com pagamento de 20% do valor remanescente do contrato.
    a3
  • Opção de escopo dinâmico: para os contratos com orçamento fixo, um fornecedor pode oferecer ao cliente a opção de variar o escopo do projeto em pontos especificados no projeto. O cliente pode ajustar recursos para atender a capacidade.
  • Aumento de equipe: provavelmente, a abordagem de contratação mais colaboradora é incorporar os serviços do fornecedor diretamente na organização do cliente. As equipes de financiamento em vez de um escopo específico preservam o critério estratégico do cliente sobre o que o trabalho deve realmente ser feito.
  • Favorecer os fornecedores de serviços completos: para diversificar o risco, os clientes podem procurar uma estratégia multisuplicadora. No entanto, a tentação será contratar o trabalho de forma que cada fornecedor faça apenas uma coisa, o  que cria uma rede de dependências antes que algum serviço ou produto utilizável emerge. Em vez disso, coloque ênfase em compromissos que oferecem o valor total (como na ideia de conjuntos de recursos independentes completos)

Uma boa recomendação é trabalhar com Sprints, cocriando backlogs de duas semanas que melhoram a previsibilidade e ajustes no escopo em direção aos objetivos do projeto. Crie também o roadmap do projeto, facilitando a visão do produto como um todo e a quantidade de trabalho para conclui-lo. Resultado de imagem para sprint agile

Seja seguindo este modelo mais dinâmico, ou em formato body shop (alocação dos profissionais), exija uma tabela com todas as atribuições que a contratada possui. Assim, você terá condições de exigir SLAs para contratar profissionais com os hard skills informados, sempre que precisar.

tabela-precos

Sutherland (Scrum.org) sugere um contrato padrão de preço fixo, incluindo a possibilidade do trabalho adicional em tempo e material. Em sequência, insere a opção de uma clausula de “mudança livre”: pode ser usada pelo cliente somente se ele trabalhar em conjunto com a equipe nas iterações.

Sem este engajamento com a equipe, a clausula é anulada e o contrato revertido para tempo e material. Desta forma, novos requisitos são bem vindos no projeto, sempre priorizando as atividades de maior valor no backlog.change-for-free

Já em modelos tradicionais de contratação, que exigem especificações claras e escopo fixo, as empresas precisam gerar RFPs com diversas informações e assim o fornecedor fica incumbido da entrega final para o cliente, gerenciando a restrição tripla (escopo – custo – tempo) mais qualidade e riscos.

  • Preço fixo: o contratante tem o menor risco, pois há um preço acordado para todo o trabalho. Apropriado quando o Contratante conhece bem o escopo do trabalho. PFAEP, PFRI e PFRC são exemplos desta modalidade.

  • Custos reembolsáveis: os custos do Fornecedor são reembolsados pelo Contratante. O risco maior é do contratante, pois os custos finais são desconhecidos. CMRF, CMPC, CMRI e CMRC são exemplos desta modalidade.

  • Tempo e Material: o preço é feito em uma base por hora ou por item. Possui elementos de um contrato preço fixo (preço fixado por hora ou por item de material) e de contrato de custo reembolsável (o custo total é desconhecido).

  • Ordem de compra: é a forma mais simples de contrato a preço fixo. Normalmente unilateral (assinado por uma das partes) e utilizado para compras de mercadorias simples (commodities).