关於这个, 我可以提出我所采用的接案流程及原则仅供参考(因为不知道别人 是否有更好的做法?). 1 签约一定要在订出规格之前确定. 签了约先收签约金. 要不, 乾脆别做. 2 制订功能规格书: 2.1 功能规格书有两部份, 文字部份以阶层树的方式表达. 2.2 将功能规格以UI的方式呈现. 用绘图工具画图. 每个功能的每一个操 作步骤就是一页图. 通常一个不大不小的系统(以CRUD操作为基础, 产品管理/客户管理/交易记录报表/帐号管理/权限管理/系统设定), 大概要画60页左右的图. 这部份的工作是不难, 因为图面大致可以 copy-paste後再修要改的部份即可, 只是过程单调乏味. 2.3 在每页图上需要文字注解的地方做记号(编号, ex: 1, 1.1, 1.2.1 etc..) 2.4 制作功能规格的文字说明表格, 与2.3相对应. 上述这一段程序我也是跟别人学来的, 在此之前我从不认为这道程序值得花 时间去做, 尤其是UI, 程式写出来就有画面了, 还先刻意去画图? 岂非可笑? 但是後来体认到很多案子会有纠纷(自己及别人的经验)都是因为规格不明确, 尤其是UI, 因为客户看UI图像比看文字会更有感觉. 所以我承认这道程序对於 确认规格有其必要性, 算是一道防火墙. 而且run过一次後, 这些文件化的东西 以後接案还用得着, 所以值得. 还有画UI图及写文字描述很重要一点就是: 为自己後续的施工做准备. 其实我 个人觉得写'程式'的逻辑是需要'图像'及'文字'做指引的, 有些东西你事先在 '概念上'以为很简单的, 没有先做文字描述来整理逻辑就直接施工(coding), 往往会漏洞百出, 最後东挖西补反而更浪费自己时间, 施工品质很差. 3 功能规格书开出来後, 给客户看过, 有问题要改现在提出来改, 我可以等 你1~2个礼拜时间去想看看哪里需要改还是要加? 没问题就签规格同意书. 反正签约金我先收了, 客户若要赖皮拖时间或不做的话我不吃亏. 其实一般 看完後都没意见.(这就是了, 其实後面会有争议都是因为一开始规格没桥好嘛 , 你主动出击, 客户就只能应你的招. 轮不到外行引导内行.) 客户签规格同意书後, 我的责任范围就很清楚, 後面就算你拗我, 也要我爽才 行. 才开始按照规格施工. 施工也有施工的流程, 不过这部份跟客户就比较没关系了. 是跟我本身的技术 及时间管理比较有关系. 最後东西交给客户, 就是请他照规格书上的图去做验 收的动作. ※ 引述《KiroKu ()》之铭言： : 如果老板是会写程式， : 通常有问题，去问通常提出的回答也比较具体 : 如果没有的话，常常真是有里说不清... : 像之前接的案子，客户图要一直改就算了 : 有些地方规划不知道要放什麽，就先空着 : 等到快结案时，pm就说了： : 就把全部栏位放大好了 : 就把全部栏位放大好了 : 就把全部栏位放大好了 : 就把全部栏位放大好了 : 因为这样结果设计师，至少就又改了三四张图 : 加五六个排版吧..（设计师真是吃苦耐劳的行业） : 要不然就是问我说： : 为什麽google/yahoo有的功能我们没有呢？ : （...为什麽会有呢？... : 并不是拿免费的东西随便改一改就跟yahoo/google一般了好嘛？） : 其实我觉得做系统，起先一定要有个架构图 : 哪边未来需要能够扩充的，一定要先想好，用有弹性的作法 : 不过一般客户，要他一次把所有细节都弄出来，再开始做 : 真是有十足的困难...所以常常变成，边做边商讨细节... : ※ 引述《TonyQ (沉默是金)》之铭言： : : 作者: TonyQ (沉默是金) 看板: CodeJob : : 标题: Re: [询价] 员工薪资管理系统 : : 时间: Wed Jan 21 08:07:35 2009 : : 讲到这个我真的是心有戚戚焉. XDDD : : 我作过两次类似这种系统(出勤、薪资计算）的经验 , : : 结论是好的案主带你上天堂 , 坏的案主结不了. : : 第一次是我刚出道接的第一个案子 , 给某大学某处室内部用的值勤系统 , : : 这个勒 , 基本上就是一天一张出勤表 + 勤务内容 , : : 假别六种还七种(公病例假补修特修...etc) , 比较麻烦的是出勤名单的维护 . : : 填写的资料也都很简单 , 反正就是填表 , : : （主要是取代他们过去的纸本填写 , : : 不过有趣的是最後还是要转成word档印出来让主管盖章.） : : 需求谈好後几乎没有任何变动 , : : 结案前夕多叫我做个值勤的行事历, 让人看看是哪个同仁当班就结束了. : : 作为第一个案子来讲 , 非常轻松愉快的案子 ,钱也还算可以. : : 第二个状况就完全不是这麽回事 , : : 规划的时候劈头就是说功能要多完善有多完善 , : : 画面要多炫有多炫 ,(还拿outlook 的介面来比 orz) : : 假别? 那种东西我不知道啦 , : : 但是你给我看的时候我就会想起来你还差哪些东西. : : 绩效奖金? : : 喔 我们就基本的出缺勤上下班啊 , 全勤没迟到有奖金 ...etc : : 隔两天做到一半去确认 , demo 并确认现在的状况. : : （喔 ... 对了 我们卖房子卖出去还有业务奖金...那个可以另外加(!!?)） : : 然後做到一半我越作越觉得不对，需求竟然往内部 portal 的方向偏(!!!)， : : 发现这是个无底洞 , 外加上面的又一直催成品(一边要改需求一边要出成品). : : 总之 , 没有收敛好需求的下场差不多就是这样 , : : 最後变成庞大的需求怪物 + 感觉根本不可能做的完. XDDDD : : ──────────────────────────────── : : 其实根据後来的工作经验 , 这样的状况真的很常态就是了 , : : 难怪具 pm 角色的老板(super user)跟 pg 往往很难相处得来 , : : pg 的苦他们不知道 , 然後又觉得自己只是改一点点 , 只是参考某些网站, : : 而且改的那些东西有没有意义还是蛮见仁见智的 , : : 比方说最近听到的一个主管名言： : : 我们不应该自己造轮子，所以参考xx网站就好了。 : : （xx请带入yahoo/google/facebook...etc） : : （参考归参考 , 最後还不是我要做出这功能...murmur） : : 一直改就会让 pm (通常是具user身份的) , : : 有自己很会规划很能指挥 pg 的信心 , : : 等到 pg 翻脸时 , 就能知道自己平时有没有烧香了. :p : : --- : : 上面後来提到的那份case 因为只是拿时薪 110 的课後兼差工作 , : : 也就只有给他 110 的水准 , 後来有做到一个阶段就没办法继续往下做 , : : 因为需求面临谈不拢的状况外加完全没把握做完 , 只好认赔杀出, @@ : : 当然这个工作经验也算是份无效履历 , 白白用掉三个月 , 有够累的. orz : : (只是那时候老板常常下班後又抓我去陪他喝酒 , 他大概也只是试试吧. XD) -- 称我 Mr. Candy 也可以, 我的Email/msn: [email protected] --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 211.74.193.210