致新晋的技术管理者

站在新晋技术管理者的角度，需要思考和解决的问题不是这个bug要怎么修复，也不是这次的故障要怎么处理，而是应该站在整个项目交付的质量和品质角度，全盘考虑软件交付过程中每个环节的指标、流程、人员角色、分工、自动化和目标结果导向的作战计划，甚至还包括配套的研发团队人员激励政策、奖惩机制等。

简而言之，作为技术管理者或新晋的负责人，如果你想根治或想颠覆目前“脏、乱、差”的研发现状（或说得朴实一些，为了提升研发产能和项目交付质量），你需要一套完整的解决方案和思想体系。

为了给新晋的技术管理者，分享一些管理经验和知识，接下来，我会从以下几个方面，分别具体展开。

• 第一篇：每天的任务工时登记和研发产能可视化管理；
• 第二篇：Git代码关联与DevOps自动化协同工作流；
• 第三篇：项目协作、项目管理和项目集；
• 第四篇：双向反馈沟通和如何向上级总结汇报。

由于幅度和时间有限，本次暂且先来分享第一个话题：任务工时。

两个小故事，两点启发

有两个小故事，我觉得是很有启发性的。

第一个小故事，是我曾经在某家上市公司就职时，发现上级领导要求我们统计每个研发团队的有用工时和占比，以此来分析研发的有效产能。相当于把每周每个团队全部人员的每日登记的任务工时，按任务类型进行分组统计，例如：修复缺陷 xx小时、需求开发 xx小时、开会又占了多少小时等。其中，当时的统计口径时，除了需求开发等和产品研发的才算有效工时，修复缺陷等其他无直接关系的则是无效工时。对此，给我的启发是：要确保整体研发的有用功，不做或尽量少做无用功。

第二个小故事，是后来我进来一家发展中的企业做技术管理。每次召集开会时，我都在心里默算这次开会的成本是多少钱。例如：开一次周例会，20多人，按人均每月1万的成本，开会一小时成本 = 20人 x 1万/月/22天/8小时 x 1小时 = 1136元。也就是说，开一次20人的会议，其他成本就要花费约1000多块。当然，员工本要不会考虑这些成本，因为他们只需要完成本职工作即可。那么，技术管理者需要关注这些成本吗？我觉得很有必要。老板之所以选择你来担任负责人，会有他的考虑。其中有一点，就是要求你能在有限的时间、资源、人力和成本内，更加出色地完成所安排的任务或应对挑战。

因此，作为技术管理者，你不仅应该要妥善周全安排会议的前后和跟进事项，还要充分考虑每次召开会议以及其他消耗背后所占用的成本，更要明白、说明和证明你安排和投入的这些宝贵时间、成本能带来多少倍的价值？对此，给我的启发：要衡量每件事情的成本、收益和给企业所带来的价值是什么，有多少（更好的建议是，能花小成本、搞定大事情，并通过数据来总结、证明和展示你的成果）。

你的老板，不会关心你和你的团队用的是什么工具，他关注的是你带领的团队可以解决什么问题、提供什么价值和最终将会取得怎样的成果。老板关心的是结果，这没有错。但对于技术管理者和研发团队而言，过程方式和结果，同等重要。回望过去和现在，我们并不缺协同工具，也不缺流程规范，但是：

为什么老板总觉得团队不够专业？为什么我们交付上线的软件系统总是那么多问题？为什么研发管理这块始终是个“黑洞”无从下手？为什么内部沟通还是存在这么大的阻碍？为什么我们依然觉得研发很痛苦、搞不懂、不可控？

我们到底还缺什么？

YesDev研发协同工具

前面有说到，站在老板的角度，老板关心结果。流程、工具和规范，对老板来说是结果导向过程中的伴生品。

但站在技术管理者的第一视角，特别是新晋的负责人，你要完成自我的角色转变，从以前自己单兵高效作战，转向对整体负责、对结果负责、对问题负责。那么你要掌握凡事，“先记录，后安排；持续跟进，最后总结反馈”的工作模式。

你和你的产品研发团队，要学会和掌握的，不是某一个工具，而是它背后的思想和所带来的价值。找到一款合适、贴切、友好的工具，并掌握如何使用它，对于团队和管理者，都尤其重要。

研发协同工具，在技术管理体系里，是属于最后执行层面的辅助工具，都是最后才来介绍的。我们用什么工具不重要，重要在于我们如何使用这个工具。为了让大家特别是新晋的技术管理者有一个具象、清晰的认识。我们先来简单认识一下这款友好的研发协同工具——YesDev。

YesDev这款友好的研发协同工具 = 任务工时 + Git关联 + 项目协作 + 通知推送。

进一步地，YesDev支持：敏捷开发 / DevOps / Scrum / 瀑布 / 混合研发模型。通过 “YesDev + X” 让研发团队，持续交付更有价值的软件。

回到每天的任务工时登记

每每和研发管理者，一提到“如何让研发人员每天都登记任务工时”，他们就很痛苦。不是说：“他们一线研发人员不愿意登记每日的工时，怎么办？”，就是“如何站在管理者的角度去衡量、评估研人员的工时有没有水分呢？”。

其实，这类问题，我一时间，也不知道怎么回答。直到现在，我才知道应该怎么和这些管理者或老板讲清楚这个道理。

