|
太上, 不知有之; 其次, 亲而誉之; 其次, 畏之; 其次, 侮之. 功成事遂, 百姓皆谓: 我自然——老子<<道德经>> 上面的引言是说: 最好的领导是让下属感觉不到他的存在; 二等的领导是大家都爱戴的领导, 三等的领导是大家都畏惧的领导, 四等的领导是大家擦拳磨掌要把他打倒的领导. 大功告成, 诸事办妥后, 老百姓都认为没有受到干扰, 实现了自然发展. 也就是说, 完成的过程没有受他人强制的感觉, 是人们的本性使然. 项目经理领导、项目经理指导、项目经理策划、项目经理管理, 这些都是需要承担让软件项目实现业务价值这一责任的项目经理所背负的重担. 虽然项目经理在整个交付机制中处于一个关键的位置, 但是如果他成为一个团队的中心, 则会给团队带来不必要的风险. 实际上, 项目经理应该用一种更温和的方式来开展项目, 从内部帮助团队走向成功, 建立一个可以让每个人(包括他自己)受益的系统.
颠覆传统的领导方式
敏捷与极限编程方法的基本原则对无形的项目经理这一观点来说非常适用. 在传统模式中, 项目经理要负责所有的事情, 包括技术工作的详细说明、管理客户、分配任务、跟踪、监控日程, 以及指导团队的动向. 所有一切都根据计划紧密地实施, 并通过正规渠道进行反馈. 而敏捷方法则与此相反, 它把客户与开发人员尽可能地紧密联系在一起, 让客户对工作进行优先分级, 开发人员评估工作并协调两者之间的意见. 在这种情况下, 虽然项目经理的各种工作仍然能够正常进行, 但是在态度上却需要一个转变. 自始而终的信息透明 建立一个开放、坦诚的环境是所有项目经理的重要任务, 这需要从项目一开始就着手, 越早越好. 把信息分布到整个团队中可以让成员们较少地担心是否有什么重要的细节被隐藏. 一旦建立这种透明度, 团队的信任度就会提升, 他们自然而然地就会相信项目经理. 这是最理想的情况, 这样团队成员就可以专心于手上的工作, 无须担心前面是否有什么突发情况在等着他们. 具体来说, 这种氛围意味着团队及利益相关人之间可以通过一系列途径得到很好的沟通, 比如站立会议、回顾会议、重要的状态报表、非正式的会议, 还可以鼓励其他人提出问题. 这几乎可以与极限编程中的持续集成相媲美. 通过持续集成, 开发人员每完成一段代码就可以将其放入信息库, 对其进行一系列的测试, 并能马上得到状态报表(比如构建失败或是通过). 如果团队可以在一天内重复数次这种活动, 那么他们就可以极大地减少在发布代码时项目可能遇到的风险. 也可以说这是用每天一点点的小麻烦来避免通常潜伏到开发尾期才暴发的危机. 作为一名项目经理, 在团队的进展、处理问题和报表中都可以应用同样的原则. 项目经理应该尽可能多地听到一些"坏"消息, 比如延误、意外、故障, 或者成果, 这样才能对实际情况有个准确的认识. 通过在整个企业中推广这个原则, 而不对某些信息进行隐瞒, 团队遇到难以应付的意外的几率将大大减少. 并且, 实际上, 所有的问题都可以由团队解决——只要能够提前通知他们并给他们足够的空间. 只要放心地把所有的事实都告诉整个团队, 该调整的时候自然就会做出调整, 而通往成功的路也会更加平坦. 睁大眼睛, 张大耳朵 管理一个团队可以说是一项具有实时性的活动. 计划无法管理人, 只有人才能管理人. 时不时过来看一眼并不能称为参与, 而如果没有人帮助团队处理路上的障碍, 项目就很容易被一些无关紧要的东西缠住, 从而无法实现目标. 在理想情况下, 项目经理应该随时注意整个团队. 用眼睛去看、用耳朵去听当前正在发生的情况, 快速收集信息. 然后, 通过思考, 做出决定和行动. 通常正确的行动是很小的或者微不足道的, 但是却可以因为时机和环境情况而发挥非常巨大的作用. 说服、建议、询问, 这些都是比强权、命令和吩咐有力得多的武器. 如果涉及到两个或者更多的团队, 那就坐在他们中间, 或者最坏的情况, 在每个团队身上花费一定量的时间. 一个复杂软件项目的需求与方案的流动性也必须在管理方式上体现出来. 正确促进与辅助 在各个团队中, 都有掌握各个技术领域的专家来撰写正确的方案. 但是, 衡量一个项目是否成功并不是看它与计划书有多吻合, 而是它能否实现商业价值. 因此, 项目经理并不需要知道各种问题的答案, 他要做的是把每个人的想法放到方案中, 并且同时注意各人都喜欢做什么, 擅长做什么, 以及应该做什么——如果这三者达到一致, 那么工作效率也就得到保障. 促进团队成员互相正确地交流、帮助一个小组做出正确的结论, 或者扫清团队的内部障碍, 在这些过程中, 项目经理这个辅助角色应该注意个体的需要, 并通过每人分配少量的责任、详细地解释各个问题, 或者仅仅在他们完成一项任务时简单地赞扬来鼓舞成员的士气. 让项目经理成为多余的人 项目, 如同公司一样, 系统地进行才能带来最高的效率. 而这个"系统"与"已定义过程(definedprocess)"是不同的. 系统代表一种不是完全依靠某个特定人的做事方式. 所谓"不可或缺"正是一个系统的致命之处. 关键的、不可替代的, 以及稀有类型的人才都是巨大的风险, 通常也需要在这种人身上花费昂贵的费用. 所以, 我们应该考虑借助敏捷思想在整个团队中发展"冗余"性, 以及培养能够以一抵多的多面人才. 这包括团队的各个部门, 比如项目经理. 当然, 如果项目经理需要离开几个星期, 就应该找一个合适的人放到这个职位上. 但是, 如果只是离开一两天, 那就不应该为团队带来什么问题. 领导权与管理权可以分派给其他人, 如果信息是发散的, 或者至少是随时可得的, 瓶颈问题的影响也会减小. 开发人员以结队的形式提高信息共享度, 而这种做法完全可以推广到团队中的任何职业. 机警的项目经理必须注意当他们或其他人离开的时候, 整个团队会发生什么情况. 这时发生的问题都可以作为寻找团队弱点的参考, 并借此机会提高团队效率. 传统上, 项目经理会被认为是项目成败的唯一责任人. 由于不管是成功的荣誉或是失败的责任都没有广泛地分散出去, 自然也就导致项目经理的活跃性高于整个团队. 然而, 要最大地发挥整体团队的效率, 就要在团队及高层管理人员中灌输共享责任的观念. 项目经理可以通过消灭自我、分派责任来逐渐施加影响. 这并不是说要无视自己的业绩或者把它们拱手送人. 我们的主旨是要在团队中分享成功的奖励和失败的教训, 这样每个人就会自觉地把他们放在推动项目发展的前线上. 如果项目经理能够忽视他们自我的需求、追求整个团队的智慧, 并根据情况分派责任, 那么这种集体责任感就会随着时间慢慢地建立起来. 激励与保护团队动力 可以把团队想像成一辆在铁路上奔驰的老式蒸汽火车. 要让这个庞然大物活动起来自然需要花费一些时间, 但是一旦它开始奔跑, 其自身的动力就足够让它保持下去. 然后, 项目经理就可以把工作重点从添煤扇火(项目早期的内部活动), 转移到铺设铁路、保障火车速度(外部事务)上. 项目经理的任务是要创建一个能让各人发挥自己特长、编写方案以及解决问题的环境. 团队成员通常都希望能够在他们自己的领域中一展身手, 这种动力应该好好地加以利用. 然而, 任何企业的这种熵动力经常会把团队的最好意图变成一个错误——臃肿的会议、多余的文件、转换项目, 以及其它各种干扰都会极大地浪费团队资源. 有时候我们会发现: 非工作时间的工作效率很高, 而这并不是什么意外. 因为这时候基本上没有什么会议, 也无人打扰——只需简单地埋头于手上的工作. 可以参考这种环境建立一个在正常工作时间里更有效率的团队氛围. 最终的责任还在这里 尽管组织这种分散、系统化的团队听起来很先进、很开明, 但项目经理的最终目标还是要实现商业价值. 企业领导层会这样看待这种方式——它是一种方法; 是一套用来实现价值的工具与技术. 因此, 并不是说项目经理可以撒手不管, 把所有责任推给团队, 实现最大价值的最有效的办法还是创建一个真正高效率的团队, 能够主动消化需求的团队. 一个自主推动项目发展的团队远比一个被项目经理和任务推动的团队有能力. 项目经理永远是团队的关键人物, 但不应该是唯一的关键人物. 通过以上原则, 项目经理可以利用团队成员的共同目标和共生关系, 让各种角色协力合作, 创造出任何个体所无法比及的成果, 将项目管理于无形.
|
收藏
分享
有用
无用