常见的10个问题
产品开发中常见的10个问题思维导图
需求相关
1. 需求不明确
在日常工作中，需求来源于用户、老板、客户、竞品分析、业务部门、产品经理等，这些人或部门会提出需求，因为他们不是产品经理，提出的需求可能是一句话、一个想法这些简单的需求点，这些需求模糊且不明确。
一般的处理方法？
- 建立需求模板，如果公司的人提需求，按照需求模板来填写需求的明细。
- 建立需求评审机制。
- 使用用户故事地图来梳理需求，帮助我们确定目标用户、需求的范围、产品价值和需求优先级。更深刻的理解用户需求。
2. 需求变更频繁
在软件产品开发过程中不断的调整需求。第一种是需求管理杂乱、经常变更需求。第二种可能是研发做需求时发现有的需求考虑不周到，有遗漏的情况。第三种情况可能是领导提的需求、加塞需求。
第一种情况最可能出现的时期是产品在 0 到 1 的 MVP 验证阶段，产品功能还没有经过用户验证，这个时期产品需求会经常变动，这种情况下需求经常变更是可以理解的。
如果 MVP 验证成功，那么还经常变更需求，就要进行干预了。需要建立需求变更流程。
第二种情况可能经常遇到，这种只能延长开发时间了。如果是有经验的产品经理，遗漏的情况可能会比较少。
第三种领导提的需求，这种也经常遇到。如果经过评估是合理需求，可以提高需求开发优先级。
一般的处理方法？
- 产品不是处于 0 到 1 的 MVP 阶段，那么就建立需求变更流程。
- 敏捷开发模式，比如 scrum，它有 Product Backlog（产品代办事项），它是一个有着优先级排序的需求池。具体可以看这篇文章-Product Backlog产品待办列表详细介绍 。
每次添加需求、变更需求都要评估优先级和工作量，才放入 Sprint Backlog 进行开发。- 建立变更评审流程、变更控制委员会。评估变更的各种成本。
3. 伪需求识别
伪需求一般指用户或利益相关者提出的，看似合理但实际上并不符合用户的真实需求，或无法带来实际价值的需求，这些需求往往是主观的、臆想的，有大量假设场景，缺乏用户真实用户行为分析。
伪需求产生的原因有：
- 用户表达不清晰：用户无法准确表达自己真实的需求，或用词不当，或产品经理理解有偏差。
- 场景不合理：用户提出的需求，在实际场景中并不成立，或使用频率极低。
- 市场调研不充分：对市场趋势和目标用户需求没有足够深入的调查分析。
- 竞品分析不全面：盲目的模仿竞品的功能。
- 公司战略问题：公司为了和竞争对手竞争，盲目追求一些不符合用户实际需求的功能。
等等。
一般的处理方法？
- 用户调研和访谈：直接与用户进行交流沟通，了解用户的痛点需求。
- 用户行为数据分析与验证：通过分析用户的行为数据，了解用户的正式需求和使用习惯。
- MVP（最小可行产品）测试：开发一个最小可行产品，快速投入市场，测试用户的真实需求和付费意愿。或原型验证，快速搭建原型让用户试用，观察用户实际行为和反馈。
- 用户反馈机制：建立有效的用户反馈机制，比如问卷、评论收集意见，及时了解用户的需求变化。
- A/B测试与灰度发布 ：小范围测试功能效果。
- 竞品分析：研究竞品的用户画像和功能迭代方向，避免重复开发低价值功能。
- 问题法：对于需求的真伪，问几个问题，1.用户、场景、需完成的任务或解决的问题，2.有足够多的用户有这个问题吗？3. 关于这个需求，用户的最终目的是什么？5. 5W
开发过程
4. 进度延迟
出现进度延迟的情况一般有哪些：
- 需求变更频繁
- 技术难题，开发过程中遇到的比较难以解决的技术问题
- 资源不足，开发的人力、物力等资源不足
- 沟通问题，团队内部或客户之间的沟通不畅，信息传递衰减或不及时、不充分，需求理解偏差
- 需求开发时间预估不足，在需求开发过程中，有确定的事情，也有不确定的事情，最困难的是难以预估不确定的事情
一般的处理方法？
- 需求变更频繁，参考上一节中给出了一些方法
- 资源不足的问题，需要合理的分配资源，确保关键需求和任务有足够的资源支持
- 技术难题，在小组内、部门级别或公司级别组建技术攻关小组，集中力量解决技术难题
- 沟通问题，建立高效沟通机制，比如敏捷开发 Scrum 中的每日站会。
领导要建立良好、安全的沟通氛围，让大家勇于沟通。
鼓励大家遇到技术困难、问题及时的与领导、同事沟通，群策群力的解决问题。- 可视化进度任务，比如燃尽图（Burn Down Chart）-关注工作量的完成、燃起图（Burn Up Chart）-关注完成工作量的增长、甘特图，还有Kanban开发、敏捷 Scrum 开发方法。
5. 技术债务
在开发软件时，为了加快软件功能的完成，加快开发速度，以满足业务快速发展的要求，开发人员在应该采取最佳方案（往往比较耗时）时候进行了妥协，改用了临时方案，为了在短期内快速完成软件开发，这为未来增加新功能带来了不稳定的因素。
通过牺牲未来的开发需求来满足当下的需求开发，其实是一种妥协，但是会产生技术债务。这是一颗不定时炸弹。短时间内不会有多少影响，但是经过长时间的积累，就可能显示出影响了。比如产品质量下降，生产事故频发，系统维护性下降，开发效率低下。
软件产品如果能存活 10 年左右，它的技术架构还能响应市场的变化，这也说明技术架构也是在不断的适应业务发展，技术架构也在演进，比如单体 -> 分层 -> SOA -> 微服务。但是很多产品随着时间逐渐推移，技术债增加，慢慢会变得不可维护，大多数都会进行重写，而且会用不同以前的开发语言进行重写。
在软件密集型的系统中，技术债务由设计和实现结构组成，这些短期内的权宜之计构建的技术环境，可能让未来的变动更加昂贵或不可能。技术债务是一种专有负债，主要影响内部系统质量，但不限于可维护性和可进化性。
来自《管理技术债务》，作者：Kruchten、Nord 及 Ozkaya
一般的处理方法？
- 制定技术债登记制度，短期技术债，长期技术债，制定相应的处理办法，分配专门迭代周期修复
- 告知利益相关方，短期解决方案的利弊，大家一起评估
- 比如在 Scrum 框架下，每个迭代周期预留 20% 的时间进行重构
6. 代码质量低下
代码质量低下在软件开发中是普遍存在的问题，它可能直接影响系统的可维护性、扩展性和稳定性。
导致代码质量低下的原因有很多，比如：
- 时间进度压力：为了赶工期会牺牲代码质量，"代码能跑起来就行"，为了赶进度可能会写复制很多重复代码，参数硬编码，忽略异常处理等等情况。
- 缺乏编码规范：团队没有制定合适的编码规范，以及代码规范自动化检查机制。
- 架构设计缺陷：没有进行架构设计，没有合理的模块划分，模块耦合度高，模块职责混乱等。
- 缺乏代码审查和自动化工具：主要依赖人工 Review，未使用代码检查工具，比如 SonarQube 等静态代码分析工具，导致低级错误频发。
- 技术债务积累：为了快速交付引入临时方案
- 需求变更频繁：上面章节有提到，频繁变更需求会导致代码为了兼容不同需求被迫"打补丁"，没有时间设计代码，代码逻辑复杂且冗余。
- 开发者经验不足：可能对语言特性、一些设计模式认识不足，代码设计不合理。
一般的处理方法？
- 强制执行编码规范：使用 ESLint、CheckStyle 等工具自动化检查代码风格。
- 代码审查与质量门禁：Pull Request 前强制 Review，用 SonarQube 自动检查代码质量，如代码重复率、覆盖率等。
- 重构与技术债管理：使用渐进式重构方法，结合 IDE 工具重构。对技术债务进行登记，分配专门迭代周期进行修复。
- 工具链支持：静态分析工具，如 SonarQube、Fortify 检测潜在漏洞。CICD集成，在流水线中自动化执行测试、代码检查等。
- 需求变更管理：制定变更流程，变更评审机制。
- 架构设计：可以使用领域驱动设计来划分界限上下文，从而合理的划分模块。
- 培训学习：定期组织大家学习，比如代码评审、经典的代码坏味道、前沿技术等
测试部署
7. 测试不充分
在需求代码编写完成后，测试代码覆盖率不足，比如单元测试的覆盖率不足 40% 甚至更低。
还有业务功能测试不足，集成测试不充分，应用的不同模块或服务之间能否很好的协同工作。
一般的处理方法？
- 单元测试：比如单元测试覆盖率要求达到 80%。相应工具有 JUnit，NUnit，PyTest等。
- 集成测试：进行软件的集成测试。测试工具有 Jenkins，Bamboo 等。
- CICD 流水线：搭建 CICD 的流水线，实现自动化测试流水线。相应工具有 Jenkins，GitLab，GitHub 等。
8. 开发测试部署环境不一致
开发、测试和部署这 3 者的环境不一致导致的问题。
一般的处理方法？
- 可以使用 docker 容器搭建环境，实施 Infrastructure as Code。将应用程序及其依赖打包成一个独立的容器，确保不同环境运行一致性。
- 使用版本控制系统，版本控制系统（如Git）可以跟踪代码的变化，确保团队成员使用相同版本的代码。
- 搭建持续集成/持续部署（CI/CD），自动化构建、测试和部署过程，确保代码在不同环境的一致性。
- 环境配置管理，使用配置管理工具（如Ansible、Chef、Puppet）可以自动化环境配置过程，确保不同环境的一致性。
- 文档化和标准化开发配置环境，确保团队成员遵循相同的环境设置。
团队协作
9. 跨部门沟通障碍
在软件开发过程中，跨部门沟通常遇到的一些问题，比如：
- 目标不一致：不同部门对项目、产品的目标不一致，期望结果存在分歧
- 沟通障碍：因为不同的部门，由于专业术语差异、沟通风格不同，导致信息传递不畅或存在误解
- 信息孤岛：各部门之间信息不共享，形成信息孤岛
- 权责利不清晰：对项目的权限、职责和利益划分不清晰
一般的处理方法？
- 明确共同目标：在项目启动阶段，组织跨部门会议，明确项目的目标、优先级和期望结果。
- 建立有效的沟通机制：制定沟通计划、沟通的频率、方式等；定期组织跨部门会议，促进信息的共享和交流；利用工具进行实时的沟通，比如钉钉、企业微信等工具。
- 可视化工作任务和项目进度：比如用 Scrum、Kanban 方法来可视化工作任务和进度。
- 明确责任与分工：制定详细项目计划，明确各个部门和个人的任务、职责和权限，确保每个任务有一个负责人。
- 打破信息孤岛：建立统一的信息共享平台，比如项目管理平台，文档管理系统（如Confluence）来存储和共享项目文档。
- 培养跨部门协作文化：组织团队建设活动，增强部门之间的了解和信任；鼓励跨部门合作，共同解决问题和应对挑战。
项目管理
10. 风险管理缺失
项目管理可以包含上面所有的管理任务，比如需求变更频繁、团队协作障碍等等。
一般的项目管理中风险有，比如：
- 技术风险：新技术不程序，技术选型错误。
- 需求风险：需求频繁变更、需求不明确。
- 资源风险：关键人员离职、硬件资源不足。
- 外部风险：政策变化、第三方接口延迟。
等等
一般的处理方法？
- 团队集思广益，列出项目可能存在的风险。
- 邀请领域专家评审项目计划和存在的风险。
- 建立风险登机制度，记录风险状态、责任人、应对措施。
- 风险仪表盘：可视化关键风险指标（比如缺陷率、任务进度偏差等）。
- 定期审查：每周/每月召开风险审查会议，更新风险状态，调整风险优先级。
参考
- 《重构：改善既有代码的设计》，作者: Martin Fowler
- 《代码整洁之道》 作者: Robert C. Martin