Category: 管理智慧

英文书名是《Creating Magic》，亚马逊上有1355条书评，总分4.7，相当高。而豆瓣只有一条傲慢的短评“看目录就好了”，还只给了一星。反差巨大，于是我花了一下午读完。结果发现这是一本好书，在国内显然被埋没了，无人知晓，可能是豆瓣没有此书的文字介绍。我给豆瓣提交了补充材料，希望更多的企业管理者能读到此书并从中受益。

下面是我摘抄的一些总结性建议或经验，要读详实案例，还得看书。

策略一：重视员工，否则他会成为别人的左膀右臂

• *不断询问自己，向大家说明你在“每个人都很重要并且知道自己很重要”这一方面做了哪些努力。
• * 创造这样使得所有员工和客户都能感到自己很特别的环境。
• * 把所有人都当作独立个体对待。
• * 给予每个人彻底的、无条件的尊重。
• * 花时间去熟悉你手下的员工们。
• * 为每一位员工学习所需知识和必要技能提供信息和资源。
• * 确确实实让所有团队成员都能见得着你。
• * 无论员工职位高低，都要给他被倾听的机会。
• * 当有人同你交谈时，集中注意力并真诚地倾听。
• * 做真实的自己，不要展现出虚伪的形象。

策略二：打破常规，关键岗位用对员工

• *你不在公司的时候，企业照常顺利运行。
• *员工的义务、责任和权利界限清晰。
• *能快速高效地做出决策。
• *不同层级之间信息沟通顺畅。
• *相关人员能迅速给予回复。 如果出现以下情况，说明当前的组织架构不合适了：
  1. *员工抱怨浪费时间、分工不明确、信息传递不畅。
  2. *过多人参与每一个决策。
  3. *企业内部“藏着”工作效率不高的员工。
  4. *每个经理的直接下属过多或过少。
  5. *会议时间过长、次数过频或收效甚微。

策略三：员工才是企业最闪耀的品牌，而老板不是

• * 确保应聘公司职位的候选人具备完成本职工作所需的技术、管理和领导能力。
• * 在你开始招聘新员工或者在公司内部提拔员工之前，想一想一个完美人选到底应该是什么样的。
• * 根据才能而非简历选人。
• * 对于各项工作要选择最佳员工，而不是在现有人选当中挑最好的。
• * 对于准员工能否融入现有的工作团队这个问题要仔细考虑。
• * 让工作团队中的各级成员参与到对应聘者的面试和选拔的过程中。
• * 适时采用结构化的面试方法。
• * 向求职者问一些需要深入思考而不是用“是”或“否”就能回答的问题。
• * 对于那些曾经与求职者共事或者在求职者手下工作过的人，要多多与他们进行深入而广泛的交谈。
• * 观察一下职位候选人当前正在做的工作或者当前正在经营的业务。
• * 要考查求职者的知识，如果可能的话，让他们展示出他们的专长。
• * 勇于做出辞退或者重新安置不适合当前工作但是富有才干的员工的艰难决定。

策略四：培养自己的员工，这才是核心竞争力

• * 确保每一位员工都深受公司文化的熏陶。
• * 清晰明了地表述公司的价值观与使命，并确保每一位员工都理解其内涵。
• * 将宗旨意识输入全公司上上下下的所有员工心中。
• * 认真履行你作为教师、教练和咨询顾问的责任。
• * 教会员工掌握岗位所需的技术知识，并教他们如何提供超出客户预期的服务。
• * 培训员工做好类似“抓住5分钟机会”和梦幻时刻的事情。
• * 清楚地说明每一位员工的工作都会影响客户的满意度。
• * 创造多种方式定期与你的员工进行沟通。
• * 快速有效地回应员工的行为。
• * 确保每一位员工都知道你对他们的期望。
• * 定期考核员工的知识与技能掌握情况。
• * 切记，你无时无刻不在对员工进行着言传身教。

策略五：锻炼员工，绝对不是让困难压跑员工

