沉思录:IT项目产品化过程中的问题杂谈（二）

项目背景可参见：沉思录:IT项目产品化过程中的问题杂谈（一) 空降兵 本人就恰逢是“空降”到另一个部门，来负责一个子系统的开发； 空降者不得不面对这些问题： 团队根基不好； 团队成员的“特征”不了解； 团队的工作经验和水平不了解； 这些实际存在的因素，必然会导致实际中存在着的问题 项目团队整体的技术力量没有预期的好，项目中期进行模块集成时，发现代码和设计存在不少的问题，这些问题的累积对项目的进度和质量有一些影响 项目中期核心成员离职，对项目有了很大的影响 （纯属管理上的严重失误，项目前期就应该了解项目成员的“去向”） 项目核心团队虽然已经组建，但后续陆续加人，项目整体合作出现问题 虽然面临不少的问题，但也没有办法避免这种“空降”的情形，实际中，始终都坚信这样思想：只有团队的支持和互相合作，项目才会成功； 但实际中应该如何解决这些问题呢？依靠个人魅力？专家能力？还是正式赋予的权利？ 简单介绍一下实际做法： 整体的思想 静观其变（前期没有太大的动作，群众基础不好，可能会有很大的抵触） 变革（中前期，根据不同的问题进行不断地慢慢改革） 融合（渐进式的改革，慢慢可以被人接受和信服） 合作/表现 (Team 已经步入了正式轨道，成员能够积极地“表现”，从而保证项目顺利地完成) 整个项目开发过程中，更多的是“专家的能力” +“个人魅力”，很少使用“正式的权利“　（个人始终觉得，对于小规模的团队，这两种权利的综合会比“正式权利”好很多） 借助工具（JIRA）来做任务跟踪和管理 能保证了资源的有效利用; 利于任务交接（尤其是团队不是很稳定的情况下） 任务控制更简单（可视化的系统跟踪) 采用“严格”的代码REVIEW来做“团队建设” 使用更多的“软”技巧来进行项目管理: 以个人发展为切入点，积极地引导正确的做法或纠正不是很恰当的行为 根据个人特点进行任务分配 技术能力/经验比较丰富的，直接提供需求点即可； 技术能力/经验稍欠缺的，需求再次细分，直到可以代码实现的粒度； 新人/或者技术能力一般，需要提供简单的代码结构和设计思想 总之，无论是否是不是“空降”，项目管理要做的始终是：为团队服务…… 团队的力量 现实中总会遇到类似的状况： 需求总是在变化，哪怕最后一刻 时间总是不够用，无论周期多么地长 资源总是那么地少 问题总是在不断地增加…… 但无论如何，最终总是会完成的…… 回首一下，会不会觉得这是个奇迹？　是不是应该享受如此“混乱”的奇迹？想想为什么能够完成？ 这就是团队合作的力量：互相鼓励；彼此信任；合作；风险；坚持…… 从而，“如何有效地发展团队”也是项目管理中比较重要的任务之一。 责任 项目编码很乱，很不规范，谁的责任？个人能力的问题？培训机制的问题，PM/PL 的问题? 产品业务知识不了解，谁的责任？ 这些问题看似很简单，但针对不同的情形，执行起来都不容易，但无论如何做，无论谁来做，都可能演变为“责任”的问题，每个人踏踏实实地去做，真正地去做，把每一件事都当作最重要的事来做…… 或许会怀疑，没有人指导，没有正确的方向，没有一个有效地规范，如何才能够承担“责任”？ 虽然可能如此，但不去尝试，不去努力，基本的“责任”都已经丢失了…… 可我凭什么要有“责任”？这将会是另外的一个令人深思的话题…… PMP 项目管理知识体系提供了项目管理框架和九大知识领域的介绍，能够给项目很大的帮助，但仅仅通过PMP 是远远不够的，如何把PMP的理论知识切实地落实到项目之中，如何运用好PMP理论中的哪些工具和方法？这才是我们应该去思考的。

Link URL: http://www.lifandong.com/management/105

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/119750/viewspace-625418/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/119750/viewspace-625418/