博客园_穆洪星

【产品经理工作笔记】第37周工作笔记

2011-09-09T12:15:00Z

【9月5日-说清楚做事的目的】

早上到公司之后先过了一遍大家上周的日报，其中两位同事的日报都提到了安排工作和自己想法的分歧。

在这两件事情上，我的处理过于简单了，只安排了工作而没有说明这么做的目的，实际上这在我们部门的日常工作中叶屡屡出现：

需求和开发的分歧、开发和测试的分歧、Leader和团队成员的分歧等等。这些分歧中很重要的一个原因是对信息掌握更全的一方没有很好地将信息传达出去，同时没有很好地听取对方的意见和建议。

在接下来的工作中，对待工作的安排我需要更加细致一些，除非是需要快速决断的情况下，要说清楚目的，并达成一致，消除误解。通过交流，这对我们每个人更全面看待问题也很有益处。

【9月6日-准备培训班】

今天一项重要的工作是准备培训班。

这个主意来源于老江，在和北项交流的过程中发现在销服采用事件驱动的方式很普遍。

由于我们部门中很多同事都不是专业出身，需要快速掌握和精通我们的产品。在年中审计的时候老江提出了可以采用事件驱动的方式，主要原因很简单：

1、自己讲出来要比听别人讲掌握更全面，理解更深刻；

2、通过目标明确的事件能够更有效率和更有效果。

在承办培训班这个专项中，主要为了实现以下目的：

1、快速掌握产品的应用；

2、锻炼相关同事的演讲能力、培训能力；

3、和销服的相关同事短路，建立良好关系。

目的明确了，下一步是如何做的问题，重要的是通过沟通、探索，了解需要完成的事项，并形成计划。大致经过的步骤是：

1、参与本专项的所有同事参加培训班，重点是了解培训班讲解的内容、节奏、重点，参加培训班的用户的一些表现；

2、根据当前掌握的资料和需要完成的工作，讨论我们遇到的问题和需要了解的情况；

3、针对性咨询销服部门有经验的同事，按照我们列出的访谈提纲进行内容的汇总；

4、获取相关的资料，比如PPT、案例文件等等。通过这个过程今天对我们销服的同事产生了一个有益的事情：他们也梳理了一下自己的文档；

5、制定完整的计划，已经具体到天。

接下来需要将计划中的关键时间点和协助项和相关的同事进行确认。由于准备比较充分，对这次整个专项应该做到了有把握。

【9月7日-管理活动模块】

给我最深的感触有2个：

首先，定义了一个清晰的框架（做什么）。这个框架说明了作为一个管理者需要掌握的技能。

我们的团队成员从最初的5人到了现在的10人，对于一个新产品团队来说，这个数量也算是“庞大”了。在这个过程中我很大的一个困扰是发现需要掌握的技能太多，需要掌握哪些技能不清晰，需要掌握的程度也不好把握，一句话，老虎吃天无处下嘴。

右边张图很清晰和直观说明了作为一个管理者（基层管理者）应该具备的技能。

怎么使用这张图，我的体会是：

1、理解每个部分的含义；

2、对照自己，针对自己对应于每个技能打分；

3、根据团队情况，找出当前最需要Leader掌握的技能；

4、根据2和3，量化对与自己而言每个技能的重要性和紧迫性，排出优先级；

5、根据优先级排出技能提升计划。

其次，给我的感触是达到这些能力要求并不容易，需要有一个科学的规划、持久战的准备、付出不亚于任何人的努力（怎么做）。

如何快速提升这些能力，对我而言，方式可能有以下几种：

1、看此技能公司近期是否有相关培训，自己能否参加培训；

2、公司内的标杆是谁，咨询他如何提高该能力。比如知识管理可以找研究中心的孙进、流程制定可以咨询企管部和PMO的同事等等；

3、看看业界有什么针对性的书；

4、能否有亟需该技能的专项任务，有无可能创造该专项任务，通过专项任务提升；

5、心态的提升和技能的提升同等重要。认识到具备一项能力不是轻而易举的事情，心智的磨练一样重要。

【9月8日-网页宣传数据分析】

