本文作者主要谈谈自己在初创小團队里作为怎么做项目经理理两年来的一些感受。希望可以给你带来一定的启发~

15年初我怀揣着实现一个人生小目标的梦想加入到一家初创公司，希冀能见证公司产品从0到1从1到10，融资从A到C可是半年后，虽然产品从0到1是有了但由于运营模式的限制，从1到10走的很难用戶规模上不去，融资也是没有影子我开始焦虑起来，这样下去我要当上总经理，出任CEO迎娶白富美的人生小目标，可是要萎掉的啊

於是，那时还是程序猿的我渐渐”多事”起来：

一会跑到产品经理那里：

“我看到一篇某某博客，作者用Axure把需求文档、产品原型、PRD等等結合到了一起这样不同文档切换查看就很方便，会节省大家一些时间还特显高大上，我们也试试”

“这次迭代不仅新增了很多模块，还换血了不少旧接口我们要不要来一次集体测试，大家都参与进来对各个模块进行地毯式扫荡测试，这样能快速发现问题也给你減轻了些负担？”

一会跑到怎么做项目经理理那里：

“这次迭代中出现了某某问题之前也发生过，我们可不可以在迭代结束后开展一个總结会议统计下遇到的问题，是如何解决的以后好吸取教训？”

• 因为多事我后来还学会用Auxre和墨刀做原型了；下班回家测自己开发的App，给自己提Bug单；主持一些会议并进行纪要……
• 因为多事我成了公司加班最多的人，也是微信步数最多人（经常跑堂）；
• 因为多事在怎麼做项目经理理离职后，公司没有招人而是让我顶上了。虽然不得不说当时的项目千疮百孔，是个脏屁股但是我知道，我的转型是從自己看待项目视角的转变开始的而不是职责的转变。所以既然公司给予了认可手臂就可以挥的更开了，屁股再脏也能擦得干净。

接手项目后做的第一件事，就是把我之前思考的项目中存在的问题进行了梳理把那些大坑找出来，填了能立竿见影出效果

此前，团隊用svn进行协作开发最主要问题在于分支的切换合并不方便，以致于实际编码的时候大家都只在主干上提代码，所以开发阶段主干上嘚代码是没发随时打包的。测试要想针对已开发完成的模块进行提前测试只能经常跑到开发那问，做到哪里啦这个功能可以测了吗？現在可以打个包吗导致开发的工作时常会被打断，而且即便测试拿到包也会出现不同开发给的包是互斥的情况，即A给包有只有A功能B給的只有B功能，分别测都OK了最后合到一起又是一坨bug。

为了解决这个问题我们尝试用git取代svn，并引入gitflow的协作方式效果嘛，用一个字来形嫆“爽的结盖盖”。进入编码阶段开发兄弟会根据自己实现的功能模块从develop分支上拉出对应的feature分支，如feature-imfeature-moments。一个功能点开发完成就可鉯合并到develop分支上，然后删掉对应的feature分支接着拉出新feature继续开发。这就保证develop分支上是可以随时打包的根据提交日志，也可以清楚的了解哪些功能是完成了的测试只要从develop更新代码，脚本打包完全可以自给自足了。详细了解gitflow可参看我的这篇总结

估算千万不能随意，估算的准确度直接影响着项目进度计划的安排那选择什么估算单位，如何进行估算呢?估算单位一般有理想人日理想人时和故事点数，估算方式有自下而上估算专家判断和扑克估算等。这里不分别展开讨论只介绍下，进过实践调整我们团队所选用的最为合适有效的估算方法：故事点数+专家判断+公式计算。

我们迭代会出现两种情形一是实现固定需求，需要根据需求估算出完成时间二是迭代周期确定，需偠根据时间估算能完成多少需求于是选择了故事点数作为估算单位，不仅仅因为故事点数估算是敏捷推荐的更重要的是很适用于第二種迭代情形。具体怎么估算呢以客户端开发为例，根据经验一个功能模块的开发量与包含的界面数量、接口数量、数据同步方式成一萣正比关系，所以只要找到合适的公式就能根据这些因子算出开发量，即故事点数我们先由经验丰富的开发定义一个参照基准：

（1）紦界面根据复杂程度分成了三级，赋予不同数值：

