本人工作多年，干倒不少公司，待过十几个人的团队，也进过上百人的团队，也算是项目开发经验丰富。今天我就来说说互联网公司项目开发的常见流程，主要来自于本人经验总结，结合了我这么多年来不同公司的实践所得。对于平时个人开发或者参与多人项目开发，大家可以参考一下，不一定适合所有公司，采取其中部分流程也是可行。
个人觉得从整体来说，项目开发流程大体分为3个大的部分，第一个部分就是需求，这个需求来源可能是BOSS、可能是用户反馈、可能是产品人员拍脑袋。第二部分是编程开发，程序员干活的地方。第三部分是测试验收，主要是测试人员干活的地方。
1.需求
这里说的需求往大了说可能是一个新项目，比如做一个商城APP，往小了说也可能一个项目里面的一个新模块新功能，我觉得都可以算需求。
大部分公司都有产品经理这个角色，虽然名字带着个经理两个字，但是实际上也是普通员工，这个角色说简单点就是画个原型图，对着友商的产品抄一抄，可能偶尔对开发程序员来句: 为什么xxx家都能实现你不能实现？
由于经常给程序员提各种需求、提bug，少不了争论和撕逼。但是这个角色往高了说，像微信的产品经理李小龙这样的可不是画原型了，他们则是对自己得产品有着深刻理解，是一个产品的灵魂设计者。
言归正传，玩归玩，闹归闹，产品这个职位不一定得有，但是需求一定要明确：你得告诉开发人员要做什么东西，即使没有原型图，你拿着友商的竞品展示一下对着抄也行啊。
需求应该有多明确？我见过写的最好的需求文档，是精确到每一个输入输出数据、包括长度大小，有一些高保真的原型图甚至都把交互设计出来了，还能点，所以越细越好，不然在实际开发中还得写一步问一步，只要产品不嫌烦，我没意见。
一般来说，一个需求在产品内部之间已经做过评审等工作，需求给到开发这边已经相对比较完善了，但是依然需要对齐。
所以这一部分在真实的项目开发中，一般有下面几件事要去做：
1.参加产品会议。参会人员包括前后端开发、测试等支撑人员，会上由产品人员对需求做一个简单明了的介绍，并配备项目流程图、原型图等资料，明确项目背景、需要做的东西、以及项目边界。
2.介绍完之后，可以问一下参会人员有没有什么疑问，不明白的地方，由产品人员解答相关问题
3.作为开发，开完会心里面应该有个概念了，有什么问题，该提就提，早点和产品说，现在改还来得及，产品写的不一定对，错的地方你可以纠正。对于有些不好实现的功能也可以和产品商量一下可以不可以换种方式或者放到下一期需求，等等。
说白了，这一步就是把相关人员拉到一起对一下需求，答疑解惑，这一步一定得有。这一步不仅仅是把需求给到开发，更是对需求的一个理解贯彻，哪些能做哪些不能做都需要开会讨论明确的，不是说一个文档扔给开发，产品就不管了。
接下来，一般产品在和开发等人员对完需求之后，会做一些修改，该明确的明确，双方都没有问题的时候，正式提需求，邮件抄送相关人员，提个禅道或者类似的项目流程管理的东西。
关于项目排期这块，大部分时候是由开发来定，如果需求不紧急的话。但是有些公司比较追求效率，很多时候是由产品定，或者老板直接拍板定个日期。个人觉得只要不是太离谱的话都没问题，如果时间实在不够，完成不了，一定要联合开发人员一起反馈，调整排期，千万不要等到最后几天才说时间不够，完成不了，这样显得太业余。
关于需求这块，我觉得最重要的是要明确需求，我见过很多产品自己都对想做的东西想的不太明白，考虑的不细致，做到一半发现设计有bug或者遗漏的地方。不求你想的十全十分，但是至少逻辑上要自恰，流程要走通。
2.开发
拿到需求之后，接下来就是编程开发，一般来说，一个需求会分配给好几个开发一起去做，这时候就得选一个人站出来负责整体把控，把大家拉一个群，方便交流。然后分解需求，分工，然后写各自的功能就行了，有问题群里及时沟通。对于敏捷开发等一些开发模式，公司如果有精力也有相关人员去管理，也可以去实践一下（对人要求太高）。
本人之前主要是从事Web开发为主，说简单点就是写API接口，自然少不了数据表设计、前后端接口联调等工作，所以有时候还包括以下工作要去做：
1.数据表设计
这点很重要，一个需求拿到手，需要那些数据文档里面应该都体现了，需要几张表应该都能估算出来，这时候应该让一个人，或者大家一起，把这次需求需要用到的数据表设计一下。然后找时间拉个会，一起评审一下字段结构设计是否合理，该改的就改。
千万不要每个人自己搞自己的，应该整体考虑设计新增的每一张表，不然时间一长，项目里面的各种表肯定很混乱
2.接口设计
在前后端分离的时代，在涉及前端页面的项目里面，自然少不了接口文档。在我的职业生涯里面，遇到过2种方式，一种是先写接口，再完善文档，然后告诉前端哪个地方调哪个接口，这种方式就需要前端等后端先开发接口才能写页面。
还有一种方式，就是先写接口文档，再写接口，这意味着开发需要先发挥想象力，把需要的接口字段定好，和前端对齐之后，前端就可以使用mock工具模拟接口数据进行开发，完全不依赖后端，等到后端接口开发完毕之后再进行联调。
对于第二种方式，有些人可能觉得我接口都没写，我咋知道有那些字段，实际上，如果需求很明确，数据表也设计完成，这不是什么问题。
对于简单需求，接口数量少，采用第一种方式也没啥问题，如果大的需求，我建议还是第二种比较好，更加科学合理，前后端可以同步开发，而且在沟通上也更明确，不用扯皮。
完成上面2个工作之后，对于程序员来说，剩下的就是按照产品需求文档，实现具体的业务逻辑了，有条不紊。
1 | func main() { |
3.测试
测试可轻可重，对于有些公司来说，在项目开发中比重与编码相当，但也有公司觉得测试只是附属工作，不必浪费太多时间，开发人员写好单元测试就可以了。
不过做过实际项目开发的人都应该知道对于那些复杂的需求，指望完全依靠单元测试来保障项目质量简直是做梦…
严格来说，测试人员在第一个阶段就需要介入了，要跟着开发一起参会，需要去理解产品需求，然后编写对应的测试用例，测试用例需要尽可能的覆盖所有情况。我之前有家公司还会要求评审测试用例，一个简单的需求都可能有几十个用例。
对于API接口，测试还需要对每个接口单独做测试，使用一些测试工具进行测试，对于部分接口可能还会做一些性能测试。
前后端联调完之后，还需要测试整体功能是否符合预期，必要时使用抓包工具定位问题，给开发提bug，等等！
总之，测试是一个非常系统性和专业性的工作，并不是一个简单的活，这里只是简单说几句，一个合格负责任的测试并不轻松，对产品需求的理解也需要到位，还需要和开发一起加班，开发改完bug之后，测试需要验证，做回归测试，编写测试报告等等。
但是我也见过有些公司的测试只做最后的黑盒测试，也就是像普通用户一样点一点，用一用，跑一下正常的流程，尽可能的模拟正常用户去使用，发现存在的问题。
甚至对于某些不太重要的项目，比如管理后台，开发自测就可以了。。。
在整个项目开发过程中，产品这个项目应该是贯穿整个项目的，不是说提一个需求，要一个排期，然后撒手不管坐等deadline就行了。
一个合格的产品应该时刻关心项目开发进度，必要时给予相关人员帮忙，协调各部门之间的工作，在最后阶段也可以参与到黑盒测试中，做一个验收工作。在开发过程中如果需要调整需求，必须及时通知相关人员。
最后，简单总结下整体流程：
1 | 1、需求对齐，拉上前后端开发、测试等人员 |
希望对一些新人有用！