今天群里由产品经理工作方法讨论到产品迭代的问题上，说说我的看法。
顺便说明几个可能产生需求更新、变更的环节，给豆荚。
在产品调研阶段，属于产品需求的储备，个人觉得不存在产品需求的更新，当出现商业目标和要求时，建立对应的产品和用户流程，使用功能体现，此时都属于产品策划阶段，大部分工作都是由产品经理完成的，辅助以市场、研发、销售、用户（客户）、老板等的目标、要求、信息。
当产品经理正式提交MRD（有的MRD不是来自产品，但后都应该由产品接手），项目确认立项后，某些情况也会造成需求更新，这些更新主要是功能或应用更新，不应该涉及核心的产品流程。
（也许有人会问，为什么不应该？项目立项表示项目需求已经经过可行性分析等环节，满足需要，如果此环节就发现更好的替代方案，那么就想办法再次说服你的老板，项目经理，研发资源，市场销售资源，重新立项）
项 目立项后，产品经理开始进行PRD制作，支撑以详细的需求说明文档【产品白皮书等】，在进行这个工作前以下的工作内容是你应该已经做过的。人无完人，所以 你的功能需求内容是在逐步推敲和完善中获得的，这时你至少需要接触两种人，一、你的客户（用户），cedar今天说应该让用户参与到产品开发中，个人比较 同意这个观点，但大部分公司不一定能做到（具体见向怡宁的《就这么简单》里面有提到一些这样的问题），不过小范围调研你还是可以做到的，使用axure作 个简单的低保模型并不会浪费太多时间，哪怕只是给受访用户演示页面跳转、简单的页面交互及信息反馈，询问他们这个是否是他们想要的，或者告诉他们将来“天 会是蓝的，草会是绿的”，甚至他们会给你意见“我认为这样可能更好”。不应该忽略这些意见和结果的重要性我想大家都明白。另一个人就是你的对应开发人员， 需求功能应该贴合技术能力（如果你的产品能带动技术突破那你更是神人），好的产品经理是把复杂的事情变简单，这里的简单不但是指简单化页面交互，如果某个 不常用功能使用Ajax的确可以让用户体验变的好那么一点，但是会造成10个人日的浪费，那么你就应该掌握好这其中的平衡，否则这些小问题会让很多事情变 得“不简单”。跟研发的同学讲讲咱们是要干什么，用户是想要什么，最好带他们参与几次上面的用户调研。别吓唬他们，更被让他以为我是在压迫他。
好 了，这时我应该已经有好几个版本的PRD了，注意PRD版本控制，这里的版本控制不是指将最后最新的版本提交给资源部门就可以了，而是应该注意需求沉淀， 有些功能是可有可无的但会提升用户体验，有些功能符合整体目标，但本期不迫切（例如在产品生命成熟期），好吧我应该把它们沉淀下来，特别是在时间紧任务重 的情况下。
遵从总体项目时间表，提交一个定稿的PRD给UED、研发人员，如果是一个连续的项目或者已经预期，把其他的需求也整理成档和资源部门的同事们说说，方便他们预留接口，但最好不要写在定稿的PRD里。
资源部门的同学们开始干活了………………
……
……
……
你可以去和他们聊聊天、喝喝咖啡，吃吃饭……@#￥#@，哈哈，是注意保持必要的沟通，每天去打个招呼，问问他们是否有什么是你可以帮忙的（如果他们让你帮忙coding，你有权选择直接无视或者告诉他们你是来打酱油的……）
一定要保持沟通，因为提交了PRD和时间表并不是说已经万事大吉等着秋天“收租子”就行了，因为这个过程中是需求最容易发生意外的时候，其实我早应该知道的“想的永远与执行有一定的差距”就算一些都OK，你也管不了地震和经济危机不是？
这 个时候出现的需求“更新”应该只服务于开发造成的功能修正或错误挽回（总之是亡羊补牢，在一个合理严谨的团队里这个窟窿一般不大，前提是需求阶段的“深谋 远虑”），切忌不是提新的需求。将因为人力或资源环境影响的不能满足预订需求的内容删改（注意触碰到核心流程时候要慎重慎重），这个删改有时候是必须的， 并不是妥协。互相理解吧。
在此过程和验收阶段产生的需求删改，要把“动过”的需求全部都记录下来，因为这阶段整个项目组可能会背负时间压 力，那如果提出的改进方案开发的预估时间超过本环节开发时间的三分之一，个人觉得在满足基本功能，损失体验的情况下，将需求安排进下期计划也未尝不可，如 果你有觉得你还有时间可以搏一下，那么也要注意项目的整体进度。
好了，在产品开发过程中，我们积累下了一些新的需求，可能因为功能删改， 可能因为研发建议，可能因为市场销售老板要求，也可能因为你长大了，思想更成熟了。这个时候本期项目已经进入收尾阶段，是否将需求滚入?个人意 见：NO。（另外，产品经理应该有能力区分啥是bug，啥是新需求）
上线了………………
不管你的计划本版是不是bate，在产品运营一段时间后，你都会得到很多需求，下面说迭代的问题了。
web产品、互联网产品开发讲究迭代，相对的是项目开发中的“瀑布模式”，啥是瀑布模式，百度知道一下。
我 觉得迭代开发在互联网产品中这么被推崇是因为以广大产品经理、ued同学为主力号召的“以用户为中心”理论直接造成的，今天在群里的讨论中，也提到了，大 家都不是典型用户，大家不知道用户想要什么，甚至用户也不知道自己想要什么，迭代提供一个产品，这个产品可能会很不完善，缺失很多功能，bug很多，用户 看了后会提供修改意见，会参与建设（如内容建设，如app、模板、widget等），这样我们就知道与实际需求的差距，进行用户、行为分析，在原有的基础 上进行改进，推出下一版产品。
迭代是指产品迭代，不是需求，不是功能，我更愿意认为是市场调研，竟比，用户行为分析，UED，开发，研发，运营一个持续的循环。（啊~谁能给我讲讲这个环境下的产品生命周期？哈哈~）
以上观点仅代表个人，如果说的太臭不代表公司和群组水平……囧。
有错别字，凑合着看。时间紧……
另外，今天
cedar 说 (15:00):
蹦跶说的迭代是产品升级。和系统开发中的迭代是两个范畴了。
因为非技术出身，所以不是很了解系统开发迭代，很困惑，但着急写这个，引出下一个话题…………………………
博文
没有评论:
发表评论