本期大咖：常柱
58 到家技术总监
从事互联网技术研发和管理 10 余年，负责业务&技术中台能力体系的建设和技术团队的管理。
行业竞争激烈，组织效能成核心竞争力。产品经理、设计师、开发工程师是组织执行关键角色，三者的工作及协作效率直接影响组织完成项目的效率。
本期【蓝湖大咖访谈】，有幸邀请到 58 到家的技术总监常柱老师，为大家分享产品、设计、开发如何高效协作，以及高效开发者的工作建议。
时间精力投资法
大家好，我是常柱，现在负责 58 到家业务 & 技术中台的技术团队管理工作。我每天的工作内容包括：
处理团队内外事务性工作
参与各种沟通会议
处理各种突发事项等
除了工作，我还运营个人公众号，坚持周更。我总能按时完成所有计划，是如何做到有条不紊的呢？
在事多的情况下，高效做事是基本。其次是，合理的分配、利用时间。我实践比较有效的方法是时间精力投资法：将精力投资在关键要务之上。
具体的一些策略如下：
✅ 会授权
技术管理每天会接到海量需求，凡事亲力亲为，需求很难按期完成。工作需求要授权给团队内合适的人，重点关注在梯队、通道、流程、原则上，让团队自主运转迭代，依赖团队的力量来成事。
✅ 批处理
分类记录事项，非紧急的小事批量处理，管理好干系人的预期。
✅ 做减法
精力聚焦在核心要务上，不贪多，集中精力做高价值的事情。
我们一天要处理的事情很多，有时还会新增工作，容易扰乱当前计划。真正高效的人，对自身要做的事情都有掌控感，有适合自己的工作系统，高效完成计划。比如，
组织提效的持续建设
个人高效能把事做好，组织也同样。效率是衡量组织价值的一个重要指标，提升组织的效能是每一个负责人最重要的工作。
效能提升是一个系统工程，不可能一蹴而就，需要持续的建设。个人对此的主要思考有以下三点：
✅ 首先，在竞争越来越激烈的这个时代，一定是高效的组织，高效的业务模式，在不断的替代和淘汰低效的组织和模式。组织要跟上时代的步伐发展，需要持续关注效率的提升。
✅ 其次，效率提升是一个系统化的工程，需要结合组织内外两个视角整体思考和行动，才能有效的提升组织效率。
✅ 第三，效率提升需要从内做出改变。改变是反人性的，大部分人都不太愿意接受。管理者需要从组织、绩效，管理等多个维度采取有效的策略，一步步改变组织环境，保障组织的价值和输出效率。
总之，效率提升是组织的核心课题，需要组织内所有角色的关注。上到管理者，下到普通员工，群策群力才能提升组织整体的效率。组织要在做正确的事并将事情做好的基础上，提高效率，更好、更快的达到目标。
产品、设计、研发如何高效协作？
我们的技术团队主要由后端 RD，前端 FE，测试 QA 等专业人员组成，技术团队的上游是产品经理 PM，下游是运维 OP 等。每个角色的工作内容、工作习惯、思维模式都有差异，如何才能高效协作呢？
我们首先要理解分工和协作的本质：分工是提升个体的效能，协作是提升系统的效能。如何提升整个产研系统的效能，个人经验总结为以下四点：
1. 信任为本
信任是打造团队效能的基石，缺乏信任的团队，是无法建立起一个王国的。靠得住的个人成就充满信任的团队，互联网行业节奏快，把精力花在解决问题上而不是形式主义上的靠谱之人，更容易得到团队伙伴的信任。产品、设计、研发之间需要维护彼此的信任账户，通过一次次的成功合作来夯实。
2. 目标一致
团队成员之间要有统一的目标，例如，一体的 OKR（ 即目标与关键成果法，是一套明确和跟踪目标及其完成情况的管理工具和方法），项目制度等。
由目标一致的成员组成的团队，在项目执行、落地时，表现出向心力，极大提升协作效率。
3. 边界清晰
产品、设计、研发的工作都有极强的专业性，专业合作需要有清晰的工作边界，成员要做好自己的工作，不要越界、滥下定论等。
❎ 举个反例：
PM 只提一句话需求：滴滴的这个功能，你照着做一个，会不会？
RD 回复：这个需求太复杂做不了。
此处正确的做法是：
✅ PM 输出有质量的需求，记录在案；
✅ RD 要给出合理的解决方案；
✅ QA 要输出测试用例和报告等。
每个角色做好分内之事，而不是过度干涉他人工作。
4. 标准统一
管理者要明确各个工种的工作产出标准，让上下游对结果有合理的预期，标准之外的非专业人士只能给建议。
例如：
PM 的需求输出标准是什么？
达到什么样的标准才可以让 RD 去做需求评审？
RD 的方案设计达到什么标准才能进入开发阶段？
明确的标准，可以减少团队内很多冲突。
协作是期望达到 1+1>2 的效果，我们需要抓住本质，根据团队具体的情况，采取有效的行动。比如说，产研团队可以借助蓝湖解决沟通、标注。切图难题，让协作更高效。
除了协作效率，影响项目成功的因素还有很多。在项目生命周期中，越往前阶段的输出结果的正确性越重要，要在关键节点上做好控制，提升决策质量。
例如，产品需求的价值和方案评估，技术概要设计评估，发布方案评估等关键节点，我们都要重点关注。
给开发者的高效工作建议
1. 从信息系统思维到业务中台思维
信息系统思维是开发工程师最典型的做事方式，缺点是在迭代较快的系统下，做事效率低，效果差。我建议开发工程师们转至业务中台思维，灵活快速的迭代需求。
什么是业务中台思维呢？
是工程师和架构师思维，重点关注点从数据转向业务领域模型。开发接到需求后，第一件事是抽象业务领域模型和业务的标准流程，再考虑数据的储存和接口设计。
中台思维的核心是闭环和复用。将业务能力 SOP（标准操作程序）化，且能自我闭环。闭环后的 SOP 能力模型才能最大的复用，复用才能降低边界成本，才能产生更大的价值。
例如你和老友聚餐，点了几个美味小菜，下单后，就可以开心聊天啦。餐厅后厨会按其 SOP 的能力，按时交付美食给你享用，而不是上一堆半成品原料，让你自己来动手。
对应业务中台，中台输出给业务的一定是一个极简的可运营的能力，可以快速配置上线运营。而不只是提供一堆 API 给上游业务团队，再由业务研发团队开发系统。
中台思维需要我们有用户思维、系统思维、抽象建模的多种思维模式。对开发者来说，无法解决问题时，不局限于代码层面，从多个维度思考方案。站在用户的立场上，多思考和实践，不断构建和丰富业务模型。
对于个人能力体系，也可以按照中台思维来构建。丰富能力工具箱，就可以做到一个人活成一个团队，高效完成任务。
2. 坚持流程和原则
技术团队经常遇到需求变更的情况，导致项目上线时间延迟，开发作为落地环节，不仅要加班赶工，还要背锅。因此，开发工程师坚持流程和原则很重要。
对于技术团队来说，需求变更是很正常的事情，出问题也很正常。面对问题的处理方式能体现一个团队或个人的担当，是积极的解决问题呢，还是忙着甩锅，这是本质的区别。
作为开发，首先要坚持跟其他部门同事的合作原则：
✅ 承诺即负责，确认、承诺过的需求，就要负责到底。无论过程中出任何问题，都要优先负责解决，而不是忙着去甩锅。
✅ 将事做到明处，如果确定需要变更需求，要全团队一起评估，根据实际情况调整计划。
✅ 对于不合理的需求要学会说不，尽可能的不做需求变更，非核心的需求一律到下个版本迭代。
一个真正好的流程和原则，会明确做事的责、权、利。通过系统规则方式，减少团队之间的摩擦。坚持这些原则，开发环境更好，开发更高效。
3. 避免坏习惯
一个优秀的开发者，首先是一个优秀的合作者和优秀的问题解决者，我们要避免三种不好的习惯，具体如下：
❎ 反馈黑洞
有效的交流是双向的。没理解要及时问，有问题要及时沟通，不能等到最后自己兜不住了再说。职场中提问题不可怕，总成为问题制造者才可怕。
❎ 孤狼
一个人一条枪就能做成事的时代已经过去了，现在要成大事需要与不同的人合作，能整合资源和力量者才是这个时代最厉害的人。技术需要抛开个人英雄主义的幻觉，成为一个优秀的合作者。
❎ 老油条
油腻会伤人害己。年轻人和中年人要避免职场油腻。不喜欢可以选择离开等。
我近两年读书比较杂，从团队管理，思维认知，到心理学都有涉及。最近读到一本有收获的书是迪士尼 CEO 的《一生的旅程：迪士尼 CEO 自述批量打造超级 IP 的经营哲学》，书中有大量关于个人职场成长和公司团队经营等多个维度的原则和经验总结，值得我们每一个人参考学习。
本期【蓝湖大咖访谈】就到这里了，感谢常柱老师的倾情分享。湖湖受益匪浅，你呢？
你有什么问题想请教大咖？欢迎在文章评论区留言~~
用蓝湖，不加班！
蓝湖网址：LanhuApp.com
蓝湖，高效的产品设计协作平台