做为一个产品经理，首先需要的是你的创意和思路，你必须去规划产品所应该具备的功能，这将使用各种分析方法和手段，比如从竞争对手的产品中进行正向和反向的思维；你需要为自己的产品构造一个好的环境，研发虽然是产品中重要的一环，但是绝对不是唯一的一环，你需要有良好的构思，来形成产品在整个业务环中的定位，需要找到各种合作伙伴来和我们一起推进整个产品在市场上的成熟，你需要根据产品在使用过程中的反馈，来考虑不断的改善（有时候，也是通过一些数据分析手段和数据分析方法，这一点，我一直认为Yahoo做得不错，他们的改进都是有系统监控数据支撑的，而不时拍脑袋出来的），并且分析用户行为，来修整自己的产品；同时，也需要为整个研发部门指明一条前进的方向，说明我们的产品在各个阶段将是什么样子的；并且你还将牵头进行产品的推广的一些工作，比如产品的关键字，产品的宣传语，产品的基本色调等等，这些都是你必须去做的。同时，象对待孩子一样看待这个产品，你必须对这个产品的过程具有一个很清晰的思路，你必须十分明白你的产品目前处于什么阶段，并且清醒地指出下一个阶段的发展方向。

在去年一年中，Yahoo的产品给我留下最深刻的印象是，他们的产品具备了良好的监控能力，我们可以很简单地加入某些代码，来监控用户在站点上的操作访问，并且能够很轻松地定义出各种综合条件的监控，这样，我们才有各种依据来说，某一项工作是否有价值，某一项工作需要改进等等。在产品设计之初，我们就必须考虑这些要素，虽然绝大多数公司未必具有这样一个灵活的监控系统，但是即使是生磕代码，我们也需要加入这些探针，为我们将来的工作来留下一些监控的余地。

以上是产品经理应该做到的一些事情。后面，我仅仅谈一些对我印象最为深刻的产品的思路，当然，这些点不足以构成整个理论体系，但是，只是这些内容在我印象中太深刻了，以至于不吐不快。
<...

查看更多...

首先，我认为，一个项目经理，最重要的职责，就是对结果负责。也就是说，当一个项目成功的时候，你不用脸红，说你什么也没有做（如果你真的什么也没有做，就能使得项目如此成功，那么你要么运气很好，有一个杰出的助手，并且你有足够的明智、信任和恰如其分的懒惰，来让他负责具体的工作。那么你的管理才能让你可以轻松地胜任这一职务，你前途无量啊，小伙子。呵呵，不过还真的有一些管理者，恶意地偷懒，给团队带来很多不好的风气，也有类似的一种现象出现――什么也没有干，问题是看如何分辨了，最简单的一种方式就是看看结果如何？并且问问他身边的上级、下级，看看大家到底如何看待这件事情了），你就是一个胜利的Team的Leader；如果一个项目失败了，首先要做的，就是责备自己，不要责备手下人，不要说：我的团队不够优秀，我的设计人员设计出现了大问题，我的开发人员代码编写存在很大问题，我的测试人员不够优秀；归根结蒂一点，是你的错，就承担下来，如果按照这样的项目经理的逻辑，没有任何错误是管理者的错误(随便插一句，为什么我认为《都是你的错》，这本书是一本胡扯居多的书，就是因为如此，实际上，在公司层面上，很多的问题并不是执行层面上的问题，而根本是战略层面上的问题，我可以承担我层面上的错误，但是我觉得再多承担，就是有点自虐了。如果客观条件都如此好，一切都按照你的想法完成了，比如一个人在一天内，完成了整个万里长城的建设；那么也许一切都很完美了。但是，真的能够如此吗？)。一个管理者要从自身去找问题，这样他才能进一步成长，如果全部从手下人身上找责任，我觉得至少这不是一个大气的管理者，不是一个让我敬佩的管理者。举一个例子，当你是项目经理，你的项目存在了很大的问题，你的态度是什么？你正常的态度应该是很惭愧和内疚，着急想法子去解决这些问题；如果你的态度是很生气，对不起，我只能说，你没有资格生气！你还没有足够的度量和责任心来承担更多的责任。...

查看更多...

