Paw Robot小试牛刀,却未见庖丁解牛(三)

    说的这么热闹,好像这次合作要谈成。那为什么是“未见庖丁解牛”呢?有标题可见,Paw Robot应该是没有被K公司所接受呀

    结果的确是这样,在今日上午10时许,K公司的人员正式通知我们,本次将不选取我们的方案,以及相关产品,还很有礼貌的附加一句,等下次有合适的机会,再谈。

   为什么会出现这种结果?我们的谈判技巧不够,还是K公司里认为我们就是不靠谱。在会谈中,有两处也许是我们做得不好的地方。

    其一,在与K公司第二次会晤是,K公司多次问及,我们能抓取哪些站点时,我们没有很好的从正面回答,我们的回答是,CCTV和各个卫视都没问题。当时我们是这样考虑的。不管各个站点发布的视频是什么格式,无论是*.mp4、*.flv、*.3gp等等,我们的抓取策略是从传输协议着手,这些千奇百怪的视频格式,最终会落在HTTP、RTMP、RTMPE三类传输协议上。Paw Robot就可将这些协议装有的视频节目还原出来。

   很遗憾,K公司的人员可能看到我们连媒体格式的后缀名,都背不全,心中暗想:别不是水货吧!可是我们没有意识到这点,还是大谈特谈 HTTP、RTMP。虽然事实上是:拿住了协议的内容的反响解析,就能轻松的还原各种视频文件,但是K公司的人员却不看重这一点。我再罗嗦一句,国内各个大小视频站点(P2P除外),前台技术千奇百怪,我不多说,后台服务器发布视频,采用的协议策略:HTTP,占99.998%,RTMP,占0.001%(我只见CCTV《百家讲坛》的某几期节目,以此发布),RTMPE,占0.001%(我只见sohu的独家美剧,以此发布)

   K公司一定要我们列出可以抓取节目的清单,最后我们去了一封email,列了六百多个节目的清单。请注意是600多个节目,节目可不是电影,电影,一部了事。节目有可能天天都有,像新闻类的节目,一年365天,做个乘法,节目量是巨大的。

   其二,我们这注重后台抓取,没注意前台界面。当时K公司提出,最终产品是否能查询?当时我们想,Paw Robot就是按照母站点个各个节目清单,按照日期,逐个建立文件夹,并将其存盘。这就已经是天然有序了,还花功夫,做这种重复开发,何意?

    用户的心里一定是要搞清楚的。这是我们的一点教训吧。我们能做得比上一家好,K公司认为是应该的。但是上一家有的功能,无论是否有用,若我们没实现,对不起,那就是不足的表现。

    K公司也许是考虑了这些,Paw Robot也就没有被采用。

    一些遗憾,只能蓄积力量,再战!

你可能感兴趣的:(robot)