《拓科项目管理的革命汇编》由会员分享，可在线阅读，更多相关《拓科项目管理的革命汇编（27页珍藏版）》请在金锄头文库上搜索。
1、项目管理的革命 By Unicorn 2017-02-23 过去四年我们如何管理项目？ 第一阶段 业务量较少，业务零散，多数快餐项目，卖出去了可能没有在使用 技术不成熟，在项目管理方面四个字：没有管理 业务量少，有活干，能按时完成就开心；项目由12人完成，不需要协调和管理； 项目是顺序执行，思维是单线程，只能一个项目一个项目完成。项目之间有较大的 空闲期，有时间折腾。 在技术方面，纯粹的在用项目练习技术，过程中碰到很多问题，没有记录，就靠百 度。做过的东西没有积累，没有文档，完全依靠头脑记忆。 在管理方面，没有管理，人少不需要管理 第二阶段 人数 4个左右 接到难度相对提升一个层次的单子，或者
2、同时接到两到三个单子，开始进入忙碌阶段，忙不过来，招人，请外援 助 招人没有一个入职培训流程，完全依赖于新员工自身技能水平和领悟能力，一般新人入职，有三种情况，一个需 求列表扔过去，把这个需求满足了；一个功能列表扔过去，把这些功能实现了；一套代码扔过去，把这个代码看 会了。 为什么？因为忙，没空，顶多抽空给你讲几句，要文档？没有文档，你自己整理吧，确实没空，写文档要思考、 编写和整理文档通顺，整理文档的时间。这是新人能力够的情况下，如果本身技能水平还不够，要接手项目完全 不可能。 人交接和离职完全通过代码+口头交代，没有文档记录或者说是应付式文档，注意，如果没有文档记录，项目原作 者可能自己都
3、不能完全清晰的描述项目的结构和设计原理，何况口口相传来交接，中间一定会有疏漏和产生错误 的理解，如果项目多来几次转手，设计思路一定是面目全非的。 第三阶段 2014年7月 从这个时期，业务来源开始稳定，逐渐拥有长期合作客户，同时做一些快餐项目 开始注意到文档的重要性，使用office文档记录协议设计，但基本在初次使用，文档几乎不会再更新。同时，新人 来会经历一个空白期，并不是一来就有事干，先自己折腾着吧。并不是闲，而是开始了部分人忙，部分人闲的状 态，为什么？员工技能不好评估，并且项目任务职责没有明确划分，导致已有项目让新人插手不容易，培训要花 费大量精力，不如自己三两下就搞定了。而暂时又没有
4、适合的新项目给新人做。 在技术方面，也暂时没有很大的突破，因为没有积累，做项目做完了就完了，要么开展下一个项目，要么闲着刷 网页，没有主动进行总结和积累。每个人做过的东西仅存在于自己的脑海中。没有技术分享精神或一个形式，导 致一个功能、一个问题往往需要找原来做过的人去做或者去解决。这会导致这个人在这个方面越来越熟练，而其 他人并不了解，而没有分享机制， 导致经常出现救火英雄。不要去试图做救火英雄。 在管理方面，因为人数扩充，出现35人共同开发一个项目，所以有决策人，任务分配的出现，这并非积极的，而 是顺应趋势产生的。 第四阶段 2015年5月 在线文档版本管理及知识库概念的产生 有道云笔记 前
5、期具有代表性的是时刻报警系统，在产品不断更新过程中记录产品特性变化及开发细节。 而知识库并没有在公司中开展成功，在知识方面仍然未出现好的共享机制，在入职离职方面也没有好的风险控制方法。 虽然文档管理方面使用有道云，并在公司内推广开来，但是文档质量、形式不一。 并且在项目开发过程中，文档的产出过少，不能够让后来人能顺利入手，很多关键的内容没有进行记录，这一方面来源于开发人员 的写作能力不够、积极性不够和时间太紧。 在项目管理中，几乎没有统一的项目对接人，导致同一个客户的需求可能交代了两个人，两个人之间可能信息不同步，到后面，由 于信息落后太多，直接项目脱手交由另外一个人全程负责。 在服务器管理方
6、面，没有严格的风险控制，服务器密码几乎公开，在源码版本控制中心、仓库私服所在服务器安装软件进行测试。 有一个原因也是在于没有固定的测试/演示服务器。 在程序版本管理上也有进步，区分发布程序版本，并对应前后台发布版本，但在源代码版本控制几乎没有，最大的原因是公司内部 对于版本控制工具没有一个统一的使用培训。 第五阶段 现在 摆脱过去的问题 技术 拓科是一家纯粹的软件公司，高 品质软件服务是我们能提供给客 户唯一的价值。 高品质软件服务： 1、命中痛点 2、短时间 3、低成本 4、高质量 唯有坚实的技术支撑，我们才能 有资本站在更高层面为用户考虑 营造浓厚学习氛围 打造优秀技术团队 拓科是一家纯粹
7、的软件公司 我们的目标是为客户创造解决业务领域问题的软件产品 为客户提供高品质软件服务是我们所能提供的唯一价值 唯技术的专注和沉淀才能支撑拓科从生存走向快速成长 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 建立技术方向主线建立技术方向主线 2 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 建立技术方向主线建立技术方向主线 2 技术分享形式多元化技术分享形式多元化3 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 建立技术方向主线建立技术方向主线 2 技术分享形式多元化技术分享形式多元化3 完成理论完成理论- -实践实践- -经验经验- -知识的转化
8、知识的转化 4 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 建立技术方向主线建立技术方向主线 2 技术分享形式多元化技术分享形式多元化3 通过知识水平测试加强知识吸收通过知识水平测试加强知识吸收5 完成理论完成理论- -经验经验- -知识的转化知识的转化 4 最佳实践 站在巨人的肩膀上站在巨人的肩膀上1 建立技术方向主线建立技术方向主线 2 技术分享形式多元化技术分享形式多元化3 通过知识水平测试加强知识吸收通过知识水平测试加强知识吸收5 完成理论完成理论- -经验经验- -知识的转化知识的转化 4 与外界沟通验证公司技术发展模式与外界沟通验证公司技术发展模式 6 项目开展流程规范化 健康的
9、项目管理方式能大幅度提升 项目的成功率 产品经理：需求范围确认与制定计划 项目开展流程规范化 产品经理：需求范围确认与制定计划项目经理：任务管理及风险与进度控制 项目开展流程规范化 产品经理：需求范围确 认与制定计划 项目经理：任务管理及 风险与进度控制 开发人员：确认与完成 任务和BUG 项目开展流程规范化 产品经理：需求范围确 认与制定计划 项目经理：任务管理及 风险与进度控制 开发人员：确认与完成 任务和BUG 测试人员：制定测试计 划和执行测试任务 项目开展流程规范化 产品经理：需求范围确 认与制定计划 开发人员：确认与完成 任务和BUG 项目经理：任务管理及 风险与进度控制 测试人员
10、：制定测试计 划和执行测试任务 产品经理：发布版本 项目开展流程规范化 产品经理：需求范围 确认与制定计划 项目经理：任务管理 及风险/进度控制 开发人员：确认与完 成任务/BUG 测试人员：制定测试 计划和执行测试任务 项目管理及技术总结 产品经理：发布版本 项目开展流程规范化 使用TeamOSC TeamOSC 是开源中国推出的专门针对 开发者的轻量级的团队协作开发平台。 GIT集成 任务&BUG管理 项目协作文档 团队讨论 资源分享 便签 项目周报 GitOSC 代码托管 接下来会可能会用到 SonarOSC 代码质量分析 PaaSOSC 演示平台 第六阶段 未来 解决我们目前已知却无法解决的问题，包括： 1、让历史项目得到良性发展 2、我们要有一个切合我们公司需要的项目管理体系和配套系统 3、几乎不需要加班赶工 4、将客户需求进行整理，分析共性和区别 5、职责清晰划分 6、人员可平滑扩充 7、从提供软件服务走向提供解决方案 Thank You！
