![\"deployment-foundation-issue\"](\"http:\/\/www.scmgalaxy.com\/tutorials\/wp-content\/uploads\/2010\/02\/deployment-foundation-issue.png\")
<\/h2>\n<\/h2>\nThe very first order of business is to firmly establish \u201cwho\u2019s on first\u201d for getting deployment done. Senior management is crucial at this point for making sure all their direct reports and managers are on board with this
\nand that it comes from the top. I mention this because at one place I worked, we immediately got into interdepartment squabbling due to a lack of senior management support and direction. If you hear a manager
\nsay things like \u201cdo what you want \u2014 but don\u2019t touch my area,\u201d you will have deployment problems. I strongly recommend the formation of a process group as the focal point for all matters related to process and process deployment. This group has to have both the authorization and responsibility for process. If you have a distributed set of \u201cprocess owners,\u201d consolidate that responsibility and authority to this new group. My requirements for membership in this process group are:<\/p>\n
Six to eight people. Larger process groups tend to be less efficient and more cumbersome. A smaller group tends to be ineffective. It is not necessary to have representatives from all corners of your organization. It is important that these domain experts get called in as necessary for process development and inspection. One company had a 15-person process group established by a non\u2013process-oriented vice president. It was a disaster to get a
\nrepeatable quorum present for any meeting. We spent subsequent meetings repeating stuff from earlier meetings to accommodate a different set of participants at every meeting.<\/p>\n
Process-group commitments. My most successful process group was when I insisted that members commit 5 percent of their workweek to process-group meetings. Group members and their managers had to sign the commitment. The 5 percent figure is doable \u2014 even for busy people. Two one-hour meetings per week reflect that percentage. I also had fixed time meetings both by time and day of week. It became automatic to show up. To make this really work, I was the process-group lead and I dedicated 100 percent to this effort. I had clerical support services available to me. The most effective process-group meetings are concentrated sessions
\nwith a time-stamped agenda and where my support staff and I do all extracurricular activities. You want to restrict extra time (beyond actual process-group meeting time) needed by your key process participants because they tend to be super busy.<\/p>\n
Showing up on time. We could not tolerate people wandering in five or ten minutes late. We started promptly on the hour and stopped promptly on the hour. At one company, I removed a person for being late because it held everyone up. Promptness became so important at one commercial company that other process- group members would be \u201call over\u201d tardy people. The tardiness stopped quickly when peers got involved in any discipline.<\/p>\n
People who are process oriented. Do not have people in this group who don\u2019t fit this requirement! At one company, a vice president insisted on naming people to the group (which became double the size I had wanted) who were almost completely ignorant about process. We spent almost all our precious process-group time just getting these people to understand the most fundamental aspects of process. It was painful. The VP wondered why progress was slow. Duh!<\/p>\n
People who are opinionated \u2014 i.e., not afraid to speak up on issues. You cannot afford to have people just show up and suck air out of the room and not participate. The best processes I\u2019ve developed came from sessions where it was not clear who would walk out alive after spirited process discussions.<\/p>\n
People that others look up to. They may be leads or workers. Every organization has these types of people and they may not be in the management ranks. The reason for this requirement is to form an initial set of process champions right out of the box. These initial process champions will develop more champions.<\/p>\n
People who are willing to have an enterprise perspective versus an organizational perspective. This could be a huge problem if process- group discussions degenerate into preservation of turf \u2014 no matter what. At one place, I actually went to a paint store, bought disposable painting hats, placed a big \u201cE\u201d for enterprise on the hats, and made process-group members wear the hats at our meetings to reinforce that enterprise focus. It got a few laughs and some grumbles but it worked.<\/p>\n
People who are not \u201cwho\u201d oriented. A process group avoids the \u201cwho\u201d question and concentrates on the \u201cwhats.\u201d Once the \u201cwhat you have to do\u201d is addressed, the \u201cwho\u201d looks after itself. When process-group meetings degenerated into discussing \u201cwho does this\u201d and \u201cwho does that,\u201d I routinely stopped the meeting and reminded everyone that when you have a hole in the bottom of the boat, this is not the time to discuss whose hole it is! I got laughs but my point was taken.<\/p>\n
This is your key group for process development and deployment. It\u2019s obvious, but if you have this marvelous group put together without regard to an overall process architectural goal, you will fail. This is where this software process model will help you enormously. Ideally, the processgroup lead has an in-depth knowledge of the targeted process architecture with an initial goal to get the process group up to speed on this aspect first \u2014 before any company processes are tackled. If you are under pressure to \u201cjust get on with it\u201d (without getting all process members up on the target process architecture), you will fail. You will end up flailing around for a large amount of time. You will also end up with a hodgepodge of process elements and no encompassing architecture. You want to end up with a hierarchy of goals supported by tasks that are measurable for earned value and progress reporting by the process group itself. Essentially, you want to create a balanced scorecard for process progress. This makes your process group accountable for progress just like any other project team.
\nFor deployment success, I will repeat an important division of labor within the process group itself. You absolutely need to develop advocates for the process framework architecture itself and make sure the integrity
\nof the process model is maintained. This book will be invaluable for that aspect. These people are very different from most process-group members, who should be domain experts. The process framework advocates are
\nthe folks that put the \u201cmeat on the bone\u201d for process and they will make sure that the process parts all fit within that framework architecture, whereas the domain folks make sure to develop process elements that are useful and make sense.<\/p>\n
I make this point because uneducated management personnel may pressure you to \u201cjust get on with it\u201d without considering the importance of making sure that all process elements fit within a framework architecture.
\nThe worst thing you can do is crank out process into an ever larger pile of stuff that increasingly gets more and more useless for the organization. The main litmus test for process is that it is useful. I have run into
\nmanagers who seem to think that bigger piles mean success. In reality, you may have just the opposite result. Resist those who are pushing you in that direction for success. The most successful process group I led was when I was not only the lead but also the process architect and had management backing to do what was needed. I mention management backing because at another place, I had the exact same situation but had a boss who was so insecure that all my suggestions and recommendations were either ignored or rejected because they didn\u2019t come from him! Anything from me was dead on arrival. If you\u2019re ever in that position, run, don\u2019t walk! You cannot succeed. There are people like that out there and (sadly) some are in senior management positions. I simply didn\u2019t want to manipulate him to have him believe that all ideas were his ideas. That\u2019s what it would take
\nto deal with this kind of person.<\/p>\n
When actually doing process deployment for the software process model, there is one how-to procedure that absolutely needs to be addressed early on: the inspection procedure. This particular procedure is fundamental to
\nall the activities within this software process model as a quality gate. If you have a lousy how-to procedure here, you will have an awful time in getting people to buy into this model. Conversely, a good how-to will
\ntake off like wildfire and become engrained in an organization real fast. The software process model wants quality built in the \u201cwhat you have to do\u201d world by placing the quality responsibility on the producer\u2019s back.
\nThe inspection procedure is critical to this end goal. I worked at one place that had a \u201creview\u201d procedure in place. It was hardly used, did not work well, and the management protected it with
\ntheir lives. I had the gall to suggest a better way of doing things. I had to present this new way at three different hearings to this management group, finally receiving a disposition of \u201crejected.\u201d They could not handle
\nthe fact that this software process model allows for better mousetraps. Both methods could coexist in this model. I knew that once the better way was an option, the bad way would drop off for usage very naturally.
\nThese managers had a personal and vested interest in preserving the status<\/p>\n
quo \u2014 regardless of usefulness. They had invested time in the existing process element. They wanted no interlopers on their possessive world. This company was very closed in their thinking. Consequently, we had
\nno effective inspection procedure at this company and had a huge management barrier to ever getting a better way proposed or deployed. This same company has the same ineffectual review procedure in place
\ntoday that is really bad and is barely used. Go figure! In another job, I had the privilege of working for a section of a very large company and had incredible support from the head person. In that
\nenvironment, I was able to provide this part of the company with a slick, efficient, Web-based inspection procedure that was up to ten times faster than the existing inspection procedure. My new inspection procedure also
\nproduced higher-quality inspections and had built-in defect prevention to boot. What happened was incredible. The word spread like wildfire within my own group about how great this procedure was. That worker enthusiasm spilled over to other organizational elements that clamored to get onboard with our solution. I was deluged with training requests and guest appearances to various \u201call-hands\u201d meetings regarding this way of doing
\nthings. I didn\u2019t have to do a thing to sell this. It sold itself. I knew that the software process model approach encourages better ways of doing things and encourages variances in scale or location quite naturally.<\/p>\n
\u0002 Every activity at the \u201cwhat you need to do\u201d level has built-in inspections across the board (i.e., the inspection procedure is a how-to elaboration on all the \u201cInspect\u201d verbs in all activities).
\n\u0002 A bad inspection procedure can have a huge detrimental effect on all activities\u2019 elapsed completion times. Conversely, an efficient inspection procedure can vastly improve activity execution times across the board.
\n\u0002 A good inspection procedure increases work product quality and reduces rework. Rework is expensive and should be avoided at all costs.
\n\u0002 A good inspection procedure gives you the basis for defect prevention \u2014 in addition to defect detection. With the software process model, you now have the ability to ask, \u201cWhere should this defect have been found?\u201d This provides the mechanism to improve any earlier inspection checklist associated with any earlier work product. With this inspection procedure you have a built-in process-improvement mechanism in this software process model.
\n\u0002 Finally, an efficient inspection procedure will be used and will become part of the company culture. A bad one will not be used.<\/p>\n
Get at Pain Issues<\/p>\n
To be successful with process deployment, you really want to keep coming back to pain issues for any organization. The big question is, how do you do that? And how do you do it so that the data is believable? This
\nis independent of the type of process model you\u2019re using. You will achieve higher levels of buy-in from all levels of the company if the perception is that you\u2019re solving real-world problems. If you separate
\nprocess initiatives from \u201cpain\u201d issues, you will get a lot of cold shoulders about this process stuff. An absolute killer is to tie process initiatives to a maturity model (like CMMI) in a vacuum. As I mentioned before, a
\nparticular model or standard can be viewed as the flavor of the month. Some people may view all this with an \u201cif I keep a low profile, this too shall pass\u201d attitude. There\u2019s nothing like solving real problems \u2014 especially
\nif people can reduce their 60-hour weeks to something more reasonable. I learned one big lesson when I got married \u2014 don\u2019t discount the power of a spouse! As Dr. Phil has said repeatedly, \u201cIf Mom\u2019s not happy, no one
\nis happy.\u201d For most employees, you really have a shadow employee to deal with as well \u2014 the employee\u2019s spouse. If the employee can get home earlier, play with the kids more, do family things more, etc., how
\ndo you think that family unit is going to support you? Do you think you\u2019ll get early support for your next process initiative? The people part of process improvement can be enormous as a huge positive factor or a
\nhuge negative factor. The process group needs to come to grips with this aspect of deploying new processes in an organization. It is not enough to have a marvelous process framework architecture into which all the
\nprocess parts fit nicely. Personal interviews have mixed results for actually getting at pain issues. Can you be trusted as an interviewer? Will the person being interviewed be forthright or will he or she give you politically correct data? Will there be retribution if he or she dares to be totally honest? For these reasons, I would not get process problem data this way. Two companies where I worked tried the survey route. In my opinion,
\nsurveys are best suited for getting simple check-off answers to specific questions. They are not suitable for open-ended responses. I still laugh at a British sitcom called \u201cYes, Prime Minister,\u201d where you can organize
\nsets of questions and get a totally opposing poll result based on the question set \u2014 even by surveying the same people. My point here is that polls and surveys can be manipulated. Busy people tend to kick and
\nscream about surveys and certainly want to get them off their plates as fast as possible. This means that open-ended surveys don\u2019t end up with a lot of useful data. For these reasons, surveys are not the way to go.
\nAs an adjunct for getting at pain issues, always leave the door open for having process practitioners critique or suggest things directly or via<\/p>\n
I have used two of the 7 M tools (modified somewhat) very successfully to get at both enterprise process pain issues and project pain issues (as a project postmortem). These two techniques have fancy names:<\/p>\n
\u0002 Infinity brainstorming
\n\u0002 Interrelational digraphs<\/p>\n
I don\u2019t use these terms when I conduct these techniques \u2014 I just call them \u201cfocus groups,\u201d \u201caction groups,\u201d or \u201cpostmortem.\u201d Using fancy terms will turn people off. Don\u2019t do it. A focus group is fast (it usually takes
\nless than two hours) and is totally anonymous (no retribution). This particular technique levels the playing field for quiet, introverted people versus loud, dominant people. That quiet, shy person may be the very
\nperson with a lot to express anonymously. The most successful focus group in my experience was done with about 35 people in a single session of about an hour and a half. At this point, you\u2019re probably thinking it\u2019s impossible to have a successful session with 35 people. Conventional wisdom says the success of any meeting is conversely proportionate to the number of attendees. The higher number of people produces lower success. The lower number of people produces the higher success. This technique is just the opposite. You need at least 12 people to be successful. A small group simply won\u2019t work for this technique.<\/p>\n
Here are the supplies needed to conduct these sessions:
\n\u0002 Large Post-it notes \u2014 enough for about 20 Post-its minimum per participant.
\n\u0002 Butcher paper or flip-chart paper \u2014<\/p>\n
these are taped to three walls of the conference room. Four or five charts are taped to one wall. Five to six charts are taped to the opposite wall. One chart is taped
\non a third wall (for infinity brainstorming rules). One chart will be used to capture the major impact analysis after we collect the data from the infinity brainstorming part of the session. The size of the room will affect how many walls are actually used. No matter what, you need two walls for charts.<\/p>\n
\u0002 Masking tape for the large paper sheets above.
\n\u0002 Fine-point felt pens \u2014 enough for participants and facilitator.
\nYou need a large conference room that will hold all the participants and has wall space onto which you can tape large paper charts on three walls. Reserve this room for about two and a half to three hours to allow
\ntime for the facilitator to set up, for the actual session, and for wrapping up. The participants show up about half an hour after the room\u2019s reserved start time. At that point, all supplies should be out and the paper should
\nbe up on the walls. This is what you need to do ahead of time:
\n\u0002 Write down the session rules on a single chart. The rules are:
\n\u2013 One finding per Post-it
\n\u2013 You can write as many Post-its as you want within the allotted
\ntime
\n\u2013 Use only the supplied fine-point felt pen for writing
\n\u2013 No handwriting \u2014 print your finding
\n\u2013 No names (i.e., anonymous)
\n\u2013 Don\u2019t get personal \u2014 it\u2019s process related
\n\u2013 Be businesslike (not crude) in your remarks
\n\u2013 Make finding clear as to your intent: Can another person understand
\nyour point?
\n\u2013 Be quiet when writing findings
\n\u0002 Take a few minutes to explain what you will be doing to the assembled group. Make sure the group knows about your expectations and desired results. I have even put this in written form and sent it to the group ahead of time to make sure that everyone is onboard with this technique. This sets the foundation. (5 minutes maximum)
\n\u0002 Announce that participants are to write one finding per Post-it note on as many Post-it notes as they want \u2014 within a ten-minute time frame. This is a totally quiet part of the technique. After writing,
\nparticipants take their individual Post-its and stick them onto one wall\u2019s paper charts. Random placement is in order. This part actually creates all the pain issues as experienced by the participants in a
\nnonretributional way because no names are used. (10 minutes maximum).<\/p>\n
\u0002 Explain that the findings should be placed into \u201clike\u201d groupings by placing Post-its from one wall into Post-it groupings on another wall. Like things should be clustered together; some adjustments
\nmay need to be made later. Also point out that there is a predetermined category called \u201corphans.\u201d (When conducting a project postmortem, I add a \u201cgood\u201d category for the things we did right
\non a project.) Forget trying to establish any category names. (About 1 minute)<\/p>\n
\u0002 Have everyone stand up, grab a pile of Post-its from one wall, and place them on another wall as Post-it clusters. Remind them that once a finding is placed, it can\u2019t be removed. Some talk among
\npeople can happen at this point. If you do this correctly, you will try to limit the category clusters to about 10\u201312 groups at a maximum. Have orphaned Post-its be placed under \u201corphans.\u201d
\n(About 10\u201312 minutes) \u0002 Identify a \u201creader\u201d from the group. This individual will read the Post-its to the entire group and possibly rearrange some Post-its. (About 1-2 minutes)
\n\u0002 Have the reader stand up and read each Post-it finding in each cluster out loud. This accomplishes the following:
\n\u2013 Everyone gets to hear all the findings.
\n\u2013 Everyone gets a chance to persuade the reader to remove a
\nPost-it if it is not in a \u201clike\u201d group.
\n\u2013 Finally, the group establishes a mailbox name for each cluster
\nof Post-its. Keep the name short if possible. (For project postmortems,
\nI found that using the names from one project as predetermined names for subsequent postmortems was helpful for metrics data. However, one group disagreed with this and felt it was stifling to have a set of mostly predetermined names, especially when they disagreed with an earlier group over those names.)
\n\u0002 The reader repeats this for all Post-it clusters until all cluster groups have category names. During this time frame, some Post-it notes may be moved from one group to another. Finally, an attempt is made to place any and all orphaned Post-it notes into a named category. If not, they stay as orphans. This part takes the findings and attempts to categorize them for the interrelational digraph part of this technique. (15\u201320 minutes)
\n\u0002 The moderator takes a large blank matrix and writes all the category names down the left side of the matrix and then writes the same set across the top of the matrix. The moderator shades out where
\neach category intersects with itself. You should end up with a diagonal line of shaded boxes from the top left down to the bottom right in that matrix. This is the foundation for the interrelationship digraph. We want to end up with some idea of what we need to work on first, second, third, etc., to get the biggest bang for the buck in process. (About 2 minutes)<\/p>\n
\u0002 The moderator reads each category name down the left side of the matrix, and asks for each, \u201cFor this category, what are the other categories that have a major impact on it?\u201d The group participates in identifying other categories that have that major impact. The moderator simply places an \u201cX\u201d across the row for that targeted category. This gets repeated for each category name down the left until done. (10 minutes maximum)<\/p>\n
\u0002 The moderator tallies up the number of \u201cX\u201d marks per column and writes the totals at the bottom of each column. This provides a good idea of what categories should be attacked first that have the most impact on other things. (About 2 minutes)<\/p>\n
\u0002 Thank the group for their time and dismiss them.<\/p>\n
Is this a perfect technique? No. Is it fast? Yes. Does it get at process pain issues? You bet. By spending about one and a half to two hours on this, you will extract pain issues from everybody. There is no retribution
\nbecause there are no names involved. The quiet person can write stuff down anonymously just like the extroverted person can. The inputs come from the very people seeing and suffering from those pain issues.
\nWhat I have done after the session is to record all the findings by category into an Excel spreadsheet. This is a great application for counting things and coming up with percentages. This completed spreadsheet gets
\nsent back to all the participants immediately. I have cautioned this group to keep this data under wraps because it is confidential. The next step is to convene a senior management meeting to go over
\nthe findings and categories. The senior staff needs an understanding of what went on and that this technique gathers data rapidly. As a moderator, take the top three categories in particular and concentrate on those for
\nthis senior management group. This is done to:<\/p>\n
\u0002 Acquaint the senior management on pain issues \u201cfrom the trenches\u201d and in a written form (not sanitized)
\n\u0002 Identify the top three categories that, if worked, should give the biggest bang for the buck in improving or removing pain issues
\n\u0002 Have this top-level management group develop an initial plan to attack the top three categories (or a subset of them) Finally, I arrange for a feedback meeting with all the participants, so that a member of senior staff:<\/p>\n
\u0002 Tells participants that management has heard their pain issues<\/p>\n
\u0002 Informs participants on the plan to attack pain issues This feedback meeting can be powerful to all involved. It closes the loop with participants and makes them feel like they have not wasted their time. It involves senior management directly with unsanitized pain issues. They can\u2019t say they didn\u2019t know about this or that. There\u2019s no place to hide. They have to do something about it. It does cause action. When any improvements are made, you will keep going back to these pain issues. You don\u2019t tell the rank and file that you\u2019ve now satisfied the first goal of some part of the CMMI! They will not relate to that at all. Tell them that these processes directly address the pain issues that were established. When regular folks get to see less pain, you will rapidly develop more and more champions to your cause. If upper management sees smoother operations, better quality, smaller time-to-market costs, better repeatability, etc., which all contribute to a healthier bottom line, you will get more champions at that level. You can do this periodically to see how you\u2019re doing. You can do this
\nas part of a preappraisal drill for process maturity. You can do this as a preaudit drill. The periodic approach will give you some powerful metrics related to pain issues. There\u2019s nothing like solid numbers to show your
\nworkforce that you are serious about reducing workforce pain.<\/p>\n
This may be obvious but you really need to provide that top-level lifecycle framework into which to fit all the process pieces being developed. Without that top-level picture, there is no cohesive way of creating process
\nelements that \u201cfit\u201d into anything. One vice president I worked for insisted on forming various Process Action Teams (PATs) to get some deployment items done without this in place. I was even ordered to get these groups
\ngoing despite my strong objections. The results of this VP\u2019s order were absolute chaos and a huge waste of time. I sure hope none of you will deal with some of the characters I\u2019ve had to endure for process development
\nand improvement! People like that are out there. Some of them even get promoted! Hopefully, the top-level life cycle has been developed before insertion takes place. You can do a subset top-level life cycle if your initial
\ndeployment efforts only deal with that part of the overall life cycle. For example, if you are attacking proposal-related processes, you can get away with just developing the proposal part of your life cycle. The bottom<\/p>\n
line is that you absolutely need a framework into which to fit any process elements, so that you develop once and don\u2019t need rework. With that top-level life cycle laid out with PADs per life-cycle phase,
\nyou now have the ability to tie your pain issues to activities and to associative procedures. You also have the ability to tie event-driven procedures to any and all life-cycle phases.<\/p>\n
Reference: Defining and Deploying Software Processes<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"
Deployment Foundation Issues Establish Key Roles\/Charter for Deployment The very first order of business is to firmly establish \u201cwho\u2019s on first\u201d for getting deployment done. Senior management is crucial at this point for making sure all their direct reports and managers are on board with this and that it comes from the top. I mention…<\/p>\n","protected":false},"author":1,"featured_media":4173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_joinchat":[],"footnotes":""},"categories":[5633],"tags":[3601,3599,3600,3598,220,3596,3595,3602,1128,1705,3603,255,351,1509,3597,293],"class_list":["post-157","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aws","tag-deploy-foundation-errors","tag-deploy-foundation-issues","tag-deploy-foundation-problems","tag-deploy-your-foundation","tag-deployment","tag-deployment-foundation","tag-deployment-foundation-issues","tag-deployment-foundation-problems","tag-foundation","tag-inspection","tag-inspection-procedure","tag-issues","tag-problem","tag-resolve","tag-software-processes","tag-troubleshooting"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/157","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=157"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/157\/revisions"}],"predecessor-version":[{"id":4175,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/157\/revisions\/4175"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/4173"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}