在上半年的网络渠道策划中，一直是瞎子摸象，始终无法理顺各个环节的关系，其中一个重要原因是没有历史数据分析。没有数据支撑还造成一个后果，我们的目标值几乎都靠拍脑袋。8月份网页上线，在没有采取大规模宣传的情况下，网页的浏览量一直不温不火，而利用这个时间，我们也抓紧时间通过代码方式，统计一些数据，为下一步的决策寻找依据。

当前已经设置了一些数据的采集点：

1、主页PV、主页上各个链接的PV；

2、下载量；

3、写锁量（下载后的安装量）；

4、下载转化率；

5、写锁转化率。

从这些数据已经能看出一些趋势，当前的主要结论是：

1、主页浏览量比较稳定，没有明显趋势，日均PV值不大；

2、下载转化率比较稳定，说明我们的宣传起到了作用；

3、写锁转化率低且不稳定，这部分原因需要跟踪，主要可能性：

1）下载时间过长，产生下载行为但是没有完成下载（网络原因？安装包太大？）；

2）用户放弃安装（不知道该怎么做？对免费改变主意？以后再说？）；

3）用户的工作机器没有上网环境；

4）安装失败（正开着Q4？下载文件有问题？没有加密锁？网络锁？GBQ版本问题？定额库？加密锁驱动？操作系统？杀毒软件？）；

5）申请试用失败。

4、我们的统计数据质量需要持续验证、异常情况也需要识别并解决。

今天通过数据发现了一个现象，有一个用户不断申请试用。通过对数据和CRM的分析，发现他无法申请成功，所以一直申请，首先需要解决这个问题，否则我们的数据存在噪音。

【9月9日-Don’t Make Me Think】

今天有个客户联系我，他通过网络下载了我们的产品，也正确安装了，并且通过网络的方式获得使用权，这时候他的问题是：我该怎么使用？

大约用了半个小时向他介绍了产品的使用，这个过程让我意识到我们的产品和销服存在的几处硬伤：

1、产品的学习门槛过高，不讲解用户不知道该如何用；

2、产品的一些按钮名字起得比较拗口，用户难以产生印象；

3、通过电话的方式解释产品如何使用比较困难。

对于我们这种面向大众的产品，用户体验极为关键，这将是我们工作的重点，无论从意识层面还是从流程上都要进行要求；

其次是推广中的策略：

1、网页宣传中要提供在线体验；

2、首次登陆可以采用向导方式指导用户使用；

3、采取游戏中常用的任务方式，按照任务全部完成后赠送50次应用；

4、完善易用的联机帮助；

5、视频教程。

本文链接

【产品经理工作笔记】第36周工作笔记

2011-09-06T03:01:00Z

【8月29日-心中有爱】

周六的时候和小秘去了一家用户处拜访。

这是一家不大的公司，租在居民楼里。里面做预算的只有一个人，他购买了我们的全套软件，我在讨论业务的过程中，“不经意”问了一下当时为什么购买我们的软件。

用户很坦诚，告诉我们他们在购买全套软件的过程中，我们的销售同事向他讲解了我们的产品，他基于对我们公司的信任就买了一套。同时他也坦诚地说，因为一些原因，买了之后他并没有用起来。

在我们咨询他工作过程中的问题的时候，他打开了话匣子，特别提到了两个需求，是我们一直想做，但是因为产品节奏和资源原因一直没有做。

这次的拜访，除了产品和业务上的收获，对我最大的触动是：

用户基于信任而选择了我们的产品；

用户和我们一样，都是辛苦工作，使用的工具还并没有那么顺手；

用户并不是都在高档的写字楼里，我们的这家用户办公桌边一张床。

想一下，我们的努力，能让我们的用户提高效率，将自己从重复、烦杂的工作解放出来，专注于创造性的事情中，这是件多么令人心动的事情。

做产品要心中有爱——爱我们的产品、爱我们的客户、爱我们的团队。

【8月30日-自动化测试】

丹丹在用户处调研，用户发现了一个很严重的报错：选择某条数据之后报异常，而且无法关闭，必须杀进程。

当前我们只有两个人测试，我们的产品要测试我们本身的功能、要测试和我们产品相关产品的功能、要测试大量的数据是否准确，工作量和难度确实非常大。

现在能想到的方案是使用自动化测试，而且基于我们产品当前的现状，我们需要低成本使用自动化测试。

可以采取的几个步骤是：

1、整理出典型的测试用例；

