※ 引述《limoki (老莫)》之铭言： : 小弟并非程设师 : 但是可能是潜在的案主... : 请问各位大大在接案时 : 会希望案主给怎样的文件吗？ 案主需要做的最基本的是: 1. 把需求表达清楚, 以及 2. 其所期待的最终成品所需具备的功能. 文件化. 文件的确就是'根据', 没有文件做根据, 只凭口头交待, 最後通常都 变成各说各话. 别说听的人可能会有遗漏, 恐怕连说的人你要他重述 他说过哪些话他都做不到, 那最後东西做出来若有争议的话当然变成 一场鸡同鸭讲的混战. X( 不过即使是有受过训练的人, 对於要把需求给表达清楚这样的一件事 做好也不简单, 至於没经验的案主就更不用说了. 因为有些需求一开 始只是一种'想要解决问题的感觉', 很抽象, 很杂, 而且要表达清楚 还得依靠某些格式化的工具才行, 要具体化/清晰化到可以用文件来表 示, 让大家都能够看得懂的过程当中其实还是需要下不少功夫. 没经验的案主是不懂得要将需求'文件化'这件事的重要性的, 而且未 经训练, 你要他把需求文件化对他来讲是件苦差事, 他绝对办不到. 所以有经验的人需要负起主导的任务, 通常就是接案厂商罗. 透过需 求访谈的流程, 做好记录, 最後整理成文件, 交给案主确认, 双方签 字同意, 成为有效的需求描述的文件. 有经验的案主能够事先提供需求描述文件那最好, 厂商看过後只要确 认没问题那就行了. 後面分析工作到开出功能规格书那是厂商的事. 至於功能描述文件, 原本是可以等厂商开出功能规格书後, 双方再确 认的. 不过案主也可以先描述他期待的功能, 请厂商在开出功能规格 书的时候考虑进去. : 之所以这样问，是希望届时我在发包时 : 能够尽量给出（当然要在我能力内）能帮助到工程师的文件 我想你应该不是案主, 而是接案的人. :) 你从案主那边接到案子, 根据需求描述文件开出功能规格书, 接着让 工程师根据功能规格书施工. 在这个阶段, 工程师需要的就是功能规格书当中, 对於各个功能的实 施的程序描述了, 程序描述可以使用自然语言. 你把程序描述开出来 , 工程师就照着功能内部的程序描述去做coding/debug/test等事.所 以照这样的流程写出来的code, 绝对都有对应的注解(就是功能实施 程序的描述), 因为注解就是写程式码的依据, 绝对不是先写程式码, 再写注解(当然在写程式码後, 还是可以对注解补遗). 後面的人若要 接手维护,是比较好维护的. : 因为我从公司的经验看到太多光靠「口头」沟通而fail掉的专案了 : 您会希望案主给的文件中 : 能够尽量有哪些内容，才能提高设计与开发的品质 : 并减少中间的沟通落差 : 谢谢大家（也期待不久後有机会跟大大们合作） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.104.188.17 ※ 编辑: bobju 来自: 59.104.188.17 (12/29 13:14) ※ 编辑: bobju 来自: 59.104.188.17 (12/29 13:18)