技术管理

第1章 写在前面 你可能是项目中的开发能手，最佳情况也只是能保证自己，负责开发的功能没有问题，其他的你是无法保证的。哪怕你承担了项目中全部的开发工作，测试阶段、验收阶段和发布阶段也是需要其他人协助的，假设这些你都可以自己完成，而且也做得很到位，但要是需要该项目在很短的时间内交付，想必你就没有办法了。一个人的能力不管多高，人的精力终究是有限的，任何事情能够得到一个比较满意的结果，都离不开众人的努力，对于项目而言也是如此。 这本小册，打算将多项目管理推进过程中，反馈出来的问题进行分析和提供解决方案，不一定全都是对的，算是自己的一些反思总结和心得分享。本小册计划分为意识篇、能力篇、方法篇、提升篇和附录，意识篇主要是项目管理意识方面的探讨，意识是这一切的基础，意识没有到位，后面的其他方面做得再好，也是有局限性的，就像一棵大树，树根没有长好，枝干树叶的成长也是有限的。因为意识很重要，所以放在前面。能力篇主要是项目管理应该具备哪些能力的探讨。方法篇主要是项目管理方法上面的探讨。至于附录，是一些有助于提升项目管理能力的书籍摘要。 第2章 意识篇 2.1 项目管理的意义 我们探讨项目管理的意义，只会是关联密切的那部分，至于关系到公司成本投入等等问题，虽然是不争的事实，但是对于我们来讲，有点遥远，就不再过多拓展。对于项目负责人而言，他需要明白项目管理的意义，根据我个人一些经验，总结了以下三点，分别涉及到一个项目完整的周期，开始、过程和结束。 一致性 目标一致、步伐一致、项目中的全体成员都需要知道，我们的目标是什么？将全部精力投入到达成目标的要事上面。在这个过程中，间接实现了项目降本增效，还有提高团队的凝聚力。 及时性 项目进行过程中，无时无刻都在发生变化，不管是项目制定的计划，还是遇到了业务或技术难点，及时了解到当下的情况，尽快解决问题，可以避免项目进度受阻。 高质性 项目完成并不意味着没有问题，质量如何保证，就需要项目负责人进行项目的验收，不然怎么知道已经完善了呢？ 以上这三点都是对于项目而言，那么对于项目负责人来说，意义又在哪里呢？那就是一个人的成功（做好事情）固然值得肯定，但如果他能将这种成功因地制宜地在团队其他人身上应验，那将意义深远。 一方面你团队里的成员能力有所提升，对项目上面的工作肯定是有帮助的，另一方面，我们都知道每个人都有自己对世界的一套认知，怎么做事情，都有自己的方式，我们只是一直在摸索那条规律，不断应验和调整，如果其他人也适用，那至少说明，你的一整套理论是有可取之处的，越来越靠近那条规律；如果不适用，那也可以借机进行反思和完善，对你而言是大有裨益的。这也是毛泽东《实践论》里提到的观点，”人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。“ 第3章 能力篇 3.1 项目负责人能力划分 我认真思考了一下，觉得项目负责人的能力可以分为五个阶段，分别对应的关键字是开发、方法、产品、整体、市场。虽然看起来好像呈递进关系，但是我发现实际上不是这样的，很多人可能没办法将其划分在哪个阶段，有些是好几个阶段都覆盖，各阶段要求的能力都有一点，但又不完全具备；有些是第二阶段了，可能第一阶段还没达到等等，所以这个划分只是参考。 3.1.1 第一阶段 项目里自己负责开发的功能高质量完成，基本可以认为是可以直接给客户演示的标准： 功能没什么特别重大的bug，比如不会突然用不了； 功能有完善边界，比如输入手机号有限制以及正确或异常提示等等； 界面交互体验顺畅，不会出现很混乱的场景； 界面美观，细节完善，哪怕一个像素都有注意到等； 3.1.2 第二阶段 项目里自己开发的模块，业务特别熟悉，其他分配出去的就不熟悉； 项目需求理解到位、项目方案设计、项目开发计划、项目内部验收、想提交测试和项目上线等环节都可完成； 3.1.3 第三阶段 项目里全部业务需求的脉络都一清二楚； 项目中涉及到硬件相关的产品都会使用； 产品需求、产品原型如果是你来做呢？对项目需求和原型有自己的见解，完全可以胜任； 3.1.4 第四阶段 项目里的技术栈全都熟悉，比如前端/后端出身的项目负责人去熟悉后端/前端相关技术栈知识。 3.1.5 第五阶段 项目的观念开始转变为产品，对其在市场上的定位以及价值有深刻的见解，明白这个产品的目的是什么？ 关注产品在市场上的推广与营销； 3.2 项目负责人对业务不熟悉 3.2.1 问题描述 一直以来，存在这样的问题，项目负责人接到产品需求之后，可能就扫了一眼，就开始制定项目开发计划，制定好之后，只深入了解自己负责开发的模块，其他的就不会再深入了解了。对于那些其他人开发的功能，只要问三个问题，一般都回答不上来。 是什么，这个是什么功能？ 为什么，客户为什么需要这个功能，这个功能对他们有什么用处，不开发这个功能不行么？ 怎么做，这个功能前端是怎么实现的，后端是怎么实现的？一般能回答到第三个问题的前端/后端部分都很不错了，实际情况别说第二个问题了，有可能第一个问题都不一定知道。而负责开发该功能模块的同事，也可能是边了解边开发，需求了解的程度，刚好可以开发出功能就行了。这样就容易导致，这个项目在管理上面会有问题，表面上风平浪静，其实是失控的状态，主要表现在以下方面： 任务时间评估不到位的问题，经常变更任务计划； 风险意识问题，业务不熟悉，不能提前发现潜在的延期因素，不能有效判断是否需要加班； 任务验收问题，功能是否已实现，与需求是否一致，只根据开发同事的回答结果而定，因为对业务不熟悉，验收的时候有心无力，只能敷衍了事，整个验收工作开展很艰难，积极性也就不高； 3.2.2 解决方案 项目负责人需自己梳理一份项目需求与功能实现文档，将每个功能都按三个问题来梳理清楚，是什么，为什么，怎么做。然后项目推进过程中，有任何变更的需求，就实时更新文档，这样子至少心里是有底的。 3.3 对Bug系统的问题敏感度不高 3.3.1 问题描述 这个问题之所以出现，是因为对工作要求边界不清晰导致的。我们在项目中引入版本管理之后，基本明确在内部验收环节，保证当前Bug系统上面的问题是已经全部解决的。 3.3.2 解决方案 和项目负责人达成共识，内部验收环节，Bug系统上面的问题全部解决，视为任务达成。 3.4 项目任务验收工作没有真正落实 3.4.1 问题描述 之前我们计划项目负责人，每周周五进行任务验收，但在开展过程中，验收其他开发同事任务的时候，经常出现缺胳膊少腿的情况，比如某个任务完成了，但是文档没写，或者写了又没有提交更新；某个任务时间都过了，也没有调整变更，什么原因也没有说明等等，执行起来很困难。现在在项目进度会议上，当场把任务验收，就需要周一的时候，项目负责人牵头更新任务的时间、功能和文档情况，不然周二在项目进度会议上，还是会出现各种各样的问题。但是周一的时候，项目负责人已经验收过任务，周二在项目进度会议上又过一次，对于其他开发同事来说，就觉得被问了两次，显然这个方式可能没有从根本上解决问题。 ...