企业级大厂项目开发的三大要素
• 流程：工作流程，15个环节
• 人员：用户（C端用户，B端客户）、产品/项目经理（PD/PM）、UI设计师、交互设计师、前端开发、后端开发、测试开发
• 文档：需求设计文档（PRD）、交互稿、UI 稿、技术方案、接口文档、冒烟测试用例、测试用例、发布日志、上线报告、复盘文档
流程
- 需求分析：
在这个阶段，项目经理、产品经理和相关利益相关者会收集和分析项目需求。这通常包括市场调研、用户访谈、竞品分析等，以确保对产品需求有清晰的了解。需求文档会被创建，它详细说明了产品应该做什么，以及期望达到的目标。 - PRD（产品需求文档）评审：
产品经理会编写一个产品需求文档（PRD），其中包含了产品的目标、功能、性能和界面需求。这个文档会在团队内进行评审，以确保所有团队成员对产品有统一的理解，并且同意需求的可行性和优先级。 - 交互/UI评审：
设计师会根据 PRD 设计交互稿和 UI 稿，然后提交给团队评审。评审的目的是确保设计符合用户体验最佳实践，并且与产品需求相匹配。同时，也是为了确认设计的可实施性。 - 技术方案评审：
技术团队将基于需求文档和设计稿制定技术实施方案。这个方案将详细说明如何构建系统，包括技术栈选择、系统架构、数据模型、安全性等。这个方案需要团队成员评审，确保技术选择的合理性和实施的可行性。 - 接口设计评审：
后端开发人员会设计系统的 API 接口，并编写接口文档。前后端开发人员需要对接口文档进行评审，确保接口设计满足前端需求，同时后端能够高效实现。 - 代码开发：
开发人员根据技术方案和接口设计开始编写代码。这个过程中可能会有持续的代码评审和单元测试，以确保代码质量。 - 前后端联调：
前端和后端开发人员会一起工作，确保前端能够正确调用后端服务，并且后端正确返回数据。 - 冒烟测试：
在代码初步完成后，QA（质量保证）团队会进行冒烟测试，以确保最基本的功能可以正常工作，没有明显的错误。 - 提测：
完成冒烟测试并修复发现的问题后，QA 团队会开始更详细的测试工作，包括功能测试、性能测试、安全测试等。 - 测试：
QA 团队会执行一系列测试用例，确保产品符合需求规格，并且没有缺陷。 - 预发验收：
在产品通过所有测试后，它会被部署到一个与生产环境相似的预发环境中。在这个环境里，产品会被进一步测试和验收，以确保上线后能够稳定运行。 - 发布上线/验证：
产品通过预发验收后，会计划一个上线时间。在上线后，团队会密切监控产品的表现，包括性能指标、错误率等，确保产品稳定运行。 - 复盘：
项目结束后，团队会进行复盘，总结项目中的成功和失败，学习经验教训，以便在未来的项目中做得更好。 - 观察用户数据：
产品上线后，团队会通过各种数据分析工具来观察用户的使用情况，包括用户行为、功能使用频率、用户反馈等。
什么项目才能叫企业级大厂项目？
- 规模大、复杂度高：企业级项目通常服务于大量用户，处理大量数据，涉及多个子系统和模块，业务流程复杂。
- 高可用性和可靠性：这类项目需要确保服务的连续性和稳定性，通常需要99.999%的高可用性。
- 安全性要求高：企业级项目涉及敏感数据，需要符合严格的安全标准和合规要求，如ISO 27001、GDPR等。
- 可扩展性和可维护性：随着业务的发展，企业级项目需要能够平滑地扩展以支持更多用户和更复杂的业务场景，同时代码和架构设计要便于维护和升级。
- 技术架构先进：使用当前业界认可的最佳实践和先进技术，如微服务架构、容器化部署、云原生技术等。
- 团队和流程专业：项目管理遵循成熟的软件开发生命周期管理方法，如敏捷开发、DevOps等，团队成员具有专业的技术背景和丰富的项目经验。
- 持续集成和持续部署（CI/CD）：自动化的测试和部署流程，确保快速迭代和高质量的代码发布。
- 用户体验优秀：注重用户界面设计和用户体验，提供直观、易用的操作界面。
- 文档和支持完善：提供详细的开发、部署和使用文档，以及专业的技术支持和服务。
- 多元化的技术栈：可能涉及多种编程语言、框架、数据库和中间件等技术栈的组合。
- 国际化和本地化：支持多语言，考虑不同地区的文化差异和法律法规要求。
- 监控和日志管理：实现系统的实时监控、告警和日志分析，以便快速定位和解决问题。
- 数据备份和灾难恢复：确保数据的安全性和在紧急情况下的恢复能力。
企业级大厂项目不仅仅是技术上的挑战，更是对项目管理、团队协作和业务理解能力的综合考验。这类项目的成功实施需要多方面的专业知识和协同工作。
相比之下，其他类型的项目可能有所不同：
- 课程项目：通常是在教育环境中为了学习某种技术或概念而进行的项目。这些项目规模较小，复杂度低，主要目的是教育和学习，而不是商业应用。
- 外包项目：由一家公司外包给另一家公司或个人完成的项目。这些项目可能是企业级的，也可能是较小的商业项目，质量和复杂度可能参差不齐，取决于外包公司的技术实力和管理能力。
- 创业项目：通常是由初创公司或个人发起的，目的在于验证商业模式或市场需求。这些项目可能在早期规模较小，但随着公司成长，有些创业项目可能发展成为企业级的项目。
总结来说，企业级大厂项目在规模、复杂度、安全性、稳定性、性能、维护性、遵循的标准和规范以及项目管理方面都有较高的要求。这些项目往往需要大量的资源投入，以及高水平的技术和管理团队来支持。
所以我们要时刻具备企业级思维：稳定、性能、复用、质量、体验。
PRD 的五个部分
产品需求文档（Product Requirements Document，简称 PRD）是定义产品功能、目标、特性和用户体验的关键文档。它是沟通团队成员、利益相关者和最终用户之间共享产品愿景的重要工具。一个标准的 PRD 通常包含以下五个部分：
1. 需求背景
在这部分，撰写者需要提供产品的背景信息，解释为什么该产品需要被开发。这通常包括市场分析、用户需求、业务目标或公司策略。需求背景应该清楚地阐述产品解决的问题，以及它将如何满足市场需求或改善用户体验。
- 市场分析：调研市场上现有的解决方案，分析竞争对手，确定产品的市场定位。
- 用户需求：通过用户调研或反馈收集用户的核心需求，明确产品要解决的痛点。
- 业务目标：描述产品预期达成的商业目标，如提高收入、市场份额或用户满意度。
2. 需求简介
这部分应简洁明了地描述产品的总体需求。这通常包括产品的基本功能、目标用户群体、预期的用户行为以及产品如何与现有的产品或服务互动。需求简介需要足够详细，以便任何阅读文档的人都能快速理解产品的核心功能和目的。
- 功能概述：列出产品的主要功能和特性。
- 目标用户：定义目标用户群体，包括他们的特征和使用场景。
- 用户行为：预期用户如何与产品互动，包括用户旅程的关键步骤。
3. 业务架构
业务架构部分描述产品如何融入整个业务流程中，包括与其他系统或服务的集成。这里可能会涉及到流程图、系统架构图或数据流图，以便清晰地展示产品的工作原理和它在业务中的位置。
- 流程图：展示用户通过产品完成任务的流程。
- 系统架构图：如果产品是一个软件或技术平台，展示它的技术架构和组件。
- 数据流图：解释数据如何在系统内部流动和被处理。
4. 产品原型
产品原型是产品设计的初步可视化，它可以是草图、线框图或更高保真度的交互式原型。原型应该展示产品的界面布局、用户交互和关键功能。这可以帮助团队成员和利益相关者更好地理解产品的外观和操作方式。
- 界面布局：界面元素的布局和设计。
- 用户交互：用户如何与产品的各个部分进行交互。
- 关键功能：展示产品如何实现其核心功能。
5. 非功能性需求
非功能性需求描述产品必须满足的技术标准和约束，这包括性能、安全性、合规性、可维护性和质量标准。这些需求对于确保产品的稳定性和可靠性至关重要。
- 性能：产品的响应时间、处理能力和并发用户数等性能指标。
- 安全性：保护用户数据和防止未授权访问的安全措施。
- 合规性：产品需要遵守的法律、规定和标准。
- 可维护性：产品代码和架构的可维护性，包括易于升级和修复。
- 质量标准：产品质量的衡量标准，如缺陷率、用户满意度等。
每个部分都应该详细、清晰，并且相互之间保持一致性。PRD 文档是一个活文档，它应该随着项目的进展和市场情况的变化而更新。
最后，注意要特别关注 投入产出比（ROI），产品效果（PV UV 等指标）
- PV 指的是页面浏览量或点击量，是衡量一个网站或页面流量的指标之一。每当一个页面被加载和刷新时，PV 就会增加一次。如果一个用户在短时间内多次访问同一页面，每次访问都会被计为一个 PV。
- UV 指的是独立访客数，用来统计在一定时间范围内访问网站的不同访客数目。一个 UV 可以浏览网站的多个页面，但无论他们访问多少次或多少页面，都只会被计算为一个 UV。通常 UV 是通过跟踪访客的 IP 地址、Cookies 或登录信息来识别的。
PV 更多地反映了网站的活跃程度，而 UV 则更能体现网站的覆盖面和用户基础的广度。两者结合起来，能够更全面地评估一个网站的受欢迎程度、用户的活跃度以及内容的吸引力。
除了 PV 和 UV，还有一些指标值得关注：
- 跳出率（Bounce Rate）：
跳出率是指访问者访问网站后只查看了一个页面就离开的比例。较高的跳出率可能表明网站的着陆页不够吸引人或者与用户期望不符。 - 平均会话时长（Average Session Duration）：
用户在网站上的平均停留时间。更长的会话时长通常意味着内容更能吸引用户。 - 用户行为流（Behavior Flow）：
用户在网站上的路径，包括他们从何处开始、访问了哪些页面以及在哪里退出。这有助于识别用户体验的痛点和流行路径。 - 转化率（Conversion Rate）：
访问者完成特定目标的比例，如填写表单、订阅新闻通讯或完成购买。这是衡量网站成功的关键指标。 - 退出率（Exit Rate）：
用户最后访问的页面后离开网站的比例。不同于跳出率，退出率关注的是用户在退出前访问了多个页面。 - 页面加载时间（Page Load Time）：
网页完全加载所需的平均时间。快速的加载时间有助于提升用户体验和搜索引擎排名。 - 新访客与回访客比例（New vs Returning Visitors）：
新访客与再次访问网站的老访客的比例。这有助于了解网站在吸引新用户和保持老用户方面的表现。 - 移动设备用户比例（Mobile Traffic）：
通过移动设备访问网站的用户占总访客的比例，这对于优化移动用户体验至关重要。 - 互动率（Engagement Rate）：
用户与网站内容互动的程度，如点击、分享、评论等。 - 事件跟踪（Event Tracking）：
用户在网站上的特定交互，如下载文件、观看视频或点击广告。 - 来源/媒介（Source/Medium）：
用户来源的渠道，如搜索引擎、社交媒体或直接访问。 - 客户获取成本（Customer Acquisition Cost, CAC）：
获得一个新客户所需的成本，包括广告费用、营销活动支出等。
排期
在前端开发中评估工时是一个复杂的过程，因为它需要考虑多个因素，包括项目的需求、复杂性、团队的经验以及可能遇到的风险等。以下是一些评估前端开发工时的方法和步骤：
- 需求理解与分析:
- 仔细阅读项目需求文档，理解项目的目标和预期成果。
- 与项目管理者、设计师和后端开发人员沟通，确保对需求有相同的理解。
- 确认需求的明确性和可实施性，对于不清晰的地方要求澄清。
- 任务拆分:
- 拆分模块，如前端可以将大组件拆分成小组件，考虑组件的静态效果 + 动态逻辑，注意拆分粒度的适中。
- 对每个任务进行详细描述，包括其目标、功能、依赖关系和完成标准。
- 历史数据参考:
- 查看过去类似项目的工时记录，了解类似任务通常需要多少时间。
- 使用这些数据作为参考点，但同时考虑到当前项目的特殊性。
- 估算每个任务的工时:
- 对每个拆分出的任务，基于其复杂性、团队成员的技能以及之前的经验来评估所需时间。
- 考虑到可能的学习曲线，特别是当涉及到新技术或工具时。
- 风险评估:
- 考虑需求熟悉时间、前后端联调、编写测试、需求变更、第三方服务的不稳定等风险因素
- 为这些风险分配额外的缓冲时间，一般我建议根据风险等级，最终估时为实际评估时间的 1.5 - 2.5 倍。
- 总结和调整:
- 将所有任务的估算时间汇总，得到总体工时估算。
- 根据团队的工作效率和历史表现进行调整。
- 专家咨询:
- 如果可能，让有经验的前端开发者对工时估算进行审查和建议。
- 持续更新:
- 开发过程中定期回顾和更新工时估算。
- 如果遇到预料之外的挑战，及时调整工时预算。
- 使用工具和技术:
- 使用项目管理工具，如 Jira、Trello 或 Asana，来帮助跟踪任务和时间。
- 考虑使用敏捷方法论，如 Scrum 或 Kanban，这些方法论鼓励短周期内的持续评估和调整。
每个项目都是独特的，因此在评估工时时需要灵活和适应性。重要的是要记住，估算是一个迭代过程，随着项目的进行，你可能需要重新评估和调整你的估算。
项目经理和产品经理的区别
项目经理和产品经理是两个专注于不同方面的角色，虽然它们在一些组织中可能会有重叠的职责，但它们的核心职能是不同的。
项目经理（Project Manager）的重点是项目的执行。项目经理负责规划、组织、管理资源，以确保项目按时、按预算和在既定的质量标准内完成。他们的主要职责包括定义项目目标、制定时间表、协调团队成员、监控项目进展、解决问题以及确保项目的顺利交付。
产品经理（Product Manager）则专注于产品的整个生命周期。产品经理需要了解市场需求、用户体验、竞争对手分析以及业务战略，并将这些知识转化为产品愿景和路线图。他们负责定义产品特性、优先级排序、持续改进产品并确保产品符合市场和用户的需求。
简而言之，项目经理关注“做项目的正确事”，即项目的管理和交付；而产品经理关注“做正确的产品”，即产品的规划、定义和市场成功。
发展路径：在IT行业中，一个比较舒适的发展路径是从研发到项目经理，再到产品经理。项目经理最好具备技术背景，而产品经理不一定需要懂技术。
