每天都在接业务需求，涉及部门多的，时间较长的要立项，以项目管理的方式去执行。

每个人都会参与其中，或作为项目组成员，或作为项目组长、或作为项目经理，职责不同，工作不同，但是目标应该都是相同的，就是项目最后成功上线。

互联网电商的项目和传统企业的项目有何不同，应该如何去更好的管理，一直是我们急需解决的。

电商行业的特点就是快！

市场变化快、业务方向变化快、项目版本迭代快、组织结构调整快、竞争对手跑的快、技术更新快……

在这样的环境与氛围中，如何更好的完成项目需求，对于我们都是挑战。

几天前，找几位前同事简单了解了下不同公司在项目上是如何协作的发现，其实对于大多数公司都在传统管理项目方式上进行改变，根据公司的特点也在不断的寻求变化。

1.尝试敏捷项目管理，在产品研发团队推行，定期进行跟进成果。

2.以类似事件管理的工单方式跟进项目需求，定期跟进进展，如果有延时或风险会需要其上级领导汇报，层层升级与绩效关系很大。

3.从0到1的项目一般在要求1~3月内完成（需求、技术、测试、上线、维护），然后每1~2周进行功能迭代。

4.重要项目进行立项，严格按照项目管理章程进行，设置不同阶段的里程碑，定期举行项目例会进行汇报，对进度、风险、成本进行评估（典型的传统项目管理）；在各小项目里各团队会采取不同的管理方式。

……

无论现在按传统方式管理或敏捷思想、还是以OKR为导向的目标管理，对于产品研发团队影响和帮助有多少？

不敢做过多的评价，因为大的复杂的项目没有参与太多，个人虽然比较倾向“项目经理负责制”的方式，但根据实践因各种原因，结果却不理想。

电商公司是否需要设立PMO（项目管理委员会），是以项目经理（PM）还是以产品经理（PM）为主呢？

Project Manager：在大型项目和传统的系统集成性型公司都是非常重要的且不可或缺的。

Product Manage：是随着互联网行业而兴起的，有从由项目经理转型的，有从业务、研发等不同行业人员转型的。

其实无论是PM还是PM，都只是一个角色而已，只要能快速适应公司的发展，啥方式不重要，结果才是最重要的。

项目和产品的定义

项目是为创造独特的产品、服务或成果而进行的临时性工作，它有开始有结束，是有生命周期的（PMBOK）

产品是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合，互联网电商中可以是一款APP、一个数据分析的软件、仓储软件，也可以是咨询服务等。

个人理解，项目是为产品的实现而实施的一套管理办法，产品/研发经理都可以成为项目经理，公司可以根据实际情况不设置项目经理岗位，但应该建立虚拟的项目组织，着力培养一些有潜力的产品、研发去担当项目经理，运用项目管理的方式去推进每一个需求、每一个产品的开发上线。

当产品上线后，经过短暂的维护期，要交回给负责系统产品的研发与产品经理进行后期的规划与迭代，以延长产品的生命期。

一般的公司都是以业务结构为基础进行组织划分，同时产品技术部也会根据其业务分成多个小组，如购物流程、仓储物流、线下门店、OMS、POP平台、供应链、财务等，而且都会有专门的产品和研发团队负责。这种划分在项目管理中属于职能型团队，学习过项目管理或读过相关书籍的同学应该都知道，矩阵型的团队是比较好的，目前这种在外包公司、专用软件开发公司比较常见。

互联网电商仍然是业务驱动技术的，所以以职能团队为主，矩阵项目为辅的方式；可以想像一下自己所在的公司是什么样的？

其实工作这么多年，参与过很多项目，个人觉得项目需求管理的形式有千千万，应该以最终结果为评价标准，其它为辅的方式进行。

人、流程、环境

下面主要说下我对项目需求管理的简单理解，主要是三部分人和流程，其次是环境。

人：没有人做啥，所以要有人，而且要有优秀的人。

