一粒略有成效的Management

经过了近两个月的忙碌,上周五顺利的发布了公司内部的一个CRM系统。就技术而已,项目本身没多大难度。但是,作为我踏入职场之后的第一次Project Management, 还是给我带来了很多新鲜的体验和不同的思考。所以,很值得来一次复盘。

management

背景

这个CRM系统在公司的技术团队组建完善之前,就需要使用,所以当时在比较急的情况下选择了外包购买的方式。后来因为多方面的原因,比如外包产品不是定制化的,不那么好用,以及该系统产出物的目标客户的特殊性等,公司决定自行开发一个此CRM系统的替代品。而在我接手这个活之前,是有一个小项目组在做的,而且据说已经做了3~4个月。这个项目组的配置是3个后端,2个前端,技术经理是一个后端开发,大概3年以上工作经验,其他人平均工作经验在半年到一年之间吧。

之所以变成我来写这个项目的review,是因为之前5个人的团队3个多月做出来的半成品,第一次提测的时候被QA认为是几乎无法使用。眼看Deadline还有不到两个月,管理层对于这个状况表示无法容忍。过程的一些细节此处不谈,最后的结果是技术经理和另一个后端开发‘被辞职’。项目组暂时停摆。

然后有天,CTO找我聊了一下,表示希望我作为牵头人,来接手这个项目。一开始我的内心是拒绝的,因为这种项目在我眼里,是大学生实验室里的一些外包活的水平。然而当时的我手头确实不算很忙,而且这个项目确实比较紧急,不能再拖了。所以尽管内心不是很情愿,也只能安慰自己说是来帮忙救火的。项目重新立项,作为该项目需求方和验收方的产品经理(公司高管之一,同时也是这个项目中我需向其主动汇报的人)老高请大家吃饭时,我的内心甚至有那么一丝对自己前途的忧虑。。。

先谈结果

进度

  • 2016.11.14本项目重新立项,到2016.12.23新系统p0(标识优先级)模块上线,再到2017.1.6新系统p1模块发布。至此,新系统可以算是提前交付了。

质量

  • QA团队的反应是该项目虽然提测时也有一些bug,但基本都是一些交互上的,不影响核心功能使用的bug,比起公司的主App版本迭代时的bug要少了很多。
  • 产品经理和目标用户试用后给到的反馈也是比较满意。不仅尽可能完成需求文档上所需要的功能要求,在交互上也做了不少的优化。
  • 我其实是知道自己埋了一些后面需要去填的坑的。没有选择一开始就填掉也是为了项目进度让步。不过这些坑对于内部系统来说,都是无伤大雅的。

团队

  • 团队从之前的五个人,缩减为现在的三个人 – 我作为一个应届毕业生,担任技术经理(或者不那么严格的区分的话,也算项目经理,因为项目进度主要是我在管控),带领另外两个大概有两到三年工作经验的程序员(一个后端,一个前端)完成任务。刚开始觉得要带工作经验比自己要长的人,心里也会有点没底。然而最后I made it,真心感激老东家@堆糖,老Leader@alswl和@shadow在技术和管理上给我带来的影响。

心态

  • 除了被队友坑的有那么些不爽之外,整个项目过程我是处于越来越享受的一个状态。这很出乎我的意料之外。

再聊过程

要人

新的团队中的后端开发也是被领导层指定加入的,所以我没有什么选择权。不过领导层没有指定前端,甚至希望我考虑下可不可以不要前端,UI开发的难看一点都没关系。这个问题被我直接拒绝了,不是技能栈没有延伸到那一块,而是出于个人的一些私心。来做这样一个项目无论对我还是另一个后端工程师都已经是对职业发展不那么好的一个选择,面向公司内部的外包项目和面向广大外部用户的移动互联网项目,我不想去进一步比较哪一个对于个人的发展更有利一些。更何况我已经坚定的将自己定位为后端工程师,花很多时间去写一些低质量的前端代码,与职业发展相悖,这一点当然不能轻易接受。我承认这确实出于私心,但是在公司有相关资源可用以及能保证项目进度的情况下,员工高度重视自己的个人成长,在长期看来也许是一件更有利于企业自身的事情。

总而言之,在我的坚持下,新团队有了前端资源。经过分析后,我向前端Leader开口要人了。因为之前跟前端的几个开发合作的不多,但对其总体水平略知一二,所以要人的时候比较谨慎。特地请前端Leader给一个效率相对较高的人,并希望后期其他项目的活尽量不要派给他,因为这个项目需要赶进度。最后前端Leader经过考虑,给了个确实相对之前的前端团队来说效率较高的人。但是在后面的合作中,依然一次次激起我内心数万头草泥马的奔腾。

