@产品项目 领导 知识体系服务工程师

项目复盘:缘起NLP

2019-10-07  本文已影响0人  wlp2evan
神经语言程序学

NLP(Neuro Linguistic Programming,身心、语法、程序等)语义分析目前在大数据领域炙手可热的话题之一。任何对语言的理解都可以归为语义分析的范畴。一段文本通常由词、句子和段落来构成,根据理解对象的语言单位不同, 语义分析又可进一步分解为词汇级语义分析、句子级语义分析以及篇章级语义分析。语义分析目标就是通过建立有效的模型和系统, 实现在各个语言单位的自动语义分析,从而实现理解整个文本表达的真实语义。

最近做的项目需要通过NLP分析用户评论,根据用户评论确定是否商品有质量问题,进而确认是哪类质量问题,更进一步给这条评价打上标签。项目时间比较紧张,甚至项目的进度安排受到质疑,项目节奏一旦确认,强力推进,这本是我的工作范畴。但我实在低估了NLP从模型化到准确率提升难度其实挺大。随着项目进行,风险也在逐步加大,但项目目标经过滚动式规划越来越清晰。从外包团队标记语料,到模型搭建优化,到归类,到BAD CASES分析处理,到关键词规则全套汇总,一环扣一环。数据源有两种,一种是真实用户记录的,一种是内部人员记录的。不确定性在于技术认为这两种数据源可以使用同一套数据模型解析。做的过程中才发现这两个数据源不能通过一种模型实现解析,于是技术就用了四个模型。此时,应该采用原型法介入了。

中期项目风险确实比较大,项目中期产品技术与业务方进行了一次深入沟通,就项目目标再次重申,明确两种数据类型需要分开处理,准确率目标也不尽相同。本期上线目标是系统流程打通,同时保证一种数据源成功率,确保大分类数据准确,二级分类可以分迭代执行,当然这个与业务方期望一致。这样的迭代升级计划是项目组是需要制订的,不能光说不能搞定,还得有接下来搞定的计划怎样,这才是一种正确的做法。

接入NLP分析,细化工作任务。在前期准确率不能提升的情况下,怎样验收,模拟现有人工操作让流程跑起来同样重要。有时候开发说很快其实是个伪命题,做过程序员的朋友都应该知道一个话题,等我几分钟甚至十分钟,恐怕一两个小时都没有了,项目经理对程序员的“快速承诺”往往会比较谨慎,可以输出需要做哪些事情,需要哪些外部输入和内部数据准备,临时抱佛脚其实是比较惨的。这也是项目经理需要留意的地方,可能你面对的是开发负责人,而开发负责人不是最终的执行开发人员,这中间的沟通断层有时候会出问题,沟通讨论具体执行计划,与实际对接人沟通显得尤为重要。

下游系统的对接,接口之间要明确,技术负责人需要仔细评审,项目经理可以抽查,尤其是可能出问题系统之间的交互,从产品技术测试的角度全面出击,确保上下游数据对接好,核心流程经历过开发联调、测试联调等,回归保证现有流程不受到影响。

安全评审、用例评审、上线评审、发布时间都还是要对齐,上线后验收用例也可安排评审,第一时间留下产品经理,和研发团队一起验收,这非常重要。每个人手头上有很多事情,项目经理就是他们的指示牌,你最了解这个项目的整体计划和时间紧迫性,而他们则有自己的需求和事情优先级,提早进行规划,确保大家全力支撑,做到心往一处想和劲往一处使。

跨地区和跨团队本来就是沟通中的难题,该沟通一定要第一时间沟通,确保双方理解一致,充分利用现代高科技,双方理解一致,深入沟通,而不是“我以为”,这在后期就是借口了。有风险也不必第一时间通过领导传递出去,你有自己的思想,有自己的计划,这个层级全方位考虑已显得特别重要,不然也挺难更进一步的。

当然,知道各个团队需求列表,项目资源的情况,了解到关键路径上的排期,整个节奏按这个对齐,同时跟开发负责人协调资源,其实都是要努力争取的。对于一些申请的特别临时资源,要关注风险,确保长期关注,周计划要明确,每日重点要第一时间关注,对于自管理团队也要看其成熟度,磨合阶段的效果一定不会太好,拉群,随时问候,每日同步都非常重要。

一旦确立目标,全力以赴,一起搞清楚要做的事情,拉上专家一起,势必在项目初期就识别风险,不要到最后各处救火。滚动式规划很重要,公司同事都是愿意做好事情的,这一点非常重要。事因难能,所以可贵,能够在很短时间里靠集体的力量完成这个难度还蛮高的项目本来就不容易。上线后持续迭代,上线后回顾都显得尤其重要,NLP尤其需要重点留意,全力以赴冲刺,上线一个比较好的效果,能够帮忙公司,这本来就是一件美好的事情,感谢、感激、感恩大家那一个个奋斗的夜晚和周末,一起继续加油,争取早日可运营!

最后要说下个人收获最大的经验教训了,目标一旦确定势必全力以赴。后续项目有则改之,无则加勉。从各个纬度:

1. 需求阶段即识别最关键路径,包括技术风险,拉主要负责人一起讨论应对之策,滚动式规划,搞不定也得有计划。最大的技术风险看其他同事怎样帮助,充分利用业务方的期盼和技术同事的主观能动性。一起感受到业务的期盼。

2. 大数据模型迭代需要一个较长的时间,这一点不仅要让自己明白,也需要让产品和技术,尤其是关键的业务明白,有计划地推进落地。做出来计划,分解出WBS。不要等上面催促的时候才回复,有计划,有安排,这也非常重要。

3. 申请到新团队资源,一定要留意有个磨合的过程。这个需要作为项目的风险,一直观察,团队组建到成熟高产出,需要时间。多沟通,各种形式狂轰滥炸。当前,快速申请资源本身还是不错的,这个值得嘉奖,从上往下得到领导支持非常重要。

4. 远程团队需要跟负责人建好,提前沟通加班安排。紧密每周沟通,尤其是在联调的关键时期,索性本次并没有掉链子。产品和实际开发要多沟通,避免技术负责人太忙,以至于信息有断层。

5. 安全评审和上线验收要提前准备,通知产品经理,同时号召各产品线准备好验收场景和所需要的数据,权限,确保干系人都在场,否则没法搞了。测试有理由不上线,因为没有产品经理验收。

6. 对需要进行数据初始化的项目,一定要确认好初始化的数据,需要的时间,各下游系统的准备,都需要规划好。可以和上线并行地搞,这样才不至于后期被动,这个也是非常重要的。

再次回顾下墨菲定律,你越不想某件事情发生,某件事情越会发生。比如这次半夜上线推迟到第二天中午,进一步推迟到第二天下午,因为担心半夜发布的风险和发现新问题所致;比如验收过程中导入数据,以为一切就绪,发现走HIVE的时间也是好几个小时,手工拼装数据也并非想象中那么容易,一个多小时硬是变成了半天;比如NLP准确率从头到尾都是一个问题,一开始懵懵懂懂到最后逐步清晰,这其实可以更要让其发生,虽然已尽全力,但着实没有办法,晚两周发布会不会更好。

期望自己能够继续成长,积累心得,下一个项目少走弯路。有并行思维而非串行思维,这同样重要。项目在每天和每周最重要的事情都需要罗列下,这就是项目周报、项目里程碑的意义,这些内容随时可供自己参考,也方便干系人了解项目最新的状态。

上一篇下一篇

猜你喜欢

热点阅读