2、请**协助将测试用例做成自动化测试脚本；

3、请**协助跑自动化或者请**协助我们搭建自动化服务器，我们自己跑自动化；

4、安排一个人针对性学习。

自动化解决不了全部的问题，至少能协助我们完成大部分工作，让我们能把精力和时间放在更重要的部分。

列为下月的专项任务。

【8月31日-拜访客户准备事项】

周六和小秘去了一下***的一个客户，在准备客户资料的时候列了一下拜访客户的准备事项：

1、客户公司的类型？

2、客户公司的规模？

3、被访谈人的性格？籍贯？家庭情况？爱好？

4、公司的风格，拜访时适合穿职业装还是休闲装？

5、客户主要做哪个专业？

6、购买我们产品的原因？

7、和我们公司的关系？

8、都买过我们哪些产品？

9、负责此客户的销售员是谁？

这些问题应该都能从销售员处得到信息。

【9月1日-我们都是LPDT】

今天的LPDT学习分享会中，一位同事用了“我们都是LPDT”作为结尾，让我感到很温暖，也为自己属于这个团队而骄傲。

在上午学习过程中，我梳理了一下LPDT需要的能力，特别是针对自己的现状做了分析。

LPDT需要的能力：

整体营销能力、业务能力（专业知识、业务架构能力）、市场敏感、项目管理、团队管理、策划能力、计划能力、销售能力（单兵销售能力和带团队销售能力）、数据能力（数据获取、调研、数据分析）、沟通能力（含口头表达能力）、文档能力、人员培养、商业计划书（单列出来，产品经理必须的能力）、个人影响力。

对照我自己，在这些技能中有一些技能我已经达到LPDT的要求，短板也非常明显。

接下来的一个多季度的时间里，需要快速提升技能，采取的策略是集中突破和事件驱动，对于我自身而言，接下来的行动是：

9月，通过承办*****提升专业知识；

9月，通过整理*****的商业计划书，梳理产品发展方向，同时准备10月份的LPDT分享会内容；

10月，用户短路，促单，改调研为销售，提升自己单兵销售能力和团队销售能力；

11月-12月，结合2012年规划，提升策划和计划能力。

同时9月份要结合团队成员的现状和期望，列出每个人的能力提升计划。

【9月2日-LPDT9月学习笔记】

1、每个阶段LPDT承担的职责不同：在**阶段担任的是客户代表、***阶段担任研发人员、****阶段是销售员+销服经理、****阶段是分公司经理；

2、对于新产品，业务本身的研究是最重要的。技术往往是约束、商模要结合业务研究；

3、数据分析能力对于LPDT至关重要；

4、选择渠道很重要。自有渠道成本低，自建渠道风险大。如果要自建渠道，要好好算清楚投入产出比。可以选择两个差不多的渠道，一个单建渠道，一个现有渠道，进行对比和比选；

5、LPDT深入一线，切身体会用户的痛苦；

6、样板量：选择样板地区的客户总量*狂热分子的比例（5%）*撬动这部分用户的比例（>50%）；

7、**的客户管理和服务管理值得大家学习；

8、选好自己的定位，不要轻易选择*****，要争做*****；

9、让别人办事很难。要自己主动推进；

10、先弄明白自己，再考虑和别人协同。

本文链接

用户体验