1.对于产品技术而言，产品总监与技术总监就是项目需求负责人，他（她）们需要对产品、项目、系统负责，否则就惨了。他们站在高一层级来统筹安排与业务部门协调，是影响公司运营的和战略的关键人员，他（她）们就可以做为虚拟的PMO组织存在，可以同召集几个业务或技术专家，但人不易过多，以5~6个人为佳。

2.项目经理：可以以虚拟项目形式存在，即需要时由PMO根据项目大小、涉及的部门多少、业务的复杂度来指定。

注意，这里仅是指产品、技术团队等独立的部门，在整个项目中属于小项目经理，不是负责其它业务部门的所有进度、风险、范围等。

作为项目经理他可以同时承担产品的设计、也可是负责具体的研发工作，但主要的责任是协调产品、技术各团队，把控进度、及时发现项目风险，对项目的成功与否负责。

同时担任此职位的人，在KPI考核中要有相应的奖励与惩罚，这样才能促进人的积极性，也能促进个人不断的学习进步。

3.项目团队成员：按目前相关公司的组织来看可以分为几部分

A.产品经理，在现在的互联网电商中的地位不言而预，是需求项目成功的关键人员，是技术与业务沟通的桥梁。

需要用产品思维去思考、去规划系统；以用户的心态去理解业务；绝不是为了完成工作而完成。在人人都是产品经理网站上看到一篇文章，说产品经理有四个阶段：功能设计阶段、产品设计、业务设计及模式设计；感兴趣的可以去读一下《产品经理成长的4个阶段》。

B.主要系统模块的开发人员：要有一定的技术能力，同时对于涉及的相关业务较熟悉；可以带领人员进行相关设计、技术选项等，可以合理的安排任务。

研发同学强的是技术，都希望成为技术大牛，一般都不愿意担任太多的琐事，在相关会议上扯来扯去远不如写段代码带来的快感与满足。

未来应该还是业务驱动技术发展的，业务架构师是牛逼的人才，大家应该向这个方向发展，除非你技术真牛，往技术架构师上发展；选择好就勇往直前吧，兄弟！

C.测试负责人：是质量的保障师，是上线前的最后一道保险，这里需要她（他）们对业务特熟，对需求理解特别深刻；对原则问题特别认真，而且最重要的还是要有耐心。

D.研发、测试成员：涉及改动的系统或模块的参与人，也是工作量最多的同事，是项目进度的直接干系人，是导致需求变更的关键节……，太重要了。

E.运维、数据、安全、架构：这部分技术同事一般都会涉及每个项目，是上线后系统稳定运行的保障，是出现问题最先介入的人。

运维是最常打交道的人，服务器的申请、部署、CDN、负载、网络等等

DBA是指导项目实施中建库、建表、索引等工作，是数据直接的维护者，他（她）与运维也会频繁的沟通。

架构、安全对具体项目参与不多，主要是涉及技术选项、安全风险时要进行参与讨论，给出合理的有效的建议和可落地的方案，注意这里强调落地，即可实施的，在项目开发过程中学习成本要低。

流程：没有规矩，不成方圆，流程是指导项目一步步走向成功的阶石。

一、遵循主流程，结合现下的不同项目管理模式进行改进。

主流程共计7个 阶段：启动、需求、分析设计、编码、测试、上线、总结。

1.启动阶段

在此期间，主要是进行需求的调研与相关风险评估，以及项目范围的确定，遵循”产品项目需求流程规范”，在项目中需要参照相关信息的填写与维护。

2.需求阶段

产品同事出具PRD文档，研发同事确定相关负责人及项目需求参与人员；目前此过程是一个多次的反复过程。

PRD文档的质量是最评审阶段最耗时的，要及时分享，补充修正是家常便饭，如果项目工期紧，要懂得取舍，不要眉毛胡子一把抓。

3.分析设计阶段

此部分主要是研发同事需要进行的，包括分析与设计、设计评审并给出详细的任务计划与排期，如果发生变更请填写需求变更表格。

