最近做专案遇到常常遇到心很累的事情
就是有些很特殊需要判断的情况
会被写在设计稿一个感觉不是很重要的备注里面
然后还很不显眼，没仔细看还不会发现
开会的时候也没特别强调这边要有特殊判断
可能对于PM来说这个只是小事情，但对于工程来说是件大事
举个例子，但详细规格就不赘述了
最近在做一个问卷审核系统
然后有分需要"覆核"的问卷和不需要的
不需要覆核的问卷只要"审核"过了就算这个问卷完成了
后面的数据分析也是依照"审核结果"来当作依据
而需要覆核的问卷要先"审核"然后再"覆核"过了才算这个问卷完成
后面数据分析的则是由"覆核结果"当作依据(审核结果就不看了)
然后会有一个开始进行数据分析的按钮给使用者按
让使用者蒐集够多的问卷以后按下去
然后我们把"完成的问卷"丢下去分析
听起来非常合理且单纯，我们前后端也就照个这个规格一直往下做问卷系统+数据分析
.....直到看到两小行备注
“按下数据分析后，若需要覆核的问卷没有完成覆核但已经完成审核
依然可以分析，但就是用"审核结果"当作分析依据”
这两行被挖出来之后，前端(我)后端瞬间炸裂
因为问卷完成这件事再也不是可以进行数据分析的唯一指标
还要考虑它是否为一份需要覆核但没被覆核完成但已经审核完成的问卷
现在要回头补这段逻辑前后端都非常的麻烦
而且可能还会有没注意到的漏洞
加上这个案子时程又赶，现在挖出这个东西所有人都不知道怎么办才好
如果一开始就有特别提醒我们有这种商业逻辑
也许还能想想有什么办法满足客户需求
到了现在这个阶段基本上是没救了
但如果我们希望能针对这件事情的发生做检讨
避免下次再出现类似情况的话
我也不知道有什么好建议可以提出
我似乎能理解站在PM角度好像不会觉得这种可以妥协进行数据分析的需求是很难的事
但对于工程来说就完全不是这么一回事
状态的验证、UI显示逻辑等等都因为放行了"没有完成却又可以分析"的问卷要调整
然后设计稿也没有针对这种状态的问卷告诉我显示逻辑
所以我们才会从头到尾都以为要完成问卷才能数据分析
请各位前辈指点迷津....谢谢

时程就不要这么赶啊 啊不然就换公司设计稿没有已审核未覆核的问卷该如何显示？那不就表示设计稿上没有说要特别注明一个问卷是不是已审核未覆核。那就当作已完成问卷显示啊。设计稿没有改前端就不用改就没有问题，设计稿要改那就是改需求就是加时间啊。后端跑分析要捞哪些问卷出来跑还不就是改几行条件就能搞定的事情，多捞已审核未覆核的问卷出来加入要分析的资料集里面，哪有那么崩溃。以后就禁止使用那个没人会看到的备注功能，不然就是你们仔细检查看清楚，再不然就换公司

感谢b大半夜回我，其实我省略很多细节只说明个大概，像那个已审核未覆核的问卷从定义上是不能算在完成的问卷的，而是这类的问卷被丢去分析以后他要强制被视为完成的问卷，后端也要暴力的更改这种问卷的状态，导致资料会出现明明是需要覆核却又没有覆核结果却又被算在完成的问卷

照你前面的说法是已审核未覆核要丢去分析，为什么需要改状态变成已完成？让他维持状态是未完成问卷就好了

但会出现这种资料就是一开始我们在设计后端的时候认为要覆核的问卷如果走到分析的话是一定会有覆核结果，没有考虑上述的情况

(旧文)(简体)10年5款游戏,项目从不延期:如何做项目管理https://www.gcores.com/articles/114366https://www.bilibili.com/video/BV1J4411B7fz

分析的程式抓所有已审核问卷出来分析，如果有覆核结果就拿覆核结果来计算，如果没有就拿审核结果来计算，不用管他是不是已完成。听你这样讲感觉是你们把自己绑死在一定要已完成问卷才抓出来分析

因为针对问卷这个前端元件，已完成的话不可编辑，未完成的话可编辑而分析结果的画面是有连结可以连到问卷去检视当初审核结果或覆核结果填了些什么，结果连过去是一个可以编辑的问卷就很奇怪

如果按照客户需求这个分析过的问卷还要能够编辑，做覆核那就照做即可，就算你觉得他好像看起来很怪，反正是需求

