个性化的行业软件打算打造成“通用产品”(行业不改变)

　　推出给客户时，遭遇不断地变更和“个性化”：问题频多，沟通也频繁出现问题

　　由于急于上线(换句话说，尽快脱离困境)，项目完全不按照正规流程来走，部分项目人员也是临时组建，很多系统都是不停地打补丁

　　本人作为其中一个子系统的项目经理，经历了几个月的“噩梦”，目前产品还没有上线，比预期的时间要长的很多，产品已经处在了“悬挂”的状态，双方都已经很疲惫，问题也不是那么多了……

　　简单回顾了一下出现的问题，思维不是很清晰，仅仅是个人的愚见，有则改之，无则加勉，无病呻吟的文字，供思考，同时期待较好的解决办法。

　　(一) 知识管理

　　公司主旨也是在努力的进行“知识管理”建设，总在谈“知识管理”及其“知识管理是多么重要”的，可现实中的“知识管理” 呢：

　　项目结束之后，留下来的有用文档很多

　　留下来的文档有价值的很少(不是很旧，就是不正确)

　　个人觉得，知识管理，更多是“意识”上的问题，项目铁三角(Scope/Time/Cost)，外加质量固然重要，但“知识”呢?没有不断地知识积累，如何才能够更好地进行项目管理?

　　思考的价值?也许一次，两次，甚至十次都没有如此做，可是第十一次，是不是应该从头开始就进行很好的“知识管理”?时刻保持着“改革“的思想很重要

　　如何有效地“推行”知识管理这种思想，不是一天两天的事，但也绝不是一年两年的事情，从现在开始自身就去考虑，去尝试，而不是总是从下一次再开始

　　组织级别的思想很好，很多产出物也很好，但推广力度不够(或者说没有被广大的PM所接受，没有深入人心)，不是很恰当，最终很多都沦落为一堆需要花费很多时间去填充的“垃圾“。。。。。。

　　是不是应该集体洗洗脑?

　　知识管理，从现在开始，从你我开始，无论多么忙……

　　(二) 执行力

　　水平有限，没有太多的发言权，但觉得必须手段强硬，才可以有效地推进产品的整个进度，一个强有力的执行者对如此混乱的产品还是有很大的帮助的，但更多，我们推荐的应该是“有意义的辩论” 而不是“漫天的争吵”，不仅仅浪费时间，更浪费大家的精力，前期的激情逐渐地在消退……

　　其中很多事情执行的不是很顺利(甚至，无法执行)，原因分析如下：

　　沟通不顺畅的两种情况

　　A Team做的任务，组织级别不是很了解;

　　很辛苦，花费很长时间的任务 不被别人承认

　　组织级别对项目复杂程度不是很了解，会导致有些任务或者功能的实现难度不了解;会总以为是很简单的事情，可真的很简单吗?

　　强制推行，这种后果就是事情做了，但不一定准确

　　总之，无论如何，想要执行力顺畅，一定要坚信，最终的目的都是一样的：尽快摆脱困境，尽快推进系统，尽快上线，各自的子系统都应该努力地“执行”……

　　(三) 主动性

　　这种产品化的系统，系统与系统之间耦合度很高，难免会出现了各个系统共用一个功能，或者使用各个系统完成同一个功能模块;然而，如何处理“模糊的”需求地带呢?

　　产品是主体，每一个系统是个体，主体很差，再完美的个体有用吗?除了保证个体是完美的，也要勇于承担“主体完美”的责任……

　　互相推诿，互相扯皮，是不可能最终解决问题的，勇于承担，勇于主动来触发一些问题，才有助于问题的解决，惹“祸”上身难道一定就是坏事吗?

　　无论如何，别忘了我们最终的目的，绝不是保证一个系统好用，我们要解决的客户的问题，保证整个产品是好用的……

　　同样，上述想法和单个项目是一样的，我们不是为了完成一个模块，一个任务而合作，我们最终的目的是保证整个系统的正确运行，所以每个人都应该有这种“主人翁”的精神，努力地都为这个项目负责，为将来的用户负责，而不是单纯地完成“所谓自己的任务”……

　　主人翁精神，你有吗?