在进行项目管理的过程中，特别是软件行业的项目管理的过程中，我们要切记一点：你首先管理的是人，而不是过程，更不是文档，企图使用管理文档的方式来管理、监控整个项目，就象仅仅站在1000公里以外，指挥进攻华沙的图哈切夫斯基一样，遭到指挥生涯中，最严重的失败。从理论上来说，你的确可以如此做，但是实际上，你将面临严重的危机。

另外，我们企图用传统的工程学（类似机械、土木工程）的方式，来定义整个软件过程，这一点，至少从现在我的观点来看，是有点过于乐观了。我们在从这些传统工程学行业中吸取经验和教训的同时，最好也能够看见他们之间的不同，不然，也许我们将一步从成功走向失败。

至少在现在，还不是流程决定着软件开发的结果，而是开发软件的人，至少从我在项目中看见的绝大多数错误，来自于我们的愚蠢的设计，比愚蠢的管理更致命（当然不是说，良好的管理就不需要，但是，的确，就我个人的观点来看，愚蠢的设计给项目带来的损失远远超过愚蠢的管理）。我们要记住一点，流程为什么而存在？流程本身并不是目的，流程仅仅是更好地达到目的的一个手段，流程可以使得良好的经验迅速固化，并且在推广展开；而且流程的操作性很强，相对于很多模糊的概念来说，他们至少更容易进行管理。但是，无论采用什么流程，我们的目的是客户所满意的结果。请随时记住这一点。不要让流程成为你迈向成功的绊脚石。

对于项目管理来说，人是最重要的，至少有三层意思：

1. 不管你开发什么软件，不管你用什么流程（不管是至少我看来多少有点胡扯味道的软件工厂也好，还是很谦虚同时也很自豪地宣称自己是软件作坊的也好），实际在为客户提供价值的是研发人员所提供的产品，这些首先是人所作出来的；

2. 你的软件，是为人来服务的，如果你不把主要注意力放在“客户...

查看更多...

OK，需求已经出现了，当然我们需要面临就是，构造这个软件了。

在这里，恐怕开发人员更熟悉以下的一些过程，比如版本控制、比如设计过程、编码过程等等，这个阶段也往往是一个研发周期中，最繁忙的一段时间，可能频繁地发生加班。但是，同时，这也是抱怨最多的一个阶段，我们抱怨流程不够清晰，我们抱怨配合出现问题，我们抱怨设计出现纰漏，我们抱怨测试不够完善，我们抱怨……，总之，士气似乎在不断下降过程中，我们一直绷紧着神经。

但是，这个阶段，也是很有成就感的一个时间，看着系统在被一天一天地构建出来，这多少是让人非常有成就感的感觉，虽然那不是最有成就感的时候。

在这个将会占据很多内容的章节中，我希望首先介绍一下我的思路，我的思路是：

首先，我们将关注人，分析在一个项目组构成中，各个角色承担的责任；我们将希望在这样一个团队中，我们都能互相往前，或者往后走半步，原因仅仅是我们都不够优秀，向前或者向后走半步，将使得我们可以尽早发现一些问题，尽早发现一些各自职责之间的灰色地带。从而使得我们可以少犯一些错误。

其次，我们将简述一下整个流程，当然，这在绝大多数情况下，都是大同小异的，说大同，是因为几乎每一个公司都是如此要求的，说小异，是因为大家具体的操作方法上，可能还是存在一些至关重要的不同，往往正是因为这些不同，导致了结果完全不同；

再次，我们将把我们的注意力，集中在几个我们很关注的过程中，在这些过程中，我们将略微详细讨论一下，我曾经如何做过，效果是什么？

最后，我们会就几个很多人很关心，而且非常非常多次问起的一些问题，针对这些问题，我希望能够给出一个我的观点。

当然，正如我很多次所说过的，项目经理是一个概念十分庞大的名词，三峡工程也可以称之为项目...

查看更多...

