软件产品开发中常见的10个问题及处理方法

常见的10个问题

产品开发中常见的10个问题思维导图

需求相关

1. 需求不明确

在日常工作中,需求来源于用户、老板、客户、竞品分析、业务部门、产品经理等,这些人或部门会提出需求,因为他们不是产品经理,提出的需求可能是一句话、一个想法这些简单的需求点,这些需求模糊且不明确。

一般的处理方法?

  1. 建立需求模板,如果公司的人提需求,按照需求模板来填写需求的明细。
  2. 建立需求评审机制。
  3. 使用用户故事地图来梳理需求,帮助我们确定目标用户、需求的范围、产品价值和需求优先级。更深刻的理解用户需求。

2. 需求变更频繁

在软件产品开发过程中不断的调整需求。第一种是需求管理杂乱、经常变更需求。第二种可能是研发做需求时发现有的需求考虑不周到,有遗漏的情况。第三种情况可能是领导提的需求、加塞需求。

第一种情况最可能出现的时期是产品在 0 到 1 的 MVP 验证阶段,产品功能还没有经过用户验证,这个时期产品需求会经常变动,这种情况下需求经常变更是可以理解的。 如果 MVP 验证成功,那么还经常变更需求,就要进行干预了。需要建立需求变更流程。

第二种情况可能经常遇到,这种只能延长开发时间了。如果是有经验的产品经理,遗漏的情况可能会比较少。

第三种领导提的需求,这种也经常遇到。如果经过评估是合理需求,可以提高需求开发优先级。

一般的处理方法?

  1. 产品不是处于 0 到 1 的 MVP 阶段,那么就建立需求变更流程。
  2. 敏捷开发模式,比如 scrum,它有 Product Backlog(产品代办事项),它是一个有着优先级排序的需求池。具体可以看这篇文章-Product Backlog产品待办列表详细介绍 。 每次添加需求、变更需求都要评估优先级和工作量,才放入 Sprint Backlog 进行开发。
  3. 建立变更评审流程、变更控制委员会。评估变更的各种成本。

3. 伪需求识别

伪需求一般指用户或利益相关者提出的,看似合理但实际上并不符合用户的真实需求,或无法带来实际价值的需求,这些需求往往是主观的、臆想的,有大量假设场景,缺乏用户真实用户行为分析。

伪需求产生的原因有:

  1. 用户表达不清晰:用户无法准确表达自己真实的需求,或用词不当,或产品经理理解有偏差。
  2. 场景不合理:用户提出的需求,在实际场景中并不成立,或使用频率极低。
  3. 市场调研不充分:对市场趋势和目标用户需求没有足够深入的调查分析。
  4. 竞品分析不全面:盲目的模仿竞品的功能。
  5. 公司战略问题:公司为了和竞争对手竞争,盲目追求一些不符合用户实际需求的功能。 等等。

一般的处理方法?

  1. 用户调研和访谈:直接与用户进行交流沟通,了解用户的痛点需求。
  2. 用户行为数据分析与验证:通过分析用户的行为数据,了解用户的正式需求和使用习惯。
  3. MVP(最小可行产品)测试:开发一个最小可行产品,快速投入市场,测试用户的真实需求和付费意愿。或原型验证,快速搭建原型让用户试用,观察用户实际行为和反馈。
  4. 用户反馈机制:建立有效的用户反馈机制,比如问卷、评论收集意见,及时了解用户的需求变化。
  5. A/B测试与灰度发布 :小范围测试功能效果。
  6. 竞品分析:研究竞品的用户画像和功能迭代方向,避免重复开发低价值功能。
  7. 问题法:对于需求的真伪,问几个问题,1.用户、场景、需完成的任务或解决的问题,2.有足够多的用户有这个问题吗?3. 关于这个需求,用户的最终目的是什么?5. 5W

开发过程

4. 进度延迟

出现进度延迟的情况一般有哪些:

  • 需求变更频繁
  • 技术难题,开发过程中遇到的比较难以解决的技术问题
  • 资源不足,开发的人力、物力等资源不足
  • 沟通问题,团队内部或客户之间的沟通不畅,信息传递衰减或不及时、不充分,需求理解偏差
  • 需求开发时间预估不足,在需求开发过程中,有确定的事情,也有不确定的事情,最困难的是难以预估不确定的事情

