创造记录我的2年产品

做产品工作也快2年了。做过运营、做过编辑、做过媒体执行、做过产品。记录一些不是经验的“经验”。

1.需求篇
1.1 需求明确

由于公司架构的原因，70%的需求来自市场的同事，20%来自运营，10%来自领导+BOSS
其实这里的市场和运营，应该都统称为“运营”，只不过职责的区别的运营市场还是运营产品？为了后面好区分，就把2者分开。

市场的同事，往往更重视“销售”。因此会丢给我很多“客户”的需求。因为不是纯粹的外包公司，因此我们研发中心有一个基本的原则，就是所有东西不能脱离固有的架构，能复用的尽量复用。

这其实是很坑的。因为市场往往希望自己得到的都是“独一无二”的。如果带了太多固有东西的基因，首先客户使用起来就会显得不伦不类。这也是我处理需求最痛苦的地方。因此，就需要产品人员，有较强的需求把控能力。

客户很可能不懂互联网，更贴切一点，他可能完全是带着PC网页信息大而全的思维，再跟你讨论一个微信H5页面的需求。他希望功能有12345……，但实际上真正适用场景的，只有功能1.不能把需求全盘承接下来，包括产品运营的需求也是。他们更多的时候在意眼前的活动效果，多过长远的规划。当然啦，好的产品应该跟运营一起规划某个产品的未来。

举一个例子，用户登录，在创建社区账号与第三方快速登入之间，怎么权衡？怎么平衡？
换做2年前的我，肯定就主推第三方登陆了。因为一键微信orQQ登陆，实在爽快。谁会为了你的产品而填写那么多信息呢？在手机上，填信息不可怕，可怕的是切换输入法。不论是ios还是安卓，切换起来真心复杂，不流畅，相信大家也都深有体会~
但是，如果从长远的角度考虑，我们如何获取用户的更多信息？你没有用户的手机号，没有用户的邮箱，甚至不知道你的用户是男是女……这就是第三方登陆的最大弊端。并且第三方登陆，其实是程序帮用户在表里创建了一个账号和密码，只不过没必要让用户知道。但是，一旦涉及召回账号的场景，你试试第三方？用户会瞬间崩溃。
所以，产品一定要比任何人，都想的更远，并且多跟开发人员对接。新的用户怎么跟老的系统适配？有时候一个看似简单的需求/功能，在开发眼里，是极其复杂的。总而言之，需求，要反复演练各种场景，逻辑图一定要尽可能形成闭环。Yes or no?If ……else……PM一定要想清楚条件循环的问题。

1.2 需求细节
还是看似最简单的注册与登陆。
输入框要留多长？有没有必要确认密码？如何温柔地让用户填写尽可能多的信息？
这是一个复杂的问题，看似愈简单的场景，愈可能给以后留下坑。

1.3 避免需求的坑
我刚刚完成的一个项目，某国际人才交流大会，需要报名，报名的时候需要填写手机号。亲爱的读者，你看出坑在哪了吗？
坑就是，程序员第一次写的手机号的数据类型，是int型的，但是，这里是国际人才大会，世界各地的手机格式是不一样的，有些国际卡并不是132********这种，而是+32-342********这种。想一想，外国友人发现注册不了，是因为你告诉他手机格式不正确，他会不会有一种what the fu*k的赶脚~

这种坑赖开发吗？不赖，谁让你的PRD没有标清楚？赖客户吗？客户哪能想得到这些技术细节？那赖开发自己吗？没办法，你只能接锅，而且说实话，这种坑确认难避免，只能跌倒了长记性……
（待续）
2.沟通篇
2.1 PM要跟哪些人沟通
2.2 沟通的工具
2.3 沟通中的坑
3.推进篇
3.1 伪“项目管理”
3.2 加班与延期
3.3 交付与升级