这是去年的旧文 The Tech Lead’s New Project Checklist 的翻译。刚好本人现在也是题目中说的Tech Lead（Tech Lead我想不出一个合适的翻译，所以下面直接用英文的Tech Lead）。
由于原文只是一篇笔记，所以很多只是记了个要点，需要读者自己去拓展思考，说实话部分点我也没理解作者说什么（可能是我英语水平的原因）。我翻译的也不一定符合原作者的意思，甚至可能翻译错了。我会在不影响原文意思的前提下加入一些话，让它读起来顺畅点。
下面是正式的译文。

这是我在一个“那些在一个新项目开始时tech lead需要知道和做的事”的讨论会中的笔记。这些智慧来自Thoughtworks的 @JimBarritt，我只是个搬运工。

这个清单对全新的团队/项目和tech lead加入前就已经存在的项目都有用。

前面两项是最有可能导致项目死亡或内耗的：

1. 基础设施
   • 生产环境在哪？这是最重要的一件事。它是怎样的？什么时候就绪可使用？(开发环境在生产环境的事情确定后再考虑)
   • 我们怎么上线？计划是什么？
   • 负载均衡怎么做？
   • 防火墙
   • 证书
2. 第三方
   • 集成！
   • 如果各集成环境间是超出你能控制的混乱状态，那么保障自己的环境是组织良好有序、顺畅、自动化、边界规划合理等就显得更加重要了。
3. 找出有号召力的人
   • 找到所有可以说“No”的人、能够砍预算、能够对你说“你干得很棒”的人，跟他们打照面认识。
   • 举例：
     • 架构师
     • 对数据保护有控制权的人（当心“organisational scar tissue”(不知道改怎么翻译这个词，看这篇文章理解一下)）
     • 高级信息风险官（SIRO）
4. 找到任何关于你团队的工作的文档，阅读并理解它
5. 预算和价值定位？
   • 如何更好的定义它？你们为什么做这个项目？Vision是什么？人们能够理解吗？
   • 一旦找到这些信息，不断重复它们。
   • 如果有些对整个项目的成功非常重要的假定条件，在每次展示开始时都对它们进行重复。
6. 试着跟每个团队成员进行一对一的面谈
   • 试着去了解成员各自的目标、特别是在这个项目中的目标，同时将自己的目标传达给他们。举个例子：比如你有想要离开的区域，就找到那些想要进入该区域的人。（这句翻译起来怪怪的，可能译错了）
   • 什么是他们的主要痛点和障碍？
7. 和项目经理做朋友，并弄明白他们时怎样管理预算的
   • 这对建立信任关系很有帮助
   • 了解 Chris Matts 所说的 “Real Options”
   • 阅读 Bjarte Bogsnes 的 “Beyond Budgeting”
   • 听 Brett Ainsley 在 Agile on the Beach in 2016 上的关于钱、团队和如何记账（account）的演讲 Accounting for Agile software
   • 阅读 Gregor Hohpe 的 37 Things One Architect Knows About IT Transformation
   • 不要尝试做一个财务细节上的专家，只要懂得财务的基础知识就可以了：钱是如何运转的？什么是不同的工种？OpEX和CapEx直接的区别是什么？(我也不懂，学习一下：文章1，文章2)
8. 如果有多个团队，找到并结识其他团队的Tech Lead
9. 弄得交付三人的重要性：交付经理（Delivery Manager）、产品负责人（Product Owner）、tech lead
   • 这三者间有时会关系紧张
   • 和这些人建立联系
   • 任何决策都必需经过这三者，不然很大可能团队会出问题
   • Tech leads有时会有点点远离这些关系。
10. Backlog：确保边界清晰
    • 使用 story trees和 backlog hierarchies（这两个词第一次听是在PMP中，不知道怎么翻译）
    • 人们会为了在组织中获得更高的地位而努力奋斗
    • 你需要从高处俯视你正在建立的东西
11. 代码
    • 确保你有代码的使用权限
    • 保持和代码的联系
    • 找开发给你做一次介绍
      • 找团队的新成员做这个能够理清思路（应该是译错了）
    • 你需要对整个代码库有个完整的印象（包括架构上）
    • 从建立到第一次允许起来可以有多简单？
12. 什么是主要痛点和障碍？
    • 项目经理是讨论这个话题的好人选
13. 跨职能（cross-functional）需求
    • 扩展性
      • 能否降低负载？
    • 安全性
      • 是否有人能入侵它？
    • 自动化
      • 虽然自动化非常棒。但不要陷入一开始就要把所有东西自动化的陷阱里。
      • 自动化不是最高优先级的，你需要发布、交付、部署什么才是。
      • 当你有东西跑起来迭代起来是非常好的，但是开头从0到1，怎么开始。
      • 你想要一些管道，但作为原则，你需要在项目已开始就制定一些守则。
      • 不要浪费大量时间建立一个不可交付的管道。确保你有东西可以迭代。
      • 想象你所建立的产品。它能带给你什么？它能带给你的最核心价值是什么？不要添加任何你不需要的东西
      • 仅在真正需要的时候才进行自动化
      • “你不想结束于成吨的技术债务”
      • 在没能力的时候，你可以花费大量的时间思索出这样的概念
      • 能否同步进行——想想跨职能需求等
      • 可扩展模型
14. 作为Tech Lead，这个项目中最让你害怕的事有哪些？
    • 做些前瞻性的思考，按时间作为横轴列下风险点，但风险点临近时要当心了。
    • 这是风险管理的一部分内容

文章整个读下来，应该是适合于大型的企业项目的，小项目小团队在项目开始时很多都不会考虑这么清楚的。不过很多的点都是非常值得学习、借鉴。