从程序媛角度去看项目管理

做者：暖暖

项目管理通常是从技术负责人、项目产品负责人的角度去看的，程序员虽然码代码很重要，但对项目的领悟能力也一样重要。咱们常常会遇到各类困惑：手上的项目需求愈来愈多，BUG列表只增不减，该采起怎样的措施，保证本身的生产力？但愿如下的讲述带给你莫名的认同感，或多或少让你磨刀霍霍一试。

需求管理

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

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

咱们要作一个有思考的程序员，不是别人说什么咱们就作什么，咱们能够引导产品经理，给出提醒并提供建设性的意见，让他们向着咱们但愿的那个点去思考去改进。 嗯，牛逼~

固然，祈求PRD完美，是不可能的，可是它又是咱们排期、开发的依据，这二者存在这不可避免的矛盾。所以，力求在分析评审阶段，把不清晰不完整的部分暴露出来，是咱们的目标之一。

特别警戒一句话需求，好比在页面添加一个连接，包含的功能可能有：

• 确认添加a元素跳转为target="_blank"，仍是在当前页面跳转；
• 连接的文字和地址是否可配置，是否经过接口拉取；
• 连接地址是否可为空，此时要警戒target="_blank"的状况；
• 连接文字是否可多行，是否限制字数；
• 是否须要埋点，以及确认埋点方案。

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

因而，给本身定个todo list，在需求评审前本身过一遍相关文件内容，列出有疑问的地方，作好砍需求的准备...

需求排期

确认需求后，首先确认需求的优先级，而后进行排期。 若是咱们手上有许多需求，确认需求的优先级是十分有必要的。

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

排期一直是历史难题，有如下“名言名句”供参考：

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

需求跟踪

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

咱们如今每周五会开项目例会，汇报内容以下：

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

需求变动

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

研发管理

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

仓库管理

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

分支要求：

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

提交commit要求：

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

有分支就有合并，合理选择适当的时机、适当的方式进行合并，好比merge --no-ff、merge --squash、rebase仍是cherry-pick。你们都知道，变基有风险，且要遵循变基原则：只对还没有推送或分享给别人的本地修改执行变基操做清理历史，从不对已推送至别处的提交执行变基操做。

有合并就可能有冲突。若是一直存在大量的冲突，说明是分工、组织架构不对，须要减小多人同时改动同一份代码的概率。如遇到冲突，可采起如下措施：

• 下降合并分支冲突的数量，好比先合并少冲突的分支，再合并冲突多的分支。
• 熟悉Git操做，适当借助可视化合并工做。
• 合并后的代码检查，让代码实际运行一遍。
• 若是冲突的不是本身负责的代码，让具体负责人来参与代码合并。

代码管理

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

风险管理

即便当心再当心，意外老是会在某一刻发生。因此咱们要时刻控制，下降需求变动、项目延期的风险，应用积累的经验和专业知识来预测什么时候会出现风险，以及如何采起有效的应对措施。

风险管理就是如何预防风险：

下面挑几个重点讲讲：

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

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

总结

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

经验有限，或许以上内容有瑕疵，欢迎交流与更正。谢谢你们~

欢迎关注凹凸实验室公众号（AOTULabs），不定时推送文章：