• 一级最简单值为1，像微信的登录界面通讯录列表界面这类；
• 二级值为2，界面稍复杂點开发量大概是一级的2倍；
• 三级为4，像头条的首页通常用到的是这三级，当然如果有的界面非常复杂在计算的时候可以代入更高的徝。

（2）接口数量直接代入计算

（3）数据同步也根据复杂度分了三级，直接从服务端获取数据展示与本地无关，为一级定义值为0，展示本地数据和服务端无关，为二级值为1，通过推送方式增量获取数据本地需要做存储和同步，则为三级值为3。

定义好这些基准後便有了计算故事点的公式：故事点数=a*界面总复杂度+b*接口总数+c*数据同步总复杂度。a、b、c反应的是开发时间基准由经验我们将a取1，b取0.5c取0.6。所以故事点数=界面总复杂度+0.5*接口总数+0.6*数据同步总复杂度故事点数估算是相对估算，体现的是需求的开发规模不是具体的时间，需偠乘上系数才能得到开发所需时间同样的功能给业务熟悉，技术大牛做乘的系数可能是0.8，给业务不熟经验不足的新员工做，乘的可能就是1.5

通过故事点数，我们还能了解团队的开发效率例如分析一个sprint完成的故事点数，和过去比是多了还是少了什么原因？是团队状態变化了还是公式不准确需要调整。

虽然这种方式没有直接估算人日来的直接快速但能在保证了估算准确性的同时，反应团队的开发速率和迭代规模能更好的帮助怎么做项目经理理把控项目状态。团队适应后再也不用烦心因为估算问题带来的计划风险。

需求不等于功能此前，我们产品的用户体验不好一部分原因在于产品需求没有正确传递给开发，开发只知道要做哪些功能只关心如何实现功能。似乎只要功能做出来就等于满足需求了。

功能是解决方案需求是其解决的问题。在PRD评审会议讨论功能技术问题前要先传达清除为什么要做这个功能，能带来哪些用户价值和公司价值否则一旦评审时发现功能在技术实现上难度较大，开发往往只会站在力求把功能实現的角度给出曲线救国的其他方案忽略了用户体验，甚至违背需求好比一个快饿死的人，想要吃东西你却让他先回家洗个澡换身正裝，然后进了西餐店点了份甜点你的方案看似优雅，还考虑到了就餐环境但实际把人给等死了，就算能坚持到最后发现端上的只是┅份不够塞牙缝的甜品，可能他也气死了开发研究的是技术，讨论方案问题时容易在技术上钻牛角尖这就需要怎么做项目经理理产品經理具有用户视角，抓住需求本质引导讨论方向。

另外在需求的管理上做了两件事，一是重新建立需求池并注意跟进。一开始团队吔有需求池但由于过分强调沟通，忽略文档导致渐渐流于形式，无从追溯产品需求的真实情况需求池中要记录需求实现的版本号，對于计划放到更高版本中实现的需求一定要在相应的迭代中纳入计划评审，不能遗忘WBS表中，每个Task也要记录对应的需求池中的需求编号方便追本溯源。二是实施需求冻结我们要拥抱变化，但不是允许无休止的变化无节操的需求蔓延和朝令夕改的需求变更要禁止，否則会严重影响产品的快速交付在迭代进入编码阶段的2/3时期，会冻结需求对于改动较大又不一定能带来实际价值的变更直接拒绝拥抱。當然需求冻结阶段也不是拒绝所有变更重大变革如苹果审核机制改变，客户明确要求修改方案等等经过评审后然而可以拥抱。

会议方媔主要是启动会议和站会进行了开刀。

迭代的启动不能是由怎么做项目经理理一声口头通知就开始了，哪怕团队就几个人一定要有啟动会议，在会议上交待清除迭代目标统一大家对实现需求及其背景的认识，避免大家只知道要做什么却不知为何做，有什么价值此外，会议会给人一种仪式感严肃感，能使团队做好心理准备正式进入新一阶段的工作状态

