百度天天低价得出（edlp, everyday low price）：这是美国零售头沃尔玛率先提出来的促销口号，现已广泛被各商家和电商平台使用。它是指折扣零售业者（例如综合超市）所采取的价格策略，亦即每天都保持较低的价格及毛利来运作，目的要吸引大量客流前来消费。
低价感觉不错
涉及的天天低价项目，旨在让供应商积极参与进来，如果供应商愿意把一批商品降到一定幅度，前端会承诺提供较好的坑位，有最少流量保证，有流量加上有低价好货商品，性价比高的好商品自然会卖得比较好。
那么，最重要的是，做这个项目到底学到了什么？我习惯从记忆中严重的问题入手，分析原因，不重复犯错，让自己成长。
第一，数据实时性展示，关注从调价到前端生效的全流程，从调价到前端展示需要多少时间，很多人都想看到效果，或者至少会有预期。系统交互分为同步调接口，异步消息监听，通过大数据小时表或者天表交互。哪些需要实时，可以实时，不实时能够接受的延迟是小时级还是天级。通过大数据表对大数据系统有依赖，多一个系统，脆弱性就会增加。这次从属性输出，到供应商告知，到商品池门槛计算，到前端展示，几乎每个过程要时间处理，异步消息队列（全量队列和增量对列）或HIVE（天表或小时表），数据计算，前端定时投放等都需要时间。一开始就要给业务方明确预期，这事情不可能很快就搞定，分钟级别都不太可能，有些时延正常得很。
第二，业务需求多变，快速跑起来是第一目标，一开始想清楚还是很重要的。需求、设计、开发、测试、运营都是如此，要保持一定的灵活性，比如动态业务规则，文案配置，黑白名单配置。比如什么时候扶植，扶植多少天，哪些类目需要扶植，哪些场景需要，每个场景具体的扶持策略是什么，与现有其他部门的扶持策略是否一致，扶植是人工提报排期还是自动捞取，在哪些地方扶植，都需要整体考虑。可以搞迭代优化，但互联网的快节奏让人实在等不及，但把项目尽快搞上线，快速运营，遇到问题持续优化都是需要考虑的。在挫折中学习，在冲突中成长，不断同业务方沟通，提前同步业务方风险，保持沟通，这是最重要的。
第三，该有的流程还是要有，期望各侧的需求。需求串讲，技术评审，上线评审，定期沟通，这都是必要的。本次后期出现的问题之一是联调时发现两个不同上游系统调用底层系统服务接口不同，包括SPU纬度和SKU纬度，条码纬度的统计口径不同，对供应商和前端展示样式各不相同。一些系统需要大量计算的团队所需机器多，连预发布环境都没有，需要其它系统上线后才能联调，这也够坑的了；问题之二是居然有需求点未跟下游系统同步到位，这个时候主产品和项目经理就应该提前发现，哪些需求点上下游需要动到，看到全局，毕竟每个产品线的产品关注自身的需求比较多，容易漏掉一些点，一起对接就显得特别需要了，确保需求点理解一致，上下游一起评估上线，不然最后重新评估上线压力也是不小的；上线评审包括各系统上线的时间，历史数据清洗，特殊场景验收，对上下游系统的影响，新旧数据切换期间的灰度，对供应商和前端的影响，提前沟通和应急措施，对上线过程中可能存在风险近期不太稳定的依赖系统，也可以提前打招呼，凌晨打扰人总是不太好的，如果非打扰不可，我还是会打扰的。
第四，紧急时刻确实要多付出，明确责任，活跃在此时，其实是树立个人影响力的最高机会，信息同步，靠谱，责任心，大家团结在你周围的感觉很不错，一起奋斗的感觉我还是蛮喜欢的。但在所有微信群对接其实压力蛮大的，还是要明确下负责的范围，第一时间找谁，紧急的事情电话，毕竟微信不是所有人的全部，回答不实时也正常，一般产品有四五十个群都正常得很，都找她回复岂不是要崩溃。
第五，每个团队的风格不太一样，有些是听产品的，有些是经开发的，有些听架构的，比较靠谱的方式拉上产品开发负责人一起对齐，特别是产品技术方案跨系统的，没有通知到任何一方都会有问题，没一起约会就比较难得了，否则产品刚聊完，开发经理一个有问题，得再开一轮，这也是挺不容易的。其实拉个大微信群挺好的，一起会议对齐，共同商量解决问题。记住，任何事情都是有办法解决的，办法始终是比问题多的。当然，有时微信打再多字远远不如当面交流一下，群里面吵起来其实远没有口头沟通来得高效，也容易误解。记住，时刻记得各产品线谁比较靠谱，谁说了算，直接找开发可能会被闭掉，因为绕过了关键干系人，最后会有麻烦的。
PPT（人、流程、工具）是比较好的总结方式，基本软件研发都离不开人、流程、工具，靠谱的人，简单有效的流程，提升效率的工具，无疑都是回顾可以考虑的点。
网友评论