《如何逃离垃圾客户（上）》

故事三：朋友介绍的好机会

C：高级程序员，5年代码工作经验。在职，工作清闲，偶尔接点私活。

外地人，在北京漂着，8K月薪税前，偶尔需要加班，有个职业普通的女朋友，买房甭想，打车掂量掂量。宅男，回家了就看看资料看看美剧，长时间持续的代码工作，视力一天不如一天，脖子和腰也经常不舒服。

C经常想，不知道有多少程序员过着像这样的生活，不好不坏，无力改变，也没有理由去改变。

好在他性格温和，人缘很好，经常会有朋友介绍一些私活给他，除了挣点钱，对生活也是一种填充。

C一个挺铁的哥们跳槽到一家传统行业的公司，公司需要开设电子商务的业务，就找到了C帮忙搭个系统，费用也不低，C欣然承应。

客户公司不大，对互联网有一定了解，由市场部门和C沟通接洽。 他们并没有太明确的想法，希望和现行跑的大部分网店差不多就行。C就用开源系统搭个一个，按照客户的要求建了分类，录入了一些测试数据。

客户总是不知道自己要的是什么，但是知道什么是自己要的。

有了可视的DEMO，客户也就有了想法。他们提出要根据自己的业务特色增加预订货物和预定管理的流程。

而此时C还没有和客户签订正式的合同，只明确了开发费用的总数，也没有具体写明任务清单。因为有朋友在这，这家公司做传统行业也有不少年，信誉上问题不大。所以C也比较放心。先花了一两周改造了开源程序的流程。

客户提出界面的风格和品牌形象不太匹配。C找了一堆开源皮肤，让客户挑一个。客户挑了几个分别换上试试。两周又过去了。

客户提出商品的缩略图尺寸不够大，图像质量不够好。C修改了GD库和图片压缩的参数。

客户又提出缩略图列表页 图片有横版有竖版不够整齐。C只好又修改了缩略图截取的程序。

此时已经过去了6周，C开始催促朋友，先把预付结了吧。朋友甚至有点惊讶：“还没把预付给你吗？我赶紧帮你催催。”

客户持续像挤牙膏一样地挤出需求。加个水印啦，添加一种排序关系啦，改下分页啦。 预付还是没有到位，补签合同显然也不太现实，朋友每周都在表示抱歉，表示一定帮忙落实费用，总是有些财务上的预算上的付款期上的理由。

C已经意识到自己已经掉进了一个大坑：项目时间持续流失，客户意见时常反复，需求零敲碎打但都不复杂，总体来看也并没有脱离当初定好的项目框架：利用现成的开源代码搭建一个客户需要的网店系统。可是到现在为止所耗费的工程时间和工作量已经足够自己重写一套了。

爆发的临界点终于到了。客户看了竞争对手的网店，发现了很多新功能，所用的开源系统是同一个，只不过使用了最新的3.0版本。 客户要求也对自己的系统进行升级。

• C性格再好也忍不住了：“我以前专门提醒过：已经对系统进行了那么多的定制化改造，如果升级，所有定制化需求都得全部重新改一遍。使用开源系统如果要升级就不能做太多改造，如果要定制化就得放弃升级！
• 客户：“当初也是你建议我们使用开源系统的.”
• C：“你们又想控制成本，又想节省时间，又不知道自己要什么，需求又总是反复，开源系统是最好的选择了。“
• 客户：“但是你看，现在很多我们需要的功能没有，这个问题总得解决吧……”
• C：“如果这个功能是需要的，在项目开发初期不提出？”
• 客户：“竞争对手有，我们没有，这个就是必需的。”

C十分气愤，客户也很不满，C的朋友夹在中间也非常尴尬。 费用一分钱还没拿到，而项目已经过去了2个半月了。

C对朋友忿忿地说：“唉，这事没法接着干了，我也不让你难做，费用结不下来就算了，以前就当白干了，就当我给你帮忙。”

朋友：“别别别，你这么说我太过意不去了，我再去和他们部门说说，他们啥都不懂，就是一堆草包。我当初给你介绍是好意，总不能到头来还让你吃亏。”

