根据要修改的数量，可能这样修改的时间可长可短。但是新的问题又来了，当程序员拿着改好的程序去交差的时候，项目经理又开始指点江山了，当然了期间居然还有遗留忘记的问题未修复，当然，还经常由于修改而引入了新的问题。于是：你这个东西你自己都不用一下么?怎么会这样!这样要返工的啊!(反驳：我刚才没改这里…￥……%&#)当然了，还是得改，再深究，还有好多的问题，被项目经理“追求完美”的眼光所识破，于是，整个程序又经历了长达大半个月的施工大功告成了，但处处有着未知引入的种种问题。
也许你会说改项目的时候用重构，再用测试去保证自动验证，再……，但是现有的框架或许根本不是那块种菜的沃土，现有的团队，压根就没有所谓的测试技术予以保证。
从以上的示例中我大致抽检成以下几种：
用户体验
项目也许正朝着“良好用户体验”的广告上靠拢，并高谈阔论之，但实际上这些“用户体验”又仅仅只是某些人的主观判断，当然在美上，人人都有发表意见的权利，但却不是每个人都能做出最后的决定的。
规范规格
没有明文规定的内容大有死无对证的隐患，造成的冤假错案，更是诸多其他问题的根源。因为一直在强调是管人的艺术，而人是有思想有主观能动性的行为体。被“冤假错案”搞得一头雾水的人，可能会上产生恐惧或排斥的心理，这种心理对于管人的艺术是不和谐的，但饮水思源，问题是谁造成的呢?都归结为那个项目经理么?不尽然，更具体地说是管理策略上的不严谨造成的。
技术变革
有效地团队沟通是团队管理中必不可少的组成部分，而以上案例明显没有做到有效地沟通，或者也可以理解成规范规格的非标准化所导致的。
事情发展到这里，海外团队已经开始进入年度旅游计划了，而国内的团队，如果没有新项目，则在接受用户的意见，当然可想而知，改是必然的，当然海外团队返工的可能性也不是没有，但问题是他们的产品已经事先和用户达成了“一致”(由于用户可能在需求阶段也是被软件团队搞得一头雾水导致也不知道定夺的方案是不是产品的效果，但这样的成功率相对于后者，则普遍高多了……)大陆团队呢，如果需求做得业余，则问题将会大量出现在业务逻辑和用户体验环节，这方面所带来的影响对整个项目都是致命的。项目成本变得不可估计，很有哪天用户不满意了，一切就得从头开始，而所有的错误都发生在一开始的“假设”上。大陆团队总是假设自己的需求以及实现对用户来说是如此地easy，大陆的用户又经常是逆来顺受的类型(见不多识不广，再加上可能是长期合作伙伴的关系，因此更能“适应”那种糟糕的体验)，而大陆的团队则认为他们的东西用户都是“没有意见”的，因此愈发他们的自大和自狂……，当然这绝不是大多数软件公司，但起码我相信是一部分。
大陆团队
现在的团队已经疲惫不堪，项目经理认为手下都是废物，一点小事办不好(相反，自己做的东西则如此地美好，沾沾自喜中……)
手下：嗨，做的又都改了，高傲型的，则愤愤不平，你做的那也叫用户体验，落后;逆来顺受型，嗨，下次多注意(开始扭曲自己的主观判断，并开始谨慎行事于未来的项目)
关系：本来和谐的办公室出现了隔膜。
这也难怪人家说外国人思想比较简单，而中国人，思路太复杂，这样看来，社会因素是导致这一复杂关系的根源，这种不利的沟通则成为团队中的不和谐音。而管人的艺术遇到这样的音符将显得死气沉沉。
文章来源于领测软件测试网 https://www.ltesting.net/
