首发：老马农的自耕田
最近我们部门有两位小伙伴被正式任命为了项目组长，结合之前培养带头人的案例,我简单对这两位小伙伴做了一点管理岗的培训工作。今天借助自己的博客，将培训内容进行整理。此为这篇博客文章的由来，希望对有需要的朋友们有所帮助，也希望管理经验丰富的朋友给出更好的建议。
为何选中你
首先，你一定是本职岗位上的优秀员工！在进行岗位调整之前公司一般都会派出专人和你进行沟通以确认你的真实想法。当你收到这样一种信号的时候就意味着你的工作态度和工作能力受到了认可，你一定是研发部门中最优秀的员工之一，要知道技术公司一般不会去选择一个技术平庸的员工来做技术带头人。
其次，你一定有超脱本职岗位的过人之处！相信我，也相信你自己。如果公司想要提升你作为技术带头人，除了出于技术方面的考虑外，很大一部分的原因一定是因为你身上具备的某种他人不具备的特质。比如为人谦逊、坚持原则、足够有主见，甚至还会因为你喜欢写文章而提拔你。
最后，你的人品受到了大家的一致认可！大部分企业的用人标准往往都会把员工的道德品质放在第一位，管理岗位更是如此。正常的公司断然不会将一个品行低劣的人放在重要岗位上。
本身就过硬的专业素质确保你能足够了解你要管理的工作；超脱本职岗位的过人之处可以帮助你快速跳出研发人员的固定思维开启新的工作模式；良好的个人品德帮助你在管理岗位上迅速打造自己的人格魅力。
综上所述，当公司选中你的时候千万不要妄自菲薄，除非你的志向就是成为某一领域的专家而非管理者，否则你可以放心的接受这一新的职务。
适应变化
走上管理岗位意味着你除了要完成之前本职岗位的技术研发工作之外，还要担任额外的管理职责，在这个过程中你将面临很多新的挑战。第一感觉就是，一切都变了。要迅速适应新的岗位你必须对应的做出一些改变来应对这些变化。
在没有成为管理人员之前你的工作节奏相对简单，你几乎不用费什么力气就能规划好自己一天甚至一周的工作，工作中你也几乎不会被任何其他工作之外的事情所干扰。但成为管理人员之后，你需要参加更多的会议、参与更多的技术讨论、撰写技术方案、制定团队内部的工作计划、收集日报或者周报并向你的上级汇报整个团队的工作。时间依旧是原来的八小时，但是工作却凭空多出来了很多，相信这点变化会让你手忙脚乱好一段时间。但是也请不要太过担心，你的上司不会把你放在管理岗位上不管不顾，一般企业都会留给新晋管理人员足够的适应期去应对这种变化。你唯一要做的就是快速转变角色。
参加会议
相当一部分研发人员都认为会议和技术讨论会浪费大量的研发时间。但事实上在很多时候项目的前期调研和计划制定所占项目总体时间的比例越大，项目成功的几率也就越大。这其实很好理解，好的规划可以避免不必要的试错从而避免返工。
试想，如果在你在盖房子之前不做好详细的设计，草草画一张图纸就作为指导性文件，那么在实施过程中工人甚至都不知道正确的工作顺序，不同的工种之间使用不同的标准进行施工，最终要么返工，要么就是你让自己下半辈子都住在全世界最不安全、最丑陋、最反人类设计的房子里。要确定房子的设计图纸和施工步骤以及协作标准，就必须召集设计师、建筑师、施工负责人、装修负责人等等所有的干系人在一起进行一次又一次的会议讨论，最终产出一张大家都很明确且没有异议的可行的设计图纸才能确保在最终得到一栋你理想中的房子。
作为某一个技术小组的负责人你就必须参与类似房屋图纸设计的会议，并且应当在涉及到你的团队工作的部分充分发挥你的业务能力，积极的参与讨论，至少你应当让总设计师知道你能按照什么样的标准做到什么样的程度。最好你还能提出合理化的建议，从你的专业角度提出种种假设和风险预测。最重要的，你应当在方案确定之前勇敢的提出自己可能会面临的困难，约定好你们团队的工作范围以确保以后不会因为约定不清、标准不明确而发生一些大家都不想看到的事情（比如相互甩锅和扯皮）。
总结：作为管理者，你要做出的第一个改变就是代表你的团队成员去参加会议并为整个公司负责。你要清楚的知道，你在会议上的发言代表的是整个团队，你在会议上的承诺是由你整个团队在今后一段时间内来兑现而非你一个人。你还要充分认识到，你的建议会影响整个项目的设计，你必须把自己的顾虑尽早的讲出来，用自己的专业知识为决策人提供正确的决策支撑，还要和项目负责人确定好你的团队的工作内容和考核指标。
会议和技术讨论是最直接的项目沟通方式，不要因为你是新人而畏惧发言，拿出自己的专业素养，大胆讲出自己的合理化建议和顾虑才是一个管理人员该做的事情。尽管你的发言可能还建立普通开发人员的基础上，可能会因为自己还不够了解整个项目而闹很多笑话，也可能会因为你的研发人员特质把大家的话题带偏。但这都是成为一个合格的管理人员必须经历的事情，你要做的只是拿出你初生牛犊不怕虎的勇气，逐渐去累积经验，扩宽视野，打开新的格局，打破自己作为技术人员的天花板，进入新的领域。
重新认识团队
程序员的主要工作内容就是写代码，那么“程序员头子”的主要工作自然就是带领大家写代码了，但这还远远不够。大部分时候你的团队成员都不必去关心自己所实施的项目是用来解决什么问题的，他们只需要关心自己负责的那一小部分如何被人们使用。这就像是盖房子的时候有人只关心如何把自己的四面墙堆砌起来，然后自然会有人在预先留好的洞里安装门窗，那个砌墙的人完全不需要懂如何安装门窗，只需要按照图纸留好安装门窗的位置即可。软件开发工作大多数时候就是这样进行的。
软件开发的协作模式带来的首要问题是软件工程师必须明确知道事务的优先级，最好还能够在团队协作开始之前就估算出来每一项任务大致需要多长时间。盖房子这项工作会被分解为很多步骤，夯实地基一定在砌墙之前，砌墙之后才能安装门窗，有经验的工人还可以让安装门窗的工作和室内装修工作同步进行。软件开发的过程也是一样，有些事情是必须做在另一些之情之前的，我们一般称之为一个任务依赖于另一项任务。有些事情可以和另一些事情在同一个时间段内进行，我们称之为两个任务可以并行开发。还有一些事情必须和另一些事情一起进行验证和调整才能完成，这个时候我们一般采取联调联测的方式来进行。
作为软件研发管理人员，你的最终目的是能够为整个项目决定技术路线，这应当是你的前进方向，你一定时间内的目标应当是成为能够管理整个项目的项目经理或者能够架构整个项目并指导多个团队一起完成生产任务的架构师。要向这一目标迈进，你面临的第一个挑战就是如何做好工作安排并组织生产。你已经不再是那个只需要写好自己那一部分代码就可以完成工作任务的普通码农了，你所考虑的不仅仅是自己的工作何时完成，还应当考虑团队整体的工作如何被完成。你必须足够了解团队内的成员，熟悉他们的工作风格、能力水平、优势和短板甚至他们的性情。
大部分时候团队协作就像是一个通过相互咬合而形成的链条，任何一个人出现问题都可能导致整个团队“掉链子”。要避免这种事情发生，那么你就必须为每个人安排恰到好处的合适的工作，你不能让泥瓦匠去安装门窗，也不能让木工去做粉刷。你必须比你团队里的所有人都有远见和大局意识，绝大部分新手项目组长在优先级排序和工作内容的分配上都能做得很好，但在时间估算上往往都过于乐观，他们一般都会低估多人协作过程中的额外成本，也经常会错误的估算团队成员的工作效率。
研发组长这个职务并不是游戏里的增益状态，你不可能一成为研发组长就能知道团队成员的工作效率和能力，你需要换一种方式去观察你的团队成员一段时间。一种比较好的方式就是记日志，要彻底了解一个人能做什么、适合做什么、他的工作风格是什么、擅长解决哪一类问题以及他不擅长什么，最好的办法就是把他每天的工作内容记录下来。在刚担任研发管理人员的时候，在管理上你甚至可以只去做这一件事。尽可能详尽的记录每一个成员每一天的工作任务、完成进度、遇到的困难以及如何客服的困难、是否加班等所有和开发有关的内容。一般坚持两个礼拜之后，你就可以知道每一个成员的工作状态了。这也许是最笨的团队能力评估办法，但他绝对有效，因为我当时就是用了这个办法去快速了解我的团队。
总结： 软件开发不是一个人在战斗，就像《人月神话》里说的那样，软件团队更像是一支外科手术团队，每个人在团队中都发挥着相应的作用，在关键角色上还会有冗余和备份。作为软件团队的带头人，你可以采用记录工作日志的方法来评估团队成员的行事风格和工作能力。
尽快为自己充电
就像上面说到的那样，项目组长在很多时候既是战斗员也是指挥员。以往的工作中你秉承战斗员的战斗意志，听从上级的号令，在代码世界奋战。但此时，你还必须承担指挥员的指挥职责。要成为一个合格的指挥员，除了本身要具备丰富的战场经验之外，还需要补充一些战术层面的知识。所谓战术层面的知识在软件开发行业即是指项目管理的相关知识。
如果你现在对项目管理一无所知，但你又恰好刚被提拔为团队或者项目小组的带头人，也请不要担心。多参与几次项目碰头会，多做几次技术方案，慢慢的你就可以找到其中的门道。一开始你可能什么也做不好，你甚至连一份完整的技术方案应当包含哪些内容都不知道，你所写出来的技术方案会被修订很多次，你所提出来的技术路线会被推翻很多次，你负责的文档可能会因为不符合行业标准被作废，但这都没关系，没有人是一生下来就能掌握这些知识的！放心，你的上级会尽自己最大的努力去培养你，因为他们不会把你强行放在岗位上却不培养你。你要做的就是虚心的接受他们的调教，尽管有时候他们可能会故意刁难（锻炼）你。
在上级的帮助下去提升新岗位要求的能力无疑是最快的一种方式，但也存在一个重大的隐患。你也许会在上级的指导下逐渐掌握需求报告的撰写技巧、技术方案的标准内容、项目的拆解技巧。但你可能仅仅是学到了一些常识，这些常识仅仅能够确保你在日常工作中不闹笑话，却不能帮助你真正理解如何进行项目管理。你需要系统的去学习项目管理的理论。这些理论大多都是一些干巴巴的范式，但它们能够帮助你认清楚项目管理的本质，重新看待你正在进行的工作。《PMBOOK》是全球公认的项目管理指导性文件，很值得你在今后的一段时间内认真的去学习，本质上《PMBOOK》就是近100年来前人实施多人协作任务的一种经验总结，这本指导性文件详细论述了项目的本质，明确了项目的定义和所具备的要素。涵盖了项目实施应当具备的所有过程以及项目风险管理、资源管理、质量监督、成本管理、采购管理、进度管理、团队建设甚至人与人的关系处理等所有你在实施项目中需要注意的事情。
《PMBOOK》可以指导你去对世界上任何能够被称之为项目的事务进行管理。但它毕竟过于宽泛，在不同的行业你需要对《PMBOOK》体系进行适当的裁剪。除此之外，你可以根据自己所处的行业去学习对应的项目管理知识。如果你所在的行业是互联网行业，那么你应当优先去学习敏捷开发的知识；如果你们公司的2B业务居多，那么你应当优先去学习企业架构知识；如果你们是某一特定行业的解决方案提供商而你恰好打算在这一行业继续发展，除了要学习基本的项目管理知识外，你还应当适当的学习行业的业务知识。
每当你对项目管理理论知识有了新的认识再回过头来回顾自己所参与的项目时，你会发现自己会不自觉地站在一种崭新的角度重新审视自我，这也许就是读书所能带来的妙处。如果你对项目管理有了一些小感悟并迫不及待的希望把这些东西运用到工作中的时候，我需要给你提一个醒，那就是切莫让自己太过理想主义。因为团队带头人所做的每一个决定都应当首先保证团队的稳定，生搬硬套项目管理指南中的内容往往会显得过于极端，强迫自己的团队按照书本中的方法去落实工作往往也是不近人情的，因为软件从业者还真和传统行业从业者有一些区别，相信这点大家应当都深有体会，在这里就不细说了。
总结，很庆幸新手带头人一般都有上级刻意培养，这种培养能使你快速进入新的行当。但要真正成为犹大那样的Master，还需要从基础理论重新学起。你的上级充其量只是教给了你在这个行业充门面的本事，真正的内功心法还需要自己勤修苦练。
结束语
本文仅仅是对新晋管理岗的小伙伴们的一点点指导。文中的方法和路线也仅仅是我从事项目管理几年来的经验之谈，或许还有更好的方法。项目管理是一门实用的技能，他不仅能帮助你更轻松且更科学地完成自己的工作，同时也是对你在认知上的重塑，学习项目管理带来的益处是作用在方方面面的，不仅限于工作。最后，项目管理博大精深，也不是短短一篇博文能够阐述清楚的，如果小伙伴们有更多的想法，也欢迎留下你的评论。
网友评论