本周工作思考
- WEB团队组织能力建设的思考
- 我是UMU土生土长的团队负责人，我之前的工作履历也没有团队负责人角色的经验，最多时是组长的角色，但是随着UMU的发展逐渐从开发人员成长为团队负责人，这个角色需要担当更多的责任和义务，在公司和伙伴们的支持下，随着经验的增多，踩过坑，摸过石头，很多事情就会汇总在我的脑海里形成一个主题，研发团队的组织能力如何建设和持续改善，这个主题是很多行动和架构设计的暗线，但是结合公司的发展需求，我现在的理解还是远远不够的，通过持续的学习，思考和实践，最终要形成完整适合我们自己发展的执行框架和方法论，积极助力公司级的业务和Web团队的人效提升；
- 坦白说，我还没有系统性的学习过如何做团队管理，所以一些方式不够科学，我觉得任何工程师不管是不是团队负责人，都应该比较系统学习团队管理的相关内容，我想这也是东朔老师推荐大家阅读《精简管理学》的初衷， 因为我们每个人都身处团队中，需要协作才能有产出结果， 如何有效的协作，如何科学的管理自己，如何科学的管理目标和计划，使用科学的方法成为团队中更有效更有价值的一分子。
- 对于团队建设过程，足球队训练踢球赛，战争中的战斗过程，散沙成石都是我常常使用的适用于团队建设一个思考模型，当我遇到要跳出舒适圈的才能解决的问题时，我常常用散沙成石的隐喻作为自我反思的楔子，就是要解决如何将一盘散沙如何化成一块坚硬的石头的过程。从物理的角度思考，一盘散沙化成一块石头，我们有很多种办法，比如使用石灰混凝，使用高压压轧，使用高炉冶炼等等，甚至我们可以用一个铁皮容器把沙子包裹起来，我想的最多的是高炉冶炼，这个是物理变化和化学变化的过程，还能形成铁疙瘩核心。首先除去其它杂质，然后经破碎，磨粉，送入高炉冶炼烧结成块，然后冷却，一块人造石就形成了，中间加入不同的材料和流程还会形成特殊用途的材料。沙子成为石头的一部分，要千锤百炼，如果石头成为沙子，柔柔的风，软软的水就可以做到。遇到一些难解的问题，我常常想到这个隐喻帮助我梳理一下思路，对于团队我觉得就需要百炼成钢，百炼成石，以这样的心态和勇气去制定组织建设的目标才能获得长期价值，这样才能锻炼了团队，又比较好的实现短期阶段的业务需求；
- 日常工作上，Web组的团队组织能力建设的长期工作思路是：目标引导，价值观激励，规范驱动过程，数字化评估呈现结果。说的具体点就是结合公司的经营理念和目标，公司方向决定团队目标制定，公司价值观和绩效体系激励团队氛围和干劲，研发规范驱动开发过程，数字化思维呈现研发产出结果并据数据做出评估，组织能力就是构建自驱动自我完善的持续发展的能力。 组织的发展和具体的人没有太大的关系，只和角色有关系，对应的角色承担起了对应的职责，这个组织就会良好运行，而不必关注承担角色的具体的人是谁，对组织我们需要这种可以自运行的能力和架构，对于个人，需要具有承担某个角色责任的能力，同时具备能够快速识别角色和人是否匹配，角色和组织是否匹配的能力，以此来推动完善人才招聘，人才培育，人才淘选等过程；具体来说，
- 团队和个人OKR必须和公司的OKR保持一致，以团队为基线制定个人的工作目标和发展目标，目标确定了，做好计划，到点交卷，团队和团队伙伴们在达成目标的方法和方式要遵守一定的开发规范和原则指导，其他的就可以八仙过海各显神通，充分尊重和挖掘每位伙伴的的自由性，主动性和创新性
- 价值观是推动的工作的底层逻辑，是我们制定结果标准和要求的依据。 公司在求生存和求发展过程中逐渐沉淀形成了自己的价值观，我们必须具备这个价值观自信，这些价值观是推动公司发展的重要因素之一。这些价值观会细化成我们对具体工作的要求和标准，比如我们很多新伙伴会问，我们为什么在很多协作工具里都是实名的，甚至微信里都是实名，为什么头像都是自己头像，我们为什么称呼彼此为伙伴，为什么我们有周报日周，福利制度为何这么设计，绩效制度为何这么设计等等，这些公司也在持续优化，但是这些事情的背后思考是公司的价值观和愿景的具体化，如果对价值观的底层逻辑思考清楚了，就会非常理解很多设计的必要性和合理性了；
- 开发过程，工作过程需要研发规范的指导，过程需要可观测， 需要适当的反馈和监控，规范可以保证让任何细小的工作都在正确的轨道上被完成， 适当的反馈和无感知的监控可以及时纠偏和推动目标达成，规范必须是公开可操作的，规范上的节点就是重要的观测节点，比如开发重点项目，开发任务完成时， 提测时，提多语时都是一些关键的规范和节点，这些节点需要被观测到。对于bug的修复，什么时候创建的，复现情况，修复情况，如何被引起的，影响了什么，设计改善，架构过程，业务沉淀，组件沉淀，性能改善这些也都是重要的可观测节点；
- 数字化呈现结果，研发一个过程，结果不是最终的状态，在理想状态下，可以通过成成观测任何一个时间点结果，在实际开发里，我们看重关键节点的结果呈现，结果评估尽量使用相对客观的结果呈现影响评估的判断，尽量避免使用主观的观察影响评估的判断。结果需要具有数字化呈现的能力，比如重点项目上线了，是一个结果，那对组织来说还需要知道更细化成本，质量，范围，目标的结果，需求范围和开发范围的覆盖度是多少，开发阶段分解任务的完成和计划的执行情况如何，测试阶段bug创建和bug修复的响度度如何等等，架构优缺点，设计优缺点，组件设计是否合理，技术项目的收益如何等这些关键的数字指标，可以我们可以直观的评估项目的现在收益和未来价值
- 以上的长期的工作需要经年累月的的持续的建设和发展，而且对我们来说也必定是挑战极多，但是对于做SaaS我们来说，已经深入行业沉淀多年，有些是适环境而变，有些必须沉下心来坚持做的。这些挑战需要逐个点突破，但就短期来说，Web组的关键目标就是4个：重点项目质量越高越好，优化点做的越多越好，bug修复越及时越好，技术项目越扎实越好
- 重点项目是创造价值的重要体现，重点项目中的功能被用户使用需要一定的时间，一个面向未来的开发，提高线上服务的质量，必须保证未来使用的功能是稳定可靠的，所以保证重点项目的质量是保证了未来可售卖服务的可靠性，具体表现上，这个质量包括2个方面，1是代码质量，2是功能质量，代码质量要保证编码，设计，架构，可维护性，可迭代性等方面的要求，功能质量要保证业务逻辑，UE/UI设计符合产品需求，相关功能和数据得到合理的衔接，保证功能的合理良好的用户体验和视觉体验，减少线上bug的发生，规避线上事故的发现。
- 重点项目的质量有目前主要关注提测质量，具体来说是测试阶段的bug相关的数据，比如修改及时率，当日bug修复，次日bug修复，N天bug占有率，P级别bug分类情况，这些信号可以反馈开发中的一些客观情况，比如N天bug占有率的大小可以反应了项目上的技术难度和开发时的设计的好坏，一般而言设计阶段做的好的话，在修改及时率比较好的情况下，N天bug占有率会非常小，技术难度比较大的话，也会导致N天bug占有率会非常高；
- 今后一阶段会持续完善代码质量的规范和数字化结果呈现，比如继续完善内部技术讨论评审规范，通过重点项目任务分解数及计划执行符合度这类指标来反应设计的情况；
- 另外重点项目后续优化点的难易程度来评估重点项目设计优劣程度，通过线上bug的出现量反馈到重点项目的开发质量，通过对重点项目的事后评估驱动大家增强对当前重点项目的开发质量的意识；
- 另外一个持续落实的技术主题是降低技术复杂性，增加业务聚合性，技术复杂性是我们后续迭代困难和产生线上bug的重要因素，产生复杂性的原因很多，包括多重依赖，晦涩的复用，隐晦的业务逻辑实现，没有合理的设计等等；在实际开发中，大家往往重视技术实现，忽略了业务架构的设计和业务思想的传承迭代， 如果更好的设计业务逻辑的实现，如何设计业务逻辑和交互逻辑的关系，如何设计和实现更容易更容易迭代的业务模型，这些都是我们非常重要的技术课题， 重点项目往往一个架构的搭建，一个设计思考的考试，很多优化点，bug，甚至后续迭的重点项目都是以一个重点项目的设计为基础，这个也是我们重视重点项目代码质量的一个重要原因；
- 优化点主要是对当前功能的完善和价值增值，这个目标上主要追求数量，数量越多，即可以短期内迅速增加服务的价值，直接的促进续费率的提升
- 优化点在web侧未来一个阶段要做好数量统计的结果展示，包括优化点响应时间，开发时间，bug量等；
- 另外对优化点按照项目规模，技术难易度，业务复杂度做一定的分级，比如A类优化点是规模较大，技术难度较大， 复杂度较大的优化点，B类优化点是规模适中，难度适中，复杂度适中的，C类是规模较小，难度较小，复杂度较小的，通过合理的分类，可以实现更合理的任务安排和结果评估
- Bug修复越及时越好，部分前端伙伴意识不到，这个其实有4层意思，1是发现越及时越好，2是解决上线越及时越好， 出现bug既然已经是客观事实，我们唯有快速解决才能有希望挽回损失，3是快速的解决提测，还要及时推动测试上线，4是上线后及时反馈给客户；
- Web组已经完成bug当月清的开发规范并已执行2个月
- 今后一段时间，会针对线上bug的及时修复率和及时上线率做统计，也就是从bug创建到bug修复提测，从提测到上线用了多久的时间；充分利用和扩展现有的线上可观测体系，比如kibana，rum等早些发现线上问题，这些我们会逐渐形成操作指南，落实到值班操作手册里执行；
- Bug修复及时率会对重点项目的排期造成一定的干扰，这其实我们必须要面对的挑战和要解决的项目管理的难题，但这绝对不是重点项目做不好的借口
- 技术项目我们不图快，不图及时，不图多，但求扎实可靠，绝大部分技术项目的立项是研究再研究，衡量再衡量之后的决定，一旦要做，它的重要性和紧迫性是不言自明的，所以务求扎扎实实的收益。坚决秉持要么不做，做就做到最好的原则。
- 前端技术项目要走重点项目的流程，并且增加多轮技术评审
- Web组的组织能力建设具体有四个方向，1是工程化能力的建设，2是开发流程规范体系的建设，3是团队文化的建设，4是执行过程和产出结果呈现的体系建设；
- 工程化能力建设是研发团队组织能力建设的核心支撑，如果研发团队没有一定的工程化能力，那么组织能力基本上约等于0。 研发开发规范，团队文化建设，结果呈现体系的最后落地点都体现的工程化建设上；
- 工程化能力是人效提升，组织效能提升的关键，开发过程中个人都有效率的天花板，但是如果合适的工具，流畅的线上流程，丰富的自动化，团队中的每个人的效率都会有质的提升；
- 工程化具体落实在三化上，流程化，工具化，自动化，而且这些都是组织人效提升的利器；
- 研发规范上，经过近2年的实践，研发侧从需求开始，开发，上线都存在唯一的版本号，当时和段君设计这个统一版本号，实际是期望在未来能够通过这ID，提取该任务下所有action， 其实现在所有任务过程都可以列举出来，基本具备了一定的数据支撑，只是分散在不同的系统里，但是可以基于此做一些数据化的呈现， 要在未来很长一段时间内要把需求，开发，测试，上线在线上连起来，就意味着asana，gitlab，vscode，jenkins等工具连接起来，未来一段时间还是继续完善和增加部分研发规范，我曾经总结过一个重点项目前端开发工程师要有大概20个左右的过程需要做好，包括：
- Kickoff及需求分析的过程
- 项目组形成和任务分配过程
- 技术设计及排期过程
- 设计及评审过程
- UI评审过程
- API设计评审过程
- 代码开发过程
- 多语翻译及回填过程
- UI Review过程
- 测试用例评审
- 测试及问题修复过程
- 联调过程
- 自测及提测过程
- 交互Review及细节明确过程
- Code Review及 Merge Request过程
- Web上线过程
- 上线后Log监控过程
- 上线后的优化点过程
- NPM提交及发版过程
- 项目复盘的过程
- 这些过程是一个重点项目中必经的过程，资深的伙伴已经把这些过程内化在习惯里，形成了属于自己的重点项目开发方法论，很多过程顺其自然的完成了。有些过程是重叠的，有些过程花费时间比较长，但是如果任何一个过程都可能出现对应的问题，研发伙伴在面对这些同一类常规问题时，应该用同一类的解决办法，然后逐渐提升这类解决办法的实践经验和工程化水平，比如多语翻译及回填过程，NPM提交及发版过程，Code Review及 Merge Request过程，Log监控过程等都可以自动化或者工具化；
- 工具化上，针对具体的技术，nodejs，typescript，webpack都是重要的工程化内容，nodejs，typescript完成了基本的升级操作，编译构建上结合Monorepo的建设也会升级，提升整个基础设施的基础平台，Monorepo的建设也更适合10人左右的让小团队的开发更加敏捷；
- Angularjs的存在目前已经严重割裂了React业务和Angularjs的耦合，开发效率上有较大的影响，甚至影响到了业务逻辑的实现，我们会在未来2年内逐渐移除Angularjs技术。同时这个也是一个宝贵的经验，技术栈要随着技术发展不断迭代升级，否则是钝刀子割肉，眼睁睁看着效率不高却没法快速提升。
- 另外工具这块我们也会逐渐增加新工具的建设，比如i18n工具，vscode开发工具，cli开发工具，最终的目标是形成开发工具链，从创建分支，创建组件，创建页面，开发调试，部署提测，接口类型化，模板代码生成 都可以同一个cli解决，业务工程师的core job会主要关注业务逻辑和交互逻辑的开发，平台工程师会专注工程化能力提升，业务工程师和平台工程师分工协作共用推进组织效能的提升
- 在实际开发中，团队鼓励大家开发提高效率的小工具和新技术，倡导前端工程师积极的聪明的“偷懒”，有意识的利用工具提高效率，利用自动化省去重复要做的事，也鼓励大家积极分享自己开发的工具，分享自己学习研究的新技术，建设团队开发工具库，积极探索新技术；
- 团队文化的建设需要落实到对具体的行动的要求和标准上
- 比如对“求真务实”这个价值观，资深的工程师对于新人不应说，我们要“求真务实”，这个就很虚，我们要实实在在告诉新人我们的困难，我们的技术上的坑，我们的槽点，我们正在做的努力，code review时客观的有啥说，不要吹毛求疵，为了review而review等等，价值观体现在细节上
- 另外每一位Web端资深工程师都是价值观的代言人，以身作则，比千言万语有效一万倍
- 大家遇到问题时也要想想价值观，这是我们做决策的根本立场，保证我们在对的方向上思考
- 产出结果数字化呈现
- 数字通常都是比较有好的思考后的抽象，虽然不是绝对客观，绝对是最大程度上的相对客观，比如说一工作结果很好，我觉得就不如说，如果我的期望是1，这个结果是1.2，这个多出的0.2在于额外完成了2项xxx工作，当然这数据需要这个工作的过程是可以被观测的，这个也是工程化的方向之一
- 在日常工作中1个方向是，通过细化流程规范，伙伴们要在关键的节点留下一定的数据，比如在task的评论里或者周报日报里，或者slack里，说明：这个项目是为了优化弹窗的样式，但是之前那个弹窗存在几个不足，我就花时间开发了一个新的，它的优点是xxxx，缺点是xxxx；当然最好开发之前和我说下；
- 另一个方向是工具化支撑，目前wiki，asana，gitlab，Jenkins都提供了API方法，针对我们关注的数据指标可以用一些工具提取一部分数据做做一些时间的数据分析，有些很简单，简单的几个脚本就可以提取到很有效的数据，只是这些脚本需要慢慢积累，每周搞一个，一段时间下来基本上就够用了
- 最重要的是通过这些措施，让WEB端伙伴们建立数字化的意识，关注自己的工作方式和工作目标，持续改善工作效率，有意识的用数字化的思维思考自己的工作，我们的工作足够复杂和多变，必须梳理自己的工作思路，有条理，有目标，有计划的的开展工作，而不是乱做一气，也不是胡子眉毛一起抓。联系到我们的业务，我们通过数字化学习赋能客户，这个理念也同样适用我们。