V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 970 天前的主题，其中的信息可能已经有所发展或是发生改变。

背景介绍

目前我司前端项目里有一个大的模块正在实现，先简单的说一下我们的研发流程：

项目经理和产品经理确定需求给出原型和需求文档
前端开始技术评审确定实现方案
该模块的参与人员进行任务评估
开发人员进行最小可行性测试验证设计师同步进行 UI 设计
开发任务录入到任务管理工具并分配到具体的执行者
小的任务开发完会转测
开发到一定阶段代码进行合并将不同分支的功能合并至开发分支
预发布时线上灰度测试
测试那边进行详尽的测试认为达到预期则准备合并到发布分支准备发布

目前遇到的问题

开发人员无法准确评估时间我们是开发人员先自行评估时间项目经理批复后确定任务周期
任务经常严重逾期

该任务参与人员规模

设计师 2
前端开发 5
项目经理 1
产品经理 1
后端 2
测试 2

诉求

参考更高效的目标管理模式，争取改善当前的局面

任务

开发

经理

测试

28 条回复 • 2022-04-07 18:49:03 +08:00

redtech

2022-04-06 10:59:28 +08:00

期望是能逐步改善毕竟现有的模式大家比较熟悉但是存在的痛点蛮多的

shintendo

2022-04-06 11:05:19 +08:00

开发人员无法准确评估时间，说明任务拆解得不够细

fe619742721

2022-04-06 11:07:10 +08:00

你们这个人员配比好奇怪，5 前端对 2 后端？

你的问题：任务详细拆解+任务中实时跟进调整，慢慢积累经验，没有其他的好办法，

HannibaI

2022-04-06 11:08:40 +08:00

楼主是作为一个什么角色参与到开发流程中的？

Ycode

2022-04-06 11:45:18 +08:00

程序员评估时间是天生乐观，以下看书和个人经历经验
1 、拆分详细模块；模块之间往往不可能完全独立，开发前需要评估完全独立的模块和无法拆分的模块。无法拆分的大模块交给一个人负责，另外配备一个副手帮助他确认沟通和文书方面的工作，必要时可以协助写代码，但没有决定权
2 、一个把控全局的架构师，由他完成模块拆分，决定所有设计细节。其他人不要发挥个性；
3 、模块开发时间 = 编码时间 + 功能自测时间 + 交流沟通时间；其中编码时间很多时候只能占到 1/3 ；沟通往往是最耗时的，而评估时间大部分人只会评估编码时间；项目在管理时应该在开发人员评估的时间基础上有所保留；
4 、详细的进度跟踪，每天至少 1 小时时间评审代码，汇报进度是必要的
5 、多频次，小规模迭代；无论是评审代码还是测试，小规模意味着更小的影响，更完善的代码评审，更好的测试质量；
6 、项目完结复盘：存在的问题，bug 率，改进建议

redtech

2022-04-06 12:11:03 +08:00

@fe619742721 感谢总体功能并不庞大只是有一两个任务单元有些挑战是富文本编辑器相关的东西

redtech

2022-04-06 12:12:15 +08:00

@Ycode 感谢回复你说的很详细了我仔细看看

redtech

2022-04-06 12:14:56 +08:00

@fe619742721 这个模块任务的工作量大多数在前端

redtech

2022-04-06 12:15:28 +08:00

@HannibaI 可以理解为类似 “组长” 对最终的结果负责

yl20181003

2022-04-06 12:28:38 +08:00

开发评审的时间，你需要复审，太短或者太乐观，要给他加上去，然后再根据经验值再调整，比如除以 0.85 之类，逾期次数多了，压力就在你这了

zhuangzhuang1988

2022-04-06 12:29:31 +08:00

永远估算不准的.

yl20181003

2022-04-06 12:30:01 +08:00

富文本或者，低代码这种，能要多长要多长，做着做着就卡壳，是很正常的 😂

RiceNoodle

2022-04-06 12:34:23 +08:00

一般估计工时的时候，都要取决于任务复杂度留出 buffer time 。
我常用 1.3 的系数，例如三天的活儿，就有 3*1.3 = 4 天，也就是 1 天的 buffer time 处理各种阻塞。

Torpedo

2022-04-06 12:41:46 +08:00

@redtech 拆任务，同时给出各个任务的技术方案。接口也完全对完，再出排期

swulling

2022-04-06 12:44:58 +08:00

既然每次都估算不准，那就挖掘历史得到倍率。

比如之前预估 3 天，实际做了 6 天，倍率是 2 。那么后续所有任务开发自评后，统一 x2 就行了。

lamour0922

2022-04-06 13:53:27 +08:00

前端也做技术评审吗😂 我这只有后端做，排期什么的也是以后端为准，一个前端对 2~3 个后端

redtech

2022-04-06 14:19:18 +08:00

@lamour0922 方向不太一样这个模块具有一定挑战性不是简单的业务

ChangJingli

2022-04-06 14:22:56 +08:00

《提高工时估计准确性 - Thoughtworks 》 https://insights.thoughtworks.cn/project-time-estimation/

3dwelcome

2022-04-06 14:42:40 +08:00

根据二八定律，一个项目里，20%的高难度功能需要花去 80%的开发时间。

如果把高难度剔除，只保留低难度，还是不能按期完成，那就是工作不饱和的原因了。

以前见过简单暴力的方法，就是酒店封闭式开发，效率还是很高的。

redtech

2022-04-06 14:55:11 +08:00

@ChangJingli 感谢推荐

redtech

2022-04-06 14:56:13 +08:00

@3dwelcome 感谢回复封闭式开发执行起来的难度过大但是我也在思考类似能让大家尽快投入到阶段性工作的模式

redtech

2022-04-06 14:56:33 +08:00

@yl20181003 卡壳的时间确实是蛮难把控的

lldld

2022-04-06 16:48:28 +08:00

无法准确评估时间, 这个有复盘是什么原因评估错误吗? 因为需求不明确, 使用了新技术, 新工具, 需求的难度远超开发者的能力? 如果没有原因, 也不排除是被迫评估了一个领导希望的时间.

redtech

2022-04-06 16:49:53 +08:00

@lldld 需求的难度超过开发者的能力也是存在的

jones2000

2022-04-07 02:20:16 +08:00

一般 3-4 年开发人员，如果不是新的业务，或没有接触过的技术，一般评估时间八九不离十的，开发评估的时间*1.5 上报。
如果有技术难点，公司如果有专门的研发小组，直接给他们搞，如果没有直接购买商用插件，这样有技术支持，开发会很快。如果是改开源的建议直接联系开源作者，给钱定制修改。5 个前端砍掉 1-2 个，砍下来的钱买商用插件或定制开发。