在这里，之所以把这章单独拉出来，是因为需求文档，一直是我们的一个大问题。过于详细的，而且缺乏分层和索引的文档，引起的是更新不及时，而且耗费大量成本。成本一点我们多少还能够接受，但是千万不要低估他的成本，认为这些文档可以随手就改过来，正式自己操作的人，就会明白，这远远不是随手改过来的问题，当然，一个文档如果结构相对合理，能够组成立体的层面，那么修改还相对简单一些，如果一锤子到底，全部是扁平的User Case的模式，那么很不幸，如果某一个地方发生一点全局性的变动（比如增加了一个在我们系统中，用户必须首先登录，不然不能使用），那么分配到每个User Case中，这将是非常庞大的工作量。对此千万要小心，文档不仅仅是写出来就完事的，将来还是要维护和更新的。另外一个极限是，几乎没有需求文档，几乎所有的需求都是简简单单一句话，比如“用户的数据需要定期备份”这一点，就存在大量的分支，是系统自动备份？还是定期提示用户自己备份？最近一个备份会覆盖前面一个备份结果吗？这些备份数据，会自动清理吗？备份的数据，用户能够进行什么操作？等等，如果这些问题都是一无所知，就直接进行开发，无异于把自己的命运完全寄托在幸运上（而且是非凡的幸运），因为这意味着，所有这些疑问，如果被提出来，还算好；不然，这些将完全依赖于大家自己的设想，而要保证大家的设想是完整的的概念集中一部分，那么这多少可以称之为奢望了。

针对上面这两种情况，都不是我们想要的，在其中，我们希望有个平衡点。

在这里，我首先要说的一点，是我对于文档的看法；无论过程多么重要，但是过程的保证是为了目标的保证，如果一件事情对于客户的直接价值不大，我们就需要极其小心地对待这件事情，因为我们要记住的是目标。那么做为重要的沟通方式和知识固化的一种做法的文档，我们应该如何看待呢？

首先需要明确的一点是：...

查看更多...

曾经参加过MS的一次笔试（哈哈，一个做得很烂的笔试，居然为我赢得了1个机会，呵呵，看来天下比我笨的人还比较多哦。哈哈，说一个比较自豪的哦，显摆一把，曾经参加过一个公司的IQ测试，结果发现是他们历史上参加这个测试的人员中，得分非常高的一个，于是我突然有一种高兴的感觉，呵呵，看来人都是有点虚荣啊。包括在这里写这件事，好像也挺孩子气的），题目是：“如果给你叁个月，你将如何设计一个资源管理器的Shell”。看到这个题目，的确让我很挠头，看来我们就如同穷困惯的孩子，在一下子得到了一大笔财产的时候，几乎不知所措了。

不说别人如何做的了，对于我们来说，一般的做法是这样的。下面的东西也许太简单了，但是我们实际就是如此做，也只能理解到这里了。

首先，我们会企图先花一些时间，先列出几个典型用户场景出来；比如举一个例子说：当用户手机地址本和服务器的地址本进行了无线同步以后，如果同步成功，将自动给用户的地址本做一个镜象，使得将来用户能够从这个镜象中取得自己某一个时间段的完整的地址本。OK，我们想像一下，我们是客户（当然，如果有现成的客户在眼前，而且这是他以前日常的一个工作，就不要想像了，问问别人就是了，胡思乱想没有什么好处），我们会如何使用这个功能。“我掏出手机(这一点一定要写，不要只是写系统的行为)à进行同步à同步成功à收到一条短信，告诉我同步成功，并且地址本已经保存”。很简单，不是吗？

OK，这时候，我们会拿起准备的一些基本的原则（比如你的系统中有多少概念？比如对于Word来说，保存就是一个概念），看看用户在这个操作过程中，是否和原来的概念有冲突？如果存在冲突概念，请想出合乎逻辑的处理方式。比如，在这里例子中，由于在网站上，我们也提供了用户手工备份地址本镜象的操作，那么这个自动操作，是否会覆盖用户手工的地址本镜象呢？如果是一个镜象区，...

查看更多...

一般在立项的过程中，我们会提交一分需求的文档，简略地说明这个软件会干什么，具备什么功能，但是这时候，还是比较粗略的。事实上，你也不可能做得如此详尽，因为那时候，你也没有这个精力，也没有那个必要。

正如事情需要一件一件来做一样，这时候，一些设计角色，框架角色，以及一些测试主管，应该快要进入团队了。你总不希望仅仅是几页需求列表，来迎接他们吧？OK，我们要干一些实实在在的事情了。

首先，对于产品经理来说，你一定已经比较过相关的产品的优势和劣势了吧（如果到这个时候，你对于竞争对手的产品或者类似产品还是模模糊糊的，那你就有点失职了），下面你就该动用你的脑子，考虑清楚，我们产品具体该是什么样子的了。

