技术主管是做什么的？
我即将卸任Signavio的技术主管一职。上次回顾会议上，一项待办事项是让我整理一份我的职责清单。考虑到我十二月就要离开公司了，这确实很有必要。然而，我目前并没有一份固定的工作清单。所以，这篇博文并非旨在介绍所有技术主管的工作内容，而是着重介绍我作为技术主管的具体工作。
太长不看
这次不会有“太长不看”的总结。如果你认为成为优秀领导者有捷径，那你打开的文章就错了。
不要成为瓶颈
我听说有些人认为，作为领导者，事事都要亲力亲为。我完全不同意这种观点！你需要信任你的团队成员，让他们各司其职。否则，你将永远忙得不可开交，也就意味着你永远无法真正提高效率。
从宏观层面来说，我需要了解周围发生的一切。
- 目前有哪些项目正在进行中？
- 接下来是什么？
- 该团队是否受到任何阻碍？
- 基础设施是否已启动并正常运行？
- 我们需要进行哪些关键更新？
因为我必须确保一切顺利进行，所以我不能过于专注于某个特定主题。即使我负责最重要的功能，也不能完全忽略工作的其他方面。结果就是，我明明负责最重要的功能，却在做其他事情。这可不好！
我尝试通过不编写用户故事来避免这种情况。至少我不会把它们放到“进行中”一栏。这样一来，我仍然可以和其他开发者结对编程，但有人等着我完成某个用户故事的可能性就非常低了。
帮助他人成长和学习
如果你不帮助他人提升工作能力，我就不会认为你是一位领导者。遗憾的是，我也逐渐明白，做到这一点说起来容易做起来难。以下是我犯过的一些错误。
像发放免费糖果一样发放解决方案
当有人问你问题时，你的第一反应可能是回答。这很正常。但这样做会剥夺他们学习的机会。因为只有当你自己找到解决方案，并且理解了所有步骤之后，你才能真正学到东西。否则，下次遇到类似问题时，你可能只会再来问我。而这种做法是行不通的！
我总结了一套解决问题的规则，现在正尝试教给大家。我会问一些问题，比如“你已经尝试过哪些方法了？”或者“你知道什么？你不知道什么？”。这些问题应该能帮助你的大脑自主地找到问题的答案。
如果一个人需要学习某些东西，那么每个人都可以学习某些东西。
结对编程不错，但群体编程更好！
起初，当我们涉足一个新领域时，新知识仅限于参与第一个用户故事开发的那一两个人。虽然聊胜于无，但我们仍然需要反复进行几次主题介绍。这导致不同的人对问题的理解各不相同，造成了大量的返工。现在，每当有新主题出现时，我们都会提前召开团队会议，确保每个人都理解并认同问题。我们（通常）也会一起着手研究这个主题。这意味着整个团队都会参与到第一个用户故事的开发中。听起来好像我们在浪费很多时间，但我认为我们实际上节省了很多时间，因为这样可以减少误解和返工。
不了解别人如何看待我
你说的话固然重要，但说话的方式也同样重要。我曾经就因为意识到，有时哪怕是呼气声音过大都会让对方感到压力，阻碍他们学习。对我帮助最大的是学习非暴力沟通，以及如何运用这种沟通方式让周围的人感到更自在。这也让我明白，我自己也需要清晰地表达自己的需求，因为如果我感到沮丧，对沟通也没有任何帮助。
此外，不要把请求伪装成要求。
帮助人们犯更小的错误
漏洞难免出现，错误也难免发生。但是，您可以积极帮助团队降低问题和错误造成的严重程度。
当危机来临时，最重要的是保持冷静。在危机之中仓促行事毫无益处。危机过后，你需要确保它不会再次发生。为了做到这一点，需要做到两件事：
- 每个人都需要了解发生了什么以及为什么会发生这件事。
- 你需要检查一下，改变团队的流程是否能防止类似事件再次发生。
你的职责是确保这两项行动都得到落实。你无需负责所有解释或提出调整方案，但你必须确保这些工作得到妥善完成。
以下是我们团队为避免大规模缺陷而采取的一些措施（我曾在博客中提到过），但并非全部。
- 我们尽可能多地采用测试驱动开发（TDD） 。
- 我们编写测试用例来帮助我们更快地发现和修复缺陷。
- 我们总能查明问题的根源，而且
- 我们不断改进工作方式。
提高他人的生产力
我见过一些人把这理解为“提高团队中其他技术人员的工作效率”。不幸的是，这种理解忽略了你每天都会接触到的很多人。以下两类人你可能无意中忽略了，但其实你不应该这样做。
你会帮助产品负责人吗？
好的，如果您没有产品负责人（PO），则可以忽略这部分。
我的团队有一位非常优秀的产品负责人。她总是尽力保持平易近人，并尽可能多地从客户那里收集结构化的反馈。过去，她还负责编写我们的大部分用户故事。问题在于，编写用户故事并非她应该花费最多时间的工作。为什么呢？因为她既需要编写用户故事，也需要在开发人员接手时进行解释。这可能会非常繁琐。
我们也遇到过这样的情况：用户故事被拆分，虽然这种拆分方式对最终用户来说合情合理，但却没有考虑到我们的系统设计。这有时会导致我们花费更多的时间在两个用户故事上，而如果只做一个用户故事，则无需如此。
我们已经讨论过这个问题，并调整了流程，让开发人员在开会讨论后自行编写用户故事。在开会讨论中，我们确保每个人都理解了我们要解决的问题。我们的产品负责人 (PO) 会负责主持这些会议。这样，问题就可以在一个更大的团队中提出和解答。
你们是否将设计融入到开发流程中？
说实话，我还没弄明白。
我尽量避免交接环节。我觉得交接这种做法有点糟糕，因为它暗示有些人可以把所有事情都想清楚，然后就万事大吉了。我从没见过这种做法奏效。
我们的设计师们做得非常出色。然而，他们毕竟是人，所以也会遗忘或犯错。如果他们花了两个星期设计一个方案，然后交给工程师，结果工程师发现这个方案根本行不通，那他们就白白浪费了大量时间。我希望看到的是设计师和开发人员能够合作，共同开发这些功能。
但是……我还没找到让这件事成功的灵丹妙药。我尝试的是以身作则。
- 我尽量让我们的设计师尽早参与到设计过程中来，
- 我明确表示，任何事情都不是一成不变的，我们总能改变现状。
- 我试图向设计师灌输循序渐进发展的理念（我发现他们中的一些人对这种理念有些抵触）。
我希望通过以上措施，随着时间的推移，设计师和开发人员能够平等相待，并更加紧密地合作。
留出一些时间进行自我反思
即便我可能要重复一遍，但我还是要再说一遍：你不应该总是忙个不停。作为技术主管，你也需要留出时间思考和反省。
我有时会在压力很大的时候重读自己之前在公关稿上写的评论。很有可能，我当时的压力情绪会影响到我的语气。如果因为我心情不好而让别人感到不舒服，那就太糟糕了。我不想成为那样的人，所以我会尽可能地改正自己的错误。
此外，今年写博客对我的帮助很大。写博文之前，我需要先理清思路。有时我还需要将某些思考过程可视化。这不仅能让别人了解我的想法，也能帮助我思考自己想成为怎样的人。我觉得在写关于目标、过程和沟通的文章时，我也反思了自己过去做错的事情，以及未来想要改进的地方。
这次我想再次强调，我非常感谢大家对本文的任何形式的反馈。如有任何问题、意见或建议，欢迎随时联系@philgiese ，分享您在领导开发团队时可以尝试的方法。
-
当然，我偶尔也会参与用户故事的编写。凡事总有例外。最重要的是，我时刻关注着周围发生的事情 。
-
我们正在使用看板，这意味着任务会经历不同的阶段。当有人领取任务进行处理时，任务就会进入“进行中”列，以便所有人都能看到任务正在进行中 。