一般的处理方法?

  1. 需求变更频繁,参考上一节中给出了一些方法
  2. 资源不足的问题,需要合理的分配资源,确保关键需求和任务有足够的资源支持
  3. 技术难题,在小组内、部门级别或公司级别组建技术攻关小组,集中力量解决技术难题
  4. 沟通问题,建立高效沟通机制,比如敏捷开发 Scrum 中的每日站会。 领导要建立良好、安全的沟通氛围,让大家勇于沟通。 鼓励大家遇到技术困难、问题及时的与领导、同事沟通,群策群力的解决问题。
  5. 可视化进度任务,比如燃尽图(Burn Down Chart)-关注工作量的完成、燃起图(Burn Up Chart)-关注完成工作量的增长、甘特图,还有Kanban开发、敏捷 Scrum 开发方法。

5. 技术债务

在开发软件时,为了加快软件功能的完成,加快开发速度,以满足业务快速发展的要求,开发人员在应该采取最佳方案(往往比较耗时)时候进行了妥协,改用了临时方案,为了在短期内快速完成软件开发,这为未来增加新功能带来了不稳定的因素。

通过牺牲未来的开发需求来满足当下的需求开发,其实是一种妥协,但是会产生技术债务。这是一颗不定时炸弹。短时间内不会有多少影响,但是经过长时间的积累,就可能显示出影响了。比如产品质量下降,生产事故频发,系统维护性下降,开发效率低下。 软件产品如果能存活 10 年左右,它的技术架构还能响应市场的变化,这也说明技术架构也是在不断的适应业务发展,技术架构也在演进,比如单体 -> 分层 -> SOA -> 微服务。但是很多产品随着时间逐渐推移,技术债增加,慢慢会变得不可维护,大多数都会进行重写,而且会用不同以前的开发语言进行重写。

在软件密集型的系统中,技术债务由设计和实现结构组成,这些短期内的权宜之计构建的技术环境,可能让未来的变动更加昂贵或不可能。技术债务是一种专有负债,主要影响内部系统质量,但不限于可维护性和可进化性。 来自《管理技术债务》,作者:Kruchten、Nord 及 Ozkaya

一般的处理方法?

  1. 制定技术债登记制度,短期技术债,长期技术债,制定相应的处理办法,分配专门迭代周期修复
  2. 告知利益相关方,短期解决方案的利弊,大家一起评估
  3. 比如在 Scrum 框架下,每个迭代周期预留 20% 的时间进行重构

6. 代码质量低下

代码质量低下在软件开发中是普遍存在的问题,它可能直接影响系统的可维护性、扩展性和稳定性。

导致代码质量低下的原因有很多,比如:

  1. 时间进度压力:为了赶工期会牺牲代码质量,"代码能跑起来就行",为了赶进度可能会写复制很多重复代码,参数硬编码,忽略异常处理等等情况。
  2. 缺乏编码规范:团队没有制定合适的编码规范,以及代码规范自动化检查机制。
  3. 架构设计缺陷:没有进行架构设计,没有合理的模块划分,模块耦合度高,模块职责混乱等。
  4. 缺乏代码审查和自动化工具:主要依赖人工 Review,未使用代码检查工具,比如 SonarQube 等静态代码分析工具,导致低级错误频发。
  5. 技术债务积累:为了快速交付引入临时方案
  6. 需求变更频繁:上面章节有提到,频繁变更需求会导致代码为了兼容不同需求被迫"打补丁",没有时间设计代码,代码逻辑复杂且冗余。
  7. 开发者经验不足:可能对语言特性、一些设计模式认识不足,代码设计不合理。

一般的处理方法?

  1. 强制执行编码规范:使用 ESLint、CheckStyle 等工具自动化检查代码风格。
  2. 代码审查与质量门禁:Pull Request 前强制 Review,用 SonarQube 自动检查代码质量,如代码重复率、覆盖率等。
  3. 重构与技术债管理:使用渐进式重构方法,结合 IDE 工具重构。对技术债务进行登记,分配专门迭代周期进行修复。
  4. 工具链支持:静态分析工具,如 SonarQube、Fortify 检测潜在漏洞。CICD集成,在流水线中自动化执行测试、代码检查等。
  5. 需求变更管理:制定变更流程,变更评审机制。
  6. 架构设计:可以使用领域驱动设计来划分界限上下文,从而合理的划分模块。
  7. 培训学习:定期组织大家学习,比如代码评审、经典的代码坏味道、前沿技术等

测试部署

7. 测试不充分

在需求代码编写完成后,测试代码覆盖率不足,比如单元测试的覆盖率不足 40% 甚至更低。 还有业务功能测试不足,集成测试不充分,应用的不同模块或服务之间能否很好的协同工作。

一般的处理方法?

  1. 单元测试:比如单元测试覆盖率要求达到 80%。相应工具有 JUnit,NUnit,PyTest等。
  2. 集成测试:进行软件的集成测试。测试工具有 Jenkins,Bamboo 等。
  3. CICD 流水线:搭建 CICD 的流水线,实现自动化测试流水线。相应工具有 Jenkins,GitLab,GitHub 等。