2011-03-28T10:33:00Z

    用户体验是一个很大的话题，先从一个故事说起。
    周末参加了两天的PMP培训，听课期间注意到老师的一个细节，在讲选择题的时候，选项A、C读音正常，而“B”老师读为Boy，“D”老师读为Dog。
    刚听到的时候大家莞尔一笑，以为这是个善意的玩笑。但是以后的题目都是这样读音。
    很快，我想明白了，B和D的发音类似，容易混淆；Boy和Dog是简单的单词，发音能够明确区分，也没有类似Bog和Doy的读音混淆。
    这是什么？这就是用户体验。

    用户体验这个词似乎突然流行起来，似乎因为以前过苦日子，不在乎衣着打扮，最近大家富足了，审美提高了，突然迸发出了需求。
    当然也和大环境有关系，比如苹果的成功，很多人就认为是用户体验至上；360不管口碑如何，产品也经常被（包括Pony）作为用户体验的榜样。
    我们公司也是如此，大家言必称用户体验，就像前两年的“敏捷”一样。上个月隔壁的老赵问我有没有做UE的朋友，能够出到15W的年薪。虽然在北京，我认为这也是个不小的数字，可见我们对UE是多么地求“贤”若渴。

    如何做用户体验，我一向反对把“最佳实践”、“方法论”、“框架”挂在嘴边，也反对固守己见，不接受别人的见解。没有任何两个项目是完全相同的，也没有任何两个产品面临的现状一样。因此，我们应该以“清零”和“包容”的心态学习成功的经验；同时以“怀疑”和“批判”的态度进行分析；最终形成自己能够想得明白，有可操作性的方法。一句话，反对照抄和不抄。

    我们的产品规模很小，功能也很少，这就意味着我们和大型项目的处理方法可能会不同。如何让我们的产品能够拥有良好的“用户体验”，从而获得用户的认可，并且叫好又叫座，这是我最近一直在思考的问题，当前主要的结论如下：

    第一步，分清责任人，用户体验是产品经理的活。
    不要片面把用户体验看做是UE的活或者需求的活或者开发的活。现实情况中，UE未必懂业务，需求未必有美感。如果恰巧你的开发也把用户体验看的很重要，在设计或者编码的时候会自然而然考虑，那么，恭喜你，捡到宝了。这是不现实的：一方面，一个各个岗位都很强而且能够自组织的团队，搭配一个Sales就可以了，还要产品经理干嘛？另一方面，每个人的审美是不同的，每个人编码的时候都考虑到了界面展示，风格都未必统一。再培训一下，统一界面风格，统一色彩搭配，统一控件形状，统一命名规则……如果这样，还是搭配一个专业UE吧，开发好好考虑一下性能、开发效率、Bug数和扩展性吧。拿建筑做比喻，需求就像是设计师，决定做什么；开发负责土建部分，搭建毛坯房；UE负责装饰装修，让建筑适宜人居。因此，除非扩专业的人才，这几个角色都无法单独承担用户体验的工作。产品经理重要的一个职责是整合，他需要从全局和整体处理用户体验的问题。用户体验的好坏往往从需求定义的时候就开始受影响了，因此产品经理需要贯穿项目始终。

    第二步，创造氛围
    这个氛围指的是让大家认可用户体验很重要，但是避免夸大用户体验的重要性。
    产品经理需要采取一些措施使得团队成员，不管哪个角色都认可用户体验很重要，当涉及到分派的与用户体验相关的问题的时候需要积极配合。
    通过创造氛围，也欢迎团队成员就用户体验提出自己的建议，产品经理需要作出判断。
    这些措施可能包括一起学习用户体验的相关知识、内部培训、换位思考等等。
    至于不要夸大重要性，是说真的没有必要在你做需求的时候，脑子里面框个用户体验的框框；在编码的时候，想着怎么配色；在UE的时候，想着客户的骂声。同时，避免镀金的行为：很多时候，加多了，意味着出错的几率大了。

    第三步，分清先后
    把握先能用，再好用的原则。在项目的初期，要高效率完成能用的版本，这主要为了验证业务思路，确定产品方向。
    我们做成GCL、GQI两个亿级产品的肖工，曾经分享了一张PPT，给我印象深刻：每个迭代的交付物都是可以独立工作的产品。
    一定要避免做一个完美的半成品。这里引用百度的一句话：快速迭代，越变越好！

    第四步，单独处理
    我们的任务安排往往过于追求功能性需求，而忽略非功能性需求。比如在我们的一个Sprint（Scrum术语，表示一个迭代周期）中，往往功能项嫩巩固排到这个迭代的最后一天。大家都忙于做功能、改Bug，有哪门子闲情逸致考虑你的用户体验？能赶上每天的末班车就谢天谢地了，难道真的希望我们通宵达旦地天天干啊？
    因此，建议将非功能需求单独列为一个Sprint或者功能点（敏捷中常常称为Story），不要将这些想当然认为是功能性需求的一部分。

    第五步，验证
    我们所做的不仅仅是客户验证。在《Show stopper》中提到卡特勒在微软NT开发期间提倡的吃狗食，也就是说所有的人必须在尚未开发完毕的NT上进行开发。
    因此，一方面，验证分为内部和外部。在产品上市之前，要求我们团队的所有成员都会用我们的产品做工程，都能够帮助用户解决问题，都习惯给我们自己的产品挑刺。我们还需要走出去，找不同的用户或客户对我们的产品进行试用，还需要能够做到试用第三步的方法，快速迭代，越变越好！

    另一方面，拿实物验证，不要用原型或者口对口进行用户体验的验证。即使高仿真的原型也不是用户真实工作的软件，因为你无法验证是否会关键时刻出Bug、是否存在性能问题、是否出现令人啼笑不得的提示、是否出现数据的逻辑问题……

    第六步，平衡
    很多人会乐道苹果是怎么追求用户至上，怎么样追求完美到偏执。如果成功有现成的流程，那么苹果不会这么少。产品经理一项基本技能就是平衡能力：用户体验和进度冲突了怎么办？和成本冲突了怎么办？和资源冲突了怎么办？
    谨防借着用户体验之口的需求蔓延。举个例子，你花1000元买个相机，你会要求它给你配2个镜头、采用航天材料做外壳、采用顶尖的卡尔蔡司镜头、具备单反能力……
    用户体验往往和进度、成本、资源等是有关联的，因此如何做好平衡非常重要。

    第七步，总结
    不管这个产品成功还是失败，一定要做阶段总结，这样才有可能越做越好。实际上，找一个有做产品经验的人（比如Jobs或者周鸿祎）可能比学习所谓的“最佳实践”，做成产品靠谱得多，这就是总结的作用。

    声明：这仅仅是我自己的思考，不代表正确，更不代表我们公司的观点。欢迎大家一起讨论。