不知道朋友的协调起了作用，还是由于C撒手不干的强硬态度，客户支付了总报酬的50% 。

C看着拿到手里的钱，算算已经用掉的时间，摊到每个月的报酬甚至都没到4位数。

虽然C的态度开始强硬起来，但是对项目本身并没有任何改善。 项目还在像挤牙膏一样继续，棘手的问题依然存在，进度变得更加拖拉，C在看不到头的时间线上 烦恼地进行着无尽的改造……

———-涕泪交加的分隔线———–

1. 由朋友介绍来的项目，如果他并不参与项目并能起到决定性作用，要慎接。不然可能到头来生意和朋友都为难。
   
2. 然后状况下都要明确合同、预付、任务明细。不然你会加速步入沼泽。关系不能代替承诺，约定不能代替协议。轻视游戏规则的代价就是失去规则的保护。
   
3. 如果意识到合作方是垃圾客户，一定要不惜代价，立刻刹车，及时止损，不然你只会付出更多。
   
4. 一般情况下，追加性支付的费用只是在增加你及时止损的代价。不能改善任何问题。
   
5. 在开发项目中千万慎用开源代码，除非确定客户没啥定制化需求。特别要慎用多套开源代码的组合。我亲身经历过客户为了省钱省事，搞了套dede+ecshop+disciz+WPmu的组合系统然后再改，结果花了大半年时间才最打通组合系统之间的各种关联、调用等。不光耗时和人力成本超过了重新开发，多次上线跳票也害死了客户的市场与销售。

————————————————————————————————————————————————————————————————

故事四：大客户的诱惑

D: 项目经理 web技术服务外包公司的创始人，创办时间2年，开发团队规模6~7人，业内口碑良好，主要通过朋友推荐获得项目。

做外包项目的公司心头总是有一块软伤：收入来源不够稳定。解决方法当然是找几家长期合作的大客户，承接外围项目或者维护类工程，磨合成本低，价钱公道，合作风险低，作为客户案例拿出去多体面。

大网站、 知名品牌、 外企和政府都是作为大客户的理想人选。

D终于遇到了这么一次好机会，某国际知名品牌的web业务部找到了他。

他心里也很清楚，大客户一般自己的开发团队齐备。能外包出去的一般都是一些比较棘手、担责任、跨平台的活，或者人手不够，没人爱干的独立的外围项目。

D和甲方的相关部门见面谈了谈：D的公司的资质和口碑不错；甲方许诺只要干的好，明年我还有多少多少外包预算……，一拍两合。

合作这事和招聘差不多，首先要解决的是信息不对称的问题，信息渠道问题解决了，只要别太离谱，基本都能成，然后双方各自许诺一番，都怀抱着美好的愿景开始合作，……。

D先给甲方干了一次 跨平台的历史数据迁移的活，不错挺顺利，算是试用期OK。

接下来是为甲方新上线的一个产品系列做一套独立的宣传平台，前端 + cms + 专题。

首先需要打交道的是该产品系列的市场部门负责人，先得把产品端效果图定下来。

对方只提供了一份没有任何详细说明的PPT框架图。D只好反复碰需求，终于弄清楚了对方想做的是什么。D用专业的格式和表述性强的文字重写了规划，附上详细说明，流程图，框架图，任务清单，甘特图，预算清单。请对方负责人邮件确认同意。

程序和产品端开始并行开发了。

产品端部门的遭遇：

首页的UI demo稿发过去，第二天就收到了甲方的反馈邮件，从配色到间距到配图到文案，密密麻麻全是修改意见。

设计师隔天送上了修改好的首页。很快收到甲方的反馈邮件，依然密密麻麻全是修改意见，比如配图不恰当啦，LOGO的摆放位置不对啦，文案需要改字啦。

设计师隔天再次送上修改好的首页。很快收到甲方的反馈邮件，仍然还是修改意见，包括配图需要再更换，文案还是有文字变动啦。

只有等首页完全敲定了，设计师才敢开始第二批次页面的设计。

