<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>

<channel>
	<title>资源收集BLOG</title>
	<atom:link href="http://blog.smartinfo.cn/index.php/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.smartinfo.cn</link>
	<description>主要转载一些好的技术文章,让我自己学习</description>
	<pubDate>Thu, 06 Aug 2009 00:35:37 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>台湾 桑河数位的 博客</title>
		<link>http://blog.smartinfo.cn/index.php/archives/166</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/166#comments</comments>
		<pubDate>Thu, 06 Aug 2009 00:35:37 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[界面设计]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=166</guid>
		<description><![CDATA[台湾一流的互动设计公司老板的博客,写的非常好,建议设计团队经常上去看看,或者可以就此引发内部讨论,供大家进步和学习: http://blog.shanger.net/  &#8220;我觉得，只要常上业界討论区，会主动和前辈討论问题，並且担心就业和专业能力並主动学习(或买书来看)，这样的大学生就算积极进取。&#8221; 你算是自我进取吗?
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/166/feed</wfw:commentRss>
		</item>
		<item>
		<title>在线绘图网站</title>
		<link>http://blog.smartinfo.cn/index.php/archives/164</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/164#comments</comments>
		<pubDate>Fri, 31 Jul 2009 00:13:32 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[优秀设计]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=164</guid>
		<description><![CDATA[在线绘图网站,以下都是在线绘图网站,技术基本都是采用FLASH FLEX等交互进行,创意非常好.国内的联想实验室也推出了类似的网站BEST4C.
http://www.gliffy.com/ 
http://www.flowchart.com/
 
http://www.imaginationcubed.com/
 
http://artpad.art.com/gallery/
http://offtype.net/painter.html 
http://www.sumopaint.com/web/ 
http://www.sumo.fi/products/sumopaint/index.php?id=0
 
http://www.izhuk.com/painter/
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/164/feed</wfw:commentRss>
		</item>
		<item>
		<title>产品经理的前世今生（职业规划）</title>
		<link>http://blog.smartinfo.cn/index.php/archives/147</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/147#comments</comments>
		<pubDate>Sat, 25 Apr 2009 05:58:40 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[乱七八糟]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=147</guid>
		<description><![CDATA[http://hi.baidu.com/myey8/blog/item/fe21e517a5e10001c83d6deb.html
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/147/feed</wfw:commentRss>
		</item>
		<item>
		<title>国外房地产网站设计趋势与欣赏</title>
		<link>http://blog.smartinfo.cn/index.php/archives/145</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/145#comments</comments>
		<pubDate>Sat, 25 Apr 2009 05:58:09 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[界面设计]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=145</guid>
		<description><![CDATA[http://oncoding.net/visual/color/article200904/137_2.html
而房地产网站是购房者了解房产信息的重要渠道，房地产网站的优劣几乎可以决定房产交易的成败。在这里，我们展示一些优秀的房地产网站设计，并介绍当今西方房地产网站的设计趋势。
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/145/feed</wfw:commentRss>
		</item>
		<item>
		<title>白色在网页设计中的使用：贴士和趋势</title>
		<link>http://blog.smartinfo.cn/index.php/archives/140</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/140#comments</comments>
		<pubDate>Sat, 25 Apr 2009 04:17:37 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[界面设计]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=140</guid>
		<description><![CDATA[http://www.yeeyan.com/articles/view/orangedan/38430
很大的国外好的文章翻译资料库,可以学习!
 
英文的,非常好的网站设计案例分析:
 
 
http://www.smashingmagazine.com/category/showcase/ 
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/140/feed</wfw:commentRss>
		</item>
		<item>
		<title>优秀网页设计的四项原则</title>
		<link>http://blog.smartinfo.cn/index.php/archives/138</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/138#comments</comments>
		<pubDate>Sat, 25 Apr 2009 04:09:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[界面设计]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=138</guid>
		<description><![CDATA[http://oncoding.net/interact/ideol/article200904/138.html 连接地址
很好的博客站点地址,里面讲了很多 关于交互和视觉设计的内容.
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/138/feed</wfw:commentRss>
		</item>
		<item>
		<title>如何逃离垃圾客(下)</title>
		<link>http://blog.smartinfo.cn/index.php/archives/135</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/135#comments</comments>
		<pubDate>Tue, 21 Apr 2009 10:07:42 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[乱七八糟]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=135</guid>
		<description><![CDATA[故事三：朋友介绍的好机会 
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在看不到头的时间线上 烦恼地进行着无尽的改造……
———-涕泪交加的分隔线———–

由朋友介绍来的项目，如果他并不参与项目并能起到决定性作用，要慎接。不然可能到头来生意和朋友都为难。

然后状况下都要明确合同、预付、任务明细。不然你会加速步入沼泽。关系不能代替承诺，约定不能代替协议。轻视游戏规则的代价就是失去规则的保护。

如果意识到合作方是垃圾客户，一定要不惜代价，立刻刹车，及时止损，不然你只会付出更多。

一般情况下，追加性支付的费用只是在增加你及时止损的代价。不能改善任何问题。

在开发项目中千万慎用开源代码，除非确定客户没啥定制化需求。特别要慎用多套开源代码的组合。我亲身经历过客户为了省钱省事，搞了套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，把它们都直接送进了垃圾邮件箱……
]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/135/feed</wfw:commentRss>
		</item>
		<item>
		<title>如何逃离垃圾客户(上)</title>
		<link>http://blog.smartinfo.cn/index.php/archives/133</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/133#comments</comments>
		<pubDate>Tue, 21 Apr 2009 10:06:37 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[乱七八糟]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=133</guid>
		<description><![CDATA[做项目做产品可以有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在这个项目失败后失去了一部分团队成员。

]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/133/feed</wfw:commentRss>
		</item>
		<item>
		<title>项目如何开始：怎样和客户一起搞定需求</title>
		<link>http://blog.smartinfo.cn/index.php/archives/130</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/130#comments</comments>
		<pubDate>Tue, 21 Apr 2009 09:58:52 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[网站策划]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=130</guid>
		<description><![CDATA[项目刚刚开始的时期，项目经理做的主要事情是搜集客户需求，这是一个项目经理非常头疼的阶段，合作的磨合刚刚开始，需求问题上的失误又会导致无穷的后患。
三种客户类型：
1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值疑问和担心。能快速回答你的问题。
2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。
3 啥都不懂。 不给文档。能给你几个参考范例（打开数个网站，告诉你我要做成和它们一样的。）只能等着你来问100个问题。。。 
四种合作方式：
1 创始人直接和你接洽：
交流结果的协商余地很大，需求不易反复，细节不会被过分追究。更容易统一想法，执行力高，你能对项目和产品产生更大的影响。但往往甲方会过于急进。
2 项目代表和你接洽：
这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表，负责汇总甲方的所有需求和标准和你沟通，他有过与外包方合作的经验，知道危险的环节所在，能承担翻译和桥梁的角色，帮助你阻挡和说服不恰当的需求。能集中地承担责任，也会积极地和你一起规避项目失败的风险。非常lucky！
3 专业部门和你接洽：
IT部门或技术部门的某个高级别工程师负责和你沟通，你们会比较有共同语言，甚至惺惺相惜。技术方面的合作会很顺利，但是涉及到产品和需求，他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后，很有可能在技术思路上产生分歧；如果在程序部分耽误了太多时间，而产品端被忽视，你有可能受到其它部门及上层的质疑。
4 市场部门（内容部门）和你接洽：
最好你先去烧烧香，准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后，切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事，写更多的文档，主动和专业部门联系，力争和决策层有沟通。
如果你面临了第3和第4种状况，
请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发：


需求 和 市场部门 沟通


功能 和 内容部门 沟通


软硬广告位或专题 等 和 销售部门 沟通（如果是改版类，广告位合同可能提前半年签订，一定要和销售协调好）


技术、系统、安全、统计问题等 和IT、网管、数据统计部门 沟通


某些问题 需要和 总裁助理、行政 等官僚部门沟通。


部分特别的内容 需要和 创意、美工、文案部门 沟通


当以后确定需求的时候，如果发现这些部门的人没有参与，请提前与之沟通。
第1和第2种状况可跳过上述步骤。
八步流程:
第一步：听听客户想要什么。
以及预计工期和预算（这两件事上一点都不要腼腆，这是关系项目成本最重要的元素）。
第二步：提问。
1 项目的目的是什么。（品牌、渠道、流量、广告费、用户数、VC、其它商业模式）
2 甲方的优势和资源是什么。(钱，内容资源，人力大战，传统行业优势)
3 尽量提供可视的参照及借鉴对象 。（应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象）
4 其它工程的细节问题。
比如（工期上的上下限是什么？
是否会需要与现有系统整合、是否需要数据迁移？是否会需要甲方的工程师合作？
是否有开发平台的限制？
是否有代码规范及标准？最终需要哪些开发文档和源码 ）
第三步：取得共识。
与甲方取得共识非常重要，保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲，画出草图或框架图。有参考对象的，标注上，哪个部分会比较像某某。
然后请甲方确认， 这个框架是他们想要的。
第四步：给出工程时间轴。
到了这一环节，就需要你的项目经理组织所有团队成员坐下来讨论，先划分功能模块，然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾 系统搭建和系统整合的所需时间。
项目经理对工程耗时和可行性完全心里有数后，画出工程的时间轴。包括并行状况，里程碑节点、测试期、缓冲期等（如何画工程时间轴，甘特图，我以后会专门写一篇）。时间轴要实事求是，并且预留好充分的缓冲期（工程师估时*2*110%）。
第五步：需求做减法。
大部分情况下，时间轴表现的状况都会超出客户的预期。如果客户对工期没有要求，也要提醒客户考虑 项目可行性风险、市场等候成本、市场或战略变化导致的浪费。
韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。
所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期，落实只开发最基础和最必要的一期需求。
这时签订正式开发协议。
不要忘了计算 需求文档和产品方案 的费用。
第六步：撰写详细的需求文档。
《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。
《流程图》》下载西乔的模版。理出产品的逻辑关系。
《功能需求文档》》下载西乔的模版。 罗列 功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的 基础文档。
第七步：商讨需求文档
尽量召集甲方所有相关部门的负责人 一起召开这次会议，商讨需求文档。
在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。
更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。
所以这次会议是一场耐心和体力的考研。
文档作者需要 分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。
安抚情绪。解答困惑。控制需求变动。
第八步：定稿需求文档
分职能（部门）类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。
所有会议中可能被提出但是未出现在此邮件文档中的 意见，不会列入需求文档中。当然允许可以书面反馈补充。
根据确认过的反馈回复，修改需求文档。直到需求文档定稿。
协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，搜集需求和文档定稿的 时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。
三种武器：
需求问卷：无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。
此时撰写一份需求问卷非常有效。
问卷里提出重要的全局性的问题，需要客户逐条书面回答。
某些问题可以提供多个选项答案，及补充区域。
某些问题 需要确凿的态度，Yes或NO。
不要提出需要客户写一大段表述性文字的问题。
需求问卷精简扼要，有针对性，重要，不要浪费客户的时间，不要把写字的工作量丢给客户。
书面确认：
书面确认 一方面包括 ：所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。
另一方面包括：你要尽量提供书面的可视化的东西 来让甲方确认。
甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。
邮件抄送：
邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。
尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。
结语：
到此看起来，搜集和确定需求真是一件耗时耗力的工程。
其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 [...]]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/130/feed</wfw:commentRss>
		</item>
		<item>
		<title>用 JMeter 完成常用的压力测试</title>
		<link>http://blog.smartinfo.cn/index.php/archives/126</link>
		<comments>http://blog.smartinfo.cn/index.php/archives/126#comments</comments>
		<pubDate>Mon, 20 Apr 2009 08:54:41 +0000</pubDate>
		<dc:creator>admin</dc:creator>
		
		<category><![CDATA[服务器技术]]></category>

		<guid isPermaLink="false">http://blog.smartinfo.cn/?p=126</guid>
		<description><![CDATA[本文介绍了 JMeter 相关的基本概念。并以 JMeter 为例，介绍了使用它来完成最常用的三种类型服务器，即 Web 服务器、数据库服务器和消息中间件，压力测试的方法、步骤以及注意事项。
讲到测试，人们脑海中首先浮现的就是针对软件正确性的测试，即常说的功能测试。但是软件仅仅只是功能正确是不够的。在实际开发中，还有其它的非功能因素也起着决定性的因素，例如软件的响应速度。影响软件响应速度的因素有很多，有些是因为算法不够高效；还有些可能受用户并发数的影响。
在众多类型的软件测试中，压力测试正是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户的访问时，软件的抗压能力。本文以 JMeter 为例，介绍了如何使用它来完成常用的压力测试：Web 测试、数据库测试和 JMS 测试。
概述
JMeter 最早是为了测试 Tomcat 的前身 JServ 的执行效率而诞生的。到目前为止，它的最新版本是2.1.1，它的测试能力也不再仅仅只局限于对于Web服务器的测试，而是涵盖了数据库、JMS、Web Service、LDAP等多种对象的测试能力。在最新的 2.1.1 中，它还提供了对于 JUNIT 的测试。
JMeter 的安装非常简单，从官方网站上下载，解压之后即可使用。运行命令在%JMETER_HOME%/bin 下，对于 Windows 用户来说，命令是 jmeter.bat。运行前请检查JMeter 的文档，查看是否具备相关的运行条件。对于最新版（即2.1.1），需要JDK的版本要求是JDK 1.4。
JMeter 的主要测试组件总结如下：
1. 测试计划是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。
2. 线程组代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。
3. 监听器负责收集测试结果，同时也被告知了结果显示的方式。
4. 逻辑控制器可以自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
5. 断言可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
6. 配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
7. 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。
8. 定时器负责定义请求之间的延迟间隔。
JMeter的使用非常的容易，在 ONJava.com 上的文章 Using JMeter 提供了一个非常好的入门。
















回页首







常用测试
压力测试不同于功能测试，软件的正确性并不是它的测试重点。它所看重的是软件的执行效率，尤其是短时间内访问用户数爆炸性增长时软件的响应速度，压力测试往往是在功能测试之后进行的。在实际的开发过程中，软件潜在的效率瓶颈一般都是那些可能有多个用户同时访问的节点。
就目前 Java EE 的平台下开发的软件来说，这种节点通常可能是：Web 服务器、数据库服务器和 JMS 服务器。它们都是请求主要发生的地点，请求频率较其它的节点要高，而且处于请求序列的关键路径之上。如果它们效率无法提高的话，对于整个软件的效率有致命的影响。而且在这些节点上一般都会发生较大规模的数据交换，有时其中还包含有业务逻辑处理，它们正是在进行压力测试时首先需要考虑的。
本文以这三种节点为例，介绍如何使用 JMeter 来完成针对于它们的压力测试。
Web [...]]]></description>
		<wfw:commentRss>http://blog.smartinfo.cn/index.php/archives/126/feed</wfw:commentRss>
		</item>
	</channel>
</rss>