至于有没有覆核结果又是另一个坑了…因为所谓的没有覆核结果有可能是它其实被覆核完成了，只是被覆核人员认定这个问卷不适用，数据库就会记null，如果适用就是一个分数(float)另一种情况是它还没被覆核所以是null

如果正确的需求是一旦按过分析就不可以再编辑，那就加个字段把问卷标示成不可编辑。遇到别人搞你又要凹时程就是先硬干能动就好了

所以如果是覆核完成但覆核结果是null时，这时候用null当分析依据才是对，不能去拿审核结果但如果它因为是还没被覆核所以覆核结果是null，那就要拿审核结果但我觉得b大的不要用那个没人看得到备注是好方向我真没想到一个备注会写这么重要的商业逻辑

你说的是要判断 ”如果问卷已完成 and 覆核结果是null，这条问卷就是不适用” 这种问卷就不要拿来分析（抓所有已审核的问卷再剔除上述条件的不适用问卷）商业逻辑没有整段文字涵盖完整的叙述，而是有其中一句藏在备注里，这个操作不知道怎么吐槽了...

我可能描述得不太好，不适用这个名词只是商业逻辑上的名词而已，并不是说他可以从分析名单中被剔除，覆核完成后的覆核结果就算是null也要进去分析名单，会有分母的问题例如我有两分覆核完成的问卷，一份有分数一份null，那我分析的样本总数还是要算2而不是1这种时候就会告诉使用者总数2份有分数1份不适用1份那如果是因为已审核未覆核导致的覆核结果为null，这种时候要去拿他的审核结果，假设有两份这种问卷且审核结果都有分数，那就是总数2份有分数2份不适用0份因为有可能会出现一份覆核完成的问卷，审核结果有分数，覆核结果被判定不适用所以给null的情况，这种情况要用null当作分析依据且总数分母+1如果是已审核未覆核这种状态的问卷去分析（覆核结果一定是null)就要拿审核结果当分析依据且总数分母+1

听起来就是多了一堆判断要刻但没有到打掉重练的程度，这种状况大概也只能你们加班努力赶。其实需求就应该完整的整段文字一次描述清楚，以后不要写在备注加上利用资料范例确认需求吧。备注我都用来放外部资源连结而已

确实是没又要打掉重练，但就是多很多额外判断，然后不知道有没有地方会因为加上这些判断再延伸出额外的bug但我觉得因为pm觉得这只是小事情所以写在备注，他可能没想到事情这么大条，要让工程回头改一堆地方然后答应客户的时程其实快到了，我们也确实都走到最后几步了，现在挖出这个备注让我们必须回头检查所有的地方，不知道要多少额外的时间成本

找一个从rd转pm的人

单从叙述看起来是PM有写在规格里但工程师漏看到,不过需求变更本来就不是什么新鲜事,甚至常有一开始没说,客户突然说要另外加判断的情形发生,只能靠工程师的经验,在架构上尽量设计弹性一点...结论就是这没有标准答案的

软件业常态，根本不用解决，而是要适应。不要当大家，SA，Scrum，DevOps玩假的，就是为了专业迅速解决这类变动。备注的文字，或需求还可能随时变耶，怎么都写不清楚。千万不要认为规格不会变，可以写清清楚楚。小弟在软件业工作超过20年，待过大大小小的公司，根本不可能发生。工作气氛还比较重要。当规格写不清楚，或有人漏看，团队怎么沟通的，气氛怎么样，结果如何，真的比较重要。

把spec看清楚是开发人员的责任，但工作合作本来就互相，所以开发者可以去训练PM，每次发生这种事，就严正告知PM应提醒各种规则，好的PM应就此学习而调整沟通方式。我就是被训练的那个，现在开发模式是，我写完spec，会口头跟开发人员对着文件一条一条说明，有些备注我如果偷懒没讲，开发者会主动指出，因为过完spec后，功能做不出来，就是他们的锅了

Code的耦合性可能也要思考一下，会不会是过度耦合导致不好改

反过来说，如果事后证明是我在过spec时没提出该需求，我会被主管骂 :-)如果PM做错不会受到惩罚，譬如被骂、譬如开发进度延迟导致PM绩效不好（因为开发者会加班赶进度），那就无解了。

看来是原PO问题比较大，基本上原PO就是照单全收，没有对spec和需求提出疑问，有些是功能上的疑问，有些是商业逻辑的疑问，有些是流程上的疑问，我想沟通是双向的，我想PM也会接受工程师提出的疑问吧

