网站建设技术外文文献,二级域名怎么解析,自己建设网站怎么被百度收入,广东 网站建设 公司排名最近在开发过程中#xff0c;遇到了好多次 “这个需求点这次要不要做#xff1f;” 的问题#xff0c; 主要有两方阵营#xff0c;比如以研发主导的 “这次先不做、等必要的时候再做” #xff0c;另外一方是以PM主导的 “这个不做需求不完整#xff0c;可能影响用户体验… 最近在开发过程中遇到了好多次 “这个需求点这次要不要做” 的问题 主要有两方阵营比如以研发主导的 “这次先不做、等必要的时候再做” 另外一方是以PM主导的 “这个不做需求不完整可能影响用户体验” 。争议主要出现在一些小需求或者细节点上一般不是啥核心功能比如一些鸡肋需求或者有些极端异常case的处理。 前者的主要观点是“这个需求不重要可能会浪费时间有哪些时间还不如做一些更重要的事”后者的主要观点是“这个点虽然不是核心功能但没有的话可能让用户决定我们产品有缺陷。” 如果遇到的两方脾气不好甚至可能闹到剑拔弩张的情况。 这两种不同的观点其实就是我标题上说的两种不同思维模式导致的前者的思维模式更偏向于 “抓大放小优先解决主要矛盾”而后者的思维模式就是“细节决定成败不放过一个问题”。不同的人在这两种思维模式上有不同的倾向就是孰对孰错、孰优孰劣。这仿佛是个无解的哲学问题下面我给出我对这个问题的答案仅仅是一份我自己的观点大家也可以在评论区探讨下。 首先我作为研发大部分情况下的决策都是“不做”因为做了会显著增加我的工作量软件开发过程中也存在二八定律80%的功能只占开发时间的20%而剩余20%的功能需要额外投入80%工作量。剩下20%的功能ROI是极低的这是我的第一个理由。 其次很多需要点和细节点只是别人的假设并不一定代表真实的场景大部分情况下这个需求点是伪需求直接拒绝可以有效避免研发人力的浪费。 我们举个我所遇到的例子。我们公司的业务建立在某云之上如果该云厂商宕机我们业务一定会挂这显然从业务上讲这是不可容忍的如果你去问老板你希望自己的产品稳定性是多少他一定会回答是100%。有一定技术经验的人都知道100%的稳定性是不可能达到的我们只能无限趋近于100%。 摆脱单云依赖我们唯一的选择就是要支持多云备份然而这个成本巨高可能需要我们全部技术吭哧吭哧改造几个月来完成这对于一个以业务快速发展的团队来说也是不可接受的。在这件事上我们都选择了坦然接受云厂商可能宕机的风险选择抓大业务发展放小极致的稳定性 再举一个决策完全相反的例子。我在入职阿里参加新员工培训的时候听老员工将讲到了阿里曾经的去IOE项目就是要在阿里巴巴的IT架构中去掉IBM的小型机、Oracle数据库、EMC存储设备。其中我印象比较深的就是他讲到支付宝替换Oracle数据库过程中他们投入了巨大的成本做数据稳定性一致性的验证因为金融级别的数据就是要求100%的准确性这种情况下就是追求极致的思维模式。 可能有些同学也看出来以上两个案例决策结果不一致的原因。表面看是业务场景的不同虽然我在案例一中没有具体介绍我们的场景但大家也能看出来我们是可以接受不可用风险的而且云厂商宕机其实算是小概率事件(虽然前两天阿里云就出事了)短暂出问题后我们的损失远小于投入人力减少多云备份的能力的。而反观支付宝替换Oracle数据库的事他们处理的是金融相关的数据也就是和钱相关的数据比如给你少算一分钱这不是一分钱的问题而是信任的问题一旦出问题公司可能就黄了所以他们出问题的成本是非常高的。 虽然这两个场景得出了不一样的决策但其背后都遵循同一个原则就是投入产出比最大化大白话就是在同样的收益下成本最小或者在同样的成本下收益最大。 投入产出比最大化 这个思路相信正常人都是认同的那为什么同样一件事不同的角色在抓大放小和极致细节之间选择不同的思维方式 答案就是不同的人对收益和投入的评估结果是不一样的。我举一些观察到的现象不一定完全准确
PM倾向于高估收益低估成本研发倾向于低估收益QA倾向于高估风险管理层和PM一样容易高估收益低估成本不了解技术的人容易低估技术成本乐观的人任意高估收益悲观者容易高估风险容易替别人低估成本替自己高估成本如果最近出过严重问题容易高估风险…… 有些是角色使然、有些是性格使然、还有些是环境使然这些都很难控制只能多沟通、建立规范、多尝试各方在软件开发过程中可以参考下这些建议希望可以尽可能减少在成本和收益上的认知偏差。
在评估收益时,我们应该考虑功能对用户和业务的实际价值,而不仅仅是满足用户的要求。很多用户需求可能只是“好奇心”或者“完美主义”,真正使用时作用不大。我们需要区分核心价值和边际价值。评估成本时,不要只看短期投入,还要考虑带来的长期维护成本。一个小功能可能需要持续Debug、完善、升级,总成本远超初期开发。沟通时,各方应摒弃主观偏见,不能因为立场不同就互不信任。研发应直面PM的质疑,而PM也应理解技术难点。管理层要站在全局角度平衡各方诉求。可以建立一套清晰的规范,说明不同类型需求的优先级原则、成本评估模型等,减少鸡肋需求的争议。并且可根据实际情况不断完善这套规范。在可行范围内,应该允许小规模试错,因为很多收益和成本在实际开发前难以准确预测。通过最小可行产品快速验证idea,再决定下一步优化方向。 软件开发过程中的抓大放小和极致细节两种思维模式并没有明显的对错之分至于不同的人选择不同的思维模式源自于不同角色对收益和成本的认知偏差。但我认为在软件开发的不同阶段中有着适合的不同思维模式所以还是需要有倾向性的。 比如在软件开发初期或者资源有限的情况下可以更倾向于抓大放小。但在软件稳定期更应倾向于极致细节。 当然如果遵循投入产出比最大的原则一切都是可以自然而然改变的。比如在软件发展的过程中有些功能初期不重要但后期可能会变的很重要。所以还需保持开放和灵活的心态根据不断变化的实际情况调整开发策略和优先级。