但是要防止两个错误：

首先，不要只以为是，不要认为你那么强大，可以在一朝一夕赶上竞争对手，你要明白一些现实世界中的基本准则；

其次，你是在替客户设计一种软件，而不是为你自己设计一种软件，所以不要告诉我觉得这个功能多么多么酷，多么多么实用，我们需要知道的是：谁用？如何用？对于我们价值何在？为什么不能没有它？在这一点上，我很赞同Yahoo的产品需求规划过程，当然，他们整个产品功能规划过程比我看见过的绝大多数公司都做得好得多，他们会说出这些功能到底谁来使用，为什么我们需要添加这个功能（这一点尤其重要，谁提出谁举证，如果不能举证，就不应该做；而不是由其他人说这个功能无用。因为相对来说，说某个功能无用是很困难的，即使再没有用的东西，我们总是能够找出他的一点点用处。），这个功能会为我们带来什么（再有用的功能，用户不买单，还是没有用）。对于产品来说，一个基本的想法就是能够不做的，千万不要做（顺便插一句，犯上“任务饥渴症”的人员，基本上都是以累死自己，累死别人而收场的），一个小而强壮的产品给客户带来的价值远...

查看更多...

以上，我们花了不少篇幅，说了如何判断一个产品是否应该做，并且在立项之前，应该考虑清楚的几个事情，其实简单地来说，无非就是：谁是你的客户？我们是否值得并且有能力去做这件事情？我们是否可能成功？我们的产品是什么样子的？仅此而已。

做到这些都很简单，不是吗？但是以下一些情况使得我们在实际中做到这些并不容易：

1. 我是负责项目或者产品的人员，不是市场分析或者预算控制者；记住，如果你这么想，那么你还不是一个合格的产品经理，还不是一个合格的项目经理；去尝试着这样做！

2. 我们的时间太紧了，我们需要尽快开始，不然我们就死定了；很诱人的理由，不是吗？但是记住一点：你现在还没有开始，在这个阶段，我们需要讨论的是是否做的问题，而不是解决如何做的问题；就象你没有把握之前，是不会投资某一个领域的，因为你知道风险太大了，这简直在浪费钱；同样的，如果我们不清楚我们的状态，就直接进入，同样也会埋下失败的种子。

3. 从结论反推起因：我这里不谈论政治，如果你仅仅是为了证明某一件事情值得一做，那么你可以放心，我们总是能够找到证据的；商界上的例子太多了，就象历史中的各种例子，只要你想，你总是能够找到证明你的观点的论点；排除或者隐瞒掉掉最大的风险点。我们就事论事来说，不要考虑你是否必须做这件事情，而是把自己看成一个评估者，你如何评估这个产品？当然，这一点，无论对于高层管理者还是底层管理者，都是一个难以抵御的诱惑。所以，我就是这么学究地一说，你就也是那么恍恍惚惚地一听就是了。但是，如果你处于这种状态，任何方法都是没有用的。

另外，我需要指出的一点是：如果你已经有了相当的经验，请相信你的直觉。直觉这种东西很奇怪，我们会直觉地感受到某些事情存在部分问题，或者存在...

查看更多...

所谓产品形态，内涵很多。但是我一向很简单地理解成为一句话；你可以在没有看见集成起来的软件的时候，清楚地知道这个产品是谁来使用（是最终使用这个系统的人，还是第三方开发者？）？他将如何使用（他是否可以打开这个程序？这个产品是否允许第三方系统通过某些接口的访问，来实现某些特殊的功能）？将在那些方面为客户提供价值。你的脑海中最好能构成一幅一幅的图画，模拟这个用户的操作过程。并且设想出来他们使用你这个产品过程中，所会碰到的一些典型场景。

“我们要做一个进销存系统”，然后脑子里面一团混乱，就带领团队开始动工，这简直是一种扯淡的做法。是一种严重不负责任的做法。

记住这一点，虽然做为开发人员来说，我们能够容忍失误，但是我们无法忍受一次又一次的愚蠢！不要让自己犯愚蠢的错误！请各位项目经理和产品经理把这一点牢牢记在脑海中，碰到问题的时候，第一时间需要考虑的是：是否我又做了什么愚蠢的决定，而不是第一反应是别人执行错误了。这是一个管理者的度量，也是你做为一个管理者将来还能向上发展的一个限度。不改变这一点，你就已经做到了你能力所允许的最高的岗位了。

