有些合作,因为话都说不清楚,所以不愉快

有些合作,因为话都说不清楚,所以不愉快

——自由人Web开发中如何提交需求与如何引导需求

我 是一个学生独立开发者(标题中的“自由人”),每月课余帮人开发网站或Web应用可以获得不少回报,过着小日子。但是在和雇主的沟通中,偶尔也会发生不愉 快的摩擦,导致心情跌落,小日子变成了大姨父光顾日。我意识到,在与我类似的Web开发中,雇主如何明白清楚的提交自己的需求,开发者如何引导雇主把需求 表达完整,是一件非常重要的事。因此,我把自己的一些感悟写下来,希望能为大家提供一些参考。原本这应该是两篇文章,一篇写给雇主,一篇写给开发者或开发 团队。但是,我比较懒,而且考虑到雇主估计不会看这篇文章,所以就干脆写在一起。

529e41ec1a8c8a8e44c2dd201d20fbfb

没有事先明确需求,导致小矛盾积累成大矛盾

开发者的工作仅仅是把需求实现成成品,分析和提出需求是产品岗(产品经理)的事。

但 是现实是,在类似我这种接单开发中,根本没有产品角色的存在,因此对需求的分析和细化,必须要么由雇主来做,要么由开发者来做。运气比较好就能遇到一个明 事理,把需求条条框框写清楚,甚至还给一些示意图的雇主。运气不好,雇主最多就是“这个应该很简单”“需要你来设计”“遇到问题再问”此类的搪塞。所以, 无论是雇主,还是开发者,在进行合作之前,一定应该先把需求细化,否则在之后的开发中一定会遇到一些可能导致双方不愉快的问题。

很多合作中,因为雇佣双方知识概念的不同,导致交流中存在障碍,而如果双方都不愿意花时间精力去让对方搞懂自己说的真正意图,那么就是标题中所说的“话都说不清楚”,合作一定不会顺利。

noasfasdf

雇主可以做什么

作为雇佣方,你应该考虑更多的是,让开发者帮你把东西做的更好,而不是把开发者当做你的员工,认为对方可以从你的角度出发为你分析具体问题,更不要奢望开发者能够超出100%预期给你做出比想象还完美的成品。

那么,要让对方把你的东西按照你的要求做好,你应该做什么呢?

事先花2个小时仔细分析你要请人做的东西,事后能给你节省10个小时。

我 遇到过懒的雇主,告诉我“我要做一个医药价格对比网站”,我说“可以做”,他马上说“那你开始做吧”。这就好像说,我要修一个别墅,你现在开始修吧,至于 要修中式的欧式的,修在哪个位置,要什么情调,有什么用途,我不告诉你。对于建筑师而言,心里只会暗骂道:TMD,修来是你住,又不是我住!因此,作为雇 主,你想让低价雇佣一个临时工帮你完成一个开发,就必须想到,应该提供完整的信息,让他可以快速上手。基于这个道理,如果你要做的东西不是直接抄袭另外一 个产品,那么起码要花上2个小时的时间(理想状态)来进行自我分析。

记住我说的,如果你不提供详细的产品介绍,后面你们的合作中99%会出现矛盾,因为我知道开发者99%是奇怪的动物,你们之间的交流存在星球障碍。

再 想清楚你要请他开发的这个东西要实现什么功能,如果你是这个产品的一个普通用户,希望能够如何操作它,并且体验到快感,这之后你可以进入下一步,写写这个 产品的具体细节。这一步是最费时间的,如果你的产品逻辑比较复杂,你可能还要提交一些表格,例如会员积分,积到多少分就是多少级,或者类似的一些数据逻辑 处理的东西,如果没有事先准备好,后面再去做,你就等着抓狂吧。

手绘产品示意图,标明每个细节的尺寸。

看到手绘你肯定又 会骂了,妈蛋,不就是做一个小网站,还TM手绘,你妹啊!但我想说的是,你可以不用手绘,只要你能接受最后拿到一坨屎。手绘的目的是告诉开发者产品的基本 结构,让他心中有数,即给了他一个大纲,他可以在此基础上发挥(别想了,这些开发者不会超出你的预期的)。开发者最恼火的就是没有明确的指出要做什么。如 果你说他做的东西是坨屎,重做,而不告诉他哪里怎么改,他一定会马上像疯狗一样反咬你。但是如果这个时候你告诉他,那个地方有问题,那个地方要怎么改,那 个地方没有对齐,那个地方要换颜色(把所有的“那个”列在一个txt文档中发给他),他马上就乖乖按你的建议改了。