　　(四) 空降兵

　　本人就恰逢是“空降”到另一个部门，来负责一个子系统的开发;空降者不得不面对这些问题：团队根基不好，团队成员的“特征”不了解，团队的工作经验和水平不了解，实际中存在着不少的问题：

　　- 过高估计项目团队整体的技术力量，项目中期发现项目模块集成和代码存在很多的问题，这些问题的累积已经完全影响了项目的进度和质量

　　- 项目中期团队成员中途离职也导致了措手不及 (管理上的严重失误，项目前期就应该了解项目成员的“去向”)

　　- 项目核心团队虽然已经组建，但后续陆续加人，项目整体合作出现问题(本身的核心团队就不是很稳定)

　　虽然面临不少的问题，但也没有办法避免这种“空降”的情形，实际中，始终都坚信这样思想：只有团队的支持和互相合作，项目才会成功;

　　但具体如何做呢?依靠个人魅力?专家的能力?还是正式赋予的权利?

　　简单介绍一下实际做法：

　　- 整体的过程，静观其变(前期没有太大的动作，群众基础不好，会有很大的抵触)，改革(中前期，根据不同的问题进行不断地慢慢改革)，融合(渐进式的改革，慢慢可以被人接受和信服)，合作

　　- 整个项目开发过程中，更多的是“专家的能力” +“个人魅力”，很少使用“正式的权利“　(个人始终觉得，IT项目团队都不是很大(小于10人)，并且有些人员个性比较强，正式权利作用不是特别地大)

　　- 借助工具(JIRA)来做任务细分，保证了资源的有效利用，尤其是团队不是很稳定的情况下，任务的交接比较方便，项目整体也比较容易控制

　　- 采用“严格”的代码REVIEW来做“团队建设”

　　- 我始终信奉的是：只有成员能力提高了，团队战斗力才会很强，所以总是不断地去扮“黑脸”去“找错”，频繁地引导团队成员应该需要知道哪些……

　　- 成员比较复杂，依据个人的特点去任务分配(技术能力厉害的，直接给出需求点即可;技术能力差一点的，需求再次细分，知道可以实现的力度;如果技术仅能够写代码，那么就需要提供简单的代码结构)

　　总之，无论是否是不是“空降”，更多是有效地利用项目管理思想，努力地为整个团队服务，这样就无所谓是否是空降的了

　　(五) 团队的力量

　　项目总是这样的，需求在变化，需求在循环地变化，时间总是那么紧，人员总是觉得少，时间总是多么紧的……　但最终总是会完成的……　回首一下，会不会觉得这是个奇迹?　是不是应该享受如此“混乱”的奇迹?想想为什么能够完成?

　　这就是团队合作的力量：　互相鼓励，互相信任，合作，坚持……

　　而管理的宗旨就是如何有效地发展团队，让力量最大化

　　(六) 责任

　　- 项目编码很乱，很不规范，谁的责任?个人能力的问题?培训机制的问题，PM/PL 的问题?

　　- 产品业务知识不了解，谁的责任?一直“闹哄哄”很久的整个系统培训的计划，为何迟迟得不到执行?难道必须要等到事情发生了，才去做吗?谁都知道未雨绸缪是什么意思，但实际呢?

　　很简单，无论如何做，无论谁来做，终究来是一个“责任”的问题，踏踏实实地去做，真正地去做，把每一件事都当作最重要的事来做。。。

　　或许会怀疑，没有人指导，没有正确的方向，没有一个有效地规范，如何才能够承担“责任”?

　　虽然可能如此，但不去尝试，不去努力，基本的“责任”都已经丢失了……

　　可我凭什么要有“责任”?这将会是另外的一个令人深思的话题

　　(七) PMP

　　单纯从PMP数量上来看，目前公司的项目的管理水平应该是相当地厉害(PMP的覆盖率有15%)，可现实呢，还不是小mi加步枪……

　　考来PMP是没啥用的，如何把PMP的理论知识切实地落实到项目之中，如何运用好PMP理论中的哪些工具和方法?

　　这才是我们应该去思考，并且积极地去实践的……

　　想，永远也解决不了问题的……