构思清楚你的产品形态，并且把他传达到整个团队中，是一个好的项目经理和产品经理所必须要做的。

这一点虽然看起来很容易做，但是如果碰到严格的立项审批者，这个问题极其难以回答，当时我们很多人立项的时候，最害怕碰到的两个问题，就是产品形态和3年现金流分析，往往被攻击地很厉害。至于其他分析，就显得很写意了。呵呵，认真对待这一点。

技术分析，是为了克服一些产品研发过程中，所必然会出现的一些明显的技术风险。一般来说，我们都会在产品研发前期启动一个Prestudy的过程（看具体产品或者项目大小，时间从1-2周到3个月不等）。我喜欢把这个阶段看成一个让大家充分犯错的过程。这个过程的目标是分析出来产品或者项目的重要技术风险，并根据这些技术风险进行预研。比如，我们常规的一般项目，是先做软件，在软件集成测试基本完成以后，然后展开性能测试和稳定性测试，但是如果这个项目是允许Delay的，这种做法问题并不大，大不了就是一个Delay而已。但是，如果这个产品这方面风险很大，那么就值得为此去做一些事情了。免得最后发现性能或者稳定性存在大量问题，不好处理，很难受的。

比如，我们曾经做过一个系统，主要的难度在于这个系统将会有至少2000万条主数据库容量（设计容量达到2个亿），这个系统访问量基本上预计为每年2-10亿次访问（也就是说并发访问量并不是特别恐怖，至少和硬件设备比起来，这种访问量还是没有让我过多的担心），但是我一直担心的是，这个系统我非常倾向于采用星形的数据库设计，我担心由于辅助的几个表出现大数据量的时候，查询速度将一下子全部下来，并且导致访问极其缓慢。而且这个系统主表数据不能定期导出，只能存放在其中（虽然数据增长量不大）。那么很明显的，如果我们系统到最后才发现性能根本不行，这个项目就基本全部失败了。在常规的功能性测试中，除了严格的性能和重载情况下的压力测试，其他的时候的数据量一直都不大。那么就有必要进行预研，使用测试数据，然后调节各个参数（比如索引的位置，数据库参数优化等等），并且模拟一个实际环境，来对每个版本进行一定测试，来保证某一个版本叠加上去以后，性能多少还能接受。

其实有时候，需要进行技术分析的，不仅仅是技术难点，还有一些其他的原因，比如做Workflow的人都知道W...

查看更多...

在比较严格的立项中，是需要附有相关的3年现金流分析的。首先，需要说明的是，这一个在其他领域使用得很多的立项必备条件，在软件行业中，并不是很多（当然，在融资的时候，这可就是一个大学问了，会有专门的人来做这一块的）。这让人感觉，我们就象一个傻孩子，什么都不看就扑上去做了起来。直到最后，才一拍脑袋：“啊～”。

这一点，在财务分析中，方法比较清晰，无非是各次追加投资，以及现金流回，折算到期末的现金。来衡量项目是否值得做。相似的，更简单的做法是投资回报期的分析（投资将在几年内得到回收）等等。就不详细说了。

具体做法不说了，但是值得说一说的是，倒是，这种分析方法，对于预测人的商业知识要求很高，否则，你能够把现金流估算在一个数量级内，就算不错的了。但是，即使如此，这个方法还是值得去作一下的，因为他将促使你去考虑，你的产品将如何盈利，你的各个层次的投入情况是什么。而且，这对于初级的项目经理（或者产品经理）来说，也可以增加成本概念，让你仔细规划成本投入和产出情况。而且，这些情况将由于此过程，深深印入你脑子里。当这些先决条件发生变化的时候，你能够敏锐地发现，而不至于一味埋在产品里，让一个产品把公司全部拖垮。每过一段时间，你需要做的就是Review一下你的现金流和Mailstone，看看和你原来的现金流估算是否存在很大的偏差，如果存在很大的偏差，务必及时提出来（当然，你执意要拿这个项目来练手，就不要提出来了，一般来说，如果你们公司的老板保持足够的理性的话，这种项目很可能被取消的）。

