关于如何增进有效沟通与表达以及团队与个人成长之间的一些思考

        从一个成员自身去思考“关于如何增进团队内部有效沟通与表达”，目前看来还是个普遍比较尴尬的议题，但是，援引近来很火的一个概念：“去中心化”，我觉得在团队建设上，理应百家争鸣，每一个成员，无论身处哪个层级位置，都无需像草一样，被动等待来自所谓管理层的“风”的吹向；团队建设与管理无需明确的条框界限，对于每个成员应是因才适用，且给予充分空间自由去任其激发才华的，这样的团队，才是一个适合于创业中的团队，才是一个有创造力的团队！当然，这是我个人对团队的一点认识，抛砖引玉而已：

        话归正题，刚才说到，一个执行和创造能力强的团队，我理解，无非会有几个特征：

        1、拥有一批业务经验丰富的老员工，经验就是活导航图，就是实实在在的财富！

        2、有一套科学良性的工作流程体制，为每一个成员无形中进行省力！

        那么我们这个的团队，如今的感到的“病症”有哪些呢：

        1、从leader开始，过半都是新入职不久的员工，对所负责项目的业务背景、服务架构与调用链关系等基本背景信息缺乏了解，在进行测试计划设计、测试实施操作、测试数据采集、测试结果说明等环节时盲区很多，而且这些这些解决方案常常都是应付于一次性的，无法或没有进行沉淀积累，导致复用率低；也导致对开发恶性循环似的依赖过重；

        2、团队内部人员角色不明、分工职责模糊，但又大体按业务项目或某些服务划为各自为战的小团体，互相之间，信息互通性差，最重要，还不便于解耦互助，即有可能导致闲的闲着，忙的忙死；比如说，leader对最忙的人说，我调那谁谁做0.5人来临时支持你，你看怎样？其实这在互相并不了解、并没有配合默契的情况下，实际可操作性是很小的。

        3、缺乏文档化建设与系统化梳理沉淀积累，也许是没有这方面意识、也许是没有时间，这又回到工作安排不合理导致的恶性循环～

        4、对已有的工作流程、工具等全盘传承，这其中，我个人理解，是由于大部分人，普遍存在三个思维误区：

        （1）所谓测试优化，即专指测试工具的优化，比如工具自动化的建设，或者认为这点优先级最高，这好像抗生素一样，只要生病，不管三七二十一，首先想到的就是先吃上两粒！

        （2）对测试工具的开发总是寄予一种能开发出一款适合当下产品的长久高大全的测试工具的希望，认为测试工具优化或自动化后，最好能持续满足版本迭代，且满足尽量全的测试需求场景。

        （3）个人专业技能的成长需要高于对团队建设管理的贡献，认为团队管理是leader一个人的事，leader在给自己排kpi或okr时，也不会提到这些，更何况，如果一不小心当出头鸟得罪了人，还有可能影响团队“和气”、影响自己发展；对于团队公共这块，常常属于被动听从，而更注重，如果有天离开了这个团队，专业技能的成长对自己才是更重要的；公司花了大价钱专门请来的leader，你却参与到团队建设管理上，抢leader的工作，真是百害而无一利！有这个心思和时间，还不如低调地、乖乖地多学两个工具或脚本语言更实际，更能对团队做出贡献！

        以上这几点病症，从人员自身过新过嫩到对工作环境的“盲目”以及现有团队体制无法为成员提供助力的一个困境，我将之命名为“嫩穷困境”！因为这个“嫩穷困境”已经变成了一个恶性毒瘤，所以我们团队内部，包括部门团队之间的沟通与表达，成本变得异常高昂！抛砖引玉，我谈谈自己的观点：

        1、不按问题的顺序，我先说说上面第四点提到的三种思维，在一定程度，是对的，但在另一方面去想，是误区：

        （1）首先说第一种思维，一个任务测试周期总是很长，身处其中的实际操作者也深感需要投入很高的成本，那么几乎大部分人都会围观，是不是该将之自动化？！这样，一来，有了业绩亮点，二来，显得自己在流程优化中确实尽力了，还显出了自己和团队的专业素养。但其实，仔细分析现在导致测试周期拉长、测试结果难产的，工具不给力是致命伤吗？我们可以先从测试结果生成由哪些部分组成来探讨，比如现在的测试结果需要一个这次测试操作得出的准确率值、一个与上次版本测试操作结果对比的浮动差值两个值即可，现有的工具虽然操作复杂了一些，但是还是可以得出结果的，但只是每次进行与上次版本结果对比时，浮动差如果太大，要定位起原因来，十分困难，直接反馈给调用链上涉及的所有开发，但开发们均表示自己这边自测过没问题，而且新版本提测服务的部署暂时也看不出毛病，扯皮半天，可能还会惊动产品层，告知两个版本测试结果偏差太大，这次版本更新无法上线，但肯定还是要上线的，最终可能还是要开发再部一套旧版环境来复现，有可能能复现，但有可能也复现不了...只是反观在这一整套沟通流程中，其实测试所提供的信息非常少，版本对比，只提供了操作结果，却没有去思考，开发提测时会提供自测报告，但得出的结果是版本更新有优化，可以更新，那么你与他之间的测试资源与配置是否一致呢？而且，你每次进行测试操作时，会受到哪些因素影响呢？服务版本记录了，那涉及调用的底层服务的版本与配置呢？测试请求受内网环境影响吗？但这个内网网络环境是只有你独立去使用的还是公共共享的？不同时间段，网络性能会有不同的波动吗？那么不同时间段的网络波动差值你有依据吗？这次的浮动偏差，为什么不能视为可接受的范围呢？为什么又一定认为是不可接受的呢？为什么现在定位复查这么困难、成本这么高呢？所有这些前提条件的思考，好像都与测试工具本身的优劣没有太大关系，而这多个辅助测试结果的维度数据的缺失，却大大增加了复查问题在测试周期中所占的沟通与时间成本！一个不太好的测试工具所耗的操作时间成本与之相比，简直小巫见大巫！所以，一谈到测试优化，首先应该谈到的，绝不是理所当然的工具优化，工具操作只是整个测试流程中很具体的一环，但不能认为扩大它所起到的作用！将整个测试流程乃至多部门间协作流程优化，才是首要，才能让测试工具的优化能够有发挥的空间！比如，搭建一套独立的测试环境、出问题时保留redis、memcache数据等“事故现场”，统一测试资源与配置、统一部署时引用的所有底层服务的版本与配置，再明确浮动差的可接受标准与依据，当然依据也要经过测试论证...所有这一切都协调好之后，再来着手测试工具本身的自动化与平台集成，我认为才是正确的优先级顺序！

        （2）第二种思维，其实这也是误区，测试自己开发工具，也属于一种开发，任何工具的开发都不可能永远满足产品的迭代，没有绝对高大全的工具，越好的工具一定是越精于某一类场景的；但是确实需要解决目前，老的测试工具传承下来，却越来越用不了的矛盾，这个需要具体分析到的是：前人传承下来的工具，有些没有源码，有些源码就是写的很局限，要重构的话基本等同于重写；但是，真正引起工具不能持续满足测试需求的原因，还是由于刚接手的人对业务背景、真正测试需求的不熟悉，其次是没有定义属于测试的编码规范和工具使用的文档化建设。产品在迭代，测试需求的场景在不断丰富多样，所以测试工具也需要不断的进行迭代升级，并做好每次升级的文档规范，这样才能最大程度的满足测试需要和避免交接的断层。

        （3）第三种思维，同样，对，也不对！一个测试工程师，究竟需要具备哪些素质和能力，其实需要在不同层次去区别考虑，职业规划这个东西本来也因人而异，没有绝对的对，只有在当下适不适合！但是，我认为，结合到第一点谈的，做一件事情，规范上层的体制流程建设要比过于注重具体节点的发展更为首要，因为两者是相辅相成的，团队与个人如果都好，那么是良性循环；如果有一方很掉链子，那么就会造成恶性循环。感受到了问题，如果过于观望、或明哲保身，这最终很有可能造成的是不欢而散，作为团队，永远留不住老员工，作为个人，对团队心里总是不能认可！除了专业技能、细心负责踏实的品质外，还有什么是越来越被需求但比较隐晦又比较难以培养的能力呢，我认为是：对一件事情的主动梳理和推动能力！这涉及到每个人自己的处事方法论的提炼，但其实每个人处事都已有现有的一套方法论标准，只是可能自己还没有意识到，但其实这是非常重要的一个能力！每个人，来到这个团队，都会有在这个团队获得成长的渴望，就好像团队对你也有能更好尽职的需求；手动测试希望在专业技能上成长，比如发展成为自动化测试，那成为自动化测试之后，就能一应百全了吗？结合第一点，自动化只是手段，还是要建立在对业务、对流程非常清楚的前提下，专业技能和良好的个人品质地投入付出，在团队层面，才能产生价值和意义！这一切的前提，都需要，首先拥有对一件事情的主动梳理和推动能力！梳理能力和推动能力又是两回事！不要认为这两个能力，对职业发展没什么实际帮助，之前我思考过另一个职业发展困惑：手动测试向自动化测试和测试开发方向提升，但是测试人员来进行开发终究普遍编程能力和规范，甚至比不上科班出身的专职开发实习生，那么你拿什么来区别自己不被替代呢？有人说是工作经验，但工作经验常常局限于业务背景，业务不同，你的工作经验排不上用场，但对一件事情的主动梳理和推动能力，却是绝对可以受用终身、任意移植运用的能力！在一个团队，学到了它们，对自己职业发展规划的帮助效果，不说更大，至少可以视为等同！

        2、如果你已经与我在前面的观点中达成了一定的一致认可，我想接下来，我们可以就上面所提的其它“病症”来谈谈对应的“药方”，这也作为今天讨论的主题：“如何增进有效沟通和表达”的“药方”！

        （1）将分享落地成长效机制，我们目前有很多专业测试技能上的分享需求，但眼下首当其冲必须是业务与服务调用链拓扑图的梳理分享。一来明朗化我们目前的业务盲区，让我们建立一张共同的全景导航图，是多么重要！二来，可以规范并统一对同一事物的命名称谓，为提升团队协作默契打下基础！三来，解决被测试工具混淆误导成对服务本身的认识的尴尬。比如一个请求要调用三个独立的基础服务，但测试工具直接封装成一个jar包和一些脚本了，所以我们在别人问起调用关系或我们遇到阻塞要去求助时，却无法向别人进行正确的描述，因为你都在描述测试工具客户端在完成的逻辑，而不是真正服务关系本身～

        （2）提升团队会议的真正价值，避免开“个人宣讲式的僵尸会“，尽量多提与每个人切身相关的议题，或者将会议粒度与周期再细分，团队会议，最直接的目的，其实是为了更好地量化把控对排期的进度情况！

        （3）注重沟通与表达的严谨！第一，沟通的严谨。测试，无非验证输入、输出是否符合预期，即使业务背景都了解不熟或直接了解偏差了，但是对于输入、输出的验证是一定要做的，不仅要关起门来自验，还要向开发、产品等涉及环节进行确认，确保理解一致，输入、输出确实是一致认可的预期，才能对一次测试给予测试通过的结果，用沟通来保证严谨，才能至少在态度上，是被别人尊重和认可的！第二，表达的严谨。在表达时，我们常常希望能在别人最短时间内，明白你要表达的意思，并且能另他也在最短时间内给予你帮助。这个最短时间，其实可以理解为，少走误解的弯路。怎样少产生误解呢？举个例子，我对内网维护较多，内网下某个服务挂有好几个节点，我都能清楚地区分，但是有天有个该服务的调用者，直接问我，”内网现在可用吗？“这一下子会让我产生困惑，因为内网下面现在挂有该服务好几个节点，空闲使用情况不同，我不知他具体所指哪一个，但其实他在实际操作时，是会配置的，即他是明确知道他想用的是哪个节点，但他没有直接问我”那个xx节点现在能用吗“，这就会造成沟通成本，有时会因此耽误很久，有时还会造成协作的不愉快，有时甚至让对方误解为暂时没有可用节点，这个任务需要因为环境原因被delay~可见，严谨地表达，问题是多么隐蔽却又影响多么巨大，不严谨地表达，有时会让听者理解的不深，从而轻易拒掉你的提议，或耽误你应有的进度。

        （4）文档化建设的重要性与好处，我想不必多说了吧！

        以上均属我对一个团队陷入某种恶性循环的困境后，如何首先增进有效沟通与表达，以及自己对于一些团队与个人成长之间的思考！在即将到来的年末，梳理自己的技术、工作等多方面的”债务“，再利用上面的观点，去好好做一次总结吧！

        

转载于:https://my.oschina.net/changeClown/blog/804030