作者bachelorwhc (积积阴阴德)
看板Soft_Job
标题Re: [请益]如何有效减少与PM对於规格认知上的差异
时间Thu Jan 12 09:15:50 2023
1. 规格会不会变 跟 应不应该写规格 是两码子事
规格肯定会变，没有不变的，但应不应该写规格就看公司文化
有两派说法：
a. 规格是产品拥有者跟开发者的依据
b. 产品迭代快，产品目前的行为就是规格
实作会错、test会错、规格也有可能会错，只要是人就会犯错，所以
板友说这是看团队，不无道理
2. 回到人会犯错，规格有时会变成政治工具的一种
因为说到底，如果你的公司是犯错就要究责的文化，那责任出在谁身上，那就很重要
此时规格的目的不再是为了完成产品
3. 规格不好写
只要规格是用自然语言写成的，就有可能会造成误解
(我相信大家不可能没遇过一群人对同一句话有两种以上不同解释的状况)
精准的规格，有些产业可能随便写下来就是一两千页，然後卖你个五六万
光是名词解释就能分成一册单售
当然你们公司的商业逻辑可能复杂程度不是什麽业界标准等级的，可以参考
domain driven的丛书，但我试过，台湾大部分是推不起来:)
如果规格的目的是在避免犯错或降低沟通的成本，但又不想写规格，那不如
由开发人员主动设想所有「可能会出错」、「模糊不清」的脚本或状况
这些edge case的设想往往需要判断与经验、对系统的了解
我的经验是大部分是非工程师的人往往不会去想这些，作为开发者的我有必要
在看到他们描述行为时，就尽量厘清我能想到的状况
当你有了这些case或脚本，你就能够建立测试
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.216.78.140 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1673486154.A.9C5.html
1F：推 black209: 推 01/12 10:32
2F：→ loadingN: 太长了 简单说就是团队如何有效协作 01/12 11:17
3F：→ DrTech: 推二楼，简单就是团队怎麽协作，遇到问题怎麽互动达成目的 01/12 12:15
4F：→ DrTech: 才是重点。不然规格再怎麽写清处都没用。 01/12 12:15
5F：→ TAKADO: 文件跟规格不是万能，一样的文件给不同人开发还是有可能产 01/12 13:37
6F：→ TAKADO: 出完全不一样的实作。实务上只能PG、SA跟PM一直持续沟通跟 01/12 13:37
7F：→ TAKADO: 追踪，不要都自扫门前雪，自己觉得做完列出来的专案工作项 01/12 13:37
8F：→ TAKADO: 目就觉得没事了。 01/12 13:37
9F：推 tsairay: 个人经验是,有些交办规格的上游是故意写的模糊的 01/12 13:46
10F：→ tsairay: 这样他们才好凹作更多,如果项目清清楚楚就是10个项目 01/12 13:47
11F：→ tsairay: 他就没办法叫你作第11项,所以他们都会写的故意模糊 01/12 13:48
12F：→ tsairay: 这样就能一直追加 01/12 13:48
13F：→ tsairay: 一些外包或是招标有打合约的案子规格就能写得清清楚楚 01/12 13:50
14F：→ tsairay: 不用打合约的规格就一直修改,要不要作而已 01/12 13:53
15F：→ jej: 原po的答案就是成为通灵王就可以了 01/12 18:42
16F：推 gary861226: ㄜ...那请问DB栏位名称还不清楚就要前端人员先开发正 01/12 21:39
17F：→ gary861226: 常吗？input name叫我先丢去google翻译成英文，等DB 01/12 21:39
18F：→ gary861226: 规格确认了再回头改 01/12 21:40
19F：推 c80352: 改名称小事吧 虽然很烦没错 但不用动到逻辑我觉得 OK 01/13 01:37
20F：推 TAKADO: Clean Architecture 的概念参考一下，DB UI都可以後面再决 01/13 13:09
21F：→ TAKADO: 定就好。 01/13 13:09
22F：推 Nitricacid: db栏位没开跟你前端有什麽关系...接口做个栏位转换而 01/22 09:15
23F：→ Nitricacid: 已 如果是要陨石开发又要追求效能就块陶 01/22 09:15