技术部门

梅斯

一、问题与如何解决问题

1. 技术部门内部（内部建设）

• 技术能力参差不齐
  解决： 一强带一弱原则，保证在做东西的同时可以学东西，同时不断提升强者的全局／项目管理能力和弱者技术能力(只针对PHP）

• 需求变更／需求不够明确／需求不可实现反复沟通和劳作

  • 需求变更：项目一期／二期版本迭代中的变更和快完成的功能被变更
  • 需求不够明确：只提出一个模糊的概念性功能，却没有接下去的更实际的功能点要求
  • 需求不可实现：合同已经签了，但到达开发手中时发现这个需求成本和实现难度过大

• 技术规范落实不够明确
  每个小的项目组开发过程中的技术规范各不相同。

2. 技术部门与设计部门（外部配合）

• 功能实现人员与UI设计之间的工作流

  • 沟通成本（技术和非技术对话的理解差异）
  • 要求规范模糊
  • 执行结果的审查

• 页面反复修改沟通

  • 技术领域和技术环境差异的沟通开发成本
  • Bug 相互提交的流程方式

3. 技术部门与产品部门（质量管控）

• 需求描述技术点对于技术人员实施不够明确

  • 需求表述的理解差异
  • 需求实施过程的渐渐需求偏差

• 协同工作不对等

  • 需求知晓
  • 沟通及时性

  • 产品开发进度
    解决：
    产品工作流

    1. 有明确的产品目录规范
       SVN：产品文档管理
       
       禅道： 产品需求和Bug管理

       • 需求指派
       • 任务分解

    2. 有明确的 case 实例
       

二、Q3 目标／KPI

1. 目标

• 部门成员目标

  • 代码规范和质量有所改善
  • 项目交流沟通有所降低
  • 能力有所提升

• 部门项目目标

  • 项目工作计划更加明确
  • 项目质量提高

• 工作任务流执行

  • 禅道使用和执行提高

• 去除日报／只用写周报

  • 工作繁琐性降低

2. KPI

• 项目交付时间（是否逾期）
• 项目交付质量（bug修复数量）
• 代码提交量／代码质量
• 每日 task 处理情况
• 个人成长情况（学习分享）只加分不减分

三、Q4 预计划／预目标

预计划

1. 持续代码规范和代码review
2. 持续工作任务流规范
3. 松江徐汇服务器区分
4. 组织架构重构
5. 相似性项目整理编排

预目标

1. 成员代码质量得到质的提升
2. 成员沟通效率得到质的改善

四、人员组织调整

产品开发SOP：

是产品不是项目