CodeStyle & 单元测试

对于前面的团队留下来的源码,不懂代码的产品经理都建议我说:‘你们推倒重来吧‘。开始我还没有那么想这样做,但是当我看到源码中各种以大驼峰的方式命名的Method,各种以拼音首字母的缩写的命名的字段,以及连.gitignore文件都没有添加的repo时,我就知道我该干嘛了,当然我是先吐了一口老血。

考虑到代码中可能有一些业务的说明注释,我还是选择了在原有代码仓库上做修改。于是在下周一就要开工写代码之前,周天自己跑到公司加了一天班。在项目的gradle build流程中增加了CodeStyle Check和UnitTest的强制执行.并在后续的开发中与同事约定,每次push到dev分支之前,请在本地保证Build是Success的。可以不用追求覆盖率,可以不用使用h2之类的内存数据库,但是请务必保证代码风格check和单元测试的正常。而且尽量增强自己写的单测的健壮性,不要因为其他人随便修改了点数据库的数据,自己的单测就挂掉了。

当然,这里提到的单测其实已经不是严格意义上的单元测试了,而有点像集成测试。还有上面提到的,不强制追求单测覆盖率,其实也是一个潜在的问题。因为项目进度本身就比较赶,根本没时间做CodeReview,那么如果开发一个单测都不写,其实也是可以Build Successful的。但其实每个开发还是有一些良知和敬畏的,不会刻意去钻这样的漏洞。所以这个看起来漏洞百出的build规约,在我们这个项目的实施过程中,还是很顺利的。如果团队更大一些,肯帝是要制定相对完善的机制和付出一定的成本来保证代码持续集成的质量,比如引入h2内存数据库,比如定一个必须满足的单测覆盖率等等。

下面是我司主App的一个版本迭代项目和本项目提测后,被QA验证出来的bug数量分析图。

  • 主APP版本迭代项目

2.1

  • 本项目

crm2.0

两个项目中,前端(特指h5)跟客户端的构建流程都没有强制验证单测,而只有本项目的后端代码的构件流程中强制验证了单测。

两个项目的业务和架构形态不完全相同,所以上面的对比并不能说明全部的问题。然而bug数量如此悬殊的差距,我认为单元测试在其中还是起到了非常重要的作用。

测试环境构建自动化

现在技术团队持续集成用的Jenkins服务,无论android,ios,h5还是backend,都是我一手搭建起来的.与同事约定好git work flow之后,设定好Jenkins的job,就能达到每次push dev分支代码即可自动重启测试环境并更新代码的效果。如果单测失败导致build failed了,那么测试环境也就挂了,问题暴露也就越发的快。这样的模式,对于我们这样的小Team来说,确实很爽,很高效。

说到快速发现问题,又想聊下日志该怎么打的问题。我本以为不管怎样,根据不同的业务把日志打到不同的文件中是很基础的事情。但是现在APP团队的那些后台项目,所有的日志全打在一个文件里面…每次线上出问题了要查找关键日志,都很低效,还经常出现找不到错误日志的情况,其实不是真的没有,而是太难找。跟一些开发反馈过这个问题,但是得到的回复是不知道该怎么按业务清晰的划分,以及不是可以用logger的Class和级别去一行行匹配查找吗?。。。。我现在想说,即使按业务划分的粒度非常大,也能轻轻松松的把一个有业务功能的系统分成个四五个子模块吧。如果能分工打出四五份不同模块的日志,线上定位问题起来也要方便和快速的多了吧。

细粒度工作量估算 & 每日站会

聊完技术上的管理,接下来主要聊聊流程上的管理。

  • 需求确定之后,我先是给需求划分了一个优先级,分为p0,p1和p2。其中p0和p1上线之后就可以交付给用户们投入使用了,p2是一些诸如管理员管理系统用户账号创建之类的功能,即使不写代码,也能通过其他方式暂时满足需求。
  • 确定优先级之后,与需求方确认每个版本上线的deadline.并让各位开发对当前阶段要开发的功能,进行自我工作量评估,最后会写进团队的工作日历(下图是部分安排截图)。确保只要按照项目计划进行,就能如期交付。
  • 每天下班前开发组站会。每日阐述自己今天的工作内容,并自我评估进度健康状况。如果发现有delay迹象,会要求对应开发尽快做出调整。
  • 每周五下班前,根据每日站会的统计情况,向需求方反馈项目进度周报。

进度日历