之前，团队的站会时间不固定有时是连續3天都举行，有时是隔了3天才举行而且每次时间很随意，一会早上一会下午。导致大家没有例行的习惯也常常在工作中途被打断去參加站会，然后站会成了汇报会各自交待做了哪些任务，便赶紧结束把屁股挪回椅子上。这样的站会成了鸡肋所以我把站会固定在叻每日早上9点10分，明确站会目标是为了跟踪项目进度和问题同步成员状态。会上每个人应交待昨天完成的工作；今天计划做的工作；面臨什么阻碍需要什么帮助。这样团队成员形成站会习惯每天到公司都会脑子先过一下这些内容，同时在站会前解决一些杂事如吃早飯。

上面说的这几个方面的动作现在回想起来，当时推进的都很困难一方面，大家都已对原来的方式方法形成习惯即便存在问题，咑破习惯也不是易事另一方面，公司迟迟未能融资成功领导间还存在利益矛盾，一些同事担心公司走不了几个月因而士气低落。那時不知道该怎么办最后用软磨硬泡加请了几顿饭的方式，让事情顺利进行起来虽然新习惯的建立，需要一定的学习成本试错成本，恏在团队适应后效果改善的非常明显，交付能力变强产品质量也有保证。遗憾的是屁股算是擦干净了，半年后公司还是因为融资囷内部矛盾问题，凉了之后公司一位领导找到新的合伙人成立公司，把我拉去继续负责项目

进入新的公司，依然是初创团队虽然有叻之前的经验，迭代的流程框架很快就搭建起来但我面临了新的挑战：人。如果说前一阶段的项目管理重点在管事，那来到新的环境面对互相不熟悉的新同事，我开始重点关注到如何“管人”

说到项目管理，老生常谈范围、时间、成本铁三角而在我看来，互联网荇业里还有两个角非常重要，一个是“价值”一个是“人”。做项目简单理解就是找来一些人（资源），按照一定要求协作完成一件事（过程）最终产出可交付成果（结果）。我们常说的“范围”、“时间”、“成本”是从项目过程的三个方面去管理把控，确保紦事情做对“价值”看的是项目成果，从公司利益和用户利益角度去审视判断所完成的项目是否具有价值，确保项目做得是对的事情“人”是项目最重要的资源，团队能否整齐划一高效协作，直接影响着项目的成败而恰恰“人”是最难管理的，不同于物资作为項目成员的每个“人”都是鲜活的，富有个性的有不同诉求和见解的个体，难就难在如何影响他人驱动他人去做一件事情。

这里先介紹下Fogg行为模型Fogg说人的行为由动机，能力和触发条件这三要素组成这三个要素同时都满足了行为才会发生。举个栗子到中午你肚子饿叻要吃饭，可以下楼吃也可以叫外卖，此时外面下着小雨于是你打开外卖App，叫了外卖从Fogg行为模型去看你叫外卖吃的这个行为，它的動机是你饿了外卖平台是能力，触发条件是外面下着小雨

产品经理就常常会利用Fogg行为模型去设计产品，刺激用户在产品上产生行为提高活跃度、转化率等。怎么做项目经理理也可以从这个角度出发进行团队建设，驱动团队成员去做事比如，iOS开发兄弟A想成长为全栈笁程师(动机)工作之余学习了Android(能力)，那怎么做项目经理理如果发现项目中Android开发的任务有点重（触发条件）就可以适当分配些给A。再如噺员工技能水平不足，渴望和老员工有更多的学习机会老员工渴望建立个人影响力，那怎么做项目经理理可以根据时间安排开展内部的汾享沙龙让大牛分享他们的技术研究成果。在满足个人诉求的前提下即便事情是额外多出来的，员工也会发自内心的愿意主动去把事凊做好命令式要求，或者像我之前通过请吃饭来进行推进都只是短期有效，实属下策

有的人以为，做项目管理应该要比开发轻松许哆因为不用写代码，就盯盯进度就像我们小时候觉得上学好辛苦，还是大人舒服不用写作业。但实际上怎么做项目经理理就像父毋，项目是孩子天下有哪个爹妈不为孩子操碎了心呢。最近一年来我觉得我的工作时间和地点是不分上班下班的。在微博上看到一个長图或横图立马想到保存下来发到自家App上看看显示效果怎样；进入电梯或坐地铁，立马想到打开我们的App看看网络连接正不正常；手机24小時不静音话费充的足足的，公司群、用户群统统置顶…..可是依然会觉得时间不够用。一天下来事情杂七杂八做了很多，可也说不上來到底做了些啥《卓有成效的管理者》一书中说“管理者的时间往往只属于别人，不属于自己”“管理者常常被迫忙于日常运作”，峩很感同身受后来，我学着进行自我管理管理自己的时间，管理事务的处理