此后大概每批次页面设计会经过至少3轮的修改，大品牌嘛，总有无数的规范和细节要求，文案和配图斟酌了再斟酌。产品1是放在产品2的前面还是后面，产品3是被产品2挡住1/2还是1/3。
……

demo终于定稿。对方终于满意了。设计稿提交到品牌市场部总监那里。

一个不幸的消息传来~~ 大BOSS认为布局不够好，要求把三栏改为两栏。

D只能在自己办公室里拍着桌子大骂：“靠，原来你TM不是拍板的呀，那天天在那瞎使唤啥呢。”

———————————————

程序部门的遭遇：

程序部分的代码已经完成了，D交给甲方的IT部门，以便合并到对方的整个web系统中。

之前D和甲方的IT部门的接触并不多，他们没提出过什么问题，也没什么意见，就沟通过关于语言版本、数据结构要求等。等到系统一合并，各种各样的问题立刻冒了出来。用户通行证没法处理做、检索索引格式不规范、ID位数不统一 等等。

一个突然冒出来的管数据统计的大哥也发来一堆问题邮件：要求预埋log代码，要求增加统计相关的字段，log格式不规范……

距离约定项目上线剩下的时间不多了，D这时才刚刚被告知了许多应该在项目开始前就应该知会的事。

D在电话里愤怒地向甲方质疑这些问题。

但是看起来没有人该为此而负责任：

• 市场部门说：“我不是给了你IT部门的联系方式吗？你们是搞技术的，你们更应该知道沟通什么”
• IT部门说：“我们不是太清楚你们具体的开发需求什么，不然有些事情会提前提醒你们注意。”
• 数据统计说：“我们一直备有统计方面需求的规范文档，你应该提前联系我们。”

D又在自己办公室里拍着桌子大骂：“我怎么知道数据统计属于IT部门还是属于市场部门！！我怎么知道你们的垃圾编制！！ ”
……

冤归冤，活还是都得干完。D只好紧急组织了加班。

————————-

最冤的事其实还没到来。

产品整合、系统整合都没问题了。东西终于就可以上线了。市场人员已经在测试发布内容了。这时D接到了来自甲方的SA部门（网管）电话，说“安全性上有严重问题！！不解决这些问题，系统是绝对不会允许上线的。”

D收到邮件一看，都是些莫名其妙的安全问题。比如CMS系统的登录安全：有很多种解决方案，比如http验证，比如内网限制IP，但对方提出来的显然是最麻烦的一种解决方案。

还有一些安全性措施，从工期和实现根本是不现实的。更有一些完全是不必要的。

D和SA沟通后，对方根本不肯进行任何让步。

D只好和甲方的市场，IT部门进行沟通，声明上线的阻碍。他们显然也没什么办法，只能说尽量斡旋，让D尽量配合。

D尝试改了一些，提出了一些中间方案，都无法得到SA的认同。D很快意识到，自己实际上已经卷入了部门斗争，正在成为牺牲品……

SA还是不肯让步，上线眼看就要延误了，甲方的市场部门也在施加压力，要求提高配合度。

“MLGB，配合个毛，根本就是强人所难！根本就是在找茬！你们之间的鬼事凭什么要我们承担代价，凭什么要我们负责任，我们之前配合度不够高吗？你们大公司整天讲流程，要求流程，这就是你们按流程办出来的垃圾事？”

D一边在办公室里破口大骂，一边写了一份语气强硬的声明邮件，抄送给甲方所有相关负责人，逐条指出了SA邮件中的漏洞和问题，声明合作无法继续，不要尾款，退出项目，同时交付所有开发完毕的源码。

“去你的大公司，去你的外包预算，去你的明年的合作”

很快甲方发来了致歉的邮件。

SA也发来了可以妥协，什么事都好商量的解决方案。

而D，把它们都直接送进了垃圾邮件箱……

做项目做产品可以有3个境界：1 挣钱的，2 做品牌的，3 很酷的。有的人从境界1做到3，有得人从3做到1。

我是从1做到3，因为有了钱，你才能远离垃圾项目和不专业的客户。

