一些项目管理的思考
|0x00 关于周会和周报
说起周会，可能大多数的团队，都在以流水账的形式汇报自己的工作：A做了什么、B做了什么……以此类推。如果有特殊的情况，则简单说一下，具体的方案也要等到会后讨论了。周报也是类似，我们越来越强调周报要“简单”、“简短”，背后也是不希望再以流水账的形式说自己做了什么，久而久之，不仅写的人疲惫，看的人也没什么兴趣在周报上面了，只会复制粘贴一下重点，然后继续发团队周报。
这其实是一个不太好的趋势，那就是团队的工作越来越业务化了，每个人都在从事自己的事情，自然就谈不上团队中的“横向互动”。对于技术团队来说，尤其是做数据的技术团队，如果越来越没有技术的感觉，那么不仅周会周报流于形式，技术人员的成长性和发展性，也很难继续搞下去。
周会和周报的目的，其实在于技术上的协同：技术风险、最新行业情况、CodeReview、干货分享等等。其实如果换个形式，让大家自由讲述工作中的困惑，或者是一些未来发展的探讨，那么气氛可能立刻就不一样了。周会和周报有必要吗？肯定是有的，但不定期的技术分享&自我批评，提醒团队成员改进不合理的地方，营造开诚布公、透明的团队氛围，才是周会周报形式的核心。
|0x01 关于团队协作
团队协作中，最怕的是“将就”。“将就”对技术团队，尤其是数据技术团队来说，是一种非常不利于成长和发展的事情。很难想象一个没有技术追求的团队，能开发出一个健壮的、可维护性好、可扩展性好的数据模型。久而久之，曾经埋下的坑，都要一个一个填上，团队的发展速度，在泥泞的“坑”中，只会越走越慢。
很多工作是需要跨团队组织的，我们必须要承认这点；但跨团队组织就一定存在不合理的地方，我们同样需要承认这点。对于一线工程师而言，团队协作的难点是最清楚的，必须要鼓励大家提出解决问题的方案，简单写写PRD也好、写一段文字描述也罢，总之要把自己的想法说清楚。大部分情况下，一线工程师如果能说清楚的事情，推广起来也就不那么难了。如果方案合理可落地，那么剩下的工作就需要交给主管去协调，或者是开发资源遇到了瓶颈，也需要主管去协调。如果一堆大头兵在相互协调资源，很难想象这个团队会解决什么实质性的问题。
|0x02 关于风险管理
最近公司一直在提倡Leader来写代码，虽然评价不一，但确实在某种程度上反映了Leader有些脱离技术的现实。因为很多时候，仅仅协调资源是不够的，能够深入到系统中、深入到技术细节中，带来技术上实实在在改变的Leader，同样非常重要。
风险管理，就立足如此。当前部门的技术栈如何、开发-线上流程有无问题、数据质量监控做的怎么样、出了问题能不能及时定位和查清楚原因？方方面面的情况，非常考验一个Leader的风险意识，以及团队责任心。
什么样的团队是好的团队？有很强凝聚力，目标一致，每个人都有较高积极性投入工作，能够在分工中发挥各自优势和潜力，这就是好的团队。而未雨绸缪、提前识别项目中的技术风险，协调研发资源投入项目，及时消除技术风险，这就是好的风险管理动作。
|0x03 关于文档撰写
业务做的久了，很多同学就非常排斥写文档了，因为这只会拖慢工作的速度，影响自己的产出，这很现实。小团队可以这样，但人数一旦多了起来，通过口口相传，或者是定期的培训，就已经不足以快速的共享和传播知识了。而在每个项目结束后，及时把工作内容沉淀到文档上，或者是公共平台上，就显得非常有必要。
并不一定说这是强制的工作，只能提倡把文档沉淀的时间也加入到项目排期中。对于管理者，可以随时了解技术和项目的细节，补足宏观思考的漏洞；对于开发者，能够快速了解项目的背景、过程、风险及应对。“一个人很强”，只代表了个人的战斗力；“整个团队很强”，才是真的强。
|0x04 关于价值观和沟通
阿里总是在各种场合强调价值观，不少人有负面的看法，但价值观的本意，是传达一种“建国理念”。很多非阿里人，来到阿里后，通常会有一种非常不适应的感觉，似乎一件事情，从头到尾，都要自己负责，非常的“不专业”。其实，对于一个公司而言，做大了，内部的管理，就是一定是个不小的问题。对于价值观产生比较负面看法，也是站在行业通识的角度上进行评价，而非深入到企业发展的核心。
价值观的本意，是在传达一种“建国理念”，阿里是一家市场化思路主导的公司，而非计划经济主导。在对内的管理上，提倡员工激发主观能动性，通过个人的能力，来寻找更多志同道合的人，来做一些有价值的事情。换句话说，虽然我们在阿里这家大公司里，但我们的部门，本质上仍是一个创业部门，阿里公司本身，就是一个封闭的小市场。
在市场化的创业环境中，沟通、干练，非常重要，所以要以价值观的形式传达下去。
很多工程师被提拔到管理岗后，依然喜欢撸起袖子自己干，而不是指导员工解决问题，其实本质就是给自己留退路：干不好管理，还可以回来做一线工程师。但如果学不会放手，就学不会新的技能：技术前瞻性和技术广度，很快你自己就会成为团队的天花板。有时候“背水一战”是对管理者的最好的鞭策。
|0x05 关于CR和故障
作为技术团队，代码写的好不好，风格是不是统一了起来，注释是否完整，CR机制是否完善，故障管理是否畅通，直接决定了我们的工作效率。由于很多细节工作交给了一线员工，所以管理者可能没有办法了解每一个技术细节，因此需要经常和员工们进行沟通，指导写代码的风格，但是这里要强调是指导，而不是命令和安排。
CR和故障管理，看起来是孤立的工作，业务压力大的时候，往往成为累赘。但是这个过程不走，就无法真的掌握一线代码的运行情况，给未来的维护，埋下种种多的坑。
|0xFF 管理从来都不是一件比写代码简单的事
是的，管理从来都不是一件比写代码简单的事。
很多人，能力很强，做事也非常棒，但到了晋升的时候，往往被卡住，认为组织对自己不公平。但如果看晋升的规则，大体就是两点：技术能力可以跨部门复用，或者是能够领导部门内的重点项目。再总结一下，就是你要能把自己的能力推广给其他人，而不仅仅是自己强。
把合适的人安排在合适的位置，公司的发展因人成事，“授之以鱼不如授之以渔”。
管理也是一种学问：如何面对负面情绪、如何调动团队氛围、如何指导部门技术发展、如何为部门寻找更多的资源支持…… 归根结底，就是如何带领部门走的更远。就像写代码一样，如果不是从小事一点一滴的积累，如果不是夜夜反思自己刻苦读书，如果不是经常寻找同行交流内心的困扰，如果不是经过实战从而“知行合一”的话，晋升的一点小问题，终会变成职业生涯的大事情。