8. 开发测试部署环境不一致

开发、测试和部署这 3 者的环境不一致导致的问题。

一般的处理方法?

  1. 可以使用 docker 容器搭建环境,实施 Infrastructure as Code。将应用程序及其依赖打包成一个独立的容器,确保不同环境运行一致性。
  2. 使用版本控制系统,版本控制系统(如Git)可以跟踪代码的变化,确保团队成员使用相同版本的代码。
  3. 搭建持续集成/持续部署(CI/CD),自动化构建、测试和部署过程,确保代码在不同环境的一致性。
  4. 环境配置管理,使用配置管理工具(如Ansible、Chef、Puppet)可以自动化环境配置过程,确保不同环境的一致性。
  5. 文档化和标准化开发配置环境,确保团队成员遵循相同的环境设置。

团队协作

9. 跨部门沟通障碍

在软件开发过程中,跨部门沟通常遇到的一些问题,比如:

  1. 目标不一致:不同部门对项目、产品的目标不一致,期望结果存在分歧
  2. 沟通障碍:因为不同的部门,由于专业术语差异、沟通风格不同,导致信息传递不畅或存在误解
  3. 信息孤岛:各部门之间信息不共享,形成信息孤岛
  4. 权责利不清晰:对项目的权限、职责和利益划分不清晰

一般的处理方法?

  1. 明确共同目标:在项目启动阶段,组织跨部门会议,明确项目的目标、优先级和期望结果。
  2. 建立有效的沟通机制:制定沟通计划、沟通的频率、方式等;定期组织跨部门会议,促进信息的共享和交流;利用工具进行实时的沟通,比如钉钉、企业微信等工具。
  3. 可视化工作任务和项目进度:比如用 Scrum、Kanban 方法来可视化工作任务和进度。
  4. 明确责任与分工:制定详细项目计划,明确各个部门和个人的任务、职责和权限,确保每个任务有一个负责人。
  5. 打破信息孤岛:建立统一的信息共享平台,比如项目管理平台,文档管理系统(如Confluence)来存储和共享项目文档。
  6. 培养跨部门协作文化:组织团队建设活动,增强部门之间的了解和信任;鼓励跨部门合作,共同解决问题和应对挑战。

项目管理

10. 风险管理缺失

项目管理可以包含上面所有的管理任务,比如需求变更频繁、团队协作障碍等等。

一般的项目管理中风险有,比如:

  1. 技术风险:新技术不程序,技术选型错误。
  2. 需求风险:需求频繁变更、需求不明确。
  3. 资源风险‌:关键人员离职、硬件资源不足。
  4. 外部风险‌:政策变化、第三方接口延迟。

等等

一般的处理方法?

  1. 团队集思广益,列出项目可能存在的风险。
  2. 邀请领域专家评审项目计划和存在的风险。
  3. 建立风险登机制度,记录风险状态、责任人、应对措施。
  4. 风险仪表盘:可视化关键风险指标(比如缺陷率、任务进度偏差等)。
  5. 定期审查‌:每周/每月召开风险审查会议,更新风险状态,调整风险优先级。

大家在日常开发工作中会遇到哪些问题呢?

希望大家踊跃发言,一起讨论讨论


我的公号:九卷技术录-软件产品开发中常见的10个问题及处理方法

参考

相关推荐
NocoBase2 天前
NocoBase 如何成为 ED 的技术底座,支撑内部系统到商业化产品?
开源·敏捷开发·资讯
用户6120414922136 天前
C语言做的迷宫生成与求解程序
c语言·敏捷开发·计算机图形学
用户61204149221312 天前
C语言做的文本词频数量统计功能
c语言·后端·敏捷开发
泉城老铁13 天前
idea 优化卡顿
前端·后端·敏捷开发
南方者15 天前
基于Amazon Bedrock Agent 的两个服务示例的完整流程与详细内容,包含技术架构、实现细节、交互逻辑及扩展能力
人工智能·ai编程·敏捷开发
用户61204149221315 天前
C语言做的停车场管理系统
c语言·后端·敏捷开发
南方者18 天前
文心文心,其利锻心!这个古风射覆,它帅到我了!文心快码 3.5S
前端·敏捷开发·文心快码
艾小码22 天前
还在拍脑袋估工时?3个技巧让你告别加班和延期!
前端·敏捷开发
李姆斯23 天前
复盘上瘾症:到底什么时候该“复盘”,什么时候不需要“复盘”
前端·后端·团队管理
做就对了666624 天前
驱动员工的核心:少谈“大道理”,多解“人心”
职场和发展·职场·管理·团队管理·销售