手绘的示意图中要标明尺寸,不要嫌麻烦,每一个尺寸都可能关系到你最后看到的是不是一坨屎。

你可能觉得站在对方的角度去帮他节约时间,太花你的时间了。但是保不准最后你们的合作会破灭,你还需要招其他的合作者,而如果你这些东西都在手里,和新的合作人谈就是分分钟的事,而且可能还能获得更低的价格。

如果某个地方是动态效果,无法用静态图表达出来,应该有专门的文字描述。

有 了手绘大纲还不够,还要细节。特别是在某些静态的图画中无法表达出来的东西,例如你通过截图,让对方按照截图中的样子做,但是没有告诉他这个地方要通过哪 一个按钮来切换,完蛋了,最后你拿到的是一个静态的页面。所以,某个地方如果是要实现动态效果,要用红色的笔圈出来,在文档中注明清楚,这个地方的动态效 果是什么,是点击之后从右边滑出来呢,还是鼠标放上去之后就立即显示出来。这里其实花不了多少时间,但是如果你不事先描述,同样后面会抓狂。

你想让这个地方怎么实现内容更新?

直接告诉对方,这个地方我希望通过后台来实现内容更新。后台内容撰写的地方,最好是有标题、内容,内容可以上传图片,可以自动获取标签,可以自己插入相册,可以自己安排排列顺序等等。

前面提到了你要把自己当做一个普通的用户来使用你的产品(当然,是你想象中,因为产品还没有做出来),而在这一步,你要把自己想象成内容编辑或运营主管,怎么操作产品中某些细节内容的更新。

把素材、文字材料等内容准备好。

前 面已经提到了要把积分规则之类的逻辑数据事先准备好。除了这些业务逻辑说明之外,例如要用到的图片(如logo、内容中要上传的图片,最好是可编辑的), 一些文字材料(如公司简介等)都要准备好。有些资料,最好还要做出表格,让开发者一目了然。只有把这些细节的东西都做到位了,后面你就可以跷二郎腿等结果 了。

通过上面这些思路,整理出一个完整的需求文档(看上去好多,但实际上很多需求可能只需要花2个小时)。把上面的这些东西全部整理好,某 个文件的命名命名好,让开发者一目了然,然后打成一个压缩包发给开发者。尽可能的检查好,一次性发出去,如果实在有遗漏,或有补充,一定要在新发送的文件 名、邮件名中非常明确的标明出来。

开发者可以做什么

你确实很有个性,很牛逼,但是注意:你没钱!《让子弹飞》里有一句话,叫“站着把钱挣了”,你以为这是在电影里或在你家乡火星么?所以,暂时放下你的个性,老老实实做一个地球人。

开 发者在和雇主合作的过程中,遇到最大的问题就是不能理解对方的需求,人家要的是非常简单的功能,他会想的特别复杂,人家想要的是高度可定制,结果他想的是 写死在代码里。所以,当开发者已经具备了开发的能力之后,唯一需要做的就是去了解雇主的需求。但是由于双方来自不同的星球,交流的时候脑海中的概念是不同 的,所以开发者应该考虑去引导雇主描述需求,把雇主当傻子,把话说到傻子都能听懂的程度。

让雇主相信你的开发能力和价格梯度

雇 主的心态都是这样的:又好又快又便宜!而作为开发者,我不提倡说:又渣又慢又死贵。我只希望世界上所有的开发者都能如实的获得自己的劳动回报。独立开发者 或团队,因为没有成立公司,所以价格上要便宜一些。但不代表实力和真实价值会低,(相反有些公司徒有其名,东西很渣)应该想办法把能力展示出来,并附上开 发价格梯度,表面物有所值。

怎么表现你的开发能力呢?首先得有一个技术博客吧,不管是csdn的,还是搭建在github上的独立博客,都要有给人一种专业干这个的印象。其次得有作品,越成功的作品,越应该放在你的博客险要位置进行展示,并且对作品的开发难度、开发过程、价格等进行描述,让现在的雇主心里有数。再次得让人直观的感觉到你能做出好产品,美化你的博客或团队网站,在界面上就要吸引对方,让对方觉得选择你一定能拿到完美的最终成品。

标明价格梯度。因 为开发产品跟生产产品不一样,价格上无法准确的给每一个开发需求定价。因此只能划定一个区间,例如普通网站(把案例放在边上)多少钱要多久时间,高级网站 又要多少钱要多久时间。还有一种定价方法,就是把一个需求切割为不同的模块,根据自己的经验,对模块定价。例如你事先规定,一个代码量为200行的功能多 少钱,1000行的jQuery功能多少钱等等,然后对雇主的需求进行拆解,确定最终的价格。

