总结下从书本中看到的和实际做开发、做产品时候的一点心得，写完这篇帖子的时候希望有能感觉到更深一层的意思。
做每一件事之前我们都需要有明确的目标，在聚焦细节之前要有大的远景，这可以在我们以后的实施过程中，为我们指引方向。如果这个远景能有些逼格和情怀那就更好了，起码对我来说是这样的。
所以第一条，产品开发之前要首先描绘远景、设置目标。
但是这么说太空了，对于远景我们应该思考什么？我觉得可以围绕三点（怎么有种领导讲话的范儿。。。）
1、我们为什么设置这个目标？为什么不是另一个呢？为什么非做不可呢？有没有其他解决方案呢？我们必须把精力集中在这个上面么？我觉得开发前想清楚目标很重要。比如我现在正在做通用SDK，目标是封装统一的接口，让手游CP接入渠道SDK的时候，减少开发时间，不会看要接入android上百个渠道的运营计划时，心里有万匹草泥马呼啸而过。
2、老许一直说的，以终为始，在做之前，脑子里应该有这货做完了是什么样子的概念。因为接下来的事情，都要围绕着你脑中的这个画面继续下去。画面越清晰，越不容易跑偏。
3、我们来做些什么来实现这个目标呢？
这方面我很喜欢facebook的设定目标方式，他们使用“SMART”规则
S：specific 非常详细具体的。你的目标必须清晰的被定义，不能混淆和误解。比如通用SDK，我们要减少开发者接入渠道SDK的开发时间，但是这还不够，因为大家对“减少开发时间”这一定义的理解是很难达成一致的，所以我们需要M。
M：Measurable 可衡量的，只有可衡量的指标才能让我们看清我们做得如何，离目标有多远，了解当前处于什么阶段，超出预期是不是请team的小伙伴们吃一顿，低于预期是不是需要增加资源的投入。你决定一件事，总要有依据的。
A：Aggressive 有挑战的，这个问题我最近也遇到的，因为通用SDK目前属于优化阶段，开发的小伙伴们觉得没有挑战，工作效率也会随之降低，至于怎么解决这个问题，让我这个PM拍脑门想一个。想的同时又得提到R。
R：Realistic 现实的，你拍脑袋想的那东西先别管有用没用，但是一定要现实，不靠谱的想法只能让RD觉得你也不靠谱。
T：Time bound 要有实现的期限，没有期限的目标是无意义的。因为你不知道什么时候应该达到什么水平。
好了，目标定好了之后你就有了需要专注的点，这才有可能有很详细的项目计划，所有内容都是要和这些目标相关的。不想管的东西会分散注意力，你要从心里坚决抵制。
第二条，收集各种想法并找到能用的
有了目标之后就会有很多想法，但是很难确定哪些想法能够帮到你。头脑风暴是个不错方法，但是要注意，一定要把“提出想法”和“分析想法”严格的区分开，肆无忌惮的提出你的想法，不用怕被批评。
等有了足够多的想法后，接下来的关键一步是分析想法，理论上如果我们有足够的资源，我们可以尝试所有想法，但是实际上我们必须把优先的资源放在最重要的想法上来。
还有一个残酷的事实，80%的影响是从20%的工作中来的，我们要做的就是找到那20%。列出TOP 1 2 3
第三条 跨团队沟通
如果不是敏捷开发的话，开发过程中是需要跨团队沟通的，其实这个沟通排除了个人关系以外，剩下的就是你体贴的换位思考了。跨团队沟通最怕的就是“意外惊喜”，比如我一拍脑门，哥们，我们需要加个需求，对方因为已经制定好了近一个月的计划还包括了和老婆还有小三一起出去的3P蜜月，你突然整一个需求要做半个月，很容易被技术杀掉的。
做好资源分配和提前沟通，很重要。
第四条 产品设计
说到重点了，对于任何一个项目，具体执行都涉及四个维度：有哪些功能、预期完成的时间、预算（人员、服务器、带宽、各种费用）、完成质量（扩展性、兼容性、性能等）。如果你的项目出现了什么问题，比如时间延后了，无非就是在这四个维度做出取舍，比如加人、投钱买服务器、砍功能、完成时间推后。
我个人认为比较好的方法是，快速出第一个版本，快速迭代，公司不会花重金让你打造一个霹雳无敌终极版，你需要用你的第一个版本去验证你的想法，看市场的反应，随后作出相应的调整。这样也避免了第一次投入过大，出了问题不能回头，只能推倒重来，这也太浪费了，又不是给国家添GDP。
但是这种快速迭代的产品，在用户量不大的情况下还可行，一旦你有一定的用户基数了，做一点点修改都有可能被喷成筛子，想想有一次QQ的升级吧。。。
针对这种情况，我建议用两种方法来避免，第一产品功能设计要设计师、工程师、产品经理都参与进来，讨论产品究竟要解决什么问题，围绕这个问题，设计最最重要的功能。然后设计师出样稿，大家对这个进行讨论、修改、讨论、修改，感觉差不多了工程师开始干活，然后在微调。
当然了，挑选什么样的人来参加讨论很重要，人多了就是冗长的会议了，根据中国人的文化底蕴和大环境影响，基本也讨论不出来什么。人少了，又错过了可以借鉴的经验。简单的说，就是找牛逼的人一起讨论。
还有几个算是小的心得吧。
1、不要过度设计。想得太多和拍脑门想，都是产品经理的常见病，得治。
2、简单但是并不简陋，secret做的我觉得就是个例子。
3、自己得是用户。你得有使用它的欲望。
4、确实有用，并且易用。
5、不追求完美，但是要有自己的底线。一下子憋出个大招儿是不可能的，当年翅膀这么和我说过，很有道理。同时要有自己的底线，比如我现在要求做的通用SDK，95%的游戏是直接可用的，有5%的游戏是用flash这种过时技术开发的，我就不建议为了兼容这5%而耗费太多精力。
太长了，今天先写一半，标题加了个“上”，如果明天有时间争取写完。关于我很重视的灰度上线功能和数据监测。
网友评论