|
会议。开会太容易变成一群人互相在扯对方的蛋。 浪费时间而且开完后发现没有结论且很蛋疼。但开会对于teamwork很多时候是必要的。 如何主持会议是门学问， 这里不细谈。 不过，你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候， 建议你考虑不去。如果想要有礼貌一点，那就写个email问问主持人你是否可以缺席。通常当你想过这个问题决定发这样的邮件时，答案通常都会是yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会鼓励他也争取不要去。Onlymake the meetings you really have to。 同样，我要求我自己的团队在组织和参加会议的时候要慎重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会经常收到来自支持团队的比较随意的会面请求。这让攻城狮的一天被会议分割得支离破碎。写代码的都知道没有3-4个小时的连续时间是不容易高潮的。 而且这种会议通常效率很低。于是，我们改变了做法，每周安排固定的答疑时间（office hour）和支持团队嗑想法然后follow up。当然，紧急的问题另当别论应当马上处理。 有一个被经常忽略的原则 -有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免介入（比如韩寒和方舟子的 -个人意见），哪些功能可以放弃，哪些关系不应该发展， 哪些人应该开掉，等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你清楚自己正在做的和自己想要的，答案会明了。Go forit。 6、增进亲密感是减少紧张关系的有效方式 工程师和支持团队之间有着纠结的合作竞争关系（注意，合作在前）。互联网技术公司中很多人（尤其是聪明人）总是期望工程师对所有问题给出一个让人会心一笑的解决方案。但现实是，不是每一个问题都可以或者应该在技术框架下解决。对于一些具体的问题，客户支持和运营部门会有一些非常深刻独到的见解。 工程师未必行。 毕竟很多见解需要不同的专业知识， 依靠实地经验。没错，工程师可以在代码中自动log大量的原始数据，但从原始数据中提炼可靠的insight却并不总能如愿。 就像大炼钢年代扔进去的是铁，出来的是铁疙瘩， 而非期望的钢。 和很多其他公司的客户或支持部门不同， 我们的支持部门招募了质量相当好的员工（很多来自美国名校 -在我直接接触的反欺诈支持组20来人中就有3名斯坦福校友）。因此，当两群都很聪明的人观点相左时，该听谁的呢？ 紧张关系再所难免。 （责任编辑：职场达人） |