最最重要的是,把这些展示能力的内容和价格梯度放在你博客的特定页面,在合作之前就要让雇主知道。

或许可以给雇主提供需求表格

如前文所述,雇主一般都是抱着爷的心态来的,啥啥不会,还装高贵,你让他写个详细的需求,他顶多花半天发给你一个夹杂了巨丑无比图片的不到两百字的文档。所以,主动提供需求表格给雇主填写具有非常大的作用。

需求表格中最好包括:雇主的基本信息,产品的基本信息,功能需求,界面需求,价格,后续服务等等。当然,我这里做不到细化,希望读者朋友们各抒己见,共同来完成一个这样的需求表格。

拿到这个需求表格,你基本就能确定自己要做一个什么东西,有了大的方向。具体的细节,还需要下一步来做。

在获取需求之后用你的视角重新描述一下需求反馈给雇主

你获得需求之后,作为雇主他可能只能从一个非常浅的表面进行描述(他不是产品经理),因此你可能需要充当一下产品经理的角色。通过对大致开发方向的分解,把每个细节要表现的东西都用一个文档拆解出来,并进行描述,把你认为可能要做成什么样子写下来,甚至把你将要如何进行开发,完成之后会是什么效果都写下来。然后把这个文档发回给雇主,雇主对你的理解进行一一反馈,如果双方的想法不一致,那么你就要仔细的和对方进行探讨。

这一步的目标,就是要在你的脑海中构建出完整的产品,不单单是轮廓,还有细节,就像前文所说的,页面元素的动态效果,操作方法等等,这些你都要了然于胸。尽可能做到,不要有些细节到后面做的时候才回头来问雇主。

雇主需要的是最终可用的产品,不是你的半成品

要 搞清楚雇主最终需要一个什么东西,仅仅是一个功能,还是直接用在产品环境中使用。我以前遇到过一次,有个人找我做开发,提出要在网站前台增加一个搜索功 能,听上去如此简单,于是我欣然答应了。谁知道,做这个功能不是基于他现有的数据,而是要另外增加数据,于是前台、后台、数据库全部都要补充,连显示的页 面都要全部新做。看似一个小小的功能开发,最后其实变成了一个模块开发,却只收了200块,那种悲凉你懂的。这是由于我事先没有了解清楚导致的。因此,在 达成合作之前搞清楚对方的现有状况和最终目标之间的距离(这个变量公式我们可以用“Δ=Goal-Present”来表示,Δ极为重要),弄清楚之后再重 新思考合作、定价之类的事情。

做好与地球人打交道的准备

作为火星猿类,开发者要学习擎天柱的精神,入乡随俗。你现在已经 不是在网络公司了,没有上面给你发布任务,而是靠你自己分析和解决问题。雇主看似是你的服务对象,但是他没有公司那么缜密的思维,更没有公司行政小蜜那么 贴心。你必须了解地球人雇主的心理和生活方式,然后见机行事,最重要的是,你要从他手上拿到钱。

归根到底,开发者身上要处理好两件事:一是帮助雇主,详细描述需求,开发之前就要在脑海中形成完整的产品;二是控制自己的个性,学会如何从雇主身上赚钱。

沟通中从对方的角度思考(非正式性)问题

对于雇主,遵循这样的一条原则:出了钱也不是爷,好态度决定好成品,装模作样是作死;使用肯定句,不使用疑问句或祈使句。

对于开发者则遵循:没有产品经理,你就是!想拿钱?学会如何在地球生活。

控制情绪,冷静想想,你合作的目的是什么。对于雇佣方,你应该想:妈的,只要你把产品做好了,劳资下次不找你做了。对于开发者,应该这样想:艹,等劳资拿到钱,就是大爷,不接你单了。但是,在拿到成品或佣金之前,你最好都装下孙子。

有 些雇主很好玩儿,明明不懂技术还要装懂,知道几个诸如模板、插件之类的词之后,就装模作样的表现的很勇敢,用theme/plugin之类的非人类词汇来 代替。这在开发者面前就是作死的节奏,其实在开发者面前,雇主最好装傻子,双方是合作(而且是愉快合作)的关系,不是学习或显摆的关系。在这个地方我本来 想用“谦逊”一词,但是想想,还是觉得用“装孙子”比较靠谱。

还有需要提醒的是,开发人员极其烦躁在自己开发中连续不断的打断自己开发的行 为。因此,如果你在开发者开发过程中打断他时,100%要通过把想法一次性发给他,无论是通过QQ还是通过写一个txt或邮件发给他,绝壁不要用QQ连续 发10条消息过去,如果连续发5条,最后你拿到的肯定是个半次品,如果连续发10条,最后肯定只能拿到一坨屎,相信我。

