09年的一个方案，很遗憾没有采纳，回头看看，我还认为我是对的

在09年初我就我们工作中的问题给我们总监撰写了一个问题分析报告，很遗憾，没有采纳，当时给予我的答复是他刚接手IT中心一切以稳定为重，直到今天我还认为我的对的，后面几年发生的事情印证了我的猜想，一个不重视内部团队建设的组织不会长久，几年过去了，我早已离开了这个公司，但是我从后面发生的事情看到了一个高高在上的领导者最终的归宿是惨淡的离开，并且毁掉了一个原本可以很好的团队，我想今天如果有人也这样给我提意见，我一定会重视的，今天拿出来给大家共勉，作为正面后者反面的教材吧。

 

关于院校支持中心问题的分析

 

   院校支持中心在A总您的领导下，目前取得了非常大的改观，不管是从内部氛围还是具体工作，较之以前有了长足的改善。但是目前您的一些非常好的方法，非常好的体系思想由于具体实施人员的问题，不能很好的贯彻执行，导致目前我们院校支持中心还是存在一些比较大的问题，下面我就具体问题分别说明。

1.       职位划分不合理，导致问题迭出

目前的实际情况是，开发人员从需求讨论、开发、测试、上线各个环节都要参与，而且有了问题，问题归根结底还是由开发人员解决。导致目前开发人员什么都参与，什么都做不好。但是目前我们的岗位人员从系统人员、需求、开发、测试一条龙配备都很完善，可是为什么事情还是做不好呢？

就是因为我们各个环节是都有人，但是这些人都没能很好的完成本职工作，原因是没有一个好的制约机制。人都是懒的，如果靠自觉，那只要是少数人，就算是有这少数人，时间一长，也会发现干得越多，你的问题越多，最后大家都成了磨洋工的了。那好，我们就用一条绳子上拴蚂蚱的办法，一出问题大家谁都跑不了，都承担责任。是不是这样问题就能解决呢？

答案是否定的。因为即便是这样，也会存在多干少干的问题，最后多干的看到自己就算再努力结果也是个差，那索性也磨洋工，反正大家一起，差全都差。这样到头来最倒霉的是谁，是公司，公司的损失最大。那难道就没有解决问题的办法吗，有，我们仔细分析一下，如何在不增加成本或者只增加少量成本的情况下，把我们的这个问题彻底解决？

我们仔细分析一下，为什么项目会出问题，是因为我们的产品质量有问题，为什么产品质量会出问题，是因为我们没有很好的质量把控体系。我们有测试啊！可是测试人员的测试到位了吗，没到位！那就让他好好测，测不好扣奖金！可这样一来，大家不但会骂老板是吸血虫还会消极怠工，一天能测完两天完，最终项目还是垮。这样赔了夫人又折兵的做法肯定不行。那好，就看看下面的方法行不行。

看看我们目前人员配备：

需求：2人

开发：3人

测试：2人

总共：7个人

那我们按照项目管理的职责划分为以下的职位：

项目经理：1人

需求分析：1人

开发架构：1人

普通开发人员：1人

测试+技术支持：2人

文档+培训：1人

总共：也是7个人

人员是没有增加，看我们的问题解决了没有，别急，我们自己分析一下就明白了。我们目前不仅是开发累，需求也累，每天电话不断，可是我们看看，需求人员每天做的具体工作。

每天一上班就是接电话，客户问怎么这里打不开了，那里显示错了，需求一看赶紧跑到开发那里。

“你是怎么开发的？“

“我按照你写的需求开发的“

“那怎么会显示错了呢“

“你问测试去，谁知道他怎么测的“

需求就赶紧又跑到测试那里，测试一看，或者是测试不到位，或者是开发理解需求不正确，折腾半天问题才搞清楚，需求刚做回座位，一个电话又来了。。。周而复始。这样需求人员能不累吗，需求是做什么的，需求是做需求分析的，不是做技术支持的，每天这样，需求人员能做需求分析吗，这也是目前我们院校支持中心支持水平不高或者说根本没有需求分析的原因。

可是没有需求分析会导致什么样的结果吗？需求错了，开发测试一连串错的，乖乖，这个问题可就大了。天长日久，我们的系统就成了目前这样的，虽然我们对外宣称我们的系统是业界最完善、功能最优秀的，但是那仅仅是宣传口号，这些问题我们其实自己心里比谁都清楚。

­­说了这么多，问题怎么解决，其实很简单，让测试做技术支持。啊？先别“啊“，让我们看看这样做的好处，然后再决定是不是值得这么做。

 

1.测试做技术支持，把需求解放出来，这样需求人员就能安心做需求分析（当然如

何做好是另一个问题，现在是想做好都没机会），这样保证了需求质量，同时也就

