需求管理

下图描述的是程序员从接到需求到开发环节的过程:

一般我们首先会收到产品的PRD或交互稿,被询问今天什么时间点是否有空,进行需求评审。时光匆匆,回想起刚毕业那时,我望着冗长的PRD,直接跳过背景、目的等看似与开发无关的内容描述。时光冉冉,我明白了一个道理:知道了为什么而做,才能砍需求啊!!

我们要做一个有思考的程序员,不是别人说什么我们就做什么,我们可以引导产品经理,给出提醒并提供建设性的意见,让他们向着我们希望的那个点去思考去改进。嗯,牛逼~

当然,祈求PRD完美,是不可能的,但是它又是我们排期、开发的依据,这两者存在这不可避免的矛盾。因此,力求在分析评审阶段,把不清晰不完整的部分暴露出来,是我们的目标之一。

特别警惕一句话需求,比如在页面添加一个链接,包含的功能可能有:

  • 确认添加a元素跳转为target=”_blank”,还是在当前页面跳转;
  • 链接的文字和地址是否可配置,是否通过接口拉取;
  • 链接地址是否可为空,此时要警惕target=”_blank”的情况;
  • 链接文字是否可多行,是否限制字数;
  • 是否需要埋点,以及确认埋点方案。

第二个目标,就是砍需求了。“没时间了,这个需求放在二期吧” 这个金句,不知道大家感悟深不深,哈哈。首先要清楚自己在某个时间段的工作重点,然后根据需求与工作重点的相关系数去评估,有意识地拒绝一些无意义的工作。当然,工作重点应该是与业务息息相关的,最好是和上级商量后的结果。

于是,给自己定个todo list,在需求评审前自己过一遍相关文件内容,列出有疑问的地方,做好砍需求的准备…

需求排期

确认需求后,首先确认需求的优先级,然后进行排期。
如果我们手上有许多需求,确认需求的优先级是十分有必要的。

  • 来自同一个产品的需求,可让对方给出优先级即可。
  • 不同产品的需求,可征求需求方的意见,避免出现严重影响到对方的主流程的情况。
  • 虽说需求的优先级主要掌握在产品经理的手上,但是我们自己也要有个认识。 了解 主线需求 > 主线的分支需求 > 锦上添花的需求 的原则,根据 用户覆盖面、用户使用频次、对用户的重要程度,以四象限法则“重要且紧急 > 重要不紧急 > 紧急不重要 > 不重要也不紧急”作为辅助等等,应付什么需求都重要、什么需求都紧急的情况。
  • 针对老板提的需求,下周要演示给老板看的需求,我们就乖乖地排期在前面吧,排除万难,没啥好说的~

排期一直是历史难题,有以下“名言名句”供参考:

  • 了解需求进入开发阶段的依赖条件,比如是否依赖设计稿还是接口,然后再进行排期。
  • 不要把一天当8个或者更多的工作小时用,临时的会议或者被打断的现象太常见了。
  • 排期留有余地,尤其是自己不熟悉的领域,风险较高。排期的计算方式有挺多,可以根据自己的丰富经验来,或者计算公式比如(一般能完成的天数 + 肯定能完成的天数)/2,或者(一般能完成的天数)* 系数,系数根据难度来区分。
  • 把握好需求的节奏,如遇开发周期较长的需求,将需求拆分成N个子需求。
  • 要明白,即使排期很轻松,你可能依然是最后一刻才完成,太扎心。

需求跟踪

需求进入开发后,特别是大项目,得利用需求管理平台,这有利于需求的进度追踪,且方便我们汇报工作。不要把汇报工作当做负担,应化被动为主动。否则,周五下午某个时刻,你会收到产品经理的盘问:“做得怎么样了?进度如何?”;汇报工作,也有利于让大家看到自己的努力成果,成就感增倍,形成良好的工作循环;或者是了解身边的小伙伴在做什么,有利于交流。

我们现在每周五会开项目例会,汇报内容如下:

  1. 结果:进度如何,完成了哪些内容?
  2. 计划:下周计划完成哪些内容?
  3. 问题:讨论问题,找出问题的失误点、关键点、反思点,如何解决。

需求变更

需求变更有时不可避免,我们还得拿出快速响应需求变更的本事,记录反馈所有的变更,拒绝不合理的需求。最好和产品经理达成一个共识,若因PRD的需求变动,则会根据实际情况重新排期。有代价,有反思,有利于督促双方在编写PRD、评审的阶段就开始认真对待,且定义好完成需求的标准。

研发管理

打开昨天没关机的电脑屏幕,找到自己喜欢的姿势,或穿着格子衬衫、棉拖鞋,或套着护颈枕,或带着耳机听音乐,然后就开始搬砖了~~

仓库管理

为了规范代码仓库,使得版本的演进保持简洁,主干清晰,因此得遵循一些规则,避免由于维护困难造成的错误版本发布等问题。

