wordpress编辑器插件ueditor,网站seo快速排名优化的软件,php网站后台密码忘记了怎么办,网站建设费用大全戳蓝字“CSDN云计算”关注我们哦#xff01;作者 | 墨玖来源| 阿里技术导读#xff1a;在技术公司、尤其是互联网公司#xff0c;技术人员作为PM(项目经理)是非常常见的。有些同学得心应手#xff0c;有条不紊#xff0c;能得到清晰稳定的预期结果#xff1b;有些同学则… 戳蓝字“CSDN云计算”关注我们哦作者 | 墨玖来源| 阿里技术导读在技术公司、尤其是互联网公司技术人员作为PM(项目经理)是非常常见的。有些同学得心应手有条不紊能得到清晰稳定的预期结果有些同学则在过程中遇到各种闹心的事最后不是项目上不了线就是带着问题或各种人员的不满硬上。当然这两种都是比较极端的结果。理性思考下这里面有没有规律在今天阿里高级开发专家墨玖和你聊聊如何做好一个技术项目的 PM。目标分析对于任何事情要有清晰的目标才能精确把握如何做好一个技术项目的PM首先我们看到这里面目标最起码应该是如期交付有质量保障的项目产出。这里有几个需要我们注意的结果关键词如期交付(守时守信)、质量保障(保质保量)、项目产出(完整结果)。当然还有最重要的因素人 过程 。阿里有句老话叫做没有结果的过程是放屁没有过程的结果是垃圾。所以项目管理也是一样。我们既要结果又要过程当然还要这里面人舒服 。这里我们再总结提取下目标1. 项目目标如期交付(守时守信)、质量保障(保质保量)、项目产出(完整结果)2. 人员目标舒服、有成就、有成长3. 过程目标风险控制、信息同步。接下来我们就按照项目的生命周期来看看以上目标要怎样才能更好地达成。 目标达成★ 项目启动项目启动重要点是需求宣讲俗称画饼拉人 。任何一个项目都会有既定的目标和预期但是这个目标大家认不认如何衡量结果好坏做完后有没有成就感这是项目后续成败的关键。所以你需要思考好这些东西才能和大家宣讲、才能拉人干事。不然人家都不知道你要干啥、干了有啥好、为啥要(卖力)给你干。作为项目PM的你定义好项目目标、衡量结果ROI、人是尤为重要的 。这里提几点建议和思考。1. 目标你为何要做这件事2. 目标你的目标有没有足够明确有没有清晰的大图3. 目标做这件事的意义是什么4. 结果你有没想清楚个目标的关键因素核心指标是什么5. 结果有没有附加的影响和因素是好的还是坏的6. 人你自己是否足够清晰能够完成项目的重要因素尤其是大的项目top-down的思考。7. 人你能为大家提供什么来确保顺利的分工配合越俎代庖阻、撒手不管都是不可取的。8. 人这个项目需要哪些人哪些角色他们核心关键是哪些9. 人参与这个项目的同学能得到什么失去什么共赢吗10.人参与的同学的成就感在哪里当你思考和整理好以上这些东西才能做好项目(需求)的启动和宣讲。目前我们很多项目的组织方式是由多个角色完成的。常见的方式是运营或业务或产品做了项目中的一部分或所有然后到需求阶段再由技术同学跟进后半段。这个角色有多人共同分担并不冲突重要的是我们要配合默契、衔接得当、相互补位拿到共赢结果。工作过程中我见到过激情澎湃的KO也见过稀里糊涂到直接开车所以生活(工作)还是需要一些仪式感。注意做好这些点项目后面会顺畅很多。★ 需求评审一般需(hua)求(bing)宣(la)讲(ren)完毕后很快会进入需求评审阶段。这里是需求细化明确重要节点。作为一个项目PM你必须要做到小需求了如指掌、大需求合理拆分 。这个阶段最好是个时间段而不是一个时间点。尤其是对于互联网我们讲究的是快速节约大家时间。你有必要提前深入介入了解需求逻辑和范围。这里会遇到如下几类问题1. 需求(描述或意义)不明确、理解不一致。 解不要牵强、不要害羞。描述不清楚的讲(写)清楚意义不清楚的增加解释。PM都要搞清楚搞明白这样你才能够在中后期答疑解惑环节节约信息同步成本。实在不行就回到最开始的目标上去意义在哪里2. 关键人员没拉到到位。解这个其实我们经常会遇到原因也有很多。事前列好人员信息版(可以放心里)是一个很好的习惯我个人习惯用钉钉群公告云雀 note 页。事中则需要补救和充分沟通了还好我们的同学都很能相互理解。3. 需求范围膨胀。解这个问题也是我们项目中常见导致项目最终崩溃的原因。所以你是需要提早接入需求的最起码要比评审早。确认好项目的人员投入数量、投入度确认好本次重要目标和次要目标。适当的时候要做需求拆解不要做超量(加班也可能搞不定)的计划。不要做好好先生。你要清楚你的职责是如期交付有质量保障的完整结果。除以上问题外对于大型的跨团队的项目可能当下是无法详细看清全局的。这就需要大PM在这个时候量力而行尽早分拣分派、划定二级责任人。在互联网公司需求评审过不过一般都会提到需求沟通和宣讲。所以需求评审一般是PM认同了项目目标和意义的这个要特别注意。所以具有PM角色的你(们)要更多的做配合需求拆分细化、答疑解惑而不是一堆问题瞎怼(这可以发生在宣讲或再靠前)。这里我提下几个重要的点。1. 需求评审要提前做好信息充分公开有会议邀请关键人员要拉到位。2. 评审后关键参与人明确自身工作目标和职责。3. 重要信息、问题和困难收集。同时做好信息公开同步。4. 重大设计、困难单列单独跟进。完成以上后项目人员也基本铺开了。接下来更多的需要并行。★ 项目排期评审完毕后紧接着的就是再次的资源盘点和目标对焦简要的 recheck 确保补齐。这时 PM 根据各负责角色工作评估做出简要排期和项目需求参与方核对各方诉求确定最终版本。这里也会遇到几个问题排期时间过长。 解拆分、加人、分阶段。建议最小工作单元评估最好不要超过2人日 。其他项目排期冲突。解分析是产品节奏冲突还是人员(资源)冲突确认好各自目标再共同协商总体排期。重要阶段未给足充分时间如设计阶段、系统联调、冒烟、测试、内测等经常忽略项。解提前协商沟通好协调。最后项目排期要和各参与同学沟通清楚投入度和时间节点。一定要明确几个重要的时间点设计评审、测分评审时间、提测时间、产品验收时间、发布时间(如果客户端还要根据不同端特殊情况分开列出)。同时排期过程中可能遇到的并行风险、人员资源风险及时对外同步。★ 设计测分评审设计之于项目隐患后期扩展、测分之于项目质量风险的意义技术同学想必都是非常清晰明确的。这不仅仅要求项目PM对于核心的系分、测分设计人员也提出严格要求。务必保证1. 重要流程有图、有文字、有用例覆盖。2. 重要设计方案、测试方案要提前沟通讨论评估风险和影响。3. 需要考虑资金、安全、性能、风险的单列 todolist checklist。4. 重要设计影响对外同步。对于技术型的 PM最好满足1.项目中的核心设计者2.业务 owner 或核心其中一项。这里主要是考虑到技术项目 PM(实在不行要有核心设计人员)对于业务定型、技术定型在业务中后期的影响着实太大。此阶段开始作为过程跟踪重要手段需要有常规的项目日报和风险提示 了。建议对于工作日小于20人日的项目可以不用每天发项目日报有风险及时同步即可。超过的最好每日有项目详细进度 根据项目复杂度不同 粒度可以精确到单人负责的模块 。重要的是过程跟踪问题及时反馈解决。★ 研发过程研发过程中一般大家精力都会集中在各自项目负责模块上。同时对于我们这种互联网公司变化又是家常便饭。这里有个原则是信息跟踪和同步评估要充分。可能涉及到排期调整的要及时沟通和调整。也要注意风险和项目范围把控。这时你可能会有如下帮助1. 项目空间任务列表(aone有批量功能)2. 排期进度表(云雀)3. 需求变更记实录表(云雀)4. 人员负责表(云雀)5. 风险跟踪列表(云雀或aone)6. 过程进度日报模块进度条百分比、当日工作主要内容、风险同步与处理。 7. 重要逻辑影响对外同步(如表逻辑、业务逻辑变更的需同步对应使用方)。★ 冒烟联调提测大家都知道大多数的线上技术问题都可以在测试阶段提前发现。而PM要思考的是测试前我们能做什么提测前的冒烟、联调包含了必要的单元测试、功能测试和部分集成测试。尤其是对于多系统联动的项目冒烟和联调的质量直接影响到测试效果和线上问题量。这里PM一定要提前沟通评估安排好时间控制和冒烟联调节奏有必要的话集中闭关小阶段目标设定可以实行 。同时对于复杂的项目由于整体节奏和工作压力等原因参与人员很容易陷入自我流程和模块逻辑里。 在联调阶段作为PM最好能设计出几个经典业务场景作为联调目标对项目的整体质量做提早把控 。重要项目特殊建议1. 全量(70%)含凭证冒烟。2. 流程覆盖设计测试执行(PM)3. 闭关联调分模块分阶段联调半日目标进度。4. 独立的项目联调环境准备。5. 关键链路的日志标要求。无论是作为核心开发还是纯PM此阶段都需要主动去检查项目的研发交付程度。包含但不限于主业务流程、特殊分支逻辑等 。你可以根据项目重要程度复杂程度来判断是否需要精细化。同时此阶段也很容易暴露缺失或错误逻辑。我个人做法是小型项目自己设计场景 case 走大型项目联合核心研发测试一起设计场景 case同时注意对产品交互和 demo。★ 测试项目到了测试阶段大部分的开发工作已经基本结束了。我们这里讨论一种场景是开发测试有不同人员执行。测试 bug 要督促做到日清不能日清的需要有原因跟踪。本阶段一般也是 code review 集中阶段。PM应直接或间接的对于关键链路设计、流程日志记录、编码规范要着重把关 。同时产品发布回滚方案在本阶段要做准备了。一般来说每个团队发展到2年后都会有比较规范的发布计划模板。这里我们着重提及几点PM要注意的事项0. 安排处理好项目测试环境确保稳定性。1. 安排各系统CR节奏并跟踪反馈。2. 安排发布计划讨论和准备。制定并总结初步发布执行计划(单点对应明确责任人)。3. 安排讨论确定版本限制兼容方案。4. 安排准备线上功能开关和灰度方案。5. 重要项目要有发布预演。6. 预发和线上不隔离的系统要注意单独考虑预评估发测试风险。有必要的给出操作步骤。★ 产品验收一般情况测试完成后就到产品验收环节了。这个过程有些同学可能就直接不问或者任凭产品验收结果做最后的质量兜底。这是极为不可取的原因是一般的产品验收最多只会跑到整体项目 case 的30%不到越是大越是复杂的项目这个比率越是低。产品验收的目标是检查产品功能完整性、产品体验而对C的线上用户几乎会全方位无死角覆盖。所以这次是你产品(功能)细节问题的最后一次机会。考虑到项目成本收益重要程度对于特殊项目需要单独的组织参与人员设计并执行内部验收以确保多人更大范围的产品检验。 这个事情有两个重要意义1. 项目产品信心建立。2. 项目产品功能体验review。一般性的准备我这里也列举下1. 产品验收checklist2. 验收环境准备3. 验收数据准备4. 验收问题列表5. 变更列表(云雀或aone)此时的改动要特别注意变更风险和范围评估6. 数据、BI、埋点验收准备7. 产品验收数据收集(可选)。★ 项目发布在以上阶段都完成后就到了项目发布的最重要阶段。在准备好发布计划的前提下。要注意多系统联动的 发布时间节奏、依赖控制、风险控制、线上验证等把握。严格执行发布流程和回滚方案的同时注意以下几点1. 提醒系统发布前中后检查建立通知机制发布群。2. 系统发布要注意API变更、数据及表结构变更等对线上逻辑的影响评估。(一般预发布已经做了)3. 发布后的线上检查特别注意检查本身会否影响线上功能和数据。4. 最好做到发布功能有开关线上白名单。5. 复杂项目的发布一般会选在在晚上但同时要做好分班跟进计划。6. 发布完、线上验证完毕后项目发布邮件及通知同步要到位。★ 复盘总结互联网公司唯快不破。再快的产品功能发布 也需要回到我们最初的本源目标有没有达成所以回到我们项目起初制定的目标和衡量标准需要有个目标达成总结。重要的点提及下1. 项目目标衡量数据统计。2. 过程优缺点复盘,扬长避短(非所有项目)。3. 较为成功的项目要及时安排庆祝(仪式感很重要)。★ 其他的补充互联网公司有个很大的挑战就是项目节奏压力。同时通过以上我们也可看到想要做好一个项目是需要付出很多的有很多东西都是默默地背后的。项目也好产品功能也好。都是人做出来的。再牛逼的业务宣讲、再清晰的目标设定、再精细流程把控最终都逃不过人这个核心的落脚点。作为PM你要时刻反思真正的业务诉求是什么项目有没有偏离轨道这个人跟你做项目能不能得到成长、成就他有没有被你推到了墙角你是否能观察判断到可能的风险并最好规避、次之解决你会否会因为一个项目一场仗而得到一批干将这是除了项目结果以外我们需要思考的。不仅仅是业务或技术这是走的长远、是准备未来。关于数据变更(结构数据)包含表结构变更、数据格式变更、数据内容变更等 在系分阶段要同步BI(其他数据使用方)项目验收前要再次确认。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读做了中台就不会死吗每年至少40%开发资源是被浪费的美女主播变大妈在bug翻车现场说测试策略漫画高手、小说家、滑板专家……解锁程序员的另一面手把手教你如何用Python模拟登录淘宝鸿蒙霸榜 GitHub从最初的 Plan B 到“取代 Android”每天超50亿推广流量、3亿商品展现阿里妈妈的推荐技术有多牛真香朕在看了
