业务方

关系

要让业务方明确团队的定位,明白团队和他们之间的关系,明白我们团队不是执行者,我们和业务方之间是协作关系,我们共同的目的是共同把产品做好

沟通

出入口

要明确项目的出入口是谁,出入口只能有一个,避免造成信息不同步或者不一致从而产生的分歧

需求

1. 明确这个项目的需求谁说了算,做事之前也一定要和产品确定我们要做的事是不是产品想要的(产品没有想法的情况下,引导产品按照我们的想法来)

2. 在项目进行中产品更改需求一定要通过邮件将需求变更抄送给该项目的各方领导层(可以做一个需求变更模版来记录每次的需求变更),以备不时之需.

信息同步粒度/周期

1. 业务方参与成员信息同步
一定要在项目前期确定业务方参与该项目的全部人员(包含产品,UI,测试,市场,运营等),还要确定后期会不会由其他人员介入,项目经理负责掌握业务方参项人员变动信息

2. 业务方出入口人员变动
要及时和业务方沟通,明确后续接盘负责人/出入口的人员,还要确定该负责人/出入口人员对项目的了解程度,如果不够了解,我们可以拒绝

3. 出入口人员变更导致需求更改
祥参需求项

4. 业务方团队内部信息不同步导致的项目延期等问题
尝试和出入口人员沟通并如实将情况通过邮件方式抄送给该项目的各方领导层

项目资料/资源版本

1. 立项前要求业务方提供项目开发的必备资料,同时确定原型/PRD等资料是否是最终版,如果不是最终版,要确定后期需求变更是否会影响主流程,否则拒绝立项
2. 开发过程遇到需求变更时要和出入口人员沟通使其同意按照小版本迭代的方式去变更需求(同时还要考虑实际场景,需求是否合理).

团队内部

项目预期

在做项目之前首先想下你对这个项目的预期是什么?想从项目中收获到什么?做完项目有没有收获到?把自己收获的能不能以文档的形式写出来?能否把收获的东西分享出来?能否在团队中推进你收获到的?

信息同步

项目经理要把获取到的信息及时与团队成员同步,团队内部信息一定要保持高频率的同步,这个需要项目经理培养团队成员这种意识.

开发细则透明化

参项人员在项目准备编码前将自己的开发过程以任务的形式写在worktile中对应的项目里面(后端人员可以是用例的形式),开发工程中把每天要开发的任务复制到每日工作计划里面,这样能够让参项的其他人员知道其他人的开发节奏,并且能很好的执行配合

心理问题

参与实际开发的团队成员在项目周期较长/较复杂或者项目无味的时候,对项目有抵触心理的时候怎么处理?
在进入研发阶段的时候,项目经理要时刻关注参项成员的状态,包括和人沟通时的语气,做事的态度,代码的质量,怠工等等,发现问题及时跟该成员沟通,以此消除对项目的抵触心理,确保项目质量与进度,参项成员若发现其他成员有这种想象也可以找该成员进行沟通,其实出现这种问题只能说明自己没有想明白自己能够在项目中获得什么

关于加班的问题

首先我们不鼓励加班,如果你一天安排的工作已经做完,并且能够保证后续工作不会影响项目进度,自身因素不会成为项目的风险点,那么你可以下班就回家陪老婆孩子了.

产品 or 项目

当你知道你要和团队成员一起做一件事的时候,首先你要明白你做的是什么?是项目还是产品?
项目:我们按照产品经理需求,项目经理的安排把手头上的工作做好,保质保量的完成工作,项目能够如期上线,线上运行良好
产品:我们做的产品被投放到市场,能够经过市场验证,能够得到大量用户,能够体现社会价值,我们自身的价值也就得到了体验
产品 or 项目?你选哪个?