h*******s
发帖数: 616 | 1 曾经在某大科技公司做售后技术支持。
客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
工程师就负责解决问题。
许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
使用场景考虑不周，从而产生歧义和误解。
这样的设计问题，有时每个季度会产生上百个 case。
从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
但现实中并非如此。
每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
自新版本、新功能的开发。Bug Fix 不能算主要的 credit。（自己拉出来的翔，自己
擦干净，算什么 credit？）
因此除非迫不得已，开发部门是不会去修补 Bug 的，尤其是上面提到的使用上引起歧
义的 bug。
你从售后压力的角度去看，觉得修补这个 Bug 天经地义。即可节省售后人力成本，又
可提高客户满意度。但开发部门不愿意－－如果安排人员去修补这个 Bug，开发部门的
人力资源就消耗了，credit 又拿不到，还有可能影响新产品的开发进度。反正售后部
门的人闲着也是闲着，让他们去纠正客户的使用方法就行了。
如果你不妥协，坚持要吵到大老板那去。一来，大老板未必鸟你。二来，就算大老板姿
态性地同意，下一次就未必灵了。你反而在公司落得个没有 team spirit 的名声。
因此，需要区别“The right thing to do”和“The best thing to do”。 |
l*****k
发帖数: 1059 | 2 在data driven approach, 并假设communication很有效的话，坚持你的判断只会给你
更多credits.
Data driven可以让你的观点makes sense, not only to yourself, but also to
others who see the data.
Communication 是为了保证大家看到同样的data.
【在 h*******s 的大作中提到】
: 曾经在某大科技公司做售后技术支持。
: 客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
: 工程师就负责解决问题。
: 许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
: 使用场景考虑不周，从而产生歧义和误解。
: 这样的设计问题，有时每个季度会产生上百个 case。
: 从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
: 既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
: 但现实中并非如此。
: 每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
|
h*******s
发帖数: 616 | 3
呵呵，
“The glass is half empty”
“No, you're wrong. The glass is half full!”
【在 l*****k 的大作中提到】
: 在data driven approach, 并假设communication很有效的话，坚持你的判断只会给你
: 更多credits.
: Data driven可以让你的观点makes sense, not only to yourself, but also to
: others who see the data.
: Communication 是为了保证大家看到同样的data.
|
c****g
发帖数: 3893 | 4 你首先要有能让人妥协的资本，人家才会和你妥协。
【在 h*******s 的大作中提到】
: 曾经在某大科技公司做售后技术支持。
: 客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
: 工程师就负责解决问题。
: 许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
: 使用场景考虑不周，从而产生歧义和误解。
: 这样的设计问题，有时每个季度会产生上百个 case。
: 从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
: 既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
: 但现实中并非如此。
: 每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
|
l*****k
发帖数: 1059 | 5 我来试着把我的观点说清楚些。
第一， 如果某人和你对同样的数据，但是结论完全不同。
这有两种情况，可能不会分得很清楚，但是如果你能区分出来的话，对解决纷争会有好
处。
A. 是某些隐含条件对方看到的和你不一样，比如team's goal, roadmap, resource,
priority.
等等。对方的judgement时基于这些条件的。 她可能假设你知道这些，而你并不清楚。
这样
你们会得出不同的结论。反之亦然。
这本质还是数据不对等，而原因是communication不充分。如果你来drive找出原因很容易
得出一致结论而解决纷争，这样credit是你的
B. 是因为某些不太好拿上台面的东西，比如politics, trust. 这种情况下坚持自己的
判断并且
必要时escalate是非常有用的。这是所谓的“do the right thing". 当然不排除战术
上的妥协。
但是道理必须讲清楚，不能不明不白的放弃。这是另一种获得credit的办法。
这两种情况，很多时候大家以为是B, 实际是A. 而且communication充分有效的时候就
会解决
绝大多数的纷争。
第二, 让别人妥协的资本。或者说怎么让人听你的
不外乎三种情况，首先, data points 就是你的资本。 其次, authority 也是资本。
最后, leadership
是最后的资本。 Data points是说： 你这么做对你有好处； Authority是说： 不这
么做不行； leadership
without authority是最有意思的事情， 他是说：相信我，跟着我干是没错的。
所以在工作中最推崇的人那些 leading without authority 的人。
【在 c****g 的大作中提到】
: 你首先要有能让人妥协的资本，人家才会和你妥协。
|
l****z
发帖数: 29846 | 6 这个说得好,支持一下.
leadership without authority 最难,因为很多时候不是别人没看到你是正确的,而是
因为其他原因(politics或者多一事不如少一事等等) 就算他们看到你是正确的也不会
跟你走.
容易
【在 l*****k 的大作中提到】
: 我来试着把我的观点说清楚些。
: 第一， 如果某人和你对同样的数据，但是结论完全不同。
: 这有两种情况，可能不会分得很清楚，但是如果你能区分出来的话，对解决纷争会有好
: 处。
: A. 是某些隐含条件对方看到的和你不一样，比如team's goal, roadmap, resource,
: priority.
: 等等。对方的judgement时基于这些条件的。 她可能假设你知道这些，而你并不清楚。
: 这样
: 你们会得出不同的结论。反之亦然。
: 这本质还是数据不对等，而原因是communication不充分。如果你来drive找出原因很容易
|
j******o
发帖数: 4219 | |
a*****g
发帖数: 19398 | 8 rgood
【在 h*******s 的大作中提到】
: 曾经在某大科技公司做售后技术支持。
: 客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
: 工程师就负责解决问题。
: 许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
: 使用场景考虑不周，从而产生歧义和误解。
: 这样的设计问题，有时每个季度会产生上百个 case。
: 从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
: 既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
: 但现实中并非如此。
: 每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
|
M*D
发帖数: 15 | 9 Good point
曾经在某大科技公司做售后技术支持。客户在使用产品的过程中，遇到问题，就会打电
话到售后技术部门，开个 case。售后工程师就负责解决问题。许多问题其实是由设计
引起的。开发工程师(........
【在 h*******s 的大作中提到】
: 曾经在某大科技公司做售后技术支持。
: 客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
: 工程师就负责解决问题。
: 许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
: 使用场景考虑不周，从而产生歧义和误解。
: 这样的设计问题，有时每个季度会产生上百个 case。
: 从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
: 既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
: 但现实中并非如此。
: 每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
|
t*****n
发帖数: 4908 | 10 这个公司5年内必倒闭。太不正常了，非常不上进。
【在 h*******s 的大作中提到】
: 曾经在某大科技公司做售后技术支持。
: 客户在使用产品的过程中，遇到问题，就会打电话到售后技术部门，开个 case。售后
: 工程师就负责解决问题。
: 许多问题其实是由设计引起的。开发工程师(developer)通常不面对客户，因此对一些
: 使用场景考虑不周，从而产生歧义和误解。
: 这样的设计问题，有时每个季度会产生上百个 case。
: 从“正常”的角度考虑，开发部门应该针对这个现象，在下一个版本中加以改善。这样
: 既提高了客户满意度，又减少了售后技术部门不必要的压力（工作量）。
: 但现实中并非如此。
: 每个部门都要求 Do More with Less。开发部门也不例外。开发部门的 credit 主要来
|
v*********n
发帖数: 3983 | 11 凡是不注重产品质量和客户感受的公司都活不久。google, apple都是产品质量好才耐
久。日本车也是这个道理。
还好我们现在的老板不赶进度，只要求尽量少bug. |
