我觉得还是写点自己的参考资料 , 算是我自己的接案守则. 有兴趣看的人就看 , 有意见的直接回直接推 , 只要是有兴趣想讨论的我们都可以聊 . （想骂、批评的也ok啦）XD 这个话题是延续至差不多一年前有人问我说出来接案该注意什麽事情， 那时候我整理出来四点，我这次更新成六点也补注一些这段期间来的经验谈。 这是有关「如何接到案子 vs 如何顺利结案」的个人守则。 如何接到案子： 1.适度的曝光自己：参与技术讨论、适时分享自己的学习成果、 良好的提问或回应。 （目的：让你的程度可以让人「看得见」，不管程度优劣至少能有个参考。） 积极的找有兴趣、能做的案主洽谈，并且拓展技术人脉， 技术人之间有案子pass来去是很正常的。 而且通常由认识的人介绍的案子比较容易谈成。 （只是不容易结案。） 2.要清楚自己想做、能做什麽样的案子： 了解自己的能力跟环境，是否能达到案子的需求。 如果不行，要准备到符合案子所需的内容， 时程是否会太赶，应该根据自己的信心程度有多少。 比方说之前我接yahoo widget , 虽然我之前完全没写过 , 但是我对 js 跟xml的操作非常有信心, 所以虽然是三天的急案 , 还是接下来. 又比方说某一次接一个 fuzzy 演算法的case , 那次时程开两个月 , 我判断能找时间充实相关资料 , 所以也是接了. 然後，当你一看就信心满满的跟自己说绝对没问题的时候， 记得要再复核一下，毕竟魔鬼藏在细节里， 特别是一开始草拟的 ERD ，很容易不小心漏东漏西的， 实作时才在更新栏位。（晕） 也要从spec去小心看案主可能会临时提出来的需求， 预先在心里做个准备，必要时先询问案主这方面的需求。 ps.客户要什麽就是什麽，不要有用手上模组拼乐高积木交差了事 的想法，除非这个模组已经是为了这个客户准备的。 举个例子 , 就算只是安装 joomla 这类CMS模组 , 各使用者通常都还有需客制化 (logo/自制功能...etc)的地方 , 过去的模组通常不是拿了就可以直接用 , 铁定还是会需要调整的. 3.眼前的案子才是真的。 很多案子我们都知道可能会有後续，但是不管後续的商机多大， 眼前的案子自己能做的下来，吃得下来才是真的。 因为只要中间一个环节你让客户印象不好，就没有所谓後面的case了。 很多客户也会用以後继续合作的理由来压低价格， 但是还是不要干这种杀鸡取卵的事情比较好。 同样的，如果合作之後觉得客户很难合作，也要做好随时抽身的准备。 （要走的顺利就是尽量把技术文件准备好交接出去， 免得落得只有你知道系统结构，客户要求交接就把你整个半死。） 4.价格 其实在这里谈到价格是非常敏感的，因为一个接案方一个发案方， 一个想要低价一个想要高价，写偏袒哪一方都是很容易引起纷争的， 写高价好，就是得罪发案方，写低价好，就是得罪接案方。 不过我这里谈得不是要开多少价，而是怎麽开价。 我认为最重要的事情，开价的准则不能看心情开，自己要有个依据。 通常我自己的作法是按照资料库复杂度、控制介面的复杂度， 从这去写功能列表，在心中草拟整个case 的结构， 整个起来大概对每个功能的细项有概念之後， 再参考案主的预算跟可以关查得资料， 来用自己觉得的难易度跟报酬来计价、报价。 （不过每个人的作法都不同啦～只是重点是自己要有个计算公式。） 通常我自己不会开超过案主的预算，除非案主有额外增加项目， 如果我估起来之後完全就超过案主的预算， 那除非案主主动谘询，不然我不会去报价。 理由很简单，既然案主对价格已经有先入为主的成见， 基本上你身为一个要赚他钱的人， 还把价钱往上抬，先天就会先有负面印象， 万一到时候case有沟通上的问题，不欢而散的机率不小。 另外案主的需求，还需以自己能估计的延伸需求来做双重参考， 因为一方面案主可能是善变、善忘、需要「共体时艰」的， 另一方面则是案主可能在规划时无法做专业的细节规划， 像是表单有些案主可能就会认为表单验证就该包含在表单里面， 有些则否。 这些延伸需求，使用者看得到的项目应该是明列给案主讨论， 一些隐性的需求（ex.正规化层级）或预留的扩充空间， 甚至是程式码注解，则是视案主预算跟合作态度增减。 （哪些项目需要讨论、解释，哪些不用这很难拿捏， 基本上案主花钱就是要你处理问题，有些过於技术的问题， 还是应该要用自己的专业来协助判断。） 总之，你开了这个价格， 就要找能对这个感到价格有物超所值的案主再接。 不要让案主很勉强接受你这个价格，这样你验收可能会很难过， 也不要让自己很勉强接受案主的价格，这样你会开发的很难过。 尽量一开始斡旋时可以让双方的认知在比较一致的区间。 基本上可以的话最好了解一下案主的经费来源跟案主的类型， 来判断案主对预算的接受程度， 根据经验，公司行号外包的价格通常比较活。 垃圾案*（即原为自己职务内容，但因种种理由转介外包）的价格 通常比较死。 垃圾案：即原为自己职务内容，但因种种理由转介外包。 （基本上垃圾案尽量不要接，要看案主处理的态度， 因为垃圾案往往会有两层以上的案主，验收跟spec很容易出问题。 举个例子，我曾经碰过一个厂商转包，请我做了东西之後， 他们又要拿去让他们某国的客户点头才愿意付钱，（做完了才讲...） 於是就一直修一直改，那时候拖半年最後还是没有搞好。-_-;; 不过这个例子主要是当时没有签约跟明定spec才会这麽棘手。 ） 学生的案子，价格通常也是没得商量，但是学生的预算空间起伏大， 有那种五百块就想叫你写GUI还包山包海的， 也有几千块只希望你帮他搞定db connection string的，很难说。 如果是梦想家*的案子，视专案的不同期间有不同的预算空间， 刚起步的通常很有钱，中期的普普，後期的可能就很抠。XD 梦想家：指有点子，希望能找技术人员实作的创业家 这也有例外啦，不过通常例外都不太会找外包，而是自己养人了. 5.时程 千万不要delay ！ 原则上要把时程切分为三个阶段跟一个可能的delay阶段。 第一个是谈，谈妥spec後先进行粗步的沙盘推演， 有问题就继续谈，没问题就开始签约做案子。 （谈的时间跟案主希望做完的时间成反比， 也就是案主希望越快做完的，就要谈越久以确保全盘了解。 第二个是做，这阶段你应该要定期跟案主对谈， 让案主能够了解你的进度，一方面是让案主有参与感， 二方面是进行各项功能可能的再确认， 最重要的是把碰到的困难跟解决方案或者自己的意见提给案主， 万一时程真的有状况，也比较好处理。 尽量不要到要结案的时候才联络案主， 不然验收通常会拖很久，甚至是直接 delay 到。 第三个是验，这个阶段把握要则就是没收到钱不给东西， 不一定要收到全部的钱，但是至少要收到一定比例的案金。 验收的时候，如果有发现已知有功能有bug的就先不要让案主测， 直接跟案主告知，如果已知的BUG尽量不要让案主自己测到 ， 宁可自己先跟他说有bug ，以免造成不必要的误会、误解。 如果到这个阶段，但程式还没做完，还是要验！ 要让案主了解目前的进度跟碰到的困难，以利进入後续的delay协商。 ---------------------------------------------------------- 如果你不幸 delay , 那很不幸的 , 这个案子基本上已经砸一半了. 基本上 delay 时，之前不管过程中间你答应帮忙额外多做什麽功能， 只要不在原始签约时协议好的，请先统统跳票。 理由很简单，那些额外的功能会因为你delay 有额外的时间， 而延伸出额外的发展空间（而且通常不会给钱）， 所以宁可先结掉眼前的案子拿到钱，再额外帮他做那些东西， 也不适合先做完那些东西再结案。 在案主的心态里，如果你没把眼前的案子给结掉， 那你现在做的就都不是所谓的多做，而是你本就应该要帮案主做完的。 但是如果你结案再回头做，这两种情境的心态就会不太一样。 还有一个很显而易见的理由， 你的 delay 很有可能是这些额外的需求造成的。 通常时程只要 delay ，一方面铁定会打坏一部分印象， 另外会给案主不知何时能确实结案的感觉。（等同於案子无限期延期） 如果案主自己有时间压力那就还好，他会比你还赶着结案。 如果案主没有时间压力，那这时候根据经验就是苦痛的开始。 只要一有 delay 的现象，请认真评估自己是不是做的完， 有时候会因为真的做不到而 delay ，而且通常接案方 心理上会拒绝接受这个事实。orz 如果你认为是做不到时请毅然断尾求生，违约如果有罚则的就认赔， 没有罚则的就明白跟案主说明清楚，自己这个案子做的就当白做， 有收的订金就退还。 至於已经做好的东西要不要给案主就看个人良心。 有时候案主也会同意你用比较差的东西来结案， 不过更多的时候是会抓着你希望你做完啦。:~ （这种时候如果做不到我是觉得就直接拒绝吧， 已经花时间去做的东西还做不到，做更久也不会有好发展。） 再怎麽样，我是觉得不要变成拿了钱又给不出东西就跑路， 这种情况其实对你自己或发案方都是很大的折磨。 反正碰到 delay 就要尽快结案，而且要让案主感觉到你有结案的压力， 如果碰到觉得案子逾期没什麽大不了的案主， 请千万记得他逾期他晚付钱还赚利息， 你逾期你等於多上了个拿不到钱的死会，还不知道要缴多久。XD 6.售後服务 自己做出去的东西，三不五时就去看看， 跟案主聊聊看原本的系统有什麽不满意的地方， 如果是系统 bug 当然要帮忙修（提昇满意度）， 如果是介面、资料的改善、维护， 则可以考虑提新的维护需求或维护案， --------- 这篇设定的浏览者是给接案方，如果您是发案方而文中有得罪之处还请见谅。 如果文中您有任何不认同的地方欢迎直接讨论、指正， 这是我作到现在的一些感想，我也很想多看看大家的意见。 XD 描述、例子多，文字可能有点冗长，还请见谅， 因为是临时起意打的，可能有些部份没有很周全，有兴趣就再讨论再研究罗:) 有些很复杂的领域（ex.如何交付、验收内容比较好，合约内容等）， 我的心得可能就不太适合给所有人参考，或许也可以一起讨论看看～ -- What do you want to have ? / What do you have? 从书本中，你可以发现我的各种兴趣。 从ＣＤ中，你可以了解我所喜欢的偶像明星。 或许从文字你很难以了解一个人，但从物品可以。 My PPolis , My past. http://ppolis.tw/user/Tony --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.224.103.13 哈哈 谢谢 , 已修正～ 楼上高见! XD ※ 编辑: TonyQ 来自: 61.224.103.13 (01/10 12:36)