对清楚 再修改就好 软件就是一直改一直迭代 又不是硬件真的有出货hard deadline

工程师自己去跟使用着谈需求，PM 只是做专案管理与控制需求范围与冲突的角色。只是有能力这样做的工程师很稀少且早在在不错的大公司了

自己没看到备注跟规格有啥关系 就写在上面了自己做错还觉得是PM的问题？

感谢各位版友们回复，先针对漏看这件事多做说明好了，其实我也不否认漏看工程师有一定责任，只是一开始开发会议上pm本来就会跟工程师对需求，规格文件只是事后拿来辅助回忆而已，那当初说到要把问卷丢下去分析这个瞬间其实pm也没特别说有要特别的判断某类未完成的问卷依然可以分析，我们工程师自然而然就一直认为要完成的问卷的才能分析，再加上设计稿图面都是用这种前提下设计出来的UI，所以就一直没人发现

感觉有些东西也没做好抽象化，全部都直接照规格写可编辑不应该绑死特定状态，结果分析不该绑特定字段

设计稿也没有告诉工程师所谓的已审核未覆核且已分析问卷这种“半残”的case显示逻辑所以我会认为是对于功能上认知的差异，就开发会议上pm没特别强调这里分析的对象，设计稿也没特别针对这种情境告知显示逻辑，而是轻描淡写的用两小行备注藏在一个超肥大的设计稿的某一小处，没注意的工程师确实有责任，但我也必须说那个小到没特别提醒还真的很难注意到，我会发现纯粹只是刚好

你是想解决问题还是讨拍啊

简单说就是针对无效问卷也能提供分析的功能保留弹性，就没有这次的问题，需求上没讲，但设计上可以保留弹性，有没有时间做和需不需要提供给客户是不同层面的问题

你搞反了吧 文件才是真理 会议是辅助你了解文件或提出建议用的我看起来像是你自己文件没看清楚 在开会时又不提出来现在怪东怪西的

回b大，经过这次以后我确实认同你的话了，文件还是自己仔细看过比较安全，不要太相信pm开会时整理出来给我们的，因为他们整理的版本可能会漏掉他们以为不重要但其实很重要的东西

嗯 总之 文件有,你没做 你肯定吵输 文件没有,你没做,pm叫你做 你吵赢的机率高多了

其实结果就两个 文件有你没做 那就加班做文件没有额外的需求 那就多要一些时间做做为开发 要对产品有点基本的sense 这样spec没写清楚的地方才会知道有可能的问题 再去问PM补齐细节每个人心理想的跟表达出来的都不一样 不要脑补写不清楚就问 或是看完spec 再确认一次自己认知的流程跟 spec的流程是否一致要自己想到各种spec上没写到的极端use case

不觉得文件是真理。花大量时间写很标准的文件，甚至走CMMI那套，什么ISO都上，都永远解决不了文字与言语沟通，就是会一直有认知落差的情形。

恩认同可能是耦合度太高，不然就只是多个流程判断而已

遇到需求认知落差时，团队怎么沟通达成目标，气氛好不好，才是职场的重点。认真检讨文件，或技术耦合度，都不如解决"人"的问题。人好了，什么事情都能解决。不然，你就算搞个很重的标准流程，产生所有可能文件，搞一堆微服务，实务上都没用。

下次画一下event storming，检讨人没有什么太大的意义

本来就应该对于spec抱持着怀疑还有多方思考的态度PM没写清楚就算了 工程师不能照单全收

江湖走跳，强烈建议PG通灵术一定要点满。

先写test case,找PM讨论,再开始开发

文件就是个追忆手册，确认的时候拿出来用的，写不写能搞砸的就是会搞砸

好像也有所谓的规格描述语言，但没用过无法评论

这个就是考验PM的功力跟经验了...

下次把文件看清楚呀，你要检讨pm请他下次把备注的字体放大一点

每天的立会就是为了这种突然加进来的备注而存在的时间一久连PM都会会忘记自己加了什么 嘻嘻不过看文章的描述PM没啥问题吧，SA跟PG问题比较大除非他偷改需求却没跟你们说

腾讯，考虑一下薪资福利跟下班时间吧，当下环境是个重要的考虑要素

觉得只是你和PM都还不够熟练，才会产生这种问题。下次PM尽量改善文件写法，你尽量用心看完每字每句用心推敲后再做就好了。这种事情总会发生，尽量减少就是了。