这是一个创建于 108 天前的主题，其中的信息可能已经有所发展或是发生改变。
例如项目开始后，如何分配 WBS
针对某一问题，如何通过 Jira 中哪些功能，能看出该人的工作效率、质量等完成情况，如何对人进行客观的评价
请教各位 V 友们，使用过 Jira 并对 Jira 有一定认识的朋友们给点建议。
第 1 条附言 · 108 天前
主要是看使用什么软件能尽可能缩短这个工期延期的时间。
28 条回复 • 2024-08-07 12:21:07 +08:00
 |
1
wildmaker 108 天前 via iPhone
看样子只能用报表横向对比故事点消耗速率和 Bug 数量？前提是用的比较规范，及时填写故事点和实际工时
|
 |
2
RandomJoke 108 天前
本质就是不断更新 jira issue 的状态，通过各种状态来统计。事实上 jira 并不能提高多少效率，只是对 issue 的追踪比较好，然后可以做一些分析罢了。提升效率还是要从研发流程，沟通基准，自动化程度来做的。毕竟是死板的工具，你只要定规则，那么必定就有漏洞可以钻，一项任务的复杂度，难易程度，都会影响他的工时，人员技术能力以及业务的熟悉程度也会影响它的工时，单纯从 jira 很难解决这些问题，而这些问题又是影响评判的主要因素之一。
我司基本只用 jira 来做： 1. 提需求，投票评判需求 2. bug 追踪，设计好流程，记录原因，解决方案 3. 分析 bug ，某些反复触发或者相关问题，需要梳理重新解决的 4. 一次上线内需求拆分成多个 issue ，这里其实并没有太多作用，只是象征性记录，更多的还是靠组内沟通 |
 |
3
liuliancao 108 天前
使用 gant 图相关插件 比如 structure.gant 和 biggant
|
 |
4
YDDDD 108 天前
效率用 jira 感觉不好使吧，我们 jira 只用来跟踪进度，记录下状态和最终结论，一个需求做个几天，具体都是用日报那种来看的。
|
 |
5
yiyiniu OP |
|
6
RandomJoke 108 天前
@yiyiniu 软件其实保障不了啊。。。30 天能不能完成主要是看研发真实时间能不能搞定，和 jira 这种软件有啥关系。jira 最多也就把任务拆解，然后每个任务上写好预估时间，只能说如果你更新的勤快，软件也许能告诉你做到一半的时候来不及或者也许可以提前。对工期本身其实没多大影响，甚至人少的时候可能还是负作用。
|
|
7
yiyiniu OP 现在主要是要解决项目延期的问题，或者说尽可能延期时间越短越好。不能说软件保障不了，对客户更不能这么说吧。 @RandomJoke
|
 |
8
ilovey482i 108 天前
项目延期应该用项目管理软件来管理项目进度，JIRA 是需求管理和 BUG 追踪
|
|
9
RandomJoke 108 天前
@yiyiniu 项目延期肯定是多方面，多因素的， 合理的工期，合理的评估，团队的激励，团队的能力等等。靠你一个软件就能解决延期问题，那这个行业就不存在延期了😄，软件本身的作用就是记录分析，辅助你管理，比如你记录了 jira 的进度，那么在中期可能发现不能按时交付，这个时候要么激励加班，要么加人，这个本身是团队的管理模式而不是软件能解决的。就比如种销售 CRM ，他帮你解决的是数据分析发现问题，而不是帮你卖产品啊。。
|
 |
10
Mithril 108 天前
你用纸笔文件无法解决的问题，用 Jira 也解决不了。他只是个代替纸笔的工具，能提升的效率也仅限于你花在处理纸笔文档上的时间。
项目经常延期，你需要考虑的是提升项目管理能力，而非诉诸于 xx 工具。要想办法找到，总结延期的原因，然后针对性的解决。到底是工期分配不合理，还是意外太多，或者项目目标设定的过于模糊等。 这些都是“人”的工作，你想着让 Jira 帮你解决这些问题实在是南辕北辙了。 |
 |
11
XXWHCA 108 天前
用了好几年了，使用的功能主要是 bug 管理，任务报表和任务备忘或者说任务池，感觉页面不太好用，有一定的门槛。每天都需要花一些时间来处理任务分配和维护任务状态，定期看一下任务分布、时长这些报表，感觉并没有提高效率。在协作开发时，任务怎么做到更合理的拆分，然后还有就是每个人能及时的维护任务，包括时间、状态，不同的项目和公司可能场景不抬相同
|
 |
12
li746224 108 天前
jira 这东西怎么可能提高效率。我们本来一些小的需求变动只要同事座位间动动嘴说一声就行，用了 jira 后，现在已经发展到不建卡不做。建卡等审批 pm ，开发过完 2 天过去了，本来只要 1 分钟就能搞定。
|
 |
13
yuedun 108 天前
12 楼说的是事实。jira 这种东西是给管理者和 pm 使用的，开发人员谁愿意使用？一天有一半时间用来更新 jira 能提高效率吗？
|
 |
