人人都是产品经理——iamsujie

前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。

Ø     敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。

Ø      项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。

Ø   随着时间变化，必然有新的信息出现，特别是瞬息万变的互联网业界，死守着开始的项目计划不调整是没有逻辑的做法，敏捷的迭代刚好权衡了变化的成本和不变的成本，就是：不变本次迭代，更新下次迭代，这是一个将项目计划细化粒度的做法。

Ø      需求唯一不变的特征就是“不断变化”（plus不断细化），敏捷的思想就是欢迎变化，拥抱变化。瀑布模型一次性完成的需求分析，会存在“过度需求”的问题，降低整体效率。

项目管理理论的发展，从开始混乱，每个项目自有一套，每个PM自有一套；到后来人们非常想订出一个统一的简单的流程，减少人为影响（瀑布模型等出现），；再后来进入灵活的敏捷，看似又变得混乱，实则有序。又是宛如那个哲学的三段论：见山是山—见山不是山—见山还是山；也如管理的三个境界：人治—法治—无为而治。

2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。

有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。

瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是不错的。

敏捷迭代开发，如果断章取义是极其危险的，比如没有迭代的测试跟上，到最后发现问题的时候就已经晚了。

介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下：

Ø  拥抱变化，大问题分而治之，先解决最核心的，风险最大的部分。

Ø  会议室中集体工作，每日例会（<20min），站立会议，充分利用白板和墙壁。

（iamsujie补：每日例会每个人说三句话：昨天做了什么，今天要做什么，碰到什么问题。）

Ø  较短的迭代周期，通常一周到一个月，团队人数不要太多（小于十几人），太多了可分割为多个团队。

Ø  一个迭代周期内绝不再加任务，有多的需求放入以后的迭代，如果迭代周期内任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。

Ø  把迭代周期内的事情列出来，很小时间粒度（天为单位）的跟踪。

Ø  不停的发布/交付，让需求方看到结果，获取反馈。

Ø  需求方充分投入，包括需求人员一起办公，验收测试的迭代。

Ø  需求方代表要有话语权，不然半途杀出个老板说三道四是极其郁闷的。

Ø  轻文档，通过开发和测试来细化和纠正。

Ø  程序员自主选择任务点，安排时间点。

Ø  反对加班，这点其实很难做到，特别是在中国，呵呵。

Ø  极其多的口头沟通，其实这点对团队成员要求很高，特别是对中国的技术人员。

Ø  强调测试，更早的测试（TC编写早于coding），重度的测试，测试驱动项目。

做付费产品，就必然要牵涉到卖的问题，2008年，正好“e网打进”火爆销售ing，plus前段时间浏览过《渠道为王》，就说说相关的体会。

销售有两大模式：直销vs分销，分销要通过渠道，渠道又分代理（赚佣金，没有产品所有权和库存风险）和经销（赚差价，产品所有权发生转移，比如批发商），现在的网络付费产品，因为多是个人应用，所以直销比较多，而我们的“e”是给企业用户的，加之国内中小企业现在相应的知识很薄弱，直销成本太高，所以我们选择了渠道销售。

（iamsujie补：太贱的东西不适合直销，e网打进2900一年还是太便宜了。）

在渠道的推拉战术方面，“e”显然用的是推的方法。所谓“拉”是通过PR、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商；“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品,快速抢占市场。推适合企业规模小、技术含量高、销售过程复杂的产品，一般来说：新产品推，老产品拉，“e”的驱动路线“PDà阿里的渠道销售–>渠道–>终端用户”。

从产品设计的角度，对于通过渠道销售的产品，在设计上，新增功能和改动功能的时候，还需要额外考虑渠道销售人员的培训成本、渠道商的培训成本，他们习惯了卖推广，要把一个功能说明白很不容易；另一方面，既然选择通过渠道来销售，就说明终端用户对互联网的应用能力不足，相应的设计思路也要转变。

再有一点，在渠道终端的用户一般是企业，企业用户与个人用户的差异也不得不考虑，比如支付，企业用户就有开发票的问题，不能简单的只考虑网上支付的途径，另外由于渠道的介入，多级的定价，分成比例，开发票的流程，渠道政策都要有相应的系统支撑。

白鸦的一篇《如何保证顾客的整体体验？》让爱好用户体验的人对销售渠道又提出了另一个层面的问题，社会发展导致对效率的优化——分工，也是出于成本考虑，我们的产品采用渠道销售——一种业务的外包形式，我们的终端客户是不会了解中间细节的，他们会把外包服务的不爽怪罪到产品上，给产品的体验减分，那么最终一个很大的问题，似乎也只有折中解决的问题，就是：如何保证渠道的服务质量来保障我们产品的整体体验？

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

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

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

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

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

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

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

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

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