本文链接

由招聘想到的

2010-12-22T16:27:00Z

由于部门明年业务线的设置，我们部门需要增加几名开发人员，我也承担起了部分的招聘工作。在这段时间里，接了很多的简历，也参加过面试，其中有多年从业经历的老程序员，也有即将毕业的新人。在这期间，有两个人给我留下非常深的印象。

第一位是一位31岁的资深程序员，他在论坛上看到我的帖子，给我留言说已经参加过四轮我们公司的面试，已经通过了TongX的技术面试，并暗示我他是通过猎头的介绍和我们公司取得联系。我咨询了人力部，得到的答复是这位朋友的能力和要求的薪水存在比较大的差距。通过一段时间的网上接触，我感觉他的团队融入度应该不错，而且有多年的开发经验，于是请人力部再邀请来面试一次。

面试由金根、智哥和我来负责，结果很让人沮丧，我们三人一致认为这位朋友的技术能力太差。当天，我们请人力部回绝了这位朋友。事后也和他聊了一次，能够感觉到他的沮丧。对于一个已婚有孩子，在北京生活的人来说，生活的压力使得一份有保障、有希望的工作成为一种梦想。这次面试之后，我感到一些难过，即为这位朋友曾就业的环境感到惋惜，也为他工作7年多来的不够进取感到遗憾。

第二位让我印象深刻的是在HBDLDX招聘时遇到的一位男同学。他穿着西装，告诉我他学计算机专业，希望从事管理。我告诉他笔试时间，他走了之后犹豫了一会又走回来，问都笔试什么题目，然后补充说他由于没有考研，可能基础的东西记得不是很清楚，又补充了一句，如果考研的话笔试肯定没有问题。这位同学还和我透漏他在学生会工作，有一定的管理经验。

老江上周说，智力型的组织是最难以管理的组织，这位同学，如果一开始就以管理为目标，需要格外的努力了。

这些天和很多同事、朋友聊过，给过别人建议，别人也给了我建议，自己也一直不间断在思考。对于一名程序员，怎样的职业发展之路能够做到安全、激情和快乐，甚至实现财务自由？

以下是我的思考，抛砖引玉，希望给大家一些参考，也给我一些建议，遵循金根提到的神奇的数字“3”。

从程序员的角度来说，有3个领域比较值得关注：

1、解决方案；

2、Web开发；

3、特定平台的App应用。

解决方案一般需要具备行业背景，Web开发和特定平台的App应用当前是内容驱动。Web开发指基于浏览器方式的互联网应用，而App指在某个平台下（iOS、Android、WP7、BlackBerry、MeeGo、Windows等等）。很多人都在疑惑为什么Google同时推Android和Chrome两个操作系统，这也表明Web和App两种方式目前来看都没有一统天下的迹象（Google似乎都拿不定主义，各赌一把）。