无论你是单打独斗兼职之余接个小项目，还是已经成立了公司签合同盖大红章接外包项目，初期阶段都遇到过垃圾项目和垃圾客户。你有可能拿到了搭上了无数个不眠之夜，只获得了少的可怜的报酬，受了一肚子气还不落好，客户正和你在心里互相怒骂。也有可能一分钱都没拿到，受骗感和屈辱感正驱使你要去百度贴吧上声讨那个客户公司。更有可能把你的一帮弟兄们一块拉进了一个大坑，你人生中最重要的资源之一正在廉价地流失。

垃圾项目是一个必经阶段：

• 考验你团队是否能同甘共苦肝胆相照
• 磨练你的耐心和自我控制力；
• 让你学习代码规范、架构规划、分工设计、进度设计、质量控制等预防规避机制；
• 帮助你健全任务计划、进度反馈、测试文档、邮件、合同、备忘录等重要文档规范

下一步你要做的就是一看见垃圾项目和垃圾客户，就跑得越远越好！！

下面我来讲一些可能大家都经历过的故事：

故事1 你得尊重我们

朋友A：一个小建站公司的创始人，优秀的WEBUI设计师，公司正起步阶段。

A偏重设计，主要接一些公司宣传类型的小站。纯界面类的活，后台拿现成开源的程序那么一套，他做设计又驾轻就熟。遇到一个做少儿智商启蒙培训类的公司做宣传站。一切谈妥，A说把公司LOGO发来吧。客户告之还没设计出来，你就先做吧。

朋友A按照少年儿童花朵般的特征选用了湖蓝和嫩绿的基调配色，这可是2.0流行色，又大方有时髦儿。大大的焦点图，这可是2.0的流行做法，视觉重心稳定，结构分明，有设计感。

做完客户表示挺满意。下面就该把客户的LOGO和要用焦点图替换上去啦。

好嘛 LOGO是大红色的旭日升起状，下面写着3字 “红太阳”。

焦点图客户有指导意见了：5张图对吧，得放我们领导的照片，签名还有题词。

拿来一看，全是大爷大妈腆着肚子，指点江山的照片。

朋友A顶着得尊重客户的想法硬给换上了。

结果就是页面怎么看也不好看了，能好看得了吗。客户不满意了，于是提供指导意见要求改动改动。这一改动完蛋了，越来越别扭。上线日期已经到了，页面正在变得越来越难看，朋友A正在变得越来越悲痛，客户正在变得越来越愤怒。上线前页面勉强丢到了线上。客户很不满意地付了钱，朋友A飞也似地逃走了，一个月后客户的网站另请人完成了页面的改版。朋友A上去看了一眼以后再没勇气看第二眼。他把这个case永远地从客户案例列表中删掉了。

故事2 我们要做成一个伟大的项目

朋友B：SOHO，一个6~7人规模的web项目开发团队的领头人，项目经理，产品端经验丰富。

B以为遇到了一个天赐良机，坐在他对面的这个人充满了激情野心与斗志，他健谈，机智，敏锐，富有感染力，他善于规划，他尊重人才，他对互联网每种盈利模式都熟知，他轻描淡写地说着手里拿到的强大资源。B的眼睛也闪闪发光：“关键是这个人器重我，器重我的团队，而且报酬也不错。”

B带领团队已经成功做了几个不大不小的项目，团队成员都不错，都能各挡一面。B的每个项目都签定合同，50%预付，50%尾款，最大程度上保障团队成员的利益。

客户说，你现在起就是我最重要的合作伙伴，我们要做成一个伟大的项目。

他们的合作正式开始了。

客户已经有了一份详细的项目规划，虽然看起来不太专业和靠谱，不过总比没有强。而且项目本身也不是很复杂，功能模块不多。

年轻而有活力的团队成员已经开始着手规划系统技术架构和数据库结构，每个人都准备借此机会大干一把，创造出一个鸡冻人心的产品。

