2016项目反思

Posted 2020-08-23

毕业至今，大大小小的项目经历了十几个，有不少成功的喜悦，也有不少失败的教训。近来暇时，细细回味，时值2016年年末，略有感想。

算来，7年的项目经历，从最开始的用C语言写编译器，到最近的.NET的机构版。其中最成功的最喜悦应该属health care的UDN和实训平台的TTS，最失败教训最足当属机构版。health care项目组是我跟随zhong li老大做的第一个正式大型项目，第一次完整的接触正式的软件过程管理。全球数千人同时为一个项目服务，其中过程管控是我至今影响我最深。跨地域，跨平台，跨语言文化，跨技术种类，跨工种合作，协同开发。最终完成了微软打入中国市场的第一款医疗产品，其中所长，至今收益匪浅。可惜由于微软的战略调整，在全球裁撤了health care。这个项目也算不得善终。

TTS是我独立主持一个组成块的第一个项目，往后所有主持项目的经验大多来源与此。虽然只是一个不到二十人开发小团队，但是也涉及软件开发各个方面，幸好有严头，孟哥扶持，首次项目，磕磕碰碰也获得了成功，我们项目组研发了中国首款医用实训平台，至今，全国几十家医科院校和大型医院的实训系统全年运作，每年成千上万学员使用，长沙的湘雅在我离开天堰的时候正在洽谈商务，不知最终结果如何，如果用上，也算我为家乡做了点贡献。这应该是我目前最自豪，同时也是最累的一个软件过程，通宵达旦，全国各地四处“出游”，被指着鼻子骂这都成了一个常态，同时也是这个过程，让我真正了解了如何在全局掌控项目，将数年所学进行验证和修正，可以说，在完成这个项目后，我真正具备了一个软件管理者的能力。之后的智能城市监控系统，sbs，中医症候人等等项目都顺理成章，只不过是在增加经验而已。当然，这中间也有流产项目，不过管理问题导致的项目失败不多。

然而，今年，2016年，我遇到了软件生涯最大的失败--机构版项目。对于这个项目，给我的只剩下了教训，滴血的教训！延期，质量不达标，软件成员心散，管理缺失，最终完全失去控制，险些项目流产。这个项目的教训，我需谨记，以备他日只需。

一，简单粗糙的项目启动

至今，我都回忆不起这个项目的启动了，没有需求验证，没有分析，我现在都找不出一张我启动这个项目依据的图纸，就是做了初步的功能了解，然后就，说的好听点是义无反顾，说的不好听点就是“没头没脑”的开着小破船驶向风雨未知的大海。我影响最深的就是4.30，一切为了这个日期服务。然后产生了高风险的计划，如走钢丝一般的过程。承蒙公司仁慈，未追究责任人的具体责任，但是我应当负有不可推卸的的“历史”责任，作为项目主持方，未能及时根据专业知识组织决策层的错误决策，而是盲目开启项目，这是作为一个项目主持方最大的失败。

基于此，有以下几点反思

1，公司的最高管理者或者管理层，应该制定一个正确的可实行的阶段目标，而不是指定一个时间。具体的日期，具体计划应该由手下的专业团队进行科学的判定，最高管理者或者管理层根据这个判定决定是否执行这个计划。这不应该是一句废话，应该是开始一个软件过程的第一层约束，通过这一层约束，将公司所有相关团队的思想进行统一，目标进行统一。如果一开始各个相关团队都不能清晰的陈述出进行某个项目的统一目标是什么，那么预计这个项目已经有5成概率是失败的。

2，具体预估团队（这里指参与这个项目个所有相关团队），应该预估包括成本，开发周期，可投入资源，可承受调整范围，核心价值，核心用户，推广程度等等细节，已提供给最高管理者或者管理团队有效的信息进行决策。同时，预估团队应该要保证预估的科学性和合理性，这就要求上层给予具体团队足够的分析时间和正确的信息，不应该说这样的话：这是过渡版本，给我初略时间，我要这个产品XX上线。这些都会给具体团队评估造成实质的影响，同时要求具体评估部门具备评估的实力和正确的态度。

3，不要急着动手，哪怕拿几天出来，捋清楚脉络，统一思想。每个项目执行过程中的具体负责人每天都应该有时间在思考目前过程中离目标有多远，有什么偏差，有什么风险。

二，过弱的项目管理和过强的行政干预

对于一个项目团队来说，管控者是核心，产品团队是至高无上的神。但是在机构版过程中，这个规则完全被打破，作为项目负责人，疏于管控，时间基本用于老产品的维护，代码开发和行政管理，真正投身到这个项目的项目管理精力少之又少。甚至有时间段处于无人管控状态。过多的人员对产品有权决策。对于一个项目过程，产品人员应该具备绝对的对产品的决策权。如果一个项目最高管理者或管理层通过，那么，产品人员对该项目由绝对的权利，对产品的决策权最优状态是只有产品人员在决策。当然，这只是一个理想过程，我也仅有在health care经历过。说句违心之话，在业界认为：最应该不说话的是对产品最具备发言权的老板。老板一般都在扣细节和比较竞品，然而，如果这都考虑不到的话，那还做什么产品经理，回家种红薯去呀！当然，绝对的权利，就必须有绝对的对项目负责的义务，就是说，产品经理应该对项目的全过程负责，包括盈亏。

三，项目成员的活路

