Answers:
在其他开发人员向高级或领导职位过渡的过程中，我见过这次旅行。这是我对其他人的一些建议。
通常，并不是所有已推入项目的功能。它涉及解决业务需求的一组核心功能。请始终牢记这一点，因为这是您的主要目标。
分解项目应该非常简单。尽早在项目中对其进行分解。如果您必须修饰零件，请理解它们会带来风险，直到您了解必须执行的操作为止。
最初，您将无法解决所有歧义（尽管您应该尝试）。确保您的经理和项目利益相关者了解他们是什么以及对项目造成的风险。
确保每个人（理想情况下每天都知道，但每周工作一次）知道项目的状态。所谓状态，是指已完成的工作，尚要做的工作，未解决的问题，问题等。任何可能影响项目完成的因素都应报告。
您应该每天花一个小时浏览大图。问自己问题。完成了什么？还剩下什么呢？有哪些未解决的问题？目标是什么？您可以随时向某人询问项目的详细状态。
我将向您提供的第一条建议是，接受团队管理比执行自己的编程任务更为关键。这意味着当您有3个需要帮助的下级时，您的工作就是不要抱怨如何使您脱离发展中。作为领导，如果您首先过于专注于自己的开发任务，那么通常会成为前进的障碍。
另外，您需要学习委托。当您可以在一个小时内轻松完成任务并且知道他们会挣扎一天时，很难将任务交给某人。但是，除非获得任务，否则他们将永远不会进步，并且您将在团队玩游戏时加班。
此外，永远不要只修正别人的代码。告诉他们哪里出了问题（及其原因），然后让他们解决。否则您将陷入一个周期，必须修复所有问题，因为它们没有得到任何改善。如果他们无法解决问题，请考虑是否应该留在团队中。不要让弱小的团队成员留下来，因为您正在解决他们所做的一切。
作为领导，您会成为坏人，并给他们带来不愉快的消息（上下链）。这也与工作相关。这意味着您必须进行不良的绩效评估；您必须告诉他们截止日期已提前或要求已更改；您需要推动没有进步的懒惰家伙；而且您必须告诉您的上司什么时候不能满足期限，原因以及您在做什么。领导不是要被人喜欢，而是要有效。您的工作是将软件发布出去，而不是交朋友。沟通是关键，避免坏消息最终会使情况变得更糟。客户被告知，比启动日期过去后，他们每月要比发布时间多三个星期，然后您告诉他们您还需要三周。
这是我的非正式清单。这是非常非正式的……我每天都不做任何事情，但是如果我每周没有打这些东西，我会有些担心，如果我每个月都打不起来，我会感到恐慌。里程数完全取决于公司/团队的文化，个人风格和项目类型。
与团队单独交谈-团队中的每个人都有要做的有益工作吗？知道产品和当前版本的总体目标是什么？他们是否知道您如何赚钱以及您业务的主要目标是什么？他们是否知道他们目前的工作与所有这些工作相符？
与团队集体交谈 -将他们与重大新闻放在一起，让小组聚在一起，以确保无论有没有您都可以进行交流。作为一个小团队，这可能是小组策略会议。随着团队的壮大，您将不得不指导他们掌握要点，并且不可避免地会成为您在他们面前讲话的场景。没错-有时候，每个人听到您对所有人说出公共信息非常重要。所以每个人都知道您正在普遍地提供信息。但是，“每个人”会议与小组战略会议有很大的不同，在小组战略会议中您更多地是一个指南。
采样团队的工作 -尝试对每个人的工作进行一些调查。阅读他们的代码，运行他们的功能，尝试他们的测试用例。不要针对每个人的100％的工作，请尝试从每个人那里取样。给他们反馈，同时消除整个团队的优势和劣势。
尽早并经常与您的管理层联系 -这不是一个小问题，这是一个循环。如果您不知道管理层的需求以及管理层的想法，那么您的团队将如何满足期望？您需要与您的老板有非常好的回酬，您需要以他的团队成员的方式加入他的团队。能够在琐碎的事情上与老板进行有效的沟通可以增强信心，使您能够在危机到来时获得帮助并清晰地理解。对于大盲人来说，这也是一个很好的现实检查。
定期检查团队资源 -当以前可用的资源变得不可用时，人们会尖叫，但要检查未知的疼痛点。你的瓶颈在哪里？是否有一些有用的新工具？我认为大多数团队都是“工具猎手”，总是跟上最新，最出色的工具。平衡Tool Hunter与GuyWhoHatesEverythingNew之间的对话，以找到下一步发展的方向。工具包括一切-软件，硬件，物理空间，学习资源。
了解并与支持团队保持联系。 每个公司都不尽相同，但都知道负责您的质量控制，文档撰写，法律，设施，财务以及您公司独有的其他支持小组的人员。它们是我能想到的最好的全局触发器，因为它们看到的世界与您完全不同。
了解您的竞争 -每周至少花费一些时间弄清楚某人如果不使用您的产品将如何解决您的产品所解决的问题。它可能不是一家公司，但是其他解决方案可以为您提供什么呢？
查看费用和时间表-您的团队表示当前截止日期的可能性有多大？下一个截止日期怎么样？您的费用消耗率是多少？您还没有为即将购买的大型商品付款？您的预算还剩下什么？具体细节随您进行财务跟踪的方式而异，但是即使在一家非常非正式的公司中，您也应该对剩余的天/周/月预算以及当前产品的截止日期有所了解。在某个地方，有人最好计划“我们需要多少人来完成这项工作？” 和“我们能否负担下个月/季度/年的费用？”。您需要知道这些数字，并在后续步骤中进行输入。下周您需要一个明确的计划，如果有人走进来问，您现在就可以解释。你下个月需要一个很好的计划，当现实发生时，它只会在2-3个地方发生变化。您需要为该季度制定一个粗略的计划，并为年度制定一个总体规划。除此之外，即使在大型项目中，数字也只是数字。听他们的话，但要意识到没有人签名。
那是我的头等大事。我通常会添加它，因为我会被“惊喜”打在头上（想象我对错过的区域非常敏感，然后我将其折叠到检查清单中。g“惊喜”带有强制的咧嘴和沙哑的牙齿） ）。
另外-为恐惧上下文切换做准备。如果您刚刚开始进行管理，则可能是您的团队很小，而管理层中的某个人则认为花一些时间管理团队并做一些个人贡献者工作会很好。可以这样做，但是两者之间的上下文切换很困难。计划一下。抽出时间进行切换（例如在午餐前后），了解自己不太熟练的技能，并意识到您需要将自己拖到那儿几次，所以请预留时间来做一些“与大事有关”的事情，您至少需要两个小时才能真正到达目的地。
上下文切换在两个方向上都起作用-管理到动手工作，反之亦然。但是，当您从力量和练习的角度出发，到不舒服而少练习的地方时，您会感到更多的痛苦，而退却的动力很强。在那儿了解它，并与之搏斗，并意识到在全局范围内晃动可以使您更好地将其全部吸收。给自己一些时间进行晃动。
阅读本书：放牧猫：引导程序员的程序员入门
不久前，我把这本书送给老板，他很喜欢。当我阅读它时，似乎他知道他在说什么。就是这样。作者讲述了自己的经历。不是经理的“简单事实”的集合-这些是前程序员的话。应该理解，这是他的HIS经验，但您的情况可能有所不同。因此，在某些事情上，您应该认真看待。“经理不再是程序员-这很重要”。
当我最近接管一家小公司的技术领导职务时，我没有开发产品，我发现对管理事情非常有帮助的是用简单的英语记录产品的运作情况（我在黄瓜中记录的功能以及内部使用的功能）我写下了对象模型的说明，并介绍了各种控制器的流程。我发现这样做的结果是：A）产品有点混乱：) B）我更快地了解了该应用程序的工作方式，因此我可以就存在哪些问题以及需要重构哪些内容进行明智的对话，或实现给定功能所需的费用。
图片也有帮助-我不会弄乱像Visio这样的产品，我只是用蜡笔和白纸（确实如此，我会做的-我在家工作，通常和我2岁的孩子在一起），但是对您有用的是您应该使用的。