但这个时候B遇到了一点比较郁闷的小挫折，精力旺盛的客户每天都会在很晚的时候上线来和他讨论应该起什么域名，域名一直没有确定，大家也知道现在好的域名太少了。拼音不行不够国际化，带数字的不行不够专业，太长了不行记忆成本太高，生造词不行容易流失新用户，太古板不行不像2.0。

域名问题折腾了B半个多月，买了许多个备用域名，终于确定了一个。有了域名该起网站名称了，起了网站名称就需要设计LOGO了。在用中文名还是英文名的问题上、LOGO和名片的设计上又折腾了很久。

科学的分工和任务并行规划并没有让这个小小挫折对整体项目进度造成太大影响。

但是产品端上的细节问题引发了越来越多的阵地战。比如积分机制，登录框的放置，首页第一屏的取舍之类的啦。客户对他所不了解的技术方面没有质疑，但是在他所有能理解能看见的地方有着极强的控制欲和偏执。

虽然大部分产品问题，客户最后还是听从了B的专业意见，但产品端迟迟不能定稿以及B作为项目经理角色在拉锯战上花费的精力已经对整体开发进度造成了延误。

产品端终于定稿，项目进入前端和程序的整合阶段，客户的精力转向去谈资源和市场。

一天，客户要求面谈某个重要的事情：“我新谈下来一批视频的独家资源，是来自***机构，有多么****，谈下来的难度有多****，我觉得放到我们现在的网站上很不错，好处有****，现在网站运营的不足有****，市场开拓难度有****，所以我们现在需要加一个视频频道。”

B开始觉得大事不好：“您想做成什么样的？”

客户说：“我觉得优酷那样的不错，能做成优酷那样的吗？”

……可行性的拉锯战……

……实现度拉锯战……

……工期的拉锯战……

……插入开发计划时间点的拉锯战……

B擦着汗说：“那费用呢，我们需要增加一点开发费用。”

客户：“当初你们开价的时候我可一点都没压价，我希望我们能抛开短视以项目为重，我们是准备长期合作的，你是我最重要的合作伙伴，我以后不会亏待你们，我现在的预算计划是****，我的初期投资准备花在*****，已经有人在给我投资****，谈妥后给你们的投入是****  …………。”

B妥协了。

于是恶梦开始了。

客户开始不断要求增加新的功能点或频道，以配合他手里掌握的资源和不断拓展的市场需求。

上线时间延迟；客户对进度持续施加压力；团队成员疲惫、挫败、不满；系统架构严重偏离初期设计，临时性处理和补丁越来越多，进度和质量控制体系全面进入混乱阶段。

B开始在需求问题上急刹车，对客户强硬。客户不满情绪积累，定下项目上线的deathline。

正常的BUG调试阶段从最初计划的1个月被压缩到1周。内测版就像一艘四处漏水的大船，团队成员在长期的连续加班中疲惫和抵触，客户看到内测版大发雷霆。

又经历了痛苦的2个月，项目终于上线可用。

残酷的结局：

• B和团队成员经历了痛苦的大半年，付出的工作量远远大于所得到的报酬。
• 客户宣传自己掌握的资源并没有到位，许多功能和频道闲置后又暂时隐藏。
• 客户请来另一个的技术顾问对系统架构大加指责，合作彻底破裂。
• 项目上线后半年不到，客户废弃了这个项目，转向另一个自己感兴趣有资源的领域。
• 精心的付出和最初产品理想的破灭，以及B的数次失误，导致B在这个项目失败后失去了一部分团队成员。

《如何逃离垃圾客户（下）》

故事3   朋友介绍的好机会

故事4  大客户的诱惑

推荐一篇文章 《经济学家如何排队》，还有一篇 《从经济学里的排队问题看效率与公平的矛盾》。

我随便说两句，如何给工作任务队列排序。

任务队列有几个排序原则：1 优先级 、2 重要性 、3 利润 、4 稳定 、5 取悦客户（老板）、6……

依照不同的排序原则会产生不同的排序结果。

在处理不同类型事务和担任不同角色时需要参考不同的排序原则。

