admin 管理员组

文章数量: 887021

项目管理

一、 项目过程:

1. 需求调研

需求来源:行业需求;企业需求;市场需求;场景需求
目前项目的需求来源于科研部,后续跟着市场节奏不断增加新的需求

总结经验:
方案探讨前一定记得把需求涉及的系统能力、系统调用逻辑调研了解清楚,这样对后续方案的讨论和敲定都会起到积极有效的作用;
● 严格意义上的需求方尽可能把业务流程梳理清楚,产品端逻辑梳理清楚;
● 尽量减少减少因为需求不明确,导致返工情况;
● 需求提前两个周提出,方便后续产品规划,和研发开发;

2. 方案开发
a. 方案设计

经过前期的调研和需求分析,方案设计阶段要求我们聚焦产品主线和价值内核,寻找能解决问题快速看到效果的最小可行化产品(MVP),即聚焦核心用户的最小最基本的功能组合。

总结经验:
● 优先关注内在的而非外在的,关注实际的而非未知的;MVP阶段优先解决的逻辑性问题,后续迭代关注细节的性能和体验;
● 在初步方案评审阶段,拉齐相关方(需求方,发起人,参与者),多次有效沟通交流,逐渐明细方案设计的具体方案;

b. 需求评审

形成初步方案后,需要拉着开发、设计、运营等相关人员以及项目负责人对方案进行评估。从初步方案到成熟方案经历好几次打磨,所以参与评估时一定要保持良好心态,并在项目周期中预留出足够的方案调整时间。
评估可分为产品侧和技术侧两方面,主要评估当前解决方案能否满足需求,能否创造价值,操作逻辑以及方案落地的技术可行性。

