|
在论坛、知乎上经常看到一些「年轻的」产品经理发的引战帖，大意是：「开发大哥，我代码写的少，你可别骗我，这么简单的需求，明明一下午可以搞定，你跟我说一个星期?如果让我来的话，巴拉巴拉巴拉...」。看到这种论调，一些没耐心的程序员就会一笑了之，甩下一句「You can you up,no can nobb」，或者「你这么屌，你咋不上天咧」之类的回复潇洒走人，但是作为一名爱管闲事的程序员，我怎么能放过这个绝佳的「站在制高点上俯瞰众生」的机会呢?项目管理者联盟
 项目管理者联盟
先来反驳一下这位「年轻的」产品经理。写代码是一个典型的「纸上得来终觉浅，绝知此事要躬行」的事情，往往一些看似很简单的需求，实际上会遇到很多坑。你看过「人在囧途」吧?一段很简单的回家路，谁知道会有那么多的坎坷。就是这种感觉。项目管理者联盟
举个例子，你要实现一个「视频播放的时候，用户可以设置屏幕亮度」的功能。实际上系统提供了「设置屏幕亮度」的程序接口，你只需要去调用就可以了，核心代码可能就一两行，够简单吧?但是，一运行你就会发现各种问题。如果用户在我的 APP 里提高了屏幕亮度，退出之后要不要给人家还原呢?如果用户只是暂时离开了我的 APP，退出又回来，我是不是要给人恢复成原来设置的亮度呢?这些都是产品逻辑问题，你们沟通之后很快就解决了。但是后来测试发现，「设置屏幕亮度」的接口是一个很耗时的接口，可能会造成整个 APP 的卡顿，这时候你就得考虑用多线程来解决。引入多线程之后，线程之间的资源共享问题如何解决，谁先谁后的问题如何解决，等等...项目管理者联盟
 项目管理者联盟
举个例子，你要实现一个「视频播放的时候，用户可以设置屏幕亮度」的功能。实际上系统提供了「年轻的」产品经理不会想这么多，自己爽完提上裤子就跑了，留给程序员一堆烂摊子，程序员能开心的帮你干活吗?还有就是，程序员写代码可不光是完成功能那么简单，代码写的规范不规范，鲁棒不鲁棒，扩展性怎么样，都是需要事先下功夫去设计的。我一开始写代码的时候，就喜欢那种实现一个功能的快感，迫不及待的要秀给别人看，后来体会到并不是那么回事。写代码就像谈恋爱，一开始轰轰烈烈，海誓山盟，谈的久了，你会发现往往一些简单的小事，要完全负起责任，才是最难的。项目管理者联盟
「年轻的」产品经理不会想这么多，自己爽完提上裤子就跑了，留给程序员一堆烂摊子，程序员能开心的帮你干活吗?还有就是，程序员写代码可不光是完成功能那么简单，代码写的规范不规范，鲁棒不鲁棒，扩展性怎么样，都是需要事先下功夫去设计的。我一开始写代码的时候，就喜欢那种实现一个功能的快感，迫不及待的要秀给别人看，后来体会到并不是那么回事。写代码就像谈恋爱，一开始轰轰烈烈，海誓山盟，谈的久了，你会发现往往一些简单的小事，要完全负起责任，才是最难的。blog.mypm.net
说了这么多，就是想让你理解程序员写一行代码，究竟要「熬过多少患难，湿了多少眼眶」。这是动之以情。接下来我们谈谈如何正确的提需求，就是要晓之以理了。项目管理者联盟
提需求要有节奏感项目管理者联盟
不要误会，这个节奏感不是啪啪啪的节奏感，而是说你提的需求，要跟着项目的版本周期走。一般一个不是太拖沓的互联网产品，每个版本会经过功能开发、单元测试、集成测试、beta 验证、上线几个阶段，我们分别来看一下。项目管理者联盟
功能开发阶段，简直是程序员的美好时光。下午懒散的阳光打在脸上，泡一杯浓香的卡布奇诺加一点点糖，戴上女朋友送的 Beats 大耳机循环一首轻音乐，手指在机械键盘上跳来跳去，噼里啪啦的，就像脑海中忽闪忽闪的灵感，根本停不下来，对对，就是这样的感觉。training.mypm.net
 项目管理者联盟
