周末打开电脑试图写点文字，发现已经没有之前经常更新博文时那么文思敏捷了，半个小时楞没有敲出一个字。试图总结一下最近工作中的一些问题，但不知道如何开头，还是从习惯的方法开始：只管敲字，把大脑中的思维转化成文字，逻辑合理语法正确是下一步的事情了。突然间想起了在《项目百态》一书中看到的一段话，找了一下在第“稻草人”模式中：人们讨厌对着一张白纸创造答案，但乐意于批评纸上已经存在的答案。写文章、写文档的时候是不是也要尊重这种“真理”，先动手创造些不完美东西，然后再去批评与自我批评，把1.0版本升级为2.0、3.0等等……
结束引子，拉回主题。最近一段，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、角色转换
这句话不只是挂在嘴上，在行动中更要注意。在和非技术出身的人员讨论需求时，一定要忘掉自己是技术，站在业务角度去思考业务可行性，而不是技术可行性。曾经和一些客户、部分销售沟通愉快，以为自己不会存在技术人的那些“习惯”，当面对更强势或者说比自己更了解产品的人，还是会走到发扬“优良传统”的路线上。