14
wanniwa 108 天前
基础的项目管理，如何拆分需求，怎么细化量化还是看项目经理能力，会管理的用 excel 表格都能管的井井有条。至于怎么管理你不如多去看看相关的视频把。。工具真的不是那么重要，只要能把一个个要做的事列出来，每个都有校准确的故事点评估，按故事点总数和开发人数尽量合理的平均到每个人。
想要完全不延期就一定要在一开始彻底决定好需求，别动不动哪边逻辑漏漏了个大场景，哪边又要大改。除非方向完全错误，定死了就死在这个迭代里，改动放下个迭代提需求。 还有需求最好是让底下负责的组长或者就是基础开发，列出他自己要实现这个功能的步骤和需要故事点，和项目经理评估的对齐一下，别需求啥都没看，开需求会啥问题没有，做的时候一堆问题。 评估故事点最好最后再*1.1-1.3 的系数，留个容错时间 |
 |
15
luozic 108 天前
效率不是使用啥软件能解决的。
jira 最好的是看板和插件多，可以有效总结和保存过程信息。 |
|
16
luozic 108 天前
如果长期工期延迟，需要切实的通过 jira +大家一起总结哪部分导致最严重的延期。
最常见的就是改需求 加需求还不改时间。 -----这种如果是客户长期的搞法，那直接评估时间的时候直接把这部分也加进去，并且控制需求变更 新增数量。 |
 |
17
mark2025 108 天前
@RandomJoke
“一次上线内需求拆分成多个 issue ，这里其实并没有太多作用，只是象征性记录，更多的还是靠组内沟通” ===== GitLab 的 issue 系统可以实现追踪一个 issue 被分解成多个 issue 然后每个 issue 链接 MR ，然后统计每个 issue 的完成时间 |
|
18
luozic 108 天前
这一类软件是能记录信息，方便你分析问题。但是解决问题不能靠软件。
|
 |
19
zhuangzhuang1988 108 天前
记录生命周期的。
不能真正的复杂问题，复杂的问题还是靠牛逼的人解决的。 当然这个有比没有好。 |
 |
20
wobuhuicode 108 天前
作为同时在两个不同 team 使用过 jira 的人太有感触了。
A team 有个 50 多岁的 leader ，每一个 Task 都是他负责发布的。一个大的任务给他分割成各种小任务分布到各个人下面，团队每一个人只需要管自己的部分就可以了。team 内的进度推进的非常平稳和准时 B team 是全是有经验的开发者（人均 30+）。一个大任务下来大家讨论分配之后领取自己的任务去完成。一开始也能准时完成。后来加入一些新人之后就经常延期，因为新人基本都很难准确评估自己的任务。 要提高效率和准时完成任务。本质上还是需要能准确针对每一个人的能力去分割任务。 |
|
21
RandomJoke 107 天前
@mark2025 jira 你说的这些其实 jira 都能做，很多项目其实是多 repo 的，gitlab 其实也并不合适。统计这些时间本身意义不大，你说进度吧，其实做项目的不如组内沟通一下，你说关代码和 issue 的关联性吧，这个倒是有那么一点用（ jira 也能关联 gitlab ），但一般来说 jira 的需求 issue 都不太会去重新打开看的。
|
|
22
YDDDD 107 天前
@yiyiniu 软件工期这个感觉想保证就只能每天对一次？用什么工具感觉不是重点吧，我们 jira 的更新状态甚至大部分都是 ld 做的，我们只管 mr 合了粘过去。不过我们每天早会，会把手里需求进度更新（不是用 jira ），但是遇到一些预料之外的问题延期也是没办法的。
|
|
23
mark2025 107 天前
@RandomJoke jira 偏重管理，关注的是流程； gitlab 的 issue 是基于代码的偏重于开发， 比如可以在基于 issue 创建 MR 的时候同时创建代码分支，让开发人员里面切入到开发中，并且基于 web 的代码审核方式也提供了同事口头交流之外的比较高效的沟通方式——直接在页面显示的代码上面通过评论进行交流沟通。开发人员应该更喜欢用 gitlab 的这个流程管理方式吧。
|
|
24
RandomJoke 107 天前
@mark2025 并不见得是这样，一般同端的协作是相对较少的，MR 作用于 review 还行，其他的情况并不适合用于沟通，issue 系统也仅限于一个 repo ，更适合对 repo 的讨论。一个项目基本都是由多端多 repo 组成的，比如后端微服务 3-5 个，前端，小程序，app 等等。这个时候用 gitlab 来管理项目就太困难了，而这种项目往往是最常见的。
|
|
25
mark2025 107 天前
@RandomJoke 不会吧。gitalb 的 issue 是可以跨 group 的： 创建一个项目组，其下包含多端的多个仓库，可以在 group 级别的看板查看管理相关的 issue 啊。
gitlab 的 issue 我觉得拿来作简单的项目管理也不错的：wbs 任务分解、任务状态管理、任务流转、里程碑管理。 |
 |
26
Akiya 107 天前
延期的问题不是一个软件能解决的，得从需求规划开始就下功夫。能做项目管理的人才在全球都是稀缺的，不然也没这么多项目延期了
|
|
27
liuliancao 107 天前
@yiyiniu 这个比较复杂 也有很多中管理方式和理念吧 我们是 milestone 和 sprint 管理的 比如两周一个 sprint,然后分支放到这些里面，上一周开发，下一周去跟进度，这个和整个团队有关了，你要感兴趣就看看项目管理相关的吧，我也不是项目经理 PM
|
|
28
yiyiniu OP @RandomJoke @luozic @wobuhuicode @liuliancao 请教，有的项目比较长，开发人员在工期长的项目中，往往会刚开始很有激情每个人自己的任务往前推进，在后期往往会疲惫，拖拉，进度缓慢。大家是怎么处理这种情况的呢？
|
Select Language