一家互联网公司是如何运作的？
当今，互联网公司在全球范围内发挥着日益重要的作用。它们不仅改变了我们的生活方式，还在商业领域产生了深远的影响。本文将探讨一家典型互联网公司的运作方式，深入了解其内部机制和关键流程。通过对互联网公司的运作进行剖析，我们可以更好地理解这些公司如何取得成功，并对未来发展趋势有所启示。
名词解释
| 项目角色 | 岗位职责（概述） |
|---|---|
| BDM 市场拓展经理 | 负责目标客户的拓展和挖掘、搞好客户关系 |
| BM 商务经理 | 负责项目的投标、实施及方案解决的沟通 |
| PM 产品经理 | 收集、分析用户需求、提需求、画原型 |
| UE 视觉设计师 | 根据产品经理原型画设计稿 |
| FE 前端开发 | 根据设计稿编写前端代码 |
| RD 后端开发 | 设计数据库、对接三方 API、开发接口 |
| CRD 移动端开发 | ios、Android 移动端开发 |
| QA 测试人员 | 根据产品需求，软件中的缺陷提 bug |
生命周期
一、商务拓展阶段
市场调研
- 目标客户的拓展和挖掘
- 各地市场的考察和调研工作
- 搞好客户关系
招投标
- 及时关注网路招标信息
- 投标标书撰写、系统演示讲解、讲述投标方案
商务谈判
- 与客户进行交流细化、收集、分析用户需求
- 制定可行性合作策略和执行方案
- 沟通合作意向，并积极促成合作
- 合作伙伴关系的建立，合同签订
二、产品开发阶段
需求评审
- 了解项目的需求和目标
- 积极参与需求讨论、敢于质疑需求是否合理（如：需求是否闭环？、开发难度如何？是否需要其它支持？等等）
- 不要急于给排期
技术方案设计
- 系统架构设计、模块划分、数据流设计等
- 确定系统的整体结构和关键模块
- 找准设计重点、技术上求简单，不过度设计
- 注意要产出文档（如：数据库设计、接口设计等），交付时用！
- 多和其他开发人员沟通
代码开发
- 符合开发规范（git 分支规范、注释的规范、RESTful API 设计规范、模块命名的规范等）
- 写出开发文档（如组件的使用、单点登录鉴权使用）代码注释
- 及时写单元测试
- Mock API、PostMan 模拟前端请求
- Code Review
接口评审
- RD 后端同学接口开发完成，生成接口文档（Swagger、Yapi ）
- FE 前端同学 、CRD 移动端同学 参与接口评审，通过之前 Mock 的数据，给后端同学反馈接口字段是否不足等
接口联调
- RD 后端同学 和 FE 前端同学、 CRD 移动端通信 接口联调
- UE 和 PM 尽早介入 （UE 确定视觉效果、UI 样式走查、PM 确定产品功能）
代码自测
- 查看需求和原型、根据需求描述，自己操作一遍是否符合预期
- 代码的单元测试
测试
- 提测发邮件，抄送项目组（如我们在项目组发消息）
- 测试问题要详细记录（比如：禅道、Teambition 等工具）
- 有问题及时沟通，QA 测试人员 和 开发人员信息不对称（QA 测试会根据需求跟 PM 确认写测试文档，会偷偷改需求~ ）
上线
- 测试环境没有问题后，就可以发线上环境了（此处可以设置预发环境，预发环境数据库和线上的一样，有时测试数据库和线上数据库不一致，会导致一些不可预知的错误）
- 上线之后及时通知 QA 回归测试
- 上线之后及时同步给 PM 和项目组
- 如有问题，及时回滚，先止损，再排查问题
常见问题
- 如何反馈排期？
- 给自己预留一点空间，考虑自己的并行工作，从前端开发的角度，可以让设计师、后端给排期，再排期，如果设计师、后端没有给出排期，自己先根据需求给工作量（多少工时能做完）
- 项目排期 = UE 设计时间 + 前后端开发时间 + 接口联调时间 + 自测时间 + 提测上线时间
- 项目排期前和相关开发人员做好充分沟通
- PM 加需求怎么办？
- 看情况、如果是改个文案加个字段的简单需求，一般顺手改掉就好了，如果是主流程改动，影响进度了，公司有规定情况，走需求变更流程即可（如：PM 提交需求变更单），没有规定的话发起项目组和 leader 的评审，重新评估排期
- 已经排完期，项目完不成怎么办？
- 加班！排期是自己给的，吃一堑长一智。
- QA 提的 bug 无法复现怎么办？
- 当面讨论，让他帮忙复现。
- 怎样才是好的开发节奏？
- 前紧后松，项目排完期了后，尽快的完成手头上的开发安排，留多一点时间给自己自测，Code Review，提高自己的代码质量
三、交付
交付一般需提供以下文档：
- 需求规格说明书：包括客户需求、功能规格、非功能性需求等详细描述，是开发团队了解客户需求和开发目标的重要参考。
- 设计文档：包括软件架构设计、模块设计、数据库设计等，帮助开发人员理解系统设计和实现细节。
- 用户手册：为最终用户提供软件的使用说明，包括安装步骤、操作指南、常见问题解答等，以便用户能够正确地使用软件。
- API 文档：如果软件包含接口，需要提供清晰的 API 文档，包括接口定义、参数说明、返回结果等，方便其他开发者集成和使用。
- 测试文档：包括测试计划、测试用例、测试报告等，记录了软件的测试过程和结果，验证软件是否符合需求和质量标准。
- 部署文档：描述软件的部署流程，包括环境要求、安装步骤、配置说明等，确保软件能够顺利部署和运行。
- 维护文档：包括系统架构、关键模块、重要功能点等说明，方便后续维护人员理解系统结构和代码逻辑。
四、市场营销和销售阶段
- 各种搜索引擎信息流、短视频投放广告、意向客户留言
- 拨打意向客户电话、促成成交
- 潜在客户挖掘和拓展（如：有一款电销系统，我要推销给客户，如何挖掘潜在客户？BOSS 直聘查看有哪些公司在招销售人员，天眼查找到公司的法人联系方式，向他推荐该系统。）
本文是基于 to G（to Government） 的软件开发模式进行探讨，对于互联网的产品自研的公司，一般没有 商务拓展阶段 , 需求从“群众中来 到群众中去”。
本文是个人工作中经验的总结，难免会有问题和理解偏差，如果有问题请进行评论，我也会尽力去改进，自己也在学习的路上，欢迎交流，非常感谢！