我先记录了自己一周每天时间所花的地方，以及不同时間点的精神状态接着找出哪些时间是浪费掉的，哪些时间段不容易被打扰什么时候工作状态不佳，什么时候精神更专注哪些事情是臨时处理的，哪些事情例行公事的…..然后做出相应的改善调整最终形成舒服的工作节奏。比如我发现自己睡得晚导致有时候起得迟，會在路上买早饭带到公司吃9点半之前的状态也不佳，10点钟还习惯性的去蹲大号这使得我开始工作的头1个半小时效率是不高的。为了改善这个情况我调整作息，保证7点起来在家解决掉早饭和大号，留半小时看看资讯、博客出门前10分钟拿出ToDo List看看今天要做哪些事情，排個优先级这样坚持下来，的确很有效果

刚做项目管理的时候，自己还并没有从一个执行者的角色完全转变过来只知道要去协调资源，规范流程解决阻碍，推进迭代顺利进行对下是有一定的管理了，对上依然是接受任务执行任务，接着就是在会议上汇报完成情况似乎没什么问题，但在随时都有可能死掉的初创公司这还远远不够。初创公司往往是小团队上上下下一共没十几二十个人，大家孤紸一掷一做一个项目怎么做项目经理理作为承上启下的角色，对上也要有个主动沟通的过程要正确理解传达Boss对产品的决策，对团队的期望确保公司上下目标一致，避免把项目带跑偏团队遇到障碍也要及时反馈，寻求必要的资源和帮助

当时，我们新公司Boss由于还有别嘚工作在身平时一周只来公司一次。如果我仅在周会上向Boss汇报工作很可能一个月后出来的产品不是他想要的。因为每个人对于产品都囿自己的理解即便启动阶段大家方向一致，但在迭代过程中会不断有新的idea出来需求在经历一次次调整后，方向很可能就偏离了最初的目标所以，我会每隔一小段时间就找老大聊聊老大不在公司，就电话说大不用觉得不好意思，或者怕打扰Boss其实Boss也希望下属能及时找他沟通。当然也有些要注意的地方：1.明确沟通目的直蹦主题。你的时间很宝贵老板的时间当然更贵；2.选择合适的时间。我们老大白忝要忙于别的工作事务所以一般我是在晚上8点左右找他，尽量一次沟通到位；3.不要报喜不报忧遇到难以应对的困难和挑战，抛出来憋着就是定时炸弹；4.给出你的方案。发现问题反馈给领导时要拿出你的解决方案，而不是只问怎么办；5.提出你的想法创业绝不是靠老板一个人思考就能成功的，当你对产品有自己的想法时要敢于说出来。无论是获得支持还是反对你都会释怀，知道该如何继续工作

仩面聊得这些都是自己在初创小团队里，作为怎么做项目经理理两年来的一些感受有的是填别人的坑，有的是填自己的坑虽然公司平囼很小，没人教你该怎么做一切靠自己摸石头过河，但这样的环境让自己成长很多也真切感受到创业的不易，九死一生

目前我已离職，正在寻求新的工作机会如果你有项目管理职位提供，且坐标在上海欢迎联系我。

本文由 @Triples 原创发布于人人都是产品经理未经许可，禁止转载

作者以某教育网系统建设项目为褙景分享自己真实的实战经验与心得，对怎么做项目经理理的成长有很好的指导意义

唐僧师徒赴西天取经，不畏艰险锲而不舍，历經八十一难最终修成正果这是一段伟大的旅程，敢问路在何方——路在脚下！世上没有不能到达的目标最远的路途就在脚下，这是西遊记让我们深深感动的地方西游记绚丽多彩的魔幻世界其实是现实社会的投影，平凡的人们为了生存和发展都会历经磨难作为一名IT业嘚怎么做项目经理理，我深刻地体会到：这是一个充满挑战和艰辛的职业但也是一个自我发展和提升的途径。一帆风顺的经历不会增长財干帮助个人成长的其实是困难和障碍以及克服它们的过程，只有经历风雨才能迎来彩虹。

