Re: [请益]如何有效减少与PM对于规格认知上的差异

楼主: bachelorwhc (单身老王)   2023-01-12 09:15:50
1. 规格会不会变 跟 应不应该写规格 是两码子事
规格肯定会变,没有不变的,但应不应该写规格就看公司文化
有两派说法:
a. 规格是产品拥有者跟开发者的依据
b. 产品迭代快,产品目前的行为就是规格
实作会错、test会错、规格也有可能会错,只要是人就会犯错,所以
板友说这是看团队,不无道理
2. 回到人会犯错,规格有时会变成政治工具的一种
因为说到底,如果你的公司是犯错就要究责的文化,那责任出在谁身上,那就很重要
此时规格的目的不再是为了完成产品
3. 规格不好写
只要规格是用自然语言写成的,就有可能会造成误解
(我相信大家不可能没遇过一群人对同一句话有两种以上不同解释的状况)
精准的规格,有些产业可能随便写下来就是一两千页,然后卖你个五六万
光是名词解释就能分成一册单售
当然你们公司的商业逻辑可能复杂程度不是什么业界标准等级的,可以参考
domain driven的丛书,但我试过,台湾大部分是推不起来:)
如果规格的目的是在避免犯错或降低沟通的成本,但又不想写规格,那不如
由开发人员主动设想所有“可能会出错”、“模糊不清”的脚本或状况
这些edge case的设想往往需要判断与经验、对系统的了解
我的经验是大部分是非工程师的人往往不会去想这些,作为开发者的我有必要
在看到他们描述行为时,就尽量厘清我能想到的状况
当你有了这些case或脚本,你就能够建立测试
作者: black209 (black209)   2023-01-12 10:32:00
作者: loadingN (sarsaparilla)   2023-01-12 11:17:00
太长了 简单说就是团队如何有效协作
作者: DrTech (竹科管理处网军研发人员)   2023-01-12 12:15:00
推二楼,简单就是团队怎么协作,遇到问题怎么互动达成目的才是重点。不然规格再怎么写清处都没用。
作者: TAKADO (朕没给的你不能抢)   2023-01-12 13:37:00
文件跟规格不是万能,一样的文件给不同人开发还是有可能产出完全不一样的实作。实务上只能PG、SA跟PM一直持续沟通跟追踪,不要都自扫门前雪,自己觉得做完列出来的专案工作项目就觉得没事了。
作者: tsairay (火の红宝石)   2023-01-12 13:46:00
个人经验是,有些交办规格的上游是故意写的模糊的这样他们才好凹作更多,如果项目清清楚楚就是10个项目他就没办法叫你作第11项,所以他们都会写的故意模糊这样就能一直追加一些外包或是招标有打合约的案子规格就能写得清清楚楚不用打合约的规格就一直修改,要不要作而已
作者: jej (晃奶大馬桶)   2023-01-12 18:42:00
原po的答案就是成为通灵王就可以了
作者: gary861226 (躺着比山高)   2023-01-12 21:39:00
ㄜ...那请问DB字段名称还不清楚就要前端人员先开发正常吗?input name叫我先丢去google翻译成英文,等DB规格确认了再回头改
作者: c80352 (谙语)   2023-01-13 01:37:00
改名称小事吧 虽然很烦没错 但不用动到逻辑我觉得 OK
作者: TAKADO (朕没给的你不能抢)   2023-01-13 13:09:00
Clean Architecture 的概念参考一下,DB UI都可以后面再决定就好。
作者: Nitricacid (硝酸酸)   2023-01-22 09:15:00
db字段没开跟你前端有什么关系...接口做个字段转换而已 如果是要陨石开发又要追求效能就块陶

Links booklink

Contact Us: admin [ a t ] ucptt.com