项目竞标

前几天一直在忙着一个项目的竞标。天天晚上10点以后。累死！

今天抽空做个小总结。

 

1. 跟客户聊需求的时候别指望客户能给你提供任何技术上的信息。 比如某个业务中，数据库的大概字段等。 客户只知道他现在的工作流程是什么样的，然后他大概对新系统有一个什么样的预期。 除此之外，一概不能提供。你所能做的就是尽量去理解他的现有工作流程，然后自己去设计新的系统

 

2.原型阶段要分清主次。

   计划用半个月时间来做竞标的原型。 原先想的挺好，设计出后台大概的数据库，然后前台用ASP.NET实现。不一定要多完善，但要能运行。

   可做起来发现不是那么回事，单是通过客户的需求设计出数据库就很费劲。因为那么短的时间内要想完全弄懂客户需求都很困难。再说前台实现，那更是有些力不从心。

  后来还是一个比较有经验的售前经理给订了基调：原型和Demo还不太一样。 Demo阶段能列出意思就成，不要求特别细致。否则等做出原型，黄花菜也凉了。

  最后实施，在纸上讨论出后台大概的表结构（主要是字段名称），然后在纸上确定出每个画面上的元素，然后开发相应的静态HTML页面。 中间用Excel作一些模拟的柱状图等，作报表结果。 实施起来的难度一下子降低了很多。

这里强调两点，一是“在纸上”，而是“确定”； 第一个可以很快，节省时间。 第二个可以让你深入的思考一些细节，然后实施的时候就不用再边想边做。 也能提高效率

 

3. 一定要明确任务

Demo阶段原先估计可能要出7,8个页面，后来觉得不一定够，可能要十几个，后来最终确定的时候其实要有23个页面。 比原先估计的工作量多了三倍。 所以，做Demo的时候，别以为简单就不去明确。 一定要白纸黑字的列出来，到底需要几个画面，每个画面是做什么的。绝对不要想当然，大概是？ 我觉得？ 甭觉得，您一般觉不出来。

 

4.竞标阶段不要犯方向性的错误。

因为招标方一般都不是一个部门，至少有财务，人事，运营，后勤，IT支持等。 竞标的时候就要做到心中有数，就是招标的时候谁说了算，千万不要犯方向性的错误。

很遗憾，我们这个Demo就犯了方向性的错误。由于公司认识一个运营部的经理，所以对运营部的业务了解的很细致。做出的Demo也很不错。可后来换个IT部分的人一看，告诉我们三点： 1，我们肯定做了他们公司运营部门的工作 2，公司对新系统期望最大的是财务，而不是运营 3, 真正招标时，运营经理可能不会参加。

 

郁闷至极，原先我们打的算盘是： 竞标的时候告诉对方，我们有能力做整个系统，但先阶段暂时拿运营这一块来举例。 看来，这举例也不是瞎举的啊。 当初为啥不拿财务系统来举例呢。

 

gf刚好是负责投标招标的，告诉偶些东东： 招标的时候，一般去几个人，但核心表态的一般也就两三个人，一人管钱（预算），一人管技术（硬指标），最多可能再出来一个大Boss，否则可能就是这两个人说了算了。 所以一定要搞清楚，你这个东西是做给谁看的。 不要乱做。 其他的人都是充场面的。

 

而且，上不上一个系统，有时候不是你背后做了“功课”就成的，还要自己确实有些本事。因为对那些人来说，自己在公司的地位才是最重要的。要是他选了你，你却整的一塌糊涂，给他再多好处他也不敢用你。

 

一语惊醒梦中人啊！

郁闷的重新设计Demo中

 

4. 最后不得不对公司的一个部门经理佩服一下。

他在一开始就比较怀疑我们认识的那么部门经理在招标中的分量，而且担心我们可能会犯方向性的错误。但由于我们对财务那块需求不明朗，所以没办法，他也不反对我们继续按运营的思路出Demo。 可我自己当时根本没觉出来这是个问题。

看来阅历这东西，真重要啊。 平时看不出来，关键时候一两句话，那可能就关系成败啊。这可能也就是为什么有些东西是速成不来的原因吧。

他不会技术，但这点我很佩服他。

搞技术的，看来真不能“唯技术论英雄”啊！

 

2009/04/17 号更新内容

今天又把Demo的内容修改了下，涵盖了更多的东东，主要包括了财务的东西，而且展示了更多的报表。

算了下，所有的页面加在一块大概有65个之多，远远多于刚开始设想的十几个。

所以啊，工作量到底有多少，一定要白纸黑字的写清楚啊。

 

PS:以后写静态画面，重复的部分一定要提出公共的Frame，然后嵌套FrameSet使用。否则，想想吧，画面左边如果有导航栏的话，需要每个画面都拷贝一份导航栏的Html代码。将近70个画面啊。 每个拷贝一下，以30秒搞定一个为例。 需要半个多小时。 如果这个导航条再稍微更改一下，又半个小时。 如果再稍微更改下，又半个小时。噩梦啊！

 

不过当所有的样式什么的定后，做一个静态页面还是挺快的。 差不多20多分钟就一个。偶昨天从下午到晚上就画了16个。今天不到一个半小时又画了5个！