产品反思

整个4月大部分时间都处在产品重构的思考与设计中,牺牲了一些正在坚持的习惯,一方面是时间紧张,另一方面自己很大的精力都投入在这些思考与设计中,没有分心的心思。作为一个由设计到开发的转折点,我觉得有必要对这个过程进行一些反思。

开场白

回顾4月,先是产品的定位的思考,包括其提供给用户的核心价值。后又用了不太到2个周的时间,对前端的框架进行了探索,包括SPA与MPA、SSR与CSR与同构。后来产品设计、架构设计尤其后端服务的拆分通信、最后对界面进行了讨论与设计。下面反思一下整个过程,一方面为了总结经验,另一方面通过回顾也找一下不足与提升空间。

产品设计

产品本身是一个重构,并不是完全从无到有去设计一个产品。从旧的产品中,发现了一些不足。这些不足表现为:

  • 原产品中,最初的想法是将项目管理整个从线下搬到线上,这个出发点没有具体表达出产品的核心价值;
  • 项目管理是一个整体,同时整体搬迁到线上的难度很高,可行性差;
  • 原产品中,虽然有很多角色,但对这些角色如何使用产品,并没有进行设计;
  • 原系统中,功能开发出来,但这个功能本身能为用户提供什么帮助,或者设想用户怎么使用并没有思考清楚;

所以这次的重构,超越了代码层面、服务架构,是一个从旧产品中重新构思新产品的过程。这个过程:

  • 首先是归纳了旧产品的价值,提出了3个核心价值:控制、协同、知识。
    控制指的是项目管理者,对项目进度、产值、成本的控制
    协同指的是项目成员为完成项目所进行的沟通、交互、审核、汇报等协同
    知识指的是由数据涌现的对工程的计划、施工、设计等的辅助功能、预警功能

  • 接着制定了3个使用场景
    第一个场景是控制场景,其包括4种角色,这4种角色以什么样的工作流程、什么样的操作来使用系统,使用后为各角色以及整体产生怎样的价值
    第二个场景是协同场景,业务上是一个用料申请的场景,这个场景本身其实可以分成4个子场景,每个子场景都是一种用料申请,每个子场景中,都是一种1v1的交互
    第三个场景也是协同场景,是一个巡查的场景,涉及2个人物也是1v1的交互

  • 从场景中抽象功能
    从第一场景开始,想象每个角色需要如何使用产品,为了满足其需要,系统要提供什么的功能
    借鉴旧系统,将这些功能分解、聚合这也就就自然过度到了服务设计

服务设计

这里的服务指的是业务层微服务的设计,不能算是整个系统架构的设计。
服务的设计过程中,是根据功能分解、聚合之后的结构,尽量达到高内聚,低耦合。另外,一些公共的业务低相关度的功能抽离到独立的微服务中完成
后来发现,业务服务竟然大约可以与角色相对应,很大程度上达到的多租户的隔离方式。
服务间的通信,大部分采用消息队列来做事件驱动,一部分采用通过redis来共享数据,最小的一部分采用Restful的方式来调用。
这种业务服务设计,由于用户的使用频率不同,对应的服务的流量要求就不同,部署的使用也就要有所差异,当然后边可以通过整个架构的监控、devops等设施来完成

交互设计与界面

交互的设计上也对比着旧系统,旧系统的组织方式是以部分来划分,原本是可以的,但存在的问题是,现有情况多个部门对于主要的个功能的要求相同,造成前端好几处写了多遍。
在这次设计中,并不是从上而下的设计方式,是根据功能使用,自下而上的设计,即先想这个小场景中的功能,应该如何表达,然后画出草图,全部场景设计完全后,将他们聚合在一起的方式。
整个设计过程也与队友进行过多次讨论,吸取了他们的意见。

总结

  • 由产品核心价值定义产品使用场景
  • 由产品使用场景定义需求
  • 由需求来定义功能,由功能定义业务服务
  • 同样由产品使用场景定义交互
  • 产品的使用场景亦可以验证交互与需求

除此之外,本次的产品,很大程度上是借鉴了旧产品,这方面的空间还有很多,比如现场管理分析、各用户分析,比如竞品分析等