这是一个普遍的误解：把看上去能够唯一标识一条信息或者一件物品的数据当成该信息或者物品的Key，而往往这种数据到了另一方（在刚才这件事中是客户），具有同样数据的信息或者物品有太多（哪个客户每年不签一大堆合同？）。
吉姆决定继续表达他坚定的立场“我认为，大多数企业所生产的产品太过庞杂了，这反而削弱了他们的实力。他们的资源被分散了。对短期市场需求做出被动反应而推出的产品并不是最好的。我们最好还是选出几个最具有潜力的产品，并让他们不断发展而成为市场中最佳的产品。”
7799是一个关于安全管理的标准，从我们现在的观点来看，7799只讲了安全管理有什么，而这些组成部分之间是什么关系讲得不多。虽然ISMS是基于业界最佳实践而提出来的，但却缺乏必要的流程。因此，在这方面ITIL正好提供了可供7799借鉴的东西。
有天听到P接到儿子打来的电话，在电话里小声地问了一句："What's the good news today?"
回想起原来开中心例会时，P也曾经采用过这种方式。但是后来没有坚持使用。从现在和孩子通话中的这句话看来，这已经是他们家的一种习惯了。
What's the good news today?
你的答案是什么？
你曾经用心地去回答这个问题吗？
假如我们的生命是80年，去掉睡眠时间还有50年，去掉我们不能思考的那些岁月还有30年。在这30年中，如果你用快乐的回忆去填充，你得到快乐的一生；如果你用忧伤的回忆去填充，你得到不快乐的一生。
所以，每天都要问自己："What's the good news today?"
今天又看《领导商数》（余世维），听到那句已经耳熟能详的话——投诉是第二次表现机会。
在很多人（也包括我在内）看来，“投诉”是一件很“可怕”的事。尤其是投诉的对象是自己或者自己的直接下属时。
其实，真的没那么可怕。当我以一种积极的心态来面对“投诉”时，我发现真的象余世维讲的那样，投诉是第二次表现机会。
余世缑先生还讲道，投诉只在下面三个条件同时成立时才会发生：
1、没有替代者；
2、不想放弃你；
3、想得到补偿。
让我有点奇怪的是，我自己极少被投诉。在公司工作3年了，我的主管通知我被投诉一共不到5次。回想一下上面这些条件，好象第3条总是不满足。因为投诉我除了对我可能造成负面影响之外，我的客户（也就是销售）不会得到任何补偿。
但是，这样带来很严重的一个问题：我得不到对我工作效果的反馈。
还让我感到奇怪的是，我们部门的成员也很少被投诉。直到前几天，一位销售才把对一位已经离职的同事在执行任务时犯的错告诉我。他们的情况稍有不同：第1个、第3个条件都不满足。
这同样也是问题：我的下属也得不到对他/她的工作效果的反馈。
怎么办呢？
很自然地，我第一想到的是要鼓励投诉。但这会带来一个问题，投诉太多了怎么办？带来的负面影响会更大。
想来想去，还就想到一个办法，鼓励直接对话。
曾经有位销售跟我说某下属的某些问题，我就跟他说，这些问题由我去转述反而不好，不如你直接和他沟通。基于我对你们两位的了解，相信你们一定会沟通得很好。结果效果不错：这两位现在彼此信任而且配合日趋默契。
但这种方法的推广却不是一件容易的事。结合昨天看《时间管理》一书的感想，得出一个结论：对任意两两组合，需要采用不同的处理方式。这里面的道理毛主席他老人家讲得已经很清楚了：具体问题具体分析。:)
昨天把买了很久的《时间管理》。读到49页。
在看目录时，对一句话很有感触——“没有万能风格”。
看到那一小节时，感觉和预想的差不多。就是那样的，没有万能风格。也就是说，在时间管理方面，不存在一个适用于所有人的方法。
这也引发了我对今年管理工作的反思。
我或多或少地犯了一个错误：希望大家表现得同样好。
这是不可能的。
每个人有自己擅长的领域，每个人有自己的偏好，每个人有自己的风格，……他们怎么会表现得一样好呢？
我应该给他们每个人都设定不同的目标。只要这些目标和团队目标相容，就要鼓励他们有自己的方向，有自己的标准。
启示一：为每一个团队成员定制目标。
原文：关注“大本营”的管理
Q1、Q2分析得相当精彩。:)
有一点不同意见：我不认为Q3应该放在“大本营”里。
理由如下：
1、Q3已经涉及到公司发展与员工个人发展的协调一致问题。
2、正如在文中提到，一个人“擅长”什么，实际是很难有准确的描述。我认为只有当一个人在工作中已经很有经验，而且对自己的定位很清晰之后才能清楚地知道自己“擅长”什么，才能去寻找一份自己“擅长”的工作来做。
3、根据团队合作分工的最小成本原则，并不总是一个人“擅长”什么就让他/她做什么。而是取最接近的。引用一个例子如下：如果A擅长工作1，能做工作2，而除了A之外，团队中没有人能做工作2。这时，尽管A还不擅长工作1，也会让他去做工作1了。而这样的事，在工作中每天都发生。所以不应该作为“基本要求”，也就不应该出现在“大本营”里。
如有不当，请指正。
:)
原文：关于产品研发的思考
感觉思考得比较深入。:)
另外想补充一点：管理。
大体上可以认为公司的管理水平从根本上决定了产品的水平：体现在你的文章中就是产品的技术指标、产品的易用性、产品的适用性。
产品管理并不是有产品经理或者产品管理部就可以搞得好的，产品管理首先依赖于公司内部的水平沟通是否顺畅，是否有保障。
今天晚上和客户讨论到2点，茶馆关门了还有点意犹未尽。
之所以会有这样的讨论是因为客户对我们提供的项目建议书不满。用客户的原话来说就是“当我仔细看完这份文档时，我发现其中只有两成左右的内容是可用的”。
为什么会这样呢？
这个问题其实已经思考了很久，也早就有了答案：客户的视角与顾问的视角不同。
作为咨询顾问，如果想把工作做好，就必须站在客户的角度来看问题。只有这样，客户才能理解我们的解决方案，才能体会其中的好处（如果有的话）。
但怎样才能站在客户的角度看问题呢？
在前一篇短文中，我提到要让客户和我们一起创新。今天我突然发现这种方法同样有利于我们站在客户的角度看问题。这还和Jordan在推荐《六顶思考帽》的那篇短文中强调的“平行思维”有相通之处。
其实就是这样，当客户说出他的看法时，我们千万不可以急于表达自己的看法。先好好想想为什么客户会有这样的看法，结合客户在组织中的位置，结合客户的环境体会一下，就会比较容易和客户的视角相近了。
可以多试试，其实就象六顶思考帽那样，没有想象中那么困难。
作为一个咨询顾问，要做的事情很简单，也很复杂。
把复杂的事情变简单，就是咨询顾问的价值所在。
如何才能把复杂的事情变简单呢？ 其中还是应该有技巧的。
技巧之一就是：让客户与你一起创新。
对于新入行的咨询顾问来说，最苦恼的事莫过于自己费尽周折想到的解决方案客户不理解。
不理解就不大可能支持，你怎么办？
方法一：不厌其烦地向客户讲解，直到客户理解并接受为止。
方法二：对方案进行改写，改善方案的可读性，直到客户能够看明白为止。
方法三：你还有第三种方法吗？
昨天开会讨论某个项目时谈到客户在准备汇报时需要我们配合。也就是说，需要配合客户写出汇报用的PPT 。于是脑中灵光一闪：这种方式何不用在我们的日常工作中呢？
对客户来说，解决方案是客户环境中某种程度上的创新。简单点，一份解决方案对客户来说是一份新东西。理解并接受新事物是需要付出一定努力的，这包括时间和精力。
对我们来说，客户肯投入在我们关注的项目上的时间和精力都是有限的，因此我们需要减少客户在这方面的开销，这样来提高客户的满意度。
和客户做一次交流，然后在规定的时间提交方案。这是常规的做法，也是效果最一般的方法。
如果想改善效果就需要改善做事方式。
和客户交流一次，然后每1~2 天把方案的中间结果提交给客户看，再电话确认一下客户对方案的想法（谦虚地请客户提意见）。这样渐进地把方案做好，在规定的时间提交给客户。这样客户总共投入的时间和精力都增加了。但是，当我们正式把方案提交给客户时，客户理解并接受方案所需要付出的努力却大大减少了。一来因为客户参与了“创新”的过程，方案中整合了客户的想法，当然更容易接受；二来客户在参与的过程中就已经一点点地积累了理解方案所需的背景知识，到正式提交方案时，理解起来已经没什么困难。
这便是咨询顾问的工作原则之一：客户参与。
Powered by Haiwit