分支要求:

  • 每个需求必须新开一个本地分支,并备注好需求描述。
  • 每个分支只做一个需求,切勿需求交叉修改。
  • 合并后或无用的分支需立即删除,如果有修改,再重新拉一个新分支。
  • 约束命名规则,如采取master、dev、feat、release、hotfix命名方式。

提交commit要求:

  • 保证commit历史记录的整洁,要求提交的代码粒度要小, 尽量保证这个 commit只做一件事情,否则很难描述清楚。
  • 约定commit提交规范,如 Angular 团队的规范<type>(<scope>): <subject>,且利用commitlint工具约束一些格式,同时避免使用-n强制提交。

有分支就有合并,合理选择适当的时机、适当的方式进行合并,比如merge --no-ffmerge --squashrebase还是cherry-pick。大家都知道,变基有风险,且要遵循变基原则:只对尚未推送或分享给别人的本地修改执行变基操作清理历史,从不对已推送至别处的提交执行变基操作。

有合并就可能有冲突。如果一直存在大量的冲突,说明是分工、组织架构不对,需要减少多人同时改动同一份代码的几率。如遇到冲突,可采取以下措施:

  • 降低合并分支冲突的数量,比如先合并少冲突的分支,再合并冲突多的分支。
  • 熟悉Git操作,适当借助可视化合并工作。
  • 合并后的代码检查,让代码实际运行一遍。
  • 如果冲突的不是自己负责的代码,让具体负责人来参与代码合并。

代码管理

  • 逻辑一定要清晰,考虑周全。不要只考虑普通情况,还要考虑什么情况会出错,失败了如何处理,总之,多维度去思考。
  • 当第二次编写相同的代码时,是提取成组件的正确时机。对于大项目,第三次才提取,将会增强执行的阻力。
  • 一定要多写注释,解释代码的意图和及其原因,再次回头看的时候,你也会十分感激自己,效率往上蹭。
  • 如果函数或方法超过 30 行代码,考虑优化它,可用工具比如vscode的插件CodeMetrics辅助提示解决,心中要有一把尺子时刻鞭策自己,凡事得过自己那一关。
  • 看到问题,即使暂时不能解决,一定要以某种方式把问题抛出来,不然容易遗忘在某个角落。当然,能解决就当场解决,再次拾起的时间、人力代价也是很高的。

风险管理

即使小心再小心,意外总是会在某一刻发生。所以我们要时刻控制,降低需求变更、项目延期的风险,应用积累的经验和专业知识来预测何时会出现风险,以及如何采取有效的应对措施。

下面挑几个重点讲讲:

  • 需求理解误差、难度误判、排期紧张,在分析评审阶段,可以一定程度地避免这些问题,当然也和我们自身的能力有关。自己越没有把握的事,争取留些时间以备不测,避免延期的情况出现。
  • 确认有效的沟通方式,及时抛出异常。可在研发邮件中暴露进度是否异常、同步需求变更,是否存在待确认的问题,或者标红其他重要信息。
  • 认真验收所有需求,是否遗漏功能。除了覆盖功能基本流程逻辑的形式,也可以从用户的使用习惯角度去进行场景测试。说起来容易,有时候做起来难,特别是对项目不是特别熟悉,项目又特别复杂的情况,此时要做的就是,根据代码影响的范围来确定自测的范围。项目成员可共同维护一份功能列表,以此为依据进行测试。
  • 保证测试分支与将上线的内容一致,也就是说,保证测试分支的干净程度。如果测试完毕后才合并分支,可能带来合并冲突的类似问题。
  • 针对大版本,分析上线前的依赖,通知到所有相关人员,最好开一个上线总动员的会议,共同探讨上线注意事项、遗留的问题。
  • 针对小版本,约定上线的频次。可每周固定周二或周四发版,且发送上线申请邮件,不可随意发版。
  • 上线前后,指定每人负责某些模块的测试以及风险管理,有利于内心产生更大的责任去做好,甚至可以影响督促别人。
  • 上线后,及时回顾总结项目的成功和失败之处,剖析各个环节存在的问题,为以后的项目提供参考。

一个优秀的程序员和一个普通程序员的差别,可能在于理解问题的深度。
“试试重启一下电脑”,当电脑出现问题的时候,我们经常会想到这句话。但是有没有想过,可能失去了一个挖掘问题本质的机会,导致以后问题该出现的时候还是会出现。
再者,我们码程序,修BUG,有时候忽略了质量,而去赶进度,这是得不偿失的,最后坑的还是自己啊。

总结

以上从需求管理、研发管理、风险管理三个大方向,又细分了小方向去讲述如何管理好手上的项目。人本身就是一个产品,多个项目的集合。项目就要好心经营,精心管理,因为正是这一件一件的执行的过程,构成了我们丰富多彩的程序员生活。

原文链接:https://aotu.io/notes/2019/09/11/project-management-of-programmer/