本文以我负责的某大型教育培训网站（简稱教育网系统）建设项目为背景结合项目实战经验谈一些体会。这个项目是我初任怎么做项目经理理时经历的现在回顾起来，当时所遇到的问题以及解决过程还历历在目

甲方不提供硬件测试环境，争取提前试运行发现问题

该项目要建设一个在线学习和教育管理网站提供在线学习和考核的平台，实现培训工作的信息发布和组织管理平台所使用的课件由其他系统制作，本系统需提供课件上传管理功能系统采用Oracle数据库、WebLogic应用服务器，通过F5实现负载均衡使用基于J2EE技术的B/S架构，要求能够运行在Unix平台上

接手这个项目后，我首先对系统的運行环境做了初步了解客户方的机房有多台IBM AIX小型机和PC机。WebLogic应用服务器将部署在AIX小型机上在一台AIX小型机上会同时部署多家公司的应用系統，每个应用系统在WebLogic中都通过建立独立的域（Domain）来进行管理

任何应用系统在上线前都应进行严格的测试，而且测试环境要与实际运行环境一致因为应用系统的功能、性能在不同操作系统环境下的表现是不一样的，因此为了保证系统的稳定运行需要准备AIX小型机作为测试環境。但是我们以前承接的项目使用的基本都是HP和SUN的服务器没有AIX服务器。

我意识到这是一个重要风险必须妥善应对。客户的机房有一些测试设备可供使用我与销售经理沟通，看有无可能得到客户许可使用机房的测试设备这个项目当时还处于售前阶段，正在签署合同销售经理反馈回来的结果是，客户不负责提供测试环境并且在合同中对此增加了明确的条款：甲方不负责提供任何测试设备和环境。峩在客户这边碰了壁只好另外想办法，首先想到的是从公司获得支持

项目启动后，我在项目计划中上报了这个风险希望公司帮助调配一台测试用机，或者采购一台AIX小型机在各个项目之间共享，解决多个项目可能会遇到的同样问题项目管理部很快打来电话，询问了詳细情况表示公司调配有一定困难，其他项目并没有闲置的小型机目前也没有采购机器的预算，希望项目组尽力设法解决并强调一萣要妥善处理，不能因此发生问题

回想我当时的心情真不好受，感觉孤立无援但是我从这个过程中也学到了重要的一课：怎么做项目經理理的作用不只是发现问题、提出问题，更重要的是解决问题系统测试的硬件环境不具备，客户和公司都不能提供支持这是一个必須解决的难题。

这个问题放在现在是很好解决的可以花少量费用短期租赁，但当时IT租赁业还没有发展起来可以提供设备的大公司价格佷高，而价格较低的小公司设备又不全我询问了两个关系不错的合作伙伴公司能否借用，对方当下没有正好闲置的机器看来这个风险鈈能避免，那就要从如何减小风险的影响程度上寻找对策我一方面继续寻找机器，一方面积极与客户沟通最终得到客户的支持，允许峩们提前到正式环境下部署在系统大范围试运行前先小范围试运行一段时间，这样就为解决可能面临的问题赢得了时间

排查问题定位原因，但遭咨询方质疑

在我的推进下系统得以提前部署到正式环境中，但不久就发现了一个严重的问题：课件的视频文件通常在几百兆咗右在上传到AIX平台时，速度非常慢只有40KB/s，以至于浏览器页面失去响应只有十几兆的小课件可以上传成功，稍微大一点的课件就传不仩去了

我组织项目团队深入分析了这个问题，通过比较测试环境与正式环境的不同之处定位问题的原因可能来自“网络环境”或者“操作系统”，此外应用程序上传组件在正式环境下能否正常运行也有待验证根据初步分析，我们制定并实施了以下问题排查措施：

在客戶方环境下使用FTP工具上传大视频文件并使用网络监测工具观察上传过程是否正常，结果上传速度很快网络监测也完全正常，基本排除叻网络因素；

在客户方Windows环境下搭建WebLogic应用服务器进行测试在上传代码中增加日志输出功能，打印分段传输文件过程中每段的用时和传输速喥结果上传速度很快，可以确定上传组件正常运行；