从技术的岗位来说，有3个可供参考的职业发展路径：

1、特定技术领域技术专家；

2、技术架构师；

3、系统分析师。

技术专家一般针对特定的领域，比如图形、密码、数据库、操作系统等等，需要做到研究深入；技术架构师更多强调的是整合能力。经过数十年特别是最近十年的发展，从架构层面上来说已经形成了很多稳定的架构风格和框架产品，需要架构师从无到有设计的机会正在变少。架构师更多的需要做的事情是根据项目或产品的需求，选择适当的架构风格和恰当的框架，来以尽可能小的代价完成。系统分析师是业务和技术之间的桥梁，需要完成业务分析到系统设计的过程，比如我们很多同事希望走咨询的职业路径，这实际上就是系统分析师。

如何更好完成职业发展路径，参考一些职业规划的书、杜拉拉和金根的《和工作谈恋爱》，我觉得最重要的3条是：

1、好的环境；

2、专注的行业；

3、自身的眼光和持续的努力。

对于好的环境有很多方面，比如稳定的工作环境、培训、明确的职业指导、高素质的同事等等。我来公司之前从CSDN上知道了小明，金根是我技术上的第一个师傅，我知道他们在广联达工作了超过8年，这从侧面上说明了环境；行业知识需要积累，特别是非科班出身的程序员们，因此如果可以尽可能选择一个行业对自身的积累非常有好处；至于眼光和努力则是充分必要条件。金根在一次晚饭的时候提到，他当时并不属于平台组，只是他自己比较喜欢钻研，主动学得比较多。

从技术领域来说，有一些技术非常稳定，在这些技术上深入研究可以成为特定技术领域的专家。我觉得比较稳定的3项技术是（主要针对我们公司）：

1、数据库、数据仓库、商业智能；

2、图形；

3、特定语言。

有一些之前一段时间和当下非常火爆的技术，比如云、SOA、物联网……，也需要持续关注。

很多人提到了转管理、转需求、转销售、创业等等，除了自身的兴趣之外，程序员也是凡人，也需要遵循马斯洛的5层需求、也要考虑职业安全和职业前景，从我的视角上来看，有三个职业比较适合程序员的转型：

1、项目管理；

2、产品管理；

3、技术型销售。

程序员都是在项目中真刀真枪中搏杀出来的，知道项目中存在的问题，也有一肚子想法，因此从开发转项目管理是相对流畅的一条道路；产品管理要比项目管理困难得多，阿里巴巴的一名产品经理说自己比技术懂业务、比业务懂市场、比市场懂管理、比管理懂技术。这像是一句玩笑话，却说明了几个问题：需要懂得多、需要站在更高层面、需要承担更多责任。华明曾和我提到过技术型销售，一般在一些软件、咨询等公司里，提供技术产品，从技术入手转技术型销售也是一条转型之路。

在即将开始的2011年，在即将的30岁，我准备好了吗?

本文链接

提高系统架构师论文成绩的总结PPT

2010-10-10T14:57:00Z

很多朋友报名参加系统分析师考试，在这项考试中，论文被视作一个难点。目前离考试还有一个多月的时间，如何利用好这一个月的时间快速提高论文考试的成绩，我们都很关注。这些日子我总结了一些自己的经验和教训，和同事做了分享，现在把PPT的主要内容页复制到这里，希望对同时备考的朋友起到抛砖引玉的作用。

我参加过系统分析师的考试，下面PPT的一些要点有的来源于我的实际经验，有的来源于一些参考资料，不一一指出了。很多属于我的一家之言，欢迎大家讨论和补充。

本文链接

《企业架构》读书笔记

2010-05-17T05:21:00Z

《企业架构》一书的读书笔记

关于创新的反思

2010-05-17T05:08:00Z

我向部门提交的一篇关于创新的一个反思。

老系统维护（四）-我是否最合适的人

2010-01-31T01:59:00Z

我是否做这个项目最适合的人？如果不是我能否说不？这是我在老系统维护中的一个反思。

老系统维护（三）

2010-01-31T01:45:00Z

关于老系统维护的一些反思。

我的实践与反思-观察者模式

2010-01-13T12:28:00Z

我的实践与反思-观察者模式