当然这种做法，会引起一些政治问题，比如初期故意降低成本估算，过高估算现金回流；而在产品过程中，不断提出一点一点的资金和人员需求；使得公司这个项目拥有越来越多的沉没成本；虽然在正常的决策过程中，沉没成本是不应该进行项目是否值得往后做的决策依据的，但是事到临头，...

查看更多...

下一个也是一个非常经典的战略管理模型；通过分析你的竞争对手，上游提供商，下游的分销商，客户等竞争环境来分析你的竞争优势所在。

上面提到的每一点都有将近10多条值得讨论的问题，比如你的上游提供商是否具有可信的向后一体化的能力，这将削弱你的竞争力量；比如你的竞争对手的强度和报复可能性和报复欲望是否足够强烈等等，也是影响你进入一个行业，或者开发一个产品所要考虑的。这些东西，在战略管理中，都有更详细的说明，这里就不一一列举了。如果你照着这个思路走下来的话，你会感觉到一些不同的。

做这种分析，是为了让自己清醒一些，知道你在这个行业中，或者具体化到这个产品上，你是否具备足够的实力来参与竞争。

一般的来说，具有比较高的入门门槛（无论是资金门槛，还是政策门槛），进入障碍比较高，退出障碍比较小，竞争对手比较弱或者市场处于一个快速膨胀的市场之中等等，这是一个典型的好的领域。如果都是相反的，那么要么你能够利用快速进入，通过扩张，在别人没有反应过来以前，取得了市场或者用户的认可，或者短期干一票，拿完就走，否则就算了。这种行业都是比较吃力的。

举两个例子来说明这个问题，为什么出租车行业的利润很高（至少北京市场如此），而从业人员的工资很低，而且工作强度很大？原因很简单，就是进入门槛低，而且退出门槛高。只要有3年驾龄的司机都可以做出租车司机，而很多大型国企的不景气，使得这些人更多了；而退出门槛体现在他们交的保证金上，如果违约，保证金将不得退还。于是大家还在这个领域中搏杀。做为一个额外的话题，如果需要提高出租司机的工资，而且不引起很大的社会不公，至少我们可以从哪些领域着手呢？也许经济强人对这个话题会感到兴趣吧。这里就不谈论了。

第二个例子是和我们更贴近的例子，大家都知道税务行业是政府行业中的一个大户，理由很...

查看更多...

这是任何一本《战略管理》中都会提到的一个分析方式。事实上，我在进行研究生课程班的学习的时候，真正让我感到受益匪浅的，只有这一门课程（至于高级管理学之类，可能是因为我们老师除了读书以外，什么都没有干，所以使得我感觉恶心不已吧，而且整本书对于我真正有用的也就是几页纸而已，其他的属于完全正确的废话）。

SWOT分析，主要是根据目前出现的机会和挑战，结合自己的优势和劣势，来分析这个机会或挑战，意味着什么？举一个现实的例子来说，2003年，做公安行业的时候，主要做公安行业的人口系统；当时正面临着2代证的换证工作。这是一个机会，也是一个挑战；说他是机会，因为公安行业是一个具备比较高入门门槛的行业（需要通过部委的认证，才能向地市一级推进），所以对于处于绝对优势位置的企业来说，对他们发起挑战，机会并不多。但是乘着2代证而引起的全面的人口系统更新上，这将是一个机会。说他是挑战，是因为我们并不是一无所有，在2-3个省的市场占有率达到了90%，那么至少应该保住自己的地位吧。

我们的优势在于，做为一个大型的IT企业，至少在口碑和市场推动力方面的能力，还是比较强大的；弱点是，在这个行业中，对于客户的细节方面的理解远远低于竞争对手。那么在这个环境下，你到底应该如何做呢？

同样的，我们举一个最近的例子，做为运营商的DM系统，使得我们有机会进入DM领域，我们的优势在于在中国落地得比较深（相对于绝大多数参与竞争的国外厂商），但是在DM这一块的积累比较薄弱。从这两点分析来看，直接竞争显然不是一个好的选择（我们不能期待自己聪明到这种程度，用6个月的时间超越别人3-4年的努力吧？但是，很奇怪的一点是：很多人相信。呵呵，这一点有点像我们都喜欢看淝水之战，喜欢看见中国历史上最庞大的军队被几万北府兵打得土崩瓦解，但是忘记了另外一点是，几十倍于这个案例的是：几万...

