从软件工程的发展历程中，不难看出软件项目管理的发展痕迹。早期的软件规模并不庞大，依赖一两个疯狂的极客就能交出几近完美的软件作品。在世人的眼中，那个年代的软件开发充满着神秘的色彩，程序员似乎也头顶着耀眼的光环，他们的心中总有着一个扭转乾坤，力挽狂澜的英雄梦，我称那个时期为软件开发的个人英雄主义时代。
大概在上世纪六十年代，大量的软件项目开始延期，并严重超出财务预算以致软件项目以失败告终。究其根本原因在于软件的规模和复杂度与日俱增，之前那种程序员之间各自为战，自由发挥及缺乏沟通的合作模式已无法交付出高质量的大型软件系统。彼时，学术界和产业界开始反思，并不断地举行各种讨论，最终提出软件工程的概念。简而言之，就是要用工程化的方法来规范软件开发活动，提高程序员团队交付高质量大型软件的能力。而要实现这个目标，探索高效的项目管理方法是每个软件开发团队的必由之路。
前辈们基于丰富的项目管理实践，已经高度地抽象出一套系统的项目管理方法论指导项目实践。然而，要深刻的体会它，仍然需要从实践中去思考和升华。具体到软件项目管理而言，就是为了在有限的资源和计划的时间内交付高质量的软件系统。而高效项目管理的价值就在于降低内部沟通损耗，让每一个团队成员朝着共同的目标而努力，提高项目的成功率。理想情况下，团队的力量等于团队成员的力量之和，这表示团队内部是没有内耗的，犹如所有人都朝着同一个目标努力一样。围绕着这个宗旨，高效的项目管理在实践过程中主要体现为做好三件事情：探寻合适的软件开发模型、处理好项目干系人的关系以及打造严肃活泼的团队文化
一、探寻合适的软件开发模型
在软件项目管理的过程中，采用合适的软件开发模型对于提高团队协作效率，按时交付高质量的软件项目至关重要。前辈们总结了一系列经典的软件开发模型供选择，如瀑布模型，增量模型、螺旋模型以及近年风靡全球的敏捷开发模型等等。然而，实际项目开发往往不容易照搬经典的软件开发模型，而应该结合项目的实际情况及所处环境，基于一种经典的软件开发模型，进行裁剪之后形成“本地化”的软件开发模型指导项目实践。诚然，抛开具体环境很难给出一套放之四海而皆准的软件开发模型，但不可否认确实有些指导思想总是值得借鉴。在裁剪出一套有效的软件开发模型时，应该重点关注以下三点：
第一，人尽其才的合作环境
项目的成功依赖于每个团队成员的努力，而有效的软件开发模型应该在机制上鼓励每个团队成员发挥主观能动性以及内在的潜力，以便同心协力地推进项目执行。实践软件开发模型的过程中，可以设置一些特定主题的会议，比如产品设计类、技术讨论类以及测试类，使相关领域的同事可以在会上畅所欲言地表达所思所想，为更好地执行项目献计献策。有一句中共宣传部门经常说的话非常有道理——“内部讨论无禁区，对外宣传有纪律”，非常值得我们讨论问题时借鉴。
从思想意识上，每一个团队成员应该创造一切条件，努力让身边的同事发挥自己的特长和兴趣，以主人翁的态度帮助公司和业务用户解决问题，以期成就项目的同时也成就自己。人尽其才的环境形成，除设置相关的制度以外，尤其需要项目经理的表率作用，以实际行动破除项目组内的权威意识，唯此才能创造人尽其才的环境。在管理学里面有很著名的X理论和Y理论：X理论认为员工是懒惰的，需要项目经理时刻地监督员工;Y理论认为员工是勤奋的，会进行自我管理，项目经理只需要帮员工解决后顾之忧即可。其实，软件项目极大的依赖团队协作和人的因素，如果团队成员发自内心的对项目不感兴趣，即使再监督他们，项目也做不好。而应该以Y理论的理念来管理团队，激发每个人的兴趣，从而推进项目执行。
第二，尽量扁平化的沟通模型
项目组内只能有权威的制度，不能有权威的专家，做到观点让人心服，而不是命令让人口服。形成这种群策群力的氛围，最有效的手段莫过于建立扁平化的沟通模型。从制度层面保证每位团队成员可以自由地提出自己的观点和意见，并通过相应的渠道让其他同事知悉，而无论该同事在项目组内的级别高低。具体到分配任务时，切忌项目发起人将任务分配给项目经理，项目经理再分派给技术经理，技术经理最后将任务分配给开发人员，而开发人员连发表自己意见的机会都没有。这种等级森严的工作模式极易导致进度安排脱离实际，即项目发起人拍拍脑袋决定了项目范畴，项目经理拍拍胸脯承诺项目进度，技术经理拍拍大腿完不成了任务，开发人员拍拍屁股不干了。
推荐的做法应该是项目发起人和项目经理确定项目范畴后，由一线的开发人员在规划讨论会上与项目经理、技术经理及其他同事充分讨论后，合理地评估工作量，项目经理基于不同开发人员的权重计算出工作量的平均值，再以专家判断的形式来评估其合理性，最终制定合理地项目进度。通过这种扁平化的沟通方式，一来可以让团队成员在团队中更有存在感和带入感，二来可以让项目更“接地气”地往前推进，否则只能是大家一起“胡夸风”、“放卫星”，三来可以避免项目组内出现信息黑洞，导致信息传递不通畅。
第三，充分利用优秀的项目管理工具
优秀的方法论需要内化到项目管理工具中后，才能更好的发挥其威力，并得到更好地执行。反之亦然，只有存在优秀项目管理工具支撑的方法论，才是经过实践检验，且行之有效的方法论。借助业界优秀的项目管理工具来执行项目，可以有效地提高项目制度化水平，避免软件开发模型执行时人为的“取巧”导致执行效果走样的情况，同时将一些有规律可循的“脏活累活”(诸如缺陷数量统计、团队成员工作负载等)通过工具实现自动化，将团队从琐碎的事情中解放出来，潜心聚焦于解决业务问题。诸如项目跟踪、知识分享、持续集成及源代码管理都有不错的软件工具支持管理。
上面说了这么多，在实际工作中，是否有推荐的软件开发模型呢?百闻不如一见，这里介绍下我们经常采用的软件开发模型，不一定完全适合你，只是希望这种思路可以起到一定的借鉴作用。
二、处理好项目干系人的关系
探寻合适的软件开发模型主要是确保我们在正确地做事情，而如何保证我们在做正确的事情则需要项目经理努力创造一个良好的项目外围环境，具体表现为处理好与项目干系人的关系。根据PMBOK第四版的定义，项目干系人是积极参与项目或其利益可能受项目实施或完成的积极和消极影响的个人或组织(如客户、发起人、执行组织或公众)。同时，衡量项目成功的标准无非两条：主观上干系人满意及客观上完成项目目标。所以，项目经理应该在项目立项之前尽量识别出所有的项目干系人，并且做到项目干系人的利害关系和重要程度心中有数，以便在项目执行的过程中平衡好各方利益。抛开具体的项目，我们无法穷举出所有的项目干系人，况且随着项目所处阶段的不同，项目干系人也会动态的变化。在此仅列出在各类项目中通常都比较重要的两类干系人以及可选的相处之道——项目客户和高层领导。
第一，维护良好的客户关系：项目的成果最终会交给客户，毫无疑问客户主观上的满意对项目成功与否至关重要。
1. 学会倾听客户的心声，但拒绝“唯命是从”。众所周知，在业务系统中，客户绝对是业务领域的专家，但是要明确一点，软件项目团队是提供合理的IT解决方案的专家。意识到这两点对我们与客户沟通时非常有必要。在与客户进行需求沟通时，我们需要学会去理解客户的业务本质，分析客户的痛点，然后再转化为计算机语言。关于如何通过信息技术手段来满足客户的需求，则需要学会引导客户理解IT解决方案，不要让客户告诉你如何解决。倘若福特对客户需求“唯命是从”，他应该去饲养千里马，而绝不会发明对近代文明影响深远的汽车。
2. 定期的组织团队成员和客户一起活动。人们在放松的环境之下较之严肃的工作环境更能碰撞出友情的火花，一旦存在友情，相互之间的信任也将随之而来。所以，项目在取得一些阶段性的成果时，应该组织团队成员和客户一起活动。活动的类型有很多，宗旨就是一条：可以让大家尽情地放松、放开，甚至“放纵”。比如：KTV“叫兽”，野外聚餐或者滑雪等户外活动。通过这些工作以外的事情，往往能够更好地建立项目团队和客户的相互信任。这对解决项目中一些似是而非的问题，非常有帮助。
3. 以快速迭代的方式，持续交付项目成果。这一方法似乎在敏捷开发中常被提及，其实它对维护客户关系也非常重要。我们的工作应该尽量不要让客户想、不要让客户等、不要让客户烦。而快速迭代这种“小步快跑”的方式正是满足这三条原则极好的方法。给客户汇报进度时，相比发送那些繁冗的需求、设计以及进度计划等文档材料，一个简单的Demo更让客户感觉易懂、直接和亲切。
第二，争取高层领导的支持：高层领导对项目的态度直接决定项目所能获得的资源多寡和优劣以及获得支持的力度。
1. 定期的邮件汇报机制。显而易见，要想领导想着我们，我们就得先想着领导。众所周知，领导的事物繁杂，不可能天天只关心某一个项目。如何能够让领导在繁忙的工作中还能了解项目的进度，而又不至于被打断手中的工作。定期的邮件汇报制度是非常有效的手段之一，领导可以在方便的时候查阅进度，并适当地给予一些指导意见。如果做的更加深入一点，发邮件的时机可以做些文章，观察领导一天的作息情况，尽量选择领导作息不忙的时候发送邮件，以免邮件淹没在邮箱中，没有被领导阅读。
2. 邀请领导参与项目重大问题的决策。项目组内的常规会议，不用邀请领导参加。而当会议需要讨论涉及项目战略的问题时，则一定要有领导在场时才进行。同时，应遵循大会办小事，小会办大事的原则，重大会议除领导外应只邀请项目组内核心的成员参加，并且应该事先总结出两套以上的解决方案供领导参考。理由有三：只有领导在场，才能确保做出的决策顺利执行;只有领导在场，才能保证领导一直能跟上项目的节奏，从而提供相应的帮助;也只有领导在场，才能充分发挥领导的丰富经验，帮助项目组做出明智的决策，他也能找到参与感，对项目“视如己出”，从给予项目更多的关注。
3. 及时地汇报项目成果。柳传志曾告诫联想人：“光说不练是假把式，光练不说是傻把式，能说会练是真把式。每一个联想人都要能说能干，做真把式。能说不能干对企业没有用，能干不能说等于没本事把自己推销给别人。”，对于项目管理同样如此。当项目取得的阶段性成果时，应及时向领导汇报，不要过于追求完美主义，应学会优雅降级，尽快地将团队的成果展示给他，让他感觉到这个项目做的不错，如此才能保证项目稳步地推进。
三、打造严肃活泼的团队文化
人是重感情的动物，富有战斗力的项目团队一定是让团队成员的感情有所寄托的团队，而感情的培养则有赖于严肃活泼的团队文化。提到文化一词，可能会觉得有点假大空。那么何谓有文化的团队呢?其实，判断的标准很简单——当你问团队成员是否喜欢现在的团队时，他能迅速地用一句话告诉你喜欢以及为什么喜欢。纵观国内外著名的科技公司，如Google, 微软，IBM以及国内的互联网巨头BAT等，他们的团队文化中都有着既严肃又活泼的元素，具体表现为工作时严肃认真、娱乐时活泼开朗。
关于团队文化，我非常喜欢在微软实习时，同事们经常说道的一句话：“Work Hard，Play Hard!”——工作踏踏实实的做，娱乐痛痛快快的玩，这与严肃活泼的团队文化其实是异曲同工的。作为项目经理应该有打造严肃活泼的团队文化的意识，在团队文化的建设过程中发挥积极主动的作用。“严肃活泼”只是简单的四个字，然而在执行的过程却有诸多细节需要考虑。比如说Scrum敏捷开发每天早上都有站立会议，如果总有团队成员迟到怎么办?
首先，迟到的习惯肯定是要杜绝的，迟到的人对那些准时参加会议的人而言是浪费他们的时间。如果不惩罚，对团队纪律是破坏性的，久而久之其他人也会开始迟到，这是典型的破窗理论。其次，采取何种惩罚措施?要知道惩罚只是手段，根本目的是要“治病救人”，在这个场景中就是让大家都能够按时到会，过于上纲上线有点桥枉过正、让人觉得缺乏人情味，这对项目组而言也是不利的。实践的过程中，我们采用迟到的人请大家喝酸奶的方式杜绝迟到，即达到提醒迟到者的目的，又不至于让迟到者太难堪，甚至还有些许团队建设的效果，大家喝酸奶时开开心心的，心里告诫自己千万不要迟到，否则要花银子买酸奶。其实这就是严肃活泼团队文化的具体体现。此外，除要和客户一起活动外，项目团队更要定期地组织团建活动。选择一个放松的环境和方式，培养同事之间的“战友情”，使每个人都放心地将“后背”交给其他人。
采用合理的软件开发模型，选择有效的项目管理工具，在一个和谐的项目外围环境之下，加之严肃活泼的团队文化，如此的项目团队不愁执行力不强，相信一定可以攻坚克难，披荆斩棘，开天辟地做出优秀的软件产品。
自我介绍：周伟，毕业于北京某大学计算机软件专业(本科)、北京某大学计算机软件专业(硕士)。在读研期间，曾加入微软亚洲研究院从事地理人生(GeoLife)系统的研发工作，独立开发的旅游路线规划功能已集成到微软旅游指南中，至今服务着广大网友。2010年毕业后，加入中国某大型金融公司主要从事金融业务系统的研发、设计和项目管理工作。金融行业与钱打交道，金融业务系统必须具备极高的稳定性、安全性和正确性。目前，主要负责私募股权投资领域系统的项目管理和系统设计工作，并专注于互联网金融的研究。
|
探索高效的项目管理（原创：周伟）