随着工作年限的增加，技术人员不能仅限于纯编码与技术方案，而是需要作为团队担当同时去整体交付任务，这样也带来了新的挑战。对于入门者，首当其冲的就是时间分配与劳而无功问题。

本文以Tech Leader为例，通过枚举时间分配，将部分不增值的时间外部化，以提高总体交付乘积效率。

背景

项目背景

H司对项目的强交付要求，与外企是不一样的，不存在类似外企的Project/Career多个经理等分工，而只有交付经理（招聘、需求、落地、进展与PPT全包），所谓的三人发四人工资干五人活。

一方で，在任何商业竞争中，核心都是快，唯快不破，快到让任何对手都来不及抄袭，快到你的项目成为唯一选择（而不是将战线延长到后期数十家竞争）。为了快，有些代价（质量，人力，未完善的场景）是必须要承担的。

• 你要快速占领用户，就算你自己知道败絮其中，也要让对手决策认为大势已去
• 你要经验丰富，不能让对手抓到致命漏洞的好时机

具体到底有多快，节奏如何，需要一个经验丰富的领导者/创业者来实施的，本文就不讨论这些了

时间为啥不够用

在大公司中，组长通常由专业技术族选拔而来，虽然固有scrum master的名号，但也有大量的编码与技术工作，以下是一个大厂小组长（大头兵）的实际工作项

• 售前介绍（technical walk-through），需求采集，场景分析，技术方案，工时导入（拆解/录入/跟踪/验收），运维售后，扯皮对齐

• 杂项：组员不断打断的决策要请，临时插队的需求或工作（比如帮别的组招聘），招聘、考评，汇报、PPT、缓解领导焦虑等工作

这些带来的问题就是疲惫中失去了方向，表现为

• 在竞争压力下，通常总是先解决眼前最简单的不赔本的工作，而更大、更重要的场景分析等决策类工作却一拖再拖。
• 陷入光环效应与细节（比如js/css体验改进，繁琐的管理轮询活动），管理微操过多
• 陷入沉没成本，担心组员因为没有活而陷入空转被C考评，因此为了输出而输出（组织僵化从这里就开始了）

这时项目就有危机了，已经陷入能力陷阱，劳而无功，就算给项目增派人手也没有用了。这个本质上就是加杠杆后的爆仓问题。

组织结构矛盾

上述时间短缺问题实际上在《千高原》这本书中也有介绍过，即“平滑”与“纹理”。这两种状态是二元对立的

• 如果你想加快交付速度，那么工作重点将类似全职经理人，通过投入事无巨细的精细化管理活动，效仿泰勒的工厂流程，压抑不确定性，实现精算且明确的计划。这种状态是很昂贵且脆弱的，但是速度真的快。就像台积电一样，复杂昂贵的芯片制造也能做到平民价格。
• 如果你希望加快场景探索，或者加大团队冗余，那么更加类似于单打独斗，团队就更加放养（stand alone complex），但是不确定性也会上升。

复杂理论可以证明，上述状态各有千秋，你费力维护的金字塔式小组虽然表面上看似高效精干，实际上单点故障更多，无法抵挡浪涌，更容易一瞬间溃败。但是仍然很强，假如再加上996，从公司间竞争来看，这种劳动的低价倾销的确有竞争优势。

时间短缺化对策

这两个问题让我纠结了数年，学费可不低。下面是改进方法主要从个人、组织上进行改善。

注意：以下对策只适用于已经形成良好迭代惯性，却劳而无功的陷入瓶颈的项目

对项目规划进行定位

每个人所在的工作岗位与工作目标都不相同，在人力短缺问题讨论前，要先确保利害关系。

• 高管/Sponsor对当前项目组的定位是什么，保持惯性不爆雷即可还是有增长要求？完成用户新需求会被认可吗？
• 直接领导对项目的定位是什么？是苟一苟等退休，是借A项目人投入到B的牺牲品，还是想再改改？领导是否有系统化的管理能力？
• 你对项目的看法是什么？是成就产品，是投机出KPI做出一个四不像，还是干一年算一年？这三者在大公司的项目中很难兼得，因为有产品能力的人很难适应大公司环境。
• 项目组员对项目是什么看法？是改改能用，还是想再努力一把？

一定要记住在大公司中“保持现状”就等于不进则退，断粮等死。

对管理动作进行定位

项目管理是对人力调度的管理，即买入员工工时，卖出产品交付的活动，核心仍然还是时间、成本和质量。其中比较重要的是大致正确的方向，大致正确的时间估算，以及合理的成本价格。

方向大致正确

项目内尽可能只专精一条方向，不能”并行全都要“，互联网公司（比如跳动或PDD）的“试金石”是不惜员工健康作为代价的超短周期试错，买菜A项目凉了，教育B项目凉了，换一个方向捞钱就可以。失败是正常的，就算头条这种公司，也每个月都有挂掉的项目。

管理层说的“全都要”是不可能实现的，对项目的投入只有两种分类：增长或停滞等死。然而对个人来说，一不小心就成代价了，因此最重要的事情是对项目进行tradeoff

• 管理层认为保持现状的项目，就拖着不死即可，不要想着去还债，毕竟债务是还不完的。
• 管理层认为要增长的项目，看自己是否还有上升空间。你自己觉得重要就做，不重要就自行决定去留。

时间大致吻合

永远不要透支时间，用自己与组员的加班时间用来规划时间点，因为大部分人都会低估时间，一旦项目质量问题与意外接踵而至时，项目就完了。避免打疲劳战，身体健康优先，保持锻炼，否则你与组员可能会患上免疫力低下、内分泌失调、肥胖症、心率不齐等疾病。