查看更多...

客户定位：并不是所有的客户都是你需要服务的客户。我的理解是，对于绝大多数公司来说，找到一个足够细分的市场，成功的希望才足够大。当然，你要是细分出来一个“北京市朝阳区麦子店片区18岁以下年龄组75KG以上太极拳高手的帅哥”，我估计也不成呢。那么之所以这么说是因为，我们目前的问题不是细分市场过度，而是细分市场不够，绝大多数产品属于打到哪里算哪里，四面突围，也许闯出去了呢？这种做法的结果就是让研发承担了产品和公司战略上的困境。因为在这种困境下，研发不得不在极大的时间压力下应付很大的改动需求。（这一点，请各位公司老总慎重，有时候，你批评下属的原因也许仅仅是因为你是他的领导而已，错误根源在你！）。

找到合适的使用人群，比如商务用户初期对于功能要求并不多，根源在于稳定、持久的服务（我之所以使用Word做为文档工具，是因为我估计这份文档，在10年以后应该还能打开；再比如我从来不使用不能导出的日记软件，因为如果突然有一天他不能使用了，我将损失我投资在上面的所有时间和心血）；对于年轻一代的“酷”一族来说，重要的是“Woo……”的感觉。这两点是完全不同的。比如我只要能够打电话，绝对不使用Short Message；但是学生一族，一天能够发出60条短信，这一点实在难以让我理解；因为那么多字的输入，发送将浪费我多少时间哪。

OK，用户首先需要会使用你这个系统，并且为此付钱。找到你的合适用户是很困难的，至少比我们想像中难很多。所以，有必要做到一点，当你确定你的用户群以后，请在后面的每个决策或者设计的时候，都记得你的用户群（而不是你！），不要仅仅把他当做是PPT上的一个幌子而已。这一点是无穷多的公司付出了血的代价而得来的，道理大家都知道，但是实际操作的时候，又有多少人能够记住呢？

并且，要记住一点，改换用户群所做的相应改动，成本是很高的，至少...

查看更多...

首先我会做业务环分析，举一个例子来说，我需要做一个小的Brew平台上的手机游戏产品，那么这个业务环是什么呢？手机用户登录到联通的“百宝箱”上，然后找到我们开发的游戏，选择下载到手机上；然后，每个月（或者一次性）的通过联通进行交费；联通收到这笔费用以后，和我们进行分帐处理。于是我们可以看见，其中涉及的角色有三个：手机的游戏玩家；运营商和我们。

OK，我们就可以划一个圆圈，来模拟在现实环境下的现金流向：手机游戏玩家à运营商à我们公司；在这三个点上，各方的态度是什么呢？手机游戏玩家其实对我们的游戏无所谓推动或者不推动，他们完全是被动的，当这个游戏很有名气，或者很对他的胃口，那么他就会选择下载。仅此而已。运营商呢？联通在企图将“百宝箱”做得和移动一样出彩，那么他们对于我们这个游戏，至少是欢迎的，虽然到不了推动的局面，那么如果需要运营商有推动的态度呢？如果这款游戏是一款在线的，商务的，出发点令他们非常感兴趣的（比如能够把短信Push到网络上保存，当然Brew平台没有短信接口，所以至少在目前也就不用费心了），那么他们就会推动这件事前进。至于我们自己，那么不用说了。当然是推动的性质了。于是，我们看见上面这个业务环，基本上是可做的。没有什么太多问题。因为其中没有抵制的人，基本上是合作和推动。而且这个业务环很短，不会出现复杂的关系，比如你原来设想的客户突然之间改变了态度（原因是他们企图在其中上自己的系统等等……）。当然，在实际工作中，我们对以上这个案例是不会费心进行分析的，因为这个业务环很短，而且其中角色的关系不复杂，所以也就不用费心折腾了。

下面举一个例子，是中国移动的DM系统。DM系统是个全网业务，基本完成的功能可以看成这些：能够动态地给各款手机下载各种软件，在用户手机呼叫或者使用WAP、SMS功能的时候，能够清楚地知道用户手机型号，用户手机中所使...

查看更多...