导航

上一页 1 ··· 19 20 21 22 23 24 25 26 27 ··· 87 下一页

2022年12月27日

摘要: 四象限法则将需求按照紧急和重要两个维度划分为四类: 重要且紧急,这类的事情可能是:明天有个重要的报告要提交、要考试了才开始看书、要上台表演了台词还没记熟... 重要不紧急,这类的事情可能是:提升职业技能、建立人际关系、英语四级考试... 不重要但紧急,比如:突然发起的会议、被安排了一个临时任务、来了 阅读全文

posted @ 2022-12-27 15:43 蝈蝈俊 阅读(550) 评论(0) 推荐(0) 编辑

摘要: 投入产出比(ROI)主要考量效益和成本。 效益可以包含直接收入,运营效率及推广成本减少,用户效益等。 成本主要是人力成本、时间成本和金钱成本等。 潜在风险有时候也是未来的一种成本。 较小的成本获取较高收益的需求一般优先级较高。 当然,在实际操作中肯定没有这么简单粗暴,还会考虑一些其他因素。 几个行业 阅读全文

posted @ 2022-12-27 15:17 蝈蝈俊 阅读(3230) 评论(0) 推荐(0) 编辑

摘要: 老板需求是产品经理无法避免的,而且一般优先级较高。 这主要是从需求来源的维度去考虑,有同事、用户、老板..... 为什么收老板需求优先级高呢? 首先,老板的经验和思考高度一般是高于一般产品经理的。 其次,老板是直接为产品最终结果买单和负责的。 最后,不按照老板需求来,产品经理可以滚蛋了... 这里讨 阅读全文

posted @ 2022-12-27 11:19 蝈蝈俊 阅读(36) 评论(0) 推荐(0) 编辑

摘要: 一般意义上的产品生命周期是指面向市场以后的四个阶段,包含引入期、成长期、成熟期、衰退期四个阶段,可能在衰退期之后会焕发出新的第二增长曲线,一般被视作为是另一个产品的“前产品生命周期”。 产品处于不同阶段,侧重点是不同的: 处于引入期,能带来新增的功能优先级较高。 新增达到一定量级的成长期,留存变得更 阅读全文

posted @ 2022-12-27 11:05 蝈蝈俊 阅读(155) 评论(0) 推荐(0) 编辑

摘要: 卡诺模型(Kano Model)是由日本东京理工大学教授狩野纪昭(Kano Noriaki)博士提出,揭示了需求与用户满意度的关系。 卡诺模型将需求分为五种: 必备型需求:具有这类属性的功能属于产品的基本功能,如果不满足该需求,用户满意度会大幅降低。但是这类功能也无法给用户带来惊喜,满意度不会因为这 阅读全文

posted @ 2022-12-27 10:30 蝈蝈俊 阅读(1212) 评论(0) 推荐(0) 编辑

摘要: DDD是解决 软件复杂度 中的业务复杂度问题的,是微服务划分最好的实践。 业务复杂度主要表现在:客户的业务需求,比如业务流程多,参与者多等,而且这种复杂度往往会随着需求规模的增大而指数级增大。 在分析软件复杂度之前,先要了解业务价值所在。即DDD的领域与核心域这里所说的关注业务核心域。我们是要聚焦解 阅读全文

posted @ 2022-12-27 06:37 蝈蝈俊 阅读(202) 评论(0) 推荐(0) 编辑

2022年12月26日

摘要: 波斯顿矩阵是由波士顿咨询公司发明的一种方法,最早用于分析市场增长率和市场份额。现在也被经常用于对需求的分析之中。 波士顿矩阵 波士顿矩阵由用户价值维度和公司价值两个维度将需求分成了四个象限: 明星需求 对用户体验有价值,对公司战略也有价值的需求。 明星需求是双赢的需求,需要优先得到满足。如一些促进用 阅读全文

posted @ 2022-12-26 18:38 蝈蝈俊 阅读(626) 评论(0) 推荐(0) 编辑

摘要: MVP(Minimum viable Product)指的是: “用户愿意用、愿意付费” “团队有能力做” “用户易于使用” 开发MVP的主要目的是为了快速获得用户对产品反馈,那么对于开发MVP来说最重要的三个维度就是: 时间成本,能不能快速做出来; 是不是最重要的几个功能; 能否展现产品特色; 优 阅读全文

posted @ 2022-12-26 17:24 蝈蝈俊 阅读(176) 评论(0) 推荐(0) 编辑

摘要: 进化论告诉我们,当环境持续变化的时候,唯有不断调整自己以适应新环境的生物方能生存下去。 同样的,为了让软件架构拥有持续的生命力,我们需要主动让其演进以适应软件环境的变化。 一、架构腐化的表现 我们经常会听到这样的故事: 一开始他们进展很快,但如今,想要添加一个新功能需要的时间就要长得多了。 需要花越 阅读全文

posted @ 2022-12-26 15:40 蝈蝈俊 阅读(131) 评论(0) 推荐(0) 编辑

2022年12月25日

摘要: DDD的事件风暴第四个阶段“微服务拆分”,我们可以用限界上下文可以作为粗粒度的微服务边界,但落地时往往不得不考虑更多其他因素,比如弹性边界、安全需求、软件包大小、团队沟通效率、技术异构等等。 本阶段的 输入: 上阶段DDD事件风暴 - 领域建模的限界上下⽂地图 产出物:服务地图 在进行服务地图设计时 阅读全文

posted @ 2022-12-25 07:14 蝈蝈俊 阅读(180) 评论(0) 推荐(0) 编辑

上一页 1 ··· 19 20 21 22 23 24 25 26 27 ··· 87 下一页