标签：
原文地址：http://suanfazu.com/t/topic/9613
Foursquare团队技术领导简要指南——有感于Ben Horowitz“好产品经理，差产品经理”一文。
一个优秀的技术领导必然是团队的一份子，他们认为当整个团队成功时自己才称得上成功。他们不仅要做好繁杂和不讨好的本职工作，还要清除项目中的障碍，从而让整个团队能够以 100% 的效率运转起来。一个好的技术领导会努力去拓宽团队在技术上的可行性，以确保对关键系统的认识与实施不仅仅局限于一两种想法。
一个糟糕的技术领导通常以完成工作邀功为目的而将所有重要的任务揽于一身。他们的理念是部分优先于整体，所以以整个项目团体为代价而只让团队成员去完成项目中最有利的部分。一个优秀的技术领导对于产品的技术方向有一个整体的把握，并且还要确保团队中的每个成员都能知晓。技术领导将不同的功能分配给剩下的团队成员们，由成员自己做主该功能所需要用的技术和方法。他们相信成员们都很聪慧，所以充分信任他们，由成员自己去处理项目中的重要部分。
一个糟糕的技术领导直接向其它成员们宣布已经决定采用的技术方向而不是解释或者明确技术方向。技术领导们自己掌握了关键系统的知识，但并没有通过编写和传播一些实用文档来加大这些知识的作用。一个优秀的技术领导会聆听和鼓励团队内的讨论。当团队成员对某个问题争论无果时，他们会简单描述一种解决思路的步骤和框架，从而帮助成员解决这个问题。好的技术领导从来不会带着结论参与团队讨论，反而经常被其他成员的奇思妙想说服。
一个糟糕的技术领导任由无果的争论无休止的进行，这显然阻碍了团队生产力的发展。而有些领导者会过早的结束讨论，用“已经解决了”的回答来反对新的讨论。对于一个差的领导者来说，在争论中获胜比得到一个正确决定要重要的多。
一个优秀的技术领导者是主动的。他们要确保项目中的技术方向不偏离正轨。他们要和团队成员一起做出预测并且制定中间里程碑。他们要预测所关注的领域可能出现的问题，并确保在问题发生时不会手足无措。他们要明确技术上的障碍并且帮助团队克服它们。他们要找出项目中重叠的工作，而让成员们合作完成它，除此之外，还要找出项目中没有得到足够重视或者资源短缺的部分并想办法解决。
一个糟糕的技术领导者是被动的。他们通常只分配任务，但从不跟进去确保进度。他们从不设置阶段性目标，只希望项目结束时各个部分能够良好集成。对于开发一个复杂系统来说，他们通常在系统发布前的端到端测试阶段才来跟进进度。他们甚至会允许队员在一些有趣却不重要的事情上浪费时间。一个优秀的技术领导追求实用，他们会权衡一件事是要做对还是要做到。对于他们来说，有时会采用一些简化方法作为权宜之计，但是他们绝不偷懒。反而，他们会鼓励团队成员用一些临时的简化方法或者应急系统来应对整个开发过程中存在的问题，以满足在发布时有可运行的基础功能。对于一个优秀的技术领导者来说，细节十分重要。在他们眼中，保证代码质量、进行代码审查以及测试工作与按时发布软件一样重要。
一个糟糕的技术领导者只会为了暂时节省时间而走捷径，但却造成后期维护花费更多时间。他们不能分清哪些情况下需要使用权宜之计，哪些情况下需要尽善尽美。一个优秀的技术领导者知道自己的角色不仅仅是写好代码，与团队成员进行有效沟通也是他们的工作中重要的一部分，为了使团队的工作效率更高，多花点时间非常值得。他们深谙在一个团队中沟通和交流的必要性，也会为了团队效率而牺牲个人时间。
一个糟糕的技术领导者却认为他们只有在编码时效率最高，并认为沟通是一种干扰。他们不以团队效率为先，崇尚个人主义。当他们不得不花时间领导团队时会觉得万分沮丧。一个优秀的技术领导会就产品如何运行的问题而和产品经理以及设计师做出讨论。他们不怕提出反对意见，但也会为了产品目标而做出适当妥协。他们会提出一些可替代但技术需求较低的产品构想，从而来解决技术限制的问题，并且帮助产品经理和设计师理解技术挑战，以便他们做出明智的取舍。
一个糟糕的技术领导把产品的决定权抛给“该做决定的人”，而不是以一种产品主人公的态度对待它。他们也会因为技术限制而否决一些产品决策，但不会提供可替代的技术方案或向其他人解释技术问题所在。一个优秀的技术领导以弹性的态度对待产品规格的变化，以平静的反应对待产品完成过程中的意外。他们会预测规格变化可能发生的地方，设计好高弹性的代码来应对。
一个糟糕的技术领导面对产品规格的变化时往往心烦意乱，以及过早的在他们觉得不会再发生变化的地方写上低弹性的代码。标签：
原文地址：http://www.cnblogs.com/davidwang456/p/5500226.html
