转手他人的注意点
转手他人是合理的，也是必须的，因为有些事情你不一定合适干，有一些事情你不一定有时间干，有一些事情你虽然可以干，但是别人干的效果也不差，让年轻的团队成员获得锻炼也是团队发展中的一个重要内容。
但是转手他人不代表甩手不管，也不代表从此不用为这个事情负责。 当我在转手他人时，往往心里会增加一些焦虑，我的这个转手是不是正确，对方能不能接手这个任务，能不能很好的完成，万一搞砸了怎么补救。当然，一般情况下，如果评估下来风险就比较大，也许我就不会转手他人了。
为了降低这种风险，我会仔细的考虑他人的实际能力和潜力，这个任务的技能要求，确保是对方可以完成，或是通过一定努力可以完成的。 同时我会尽量帮对方降低上手的难度，给出我的思路建议，甚至多遍的跟对方讲解我对这个事情的思路，哪怕对方不一定会在实际操作中按我的思路来。
我需要列出完成这个事情一定要达到的功能点，就像城市定位赛，所有的关键点是一定要达到的，否则就是失败，转手他人也是如此，如果你不规定好这些点，那么可能就不会看到预期方向上的结果。
此外需要定期的交流进度，状态，以免中途跑偏而未被发现。
平常心对待一时得失：塞翁失马，焉知非福
有时候一些负面的不利的事件，往往也隐藏着机会，这就是换个角度看问题，同时，这也是减轻负面情绪的一种调节方式。
比如说过完年开工后大量人员离职，公司人心不稳，然而此时正是潜伏多时的我的机会，事实证明走了不少人之后，剩下的人仍然做出了不错的业绩，而其中站出来承担责任的人则证明了自己的能力。
有时候能做救火队员，也是一种能力的体现。
但是长远来看，走了一批人后毕竟元气大伤，没有及时进补，缺乏了继续上进的后劲，也是安知非祸。
作为管理者或者当事人，永远需要不被失败打倒，正视失败去寻找补救机会，不择手段去弥补损失，保证主体目标的实现。
做事原则：要事第一
80-20原则，结果说话原则 要事第一实际上就是全局观，不纠结于局部，明确重点并有倾向的投入精力 重要不紧急与紧急不重要的取舍
当然也有例外，那就是 1分钟的事情马上做掉 如果这个事情很短时间就能做完，那么别管其它，先干掉它，别拖
做事原则 以终为始
同样，结果说话，在动手前先动脑，确保自己的方向是正确的
方向不正确，往往意味着浪费，和以后更大的麻烦
正视风险： 怕什么往往来什么
克服怕事心理，悲观论看待可能性: 做好自检，避免大坑
前段时间，我的车经常在怠速时异响大作，就像是开启了空调一样，这种现象持续了很长时间。 然而我当时认为也没有发现其它问题，只是有声音异常似乎并不严重， 感觉毛病不大，就一直拖着没有去修理厂看看
结果后来某一天晚上我跑高速，突然出现异响，坚持了一会后实在不行了，靠边发现引擎盖下浓烟滚滚，吓了个半死。后来拖到汽修厂，因为水管破裂导致发动机过热，损毁严重，不得不大修，换了一堆零件，花了一万多。 据汽修厂师傅讲，如果早点来检查发现水管问题，换一下不过一，两百的事，然而毁之晚矣
所以一个教训就是，不要忽略小问题，如果整个系统比较重要（比如电，燃气，汽车等可能涉及人身安全的范畴），那么不能忽视这些平时的小问题，甚至应该主动的定时检查工作环境，确保没有异常出现。
远离坑货，提前规避风险
电动车，大货车，以及那些行驶过程中明显异常（频繁变道，刹车，加速，变速，双闪等）都可能会变成与自己车相碰撞的危险点
因此开车上路需要时刻紧蹦这根弦
那么，在工作中也应该如此，做事前先了解下这个方向上的坑点，敏感点，哪些碰不得的点，哪些要小心的点，以免给自己人为添加障碍
避免麻烦，但是不怕麻烦，不首先碰麻烦，不惧怕解决麻烦
不要拖拉： 不要让球停在你的手上
工作中，许多事情往往需要多人参加完成，多数时候，做成一件事情需要先后通过不同的人的参与得以完成，而且许多时候会有依赖性，前面一个人的工作进度决定了后面一个人工作开始的时间。 所以，作为这个链条中的一环，好的工作方法应该是像接到一个烫手的球一样赶紧把这个球扔出去传给下一个人，而不是握在手里仔细研究这个球的弹性，大小，重量，材质等似乎有趣却无关紧要的东西。
否则，你在别人的眼中不会是一个好的teamplayer
抬头还是低头： 小步快跑还是深谋远虑
用户需求总是充满不确定性的，基本会有一个演进的过程，今天他说需要一个手机能打电话，明天他希望手机能有mp3功能，后天要听FM,大后天说要有拍照功能，这样的情况其实是比较常见的，用户也是在学习中进步
不过害怕的是一种： 用户今天说需要一个塞班系统的手机，半个月后说要一个安卓的，那这下麻烦就大了
还好，这样的用户应该不多，另外用户通过一定的学习过程，也会明白这样的需求对于开发方来说有多不合理
但是目前我们自己有这样一个趋势，就是发明需求而不是总结需求， 我们可以认同用户的需求是梯度演进的，但是他的演进应该是有迹可寻的，不太可能是革命性的，或者说突然从用户视角转换成开发人员视角
今天我们在谈论说给每条数据都打上标签，让每个操作都关联上用户的信息，whowhenwherewhyhow, 但是我觉得这实际上是一种对用户需求的过度发挥
我们应该思考用户提出日志关联的目的何在， 他是想看到统计数据么？ 在我们过去几年的摸索中，我们应该明白，在运维这个场景中， 90%以上的情况下用户不关心统计数据，不关心正常情况下的各类参数，只关心异常，以及潜在的异常，诸如此类会给他立刻带来麻烦的地方。统计相关的数据，我只能看到这可能会所谓高级层面的价值（比如容量扩张等），但是这个应该是满足基本需求之后的事情
另外互联网企业的需求，和我们所面对的用户是不同的， 对于互联网企业来说，互联网基本上就是他的全部，一切业务都是建立于互联网上，依赖于互联网和数据，一旦互联网或应用故障，那么企业基本上全完蛋。 而传统企业，他关注的重心还在业务，目前还没达到断网了医生就不能看病的阶段，所以他们关心的点是与互联网企业不同的。
另外解决一个未来可变的问题，应该小步快跑而不是一开始就试图把所有环节想得明明白白，因为用户并不是那么容易预测的，我们预想的需求12345，不代表用户一定会提出需求12345，如果用户提出12678，那么可能我们的345就是白做了
而且很多时候我们的计划都是偏复杂，从动工到看到结果可能要1个月以上，充满了变数，做完了拿出来看，如果不是想要的，却转身困难，因为不愿意一个月的劳动被当作无用功抛弃，只能是就现有的路子改来改去。结果就是啥也没干成，先负重前行着。
一方面我认为需要从实际出发，看有什么原料做什么菜，一方面也当然希望有技术上的拔尖提高。 但是不可能空想，也不可能在不考虑实际企业压力的情况下一味钻研技术
恒心
做事情应有恒心，不应三天两头
比如提倡某些做法，应该把这个宣传目标当作长期任务来执行，而不是像头脑一热一样临时一提，然后抛之脑后，过半年再重复一次，这样给人的感觉就是做事并不稳妥，明明是想强调重要性却会起到反效果