在之前设计Scrum考核制度的时候,发现一个很难解决的问题,就是前后端分离的团队,想要准确量化“后端”、“前端”和“测试”的工作量,达成共识的故事点非常难。
产品的需求有时候后端改动比较多,有时候前端改动比较多。所以前后端成员针对一个完整的产品需求是有不同的故事点认知的。有时候代码改动不多,但是涉及面非常广,测试人员回归测试就比较难。前端、后端、测试三个维度的认知不同,就导致故事点无法达成统一。
在之前设计Scrum考核制度的时候,发现一个很难解决的问题,就是前后端分离的团队,想要准确量化“后端”、“前端”和“测试”的工作量,达成共识的故事点非常难。
产品的需求有时候后端改动比较多,有时候前端改动比较多。所以前后端成员针对一个完整的产品需求是有不同的故事点认知的。有时候代码改动不多,但是涉及面非常广,测试人员回归测试就比较难。前端、后端、测试三个维度的认知不同,就导致故事点无法达成统一。
在微服务架构中,服务除了要更新自身的本地数据存储,有时候还需要通知其他服务发生了数据变更。Outbox(外写)模式 就是一种能让服务以安全、一致的方式完成这两项任务的方法。它保证源服务(source service)具有“读你自己的写”(read-your-own-writes)语义,同时实现跨服务边界的可靠、最终一致的数据传播。
更新(2019 年 9 月 13 日):为了简化 outbox 模式的使用,Debezium 现在提供了一个现成可用的 SMT(单消息转换器)用于路由 outbox 事件。本文中所讨论的自定义 SMT 已不再是必需的。
在公司管理的时候碰到一个非常棘手的问题,Scrum管理制度设计了,但是公司没有产品发展的战略方向和能够持续造血的商业模式。
所以我最近在思考“经营”和“管理”哪个更重要?
现代管理学之父彼得·德鲁克说过:“效率是‘以正确的方式做事’,而效能是‘做正确的事’”。
“做正确的事”就是经营方向,“正确的做事”就是管理制度。
这和之前的激励机制是一体两面。
激励机制是“力”的来源,管理制度是“力”的传导结构,经营理念是“力”的方向。
没有力,再好的结构也推不动;力的方向错了,结构越精巧,跑得越偏。
| 维度 | 经营 | 管理 |
|---|---|---|
| 核心目标 | 创造价值、赢得市场、实现增长 | 提高效率、降低风险、保证秩序 |
| 关注重点 | “做正确的事” | “正确地做事” |
| 典型活动 | 战略制定、商业模式、市场布局、品牌建设、创新 | 计划、组织、制度、流程、考核、控制 |
| 时间维度 | 面向未来、战略性 | 面向当下、执行性 |
| 主导角色 | 企业家、老板、董事长 | 管理者、总经理、中层干部 |
之前在Scrum敏捷管理制度设计一文中,针对公司存在的诸多问题,基于scrum设计了一套产研管理制度。并在最后给出了产研团队量化考核的指标。
但是这套制度如果没有实际落地的绩效激励制度,那就是空中楼阁。
马云曾说过:十个人的公司、一百人的公司、五百人的公司、一千人的公司和一万人的公司, 带队伍的方法是完全不一样的, 但管理的最低要求是一致的。这个最低要求就是十六个字:⽬标清晰,职责明确,赏罚分明,超越伯乐。
其中呢赏罚分明就需要考验公司激励制度如何设计。激励如果不能引起团队其他人的眼红,那这个激励是无效的;惩罚如果不痛不痒不能震慑团队中其他同类型的人,那这个惩罚也是无效的。
但是在赏罚分明的同时如何保证团队的凝聚力,这又是一个管理的重大大挑战。

你有没有想过AI到底是怎样推理的?这篇文章将带领读者钻进AI的大脑,把它的思考过程一层一层的剥开,让你彻底的搞明白它的那些惊艳的答案到底是通过严密的推理一步一步推导出来的,还是像复读机一样从它以前背过的内容里抄过来的。
这篇文章的内容来自于谷歌DeepMind团队的首席科学家Denny Zhou在斯坦福大学CS25 《Transformers United V5》课程中的讲座。相信通过这篇文章的讲解,你将对AI的理解和使用方式都会发生根本性的改变,你会彻底搞懂为什么AI会一本正经的胡说八道,你会发现其实AI根本没有你想象的那么聪明,但是也没有你想象的那么笨。