你自己估算需要完成的时间分解给组员去做，耗时一般需要乘以三，估算准才有意义

成本与质量符合市场

合理分配资金包和升级包，匹配市场价格，最终接受相应的产品质量。方案如下

• 通过考试，自动化工具等提高质量
• 让组织充满活力，别让人跑了，尽可能给出确定性

将全部工作分出去

以下是管理投入的三种场景

作为组长，除了管理角色，还有技术或场景攻克等工作内容，管理动作的分配自然会降低，因此要尽可能把自己的所有工作全部手册化并清空（持续压缩或转移工作量），流出大量空余时间才能思考更重要的事情。

正当我以为自己可以置身事外时，他们却把我拉了回来。

如果项目中出现“劳而无功”的瓶颈，这时就要降低你自己的管理活动，找出限制步骤，防止瞎忙。

• 管理事务工作：形成惯性后，scrum master的事务类工作指派给一个组员来干（周会，进展）

放权技术的工时：

• 已经运行稳定的优化任务：不再参与落地设计，只看组员的方案汇报（高阶设计时就要考虑low-code/visualize/portal等方案，如果你没考虑，说明SaaS水平不行）
• 业务需求：完全让开发人员进行原型设计，高阶技术设计与落地实现。
• 你认为组员慢的：慢可以接受。假如某个功能开发，你自己亲自写需要两小时，但是让组员写可能要折腾两天，那你要也分出去，后续你就可以用高语境来回本了，即使人工传递是有损耗，你也一定要分下去。再不行就换人。
• 你没搞过但是觉得不难的任务：只出指标，给一个宽松时间，让组员去POC、评估工时与写PPT给你汇报
• 你自己也不会的任务：让组员去POC、评估工时与写报告，但是要进行定期check
• 现有债务与阻塞：指定度量标准，让某个组员去POC、写方案与评估工时，到时候只评审
• 组员找你开会的时间太长：培训组员写更完备的方案，降低开会时间。

这里有人可能就不满了，那组长岂不是管理重心过高，天天看汇报了？这个无所谓，大部分软件并不需要人人都是精英，富士康模式就是最高效的倾销模式，控制好质量的标准差就是最好的管理。

质量控制

• 自动化与考试：降低代码审核时间

  • 能够自动化与度量的问题（比如静态扫描）一定要清空，这种稳赔不赚，而且可以防止破窗效应
  • 安全编码/编程规范等问题，面试是难以识别的，通过考试让全员掌握

• 摆正心态，认识自己与同事的平庸，不要焦虑。你不是全知全能的神，项目离开你一定照样能跑。

  • 你觉得别人慢：不要急，定期问一下即可。
  • 别人觉得你慢：不要别人催你你就开始慌，决策权在你这里。

• 控制好验收、上线、运维的度量标准，测试要基于用户场景进行测试，而不是简单的点点点，作为高阶设计者是要输出测试标准。

• 遇到能力弱的组员，保持心情通畅，不要自己生闷气与焦虑（会导致皮质醇异常），也不要爱惜自己的羽毛

  • 年龄大的员工要把压力给传导下去，把旧公司的习惯给纠正过来
  • 年龄小的要稍微耐心点，不要惯着陪加班，不要打压自尊
  • 实在不行的，进行绩效改进计划（PIP），给出截止日期，再不行只能开除

• 放弃强迫症，将缺陷记录归档为债务，看作资产负债表。这种属于不良债务的杠杆，没必要当月清除，能拖就拖，100%完美架构是代价高昂的，而且ROI也很低。

基于专注度的组织改善

基于专注度划分任务：这两种时间分类在标记任务时，建议加到tag里，因为间断的时间很难估算，但是非常重要。

• continuous: 完整连续的时间
• fragment: 间断的短期时间

在项目中，组员的角色要进行分离，而不是混到一起统称为“研发”。我们可以按照“专注度”强化分工角色

• RD Team: 设计与编码工作，一定要避免核心开发被频繁打断
• Support Team: 支撑与客服工作，注定会被频发打断，考评要倾斜
• DevOps Team: 开始有开发兼任，后续需要专人处理运维。

项目的后期千万不能让一个人既进行开发工作，又负责Sales&Support工作，那样时间估算会乱套的。

虽然标题写的是组织，但是就算你只有一个人，也要这么将时间按照上述角色进行分块，否则人被频繁打断会很疲惫的。

总结

通过上述改进后，个人的工作时间大量释放，质量也没有显著降低

• 获得了不被打扰且连续的高阶Portal设计、技术方案与预研时间
• 大部分工作用于收集与处理信息流（反馈，例外或者评审）
• 对工作项的验收与质量监理成为了新的挑战

附录

个人总结

我认为软件行业，在未来随着基础云化软件的成熟，从零开始的机会越来越少，未来的核心将是场景创新

• 未来软件知识贬值越来越快，管理经验将高度分化且冗长，
  • 低端类管理者沦为工厂领班，转为永无天日的富士康模式、对日外包、low-code/no-code开发
  • 高端类的将类似经理人角色，基本脱离一线编码
  • 任何工作都需要复盘再复盘，持续改进，才能进步
• 高端类IT技术工作将转为医生、律师、快消类的CPTcode工作模式，将形成行业组织或者创业伙伴

对于个人来说，除了八股文外，一定要掌握“组装”的活用技巧，否则很快会被淘汰。