前言

给非互联网行业从业者科普一下，互联网公司一个项目团队的标准成员组成和职责分工：项目经理、架构师、产品经理、核心开发人员（TL）、开发、测试、运营（或业务方）。

项目经理：一般是经由PMO发起项目后，由一个专人负责该项目的落地和整个后续推进工作等。项目经理直接对整个项目负责，并直接向CEO或PMO（项目管理办公司）汇报工作。

架构师：负责整个项目的技术架构，技术实现，技术攻坚难点和统筹整个项目；并用技术实现项目业务内的所有需求。

产品经理：负责整个项目的业务需求梳理，需求分析，输出产品原型PRD（也是项目的雏形）。

核心开发（程序员）：核心开发负责整个项目的核心模块和业务开发，或者负责项目的核心基础组件功能开发。除架构师外的一些技术难点攻坚，带领其他开发组员协同工作等。

测试：负责整个项目的测试工作，测试用例编写，检验开发人员设计出来的系统或产品是否符合产品的业务预期，对产品的质量把关。

运营（业务）：负责产品上线后的日常运营和维护工作，包括用户增长、广告投放、用户资料维护等。这里公司分甲方和乙方不同，运营和业务区分也不同。

背景

一个项目的发起，小到一个需求的迭代，大到从0到1或从无到有搭建的项目。无不经由业务需求挖掘和分析，评审；涉及到项目的三个要素：时间、范围、成本，学过项目管理知识（或了解项目管理）的同学应该很清楚。

2.1 项目的流程和环节

就像工厂里面流水线作业一样，只待在某个岗位上，是没法从全局观看待整个产品的生产流程的。当你跳出固有的思维，站在整个项目的流程和环节上来观看，就如雄鹰俯视脚下猎物一般。你会把所有流程环节，看得仔仔细细清清楚楚的。互联网的项目也是一样，项目立项——>干系人——>确定（时间、范围、成本）——>落地——>产品涉及、开发、测试——>上线 后期就是运营。

2.2 项目里程碑

这里一般是指当项目到达落地阶段，项目在流程环节上所处的位置，即：里程碑。这个概念也是项目管理里的术语。大的里程碑如产品立项完成，产品prd和需求文档输出完成，项目开发完成，产品测试完成，上线。小的里程碑：产品某个模块开发完成、某个系统功能开发完成、某个模块测试完成（白盒测试、黑盒测试、压力测试等）。

谁最了解业务

有人说产品最了解业务，有人说业务方最了解业务，也有人说测试最了解业务...还有人说程序员最了解业务。那到底谁最了解业务呢？这里其实没有标准答案，不能简单按照职责划分，谁就最了解业务。产品、业务、开发、测试，都需要了解业务。不懂业务，工作没法展开：

产品不懂业务：画不出原型prd，没法给程序员提供需求文档，无法跟业务方交流，无法做出用户想要的产品。

开发不懂业务：仅仅按照产品给出的原型prd和需求文档，当然能够开发和设计出程序和产品来，一旦某些细节点在prd和需求文档上没有体现同时又需要设计的点，这时就必须得懂业务并且跟产品方沟通确定方案。

测试不懂业务：只能按照开发设计出的程序测试，被牵着鼻子走，哪里开发好了测试哪里。完全没有在产品和用户的角度去测试系统的质量是否符合预期？

程序员要不要懂业务

最后，程序员到底要不要懂业务？之所以要写这么一个话题，是因为这是横亘在程序员和产品之间已久的一块障碍石，你说如果程序员懂业务吧，那我还需要产品干嘛，你说如果程序员不懂业务吧，开发设计出来的产品完全不符合预期。每次需求都是修修改改，到底是产品业务要符合系统技术底层逻辑来，还是系统技术逻辑得符合产品业务逻辑来？

4.1 没完没了的需求评审

需求评审，是对产品输出prd和需求文档的一个评审会议，也是整个项目产品整体实现的要求和基本原型方案的讨论与制定。作为产品方，会站在用户角度尽可能多和全的实现用户的需求。作为开发人员，会站在系统技术层面考虑，整个产品实现花费排期多长？哪些点是很难或没法实现的？能否以最少改动实现这个需求？这样就会导致，需求文档出了一版，程序员推翻后再来一版。一个项目需求评审会议不断。

4.2 没完没了的改改改

程序员最怕的不是需求，最怕的是一个需求改改改很多次。所以，这里又回到这个话题：程序员要不要懂业务？如果单纯按照产品给出的文档和prd，实现产品需求没有问题。顶多碰到不懂的业务问题再去问，如果一直按照这个思路的话题，那就避免不了需求一直改，你的程序也要一直改？所以，程序员最好懂业务，而且要深入的了解。这样，在每次需求下来时，可以非常有底气的跟产品讨论（Si Bi），需求如何实现，到底要不要实现等，甚至可以推翻产品的方案，按照你自己的涉及思路来。