• * 当出现问题时，务必先找流程机制上的瑕疵，而不是责怪他人。
• * 不断地鉴别客户和员工遇到的麻烦事，并通过流程机制改革来消除麻烦。
• * 让一线员工帮忙识别分析影响客户满意度或妨碍员工完成任务的工作流程障碍。
• * 询问客户哪些工作流程给他们造成了麻烦，他们喜欢或者不喜欢哪些业务流程。
• * 亲自打电话给对公司不满意的客户，了解工作流程中所出现的问题的第一手详细信息。
• * 将最新技术和相关研究成果运用到你的流程机制中。
• * 确保工作流程机制落实到位，并在问题出现之前做好相关准备。
• * 请管理好自己的时间以消除你个人工作生活中的麻烦。
• * 新的工作流程试运行3~6个月以后，检查一下看看是否能够行得通。
• * 经常问问自己：“我们为什么要用那种方式做？”
• * 探索一下怎样改革工作流程，才能使你更有时间指导、忠告、培训员工。
• * 寻找能使你的经理们有更多的时间与客户在一起的工作流程。
• * 问问自己：“最近30天里我形成了多少关于流程改进的想法和建议？我跟踪了多少呢？”
• * 时常检验员工对当前的工作流程和经营指导方针的理解支持程度如何。

策略六：愿意了解真相的领导，才能留得住员工

• * 每天，特别是一天刚开始的时候，到员工工作区和客户区中转转。
• * 在工作场所让员工和客户都能找到你。
• * 定期从客户及员工的角度体验公司的运营情况。
• * 努力探寻在工作场所与每个人都建立轻松自在关系的方法。
• * 经常出去走动走动，使员工时刻能接触到你。
• * 定期与直接下属交流，讨论与4个P——员工（People）、流程（Processes）、方案（Projects）和利润（Profit）的相关问题。
• * 经常举办研讨会，让员工能够告诉你公司的实际进展情况。
• * 从员工告诉你的信息中挖掘他们的真实想法。
• * 落实员工分享给你的每个创意和关注点，务必信守诺言。
• * 向员工表明你对他们的关心、重视、尊重、体贴，并表明你能保守秘密。
• * 询问你的经理及一线员工他们在权衡什么。
• * 往深处挖掘信息，直到你掌握全部实情。

策略七：请仰视你的员工，他们不是打工仔

• * 与你的员工和直接下属们共度有意义的时光。
• * 参加并出席员工的活动。
• * 记住员工的姓名并向他们说声谢谢。
• * 向你所接触到的每一个人表示问候。
• * 请意识到你的存在和你与员工进行互动交流所产生的影响。
• * 找到庆祝员工个人成就和胜利的方式，同时不要忘记向他们的家人、朋友和亲人表示祝贺。
• * 衣服口袋里随身携带几枚奖章，用于向员工表示认可。
• * 当员工做出正确的事情时，一定要确保让他知道。
• * 经常性地关注员工的行为表现。正面也好，负面也罢，都要迅速做出回应。
• * 当场指导和培训员工以更好的方式完成工作。
• * 不要容忍员工的不良表现或是忽视员工工作绩效方面的问题。
• * 对员工的进步和出色的表现进行公开和私下的认可。
• * 训练你的团队去了解什么是看起来出色的工作表现。
• * 使用日常工作计划来提醒自己每天都要向员工表示欣赏、认同和鼓励。
• * 多说鼓舞人心的词语，使员工拥有被尊重的感觉。

策略八：创造领先条件，让员工更有归属感

• * 紧跟当前行业、企业、文化和社会发展趋势。
• * 发现最前沿的服务和产品。
• * 亲自体验最好的服务和最好的产品，反思你的亲身体验并据此采取行动。
• * 进行“最佳实践的旅行”——向那些名声在外的公司学习。
• * 去参加合适的会议、阅读合适的杂志、认识合适的人士，紧跟你所在行业的发展变化。
• * 建立强有力的职业关系，去结识专家并与他们多保持联系。
• * 践行你自己的“客户至上学”，找到使客户满意的方法。
• * 经常询问你的员工公司可以在哪些方面做得更好。
• * 扩大你的参照系，抓住每一次机会尝试新事物。
• * 多在网上搜索信息，以激发新的创意。
• * 以积极进取的方式收集竞争对手的服务和产品的相关信息。
• * 鼓励团队成员时常关注他们职责以内和职责以外的事情，并公开肯定他们的贡献。

策略九：领导说者无意，但员工听者有心

• * 总是表现出激情和责任心。
• * 每天兴致高涨地去上班，用你的激情去感染你的员工。
• * 花合适的时间在工作上，用合适的方式做合适的事情。
• * 保持积极的态度，并用积极的态度感染他人。
• * 建立牢固的合作伙伴关系，并且在你的合作伙伴需要你时总是及时出现。
• * 设定高标准，并努力达到你自己设定的标准。
• * 通过你的行为举止、外表穿着和周围环境给外界留下好的印象。
• * 探索为员工打破单调乏味和千篇一律的工作方法。
• * 努力使对手成为合作伙伴，并且总是主动迈出第一步。
• * 解决问题的时候注重合作而不是冲突。
• * 明白何时站到一边并让他人领导。
• * 做专业化素养方面的行为榜样。切记，你经常站在舞台上，请表现良好！