注：详细任务计划与排期，不仅要包括系统的研发任务，还需要包括测试准备计划与时间、权限资源的申请与开通计划与时间、数据初始化等

4.编码阶段

此阶段是研发人员的主要工作,开发过程要严格按主流程进行，涉及到相关规范与文档如下：

开发过程中要遵守开发手册与编码规范，由于使用不同的开发工具所以编码规范可能会略有不同，但是在技术内部要统一，项目命名、函数命名、代码缩进、单元测试用例的编写等等。

源码管理要遵守GIT或SVN等源代码管理工具的标准，每个人使用习惯不同，但在此部分要严格执行流程。不能随意的创建分支、随意的提交代码到master库、分支何时合并到主干，由谁来合并，合并前代码是否Review了需要大家共同遵守。

目前在实际工作中，由于业务需求众多、每个团队都可能在进行着几个项目，项目需求上线时间也不同，这样对于研发同学产生很大的难度（相同模块代码可能几个项目都涉及更改）；此时就需要项目经理、产品经理和研发负责人来介入了，如何减少冲突是需要方法或个人魅力的。

开发任务与问题管理，要使用统一的管理平台，如Jira等比较成熟的软件。

此部分对于项目经理来说，不仅要应用项目管理平台，也应该利用Project工具做些处理，要关注关健路径上的任务，掌握进度及影响。

注：编码期间要进行单元测试及接口联调，在提交测试组前要进行联调测试保证整体流程是通的，对于代码的审核要在合并代码时或不定期的抽查进行。

单元测试是每个研发同事都必须要做的，这可以作为代码Review的一部分。

接口联调的时间往往被大家轻视，实践证明此部分工作经常是最耗时的阶段，也是最不确定的，表现在以下几个方面：

A.接口在定义时，涉及的双方并未能够明确接口的方式、参数、返回值等细节

B.需求业务发生变更，没有及时通知，你提供的并不是对方想要的。

此部分可以充分利用wiki等来进行信息的共享，加强沟通，一旦确定要以正式的邮件或文档为准，不要在项目微信或钉钉群里讨论这关键信息，很容易刷屏。

我曾需到过很多次因联调时因不满足互相扯皮的事件，不要以为平时大家时兄弟就降低了要求，工作与感情要分开。

5.测试阶段

测试是保证产品质量的不可或缺的重要环节，首先研发人员要按时、按要求进行提测，同时在系统BUG的解决过程中要严格遵循测试要求并及时处理。

原则：

当日的问题及BUG要当日处理完成，如果有问题要与相关人员进行沟通，影响严重的要升级，绝对不能私下解决。

测试过程中出现开发的系统与需求PRD不符的，要及时与产品、测试及相关负责人进行沟通，同时要确定解决方案

在此阶段，测试人员与研发人员是死对头，这时要互相理解，都是工具不要人身攻击，也不可意气用事，家和万事不兴，这句话也同样适用于项目组。

待项目结束时，回顾这些磕磕碰碰，回顾经历的事情，才发现成长的路上需要这些，有了这些才成熟，遇事才更稳重。

6.上线阶段

上线是项目的一个重要里程碑，上线的成功与否非常重要，所以上线计划及回滚预案是此环节必不可少的。

上线前需要制定上线任务计划表，同时要制定回滚的策略，如果存在风险在上线邮件中要声明，同时项目经理要组织会议进行讨论，风险的控制是贯穿于项目始终的；生产环境无小事。

A.上线期间严格遵守相关规定时行，严格按上线计划进行每一步骤的操作。

B.上线期间有需求变更，注意风险的评估

C.上线期间任何问题都要详细记录，同时关于测试数据与相关规范参见“测试任务流程规范”流程

D.上线日志交接（关键问题与遗留工作的交接）

在上线期间，最怕的是临时修改代码，这就是悲剧的开始，多少个不眠夜里，一群人围着一个人在修改代码，想想……确实挺怕的。

