fix img

专栏/微服务质量保障 20 讲-完/18 组织保障篇：质量是设计出来的.md.html

@@ -158,7 +158,7 @@ function hide_canvas() {
 <h3>协同方角色</h3>
 <p>我在第 10 课时“流程规范篇：高速迭代的研发过程需要怎样的规范？”中有提到，产品研发是为业务服务的。业务流程分为 3 个阶段：产品研发阶段、日常运营/运维阶段、售后服务阶段。这三个阶段涉及许多部门角色的协作，包含但不限于产品经理、研发人员、质量保障人员、客服人员、SRE、业务运营人员、法务人员、商务人员、财务人员等。</p>
 <p>下面将对在业务流程中与质量保障人员打交道最多的角色及职责进行讲解。</p>
-<p><img src="assets/Ciqc1F9ggL2ACmL7AABQHv6ZJkU208.png" alt="image.png" /></p>
+<p><img src="assets/Ciqc1F9ggL2ACmL7AABQHv6ZJkU208.png" alt="png" /></p>
 <h4>（1）PM： 产品经理</h4>
 <p>通常来说，需求分为业务需求和技术需求，业务需求由产品经理负责，技术需求由研发人员负责，技术需求占比较少，一般不超过 30%，所以产品经理是主要的需求负责方。</p>
 <p><strong>角色职责</strong></p>
@@ -187,7 +187,7 @@ function hide_canvas() {
 <p><strong>常见问题：协同项目易出问题</strong></p>
 <p>研发涉及多个方向的需求或项目，比较容易出现各种各样的问题。比如多方需求理解不一致、项目排期未对齐、技术方案实现有误、因依赖服务问题导致测试阻塞，等等。上述这些问题的主要原因是，各方向的产品研发测试等人员都只明确负责所在方向的交付内容，对于需求关联处和需要协同的部分，看似都负责，实际上<strong>多人同时负责等同于没有人负责。</strong></p>
 <p>这种情况比较推荐的做法是借鉴 RASCI 工具的思想。比如，有且仅有一个人为整个项目的完成负责，在各子方向需求的产品经理、研发人员、测试人员中也推选一个主 R，职责是在该职责角色内起到横向主导作用。在整个项目过程中，分职能主 R 向项目主 R 虚线汇报，如下为相应的 RASCI 矩阵：</p>
-<p><img src="assets/CgqCHl9ggNOAK7HQAABwTzbiGic297.png" alt="image" /></p>
+<p><img src="assets/CgqCHl9ggNOAK7HQAABwTzbiGic297.png" alt="png" /></p>
 <blockquote>
 <p>RASCI 是一套用来确定责任的表格，RASCI 是指负责、批准、支持、咨询和知情。</p>
 <blockquote>
@@ -273,7 +273,7 @@ I：知情（Informed）需要了解项目相关情况的人。</p>
 </ul>
 <h3>结语</h3>
 <p>本课时我讲解了业务流程过程中主要协同方的角色、职责、常见问题与对策，总结如下：</p>
-<p><img src="assets/CgqCHl9gmzSAdxWhAADU7UHdHwc646.png" alt="Lark20200915-184359.png" /></p>
+<p><img src="assets/CgqCHl9gmzSAdxWhAADU7UHdHwc646.png" alt="png" /></p>
 <p>其次还讲解了质量文化建设相关内容，文化不是纸面上写了什么，喊了什么口号，而是大家信仰什么，比如日常如何思考、如何做事儿。质量文化的价值在于组织成员能够主动、自发地思考质量保障，做好手头的事情。另外，通过领导层重视质量、建立激励制度、质量文化触达等多种方式推行质量文化建设。</p>
 <p>下一课时，我将针对软件测试新趋势进行探讨。</p>
 <blockquote>