解决方案落地思考

解决方案的几个概念:明德立达认为:作物解决方案=健康种植服务方案;作物解决方案是一种服务-是作物从种到收获以至存储的系统服务,其本质是一种产品;这种交易...

解决方案落地思考

• 方法论
  • 目标
    • 要完成到什么程度和标准，达到什么预期
  • 组织策略
    • 围绕目标需要做怎么策略和组织，调动什么样的资源
  • 执行力
    • 每个组织和策略用什么方式来执行，什么人来执行
  • 工具
    • 用到哪些工具来确保执行的高效和可靠
• 方案设计阶段评审
  • 目标：确定项目业务边界和业务架构，在业务形态和功能层面能否满足客户需求
  • 牵头角色：售前及区域技术经理
  • 组织策略
    • 项目调研
      • 对客户
        • 客户方面的项目负责人是谁什么职务，他对项目有哪些要求，看重哪些业务功能
      • 对内部
        • 我们在项目中的角色是怎样？总集成还是被集成？话语权强势还是弱势？该项目涉及哪些公司产品？有哪些是定制化需求？
      • 对第三方
        • 有哪些参与第三方的公司，在业务上我们与他们可能在哪些业务模块上存在交集？可能需要双方在业务和技术实现方面要提前沟通？
    • 方案设计
      • 方案整体设计
        • 建设背景
        • 业务需求
        • 业务框架和逻辑关系
      • 标准产品方案设计
        • 产品版本和最新功能清单
      • 定制化需求设计
        • 调研客户定制化的深层需求，这些需求需要满足哪些角色的业务需要
        • 行解研设计用户故事地图，每个业务需求涉及的角色和大的业务逻辑关系，跟客户需求部门求同
        • 产品经理和需求分析师根据用户故事地图，设计原型同客户沟通确定
    • 方案评审
      • 评审形式
        • 方案设计者讲解方案设计文档
      • 评审小组成员
        • 售前、区域技术经理、行解研
          • 需求是否准确无偏移
        • 方案所涉及产品的产品经理
          • 产品能否满足客户需求
        • 架构师、开发经理、开发管理部等
          • 非产品需求和定制化需求是否具有可行性
          • 不确定的需要预研
      • 评审次数
        • 三次评审制度
          • 初评
            • 项目初次评审，提出问题发现问题
          • 复评
            • 解决初评问题，就难点进行讨论和研究
          • 终评
            • 确认难点的解决思路，认可方案边界和可行性
      • 评审输出
        • 形成评审报告，记录三次评审记录和最终方案，各方确认
        • 小组评审结论，就评审的方案设计和修改内容，各方确认
• 交付阶段深化设计
  • 目标：深化研究方案在项目中的技术落地细节和问题，提前设计解决问题的思路，降低交付风险
  • 牵头角色：区域技术经理主导客户和合作伙伴对话，牵头拉通开发管理部及相关开发资源，由开发管理部输出深化设计方案
  • 组织策略
    • 深化设计范畴
      • 与其他厂家和集成商的功能边界
        • 我们做什么，别人做社么
      • 数据的类型与流向
        • 有哪些数据类型，比如视频、人脸抓拍、车辆抓拍、人形结构化、特征值、url
        • 这些数据是谁生产的，怎么生产的，怎么流转，在哪些产品和系统之间流转，给到哪些应用，怎么给到应用
        • 在数据流转的过程中，哪些需要定制化，具体定制化的方案和要求
          • 由研发团队评估可行性和工作量
      • 涉及定制开发功能的明确
        • 比如多个系统权限一致、统一系统门户、统一日志、APP功能等
        • 确定技术落地的可行性方向和大概工作量
      • 相关文档的收集
        • 各方对接接口文档
          • 我们需要给对方什么文档
          • 我们需要对方提供哪些文档
      • 部署方案
        • 明确部署哪些模块和版本
        • 具体的服务器资源和部署规划
    • 深化设计过程
      • 组建深化设计小组
        • 开发管理部主导
        • 项目涉及的相关产品和技术人员
        • 拉通技术资源
      • 对接外部资源
        • 客户
        • 厂家
        • 合作伙伴
      • 围绕技术落地进行讨论
        • 尽量面对面会议，条件不允许则通过电话会议方式
        • 按照数据类型设计技术实现方式
        • 参考“深化设计范畴”
      • 深化设计输出
        • 与厂家、合作伙伴等方案求同后，输出深化设计初稿
        • 开发管理部结合内部技术资源对初稿进行评审和补充，形成深化设计终稿
        • 业务方案设计者需要参加评审，确保技术设计真正满足业务需要
• 需求变更管控
  • 目标：控制需求变更的边界，降低因需求变更造成的成本不可控和交付风险
  • 牵头角色：产品经理
  • 组织策略
    • 倾听记录客户需求的描述
      • 可以使用多种格式，如句子、表格、流图、模型、原型等
    • 在理解需求的基础上对需求进行分类
      • 业务需求
        • 业务需求关注业务问题、业务需要和业务目标，不关心怎样解决和实现
        • 挖掘客户的业务目的，为什么要实现这个目标，实现目标的路径有很多种方法
      • 功能需求
        • 怎么完成工作，怎么实施业务规则。描述用户最终看到系统的样子
        • 一个业务需求的可能需要多个功能需求的才能实现
      • 非功能需求
        • 不一定与业务、功能有直接关系，但必须满足的某种需求
        • 可访问性、审计、控制、兼容性、效率、可延展性、可维护性、性能响应、可靠性、稳定性等
      • 技术需求
        • 与技术实现要求有关，如数据库定义、系统接口、网络架构、组件等
        • 技术需求是业务需求的实现路径
    • 沟通需求变更的原因
      • 新增合同外需求
      • 原有需求已经实现但用户不满意，要求变更
    • 需求变更机制
      • 完整描述需求变更的原因
      • 完整描述新需求的内容，必要时可使用原型与客户反复沟通确定需求边界
      • 开发人员评估需求变更造成的新的工作量
      • 以上三点合成《需求变更确认函》，用于在开发工作开始前与用户最终确认需求
      • 所有需求变更均需要需求分析人员与用户沟通并书面确认，请客户签字或盖章