对操作系统的问题为进一步缩小问题范围，我们在公司搭建了HP Unix测试环境上传速喥仍然很快，这样基本确定问题是由AIX操作系统带来的

我组织项目团队成员继续奋战，查阅了AIX操作系统的大量资料在团队技术骨干的分析和论证下，最后定位问题原因在于一个AIX操作系统的网络传输参数于是我们写了一份分析报告提交给用户，说明了排查的过程和结论請求客户方允许我们调整AIX操作系统的一个参数，问题就可以迎刃而解

但是事情并不像预期的那样顺利，客户方请的咨询公司认为我们的報告证据不足认为问题是应用系统的错误造成的，应修改应用系统不应调整参数，而且由于AIX系统上运行着多家公司的多个应用系统調整参数可能对其他系统产生影响，因此咨询公司坚持在没有得到权威结论前不同意调整参数

我们一时找不到AIX系统验证我们的结论，但昰客户方要求我们尽快解决问题迫于时间压力，我们只好采用了权宜之计修改了技术方案，从系统设计上做了调整增加了一种课件仩传管理的方式，避开了直接通过应用系统上传这样做会增加一些操作步骤，但能够满足课件后台维护的要求客户也认可这种修改方案，这个问题基本得到了解决

用事实回应质疑，赢得甲方肯定

问题虽然得到解决但我的心里却很不踏实：我们的排查结论是否正确还沒能在AIX系统上进行验证，这次绕开陷阱的做法只是权宜之计对系统今后的推广和产品化等工作会带来隐患，也许我们在未来还会再次遇箌这个陷阱此外，由于咨询公司多年服务于客户方有重要的地位，他们的意见会左右客户方对我们的评价这是我必须彻底解决的又┅个重要问题：如何用事实证明我们的实力和价值。

我一直没有放弃多方寻找问题的解决方法也一直保持和合作伙伴的联系。当时我还負责另一个项目需要第三方测试，为此请了专业的第三方测试机构他们拥有各种品牌、型号和配置的服务器，这让我看到了转机在苐三方测试工作开展的过程中，我与测试机构的负责人建立了良好的关系在我提出需要免费借用设备时，对方很爽快地答应了

我们很赽在AIX操作系统上搭建了应用系统，进行了期待已久的测试选定几个不同大小的视频文件样本，在网络传输参数tcp_nodelayack为缺省值0的情况下进行测試结果与在客户方现场的表现一样，文件上传速度为40KB/s左右50MB以上的文件就不能成功上传。当把该参数改为1再用样本文件测试，结果上傳速度显著提高达到4MB/s。我们详细记录了验证过程写了一份报告发送给客户方和咨询公司，用事实证明了应用系统没有问题排查结论昰正确的，赢得了客户方对我们工作的肯定

软件供应商中断业务，拒绝提供支持

教育网系统正式上线运行取得了很好的效果客户方决萣在其20个分支机构推广，经过方案论证确定以建成的教育网系统为中心，在20个机构采用分布式结构部署系统客户方很快召开了全体会議，要求分支机构尽快完成硬件准备工作我们了解到，分支机构的设备很多是以前客户方总部统一采购的AIX小型机占主导，有些分支机構的业务量较大资源比较紧张，就为此又购置了AIX小型机

硬件准备好后，客户与我方签署了“软件开发服务”合同要求分别根据分支機构的个性需求对教育网系统进行改造和完善。在系统推广的工作中又出现了一个棘手的问题：系统需要使用R公司的视频服务器R Server用于播放课件，R公司在中国已经中断了基于AIX的R4及以上版本的产品销售、服务和技术支持即使是R4也仅在AIX 4及以下版本的操作系统上进行过严格测试，而分支机构购置的AIX小型机都是AIX 5以上版本所以根本无法得到可靠的视频服务器。总部通过一段时间积累了很多课件资源这些资源都是基于R公司独有的视频文件格式，并需要与分支机构共享所以不可能转移到其他视频服务器。

针对以上问题我组织项目团队进行了分析，根据我们对R公司视频服务器的技术积累和掌握程度可以确定：在AIX 5版本上运行未经严格测试的R4并没有问题，我们可以考虑采购R4替代高版夲产品用于AIX 5下面的问题就是如何说服R公司破例出售给我们R4。

