是沉没成本还是撬动杠杆？Scrum Master于个人和组织的取之有道。

在设计一个全新的产品时，经常会遇到很多问题，用户是谁？这个模块应该占界面中多大的区域，用户的操作流程是如何的？在遇到较为复杂的交互模式和行为的工具型产品时设计师可能一开始就陷入某个功能的设计细节中，这往往到了产品后续迭代中会产生一些因前期设计框架的思考不足导致了产品后续迭代过程中需要从框架层面进行一些调整可能会带来一些不可逆的伤害。

IS（Inspiration Spaces，灵感空间）是一款由酷家乐Coohom团队开发的面向消费者的家具或定制行业营销产品，用户可以根据个人取向选择样板间，并以全景图形式查看样板间详情并进行内容素材替换，实现所见即所得。适用范围包括定制，成品，硬装在内的多个行业，目的是引导消费者以极简的方式经历一个方案设计过程，亲自选择喜欢的风格，刺激消费者的兴趣，成为高质量的商业线索，以促进企业后续电话沟通、店面访问、成单。

Freemium（免费增值）模式：顾名思义，它允许用户免费在应用或游戏中体验免费的基本功能，然后打包对高级功能“收费”，最终引导用户为增值服务埋单。“Freemium”在SaaS和应用程序中非常普遍，在这里，产品的免费版本是一个用户增长的驱动力，长远看来可为产品带来收入转化。

2022年开始，公司对敏捷组的规范运作有了比较明确的要求，为了能够及时发现和识别团队存在的问题，促进团队持续改进，不断提升业务交付能力，为达成酷家乐战略目标提供支撑保障，敏捷治理事项就被提上了日程。

治理事项涉及到定量的各项度量指标及敏捷活动的规范性落地。酷家乐敏捷组的自由度是非常高的，在这种情况下，如何井然有序的进行治理，以达成不断提升交付能力的目标，将是一个非常有挑战的事情。

随着全球化贸易的进一步加深，不少互联网产品为了引入更大体量的用户体验并使用产品而开启了“出海之旅”。直接降低用户购买门槛的多币种支付，变成了产品必需品。如果说语言翻译是产品国际化的第一步，那么多币种支付能力的搭建就是紧随其后的第二步。

随着迭代的更替，业务数据数据越来越庞大、复杂，日常测试中，JSON数据存在每次id都变化、数组顺序变化、坐标发生变化、json中包转义json等现象，现有的JSON对比工具无法解决所有问题。业务线需要做对比，必须对数据进行特殊处理，未来数据结构发生变化，维护成本高。

基于此，我们决定开发一款通用的，能够支持个性化对比需求，拓展性好的JSON对比工具，来解决业务线日常测试中的JSON对比的难题。

本文结合群核科技技术类项目管理流程，浅谈下技术项目特有的一些挑战点及对应的解决方案。

关于软件的可用性测试大家并不陌生，可用性测试是评估软件/产品体验质量（是否易用、高效、令人满意）的常见手段，是体验度量的重要手段之一。

常见的可用性测试可大致分为两类：

不面向用户的可用性测试-用户模型法

用户模型是使用数学模型来模拟人机交互，其原理是认定用户使用产品都是有目标的，而大的目标有可以拆分为若干小目标，通过模型计算达成目标的所需时间。该方法无法适用于用户测试，在人机交互领域著名的预测模型是GOMS模型。

面向用户的可用性测试—用户调查法

用户调查是通过对用户进行访谈，手段多样，包含问卷调查、用户访谈、焦点小组、观察法、绩效测量、启发式评估等，这其中，使用更多也更为人熟知是问卷调查。

问卷调查相对于其他手段的好处在其调研结果更为客观，可信度较强，且问卷的创建经过了信效度和灵敏度测试，结果更具备说服力。

随着产品的不停迭代以及新旧产品的更替，有些产品一旦转入维护状态，测试工作就会变得相当棘手，保障老旧服务的稳定运行也就遇到了瓶颈。

JTBD全称Jobs To Be Done，中文翻译为待办任务（或待完成工作），也有人称其为“焦糖布丁理论”。是由哈佛大学教授Clay christansen于2003年提出，一种洞察用户需求的模型及理论，被认为是颠覆性创新的理论基础。JTBD中的一些概念并不是全新的，但它确实是一个少有的可用于产品创新的系统性研究框架。

从催逼盯，到串推破的进化；从点线面，到突破认知的格局；做认为对的事，心态定乾坤。

数据保存是Web端工具的基础功能，一般在产品和技术框架设计之初就已经确定了数据保存的方式，后续不太会频繁更改。

正因为如此，在日常需求迭代中，设计师很容易忽略数据保存的过程，也很少质疑当前的保存机制是否合理，但是当需要设计新模块或产品时就会对保存有疑惑。

此外，保存也是一个受技术限制较大的领域，设计师需要对保存的技术类型有基础认知，因为它会影响保存生效的逻辑和交互形式。 本文将会基于个人经验，从设计表现和技术实现的角度聊聊Web端工具的数据保存。

SaaS业务设计本质上属于B端产品设计， 但是房企业务因行业属性的独特性也带来了设计层面的差异性。笔者将自己在房产业务的设计心路分享跟大家，一方面希望帮助大家一定程度上了解面向大型B端地产客户的SaaS业务，另一方面也希望从“设计支撑”及“设计赋能”2个维度为大家带来新鲜的视角。

接口自动化是一种能提高服务回归效率，保证服务稳定性的重要方式。但是对很多做接口自动化的测试来说，往往痛苦大于快乐。主要问题还是在于接口自动化的校验。

写校验成本较高。很多接口响应字段可能非常多，结构体复杂，要做到详细校验编写成本很高。而越详细的校验，维护成本也越高。测试数据的变动，开发的改造，往往能让人崩溃。

校验不够详细。很多接口case为了急于求成没有写返回校验，或者校验深度不够，这会导致接口自动化流于形式，不能发挥真正的作用；

基于此，希望有一个快速编写接口响应校验的方法，要求简单、便捷、有效、可维护性高。

本以为接口自动化大家都在做，通用的响应校验网上应该有很多现成的，但是找了下却没有找到满意的。通用的json校验有，但是接口响应未必都是json格式的。DeepDiff在功能上基本满足要求，但是它是python的，而本人需要的是java的。

基于此，就考虑自己封装出一个基于java的通用的接口响应校验方法，降低接口响应校验的编写和维护成本。

对于以技术为核心竞争力的公司，往往会存在一些技术科研或技术实验室的团队，在主产品稳定后，避免不了要将实验室研究的其他技术进行孵化，衍生出新的产品来扩展新市场，完善公司更大的版图。技术创新通常分为2类，一类是成熟技术的改革，另一类是新兴技术的诞生，其中成熟技术的改革在一般公司更为普遍。