这套流程中,我觉得对本项目按期交付帮助最大的就是优先级的划分和每日站会的进度管理方式。优先级划分清楚之后,让我们心头的压力小了不少,只需要集中注意力去做一些用户核心需要的功能需求,那些不那么紧要的需求,我们可以排在最后慢慢去做。从而团队的节奏就会显得从容很多。

每日站会这个进度管理方式就更是重要了。它能够帮助我很及时的发现团队中有人节奏掉队,不管是什么原因引起的:也许是一整天游手好闲不专心干活,也许是被其他优先级更高的事件占据了时间,也许是碰上了技术山的难题卡壳了,或者干脆就是执行效率低下等等。我只需要每天拉上开发,花5分钟左右的时间,大家汇报一下工作内容并自我评估一下进度,真的是一个蛮轻松的事。因为有时候,通过口头汇报one by one的方式,落后的人会通过比较很明显的发现自己的进度是落后的。然后脸红,心跳加速等反应就会发生,然后会自己反思该如何把进度补上来等等。我作为项目经理,大多数时候不需要去过多的提醒。但是如果没有这样一个每日反思一下的流程,即使是自我驱动性较强的人,也会出现自己没能及时察觉的进度掉队。毕竟,在没有外力的干扰下,人总是比较容易的原谅和包庇自己。我自认为是一个自驱性比较强的人,然而也曾掉进过这样的人性陷阱里,幸亏是每日站会的制度及时的把我拉了出来。

另外,有些自律性比较高的同事也曾聊起过对每日站会这种进度的抵触性,认为其将团队气氛弄得过于紧张了等等。我也承认这种问题的存在,我觉得非常优秀的团队也许对于轻松气氛的需求胜过对进度状态监控的需求。然而大多数相对平庸,甚至情势不容乐观的团队(我司的部分技术团队目前应该算在内),对项目进度的及时掌控和调整,如果做的不好,可能直接关系到生死存亡。。。

推广协同工具

在本项目开展之前,我曾想推动整个团队去使用一些类似Trello, Tower,TeamBition之类的Get Things Done的团队协作工具。但是因为一说要花钱,就没太多后文了,所以一直没能成行。这次可以自己主导项目的节奏,于是要求小团队入驻了Tower,前文提到的工作日历,每日站会等都是在Tower上进行的。还有很多次与产品经理商量一些产品上的细节,我们都是在Tower上讨论并归档的。因用QQ讨论显得有效力不够,用邮件讨论觉得稍微重了点,而且两个人之间的讨论后面想让其他人看到,还得再转发,以及在内容的编写格式上受到的限制等等。而且这种工具对责任田的划分,任务完成时间的管理等都是有比较好的帮助的。

值得欣慰的是,产品经理在慢慢的使用过程中,向我表示过对引入这种好用工具的赞赏。最近跟CTO聊的时候,贴了个链接给他,他也表示希望能在后续推动这种协同工具在团队中的使用。

卓有成效的管理

在项目进行的同时,我拜读了Peter F. Drucker的经典作品《卓有成效的管理》。这是我到目前为止在kindle上看书做标记做的最多的一本。原因很简单,因为有很多观点直接戳中我所面临的问题。比如用人只需关注其长处,并利用好这个特质,让其发挥尽可能多的作用,而不用过多的关注此人的短处,更不能让其去承担太多于他而言有风险的任务。这种一边实践,一边通过看书来review自己的实践效果的方式,我会觉得受益很多。上次有这样的体验是在做一个重构性质的项目时,同步阅读了Martin Fowler的《重构:改善既有代码的设计》一书,同样印象深刻受益良多。

不吐槽会憋死

我决定还是控制下情绪。不多说了。

我对管理的认知

说了很多,但本文的核心关键词是‘管理’。这里我也不将论点延伸到个人管理什么的了,就谈职场上的团队管理。我认为,作为一个技术人员,个人的潜心修炼,日复一日的沉淀积累,也许可以让自己为企业输出的价值保持在30%到50%的年增长率,这个状态在刚参加工作时也许可以持续好几年,但增长率通常会越来越低,甚至会随着时间的迁移,出现负增长的现象。然而如果他能知人善用,能运用好「团队管理」这项“可怕”的技能,那么他的输出价值增长率也许能达到300%,500%,或者1000%,甚至更多。

但是,想要带领技术团队产出相比于自身500%以上价值的Manager,不经过好几年的潜心修炼和沉淀积累,那么他能领导和管理的人,也许会有一个很低的天花板,然后他的Team所能创造的价值,也会有一个很明显的天花板。

不过,我也不认为Team Leader只能管理比自己弱的人,毕竟「用师者王」。如何「用师」,是管理的高级艺术,此处不敢妄谈。。


路漫漫兮其修远。

road