雇主身上可能还存在 一个问题,就是放出暧昧的信号,让开发者摸不清状况。不要用疑问句和开发者商量,例如“你觉得这个地方是用红色好还是黄色好”“你有没有什么建议”“你觉 得要不要加入这个功能”“你是不是可以加快速度”等等之类的疑问句要坚决杜绝。也不要用祈使句,例如“这个地方要你自己设计”“这个地方要你来安排”“这 个地方你看下怎么好怎么处理”“你想怎么弄就怎么弄”,你永远想不到连“你想怎么弄就怎么弄”这样放荡的话都会被开发者认为是架在脖子上的镰刀一样。所 以,你只要用肯定句就可以了,“这个地方用红色,C90000”“这个地方是动态显示的”“这个地方必须能够自动出现”,当开发者看到“必须”这样的词汇 的时候,才感觉遇到了知音(本来我想用个更形象的比喻,为了和谐社会还是放弃了)。

独立开发者自己干,就是不想受制于公司,有种自己给自己 当老板的感觉。但是要知道世界上所有的生意都不好做,你自己当个光杆司令老板,也必须要有能力谈成生意,做出产品才能赚到钱。你不是天天谈用户体验吗?雇 佣方也是你的用户,而且是大用户,你要把用户体验的那一套套都要拿到这里来,懂了么?

另一方面,开发者如果一直抱着“我不是产品经理”的心 态,就会和雇主之间产生摩擦,甚至合作破裂。我也一直有这种心态,雇主应该把详细的需求给我,我按照文档中的需求一条一条去实现就好了。但是现实根本不是 这样,如果不及早调整心态,让自己去干一些需求分析和做心理咨询师的事情,那么永远都别想赚钱。

独立自由的开发者,说的好听叫创业,说的不好听就是混日子。只有调整好心态,用积极的商业情绪去应对雇佣合作,才能日趋成熟,当然,赚到更多的钱。

防止矛盾激化后合作破裂的一些建议

因为这种雇佣关系是非正式的,没有法律合同的,所以得不到法律保障。做一些保护措施是有必要的。

找对人

我之前把收取定金放在第一位,但是现在我觉得找对人才是最重要的。

你 作为雇主,要找这样一个人:牛逼,可信,做出来的产品安全性高,性能好,用户体验杠杠的,当然最好还要便宜,开发速度就暂时不用考虑了。通过各个方面去考 量找到的开发者,同时要适应开发者的思维,比如有些开发者有好作品,但是不屑于显摆,你要看作品是吧,就给你一坨屎看。所以,要根据开发者的个性来,但上 面是前提。

最为开发者,如果遇到这样的雇主,即使你已经开始干了,也最好把定金退回去:让他(按照上文)提供详细需求,给你扯犊子,满口 “很简单”和蹩脚的英语词汇,傲慢,炫富,做到一半你以为差不多了,他给你来一个新需求,甚至有些还没有把需求搞清楚就要给你定金的,千万不要接。开发者 都是折翼的天使,要保护好自己脆弱的心灵。

收取定金

收定金不用说了,我一般选择两种方案,一种是第三方托管,全额,另一种是先付50%定金,是否最终完成,不退。

再获取完整的需求之后再收定金,我遇到过好几次,一说定金,马上就支付宝转账过来了,做到后面这里不行那里不对,纠缠的要死。那些很爽快给定金的,也不一定是好雇主。

类似合同一样的文字材料

双 方各自声明自己的权利和义务,通过邮件的形式(不要QQ)相互发送。其中的条款写清楚,其中要把上述需求分析模块化写进去,完成哪些就给钱,没完成的,或 提出来多余的怎么处理。这个类似合同的文件要合作之前就确定,开发到中途有新的需求提出来,要再拟一份,当做两个子项目分开来。

不到最后一手交钱一手交货的时刻要留一手

我被骗过,有个人一开始态度极好,给了一半的定金,到后面慢慢开始油了,拖着不给钱,最后MD跑路了,悔恨自己不应该提前不做处理把代码发给他。无论是雇佣方还是受雇方,都要留一手,到最后一手交钱一手交货的时候再把留的那一手放开。

结语

写 了那么多,我主要还是站在开发者的角度去写。其中有很多不足或偏激之处,读者朋友有自己的想法的,请通过评论互动。作为雇主,如果不小心读到本文,也能感 受一下作为开发者对雇主的一种期望。我希望通过本文,让像我一样的独立开发者,和那些通过网络寻找开发者的朋友,都能在开发这个事情上各有所得。【完】

2014-10-31