• 比如bug任务列表，依据应该是重要性。
• 比如任务分工排序，依据应该是优先级。
• 比如整体改版计划，依据应该是稳定和利润。
• 如果你是那某几个倒霉的部门经理，依据中别忘了取悦客户（老板）（用户）（投资人）列表无限中……

项目工程中，很多人搞不清优先级和重要性这两个衡量指标的区别。所以任务列表中这两列经常被混用。其实这不是由于他不够专业造成的，而是取决于他的立场，他是项目经理还是系统架构师，他是干开发的还是干测试的，他是IT部门还是市场部门。

转一个分级指标的范例：

以处理问题的优先等级来分类

优先级 (Priority)	预计完成时间预设值 (Estimated Finish Date)	应变措施 (Resolution)
1	即日完成	立即修改完成 (Fix immediately)
2	三个工作天内	下一个阶段结束前必须修改完成 (Fix before next stage)
3	七个工作天内	产品推出前必须修改完成 (Fix before release)
4	十四个工作天内	如果时间允许才进行修改 (Fix if available)
5	本月内	在下一个版本再修改 (Fix in next version)

以问题的严重性来分类

严重性 (Severity)	指标描述 (Guidelines)	范例 (Examples)
高 (High)	缺少主要功能，或者主要功能毫无作用 所产生的问题会导致系统停顿 所产生的问题导致无法进行下一步测试	GPF (General Protection Fault)、Crash、当机 (System Hang)需要重新启动来解决的问题
中 (Medium)	主要功能运作不完整 所产生的问题会导致系统部份功能不正常 所产生的问题宿因严重但不影响下一步测试	Access Violation、Exceptions问题多数出于所有测试路径中的其中一个
低 (Low)	功能运作正常，但会有一些不一致的情况产生 所产生的问题不会导致系统任何问题 所产生的问题不会影响下一步测试	使用的介面或者接口不一致或者不正确
微 (Minor)	功能运作正常，可是有改进的空间 所产生的问题不会导致系统任何问题 所产生的问题不影响下一步测试	并未完全符合使用者习惯或者方便使用者

由这两张表格可见，优先级是在描述时间，影响的是进度，而 严重性 (Severity) 是在描述质量，影响的是稳定和架构。

我贴出这两张表的原因是 我要说的原则1：别想排出一个面面俱到所有人都满意的任务序列。排序列的时候牢记你的职位、分工和立场。

下面的问题就由于是我的原则，涉及我的角色和立场——外包技术服务项目的项目经理。 

原则2 会对他人造成影响的排在最前面。  造成影响包括：

• 会产生报怨的任务。有些角色的报怨会产生严重的负面影响和压力。为团队和长远着想，优先把报怨解决在说出来之前，及时无法及时解决，展现一个姿态。
• 前置任务。如果某个任务的完成成为其它任务开展的前提条件，提前干完它。（项目经理的主要前置任务基本是是。。写邮件）

 原则3 把容易看到成效的任务优先级提前。  包括：

• 快要完成的任务——“这座楼改完啦”的成就感 乘10倍 远远大于  “这个10座楼的小区改完啦”
• 同类未开展类任务中容易完成的——所以项目在进入密集开发的几个月后，技术人员会进入一个“干疲了”的状态，表现为开发效率下降，bug率提高，对优化和全局考虑的积极性下降。原因之一来自技术人员乐观天性导致的挫败感：需要干的事的数量、难度、复杂程序永远远远超出最初的想象。所以，优先开展容易完成的任务。
• 能实现收益回报的——优先搞点收益回报会令你在以后调配资源更得心应手。

原则4： 见这篇专业文章。《CARVER-教你进行项目的优先级处理》

 WEB开发技术发展到现在已经有了越来越细化的分工，从90年代末，一个懂html代码的人就能写一个站，到现在，内容、架构、UI、前端、程序、UE、分析监测、SEO、推广 都有了独立而成熟的角色分工。随着网站规模的增大、开发技术和标准的发展、运营过程中各类门槛性、专业性问题的解决需求增加，有一些新工种衍生出来，它们包括：内容设计师、架构设计师、前端技术工程师、网站分析师。这些基本是前端和内容部分的，技术部分的我就不敢说了。

