m***h
发帖数: 77 | 1 今天看到国内前淘宝的工程师讲1230的复杂度，
瞎想一下（结构一旦搭好，很难改变），
技术(tech stack, architecture)决定于需求(requirements)，
而“所谓”的需求受制于个别人的背景，视野，以及对用户，产品，市场的理解，尤其
是局限于人为分割来的两个截然不同的group，造成business side只懂得比猫画虎，
technology side则醉心于技术喜欢拿着hammer找nail，而用户呢，分不清想要的和需
要的。
user说他想要一张火车票，他说他要20号广州到贵阳的票,
其实他真正想要的是回家（但他不会这么告所你.
20号没有，21，22也可以“接受”，是在不行站票也可以！（这个场景在火车站售票窗
口循环上演,decision making in 20 seconds）.
铁路春运票务系统首要gurantee的是保证你回家，保证每个人都不费力的得到一张回家
的票，至于20，21还是22是次要的
这和淘宝双十恰恰是相反的－淘宝的用户要的是那个exact deal,如果买不到也无所谓。
所以用淘宝或online store的思路做春运票务，可以，但费钱费力还不讨好.
春运的核心其实更多象travel planning而不是ticket sale.
如果用户承认他们的flexibility,铁路则可以保证a ticket（运力不是问题).
这有点象Cassandra这堆no-sql vs oracle/mysql,不同的use case，不同的guarantee.
春运还有它自己的特点和优势（对铁落而言).
大多数人提前就知道自己假期和preferred dates.
real time不是priority,铁路没有竞争对手.
假设每个用户填写3个dates(preferred date,acceptable dates)和多个可接受车次，
而系统guarantee 在2/3/4小时内assign座位票，是不是better user experience?
前台基本上是static,只显示运行车次，用户填写plan,submit.然后用证件号查询
ticketing result。后台就是一堆机器算了。（一个好处是可以对用户patten 有个很
好的了解甚至基于它计算增加临时车次）
当然怎么安排整个大系统要复杂的多，譬如车站还得是realtime，象所有“大系统”一
样，真正起决定所用的还是在Sr Executive以上譬如Jobs.
－－－－－
上面还是有sales系统的味道，既然定义这个系统的目的是保证整体的效益，保证每人
都有票，走ticket allocation的方向。这样需要在春运开始之前规定几天专门用来让
用户提交ticket plan。一旦过了cutoff date，就开始计算和出票（系统switch回正常
sales模式）。这样可能能解决大部分人的需求。以后只有当日和三日以内可以购票。
当然那些没有得到第一选择的人可能试图再买和退票，不过traffic应该少得多了。 |
w*********m
发帖数: 4740 | 2 要想解决这个，那就是个复杂的优化问题，从建铁路，规划车次，到按权重分配车票，
以及博弈论，都要一层层考虑到
可以考虑申请个5年的nsf founding
【在 m***h 的大作中提到】
: 今天看到国内前淘宝的工程师讲1230的复杂度，
: 瞎想一下（结构一旦搭好，很难改变），
: 技术(tech stack, architecture)决定于需求(requirements)，
: 而“所谓”的需求受制于个别人的背景，视野，以及对用户，产品，市场的理解，尤其
: 是局限于人为分割来的两个截然不同的group，造成business side只懂得比猫画虎，
: technology side则醉心于技术喜欢拿着hammer找nail，而用户呢，分不清想要的和需
: 要的。
: user说他想要一张火车票，他说他要20号广州到贵阳的票,
: 其实他真正想要的是回家（但他不会这么告所你.
: 20号没有，21，22也可以“接受”，是在不行站票也可以！（这个场景在火车站售票窗
|
e*****r
发帖数: 700 | 3 有一点不理解。为什么不可以提前订票？
欧洲之星如果提前几天订的话，是很贵的，自然让一些对价格敏感的人提前很久订票。
这样也自然分流了订票的流量。 |
b*******s
发帖数: 5216 | 4 归根结底还是铁道部业务流程傻b
【在 e*****r 的大作中提到】
: 有一点不理解。为什么不可以提前订票？
: 欧洲之星如果提前几天订的话，是很贵的，自然让一些对价格敏感的人提前很久订票。
: 这样也自然分流了订票的流量。
|
x****d
发帖数: 1766 | 5 错，归根结底是春运坐火车的都是ds，人家zf不care
【在 b*******s 的大作中提到】
: 归根结底还是铁道部业务流程傻b
|
k********e
发帖数: 702 | |
s********r
发帖数: 923 | |
m********s
发帖数: 55301 | 8 你比虫虫强太多了。
对，你对春运的认识是正确的。
【在 m***h 的大作中提到】
: 今天看到国内前淘宝的工程师讲1230的复杂度，
: 瞎想一下（结构一旦搭好，很难改变），
: 技术(tech stack, architecture)决定于需求(requirements)，
: 而“所谓”的需求受制于个别人的背景，视野，以及对用户，产品，市场的理解，尤其
: 是局限于人为分割来的两个截然不同的group，造成business side只懂得比猫画虎，
: technology side则醉心于技术喜欢拿着hammer找nail，而用户呢，分不清想要的和需
: 要的。
: user说他想要一张火车票，他说他要20号广州到贵阳的票,
: 其实他真正想要的是回家（但他不会这么告所你.
: 20号没有，21，22也可以“接受”，是在不行站票也可以！（这个场景在火车站售票窗
|
m********s
发帖数: 55301 | 9 但你忘了，春运就是僧多肉少。
你有机会大年二十六走，决不轻易把时间改成二十七，更不会挪到二十八。
这就是问题所在。
【在 m***h 的大作中提到】
: 今天看到国内前淘宝的工程师讲1230的复杂度，
: 瞎想一下（结构一旦搭好，很难改变），
: 技术(tech stack, architecture)决定于需求(requirements)，
: 而“所谓”的需求受制于个别人的背景，视野，以及对用户，产品，市场的理解，尤其
: 是局限于人为分割来的两个截然不同的group，造成business side只懂得比猫画虎，
: technology side则醉心于技术喜欢拿着hammer找nail，而用户呢，分不清想要的和需
: 要的。
: user说他想要一张火车票，他说他要20号广州到贵阳的票,
: 其实他真正想要的是回家（但他不会这么告所你.
: 20号没有，21，22也可以“接受”，是在不行站票也可以！（这个场景在火车站售票窗
|
z****e
发帖数: 54598 | 10 然
老魏死活认识不清楚
我早就说过了，一个是legacy system就可以让它整套方案作废
不知道在讨论个什么劲
前提假设一堆的破绽
【在 m********s 的大作中提到】
: 但你忘了，春运就是僧多肉少。
: 你有机会大年二十六走，决不轻易把时间改成二十七，更不会挪到二十八。
: 这就是问题所在。
|
z****e
发帖数: 54598 | 11 没用
运力不解决，提前10年都只会让10年内所有的票都被抢光
如果你提前10年就知道你这10年都回不了家的话
你会有起义的冲动
【在 w*********m 的大作中提到】
: 要想解决这个，那就是个复杂的优化问题，从建铁路，规划车次，到按权重分配车票，
: 以及博弈论，都要一层层考虑到
: 可以考虑申请个5年的nsf founding
|
m********8
发帖数: 7463 | 12 搞笑
用提前时间量增加不确定性
导致需求减少。这个不但可以减少技术瓶颈，甚至可以增加废票率，可以让多赚钱。
【在 z****e 的大作中提到】
: 没用
: 运力不解决，提前10年都只会让10年内所有的票都被抢光
: 如果你提前10年就知道你这10年都回不了家的话
: 你会有起义的冲动
|
G*****n
发帖数: 3863 | 13 首先，可以让谁多赚钱？怎么一句话掉了宾语？
其次，增加废票率，说明运力没有利用好。有一张废票，就有另一个本来可以回家的人
买不到票。这个系统本来困难就在于让尽量多的人更容易买到票回家。大家都在讨论这
个目标，你突然开始扯某个不知道谁（因为你把它掉了）赚不赚钱。这不是胡扯么。
【在 m********8 的大作中提到】
: 搞笑
: 用提前时间量增加不确定性
: 导致需求减少。这个不但可以减少技术瓶颈，甚至可以增加废票率，可以让多赚钱。
|
