{"id":7651,"date":"2018-06-28T14:21:07","date_gmt":"2018-06-28T17:21:07","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7651"},"modified":"2018-06-28T15:36:47","modified_gmt":"2018-06-28T18:36:47","slug":"agile-para-pmps-pmbok-para-agilistas-divide-et-impera","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2018\/06\/agile-para-pmps-pmbok-para-agilistas-divide-et-impera\/","title":{"rendered":"Agile Para PMPs, PMBoK Para Agilistas: divide et impera"},"content":{"rendered":"
SPOILER ALERT – Para voc\u00ea que bateu o olho neste text\u00e3o e achou TLTR (ou Too Long To Read), inclu\u00ed uma tabela comparativa ao final, como resumo do blog post.<\/span><\/i><\/p>\n <\/p>\n Divide et impera <\/span><\/i>– Dividir para conquistar. C\u00e9sar, Napole\u00e3o e outros grandes gestores provavelmente n\u00e3o constru\u00edam EAPs (Estrutura anal\u00edtica do projeto) e nem montavam Story Maps com post-its para planejar a conquista de territ\u00f3rios b\u00e1rbaros, mas j\u00e1 utilizavam o conceito que est\u00e1 por tr\u00e1s dessas t\u00e9cnicas: quebrar partes maiores de escopo em partes menores e mais gerenci\u00e1veis.<\/span><\/p>\n <\/p>\n <\/p>\n <\/p>\n Vamos ser humildes e assumir: n\u00e3o d\u00e1 para assoviar e chupar cana ao mesmo tempo. Embora eu mesmo nunca tenha tentado realizar essa proeza, penso que esse dito popular expressa bem a ideia de que nossa limitada mente humana n\u00e3o \u00e9 muito boa na execu\u00e7\u00e3o de v\u00e1rias tarefas simult\u00e2neas e muito menos no planejamento de v\u00e1rios assuntos ao mesmo tempo. Nosso c\u00e9rebro pode at\u00e9 ser um processador super-poderoso, mas ainda assim tem apenas um \u00fanico n\u00facleo. <\/span><\/p>\n Pensar em estrat\u00e9gias de solu\u00e7\u00e3o de problemas grandes e complexos \u00e9 uma tarefa quase imposs\u00edvel, porque envolve atacar diversos aspectos desses problemas ao mesmo tempo. Por isso, dividir o escopo de um empreendimento em partes menores e mais gerenci\u00e1veis \u00e9 a estrat\u00e9gia que vem obtendo o maior grau de sucesso na Hist\u00f3ria, pois nos permite focar em uma coisa por vez, respeitando assim nosso limite humano de processamento. <\/span><\/p>\n Al\u00e9m de aliviar as coisas pro nosso c\u00e9rebro, essa estrat\u00e9gia tem outras vantagens como prevenir o famoso <\/span>scope creep<\/span><\/i>, um dos maiores vil\u00f5es na gest\u00e3o de qualquer iniciativa, e facilitar o gerenciamento da execu\u00e7\u00e3o, etapa em que o produto \u00e9 constru\u00eddo. N\u00e3o quero deixar este text\u00e3o ainda maior ent\u00e3o n\u00e3o vou me aprofundar nos aspectos da constru\u00e7\u00e3o, mas tem uma coisa que eu tenho que destacar: uma estrat\u00e9gia eficiente de execu\u00e7\u00e3o depende necessariamente da quebra desse escopo em peda\u00e7os menores. Como dizem os adeptos do m\u00e9todo Kanban: o problema n\u00e3o \u00e9 o Waterfall, \u00e9 o tamanho do lote que \u00e9 grande demais.<\/span><\/p>\n Para fazer a divis\u00e3o descrita acima, o PMBoK apresenta a EAP – Estrutura anal\u00edtica do projeto, do ingl\u00eas WBS – Work Breakdown Structure. Voc\u00ea pode at\u00e9 ter desconfiado, mas n\u00e3o foi a galera da Sess\u00e3o da Tarde que fez essa tradu\u00e7\u00e3o. Talvez o melhor seria “Estrutura do projeto quebradinho”, mas o termo “anal\u00edtico” \u00e9 mais apreciado no erudito e rebuscado idioma Consult\u00eas Erudito, aquele que os consultores do passado usavam para dificultar a comunica\u00e7\u00e3o com o cliente e parecerem mais s\u00e1bios do que realmente eram. J\u00e1 nos projetos \u00e1geis, a t\u00e9cnica mais comumente utilizada \u00e9 o Story Mapping – Mapeamento de hist\u00f3rias. Felizmente ainda n\u00e3o inventaram uma tradu\u00e7\u00e3o a l\u00e0 “Estrutura anal\u00edtica das hist\u00f3rias”.<\/span><\/p>\n Apesar de ambas as t\u00e9cnicas serem baseadas no conceito de break down – que significa quebrar em peda\u00e7os menores, apesar de \u00e0s vezes esse trabalho dar vontade de chorar – \u00a0sua aplica\u00e7\u00e3o e abrang\u00eancia s\u00e3o diferentes. Essa diferen\u00e7a faz com que essas t\u00e9cnicas possam ser usadas de maneira complementar, com uma cobrindo os pontos fracos da outra. Logo, conhecer as nuances das duas ferramentas pode ajudar meus amigos PMPs a gerenciar melhor seus projetos, assim como \u00a0conhecer a EAP pode abrir a mente dos meus amigos agilistas para dimens\u00f5es que nem sempre s\u00e3o consideradas em iniciativas \u00e1geis. O intuito desse texto n\u00e3o \u00e9 ensinar a usar uma t\u00e9cnica ou outra. \u00c9 apenas compar\u00e1-las e provocar os leitores a abrirem a mente e a se aventurarem na utiliza\u00e7\u00e3o de t\u00e9cnicas diferentes. Portanto, adotei a licen\u00e7a po\u00e9tica de simplificar alguns conceitos para facilitar a compara\u00e7\u00e3o, ok? N\u00e3o precisa me xingar nos coment\u00e1rios.<\/span><\/p>\n Como eu sou f\u00e3 de Kanban e do algoritmo FIFO (<\/span>first in, first out)<\/span><\/i>, comecemos pelo que veio antes. A EAP \u00e9 apresentada como a ferramenta para detalhar o que um <\/span>projeto<\/b> deve entregar, e isso \u00e9 muito importante. Hoje em dia, o termo “projeto” virou sin\u00f4nimo de iniciativa, mas idealmente, esse projeto \u00e9 uma iniciativa com in\u00edcio, meio e fim. Ou seja, pro PMBoK, n\u00e3o basta ser iniciativa, tem que ter a “terminativa” tamb\u00e9m. Esse conceito marca a gest\u00e3o de projetos de forma t\u00e3o importante que, parafraseando o professor Rodrigo Caixeta l\u00e1 da ProjectLab: “<\/span>\u00c9 melhor um fim horroroso do que um horror sem fim<\/span><\/i>“. Por isso, apesar de ter algum n\u00edvel de flexibilidade e estar sujeito \u00e0 mudan\u00e7as ao longo do projeto, o escopo tem um limite, porque o projeto tem um limite. <\/span><\/p>\n Um dos motivadores da utiliza\u00e7\u00e3o de m\u00e9todos \u00e1geis \u00e9 a volatilidade que o mercado imprime aos projetos. Esperar um marco t\u00e3o raro quanto o fim do projeto para tomar decis\u00f5es e reavaliar estrat\u00e9gias pode levar ao desperd\u00edcio. \u00c0s vezes, quando um produto \u00e9 entregue, j\u00e1 n\u00e3o faz mais sentido. Por isso, quando usamos ferramentas mais \u00e1geis como o mapa de hist\u00f3rias, ou melhor, Story Mapping, o fim do projeto, ou o limite do escopo n\u00e3o \u00e9 t\u00e3o importante pois essa t\u00e9cnica tem uma vis\u00e3o mais abrangente, mais pr\u00f3xima do ciclo de vida de um produto (n\u00e3o quer dizer que n\u00e3o exista expectativa por prazo; depois cheque <\/span>esse blogpost aqui<\/span><\/a>). O ciclo de vida de um produto \u00e9 afetado por diversos projetos com objetivo de evoluir esse produto. O mapa de hist\u00f3rias pode representar, entre outras coisas, o escopo do roadmap de evolu\u00e7\u00e3o deste produto.<\/span><\/p>\n <\/p>\n Numa abordagem h\u00edbrida da vis\u00e3o de roadmap, cada pequeno incremento na evolu\u00e7\u00e3o do produto \u00e9 realizado por uma itera\u00e7\u00e3o, que pode ser representada por um projeto (ou fase de um projeto), que por sua vez, pode ser representado por uma EAP, mais ou menos como demonstrado na figura abaixo:<\/span><\/p>\n <\/p>\n <\/p>\n <\/p>\n Visualmente, a EAP \u00e9 representada como um organograma, onde todo o escopo \u00e9 “subordinado” ao projeto. Embora a EAP seja um artefato atemporal, isto \u00e9, sem rela\u00e7\u00e3o com o cronograma do projeto e com a ordem em que devem acontecer as entregas, seus primeiros n\u00edveis n\u00e3o representam pacotes em si, mas sim divis\u00f5es l\u00f3gicas que buscam organizar a estrat\u00e9gia de entrega do escopo do projeto. Num segundo n\u00edvel de divis\u00e3o est\u00e3o os grupos de pacotes (ou produtos). Os pacotes de entrega, ou seja, o escopo em si, s\u00e3o representados no \u00faltimo n\u00edvel da EAP, mais ou menos assim:<\/span><\/p>\n <\/p>\n <\/p>\n <\/p>\n Embora exista um certo preconceito contra o gerente de projetos “tradicional” e muita gente acredite que para o PMBoK seja fun\u00e7\u00e3o desse gerente elaborar a EAP sozinho, a verdade \u00e9 que o processo de constru\u00e7\u00e3o da EAP, a exemplo do Story Mapping, deve ser feita de forma iterativa e colaborativa com a equipe do projeto e das principais partes interessadas. A diferen\u00e7a \u00e9 que o processo iterativo de planejamento descrito no PMBoK recomenda que a constru\u00e7\u00e3o da EAP passeie por todas as <\/span>\u00e1reas de conhecimento do projeto<\/b>, ou seja, ao elaborar o cronograma, estrat\u00e9gia de gest\u00e3o de riscos, gest\u00e3o de pessoas, contratos e terceiriza\u00e7\u00e3o, gest\u00e3o de partes interessadas, gest\u00e3o de qualidade, gest\u00e3o de comunica\u00e7\u00e3o, gest\u00e3o de custos etc., dando visibilidade a outras dimens\u00f5es do projeto, que t\u00e9cnicas mais light acabam ignorando.<\/span><\/p>\n A t\u00e9cnica de constru\u00e7\u00e3o da EAP tem o objetivo final de gerar um baseline do escopo do projeto ou de parte dele. Ou seja, a partir da constru\u00e7\u00e3o deste artefato, \u00e9 gerado um compromisso para o projeto ou para uma fase do projeto. \u00a0Outra ideia falsa que \u00e9 espalhada em confer\u00eancias mundo afora, \u00e9 a que os processos do PMBoK tornem necess\u00e1rio fazer um “<\/span>waterfall”<\/span><\/i> e construir todo a EAP detalhada do projeto de uma vez s\u00f3. A EAP tamb\u00e9m pode ser elaborada iterativa e incrementalmente, por fase de projeto, onda, sprint etc., e permitir a descoberta gradual do escopo. No meu ponto de vista, a principal desvantagem da EAP em rela\u00e7\u00e3o ao Story Mapping \u00e9 que a obrigatoriedade de um compromisso com os pacotes da EAP n\u00e3o permite uma vis\u00e3o clara de prioriza\u00e7\u00e3o, dado que todos os pacotes tem a mesma import\u00e2ncia. Como consequ\u00eancia da aus\u00eancia dessa vis\u00e3o, o time do projeto pode ser direcionado a entregar tudo o que foi mapeado, mesmo que em dado momento do projeto esses pacotes n\u00e3o fa\u00e7am mais sentido.<\/span><\/p>\n O Story Mapping n\u00e3o traz a ideia do compromisso representado pela EAP de maneira t\u00e3o forte. Essa flexibilidade tem origem no pr\u00f3prio manifesto \u00e1gil que foca em “<\/span>responder \u00e0 mudan\u00e7as mais do que seguir um plano<\/span><\/i>“. Isto \u00e9, mais do que uma ferramenta de levantamento de escopo, o Mapa de Hist\u00f3rias \u00e9 uma ferramenta \u00a0para maximiza\u00e7\u00e3o do valor entregue por esse escopo. O ponto de comprometimento depende muito mais do m\u00e9todo de trabalho adotado pela equipe; Por exemplo, pode ocorrer no “<\/span>Replenishing<\/span><\/i>” do Kanban ou no “<\/span>Sprint Planning<\/span><\/i>” do Scrum. <\/span><\/p>\n Existem diversas formas de representar um mapa de hist\u00f3rias. Uma das vers\u00f5es mais comuns apresenta pelo menos duas dimens\u00f5es temporais. A primeira dimens\u00e3o temporal \u00e9 chamada de <\/span>Backbone – <\/span><\/i>espinha dorsal. Ela representa o fluxo de valor e fica logo ao topo do mapa. O fluxo de valor \u00e9 lido da esquerda para a direita e \u00e9 escrito na ordem em que acontecem as grandes atividades que o usu\u00e1rio poderia realizar. Esse fluxo \u00e9 dividido para representar o passo a passo daquela grande atividade. Essa divis\u00e3o \u00e9 chamada de “esqueleto andante”. Para cada atividade, s\u00e3o mapeadas as hist\u00f3rias de usu\u00e1rio, essas sim representando “requisitos” ou “caracter\u00edsticas” do produto. <\/span><\/p>\n <\/p>\n Um dos princ\u00edpios do Manifesto \u00c1gil \u00e9 a \u00a0Simplicidade: a arte de maximizar a quantidade de trabalho que n\u00e3o precisou ser feito. O mapa de hist\u00f3rias provoca a discuss\u00e3o sobre MVP – <\/span>Minimum Viable Products, <\/span><\/i>ou<\/span> “Produtos M\u00ednimos Vi\u00e1veis”. Numa vis\u00e3o simplificada, esses produtos representam um agrupamento de hist\u00f3rias e features que visam entregar a menor quantidade de escopo poss\u00edvel para que seja realizado um lan\u00e7amento (release) que traga valor para produto, do ponto de vista do cliente\/usu\u00e1rio. Pelo lan\u00e7amento “minimizado”, \u00e9 poss\u00edvel testar se o produto entrega o valor esperado. Mais ainda, \u00e9 poss\u00edvel obter o feedback do produto final e assim re-priorizar o escopo do projeto. Dessa maneira o Story Mapping direciona a efici\u00eancia (fazer menos) com a efic\u00e1cia (fazer o que \u00e9 preciso).<\/span><\/p>\n O Story Mapping foca no valor entregue para o usu\u00e1rio final, mas n\u00e3o considera por exemplo, a influ\u00eancia de outras partes interessadas da organiza\u00e7\u00e3o e seu impacto no processo de constru\u00e7\u00e3o em si. Uma estrutura mais completa como a EAP garante que al\u00e9m do usu\u00e1rio final, ser\u00e1 entregue valor a todos os envolvidos no projeto, gerenciando expectativas e outros aspectos pol\u00edticos, \u00a0pois ela reconhece a exist\u00eancia de duas origens distintas de escopo: o Escopo do Produto e o Escopo do Projeto. Por exemplo, considere que seu projeto precisa entregar um Ovo para gerar valor para o cliente final. T\u00e1, \u00e9 um exemplo besta, mas \u00e9 f\u00e1cil de entender e simples de desenhar:<\/span><\/p>\n <\/p>\n Um Story Mapping mapearia esse ovo. A EAP iria mais al\u00e9m: mapear o Ovo, mas tamb\u00e9m mapearia a necessidade de Constru\u00e7\u00e3o da Galinha, o que pode ser um processo bem mais complexo que o Ovo em si. Note que frequentemente existe certa frustra\u00e7\u00e3o por parte dos times de projetos \u00e1geis, pois os aspectos da Galinha frequentemente limitam e bloqueiam a evolu\u00e7\u00e3o da entregas do Ovo. Principalmente quando deparado com um projeto h\u00edbrido ou em escala organizacional \u00e9 bastante comum que a equipe do projeto tenha que entregar coisas chatas e complexas como:<\/span><\/p>\n <\/p>\n <\/p>\n Pode at\u00e9 ser que esses itens estejam relacionados \u00e0 alguma das hist\u00f3rias mapeadas quando se utiliza a t\u00e9cnica de Story Mapping, mas constantemente eles s\u00e3o independentes dessa entregas e acabam negligenciadas pelos l\u00edderes de projetos \u00e1geis, at\u00e9 mesmo quando est\u00e3o dentro do alcance da pr\u00f3pria equipe. Por exemplo: Vamos supor que voc\u00ea est\u00e1 usando uma abordagem \u00c1gil e faz uma retr\u00f4 com a galera do seu time e levanta um monte de planos de a\u00e7\u00e3o para serem implementados. Tecnicamente, esses planos passam a fazer parte do escopo do seu projeto, s\u00f3 que n\u00e3o fazem parte do seu Story Mapping, pois n\u00e3o t\u00eam rela\u00e7\u00e3o nenhuma com o produto final.\u00a0<\/span>Se voc\u00ea usar a “filosofia” da EAP, dar\u00e1 visibilidade para esse novo escopo, para poder gerenciar sua implementa\u00e7\u00e3o. Voc\u00ea pode , por exemplo, criar “cards” no seu board para acompanhar os planos de a\u00e7\u00e3o que foram levantados. Se voc\u00ea usa Scrum, pode ter uma ideia de quantas melhorias consegue implementar por \u00a0Sprint. Se voc\u00ea usa Kanban, poder\u00e1 at\u00e9 mesmo medir o “lead time” de implementa\u00e7\u00e3o desses planos pra ter uma ideia de qual seria a cad\u00eancia ideal para realiza\u00e7\u00e3o de retrospectivas.<\/span><\/p>\n Sabemos que uma vez definido o escopo, seja ele para o projeto, para uma fase do projeto, para uma itera\u00e7\u00e3o, sprint, para um release, ou mesmo numa abordagem de fluxo puxado, no momento imediatamente anterior ao comprometimento com o in\u00edcio constru\u00e7\u00e3o do produto, \u00e9 necess\u00e1rio um n\u00edvel de detalhamento maior do que essas t\u00e9cnicas apresentadas acima oferecem. Ah! Em tempo, se voc\u00ea conhece algu\u00e9m que acha que em \u00c1gil n\u00e3o existe documenta\u00e7\u00e3o, recomende ao estimado coleguinha a leitura atenta da declara\u00e7\u00e3o do manifesto “<\/span>produto funcionando mais do que documenta\u00e7\u00e3o<\/span><\/i>“.<\/span><\/p>\n A EAP, por exemplo, \u00e9 complementada pelo “dicion\u00e1rio da EAP”, que descreve detalhadamente cada um dos pacotes de entrega e seus requisitos. No Story Mapping \u00a0comumente se utiliza a t\u00e9cnica de “Hist\u00f3rias de Usu\u00e1rio”. Mais uma vez, essas t\u00e9cnicas n\u00e3o s\u00e3o excludentes. \u00c9 valios\u00edssimo por exemplo, descrever os requisitos dos pacotes da EAP usando o padr\u00e3o de hist\u00f3rias de usu\u00e1rio.<\/span><\/p>\n Uma outra similaridade entre as t\u00e9cnicas est\u00e1 no fato de que, ao final do planejamento, seja usando EAP ou Mapa de Hist\u00f3rias, a equipe de projetos terminar\u00e1 no n\u00edvel “nuclear” de tarefas. Tarefas s\u00e3o indivis\u00edveis, e s\u00e3o elas que determinam qual \u00e9 de fato o trabalho necess\u00e1rio para que o escopo seja produzido. Definidas as tarefas, podemos parar de quebrar o escopo.<\/span><\/p>\n Como gestor de projeto agn\u00f3stico, gostaria apenas de deixar um alerta: independentemente da t\u00e9cnica utilizada, a tend\u00eancia em escrever contratos, ou detalhamento exagerado dos requisitos de forma textual, pode resultar em falhas de interpreta\u00e7\u00e3o. Esse \u00e9 o tipo do excesso sobre o qual o manifesto \u00e1gil se refere. Se voc\u00ea n\u00e3o entender que o grande valor do mapeamento est\u00e1 na colabora\u00e7\u00e3o, discuss\u00e3o e alinhamento, n\u00e3o importa se usa a abordagem dita tradicional ou \u00e1gil, poder\u00e1 cair nessa armadilha.<\/span><\/p>\n Outro ponto de aten\u00e7\u00e3o \u00e9 que a EAP \u00e9 uma abordagem suficiente gen\u00e9rica para qualquer tipo de problema. Embora eu acredite e tenha acompanhado sua utiliza\u00e7\u00e3o para outros tipos de iniciativa, o mapa de hist\u00f3rias \u00e9 amplamente difundido e testado em software. \u00c9 muito prov\u00e1vel que seja aplic\u00e1vel para qualquer tipo de trabalho do conhecimento, ou seja, aquele que n\u00e3o produz entreg\u00e1veis materiais f\u00edsicos. Esse “talvez” est\u00e1 sendo amplamente discutido e testado atualmente.<\/span><\/p>\n Por fim, ambas as abordagens devem ser encaradas como ferramentas. Um bom gestor de projetos deve construir seu portf\u00f3lio de ferramentas independente de vieses conceituais a apego a uma abordagem ou outra. Dessa forma, poder\u00e1 adaptar a gest\u00e3o de sua iniciativa ao contexto em que ela est\u00e1 inserida. <\/span><\/p>\n Esse blog post \u00a0faz parte da s\u00e9rie Agile para PMPs, PMBoK para agilistas, na qual comparo as principais t\u00e9cnicas de gest\u00e3o das abordagens tradicional e \u00c1gil para que os gestores de projetos possam tirar proveito de uma abordagem h\u00edbrida e agn\u00f3stica. E voc\u00ea, que ferramentas e t\u00e9cnicas tem usado na gest\u00e3o do escopo de seus projetos?<\/span><\/p>\n Abaixo, segue a tabela resumo comparativa das principais caracter\u00edsticas discutidas nesse texto:<\/span><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" SPOILER ALERT – Para voc\u00ea que bateu o olho neste text\u00e3o e achou TLTR (ou Too Long To Read), inclu\u00ed uma tabela comparativa ao final, como resumo do blog post. Divide et impera – Dividir para conquistar. C\u00e9sar, Napole\u00e3o e outros grandes gestores provavelmente n\u00e3o constru\u00edam EAPs (Estrutura anal\u00edtica do projeto) e nem montavam … \u00bb<\/a><\/p>\n","protected":false},"author":66,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[123],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7651"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/66"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7651"}],"version-history":[{"count":15,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7651\/revisions"}],"predecessor-version":[{"id":7674,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7651\/revisions\/7674"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7651"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n