问题1：

在依赖QT的C/S项目中（同一个pro下），c端和s端的不同类中定义了相同的结构体定义，用于C/S传输和解析socket数据。我review时，认为此法不妥，应该唯一定义，以此理由要求同事修改是否妥当？


问题2：
如何使用jira工具做好项目工作管理？

我简单说一下我当前面临的情况，团队之前在jira记录主要功能需求和问题记录，会预设完成时间，但非强制，根据实际完成情况提前结束或延期。
最近，leader要求团队成员必须围绕jira的任务管理功能展开项目工作，同时固话角色分工和责任，以后季度绩效考评就看每个人完成和剩余的任务数量，用量化数据明确考核标准。
对此，我持怀疑态度和抵触情绪，原因如下：

1.任务的时间分配不均衡。如果要求完成和剩余任务数量作为考核标准，则前提条件是不同开发人员开发任务涵盖的工作量应该大致相同，否则无法得出相对公平的评价。但是，实际工作中很难实现，因为不同人员维护的功能模块不同，开发需求不同，所以不同任务的工作量往往不一样，小任务一天可以完成好几个，一般任务需要1-3天，偶尔会有一些难改的问题超过一周，但由于任务整体性强很难继续拆分，且存在工作估计不准确的情况，所以很难保证所有任务的工作量相等；

2.任务记录跟随效果不充分。jira可以记录预先计划的任务，但是对于突发问题，往往只能事后补齐，但是现阶段工作中插队需求和线上突发问题常常发生，所以这部分工作量不小。

3.加剧了工作中的机械化。如果只为jira任务论，我担心开发人员发现不在jira上记录的程序问题时会比以前更倾向于忽视该问题，而将时间花费于jira中的任务，哪怕被忽视的问题可能更严重。

4.评价维度单一。我认为这是机械的评价他人工作成果，反而应该从代码质量、解决共性问题的贡献程度、任务的难度和数量等多维度考量，并且工作成果是依靠自驱力的，这种机械式的量化方法看似公平，但仅是局部公平，可能会伤害团队成员主动性。（还有一个原因，我不想投入更多时间在记录别人任务上，有更需要我做的事情）
--
修改:wuzhiqiu1 FROM 1.202.113.*
FROM 1.202.113.*

1. 同一个 proj 下为啥要分开？他的理由是什么？没有特殊原因当然应该引用唯一定义
2.
纯单量考评是比较扯淡，至少得算上story point啊
但是你们的jira用法看上去也有很多问题
超过一周的工作一个任务，而且不可拆分？你们团队中间不沟通进度吗？没有中间里程碑？
那你什么时候能发现要超期了？
临时任务不进jira就直接开始做，全做完了再回头补，中间都不需要记录和同步吗？而且按你说法，这种任务数量不少，也就是经常团队里有一些人干的活没人管的意思？
然后既然有的不在jira中的问题可能比jira里的问题更为严重，那这些任务为什么不放进jira管理？

整段看下来你们就没把jira作为日常项目管理的核心工具，就是写个需求计划往那儿一放完事。那当然问题多多。如果真做到了“围绕jira的任务管理功能展开项目工作”那有些问题就不存在了。

话说你在团队中是什么角色？

【 在 wuzhiqiu1 的大作中提到: 】
: 问题1：
: 在依赖QT的C/S项目中（同一个pro下），c端和s端的不同类中定义了相同的结构体定义，用于C/S传输和解析socket数据。我review时，认为此法不妥，应该唯一定义，以此理由要求同事修改是否妥当？
: 问题2：
: 如何使用jira工具做好项目工作管理？
: 我简单说一下我当前面临的情况，团队之前在jira记录主要功能需求和问题记录，会预设完成时间，但非强制，根据实际完成情况提前结束或延期。
: 最近，leader要求团队成员必须围绕jira的任务管理功能展开项目工作，同时固话角色分工和责任，以后季度绩效考评就看每个人完成和剩余的任务数量，用量化数据明确考核标准。
: 对此，我持怀疑态度和抵触情绪，原因如下：
: 1.任务的时间分配不均衡。如果要求完成和剩余任务数量作为考核标准，则前提条件是不同开发人员开发任务涵盖的工作量应该大致相同，否则无法得出相对公平的评价。但是，实际工作中很难实现，因为不同人员维护的功能模块不同，开发需求不同，所以不同任务的工作量往往不一样，
: ∪挝褚惶炜梢酝瓿珊眉父觯话闳挝裥枰1-3天，偶尔会有一些难改的问题超过一周，但由于任务整体性强很难继续拆分，且存在工作估计不准确的情况，所以很难保证所有任务的工作量相等；
: 2.任务记录跟随效果不充分。jira可以记录预先计划的任务，但是对于突发问题，往往只能事后补齐，但是现阶段工作中插队需求和线上突发问题常常发生，所以这部分工作量不小。
: 3.加剧了工作中的机械化。如果只为jira任务论，我担心开发人员发现不在jira上记录的程序问题时会比以前更倾向于忽视该问题，而将时间花费于jira中的任务，哪怕被忽视的问题可能更严重。
: 4.评价维度单一。我认为这是机械的评价他人工作成果，反而应该从代码质量、解决共性问题的贡献程度、任务的难度和数量等多维度考量，并且工作成果是依靠自驱力的，这种机械式的量化方法看似公平，但仅是局部公平，可能会伤害团队成员主动性。（还有一个原因，我不想投入更多
: 奔湓诩锹急鹑巳挝裆希懈枰易龅氖虑椋
--
修改:cybereagle FROM 220.249.170.*
FROM 220.200.24.*

了然

确实存在外部需求时间要求不明确，内部管理的关键时间节点经常失效的问题
【 在 iwantfly 的大作中提到: 】
: 1.显然应该统一
: 2. JIRA使用任务分配， 我觉得主要的用途在于文档化，记录话任务分配调度的过程， 在以后得追溯过程中会有很大的用途， 至于中途添加修改小的可以作为bug,大的可以作为任务, 对于产品级，多期项目还有些效果
: 至于任务分配的时间估算是很困难的， 不仅任务估算时间本就不好估量，更有人员水平的差异，通常无视， 主要是卡里程碑卡关键点， 用于绩效评估有效，但是实际上都不用估，项目经理门清
: ...................
--
FROM 223.104.42.*

感谢，学习了
【 在 z16166 的大作中提到: 】
: 1、分别在 C 端和 S 端定义相同的结构体，严重违背了 DRY (Don't Repeat Yourself) 原则和 单一事实来源 (Single Source of Truth)。
: 2、楼上说的story points是很好的。
: 研发管理中一个非常经典的陷阱——“古德哈特定律”（Goodhart's Law）：当一个测量指标成为目标时，它就不再是一个好的测量指标。
: ...................
--
FROM 223.104.41.*

定位是pm，但管理系统中给定义的角色叫项目负责人，我理解就是什么干的意思。
【 在 cybereagle 的大作中提到: 】
: 1. 同一个 proj 下为啥要分开？他的理由是什么？没有特殊原因当然应该引用唯一定义
: 2.
: 纯单量考评是比较扯淡，至少得算上story point啊
: ...................
--
FROM 223.104.41.*