策略十：人格魅力，才是吸引员工最大的“磁铁”

• * 知道你自己的价值主张，并且每时每刻都去践行这些价值主张。
• * 请记住：只有当员工确信你对他们尽心尽力后，他们才会为你全力以赴。
• * 始终坚持说实话，编造和篡改事实只会造成不信任。
• * 对每个人都要热心、敏感和尊重，即使你是在指导或者忠告他们时。坚强的领导者是不屈不挠的人而不是冷酷的人。
• * 千万不要羞辱任何人。你没有这样的权力。
• * 千万不要伤害别人的自尊和自信。谁也没有权力这样做。
• * 有勇气坚持正确的事情。
• * 决不做任何违法或接近违法的事情，也决不让你的员工这么做。
• * 坦率地对待所有人，并鼓励他们也坦率地对你。
• * 创造多样化的工作环境，并尊重你周围每个人的差异性。
• * 学会放松和娱乐，并鼓励你的团队也这样做。
• * 确保你领导的每一位员工都明白公司的价值观，并教会他们遵循这些价值理念。
• * 切记领导者的影响力是建立在你的人格魅力的基础上的，假如你人格魅力不足，你离开之后也很难留下任何影响。

这个问题从来没有一个简单的答案。它俩其实都是成功必不可少的条件，缺一不可。方向的本质是战略，努力的本质是执行力，这二者天生缺一不可。再好的战略，没有执行力，无法落地都是白搭。没有好的战略，管理规范严谨，团队拼死努力，也很大程度是在错误的道路上越错越远，最后穷死。

要制定正确的战略，根本问题在于核心技术与客户市场的紧密结合（这里不讨论各种低技术含量、贸易型、皮包型公司）。核心技术总是掌握在人的手中，所以不重视人才的公司注定失败。决定客户和市场的因素更多。不是所有的客户都是上帝，尤其在经济不景气或行业下行的情况下，有钱且商誉良好的客户才是上帝。

能带来执行力的是公司文化与价值观，其核心体现为以激励和分配制度为代表的公司管理制度。而这些，本质上都会是一把手意志的体现。公司一把手的管理理念与价值观如果歪了，这公司长不大。

以上观点总结如下图：

当然，如果在方向和努力两者之间一定要一决高下，我选努力。选方向貌似更正确，但实际上更难做到，因为决定它的因素太多，而画ppt又太容易。努力，就是执行力，本质上只取决于一把手一个人。跟对了人，这个就容易做到。如果在努力的过程中，发现方向不对，还能及时调整。可如果方向再正确，没有努力，永远等于零。

带领硬件团队两年，战略第三版，更加务实：

参考2023年2月的《地上的战略》，以及2022年2月的《墙上的战略》。

去年2月27日，刚接手硬件部门2个月，画了个《墙上的战略》。一年过去了，这墙上的战略终于走到地上。总路线图还是三个分支，但各自都更深远和明确，未知的红色也少了许多。今年，继续将红色转绿，并且将地上的战略变成扎实的订单。少说多做，我的原则。

当然首先是把问题全部列出来，分门别类：

然后梳理问题间关系，找出关键问题，才能对症下药：

什么是战略？

迈克尔·波特说，战略就是创建一个价值独特的定位。特劳特说，战略是指企业如何在顾客心智中建立差异化定位，并由此来引领企业内部的运营。战略就是让你的企业和产品与众不同，形成核心竞争力。对受众而言，即是鲜明地建立品牌。

与众不同其实不难，比如标新立异，比如大打广告，难的是成为核心竞争力。核心竞争力是一个企业（人才，国家或者参与竞争的个体）能够长期获得竞争优势的能力。是企业所特有的、能够经得起时间考验的、具有延展性，并且是竞争对手难以模仿的技术或能力。

海底捞的核心战略是人性化服务，但这种能力缺乏壁垒，而且脱离了餐饮的本质——好吃的美食，所以是伪或短暂的“核心竞争力”，所以也就难以持续。

明确核心竞争力，是确定企业战略首先要做的事。核心竞争力可以从四个方面识别：价值性、稀缺性、不可替代性、难以模仿性。