总结经验:
● 需求评审,产品事先了解相关技术,评估会之前与技术同学沟通,了解技术背景进行简单的技术评估;
● 借助图形和少量文字聚焦逻辑主线,不要过多关注细枝末节或者价值输出少的功能点。要讲清楚需求背景和方案价值,与与会人员建立起共识;
● 在项目周期中预留出足够的方案调整时间,需求评审早于开发版本一个迭代周期,出现问题可及时调整,不影响下期开发进度;
● 产品做好排期之后,开发同学根据实际情况,做个预估,在可控的时间范围内,做好自己的排期,(后续出现问题及时沟通交流);
3. 项目管理
a. 任务管理
1) 需求排期
● 排期前首先要评估需求优先级,在评估会之前最好先自行评估一下,对需求进行排序。然后再拉着团队成员在此基础上调整,这样能够有效提升评估排期的效率;
● 善于利用排期表进行任务分配,需要确认每个需求任务的负责人,保证其真的清楚任务要求和交付节点,每个人的表达和理解能力是不同的,其实很多任务延期都是因为前期没沟通清楚导致的;
2) 文件管理
● 需要熟悉项目开发中产生的各类文件,确定统一的传输和保存路径。
● 文件名可以加上创建时间方便后续查找,即使是更改过的文件,对于较大改动也应当保存更改记录,这样有助于我们更清晰地了解项目演进过程。
3) 进度跟踪
● 每日例会或是周会,开发过程中可以根据项目情况多组织小会及时同步进度;
● 对于多条并行的任务要合理安排时间及时推进,切不可只顾一头,真实的实践场景很复杂,提升多任务并行解决的能力很重要;
● 关注交付节点和风险点,当感知到问题在节点不能解决时可以积极需求其他开发人员帮助,遇到问题及时沟通交流,不要陷入苦思冥想而超过交付节点。
4) 解决突发问题
● 面对突发的bug,快速试错和复现判断问题成因,提高解决问题的效率;
● 举棋不定的时候不要搁置争议和问题,一定要搞清楚原因,再三确认能否解决,解决不了的话也把原因记录清楚再找其他解决方案或者咨询他人
b. 向上管理
作为项目负责人,除了具体的方案开发工作外,沟通是非常重要的一部分,主要包含向上管理和团队沟通。
向上管理指与上级相关的沟通管理工作,向上管理是否有效良好甚至决定着项目的走向。
总结经验:
1) 方案讲解
● 方案讲解时主次分明,指出主要问题阐释和相应解决方案以及该方案的优势和价值;
● 注重讲解的脉络和逻辑;
● 在方案首页和末页整理出一个议程或信息总览,让与会人员对讨论的议题更有概念,方便围绕议题进行讨论并敲定方案。
2) 应对质疑
● 积极反馈项目进展和工作内容;
● 对于上级的合理质疑,不要急于给出结论,要多思考实践从多个角度去论证,得出结果后及时反馈给上级
3) 进程汇报
● 除常规的项目汇报外,对于风险点要及时尽早提出,千万不能抱有侥幸心理,要学会借助上级的力量协调资源处理问题规避延期风险;
● 对于市场的发现的新动态也可以多整理多汇报,这样之后形成需求落地就会容易很多。
c. 团队沟通
总结经验:

  1. 沟通方法
    ● 说对方能听得懂的话,除了上级产品经理面对的角色主要有开发、测试、设计同学,还有可能接触市场、销售、美术等其他部门同学,不同角色往往有着自己的话语体系,产品经理需要对此有所了解并有针对性地调整沟通方式;
    ● 沟通方式要灵活,对于难以解释的事情或者紧急的事情,要积极地去进行面对面沟通;
    ● 带着目的去沟通,沟通时要有明确目的不可含糊不清,注重提高沟通效。
  2. 任务落实
    ● 队内沟通中非常重要的一部分是任务分配和执行,任务实施前要把任务细则、目标和时间节点都明确出来确保成员意见一致,并让每个人都清楚负责的内容,有可能出现的风险和预案最好提前说明,让大家都做好应对准备;
    ● 任务执行的过程中,非必要时产品经理不能擅自修改需求,不然开发会崩溃,测试同学会流泪,不利于团结;
    ● 跟进任务时要有节奏,可以为执行阶段设几个跟进节点,了解任务进展及时规避风险。
    d. 测试实践
  3. 产品自查
    ● 在方案设计阶段,自己准备一个常用自查表进行产品自查,比如页面、控件、交互是否完整流畅,文案和提示是否适当完备,是否考虑全异常情况等等。
    ● 前期把事情都考虑清楚能够极大减轻之后的开发和测试压力;随着开发深入和产品成熟,自查表需要及时更新,可以去掉项目不涉及的检查条目,让自查表和项目更加匹配,为后期迭代提供依据(目前可能存在更新不及时情况,这个之后会注意)。
  4. 测试准备(目前缺失部分)
    产品测试是产品生命周期中及其重要的环节,一款产品没有经过测试就推向市场的话。尤其是B端硬件产品,整个系统较为复杂,存在系统性风险的程度非常高。推出的产品在用户使用过程,出现重大异常,会损失产品口碑,甚至结束合作关系;

● 当项目开发进入尾声,就可以开始准备测试内容了,要提前和测试同学沟通好测试需求和测试样例,并让测试同学尽可能熟悉项目内容;
● 产品测试过程涵盖产品生命周期几乎所有环节,产品测试保证了产品制造输出产品与最早定义的产品一致,同时能够发现评估产品存在的风险,为打造稳定、可靠、可制造的产品提供闭环检测手段。
3) 测试反馈
找一个固定位置或者软件同步测试结果,保证项目相关人员都可以看到,并做好记录保存,方便之后查看校验;对于测试结果,需先对测试结果分类处理,再对要修改的问题进行优先级排序最后与开发沟通排期,解决相关问题
4) 项目验收,运营上线

二、 总结分析

  1. 问题描述:以叙述的方式描述项目过程中,遇到的问题或收获,可以从项目各阶段里程碑划分,例如,上线部署时,测试验证时间比较长而且覆盖面不够全。
  2. 预期结果:基于问题或收获,抛开实际结果,理想化的分析目标期望达到的最完美结果。
  3. 实际结果:实事求是,记录基于问题描述,实际达到的结果。
  4. 原因分析:通过对比实际结果和预期结果的不足或超额完成点,分析导致两者差距的原因。
  5. 经验总结:从原因出发,剔除项目因素,分析优点,不足之处,总结可适用于后续项目的经验规律。

本文标签: 项目管理