[答疑]屌丝可以接受土坑酸菜面吗-架构可以影响需求吗

2023-10-13 05:18

本文主要是介绍[答疑]屌丝可以接受土坑酸菜面吗-架构可以影响需求吗,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Alan 2022-3-18 9:46

潘老师,RUP里这个观点,架构影响用例,与你的课程里的观点不大一致,用例就是什么啥,该用什么药就用什么药

实际也会可能因病人家里穷,用的效果没那么好的药,所以RUP这个观点感觉与实操比较符合。

UMLChina潘加宇

这里面有一些思想上的错误,即使是RUP的作者们应该也没有意识到。

错误一:认为医生手上已经有各种各样的“药”给病人挑选。

实际上并没有,否则你拷贝一份给他不就行了?

软件的复制成本几乎为零,主要成本是研发的沉没成本。

病人是什么样的?病人是不是你想争而且能争到的?要给病人弄一个什么样的药才会让病人满意?这些并没有答案,所以才需要做业务建模和需求工作,搞清楚要做的“系统”应该是什么样子,才能被目标组织的老大所接受,才能“卖”得出去,得到符合期望的回报。

如果没有这个环节的思考,可能会导致大量研发资源沉没进去,做出系统后却得不到符合期望的回报。

错误二:以为医生可以随便挑病人。

如果说研发团队的情况(包括人员基本素质、擅长的领域、擅长的实现技能、现有的技术积累等,图中说的“已有构架”包含在这里面)会“影响用例”,那是发生在定位目标组织的时候。

研发团队负责人根据研发团队的情况,预测如果本团队研发某系统加入各个战场的胜利回报和胜利概率,来确定研发团队当前最值得加入的最佳战场,即系统的目标组织的老大(最佳病人)的大脑。

搞武器系统回报高,可是研发团队擅长的是PHP+MySQL,加入这个战场胜算极低;把团队已经做过的某网站系统随便改改,在自己熟悉的行业卖,可是这个东西的价格已经低得可怜,回报不划算。

所选择加入的战场不同,需要做的系统不同,系统用例自然也就不同。

用看病类比,就是:医生根据自己擅长的医疗技术和治疗某种疾病带来的回报挑选自己最合适的病人。

但是要注意:某个医生可以不乐意接诊某类病人,但该类病人的病情没有变。只不过从医生的视角看,可能会有“病人的病情变了”的错觉。

错误三:以为“穷病人”就好商量。

一旦经过慎重考虑选择了某个战场,就要意识到,战场上有很多对手在和我们争夺,步步惊心。

而这一点,很多开发团队并没有意识,例如问题中的“病人家里穷”就体现了这一点。

以为“病人家里穷”就可以爱怎么干怎么干,殊不知分分钟病人都在把你的所作所为和战场上的其他对手比较,在心里的小本本记着呢,我们还茫然不知。

既然你选择了某个目标组织(人群或机构),说明你是认可为它服务所获得的回报的。

你的老坛酸菜面瞄准了屌丝,说明你是认可屌丝出的这个价格的,这已经不“穷”了。

你试试和屌丝协商一下,老坛酸菜面能不能用脚踩的土坑酸菜,你看他砍不砍你。又不是非你不可,大把的竞争对手和你在抢这个屌丝。

每个战场的竞争都是残酷的。如果做面向屌丝的老坛酸菜面很容易赚钱,猪都能飞得很高,会怎么样?大量资本会从房地产、汽车制造甚至飞机制造等行业迅速涌入,难度马上和其他战场拉平。

即使是选择了某个目标人群“免费施舍”,也是认可在他身上获得的回报,例如感恩,称颂,选票等。“免费施舍”也有大量的竞争对手,难度也是杠杠的。

当然,加入战场之后,发现之前的判断错误,以自己团队的特点,在这个战场实在不好混,可以忍痛割肉撤离,换一个战场。

如果“已有构架”就是擅长脚踩土坑酸菜,中国混不下去,可以把你的方便面的目标人群转向津巴布韦嘛。当然,津巴布韦有津巴布韦的战场。

但一旦加入某个战场,就不要有侥幸心理,要意识到对手的存在,尽力去打败对手。可以选择以最小成本“险胜”对手,也可以选择大力“碾压”对手以立威。

如果说可以“和客户协商”,协商的出发点应该是以这个价格,应该先解决哪个最重要的问题,绝对不能从“已有构架”出发——因为“已有构架”这样,所以需求这样。

可以参考以下链接:

[答疑]反正最后都会有增删改查用例,为什么不直接写出来?

[答疑]系统用例多少个为好?1个!

[答疑]创业公司玩不起建模?

错误四:以为“大家都是这么干的”就是对的。

问题中的“感觉与实操比较符合”大概是说“大家都是这么干的”,但“大家都是这么干的”和“这么干是正确的”未必一致。而且,越有思考难度的工作,“大家这么干”和“这么干是正确的”相反的可能性越大。


总之,如果某种“需求实践”是从竞争角度出发的,它可能是正确的,但往往是辛苦的。

反之,如果没有竞争的意识,就会迅速滑坡,弄出各种开发人员喜闻乐见的、“简单易行”的“最佳实践”——“爱做什么做什么,反正总能找到人来用嘛”,“爱开什么药就开什么药,反正几十亿人总能找到合适的病人”——再冠以“工程师文化”、“敏捷实践”、“DDD实践”之类的名头来割韭菜。

这篇关于[答疑]屌丝可以接受土坑酸菜面吗-架构可以影响需求吗的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/201016

相关文章

SpringBoot中的404错误:原因、影响及解决策略

《SpringBoot中的404错误:原因、影响及解决策略》本文详细介绍了SpringBoot中404错误的出现原因、影响以及处理策略,404错误常见于URL路径错误、控制器配置问题、静态资源配置错误... 目录Spring Boot中的404错误:原因、影响及处理策略404错误的出现原因1. URL路径错

MySQL 缓存机制与架构解析(最新推荐)

《MySQL缓存机制与架构解析(最新推荐)》本文详细介绍了MySQL的缓存机制和整体架构,包括一级缓存(InnoDBBufferPool)和二级缓存(QueryCache),文章还探讨了SQL... 目录一、mysql缓存机制概述二、MySQL整体架构三、SQL查询执行全流程四、MySQL 8.0为何移除查

微服务架构之使用RabbitMQ进行异步处理方式

《微服务架构之使用RabbitMQ进行异步处理方式》本文介绍了RabbitMQ的基本概念、异步调用处理逻辑、RabbitMQ的基本使用方法以及在SpringBoot项目中使用RabbitMQ解决高并发... 目录一.什么是RabbitMQ?二.异步调用处理逻辑:三.RabbitMQ的基本使用1.安装2.架构

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

【系统架构设计师】黑板架构详解

黑板架构(Blackboard Architecture)是一种软件架构模式,它模仿了多个专家系统协作解决问题的场景。在这种架构中,“黑板”作为一个中央知识库,存储了问题的当前状态以及所有的解决方案和部分解决方案。黑板架构特别适合于解决那些没有确定算法、需要多个知识源(或称为“专家”)共同作用才能解决的复杂问题。 一、黑板架构的组成 黑板架构主要由以下几个部分组成: 黑板(Blackboa