|
就这样，带着这些问题，我走过了前两个阶段，直到到达第三阶段，才有了质的改变。项目管理论坛
总结以上问题，核心还是在于团队能力线问题，所以提高团队能力线，才是以上问题的正解。到这里，正如“如何学做管理”中所说，这个问题要通过培养团队成员来解决，那么问题来了，怎么样培养团队成员呢?项目经理博客
我们的Android应用开发团队是一个年轻的团队，一些知识体系都还有待完善和建设，作为团队负责人，我有责任和义务给团队成员指明未来的方向。因此，作为培养的第一步，先明确我们团队需要些什么，他们要做些什么，现在能做些什么?我们先来第一步，组织构建：项目管理者联盟
组织构建转自项目管理者联盟
控制组织大小，4到6人为一个小组织。项目经理博客
我们团队有20人，一个20人的团队，任何思想的传达效率都会比较低，协作成本高，根据我个人的开发经验，4到6人的团队沟通成本低(随便找个空地就能开聊)，利于互帮互助。项目管理者联盟
明确各个小组织的领域范畴和责任。项目管理论坛
这个点需要一定的技术背景才能操作，我将Android应用领域拆分为8个领域，包括数据与系统对接、网络与性能、界面与国际化、H5与工具链，每个小组织负责2两个领域的持续跟进研究，以及沉淀。PgMp.mypm.net
人员责任包括领域研究和产品开发。项目管理者联盟
对于人员的要求，所有应用开发人员同样需要负责模块功能的开发，同时要兼顾领域研究，让所有人员既有产品观，全局观(了解应用开发需要的所有技术)，同时又有自己的核心领域，做到广而精。项目管理者联盟
这样才划分带来了很多的好处，各个领域的独立，降低了团队成员的心智负担(操心的事情多)，每个人都能一门心思的研究自己的领域，遇到非自己领域问题搞不定时，团队里总能找到能提供帮助的人(有所依靠，哈哈)。一个小组织的成立，我们还可以做弱结对编程、代码审查。因为他们的领域相同，知识体系一样，很容易做到这件事，沟通交流更顺心。项目管理者联盟
另外，附加的收益，由于领域的独立，紧接着领域的沉淀也逐步加强，各种设计文档也很自然的产生(开发人员不是天生都不喜欢写文档，而是不愿意写没有意义的文档)，未来新成员培训也是很有希望做到的。这些好像和团队成员培养没关系?嗯，是的，没有直接关系，但是他们是我进行团队培养的基础，是成员成长必不可少的环境，没有这样的设定，团队培养很难落地执行，接下来开始团队培养：项目管理者联盟
团队培养www.mypm.net
识别团队中的核心成员，给他们合适的权力和责任。项目管理者联盟
想想，一个班里面，除了老师还有班委。为什么呢?层级太多不是也不怎么好么?如果我能同时兼顾20人的所有细节工作，自然不想再构建新的层级。当我们的关注的事务细化到一个层面后，那么精力就不够了，作为领域团队层面，我们的关注点要细化到代码设计甚至编码级别，一个人能搞定吗?至少我搞不定!那么这和培养有什么关系呢?我对培养的定义不仅仅是指导，还包括培养环境的构建。所以这里做的目的主要有两个。第一，给他们更大的发挥空间，发挥更多的价值(构建带领一个小领域开发的学习环境，现在的开发已经很少能单兵作战了)，第二，让他们带我传递我的思想和理念，小团队传递效率更高，深度更深。项目管理者联盟
各领域持续指导和跟进。
各领域成立后，我的精力主要放在和他们沟通上，让他们明白程序应该怎么设计，这个领域需要做哪些事情，应该怎么做，成员如何组织等，反复不断的沟通、总结、改善，持续的做下去，直到我觉得我们大家的思想是一致的，方式方法没有问题(当然，如果我错了，那么问题就大了，我得保证我没有搞错，或者错了及时改正)，这样他们才能有效的指导他们领域的成员，带领他们前进。项目管理者联盟
领域拉通，成员能力挖掘，查漏补缺。项目管理者联盟
各小领域成立后，并不代表我就可以做甩手掌柜，除了各领域的培养以外，我还需要拉通各个小领域，促使他们有效的协作，降低他们之间的耦合，减少跨领域的成本。同时，还需要持续不断的关注团队成员的学习进展，给与他们合适的建议，以及符合他当前能力的工作，针对有潜力的成员重点指导，针对有问题的成员及时告诉他的问题，促使他改善。项目管理者联盟
关注新技术，加强自身对技术的学习，带着团队向前走。项目管理者联盟
细节有很多，这里谈到了主要方面，个人总结能力还是有限啊，主要只想说一点：核心是为了产品的研发，开展基于培养提升团队成员能力，形成自组织，流程、规范、考核均是辅助措施，能无就无，谨慎对待。项目管理培训
3.如何做敏捷项目管理项目管理者联盟
敏捷团队是一个全功能团队，里面包含了各个领域的成员，由于公司原本组织架构的一些特点，我们并没有像标准敏捷项目团队那样，有产品经理、敏捷教练等职务，与之对应的是规划与交互，项目负责人。虽然“形”对不上，但是如果能对上“神”，也是不错的。项目管理者联盟
在敏捷之初，我们并没有理解什么叫迭代，我们傻乎乎的定迭代周期为一周，而且还觉得自己在走敏捷的迭代。可惜我们那不是迭代，我们只是每周计划一下需要开发的工作而已，仅此而已。因而带来了很多问题，前端需求人员不知道功能的开发预期和进展，项目负责人也就是协调协调资源，面对纷繁复杂的功能项开发，也不太情况每个功能的开发进展，当前是否正常(除非非常不正常才能发现)。整个项目组感觉都忙忙碌碌，但是却不知道大家都做了些什么?每天晨会大家说的事情都有点不知所云，感觉晨会都快没有实际意义了。问题太多，以至于我们有点迷失方向。项目管理者联盟
敏捷，宣称要拥抱变化，我们却粗浅的理解为不需要计划，是不是很白痴。我个人现在对拥抱变化的理解为：“及时交付可体验的产品，随时做好调整的准备，日常的工作任务安排，如果发现不合符预期，需要及时调整，重新评估新的任务，而不是掩耳盗铃，觉得不列一个新任务就会快一点”。好了，临近年底，对于敏捷总算有所顿悟，多亏了《敏捷估算和规划》这本书，给予了我很多启发。接下来，谈谈具体的一些实施细节。项目管理论坛
|
