项目总结

参与人员

• 产品(PM)
• UI设计师
• 开发人员
• *测试人员

主要流程

• 产品(PM)确定需求，需求整理成档
• 开发人员参与讨论，确定技术可行性

• 产品二次整理，并出项目原型稿与必要说明文档

  • 设计人员丰富产品细节，出最终效果稿，并整理色值、宽高等供开发人员使用的说明文档

  • 开发人员依据原型稿，初步设计搭建技术框架

    • 技术选型
    • 项目基础框架搭建
    • 全局把控，模块化设计
    • 为分工执行做好必要准备

• 开发人员正式全力开发(各职位相互配合，此时已开发为主要中心)

  • 针对实现过程中的功能需求需要与产品沟通
  • 界面交互等视觉问题需与设计人员沟通

• 开发完毕，自我测试

  • 设计验收效果
  • 产品体验检查

各角色职责与注意事项

产品(PM)

• 立项

  • 要做什么产品？
  • 该产品的基础功能与要解决的基本需求是什么？
  • 我们是否有做该项目的条件或基础？

• 明确产品目标及定位

  • 洞察目标需求
  • 明确核心功能

• 采集需求

  • 调研目标用户的相关情况
  • 市面上有哪些对标的竟品？它们的状况如何？
  • 有哪些是潜在的可参考目标？

• 确定需求

  • 我们需要的项目特色辅助功能是？
  • 排列需求与功能优先级，并进行分析挑选

• 集体讨论

  • 与开发等人员集体讨论，讨论可行性；并让所有参与人员明确产品本身的定位与思考

注意事项:

• 产品需要走在开发与设计前面：即需要考虑周全，顾虑细节；尽量避免最终实现中发现有遗漏点或不可行
• 产品需要做好沟通与协调的工作，需要让项目开发人员能从一开始就参与进来(前提是产品已经有了一套方案或思路)，避免因为个人思考的局限而导致的未知坑
• 需要有果断力，在一些似可而非的需求方面，能理智的当机立断(所以“明确产品目标及定位”是最大的前提)

UI设计师

• 结合产品特性与定位，确定产品设计基调

  • 主色调、副色调
  • UI风格流派

• 根据产品给的原型，丰富细节

  • 过程中，有任何交互等方面的问题(不明确或不理解)，需立即与产品沟通(或许这就是潜在的产品疏忽)
  • 做第一个UI界面的时候，当完成六七成的时候，就给产品过目，避免不必要的徒劳
  • 整体设计完成一半的时候，就邀请产品一起讨论，以及时解决设计中的问题(可能与产品起初的预期有偏差的问题都可以最小化的避免)
• 设计不应该局限于设计视角，也需要站在产品的思维去理解，甚至是去思考
• 合作过程中，设计会与前端开发人员有较大的接触；而若设计能了解一点前端开发的东西，这能很好的帮助之间的沟通；并且还能很好在设计UI之初就有一种全局观，能同时站在开发人员的角度去分解视觉与交互的逻辑

注意事项:

• 设计需要有产品观，最好还能了解一点开发
• 需要培养自己的产品视觉感

开发人员

• 正式开发前

  • 技术选型

    • 产品确定后，根据产品的功能特点，综合选出最佳技术方案(自身熟悉且擅长的优先)

    • 选型主要围绕这几个点：

      • 开发语言
      • 数据库
      • 框架
      • 第三方工具或依赖
      • 缓存等

  • 定方案

    • 针对需求与功能，设计开发方案
    • 需要明确各个细节，不要把问题留到开发过程

  • 提前模块化准备

    • 拆出重点难点问题，为后期“化整为零，逐个击破”做好准备
    • 方便正式开发时的分工，且减少相互等待干扰等问题

  • 搭基础框架

    • 一旦基础框架搭建好后，后续就是在这个框架上砌砖堆瓦，这是打地基与建骨架的阶段
    • 需要做好可扩展性、安全性、可持续性等方面的考虑

• 正式开发中

  • 统揽各方面细节与因素，设计一套开发流程分工方案
  • 独立开发过程中的改动(如数据库等)，需要及时通知开发组人员；有牵连其他开发人员的功能时，需一起协商讨论，避免开发错乱与无用功
  • 过程中，遇到问题及时找相关人员了解沟通(产品&设计等)

  • 注意规范性、条理性；最好有一套内部的沟通方式(沟通文档)

    • API文档
    • 产品功能列表与注意事项
    • 重点功能解决方案
    • 功能对接说明
  • 该封装的封装，该独立的独立；既要考虑公共可用性，也要考虑逻辑独立性 (高内聚低耦合)

• 正式开发结束后

  • 注意完成一块逻辑后，需要自行测试，及时修改不必要的bug
  • 让产品与设计参与进来，一起检查，及时修改调整

注意事项:

• 开发过程中，最可怕的是已经做了一半，甚至已经完成，结果需求说不是这样的；所以开发人员需要与设计和产品及时沟通，确保对需求或功能的理解准确无误
• 开发人员与开发人员之间在独立工作过程中，需要注意到若目前的功能后面会与其他同事交接，最好提前沟通
• 按功能需求来，一个模块一个模块的按流程与计划完成
• 开发完成后，需要自行测试
• 在待确定或需要后续完成的功能逻辑处，标记TODO，并进行必要说明
• 代码注释是一个好习惯，方便合作开发
• 每个人的工作进度最好及时更新与通知(所以，一套好的协作工具能起到事半功倍的效果)，让每个人都能知道项目的进展，也方便及时解决过程中的问题

测试人员

• TODO