能考虑整个系统的问题，多考虑业务，让大家成为业务专家才不是一句口号。

        2.测试做技术支持，他知道如果上线的业务有问题，院校肯定找自己，所以在测试的时候肯定能仔细测，这样如何提高测试人员责任心和水平的一个老大难问题，就能在不施加任何外在压力的情况下，让这个体制自己把问题解决掉。

        3. 测试做技术支持，因为他自己把好了测试关，督促开发必须写出高质量的代码，这样开发也能提高质量。另外开发还能更好地提高质量，因为我们对开发重新划分了职能啊。

    开发分为架构人员和普通开发，这样做有什么好处呢？目前我们的代码质量不高主要是因为我们开发的人员水平参差不齐，水平差和水平高的自己忙自己的，导致一些页面质量很

差。如果我们采用模块化的处理手段，把重要的、经常使用的让架构人员去做，这样在质量上就有保证，而且只让普通人员去调用，普通人员也可以很快完成任务，这样即保证了量又提高了速度，而且架构人员由于越来越专业，会带动我们整体系统越来越先进，这样的一个良性循环，不正是大家所期待的吗。

 

     看吧，我们在人员没有增加的前提下，把需求、测试、开发三个部分的任务都解决，别着急，我们还有个项目经理呢，我们可以把工作做得更好！因为这个职位可是我们原先没

有的，那他可以做什么呢，首先他能协调我们各个职位人员之间的问题，原先这个问题一直没有人去协调，闹大了，领导出面说两句，大家也就先不说了，可是面和心不和，后面该怎么闹还怎么闹，现在好了，有人专门协调大家的资源，甚至如果项目紧了，挽袖子也上马编代码。项目的过程控制有人管了，领导也省心了，另外时不时的还可以搞个激励竞赛，请领导讲讲话，大家和睦得像一家人一样，即做好了工作又能高高兴兴的，这样的方案是不是值得我们采用呢？

     别急，万一不行呢，我们要做到万无一失！对,所以我们才要使用“试点“的方式，就像经济特区，一个试点搞好了再推广，如果搞不好那就再采用我们的老方法，这样的进可攻退可守的方案是不是有试一下的必要呢？

 

2.       很多人心有余而力不足

很多运维工作几年的老员工都有这样的体会，都知道目前系统的一些问题或者解决问题的一些思路，但是由于手头工作太忙，导致一个很奇怪的现象：不断地发现问题，不断地不去改问题。直到有一天，院校拍桌子骂娘了，这样我们赶紧该，开发人员一边改一边嘟囔“早就说了，早给我几天时间不就早解决了了吗“，就算问题解决得非常完美，院校也是一肚子火，”你们是干什么吃的，这样的问题自己就发现不了“，领导和大家一肚子委屈，那也只能打碎了牙往肚里咽。

      这个问题就不能早点发现早点解决吗？能，当然能！关键是谁去做的问题。开发知道问题但是没时间去解决，因为开发的任务是需求分配的。需求也无能为力，需求的任务是院校排的。院校也不理会，你们自己的问题还有脸来问我。那这就是一个死循环了吗？不，如果有项目经理，这个人是干什么的，这个人就是要解决这样的事情的，要不，设置这么一个经理仅仅是排排任务，那找个机器人得了，干吗还要找个人来做。

      其实如果有一些沟通技巧，这些问题都是小问题，院校也不是没事找事的主，只要把利害关系说清楚，他们还是非常配合的。毕竟出了问题，院校是第一受害者，如果站在他们的角度上思考问题，解决问题，我们目前遇到的问题都是好解决的。但是东财08年满意度比较低的另一个原因虽然没有体现在指标上，但是去咨询一下院校，我们就会发现，是我们在处理问题的角度上有问题，和院校处在对立面，甚至让院校下不来台，这样的情况下能对我们有好的评价吗。如果我们采用了项目负责制，只要给项目经理以项目职责内的充分权利，今年这样的问题还能算个问题吗，所以说目前的体制是大家有苦说不出的一个原因。

      有了项目经理，除了解决项目运作中的一些问题，他还能解决项目发展的一个问题，毕竟我们目前的情况最了解各个院校内部情况的都是一线的员工，他们可以把目前系统中的问题，流程上的一些问题都反映到项目经理这里，由于项目经理只负责本项目内部，不像部门经理要处理的事情那么多，所以有很充裕的时间去考虑和解决这些问题。

      其实大家放眼看看中国的现状就会发现，项目负责制是非常符合中国国情的，对我们院校支持中心而言，尤为如此。

   项目负责制的另外一个好处是，可以提供给领导一个最直接、最准确的信息，因为他不会存在部门间的扯皮，项目经理直接负责，直接上报，可以最快最真实提供第一手资料，以供领导决策。

 

3.       为什么人员流动比较大

也许您会比我们有更深切的体会，因为院校不止一次的抱怨，我们不是没有人才，很多离职的员工走后，院校都表示了惋惜。可是我们的这种现象还在继续，甚至在一个特定时期内很严重，也许老板不会为一个人的离开作出什么改变，可是这种现象持续发生，带给我们的负面影响是很深远的。我们成了别家公司的免费培训基地，把从我们这里得到的经验教训在别家的平台上更好的发挥，我们难道不应该反思一下，为什么会发生这样的现象吗。

