偶然的机会在西单图书大厦新书榜上看到了苏杰的《人人都是产品经理》，随便翻了一下，感觉作者是同龄人，目录也没有循规蹈矩的列出引言、背景、原理等等如是的内容，很有亲切感 ，随即买下读读 。

平时看书时间少，公交车上拜读了苏杰的产品（呵呵，被同化了），有很多同感，也有很多惭愧不如的地方。

与作者一样，我也工作了四年，虽称不上产品经理，但基本也负责了公司的两个模块功能的开发及十几个项目。用作者的话说就是，产品经理并不是一个或几个岗位或职位，人人都是产品经理，更甚，我们可以把自己当做自己的产品经理，经营自己的生活。

---  一个需求的奋斗史

从需求采集、需求分析、需求筛选，看似简单的过程，工作中却很难把握，在金融行业做IT，技术人员是整个公司的后援的后援，是一个纯粹的消费部门，在一些大的事情上大老板会更多的认为技术部门会托后腿，在决断事情方面，也会给技术部门更大的压力，技术部门从上到下基本上是哑巴吃黄连，硬着头皮上。作者所在的公司，在这方面有着比较优越的条件，技术部门有较强的话语权，UI的不同设计，会对客户产生不同的感受，从而直接影响公司某项业务的业绩。在这方面金融企业还是要学习更多，不要把技术部门作为一个为实现公司业务的工具，而是具有长远的系统规划，稳而不乱才是金融企业系统建设的基础。

-- 项目的坎坷一生

这一节更接近我平时的工作。项就是清单，目就是目的，项目就是有清单有目的的做事情（自己理解啊），在我们公司存在一个比较大的问题就是，业务只知道提需求，也不太愿意说太明白（可能后便有很多不可告人的隐情），IT只知道做需求，也不太愿意了解那么多的业务背景，这是很危险的做法。我碰到过这样的项目，业务开始很积极的说要提某个需求，说多么多么的急，如果赶不上要求的时间，会有多大的损失 ，模块负责人向领导说明问题，并申请资源，准备奋力一搏，然而业务尽然很快提不出需求，那怎么办，只能通过项目经理（不是产品经理了中）的步步引导，项目需求出来了，设计人员、开发人员、 测试人员密切合作，各司其职 ，待需求上线UAT后，业务尽然说没法和第三方联调测试，让我们先上生产 ，项目经理对这种要求当然是回绝了，然后这个项目就放在测试环境无人理睬了，业务部门先前的要求也没有了回信 。

以上说明了两点（个人认为）

1、 金融企业的技术部门一定要有BA，与业务部门接洽 。

2、 业务部门的需求要通过BA的分析后才能确定是否投产。否则就又是一颗臭蛋。

--  我的产品，我的团队

  我的产品我不敢说，因为大家都在为核心系统服务，为公司业绩服务 。我的团队，确实很重要，这个团队包括自己的下属，自己的同事，所属外包成员，由于个人性别比较厚道，基本不会发什么脾气，在管理人员方面存在技巧缺陷，这方面还得好好学习 。

-- 别让灵魂跟不上脚步

最喜欢kpi 一节 ，都是出来混饭吃，公司的业绩评估指标是啥样的，我就怎么做，这就是目的，没有了这个，基本上在公司混不下去的 。

--产品经理的自我修养

很是长见识，苏杰的阅读能力一定很强，要不不会啃了那么多书了，而且范围很广 。 这方面自叹不如 ，同志还需努力啊 ，呵呵 。