最后强调一下：测试阶段的数据准备与回收，涉及到生产环境的要检查、检查再检查；审核、审核再审核。

7.跟进总结阶段

上线后，需要继续跟进生产环境的数据与系统的功能是否正常，产品、研发等相关人员都要关注，对于重要数据要进行监控。

主要三部分：系统功能及接口的稳定性、关键数据的监控与预警、产品运营效果及数据分析

在此阶段最好能够将涉及的项目组成员召集到一起，做个PPT，展时一些数据，如关键服务接口的调用次数与响应时间、上线后带来的用户数、订单数以及业务的回馈。这样能够让参与的项目成员有成就感。

对于遗留问题的分配、要做到有人跟进处理，不能上完线了人就散了，过去的问题也随之灰飞烟灭。

此时公司或部门能够有项目奖金就更好了，可以组织成员吃一顿，互相唠唠，这时的沟通效果绝对比大规模的团建效果要好。

有的公司没有经费，是由项目经理或负责人个人组织的这种聚餐，随着消费的升级，人少还好，人多真TMD的承担不起；如果看到此文章的管理人员，希望你为你的团队去争取一下吧，毕竟公司的成长是需要各个团队努力付出，好的氛围是项目成功的一个基本前提。

环境：工作环境好坏也会间接影响项目的成败。

举个例子，目前大家都会去外面就餐，你喜欢有点档次的舒适环境，还是小吃店那种喧闹的环境。

工作环境也是很重要的，要让产品、技术的人有一个相对好点的环境，我个人比较想要的是这样的环境

1.灯光要亮一点，卫生要整洁一点，有阳光才有快乐，每天写代码就够累的了，讨论需求、设计，争论接口逻辑都会影响心情，一个相对宽敞的环境会让你舒服一点；好的办公楼租金不菲，但是无论在哪，安点大灯泡子费不了多少钱。

2.要有多一点的会议室，多一点的白板。

这是我这么多年工作最在意的，会议室其实是使用频率最高的地方，需求评审、技术评审、讨论方案、项目例会等等都需要有个地方；团队里、项目组总得开个会总结，总利有些内部的话要讲吧，如果没有地方，那么对沟通的质量是有严重影响的。

讨论过程中总要记录一些东西，白板的重要性相信每个人都清楚，随手拿起笔，随时记录画下来，是讨论过程中最简单有效的沟通方式。

如果连这些基本的条件都满足不了，项目执行过程中就需要克服，沟通质量适必下降，适必会额外增加一些时间。

我曾经在一家卖美妆的互联网公司工作过一段时间，充分感受到了互联网的氛围，办公区有很多会议室，随处都有玻璃墙、有笔可以让你在那讨论；高管有很多都没有办公室，就是为了增加员工开会的空间，人的状态饱满，真的挺怀念。

3.电话、视频会议的重要性。

异地办公不可避免，所以电话、视频会议是项目执行过程中不可或缺的过程。现在钉钉办公是非常有效的企业办公软件，大家可以尝试。

总结

人是环境、流程指导、环境辅助，这就是我目前对项目管理的理解。这里没有过多的说敏捷项目管理（因为我也没有什么实践不敢乱说），但是我们可以尝试着去用这种方式在项目执行过程中引用，譬如在需求收集阶段我们可以采用用户故事的方式来引导业务、来提高我们的需求质量；在开发过程中可以充分利用卡片或软件看板来展示当前的任务，标注出哪些在待开发，哪些在开发中，哪些在已完成，充分了解当前任务进度；每在可以利用几分钟的站会来讨论问题，以便提前解决问题，控制风险。

无论怎样，我们无论在大项目，还是小需求上都应该按项目管理的方式进行，可以简化一些流程，但不能无脑的去改变，基准线和原则还是要把握的，有很多朋友在考PMP或项目管理师，网络上也有敏捷项目管理的课程，取长补短互相借鉴总是好的， 最后感谢您的阅读！

作者：倔强的大萝卜
链接：https://www.jianshu.com/p/5460ebaade9a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。