毫无疑问，项目过程中，项目成员是主体，项目成员的工作热情，工作态度会直接的影响项目的质量和过程。那么就引申出了项目成员日常管理。我承认我深受欧美企业和成熟团队工作方式影响，对于项目成员的管理我只关注按期保质完成工作任务，至于其他方面，哪怕你是个杀人犯我都不管。但是我忽略了欧美文化和我国文化，成熟团队和不成熟小团队的差别，这也导致了成员管理的彻底失败。今年下半年我在一直都在考虑我并不适合做中国式企业的项目管理，理念的格格不入只会使项目遭受损失。我期望这家公司可以大跃进式的完成软件过程管理蜕变，但是我又忽略的这家公司成员所具备的基础素质，我看到了这家公司“资本主义”的萌芽，但是很快的又回到了作坊式中国式企业管理方式。这个过程我很茫然，不知道该如何选择今后的项目管理道路。公司或许也看到了这个情况，对我进行了调整，新加入技术经理进行全体管控，收回我的管理职务，目前我作为一个普通的开发人员，接受行政管理方式管理项目成员，就是给项目成员设定框框，加入限制，确实取得了一些成效，但同时，以这几月观察，也造成了责任心下降，相互甩锅，不愿承担责任的巨大问题。这我目前确实没有好的方案~~

四，缺失的质量把控和缺陷控制

举个例子，机构版有个主流程的bug，在上线后，客户进行反馈，说无法使用。这应该算是一个严重的质量事故。为什么会有这样的问题出现，当天我找了测试人员，测试人员告诉我，说这个bug早就测出来过，开发也提交了修复版本，并且还通过了验收，但是不知道为什么上线后就是出现了。然后我问了这个bug具体的开发人员，他给我看了这个bug在禅道上的具体描述和解决过程。显然，这个bug确实已经修复并且测试人员已经关闭。那么，问题在哪？根源在哪？后来，跟测试负责人聊天，他向我抱怨，他们测试人员总是在各个项目中调来调去，往往一个项目中某个提交版本来了，却突然抽调到了另外一个项目，原来那个问题就先放下，过了几天或者一两个星期，就忘了。然后我问了他关于那个bug是不是也是这种情况，他告诉我，执行这个版本测试的成员就是突然被抽调走了，这个问题又是常例的放下了。然后~~~~~ 出了这样的问题，第一想法就是测试人员不负责，开发人员质量低下，确实，具体执行成员负有不可推卸的责任，但是这家公司又什么时候挖掘过它深层次的原因：阶段性目标缺失，项目穿插混乱。

五，“会议”文化

这家公司是我见过的最能开会的公司了，往往一个会议就是几个小时，最终基本没有定论，一个简单的技术应用问题，不知道会扯到哪个天边去，同时，这家公司还流行“小会”，就是负责人碰头开会，这本身是科学的，负责人应该经常性碰头商议。然后，它的问题是“小会”上定论的一些结论不向下传达，甚至有时项目经理还不清楚“小会”上改变了什么。然后在完成的时候，“小会”成员会说：这个我之前不是跟谁谁谁修改了一块吗？怎么现在还是这样？然后大家一脸懵逼！当然，我目前无法对此文化做出什么评断，但是我认为，会议，适当就好，说有意义的话，其余的，下班说去。

六，不能有效管理用户需求

很简单的例子，教研对于题库的需求，我们在项目开始是有很多乐观的估计，貌似达成了一致的需求。然后在这个乐观的基础上，用户需求膨胀了，脱离了产品边界的期望出现了，用户不知道应该期待什么或者他们不能看到项目的实际进展情况，然后他们对项目失望了，我们的关系彻底的破裂了。

解决方法：

将期望值管理到一个合理的水平是项目经理的职责。

其中一个方法是将项目分解为有频繁里程碑的各个任务块或者项目阶段。你可以通过发布周期性的交付物给客户，让他们看得到他们将要得到什么。通过这种方式让客户在早期就能看到你们在做什么，从而客户保证项目交付物能符合客户的期望

七，不强调风险控制

在项目的生命周期中，有很多场合风险和异常会导致问题，甚至失败。感觉在这个项目中，我们至少犯了以下几点：

 1 没有清晰的定义需求，结果是不能满足客户的期望；

 2 过于简单的技术设计使得未来的方法没有变更与伸缩的可能；

 3 无效的变更控制使的变更要求导致项目偏移原来的目标；

 4 测试不充分导致错误和缺陷遗留到产品上；

 5 在关键时刻缺乏关键人物的支持。

解决方法：

在项目开始的时候对风险和问题列表进行评审。其中一个好办法是使用头脑风暴列出可能的风险和问题，参与人员包括项目成员、其它参与过类似项目的项目经理等。在整个项目过程中不断对风险和问题进行评审。对上面例子中的解决方法包括：

1 对雇佣人士勾画出客户的需求，并使用清晰、明确的文档进行记录；

2 提问是否必须使用前沿的新技术，后者是否有能提供相同功能的更多方法；

3 由你的团队进行技术设计。这样有很大的机会获得一个可靠和灵活的设计，而且你的团队也有了可以继承使用的基础设计；

4 在项目启动之前与客户达成一个变更控制的流程，并且严格根据流程执行；

5将测试计划与根据客户要求制定的测试场景放在一起。保证你有足够的资源以及保证客户承诺进行测试；

6制定一个针对失去关键人物的风险的应急计划。