软件开发周期----如何提高软件开发质量----论团队管理的非技术性因素（part 2）

    本来昨天就准备把这个题目全部内容写完，但因为手机罢工日久，需要单独呵护，所以只能把后半部分移到今天来写。此次分割纯属本人安排不善导致，不代表探讨内容的自然分割。:)----软件开发周期----如何提高软件开发质量（part 1）

    昨天的探讨先从一些公司对提高软件开发质量的错误看法入手，引出了开发周期质量提升的其他非时间控制因素----团队基本技能、团队协作能力，团队行为意识。在讨论每个因素的同时，也结合自己的多年工作中的经验提出了自己的一些解决办法。最后stop at于过程控制阶段中的第二个重要因素----快速解决疑难的最佳方案是交流。

    now continue....................

    （.....2、问题快速解决或确认的最佳方式是交流。............）

    任何一个team在任何一个项目的开发过程中都或多或少地会碰到令团队内部个别成员迷惑不解的问题，此类问题的共同特征是会让团队成员首先对当前自身的认识产生疑问，进而让成员感觉到难于理解----很难与自己的当前认识挂钩。所以此类问题被人类统称为疑难，:).........我曾经在很多地团队中看到当此类问题出现时候的两种截然不同的解决方式，且通过最后的留意也发现一些有趣的现象。那么这两种截然不同的解决方式是什么呢？产生的有趣现象又是什么？

    团队碰到疑难问题时候的两种常用解决方式（场景）：

    resolve method one：疑难问题的出现没有引起任何人的心理变化，除了1个人----负责开发引出疑难问题的那个团队成员。每个人的工作依然如故，早上早早的来到单位上班，然后打开电脑坐在那里噼里啪啦地敲着键盘，好比钢琴家在欣赏着自己的技艺一样.........晚上顶着路灯的眼神，穿梭于车水马龙之间匆匆回家...........每天除了一些例行的工作会议，局部的解决问题的方式选择讨论外，一切都如故地进行着...........导致疑难诞生的那个团队成员心想：“这群王八蛋，平日里称兄道弟的，一碰到问题一个都指望不上.......等老子学好了@！#￥#%￥#%…………”........

    resolve method two：团队内部的各个或部分成员的工作内容增加了1项----就疑难的解决方案进行讨论----逐步讨论产生问题的代码   段，努力思考，及时见解............氛围很热烈，搞得那些没有被团队负责人拉来讨论的成员都跃跃欲试.........

    这是我们在团队内部发生疑难阻碍的时候会经常看到的两种场景，但这两种场景却真实地反映了作为一个团队负责、管理人员，是否具备管理团队、引导团队发展的最重要的一个技能甚至是意识。

    前面（上文）提到过，人的能力会被精力束缚，且对于同一事物（疑难问题的抽象父类）认知方式会受自身成长经历的影响和束缚，导致关注同一事物的视角和侧重点有着些许的差异。好比同样是一棵荫满叶茂的大树，有的人第一眼看到脑子里可能会想“砍下来回家做个床板一定很结实”----这个人的父亲可能是个木匠，导致此人从小对木头的敏感联系方式第一反应就是家具.........而有的人一眼看到这颗大树脑子可能会立刻想到“里面有树仙子吗？是不是里面有个童话的世界？！夜深人静的时候，树仙子们就会出来洗净每片叶子，扶正方向，准备即将到来阳光沐浴........”----这个人可能看过disney的《Tinker Bell》，并给她留下来美丽的难以磨灭的印象。所以，对待软件开发过程中的疑难问题，道理也是相同的。不同的团队成员针对疑难问题的审视角度和侧重点存在着差异，这种差异不代表错对的标准，但绝对代表着思路的分离甚至最终解决方案的起点。

   当团队开发过程中出现疑难的时候，作为团队负责或管理人员，应该第一反应很敏感地意识到组织讨论的时刻到了。不要小看这种能力，这么一种看似不起眼的能力，决定着团队整体技能，决定着团队协作习惯性行为的层次以及团队行为意识的提升，甚至最终决定着整个编码过程的进度控制是否会如己所愿----还记得我们在最开始提到的那个一些公司对开发质量提升的一个不完善的标准吗----只重视按时性和当前需求满足性、而不考虑后期扩展性和维护性。是的，俗话说的好，细节决定成败。其实任何团队的整体行为都是从一个看似不起眼的细节开始最后逐步发展到整个团队的一个优质的特征。

   所以，在过程控制中，我们在明白人是最重要的因素的基础上，我们还要时刻留意“现在该组织讨论了吗？是不是再让大家多想想再组织讨论会更好一些？哪些人参与讨论呢？”等等这些问题的答案。三人行必有我师，一个刚毕业的大学生不代表没有解决疑难问题的好思路，一个工作多年所谓的业内资深人士就一定能想到解决疑难的好思路。所以，抛开衡量团队成员的不良因素，此时不论待何时？

   很多的团队管理、负责人员出于自身意识的偏差，会将自己不自觉地放在一个高高在上的位置----最终的结果也不难想象，所谓上梁不正下梁歪，虽然此话置于此有些言过其辞，但最后的结果也未尝不是如此----团队成员得不到发展该有的氛围，自然个人技能的提升会放慢脚步。而作为团队管理，日子一久，就会发现自己的错误意识导致自身也受到了损害----自己变成了一潭死水！害人害己啊........

  3、交流固然重要，但交流不是万能钥匙！

  可能有的朋友会问，“你不是从头到尾都在说交流重要，交流可以提高团队整体技能，可以提高团队协作能力，还可以提高团队行为意识。这个也可以提高，那个也可以提高，怎么现在又突然说交流部是万能钥匙了？”----是的，当我碰到这个问题的时候，还是那句老话，“开发过程重要的是人，而不是工具”-----还记过程控制重要因素的第一条吗？

  交流其实也是个工具。

  工具是被用来利用来辅助人的，交流也是如此。我们可以利用交流去引导或扭转团队成员迈进的方向为我们预期的目标，但扭转一旦完成，后期的交流更多地体现在持续性的引导上。用中国的一句老话来说就是：师傅引进门，修行在个人。

   一个交流过多的团队需要注意度的问题，因为过多的交流将导致留给成员提升成效的有效时间减少。所以团队协作中交流的百分比没有放之四海皆准的硬标准，每个团队要根据自身的实际情况进行相应的调整，只要符合自身的实际情况，就是度的最好把握。

   团队需要安静的空间和安静的时间去让每个成员有思考的氛围，否则交流就成了纸上谈兵了。

   4、人心未必叵测，以诚相待从自己做起。

   中国有句老话，叫人心叵测。但在过程控制过程中，人心的叵测程度则完全在于团队管理建立的附加感情环境。

   为了保障过程控制可以达到预期的目标----让项目在预定的时间周期内顺利通过客户的验收，那么团队中成员的工作稳定程度就势必显的很重要了（单从过程控制角度考虑。当然项目结束后，成员的工作稳定程度也很重要，但彰显力度的确稍微次之）。如何保障团队成员的工作稳定程度，让大家的工作效率始终保持在一个正态分布的水平上是摆在每个团队管理负责人面前的现实的问题。

   我想很多做团队管理的朋友都碰到过这样一种情况：团队内部原本你很看好的一个成员突然在发了工资的第二天人间消失了，只给你留下一条以后常联系的短信，怎么叫也回不来，晓之以理动之以情完全失效。除此以外，更常见的情况就是一个不熟悉的成员突然离职，甚至很多朋友会认为熟悉不熟悉是离职正常与否的衡量标准----其实这个认识是完全错误的----正常即可测，不正常即叵测！？

   人的能力有限，所以不可能面面俱到也就很正常。作为团队管理，勇于认识并说出自己的技能缺失并非一件“丢人的”事情，反而会通过这个举动告诉团队成员，我也是人，并非半仙，和你们一样也是一步一步历经艰辛走过来的。同时通过交流的细化让下属成员了解到你的能力的强处在哪里。两个方面组成了工作中以诚相待的基本内容。工作之外，应有的尊重并不代表职能的划分要体现在工作中。

   知之为知之，不知为不知，是知也。这句话体现了团队日常工作中技能提升阶段团队成员间以诚相待的基础。人和人之间只要以诚相待，叵测就会被弱化。所以从自己做起，在团队内部培养诚待意识就显出其重要性了。

   OK，到此为止，我结合自己的工作经历和些许经验谈了自己在做团队管理和过程控制过程中非技术因素之外的几点侧重点，拿出来与大家分享，不足之处难免，恳切期望与大家形成有效互动之势。

   最后，说明一点：小团队的管理因为人员数量关系不太可能多级管理，所以单级管理足矣。在中型到大型团队中，由于存在多级管理，最高级直接和最基层接触过于理论化，也不符合管理中的分层管理思想，所以本文谈到的一些侧重点只适合单级管理或多级管理中的每一级内部。