管理浅认知
很多时候，我们对管理工作的一般的认知带几个员工，对上做到及时汇报，对下提出目标、制订计划、检查反馈并进行改进，就是所谓的PDCA循环（PDCA循环的含义是将质量管理分为四个阶段，即Plan（计划）、Do（执行）、Check（检查）和Act（处理）），以此达到总体的目标规划。
于我而言，这是我们常说的纵向管理分支，今天我想来谈的是横向的管理。
横向管理是指管理除内部人员外的其他人员（如开发人员、需求人员、设计人员），与这些人的对接既是沟通也是管理，下面画了一个模型，浅显易懂。
本篇故事内容针对与开发人员的经典案例，我应对的方案及办法，有时候处理办法不固定，找到适合自己的就可以。
小案例
故事一 没动静
前几天，已上线的系统有一些数据问题，因为需要对接多个系统间的数据，我们去客户现场大致过了一遍所有系统，回来后将整理好的Buglist同步各PM。
然而第一次沟通反馈的状态就大不相同：
PM_one : 处理完了，马上可以测试，实际效果有一些问题还没进行落实。
PM_two：处理了一部分，80%，下周可以进行回归，实际确实这样。
PM_three：知道这个事，还没处理。
针对PM_three，第一次只是简单沟通了下有这个事需要处理，希望提上日程。
过一周之后，针对我的Buglist第二次沟通，加了一列开发状态，再次同步。
一是对我的问题进行了修改；
二是对工作起到了推进作用。
当我二次进行沟通后，Bug状态进行了变更，达到了我想要的效果。
我们都知道，在整个项目管理过程中，影响质量的因素有3个，分别为人员、过程、技术，其中人占主要因素。
如果能管理好人，基本就解决了90%的问题，对于沟通后无反馈、无结果的项目，最好的办法及时跟踪，心里要有所预期，不可能一次就能达到效果。
故事二 未同步
前几天测系统首页的功能（对数据），测之前跟开发A确认了一下可以进行测试。
中途我跑去写了两天文档，再进行测试时（首页数据和其他开发有接口），问了一下开发B数据来源，得知现在的数据是假数据，沟通确认后问题得到了证实，当前新版本进行了变更。
这个问题的原因是计划赶不上变化。人员不足、有突发事情时，自己手头的工作暂停，就无法保证按照计划进行，也无法保证进度。
信息同步不足，自己管理自己的工作，没有想到后续流程。深层次剖析原因：我们部门缺少流程，一切还处在以人为核心的工作模式，没有监督，缺少管理。
故事三 拖进度（老油条）
跟一个人打过交道几次后，你就知道这个人的办事风格是什么样。最近，线上系统Bug提交后，我查看了下修改进度，开发A的备注是这样：
【未复现】
【未排查到空数据】
一旦看到这样回复，就知道接下来的流程：交给测试整批量验证，再反过来沟通，这么来来回回至少浪费半个月，如果再遇上同样态度的开发还会再给打回去。
如果一直这样的话，这种问题还用解决么？
对于Bug管理系统来说，正常流程可以这样做，但是对于线上问题来说不可以。
很多开发人员拿到提交的Bug，基本都会核实到底是测试问题还是程序问题，而不何核实直接打回来就是态度问题，这种态度有问题的人，我把他们称为“老油条”。
对于这种老油条，我的解决方案是：和这类员工私下沟通，交代一下再遇到这种事情直接跟我核对，沟通无效果再向上反馈。
这也是一种管理，让事情按照你预想的方式进行，管理过程中沟通非常重要。最近的感悟：即使你不在管理岗位上，只要能干成一个多人配合才能完成项目，就算是攻克了管理的难点。
故事四 不熟悉
某一天，需要测试某块功能，开发人员发现代码非最新，于是要发个新包给我，经历过多次验证，等到新包安装成功，已经过去了大概5个小时。
这次因为开发人员不专业而造成时间浪费的乌龙事件，据我观察有下面几个原因：
1、由于技术更换，发包或环境问题基本就一个人了解，当这个人不在岗情况下，就会遇到阻碍。如果换做我，我会定期安排培训或者让负责人将过程梳理成文档。
2、职责不到位，一般大公司会有专门的发版人员，也就是发版这个事给一个人做，不会中途更换他人。
3、站在个人角度，我可以容忍对方技术不到位，但认真的态度必须有。对于团队来说，人和流程是主要的，技术为辅，因为技术可以通过学习提升。
总结
以上仅仅是和开发沟通中的一角，比较有代表性。
对于横向管理来说，管好自己的事情是最基本的一步，而管理和自己平行岗位的工作和人值得每个人慢慢探索，我一直在路上。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
