人人都是产品经理——iamsujie

有关招聘：一流的人招一流的人，二流的人招三流的人。（李开复说的）

你是几流，身边又是几流？

2008过年那段时间，抽空看掉了《产品经理实战手册》，金山的王欣、夏济写的，很实用的操作读物，看起来比较轻松，记录一下自己的体会。另推荐《产品经理的第一本书》和《第二本书》（2本我5+6块在浙江图书馆外面的二手书市偶然淘到，哈哈）。

看完之后对产品经理有了更全面的理解，正如Product Manager是从宝洁的品牌经理发展而来的一样，还有很多工作是PD平时接触不多的，因为公司里有专门的运营、PR、市场、销售团队会做相应的工作。不过2008年手上的产品没有专门的运营团队，而且又加入了销售团队的邮件组，正好给了我接触相应领域的机会，列几个还记得东西吧。

包装：对互联网产品来说，我的理解就是产品的portal、登录页面等，这块是给用户的第一感觉，重要性不言而喻。

（iamsujie补：2008年下半年开始，我们发现互联网的软件如果通过渠道卖的话，也有必要搞一个实体的包装，不然用户花了几千块钱，你只给他一串数字（登录帐号），实在有点说不过去）

定价：有很多种理论方法，比如成本导向、需求导向、竞争导向等等，似乎还有种更常用的，就是：老板开会讨论法，=,=。

促销：“广告”和“公关”（“臭名昭著”的PR，哈哈）似乎都可算为促销策略的一部分，这部分的功能是大覆盖的“面”的攻击，好比空军的轰炸。（这部分一直没理清，好像几件事情互相包含的）

销售：好比地面部队，更精准的点对点的攻击。B2B那边一大半的员工都是销售，攻击力还是很强的。所以说阿里其实不是IT公司……

渠道：产品销售的方式，产品采用何种渠道，取决于性价比的综合考虑，比如自己公司的多种产品，就有电话直销、登门直销、网上直销、线下渠道加盟（好比雇佣军）等多种模式。

产品市场化要做的事情很多也很细，这块实在是没有研究，比如做一次公开的市场推广活动，就牵涉到市场预算的及时到位、宣传资料的准备、事前事后的PR轰炸，确实需要老手来做。给自己科普一下，简单一记。

突然想起QA的一个职业口头禅：你这样做是不对的……当PD们激情四溢的乱冲乱撞时，有个严酷、冷酷、残酷的QA/测试控制着，确实太有必要了，虽然经常吵架，：）

先分清两个概念，原来一直很土的以为QA和测试是一个概念，其实QA是质量控制，主要做流程管理（如需求跟踪流程、需求变更流程）、配置管理（版本管理，多分支开发的管理）、文档管理（如开发规范、UI规范）等东西，经典的CMM能力成熟度模型说的就是这回事，不过这方面懂的不多，有兴趣可以去研究，人月神话的blog里有很多这方面的文章。而测试本身就比较单纯了，说下我的理解。

从流程角度上讲，阿里的测试人员通常在UC评审的时候第一次介入项目，评审完成以后，开发开始编码的同时测试开始写TC（Test Case，一般依据需求/设计文档plus与PD/开发当面沟通），在编码快结束的时候正好写完TC，进行TC评审（相应功能的PD、开发一定要参加），评完以后进入测试执行阶段，之后再出报告，多轮回归测试。

从类型角度包括功能测试（又细分为单元测试、集成测试、系统测试），测试管理工具我们用的是Mercury的Quality Center；性能测试（主要看系统是否满足性能需求，期间会包含压力测试，考察系统可承受的最大压力）。

另外还有两个特别的，一是“验收测试”，一般在项目外包或者引入ISV（独立软件供应商）的时候会用到，是把系统有关的所有功能、性能概要的测一遍，外加检查项目交付物（项目阶段文档、用户手册等等）是否齐全符合规范。

二是“可用性测试”，是属于用户研究的范畴，做测试的人不是公司里的tester而是用户，微软称作UAT（用户可接受度测试），也是类似的东西。

技术人员的全面介入，可以简单的看作以“需求分析初稿完成”为界，需求完成以后，派生出几个设计：交互设计、编码设计、数据库设计、测试设计，各自设计完成并执行以后，再部署发布。

具体的说一下，交互设计这块，主要是做软件和用户交互的工作，分工有从最直接的视觉设计师到使用感受上的用户体验师（交互设计师）再到偏代码实现的前端工程师。

编码设计，比较偏概要设计的有软件架构师（比如整个系统的表结构设计），具体到coding的层面就是最常见的开发工程师，他们也会有分工，比如偏应用、偏底层数据库、专做搜索引擎，等等。

数据库设计，对于大用户量的应用特别重要，而阿里的用户数实在是比较多，所以相应的人员——DBA，数据库管理员，在业界也确实是比较强的。

测试设计，就比较单纯了，相应的人员就是测试工程师，再细分一点就有功能、性能等等，一般来说性能测试会写一些自动执行的脚本，感觉更高科技一点。

上述各项工作完成之后，就要把各方面准备好的产出物拼在一起部署发布，那么就牵涉到硬件方面的管理，这就是SA，系统管理员。对于BS应用，感觉部署方面的工作比传统CS软件简单一些。

对于软件项目的整个过程,需要在流程/规范上做控制以防止低级失误的发生，比如有时候需求人员会觉得某个功能的改动很小，就直接叫开发人员改而跳过测试人员，这样违反流程的行为对于复杂的系统是极其危险的。所以产生了SQA，也就是软件质量控制人员，这块和测试不一样。

对于多次不断发布的产品、多分支开发的产品，配置管理员（SCM）就显得非常重要了，有他们的控制，就不会发生“某个bug在新代码发布之后重新出现”这样的低级失误，或者分支切来切去乱成一团的情况。像简单的用SVN、CVS来管理文档、代码的更新、软件版本的变更、日构建/发布的控制，就是SCM的雏形。