|
消息类型：系统通知、网站公告、订单消息、活动消息(其他类别)项目管理者联盟
消息类型可能存在扩容，而消息的状态相对固定/稳定，包括：已阅读、未阅读，完整诠释了事物的两个方面。良好的产品必定一开始就为后期的扩展预留了足够的空间，这也是一款优秀产品的开始。club.mypm.net
2.4 后台功能项目管理培训
因果循环，深深不息!站内信本质上是——某一特定场景之下触发的某一条通知性消息。大致分为：系统消息，主要是行为信息流的关键节点类通知;运营类消息自定义手动发送运营消息，主要是运营人员依据实际的业务需求手动推送的指向性信息。项目管理者联盟
系统消息：由系统业务流触发不同场景下的消息提醒，极具过程性，将每一个结果融于有意义的过程中。下文PRD案例中将会详细描述不同应用场景下的站内消息。club.mypm.net
人工消息：由运营人员在后台CMS内容管理直接投入到前台内容的生产和管理，俨然一副商业化营销和运营工具的样子。有时候，人恰恰才是最不可靠的!对人员的束缚就被提到了一个更高的道德层面。training.mypm.net
2.5 跨产品线项目管理者联盟
互联网发展趋向多样，单一产品跨平台、多场景的也是大势所趋、人心所向。产品路线规划图体现着公司发展的意志和资源性投入的重要参考。跨平台产品设计存在多难点，数据、账户、存储都值得付出和努力。站内信推送就是一个典型的例子，而这一点在面向C端的产品上体现的更加明显。以下为多产品线并行的一些值得思考的价值点：项目管理者联盟
产品形态：WEB消息推送时，是否同步推送H5/APP移动终端?项目管理者联盟
推送形式:(PC/手机)产品，消息推送的形式存在差异;项目管理者联盟
推送时机：不同形式(WEB/H5/APP)的产品推送消息的时段都有各自的特点;bbs.mypm.net
运营内容：消息的触发场景存在差异，即并不是所有推送站内推送都适合全平台推送;项目管理者联盟
需求管控是产品管理的核心环节，一句话：需求都没搞清楚，做个Pi啊!搪塞了多少老板的冲动，堵住了多少产品经理的嘴，挽救了多少技术程序员的付出。需求管理位于产品管理的上游环节，决定了下游产品、技术、运营等一系列工作的开展价值与意义。service.mypm.net
刚接触产品之初，需求管控——需求收集整理、分析细化、抽象具体、沟通确认、排期追踪几乎占据我个人工作内容的一大半。说实话，真要感谢那段时光，这么一项极具挑战而有意义的工作与我不期而遇。尽管充满不易与纠缠，细细想来却还是满心的不舍与难忘。项目管理者联盟
如果说人类起源于海洋，产品/服务必定是立足于——用户需求(RT)。这句话可以从两个维度解读：项目经理博客
产品/服务/解决方案不是无源之水、无本之木，也不是产品经理的一厢情愿，更不是凭空想象的不切实际。PgMp.mypm.net
用户/需求方概念是广义的，泛指老板、产品经理、运营人员、技术团队、产品用户等需求潜在提出者。
两大背景pmp.mypm.net
有人问：为什么需求管理拥有如此举足轻重的地位?存在即合理，需求分析的存在得益于两大背景：www.mypm.net
背景一、需求已经成为互联网/软件产品/服务的代名词。产品经理只要谈到产品，需求二字绝不离口。用户需求是产品/服务的最初出发点，还原原质化需求(Material
RT)，产品经理应该本着尊重事实的原则看待每一个需求。需求位列用户体验五要素的第一层：战略/需求层，强调了越早接触需求、越早理解需求。bbs.mypm.net
背景二、需求属于产品的顶层设计，决定了产品的方向及被赋予的意义。需求理解不到位、出现偏差，未能洞悉用户需求的本质，等待的只能是毁灭。核心环节之所以意义非凡，在于想要精准把握原始需求远比想象要难地多，将不同立场的需求提出者“统一思想、听指挥”更是不小的挑战。项目管理者联盟
两个问题service.mypm.net
纷至沓来的需求，最初显得有些凌乱。需求充分接触之后，我觉得需求分析过程的两个核心问题：PgMp.mypm.net
1、需求来源广training.mypm.net
2、需求数量多项目管理者联盟
|
