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

作者：暖暖

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

需求管理

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

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

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

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

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

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

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

需求排期

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

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

需求跟踪

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

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

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

需求变更

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

研发管理

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

仓库管理

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

分支要求：

提交commit要求：

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

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

代码管理

风险管理

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

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

下面挑几个重点讲讲：

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

总结

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

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

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