其实原因大家都很清楚，就是没有一个好的氛围和施展自己抱负的舞台。很多人的综合素质很高，在岗位上本来能发挥更大的作用，却因为我们内部的任务分配、体制、流程等等问题一直压抑，无法发挥自己的聪明才智，时间一长，只能选择跳槽。因为不是所有人有敢于改变环境的勇气和魄力，大多数人是被环境同化着，当发现自己的理想确实不能实现的时候，如果我们站在这个人的角度上，那能怎么做？我们不能指责他们的职业道德，因为现在的社会是一个双向选择的平台，公司选择员工，同时员工也在选择公司，社会也在选择企业。如果我们在对待人才的问题上还是墨守成规，还是认为“人有的是”的观念，那我们企业的危机就真的不远了。

其实好的氛围不仅仅是由公司来左右的，氛围由人培育，关键看有没有人意识到要培养一个良好的氛围的重要性。怎么形成良好的氛围，我想结合我自己的亲身体验谈下我的想法，因为我们组可以说已经实践着我下面要谈的内容。

 

1.       形成真正负责的“导师制“

我们是有导师制度，但是在实际运作过程中多数流于形式。为什么？因为大家都没有动力。老师为什么要教，学生为什么要学，自己双方真正有了渴求以后效果才会好。我们有指定师傅的习惯，可是这个师傅一定适合这个徒弟吗，为什么我们不能考察一段时间后，师傅不行可以换师傅呢。我们的很多人技术水平是不错，但是沟通能力不行，这样的闷葫芦怎么能带出好的徒弟。至于怎么激励大家对导师的积极性，我目前也没有太好的办法，但是有一点，这个问题可以征求大家的意见，我想肯定会有一个满意的答案。

 

2． 团队内部沟通不畅

    我们的很多团队，别说和其他部门沟通，甚至自己小组内部的成员之间也很

少沟通，大家在一个个自己的孤岛中，时间一长，能没有思想问题吗？我也是其中的受害者，但是当我发现这个问题以后，我主动加强与团队其他成员的沟通，了解项目的情况，主动做一些工作，很快得把思想问题调整过来。但是不是所有的人都能像我这幸运，像我采取这样的处事方法，很多人有了问题，没有人帮助他解决，最终只能选择离开。

这里我举两个今年发生的实际例子：

b君是我们的新员工，她来公司前的技术水平很一般，在适用期我们发现了这个问题，并延长了她的适用时间，但是在适用结束的时候，我们的领导要决定让她做“发布专员“。我了解到这个情况后，主动与她进行了深入的交谈，了解到她已经决定要辞职了。但是当时我发现了她的一个很大的优点：她的工作态度非常端正，非常努力在学习，成果也比较明显。她离职的主要原因是她自己说自己感觉非常委屈，自己非常努力去工作，却得不到认可。我了解到这些情况与需求开发其他人员沟通后，都普遍对她比较认可，于是我和c君（需求）找到领导就此事进行了沟通，最终留下了她，事实证明当初的决定是正确的，目前她已经成长为东财的一个非常不错的员工，虽然才来公司几个月，但是所起到的作用已经和一两年的老员工不相上下了。

另一个离职是我在年前发现我们内部开发人员的情绪不稳，已经影响到了日常工作，我主动抽其他时间沟通了解谈话，解决了开发人员思想上的抱负，在几天内就立马起到了非常好的作用，目前的干劲十足。

我举这两个例子是想说明，在团队建设上的沟通的重要性，但是很可惜，我们很多人都忽视了这个问题，领导事情多难免有疏漏，但是一旦出了问题，没有人帮助他们解决问题，那后果是什么，如果今年我没有化解这两个问题，我想东财不会是目前的状况，虽然现在满意度不高，但是我们正在逐步解决着这些问题，东财今天发生的问题明天就很有可能是别的院校要发生的问题，未雨绸缪，不是所有人都能这么做的。

 

3         工作内容的“泛大锅饭“化

由于开发任务是由需求分配，但是需求不了解开发人员能力上的差异，就算了解也不知道该采取什么样的处理手段去解决这样的问题。如果有一个项目经理，如果我们采取了开发人员的梯度化职位，让合适的人做合适的事情，不仅仅是提高工作效率和工作质量的问题，最重要的是满足了大家心里上的需求。人其实很多时候是需要这种的“认可“，而我们现在没有这样的途径让大家得到认可，时间一长，大家会认为自己什么都做，什么都做不好，而最要命的是自己原本有能力做好，是这该死的公司不让自己做好，这样的情况下，不跑路才怪呢。

解决这样的问题最好的解决办法就是具体工作内容上的调整，让大家都做着自己认为能发挥自己能力的工作，这样的情况下，大家在工作上的怨气就能消除，对公司而言，其实是和很大的福气。

 

 

 

以上是我对我们院校支持中心目前存在问题的一些自己的看法，业务有些地方可能有些极端，但是我是本着“这是我的问题，我要解决“的心态来分析的，是我这几年工作的结晶，如果能给领导决策提供参考，不胜欣慰。

 

恭祝新年快乐！