内容设计师（网站策划）和UE：

把内容设计和UE放在一起说是因为我认为UE应该做为是一种观念来对待，是应该贯彻到包括内容设计、流程设计、用户界面设计和前端技术等开发环节中的一种意识。

除了电子商务或者专门的应用服务类网站（比如SNS），大部分网站项目并不需要单独的UE设计师，建议聘请可用性顾问来做培训，指导参与用户调研设计、可用性测试及分析交互模型设计等，并在开发过程中中分阶段跟进，对设计产品做UE评测。

这点上，我同意一叶千鸟说的：“把职责分散给内容与UI设计师和PM，而不建议由专职UE团队来把控产品质量，第一责任太大，第二职权失衡，第三增加管理成本，第四降低工作效率。”每个人都贯彻UCD来共同完成UE的工作，比把事情都交给用户体验工程师去做要有效得多。

内容设计是UI、 UE工作的上一环节，清晰明确的结构内容规划直接影响网站所有前端层面的开发方向与规范。以前这块工作多是由内容编辑人员或页面设计师来做，在近两年内，网站策划这一工种慢慢独立，多数是从这编辑、设计、营销人员或者互联网行业分析师中转型出来。

很多项目中，PM在做着其中的一部分内容设计的工作，比如负责沟通，采集需求，确定网站的内容结构、风格、栏目、功能，制定网站策划书。但是一但到达中型规模的网站项目，必定需要大量详细的描述型和图形化文档来需要规范相关环节的工作。帮助开发成员将需求分析结果更加明确化，实现文本备忘。

内容设计师应做的：
1.   明确的用户需求，进行用户需求调研，设计调查问卷或组织讨论。撰写《用户需求分析报告》。
2.   进行市场调研，清晰的分析相似网站的性能和运行情况。撰写相关《市场调研文档》或《同类竞争对手分析文档》。
3.   协调PM，组织相关开发人员与用户一起进行需求分析，根据讨论结果撰写《网站功能描述文档》，描述文档中的相关部分可组织核心设计和程序共同编写。
4.   根据项目需求和功能描述，生成高度结构化的文档，并形成线框图（页面结构图）。
5.   根据网站功能需求，配合UE顾问/工程师设计用户交互模型，生成用户任务的流程图。
6.  结合项目需求，制定可用性改善目标，制定可用性基准。配合UE顾问/工程师，在用户界面草图阶段，组织用户做一次可用性评估。同UE顾问共同撰写并分析评估报告。制定改善方案。 

写完一大溜内容设计师应该做的，就会发现这个工作主要做的是协调和文档性工作，并不一定要求设计师去多懂设计、懂技术模块、懂交互、懂可用性。但是一个合格的内容设计师，必须对这些相关的配合工种有所了解，并具备协同工作的能力。

许多网站中这部分工作都是由PM来做，或者由PM将工作拆散交给相关人员去做。PM应该做的工作是担负与产品项目相关的项目管理职责，负责分工、联络、协调和驱动。控制进度、梳理各类分歧、监控项目质量。从策略高度对产品的长期发展战略提出建设性意见，

PM是公司决策层与项目团队之间的桥梁，而不应该埋头于各类文档，将桥梁延伸到更具体的内容设计中。

一个人参与到整个产品的支持是不合理的，让专业的人做专业的事。

内容设计师相当于PM、设计、前端、架构、开发、和UE之间的汇聚点。在需求制定和内容决策期，组织各个部门留下清晰规范的指导性和备案性文档。在聘请外部顾问的时候，尤其充当了做对定制化部分做需求描述与补充的重要角色，也就是自身需求与外部专业指导之间的桥梁。

各类文档中，有很多部分需要相关技术人员去共同撰写，内容设计师落实不了，没有细化的文档很快会被束之高阁。千万不要把文档都丢给一个人，大家脚翘在桌子上张张嘴开开会就算了。

很快又有人会说到内容设计师的控制权问题。争论谁拥有对设计或内容的控制权是一个非常无聊的话题。如果你有足够的说服力。决定交给对项目/产品负责的人去做。