这期间程序员要么做产品经理提的需求，要么闷头做一些技术需求。这是产品经理提需求的最佳时期，程序员刚刚结束了上一个版本紧张的发布期，急需要一些新鲜的需求来压压惊。技术需求是一些性能优化、代码重构之类的事情，这个虽然是程序员自己给自己提的需求，但是你一定要给他时间去做，不然程序员每天总觉得自己写的代码乱糟糟的，没有安全感。项目管理培训
单元测试是一个功能模块的需求做完之后，提给测试同学去找 bug。集成测试时所有模块的需求都单元测试完成之后，整体来一轮测试。这时候程序员天天在改 bug，你奇思妙想来一个新需求，他可能要象征性的反抗一下，但是大多数会乖乖去做。club.mypm.net
 项目管理者联盟
到了 beta 和发布阶段，大家都绷紧了神经，天天盯着用户反馈和线上的各种指标。这时候你突然被一块石头砸中，有了一个绝妙的需求，请 hold 一下，一定要 hold 住，因为你提任何需求都是会拉仇恨的。项目管理者联盟
先自己尝试评估一下需求难度项目管理者联盟
这个就有一点技术含量了。有些需求天生是很难的，比如智能推荐、智能识别、搜索引擎这种，需要很强的技术能力。还有些需求，需要前后端联调，后端开接口，商量协议，这些时间算上去总时间要翻倍。除了这些，剩下的就是相对的了，取决于是否有现成的轮子。程序员常说，「不要重复发明轮子」，就是说如果有现成的代码，就直接用不要自己再花时间写了。现成轮子可以来自开源社区、自己项目的积累、还有系统平台提供的支持。如果某个需求有现成轮子可用，那它的难度应该至少要减半。club.mypm.net
你想知道开源社区都是有哪些轮子，可以平时多看一些别人整理的技术博客，你可能并不需要知道里面技术上是如何实现的，你只需要记下，这个功能是有轮子可以用的，就够了。你想知道自己项目积累了哪些轮子，去问你们的开发吧，找他们抽支烟、吃个饭，很容易就套出来了。有些项目比较成熟，像推送、埋点上报、自动更新这些都有轮子可以用，但一些年轻的项目则不然，建立这一套东西也要花不少时间。你想知道系统平台提供了哪些轮子，就买一本介绍你们产品平台的技术书，比如《疯狂 Android 讲义》、《iOS Programming》，大体翻一下就行了，主要是了解一下这个平台到底可以做哪些事情。没有轮子可以用的需求怎么评估呢?少侠，你眼光不错哦，每天进来看看，你就知道答案啦。项目管理者联盟
下点功夫做准备项目管理者联盟
这是个普遍的道理，你让别人给你办事，吩咐半天讲不清楚，别人肯定不耐烦。如果你的需求是抄的别人的，可以拿别人做好的效果演示一下，这是最直接了当的。你的需求是业界首创的，可以简单画个流程图，如果这时候你能用上一两个技术上的术语，程序员肯定觉得你碉堡了。需求讲清楚了也要顺便让人理解为什么。这时候不要留情，把程序员带到你的产品世界里，用你丰富的经验打败他，他就会乖乖的跟你走了。项目管理者联盟
 项目管理者联盟
还有一点很重要，产品经理要给开发协调一些其他资源，像设计、测试这些，如果能提前准备好，那么即使是 beta 甚至上线阶段加需求，程序员也会十分感动然后再拒绝你的。项目管理者联盟
最后忍不住吐个槽。有些产品经理动不动就拉老大来给程序员施压，我觉得这种是最 low 的，连文章开头那些「年轻的」产品经理，水平都比他们高到不知道哪里去了。就好比两个小朋友打架，你打不过人家，喊的不是「放学你等着，有种操场见」，而是「我要告老师，看他怎么收拾你」。项目管理者联盟
|
