研发团队改进解决方案报告.pdfVIP

石空谁道 2013-9-16 目录 1 研发团队现状与分析 7月 需求分析与改进目标 2 3 总体方案与工作分解 4 主要步骤与工作计划 Page 2 一些工程师的声音 我同时承担了部门工作和多个项目的工 我不知道别的人在忙什么，虽然在 作，我该如何安排好自己的工作时间？ 一个项目中，我也不知道他应该做 什么？ 自己做得很辛苦，领导不了 解，很委屈。 怎样继承其他人的经验， 避免犯同样的错误？ 我的职责到底是什么？这 以前不给文档不是也测试， 反正我不承担责任！ 现在居然还对我写的文档提 要求，得寸进尺！ Page 3 一些技术管理人员的困恼 对资源预测不清楚， 总是要从不同层 导致规划成“鬼话” 面解决各种问题， 角色复杂难切换 工作质量和工作 每天要花很多时 效率总是难以平 间扯皮开会，搞 衡，外面投诉的 不清楚该谁去做 声音很大 这个事情 没时间培养人员，导致 团队能力提升缓慢，士 气低落，绩效能以评估， Page 4 缺少技术梯队 一些项目管理中的困恼 项目组人员忙闲不均， 项目信息不透明， 工作不透明；任务布 布置下去的工作不 置不下去，员工反馈 能天天盯着员工， 工作很忙，但不知道 无法实时监控 在忙什么 缺乏量化数据， 过去犯过的错误经常 做绩效考核缺乏 犯，缺乏经验教训的 客观依据 积累 Page 5 一些资源管理人员的困惑 每年的研发投入不少，但是产品总是不能够按照计划推向市场？ 研发资源究竟投到什么地方了，是否有监控保障？ 如何量化评估研发项目和工程师的绩效？ 人员离职对公司和项目的冲击很大，如何固化技术知识库？ Page 6 研发团队场景描述 管理越来越复杂 团队氛围越来越压抑 技术开发成本越来越高 Page 7 对现状的分析-开发模式 主要缺陷： 程序的维护成本会越来越高（需要很多人） 团队氛围压抑（感受不到激情） 不方便做需求变更（引起客户不满） Page 8 对现状的分析-人员层面 研发部最主要三种类型人员 技术经理 技术经理 技术经理不够职业化，还是从技术角 度去思考问题，忽略管理。 对项目过程的监控不够，依赖于技术 项目经理 经理的分配，导致周期难以评估 工程师 项目经理 工程师 没有从自身职责考虑问题，展示出自 己专业化的技术水平。推诿责任。 Page 9 对现状的分析-流程制度 组织架构以产品为导向， 研发过程过于向项目化倾斜， 导致没有机制沉淀技术成果。 导致技术组难以抽出时间强化产品。 目前有平台化的规划。 目前有准备成立专门小组优化。 缺少有效的质量保证的机制。 项目监控过于依赖技术经理分配， 对研发过程的风险控制， 技术经理没有足够时间合理协调资源。 质量跟踪，需求跟踪和进度跟踪不够。 缺少研发信息管理系统。 Page 10 对现状的分析-整体考虑 缺少系统解决问题的思维 缺少逐步改进的机制 缺少相互学习推进的意识 缺少沉淀知识的管理 缺少自我激励的动机 缺少客观评估的数据 缺少对任务本身执行的主动思考 缺少团队之间高效的沟通 缺少自我反省，持续改进的态度 缺少对技术的深入研究 Page 11 分析总结 ? 大量的研发技术工作重 ? 同样的技术要求，人员 ? 存在项目繁多，但是大 复出现在不同发布产品 分配到不同产品开发小 多是短平快的特性。 中。 组中。 ? 入口和出口的定义不清。 ? 大量的研发数据分散在 ? 同一个开发人员，同时 ? 大多数业务需要多人沟 不同技术主管的大脑中。 承担多个项目开发工作。 通协作完成，沟通成本 ? 大量的对前端的支持需 ? 开发人员技术水平和人 高。 要项目经理和技术经理， 力投入量难以评估。 ? 缺少反馈和变更控制机 工程师一起协作完成。 ? 研发资源的复用性不高。 制来迅速响应变更。 ? 项目密集型容易造成劳 ? 研发被认可度低，造成 ? 软件开发的构建，部署， 动密集型研发团队。 士气低落，陷入恶性循 测试，发布过程缺少自 ? 研发过程的项目监控薄 环。 动化。且Beta测试是由 弱。 工程人员完成。 Page 12 面对现状该怎么办？ Page 13 目录 1 研发团队现状与分析 7月 需求分析与改进目标 2 3 总体方案与工作分解 4 主要步骤与工作计划 Page 14 研发团队面临的挑战 也许因为所在的行业曾经并不开放，属于寡头市场，所以对研发产品的要求并不高， 但是随着市场的开放，商业竞争的激烈，导致了研发跟不上市场的变化。而越是竞争 激烈的市场，对产品和研发的要求越高。这就要求研发迅速解决当前存在的问题： ? 统一产品线运营 ? 高效开发测试的能力 ? 将产品变成整体解决方 ? 平台化管理 ? 知识管理与技术创新 案 ? 降低运维成本 ? 掌握行业领先的前沿技