随着现阶段公司规模的发展壮大，我自然而然的晋升了，这种晋升是隐性的，因为这种晋升，并没有伴随岗位的任命，也没有伴随有职级的提升，就是自然而然，顺理成章地掌握了一些话语权，并事实上行使着一些职权。
而这，恰恰是业务高速发展带来的一种红利，是在大公司，稳定团队里，没法享受到的待遇，曾经我加入的团队，经历过一次这样的扩张，然而那时候，我只有一年工作经验，机会来临时候，我毫无准备，现在公司再次经历这样的扩张，何其相似，历史重演，而此时，我已经有五年工作经验了，自问资质不算鲁钝，然而也并不太佳，刚刚够抓住这个机会而已，而恰恰巧合的是，我出现在家公司里，恰恰没有别人在，都是那么巧合，所以，我觉得现阶段，可能没法找到比这里更好的机会了。
之前一直以员工的身份成长，并没有机会扮演现在的角色，而贸贸然，我就已经在扮演了，于是乎，似乎有点应接不暇了，迷茫，疲劳，疑惑，所以，我觉得应该要对现在的角色做一个总结和思考，未必有什么用，但总比不想要有用。在这个到新公司入职一周年的时刻，我觉得时机也算得上是正确。
我简单整理了下，发现我至少扮演着8重以上角色，主要是从我的日常职责里面分离出来的，所以，我要分别按照八种角色的身份，来咀嚼一下每种身份的内涵。
以上作为前言。
流程梳理者
这大概是我扮演的第一重角色了，应该没有人能感知到我在做这样的事情，但是我自己知道我在做，因为我深信，做这些事情是有效的，尤其是放在一个比较长效的时间上看，是有效的，我曾经不自觉地践行过这些事情，恰恰我在上一家公司工作了近乎5年，从一个长的时间段的最终效果来看，我是取得了一些成绩的，但是那是在无意识的情景下，而现在，我知道我在干什么。
先谈谈以前，以前，我懵懵懂懂地就知道Wiki这个东西，也深刻认同这个是好的，当时，初入公司，发现公司有知识库平台，但是做得很烂，就像个10年前的论坛一样，好差劲的系统，好破烂的皮肤，大家在里面基本也只是灌水而已，根本没有认真去写，而我也觉得那上面大多数东西，都没有什么实际意义，所以，初生牛犊不怕虎的我，提出要建设团队的Wiki。
Wiki建立后，并没有人买账，你开个网上集市，别人就来卖东西买东西，最后你做成了淘宝，你觉得可能么，显然不可能，这道理何其简单，然而，那时候的我是不明白的，然而，那种冲劲决定了，我根本没必要明白这个道理，也会跨越，我就做了一个事情而已，你们不玩，老子一个人玩，我什么都往上面写，所有工作中用到的文档，技术文章，小技巧，小窍门，编码规范……而且，每来一个人，我都不遗余力去推广，直到一段时期部门扩张，大量新人入职，很混乱，我在上面写了一个新人入职指引，这个东西突然就变得受欢迎了，Wiki的威力显现了，这个总是能被轻易更新的Wiki，一下子打败了秘书的Word文档，最后技术团队的人入职，都按照Wiki来了，而对于新人来说，这个东西自然走入他们的眼帘，而里面也不乏有识之士，帮助我不遗余力地推广。
直到我离职的时候，五年过去了，全中心100多人，都在使用这个Wiki，渐渐已经呈现了威力和自制的一种氛围，大家已经养成习惯去编写，去维护，也知道什么该放上去，比如一些团队自己的知识，自己的历史，自己的系统，都会在上面积累，马太效应已经形成，社区自治规则凭空孵化，真是太棒了，我走的时候，上面的文档加附件已经几百兆甚至上G了。首页做得有模有样，我装的插件，前端组Leader给我做的皮肤，大家已经把这个当成了自己部门的网站了。
知识库，其实就是一种流程，一种传承，一种文化，一种氛围，这种东西在很多公司和很多管理历史里，都取得了骄人的成绩，而且产生一种隐性的好处和良性循环。可是建立这个东西是非常困难的，这就是标准的互联网产品冷启动的问题，所以，作为一个践行者，绝对不能着急，要有投入三年五年把它做好的一个决心，只有这样，才有希望，也才能在后期收获巨大的好处。
所以，为了复制这个成功经验，这次在公司一开始没多久，我就建立了一个Wiki，并且开始亲手编辑维护，不断地梳理内容的逻辑性，不断去整理，现在上面仍然没有多少东西，但是我坚信，我会把这个东西做好，以后就算我不在公司，也能发光发热。
这种隐性的，看起来没什么用的东西，恰恰是我觉得最重要的东西，大家未必会认同，但是我自己绝对认为这是最重要的，这是我这辈子唯一见过的，经我双手建立，自己产生生命的东西。
第二件事情，是对版本库管理的规范，标准工作流程的梳理和建立。这个事情，我恰恰在前一家公司也做过，非常巧合的是，也是我自发去做的。刚进公司，我就发现，大家对SVN抱持各种各样的误解，并且各种各样的误用，然后我自己也懂得不多，但是我至少知道，要分三个文件夹trunk，branches，tags，而且，应该一个项目一个单位，不应该一大堆项目放在同一个项目里，用一个子文件夹管理，太不专业，于是从我开始，各种新开的repo，各种新的项目，甚至为了大的新项目，开设repo，为里面所有独立的小项目，开proj，渐渐形成了一种惯例和感觉，什么情况应该申请repo，什么情况申请proj。
后来在两年多的时候，我又开始推动工作流，就是一个项目到底要怎么开发，怎么分支，怎么提测，怎么tag，不是去branches里建立个拷贝就叫分支的，必须是把整个trunk建立一个镜像，才叫分支，SVN不会阻止你去误用，但是你用对了，是有些额外好处的，建立了分支后，应该保持和主干的同步，最后开发完毕，应该重新集成，这些东西，SVN的文档里，写得清清楚楚，然而，基本没有人去看，我仔仔细细阅读了N遍，翻译，截图，写教程，然后开培训讲座，讲一遍，看一遍，一个个手把手教，帮他们解决疑难杂症，几个月，全部被我掰正了，一切都无比流畅。
最后，大家觉得我们的做法是理所当然的，几乎没人记得是我当初坚持，并且推广，硬掰，已经没人记得了，没人记得大家本来怎么用的，现在的就是最正确的，我觉得被忘记也没什么遗憾，但是所有的事情都正确了，我自己知道我的价值就够了。你把一列火车扶上了铁轨，它欢快得跑了起来，还有什么比这个更令人兴奋？于是我学懂了，研发流程管理里面，版本库操作工作流的重要性。以及实施这个流程的真正难度在哪里，为什么难。
在新公司里，CTO很时髦地选择了Git作为版本控制工具，然而，我来了发现，他自己，学得也是个半吊子，甚至同为技术合伙人的另一位，也用得一知半解，并不清楚其背后很多的思想，原理，工作流等等所有问题。而最最悲剧的是，Git的普及非常有限，而学习成本及其陡峭，无论从哪个角度看，这个东西都不应该被作为公司级的版本控制工具，这个事情，在早期意味着巨大的成本和紊乱。
我并没有反对CTO或者搬倒这个事情，我本人非常喜欢Git，出于理智不该用，但是出于情感，我想用，最早期，也并没有什么很多的程序员，就只有我而已，所以不会出乱子，我就很忐忑地开始用了，同时玩命学习Git的原理和工程管理实践。
随着陆续有人入职，大家果然在Git上遭遇巨大的困难，我手把手地教，跟他们讲怎么做，并且把最不容易引起混乱的方法告诉他们，但是这绝非最佳实践，我当然知道这不是最佳实践，就好比经济基础决定上层建筑，在程序员基础及其差和能力参差不齐的情况下，应该让大家快速投入生产，而不是耗时费力去学什么最佳实践，生产才是程序员的第一要务。
所以，我将大家实际操作的一个工作流，固化成了一个文档，去帮助大家学习理解，并且已经在这个环境工作的人，听说最新的操作流程不影响他们工作，就丝毫没有抵触。而且也很乐意去带领新人，于是整个流程就推起来了。
一个不规范不优美但是奏效的流程，绝对好于一个完美但是难以被理解和学习的流程。小公司招聘不到80分的程序员，更没有精力去将50分的人培养起来，能在他们里面制定一个自学习，自传播，自培训的版本控制管理和工作流程，我觉得我非常自豪，我觉得已经比以前更加成熟了，还给三年前的我，我绝对要让所有人学会业界公认的最佳实践的，然而我要是那么钻牛角尖，绝对无法做到今天这个位子上的。
做完这两件事情，人数渐渐多起来了，我就逐渐无法再写代码了，其实我从写代码的任务淡出，本来不该这么快的，但是一方面，我当时确实有点心情差，另一方面，CTO要求我从写代码中抽出精力，既然心情差，又有官方的指令，我乐得不写，结果一下子反而放空了，感觉什么都不做，很难受，简直难受的想死，根本不知道干啥，每天都打发时间，一直憋到我觉得我对不起我的工资为止，我想我必须干点什么了。
不能亲身去写代码，到底怎么才能发光发热呢？管理项目吧，于是我就开始管理项目。其实，5年前的我，最讨厌的人，就是项目经理，我觉得这个角色超级多余，他们的工作完全没有价值，都是些吃干饭的。可是我现在，竟然要自己做，这是何其可笑的事情，更可笑的是，因为对这个岗位职责的鄙视，我几乎没有任何经验的积累，甚至连从身边的项目经理身上学习，都做不到，因为根本不屑他们。
我对项目管理的第一重理解，就是监督工时进度，但是我发现，企业里N多人都在干这个事情，CTO自己就关心每个项目的工时进度，然后技术合伙人也在关心，产品经理也在关心，每个人都在采集这个数据，并做各自的汇报，我疾呼，这是我的职责，你们别管，根本没人理我的。我甚至天真地希望CTO任命我管理这个东西，这样所有人向我汇报，多余的人也不用来关心这个事情了，这想法何其可笑？
最后，我发现唯一能做的事情，就是也向别人那样去做，但是要用自己的方法，用更委婉的办法采集工时，用更科学的视角去总结统计，用更符合领导心理的视角去呈现，渐渐的，当别人都觉得我在做这个事情，并且他们做得没我好的时候，他们竟然自己就悄悄不再做重复的事情了，这事情就被我抢过来了。
通过这个事情，我竟然领悟了管理的本质，你先管起来，管得好，这事情就是你的了，任命什么的，只是锦上添花而已。这才是做事的真正顺序，先做，证明自己能做好，大家才会自然撒手，这事才渐渐归你了，那该有的都会有，任命会有，升职会有，加薪也会有。当然我仍然没有任命，也没有升职加薪，但是这个事情已然是我的事情了，别人再要拿过去，首先得做得比我好，我想那很难，是个很大的挑战，因为我为了拿到这个事情，付出了巨大的努力，那别人想拿走，需要付出比我多的努力。于是这个事情变成了只要我不撒手，就一直是我的，总不能永远不任命吧，而且，一旦这个事实成立了，那么其他的东西又有什么重要呢？
这个事情也是我建立的流程，是内化在我心里的一个流程，一个我管理下属，并且提拔他们的思考审视流程，提拔培养的流程。以后我想分拆哪个职责出去，我就会用这个流程顺序，请他先去做，并且请他背负这个责任，如果他背起来了，就代表他行，那给个任命不就是顺手的事情么？
通过采集汇报大家的工时和进度这件事情，我又发现了问题，我不遗余力的采集工时和汇报进度了，进度还是不能如我所愿，也不能符合领导的预期，每个小伙伴都觉得大家加班到想死，甚至已经萌生离开公司的念头，领导觉得最近一个月乱七八糟，简直糟透了。
我一定做错或者少做了什么，于是我想起来，大家都是程序员，研发团队，不光是工作就行的，工作需要节奏，一张一弛文武之道，总是加班，必然怨言，但是太空闲，则生产力低下，所以，要加班一段日子，空闲一段日子，求个平衡，就会习惯，给大家以喘息。
恰恰在这个时候，我们以前用惯的一套敏捷管理工具，突然出现了商业版本，立刻采购回来，用了起来，我虽然什么都不懂，硬是用一知半解的敏捷研发理念，去给大家灌输，规范，在每个人脑子里建立概念。我们怎么怎么规划迭代，迭代怎么怎么去管理。然后，大家说需求质量差，我就提出需求评审制度，大家说太忙，评审浪费时间，加班更多了，我建立了评审集中制制度，规定每周二四评审，并且不许拖时间，而程序员，必须把每周二四作为研发时间估时来计算，占用研发时间，其实并没有卵用，无法节约开发的时间的，但是程序员会觉得，我为这个评审估了时间的，再占用这个时间，是我自己的问题了，而且评审集中制，其实有很大的帮助，开发可以在评审的时候，休息下大脑，前瞻下后续的项目，好像做了个脑子保健操，关键是这种周二周四的节奏感，使得产品需求发射节奏化了，进而研发任务也就逐渐节奏化，很幸运，渐渐有了点节奏的气味。
而且，我至今也说不清楚的迭代概念竟然深入人心，每个人我相信并不懂，这到底是什么东西，但是整个研发学界都在嚷的名词，势必错不了，大家就以为自己明白了。于是也相安无事。只有我知道这里有多大的问题，太平只是暂时的，更进一步的混乱还没有开始，但是我不能说出来，我自己需要时间去成长，去摸索，去学习，那样才有机会带领大家走出这个坑，走出一个真正的节奏。
我面临的挑战是，所有掩盖的问题会再次爆发，整个研发团队会再次变成一团乱麻。而项目管理的失败会真正暴露。当然，挽救这所有一切，就是我后续的课题，这里作为一个总结性的文章，我无法陈述更多了。
我内心还有一个想法，就是程序员的成长与培养，我觉得我还没有太多的精力去思考这些问题，但是直觉上，这肯定是比组织大家从事生产更重要的。程序员需要空间去学习，去成长，而这些东西，需要有养分输入，而比起养分输入，更重要的是唤醒大家自学习，自成长的一种动力和愿望。我觉得这比一切的一切都要重要，这是研发团队凝聚和稳定的根源，这是团队文化和团队氛围的核心内容，建设好这些，我才能真正地解放出来，交出一个让大家放心的团队。
流程建设，这种事情超级无敌抽象和困难，举步维艰，如果说，作为一个程序员，我在IDE里面编程，作为一个流程建设者，我就在每个人的脑子里编程，甚至在一个虚拟的谁都不是的脑子里，一个公司的性格里，公司的氛围里编程，这种超级无敌抽象的东西，并没有一个文档，也没有一个形体，既无法学习，也无法观察，只能深入其中去体会，去揣摩，去假设，去求证。
以上就是我，一个自封的流程建设者，这一年以来工作的总结和思考，未免有些自大和自恋，但是真正都是肺腑之言，我希望读者能从中得到启发，也希望一段时间后，自己回望这个时期的经历和想法，能有新的成长。
完。
网友评论