首先，不要本末倒置。我们最终的目的和想要达到的效果是让整体研发的效能最大化和价值最大化，而不是去抓每天有哪些人员没有填写任务工时这些“鸡腿”（当然，这块可以结合公司的规则制度交给行政部门来例行宣导、督促和考核）。所以，我们管理层，自身应当要明白进行任务工时登记的意义何在，以及我们应该要怎么利用好这份数据做出有针对性、有指导性、有前瞻性的洞察、部署和安排。

其次，没有数据的支撑，就很难进行精细化的研发管理和效率提升。我可以比较负责任地说，如果没有任何记录、内部数据和资料，真的就是“两眼一抹黑，决策考核全凭个人主观感觉”，基本很难对现有的研发团队的效能进行评估、分析和改进、提升。简单来说就是，No Data, No Talk。如果想要提升当前研发团队的开发速度、交付速度和响应速度，就需要有任务工时的数据支撑。

那么工时数据怎么来？就需要大家配合来填写任务工时，并且和大家说明登记工时的作用、价值和意义。

任务工时怎么填？还是那几个要求和原则：

原则（1）由任务的一线执行人员来填写、登记和评估（原则：谁做谁评估，我们需要最真实的工时预估）；

通常而言，任务和工时，应该由具体负责执行的一线人员进行评估和登记；个别情况下，可以由上级给下级直接指派特定的任务。如果是和项目或需求有关的任务，则应该同时关联到项目或需求。注意区分：计划完成日期（什么时候可以完成）和任务工时（工作量多少，以小时为单位）的不同。

要求（2）每个任务工时不要越过8小时、越细越好（经验表明：任务拆分越细的人，效率越高，越忙的人越有时间）；

在全览人员团队的任务工时时，技术管理者应该以实际的项目组为单位，进行“前（前一周）、后（后一周）、上（整体的工时完成情况和进度）、下（具体项目成员的工作任务计划和完成细节）”的查阅，通过记录和数据，更贴近地了解和实时掌握一线最真实的研发动态和进度。每个项目组成员，建议不要超过7个人，可以隐藏不需要登记任务工时的人员名单。

要求（3）每周计划个人本周工作计划时，要同时考虑遗留的任务工时（周五前评审新需求，周一做计划）；

历史遗留的任务工时，也要值得注意。在进行下一周工作排期时，要review和回复过往未完成的任务工时。对于已经评估工作量又还没来得及进行开发和任务，应该重新调配和分配。或者经过确认后，删除不需要的任务。拒绝拖延症。如果需要开启任务的延期提醒，可以使用企业管理员账号进入企业管理后台，进行相应的提醒设置和其他高级设置。

登记每日任务工时的价值和作用

有了团队成员每天的任务和工时，接下来，我们需要怎么充分发挥这些数据的价值呢？

任务工时的价值，一方面，不管是作为自己，还是上级、同级和虚线管理的项目经理，都能通过敏捷任务看板、任务工时登记界面，快速查看到个人或工作组的工作计划和时间安排，方便快速协作。

任务工时的价值，另一方面，在于除了汇总个人的工时和工作饱和度外，还可以站在项目和需求的维度，自动汇总项目的研发进度、需求进度、需求排期、项目排期表、项目燃尽图、项目甘特图等实时自动汇总刷新并且能增量进行跟踪的数据、表格和图表等。

例如，可以持续跟进变化的项目排期表，

以及项目开发计划表，

又如，项目内的敏捷任务看板，也可以用于每日站会的同步沟通和立即更新。

在分配和创建新任务时，也可以结合已经安排的任务量和放假时间，获取即时反馈，从而做出更合理的工作安排。

任务工时的闭环管理

接下来，继续沿着每日任务工时登记这一件小事出发，把工作汇总、日报/周报/月报、定期反馈和行政考核等进行串联，完成整体的研发产能闭环管理。

导出每周团队的统计工时

在每周五，在编写周报时，可以通过【导出Excel】来快速导出自己团队的人员工时。

导出来的成员工时，按每周进行汇总。Excel导出效果类似：

月底导出整体团队的任务工时

如果行政人员需要考核研发团队的每日任务工时，则可以进入任务工时查询，选择自己所在的工作组和时间范围，进行筛选和全部导出到Excel。

导出后，可以把Excel文件发给行政人员，进行快捷的各种排序、过滤、统计和考核。

诸如：

年度的绩效考核数据参考

到了年底和进行年度考核时，可以再结合YesDev提供的团队分析数据，对员工每个人的分布、对比和表现进行多维度的评估和参考。

例如，需求、工时和Bug，在效率、时间和质量，这三者两两之间，我们可以较好看出团队成员哪些是分布在高效、高产、高质量区域，哪些是在低效、低产、低质量的区域。

小闭环、大协同

让一线员工和团队成员，能有清晰的执行清单；让技术管理者能有明确的整体提升计划和落地方案；让行政人员能获取到考核所需要的指标、数据和记录；让老板看到持续不断有新的变化和改善的感觉；最终让成果共同被看见。

在这期间，要做好记录，做好沟通，提前安排，持续跟进，中途别忘了及时反馈，最后总结。

研发不易，可以先从任务工时这一个常用且简单的小闭环入手，敢于提出自己的想法、观点和计划，并且敢于去执行和督促。相信，持续一个月，便能共同看到大协同下的新效果。

^_^