结束引子，拉回主题。最近一段，byteh同学感觉自己工作中的压力增加，所在团队负责的项目成为公司的战略重点，免费用户和收费用户都日益增多，部门内也对人员进行了一些岗位调整(无人离职)，从立项就参与项目的人员只剩下我自己了。原来自己最多算个主力，干好自己的事情再多做一些事情基本上就可以获得“好评”了。良性发展的企业，公司在成长，团队也在成长，员工也必须成长，组织对于个体的要求和标准也是与时俱进的，你是不可能向一些“吃皇粮”的单位那样几十年一直在平凡的岗位上坚持“奉献”的。团队决定把byteh同学推出来负责项目开发团队，履行一个项目经理的职责：对外沟通协调、对内负责团队建设和项目进度。

　　机会和压力并存，能否像前负责人那样把事情做成做好，能否把自己的能力得到应用和提升!做不好，离自己卷铺盖走人的日子也就不远了，混日子应该不是我目前的心理素质所能接受的，再说了，business is business!

　　年后实际上就开始做相关的事情了，从一开始周报中经常出现的“*可能的挑战*：若干事务同时进行，做到有序不乱!”到这些字逐渐消失，自己还是用了一些时间去努力的。有时候发现，事情还真的比自己原来在传统软件公司多，怪不得传统软件企业干不过互联网企业，呵呵!

　　在自认为能够应付整个工作的时候，一场信任危机爆发了!

　　公司大boss口头传达了一些需求，需要转化为产品文档并开发落实，产品部门只是知道却并不管这件事，于是理解需求和整理产品文档的事情也到了我的头上。很显然，大boss的需求和当前产品部的思路是不一致的，他们上期提的需求包含了大boss的思路，但是在我们开发工作几近完成的时候，取消了这个需求，代码进行了回滚。如果我按照大boss的思路完成产品设计，那么运营人员该如何去用?

　　1、尽管大boss态度比较强硬的说这不是我应该考虑的，但是我还是去找了产品部的负责人，和他商量具体做法。看似明智，但实际上在这里我就犯错了，为之后的事情埋下了伏笔……

　　2、产品部的负责人当然还是希望首先不影响现在的业务运营，商讨出了一套解决方法，能满足大boss的要求，但是思路截然不同。文档初稿写好后，征求了些意见，但改动不大，给大boss发邮件并没有得到回复……

　　3、开发日临近，测试用例会上大boss没有参加，过完用例开始设计开发……

　　4、开发日，看到大boss出现，赶紧去找，发现大boss并没有时间看文档，我开始一对一讲解需求，有机会第一次和大boss单独面对面……

　　5、大boss对于我不理解他的需求表示出了不满，局面一度让我无法控制……

　　6、拉来了产品负责人和原有负责人帮我一起与大boss“理论”，推出了新的实现方式，实际上是原有需求的综合版……

　　7、大boss敏感的推断后，向部门负责人“表示”了压力……

　　最后一点是我所没有想到的，byteh当时并没有觉得这个事情会严重到使外界对于整个项目团队产生怀疑和不信任，但是之后的团队内和我的谈话还是使我认识到了这一点。总结几点吧!

　　1、角色转换

　　这句话不只是挂在嘴上，在行动中更要注意。在和非技术出身的人员讨论需求时，一定要忘掉自己是技术，站在业务角度去思考业务可行性，而不是技术可行性。曾经和一些客户、部分销售沟通愉快，以为自己不会存在技术人的那些“习惯”，当面对更强势或者说比自己更了解产品的人，还是会走到发扬“优良传统”的路线上。(曾经写过文章《你们需要客户端吗?大话软件企业的营销》)

　　2、想说“这样是不对的”

　　不认同对方的观点，或者和你的思路有碰撞，产生火花的不是思想而是情绪!对方是领导，可以用一句“就这么办，必须按我说的去做”来压你，怎么办?

　　(1)不要着急反驳，适当的沉默，先听对方说完;

　　(2)复述对方观点，确认理解上没有差异;

　　(3)顺着对方思路往下推，推导出一个可能错误的方向，让对方确定，也许对方就把自己否定了。

　　3、上司们观点不一致

　　如果没有呼风唤雨撒豆成兵的本事，在面对这种情况时，一定要头脑清醒，做出相对正确的判断，甚至要找好同盟者，千万不能让上司们觉得你连他们任何一方的观点都理解不了!真实的情况可能是他们的想法都有漏洞，你试图站在客观公正的角度，但是你自己的想法也有漏洞……

　　4、寻求帮助的技巧

　　想起来商场买东西的见闻，顾客认为价格还能再低，只是店员做不了主，就让店员去找店长，有的店长来了的确会便宜也有的会说些好听的话或者送点赠品把顾客搞定。这样是可以增加成单率，但是这个单子的提成是不是要分店长点?顾客再来是不是还会不信任店员?店员正好每次都能在店长有时间有心情的时候把他找来吗?店员如何独自面对顾客独自成单?

　　不透漏具体的内容了，感谢部门给我的支持!看见的力量会弱化你自己的力量，看不见的力量会加强你的力量!

　　5、非“一次合同制”的项目中项目经理的职责

　　一次合同制，指的是按照合同交付的项目，比如之前经历的一些软件项目，合同中大致约定了需求范围、交付日期、项目金额等，交付和付款结束，意味着一次合同履行完毕，可以理解为“一锤子买卖”。这种情况下，项目经理不需要持续熟悉系统参与设计，因为开始就会进行比较具体的分析设计，中间不会偏离太远(合同中开始要做汽车，做到中间想要飞机)，而且事情总有个到头的时候!

　　非“一次合同制”的项目中项目经理也好，负责人也好，一定要熟悉系统，而且要懂得如何讲出让普通人听明白的话!

　　写了不少字，证明bythe同学明白这个理了，落实才能真正进步!

　　写完了，发现开始的题目“技术什么时候和产品划清界限”不合适了，叫什么好呢，“呛水的项目经理”?是不是能表达更多的意思!又给自己扣了个“经理”的帽子，不过想想产品经理，我淡定了。

　　2012/7/23 补充

　　6、评估进度

　　当有不可靠的情况出现，要考虑到不确定的因素，不要让计划和现实差距太大。这点在《项目百态》中“明天会是晴空万里”模式中，充分说明了这点，书中的文字：经理相信未来的平均进度会超过过去的平均进度。因为之前遇到过很多突发事件，导致的进度比较慢，所以经理认为后续进度会赶上来。但往往没有意识到，后面也会有很多突发事件，所以在制定计划时，就要考虑好。

　　博主推荐阅读：

　　职场中的“赶大象心理”

　　职场中的第一次顶撞老板

　　把握二八法则工作生活更美好

　　职业价值取决于解决问题

　　职业寿命取决于营销理念

　　互联网公司的项目经理：客户伤不起

　　技术向销售学什么

　　当你被辞退时

　　本文出自 “韩宇斌-大道源于生活” 博客，请务必保留此出http://byteh.blog.51cto.com/141786/931516