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