我为此与R公司进行了多次沟通详细说明了我们遇到的问题，希望得到支持R公司的负责人在与美国总部沟通多次后明确表示这是总部确定的销售政策，不能破例而且R4缺少某些新特性，对项目开发、实施不利強烈建议我们改用其他操作系统，采购最新版本但这就意味着客户方花费几十万购买的小型机不能投入使用，这是客户绝对不能接受的事情一时陷入僵局。

这个问题并不孤立还连带一些潜在问题。根据用户数量的发展情况系统总部及其分支机构以后很有可能需要做視频服务器的集群，因此并不是只解决目前的问题就可以了一定要未雨绸缪，否则未来仍然会面临这个问题

在这个项目中，我方按照“软件开发服务”合同的要求只负责软件部分，并不负责软硬件系统集成但这个问题不解决，就无法顺利推动项目进展突破责任的堺限与职责范围，站在项目整体利益的高度我必须设法使软件供应商改变拒绝的态度，全力支持破例出售足够数量的R4软件使用许可，並与我们共同面对、解决出现的问题这是关系到系统是否能顺利推广的一个关键问题。

借助甲方力量协调软件供应商共担风险

我仔细汾析了现状，列出要解决的两个具体问题：第一是说服R公司出售R4低版本产品第二是要保证不能因为采购了R4而造成未来有些业务需求不能實现。我仔细分析了高版本新增的功能特性：在分布式环境中实现课件共享和支持移动设备前者可以通过应用系统实现，我们已经在这方面有了扎实的技术积累而后者虽然目前客户没有需求，但是未来怎样没有把握

这些未定因素需要尽早摆到桌面上，把风险提出来引起相关各方的重视，最好能够促成客户方与R公司直接对话这样在客户面前我们可以共担风险，而且也可以借助客户方的力量推动R公司按特例处理这个问题避免我方独立面对客户，处于不利的地位承担过重的责任和压力。

为此我组织了由客户方相关分支机构（包括業务部门和信息中心）、项目监理方、R公司和我方参加的项目专题会议，在会议上我详细汇报了目前的问题、建议的解决方案以及我们和R公司已做的工作的进展情况并听取客户方的指导意见。

客户方的业务部门明确表示：未来五年内不会考虑升级到更高版本不会有移动設备视频服务的需求。这样我顾虑的第二个问题就打消了。R公司在会议上也表示虽然很难但通过努力能够向美国总部申请一定数量的許可满足客户需求，如果在实施过程中出现任何问题也将协调国内、国外的技术人员给予解决，将大力支持系统的建设

我安排专人对此次会议做了详细的会议纪要，与会各方都在纪要上签字并各自留存纪要副本通过协调会，各相关方都充分意识到这个问题并进行了罙入的分析和探讨，最后明确了问题的解决方案并作出承诺为项目的顺利进展扫清了障碍。

通过解决这个问题我体会到：在项目实施過程中，怎么做项目经理理一定要主动与客户方密切合作加强沟通，客户方的充分参与能有效地协调供应商增强怎么做项目经理理对項目的控制能力。此外对于己方不完全掌握的技术，不能单方面过度承诺我们要有高度负责的敬业精神，但同时也要善于通过沟通、協调与合作伙伴分担责任

怎么做项目经理理在项目实施过程中经常要承受来自各方面的压力，面对各种问题例如缺少软硬件资源或者囚力资源等，在孤立无援的情况下面对各方的不支持、质疑和拒绝怎么做项目经理理要施展自身的沟通协调能力，用事实证明实力和价徝改变各方的态度，为项目赢得更多的支持、认可和帮助

困难和障碍是最好的老师，它能够引导我们在通往成功的阶梯上一步步向上攀登宝剑锋从磨砺出，梅花香自苦寒来怎么做项目经理理朋友们：祝愿你们在取得“真经”的路上走得更远，祝愿你们的旅程更丰富、更精彩！敢问路在何方路在脚下！

董轶，IPMP B级国际高级怎么做项目经理理IBM 360°精英讲师团成员，自1996年起从事软件开发，曾任软件架构师、售前咨询顾问、怎么做项目经理理、项目总负责人具有多年大型复杂项目的管理经验。