但是很明显，核心竞争力的建立不是一朝一夕，是需要智慧的眼光、持续的投入、坚定的决心和时间的积累才能达成。

放在这里，每年来看一眼。

整理有道云笔记，发现一篇大概写于2015年左右的关于敏捷的思考，贴上来以纪念那些专注于研发的岁月。

1. About Iterations

• Iterative and Incremental Development – IID. What are we doing? – Iterative? Incremental or IID? Suppose we are doing IID in most cases, don’t be confused by the term of “iteration”.
• IID – All Iterations should have a verifiable deliverable. That’s why we need to involve test team in iteration planning meeting to help on the backlogs identification.
• Tracking Agile project commitments is based on scope. Trying to keep same iteration length as much as possible. Move the underestimated part to latter iteration even buffer iteration. The pace of iterations is the beauty of Agile like the turns of seasons, ticks of clock, or rhythm of running. But life is not always simple. Team still needs the balance between schedule and scope.

2. About Milestones

• Milestones are something serving for waterfall model. How can you imagine you can accurately foresee a very specific release date in one year later while so many things will be changed during that one year? But we still keep that date as our M11 Commitment! So people play with data and date (increase internal buffer to make the commitment safe for example). 
• Release date should be forecasted based on scope and quality along with iterations ongoing. A rough date could be expected (which quarter or which month) in the beginning of the project. More accurate date will be forecasted in later phases. Then people can focus on the real work and real quality, not scaring of the deadline that defined one year ago.
• M5 is absolutely derived from waterfall model. That assumes the box test will only start after all development done. In Agile, test involves in every iteration to make sure the delivery of every iteration is healthy. A short cycle of full regression is still needed after all iterations, but that should be very short as most of tests are already passed in previous iterations. This is how Agile improves quality and shorten cycle time. Why can’t we do like this?

3. About Architecture

• System architecture should be locked down before iterations or at least in very early iterations.
• So, for the project of new platform creation, the 1st iteration might not be able to have a verifiable deliverable because the platform that support the whole architecture need to be built first and that is probably not verifiable without feature associated. But this doesn’t stop the goal that agile team should set to define the backlogs verifiable as many as possible and as early as possible in iterations.
• For the project of new platform creation, my suggested lifecycle model is Prototyping, not agile Iterations. Once we have defined the architecture and high level technical solution, then it’s ready for IID planned for subsequent features development.

4. About Test

• Agile can never live without test. Test is naturally part of Agile. 
• Automation is the spirit of the test in Agile because only automation test can meet the quick turnover of the daily build. 
• TDD is an embedded format of testing to build functions/features inside coding. Regression is a quality guard after functions/features ready. Both of them theoretically are in the same one iteration. Actually you could insert your own test anywhere inside the work flow once the automation test framework with test case pool is in place.
• TDD contradicts with normal coding habit. To overcome the habit is expensive, though the benefit is obvious but hard to measure. TDD is also highly relying on automation framework that should be easily maintained with more codes added. That’s why TDD is difficult to implement.
• Try to combine the auto test in the work flow of Continuous Integration. I’d rather interpret it is not a full concept of CI if there’s no auto test attached.

5. About Refactoring

• Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. Refactoring opportunities can be found from architecture down to the code level.
• A risk evaluation should be done to determine if refactoring is necessary.
• The emphasis should be on refactoring the newly implemented code and not legacy code.
• Refactoring needs automated test to support. Otherwise you cannot do refactoring frequently because you cannot afford the test effort after refactoring.
• Refactoring should be a formal planned action in each iteration, not a one-time shot in the beginning of a project and then totally forgotten afterwards.

6. About Paired Programming

• Paired Programming, requires a social change as well as a technical change, so we expect more resistance to this practice than others. 
• Formal Technical Review can be integrated in paired programming if team has confidence to skip or consolidate the FTR(s). The precondition is that the two engineers in the pairing both have enough domain knowledge on what they are doing. The pairing with mentoring purpose cannot guarantee the quality of peer review integrated in the paired programming.
• For Agile projects doing Paired Programming and not formal reviews, ICE may be significantly lower because faults may not be logged. But on the other hand, faults logging is not really important in Agile because Agile weights the working software (…think about 4-UP charts). 

7. About Tools

• Agile never compels a specific tool to manage and track the project progress. As a manager you know project progress through talking and walking in the team.
• Version One is not mandatory to manage the Agile project. It does provide more functions like “feature group”, but if you only need a tool to track backlog progress, Excel spreadsheet is the simplest and fastest one.