{"id":8556,"date":"2019-01-28T15:32:43","date_gmt":"2019-01-28T17:32:43","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=8556"},"modified":"2019-02-11T15:30:08","modified_gmt":"2019-02-11T17:30:08","slug":"tipos-de-demanda-e-classes-de-servico-afinal-e-tudo-a-mesma-coisa","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2019\/01\/tipos-de-demanda-e-classes-de-servico-afinal-e-tudo-a-mesma-coisa\/","title":{"rendered":"Tipos de Demanda e Classes de Servi\u00e7o: Afinal, \u00e9 tudo a mesma coisa?"},"content":{"rendered":"\n
Certo dia, durante uma conversa sobre STATIK (Systems Thinking Approach to Implement Kanban) com outros colegas da Plataformatec, foi levantada uma d\u00favida interessante durante esse debate e que pode fazer parte do dia a dia de quem tem adotado as pr\u00e1ticas do m\u00e9todo Kanban: Qual \u00e9 a diferen\u00e7a de tipos de demanda e as classes de servi\u00e7o? Elas querem dizer a mesma coisa mas com nomes diferentes ou s\u00e3o de fato coisas distintas? Vou tentar explicar para voc\u00eas neste blogpost.<\/p>\n\n\n\n
Mas antes de tudo, vamos falar brevemente do que se trata o STATIK para ficarmos todos na mesma p\u00e1gina.<\/p>\n\n\n\n
O STATIK trata-se de uma abordagem difundida por David Anderson (autor do m\u00e9todo Kanban) e posteriormente por Mike Burrows (autor do livro Kanban from Inside), para se compreender como um sistema de trabalho se comporta e como aplicar\/melhorar a ado\u00e7\u00e3o do Kanban dentro de um produto ou servi\u00e7o atrav\u00e9s da execu\u00e7\u00e3o de alguns passos explorat\u00f3rios. Segundo David, estes passos n\u00e3o necessariamente precisam ser executados de forma sequencial mas, eles geram insumos e conhecimentos para o processo de melhoria cont\u00ednua e a ado\u00e7\u00e3o propriamente dita do Kanban (podendo inclusive serem revisitados conforme a necessidade).<\/p>\n\n\n\n
Os passos s\u00e3o:<\/p>\n\n\n\n
Entender o prop\u00f3sito do servi\u00e7o para o cliente;<\/li>
Entender as fontes de insatisfa\u00e7\u00f5es com o atual sistema de trabalho (internas e externas);<\/li>
Analisar as demandas<\/strong>;<\/li>
Analisar a capacidade do grupo;<\/li>
Analisar e modelar os fluxos de trabalho;<\/li>
Criar as classes de servi\u00e7o<\/strong>;<\/li>
Modelar o sistema Kanban;<\/li>
Negociar e implementar mudan\u00e7as atrav\u00e9s do trabalho colaborativo e feedbacks.<\/li><\/ol>\n\n\n\n
Como podemos ver nesta listagem, encontramos tanto uma etapa relacionada \u00e0 demanda quanto \u00e0 classe de servi\u00e7o (destacados em negrito) e ali os assuntos come\u00e7am a se misturar. N\u00e3o entraremos em m\u00e9ritos de explora\u00e7\u00e3o a fundo desses dois passos, e sim aprender a diferenciar e entender como as demandas e classes de servi\u00e7o se relacionam. Quando falamos de demandas, automaticamente lembramos de User Stories, Bugs e afins. Mas, como enquadramos estas demandas de trabalho para que recebam o tratamento adequado em termos de prioriza\u00e7\u00e3o ou urg\u00eancia?<\/p>\n\n\n\n
Vamos por partes:<\/p>\n\n\n\n
O que caracteriza os tipos de demandas?<\/strong><\/h3>\n\n\n\n
Todo item de trabalho, ou demanda, possui um conjunto de informa\u00e7\u00f5es que a definem e que podemos chamar de suas caracter\u00edsticas<\/strong>. Dentre essas caracter\u00edsticas podemos destacar a motiva\u00e7\u00e3o que existe por tr\u00e1s desta tarefa, a natureza do trabalho que ser\u00e1 desenvolvido (A cria\u00e7\u00e3o de algo novo, uma melhoria ou uma corre\u00e7\u00e3o por exemplo), o solicitante, a persona que ir\u00e1 interagir com o resultado daquele trabalho, dentre outras.<\/p>\n\n\n\n
Atrav\u00e9s desse conjunto de informa\u00e7\u00f5es, conseguimos agrupar estes itens de acordo com suas semelhan\u00e7as e damos origem aos tipos de demanda. Utilizando como exemplo demandas de desenvolvimento de software, alguns tipos de demanda que s\u00e3o classicamente utilizados por todos (ou quase todos) os times de desenvolvimento s\u00e3o:<\/p>\n\n\n\n
Funcionalidades – Implementa\u00e7\u00e3o de um novo requisito de neg\u00f3cio ou funcionalidade em um determinado produto e\/ou servi\u00e7o para entregar valor ao usu\u00e1rio final;<\/li>
Bugs\/Corre\u00e7\u00f5es – Corre\u00e7\u00e3o de algum problema identificado ap\u00f3s uma implementa\u00e7\u00e3o anterior e que possivelmente est\u00e1 impactando em algum tipo de uso em uma ou mais funcionalidades;<\/li>
Melhoria Evolutiva – Melhoria em alguma funcionalidade ou comportamento j\u00e1 existente;<\/li>
Tarefa – atividade n\u00e3o necessariamente relacionadas a uma funcionalidade em espec\u00edfico (ex: Criar documenta\u00e7\u00e3o do projeto).<\/li><\/ul>\n\n\n\n
A utiliza\u00e7\u00e3o ou n\u00e3o destes tipos ou at\u00e9 de algum outro em espec\u00edfico devem ser consideradas mediante ao contexto, necessidade do time ou do escopo de trabalho daquele momento. Existem outros tipos como os Spikes\/PoC(Proof of concept<\/em>), que correspondem a esfor\u00e7os tempor\u00e1rios de pesquisa e valida\u00e7\u00e3o antes de uma implementa\u00e7\u00e3o efetiva, e que podem ou n\u00e3o fazer sentido dependendo do tipo de atividade que a equipe desempenha. Equipes de outras \u00e1reas de neg\u00f3cio como suporte ou vendas, muito provavelmente ter\u00e3o tipos de demandas diferentes a se trabalhar. Resumindo, os tipos de demanda dizem respeitos aos diferentes tipos de trabalhos que uma equipe precisa lidar, de acordo com suas caracter\u00edsticas comuns.<\/p>\n\n\n\n
Classes de servi\u00e7o: O que s\u00e3o? Onde vivem? Do que se alimentam?<\/strong><\/h3>\n\n\n\n
Como dito anteriormente, os diferentes tipos de demandas (ou at\u00e9 mesmo diferentes demandas do mesmo tipo) podem exigir diferentes tipos de tratamento de acordo com suas caracter\u00edsticas. \u00c9 a\u00ed que entram as Classes de Servi\u00e7o<\/strong>. Cada classe de servi\u00e7o corresponde a uma forma diferente de tratar as demandas de trabalho de um time diferenciando-o em termos de prioriza\u00e7\u00e3o, senso de urg\u00eancia e fluxo de trabalho baseado nas suas pr\u00f3prias defini\u00e7\u00f5es. Baseado nas suas pr\u00f3prias defini\u00e7\u00f5es, nascem o que chamamos de pol\u00edticas expl\u00edcitas do processo<\/strong>.<\/p>\n\n\n\n
As pol\u00edticas s\u00e3o regras e acordos definidos pelo pr\u00f3prio time e orientam fluxos de trabalhos dentro do sistema. De acordo com o m\u00e9todo Kanban, \u00e9 importante que todas essas pol\u00edticas sejam registradas e acess\u00edveis ao time para que todos possam conhec\u00ea-las e aplic\u00e1-las no dia-a-dia de trabalho. Isto contribuir\u00e1 para uma melhor gest\u00e3o de riscos e aumentar\u00e1 a previsibilidade de entrega mediante o seu enquadramento e tamb\u00e9m trar\u00e1 alinhamento de expectativas com todas as pessoas envolvidas com a demanda.<\/p>\n\n\n\n
Existem 4 tipos de classes de servi\u00e7o que comumente s\u00e3o utilizadas com o m\u00e9todo Kanban. S\u00e3o elas:<\/p>\n\n\n\n
Expedite<\/strong> – Itens de grande urg\u00eancia e que necessitam serem trabalhados e entregues o quanto antes pois podem trazer grandes impactos em pouco tempo. Ex: Um bug que parou completamente o funcionamento de um e-commerce de larga escala ou uma oportunidade de venda ou cria\u00e7\u00e3o de um produto que est\u00e1 em alta\/tend\u00eancia no mercado e nas redes sociais;<\/li>
Fixed Date (Ou Date-Driven)<\/strong> – Quando a demanda precisa ser entregue at\u00e9 um prazo fixo, geralmente relacionado a uma situa\u00e7\u00e3o eventual ou sazonal, e que faz sentido apenas ser entregue antes do acontecimento (ex: Um hotsite de promo\u00e7\u00f5es para o dia das m\u00e3es) ou a algum tipo de implementa\u00e7\u00e3o regulat\u00f3ria ou legislativa e que pode gerar uma penalidade se n\u00e3o entregue at\u00e9 aquela data.<\/li>
Standard<\/strong> – Itens de trabalho comuns orientados segundo uma prioriza\u00e7\u00e3o expl\u00edcita por algum tipo de crit\u00e9rio (urg\u00eancia, valor de entrega, ordem de pedido, etc) que o time ir\u00e1 trabalhar quando n\u00e3o houver nada com maior urg\u00eancia (como um item expedite<\/em>). Ex: Uma nova funcionalidade de consulta em um sistema ERP.<\/li>
Intangibles<\/strong> – Demandas de trabalho que s\u00e3o dif\u00edceis de mensurar seus ganhos ou impactos a primeiro momento mas que a m\u00e9dio ou longo prazo podem tanto causar preju\u00edzos, caso n\u00e3o sejam cumpridos, quanto trazer bons resultados. Ex: Atualizar documenta\u00e7\u00e3o do projeto.<\/li><\/ul>\n\n\n\n
Agora algumas ressalvas:<\/p>\n\n\n\n
O que quer dizer diferentes fluxos de trabalho? Itens com classes diferentes podem requerer outro tipo de processo em rela\u00e7\u00e3o a como a demanda vai caminhar at\u00e9 a sua entrega. Para exemplificar melhor a defini\u00e7\u00e3o apresentada anteriormente vamos imaginar que o processo padr\u00e3o de um time seja composto da seguinte forma:<\/p>\n\n\n\n<\/figure>\n\n\n\n
Uma nova demanda Expedite chega, e se trata de um bug na aplica\u00e7\u00e3o que parou toda a cadeia de produ\u00e7\u00e3o. Esta tarefa precisa realmente passar por todos estes passos para ser entregue? Aparentemente n\u00e3o. Devido ao seu car\u00e1ter de urg\u00eancia e prioridade, ela provavelmente j\u00e1 nascer\u00e1 como “Pronto p\/ fazer” ou um membro do time ir\u00e1 parar sua tarefa atual para assumi-la e far\u00e1 toda a an\u00e1lise pr\u00e9-desenvolvimento j\u00e1 na fase de “Em andamento”. E tamb\u00e9m ao final, possivelmente n\u00e3o precisar\u00e1 de uma aprova\u00e7\u00e3o formal para ser submetida em produ\u00e7\u00e3o.<\/p>\n\n\n\n
Ent\u00e3o todo bug \u00e9 Expedite? N\u00e3o necessariamente. Cabe ao PO ou time analisarem os verdadeiros impactos desta necessidade e mapear a sua criticidade e urg\u00eancia de entrega frente ao problema que ele pode causar, ponderando tamb\u00e9m as tarefas que o time j\u00e1 est\u00e1 desenvolvendo.<\/p>\n\n\n\n
Preciso seguir a risca e utilizar todas as classes de servi\u00e7o? N\u00e3o, isso pode variar conforme o contexto e a necessidade do time ou do neg\u00f3cio. Um time pode trabalhar apenas com Standard e Expedite por exemplo.<\/p>\n\n\n\n
Existem outras classes al\u00e9m destas? Com certeza! Time de diferentes contextos podem trabalhar com classes diferentes e ter expl\u00edcito suas pr\u00f3prias pol\u00edticas. Exemplo: Um time de suporte pode trabalhar com tarefas de classes como “Tickets”, “Atendimento VIP” e “Manuten\u00e7\u00e3o”.<\/p>\n\n\n\n
Inclusive, podem ocorrer situa\u00e7\u00f5es em que implicitamente algumas demandas s\u00e3o tratadas de forma diferenciada, por\u00e9m n\u00e3o h\u00e1 uma pol\u00edtica expl\u00edcita para elas. S\u00e3o as chamadas Classes de servi\u00e7os ocultas.<\/p>\n\n\n\n
Um exemplo comum s\u00e3o demandas solicitadas por um CEO e que acabam n\u00e3o sendo encaixadas nas classes utilizadas pelo time, mas ainda sim furam fila na lista de prioridades. Neste caso, elas n\u00e3o atendem todos os requisitos necess\u00e1rios para serem enquadradas como expedites por exemplo.<\/p>\n\n\n\n
Se existe uma certa recorr\u00eancias deste tipo de situa\u00e7\u00e3o, \u00e9 importante destac\u00e1-las atrav\u00e9s de uma classe de servi\u00e7o para que o time possa de forma expl\u00edcita e transparente saber como trat\u00e1-las e tamb\u00e9m mensurar quais impactos elas podem estar causando e, assim, poder negociar ou discutir este tipo de situa\u00e7\u00e3o.<\/p>\n\n\n\n
A Rela\u00e7\u00e3o das Classes de Servi\u00e7o com o <\/strong>Cost of Delay<\/em><\/strong><\/h3>\n\n\n\n
O Cost of Delay, ou CoD, traz uma abordagem de car\u00e1ter econ\u00f4mico de como uma demanda pode impactar financeiramente caso ela n\u00e3o seja entregue ou sofra um atraso no seu prazo ou deadline (ex: seja uma multa\/penalidade ou a oportunidade de adquirir receita ou outro tipo de valor), servindo assim como ferramenta de prioriza\u00e7\u00e3o de trabalho e aux\u00edlio na tomada de decis\u00e3o. Dentro do CoD temos algumas formas de exemplificar os diferentes tipos de impacto de acordo com a curva de rela\u00e7\u00e3o de tempo x custo. Fazendo um paralelo com as classes de servi\u00e7o exploradas anteriormente n\u00f3s temos:<\/p>\n\n\n\n
Demandas priorizadas na classe de servi\u00e7o expedite tem seu custo crescente de forma vertiginosa em pouco tempo, necessitando urg\u00eancia no seu tratamento para minimizar o impacto gerado.<\/p>\n\n\n\n
Nesta classe, inicialmente temos um baixo custo devido ao prazo at\u00e9 a data espec\u00edfica, por\u00e9m conforme esta data limite se aproxima, ela se eleva proporcionalmente ao risco e, quando atingido o deadline, que por sua vez \u00e9 inegoci\u00e1vel, temos uma mudan\u00e7a brusca na curva de custo de impacto at\u00e9 que ela volte a se estabilizar.<\/p>\n\n\n\n
J\u00e1 para as demandas de classe de servi\u00e7o standard, o custo cresce de forma linear \u00e0 medida que existe o atraso\/demora na entrega e geralmente n\u00e3o ocorre uma varia\u00e7\u00e3o no seu c\u00e1lculo<\/p>\n\n\n\n
Devido a dificuldade de mensurar seus impactos, perdas ou ganhos, a curva relacionada a classe de servi\u00e7o intang\u00edvel cresce de forma muito lenta mesmo a longo prazo, indicando um baixo risco e grau de impacto, pois possivelmente corresponde a a\u00e7\u00f5es de baixa prioridade.<\/p>\n\n\n\n
Comparando demandas de diferentes tipos de classes de servi\u00e7o, temos uma ideia mais clara de quais classes devem ser trabalhadas de forma priorit\u00e1ria devido o seu impacto. Com demandas de um mesmo tipo (Standard por exemplo), esta abordagem tamb\u00e9m te possibilita quantificar estes valores e compar\u00e1-las entre si a fim de se chegar a uma tomada de decis\u00e3o sobre quais itens s\u00e3o mais interessantes de se priorizar de acordo com algum ponto de an\u00e1lise (Ex: receita esperada; redu\u00e7\u00e3o de custos). Neste blogpost<\/a> escrito por Lucas Colucci, temos alguns exemplos de como calcular e comparar estes custos de atraso.<\/p>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/01\/Process.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/01\/urgent-curve.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/01\/fixed-date-curve.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/01\/standard-curve.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/01\/intangible-curve.png\")
<\/figure>\n\n\n\n