软件开发中，常见一种流程，评审阶段需处理众多需求。看似井然有序，实则暗藏诸多问题。这种模式与产品最终价值、部门间协作紧密相连，还涉及技术手段和流程细节。其中争议和探讨点颇多。
评审阶段的需求处理
不少互联网公司在评审阶段会遇到众多需求。比如，有的公司一次评审会就得处理二十到三十个需求。大家纷纷发表意见。经过与开发团队的沟通，那些优先级较低的需求被淘汰，仅保留部分优先开发。开发团队会依序推进开发。虽然这种方法看似合理，却可能遗漏一些有潜力的需求。在实际工作中，有些小需求可能是实现大需求的关键，却因优先级评估而被忽视。
需求的优先排序常常受到主观因素的干扰。各部门人员对需求重要性的看法各异。比如，市场部门可能认为某个功能是吸引顾客的关键，而研发部门则可能觉得该功能开发难度高，回报却不多。这种差异导致了需求选择的冲突。
开发与测试阶段的状况
项目开发完毕便进入检验环节。检验期间，开发人员多数时间处于闲置状态，偶尔会接到一些辅助任务。这种现象反映出开发与检验之间存在较大差距。某些公司为了缩短开发周期，几乎不给开发人员留出自我检验的时间，就直接将任务转交给检验部门。从时间角度分析，开发人员急于处理后续任务，导致检验人员接收到的产品可能存在不少未被发现的缺陷。
测试部门此刻颇为烦恼。他们频繁遇到开发阶段的小问题。比如，某测试公司发现一个功能在三天测试期间，由于初始开发不够精细，暴露出二十个问题。这些问题使得项目进度受阻，还影响了后续的上线安排。
产品需求的价值考量
产品持续推动需求增长，却引发了不少问题。有些需求虽价值不高，却需投入开发。例如，某公司半年内新增一百多项功能，但用户实际使用率却相当低。这主要是因为产品团队为了追求新亮点而盲目添加功能。此外，每个需求的提出与实现，都需要消耗大量人力和物力资源。
尽管开发人员已经竭尽全力，可面对这些价值较低的需求，他们还是感到很无奈。有开发人员说，他们90%的精力都投入到只占30%实际价值的任务中，从人力成本的角度来看，这无疑是一种巨大的浪费。
互联网公司的核心竞争力
现在很多互联网企业的成长并非依赖于技术或产品本身。不少新成立的小公司，其技术实力并不逊色于大企业，却因未能迅速更新迭代、快速纠正错误而遭遇失败。比如，一家有创新思维的电商企业，原本有个出色的产品想法，却固守着传统做法，力求完美后再上线，结果被那些快速更新的对手夺走了市场份额。
采用这种流水线式的开发模式，每个人只是众多环节中的一员。这导致员工的自主性无法得到体现，他们更像是按照程序机械地执行任务。从长远来看，这对公司的创新和进步是不利的。
开发中的技术细节
技术流程在开发阶段颇为繁杂。从需求提出到产品上线，再到数据收集的整个过程，包含了众多平台和技术手段。比如，大数据平台、数据提取平台、端上报框架等，都与此相关。这些环节都需要投入相当的成本进行维护。
根据开发流程的不同，文档的种类也会有所区别。比如，周会文档主要用于记载会议中的关键决策。此外，技术方案文档能在前期识别潜在风险，这在快速迭代开发过程中显得尤为关键。
模块：A-api
模块：A
模块：B-api
模块：B
开发中的流程问题
组件管理和代码合并在开发流程中同样颇具挑战。组件负责人需持续跟踪组件更新，及时获取最新版本。合并代码时，常会出现遗漏，就像之前提到的a同学和b同学遇到的情况。此外，模块间的依赖关系缺乏有效管理，一些公司为了应用某个模块的修改，不得不重新进行打包。
传统开发与新型开发存在测试环境的不同。传统测试需经历多阶段环境检验，更为严格；而模拟开发则难以实现这样的效果。
你认为如何对这种开发方式进行优化，以便增强效率并增加产品的最终价值？期待你的点赞、留言以及转发这篇文章。
