一线架构师的一些项目管理心得
项目管理
现代的项目管理通常是4个部分：需求、软件设计、软件开发、产品交付与维护。通常情况下，整个过程是中间重两头轻。
1，需求
每个项目都是要明确需求的，因为没有明确的需求，就没有项目结束的时间。
需求需要分享
需求需要管理
在项目中，需求经常是不断变化的，或增加、或改动，而沟通需求的时间通常是不充分的。所以，需要对需求进行等级规划，等级高的优先处理，进而形成阶段性开发，形成开发节点，即里程碑。这样可以在不同的阶段结束时，对需求进行再讨论，使交付产品更接近客户需求，同时规避需求频繁改动带来的风险。
2，软件设计
软件开发前，通常需要进行软件的概要设计，通过概要设计来指定开发，从而可以提高开发效率。
软件设计时通常会参考一些设计标准，比如ADMEMS设计方法。
ADMEMS矩阵如下图，理论上是先上后下，先左后右。
除了设计架构理论外，还要思考三个W。
Who：为谁设计？What：要解决用户的什么问题？Why：为什么要解决这些用户问题？
通常在项目启动前是没有成功的设计模式的，成功的设计模式都是完成后，回头总结的，即，实际开发过程中也都是靠摸着石头过河的。不过有些经验可以借鉴。
3，软件开发
在资源充分的情况下，软件开发是依托于概要设计拓展出来的详细设计来指定代码编写的。不过，资源充分情况相对较少，所以，多数情况会取消详细设计阶段，直接代码编写。这样，就需要良好的框架予以支撑。通常软件开发进度随着项目越大越完整，而变的越慢，良好的框架也不能解决这个问题，不过它可以延缓研发效率变慢的出现时间。
在具体的代码编写实施中，有很多规则可以参考，如ABSD（基于体系结构的软件设计）、XP（极限编程）。通常来讲，软件开发方法就是指资源的合理调配。比如，项目功能分配，项目功能工时决策权分配，项目需求决策权分配等。
举个敏捷开发的需求决策权分配方法，该方法的好处是研发人员即项目经理，可以减少人员投入。
具体实施如下：
需求具体分为【常规需求】和【审核需求】
【常规需求】：【常规需求】由研发人员直接对接，研发人员拥有需求否决权。
当研发人员接到需求超出常规需求要求，则将【常规需求】转为【审核需求】，转交给项目负责人，由项目负责人审核后，重新分配任务。研发人员拥有需求升级权。
【审核需求】有项目负责人进行审核、或组织会议审核，最后将其量化，重新分配。
流程图如下：
4，产品交付与维护
产品交付后，软件的生命周期正式结束，通常，维护工作会转交给运维部门负责，研发人员转投下一个项目。运维部门对交付后的需求进行整理，统一转交研发负责人，由研发负责人调整工期，统一应对产品交付后的需求。
团队管理
常规团队中通常包含四个角色：架构师、项目经理、组长、组员。其中架构师、项目经理、组长为管理者或协助管理者。现实中，由于资源紧缺，一人身兼多角色的情况也很常见。对这个四个角色进行管理，就是团队管理了。
团队管理是为了提高团队效率，因此很多公司会对团队成员使用KPI(关键绩效指标法)来进行绩效考核，KPI遵循二八原则，重点关注关键任务，对普通任务进行取样计算，这样就对一些不可量化的任务做出了很好的考量标准。
不过现实中，KPI最好的应用，通常是在中小型团队，而在微型团队和大型团队中，经常会出现反效果。
对微小团队管理起最大作用的通常是领导力，而不是绩效。对大规模团队管理起最大作用的，通常是流程。不过，现在主流公司也经常采取团队切割的模式，将大团队切换为更灵活的多个小团队，来提高效率。
团队管理中，除了绩效考核外，还有一个重要部分是团队建设。
团队建设是为了实现团队最大化产出而进行的一系列结构设计及人员激励等行为。
合理的结构设计通常会让团队变的更加稳定。
比如当下流行的鱼群管理。
鱼群本身就是一个复杂的体系，是一个没有核心管理的自组织，但规则简单清晰。
鱼群的基础规则。
1，与其他鱼保持距离。
2，跟上周围鱼的速度。
3，5%的鱼受到奖励，能激发整个鱼群的强烈反应。
即，管理者利用简单清晰的规则，让高度复杂的庞大鱼群得被管理。
----------------------------------------------------------
注：此文章为原创，任何形式的转载都请联系作者获得授权并注明出处！
若您觉得这篇文章还不错，请点击下方的【推荐】，非常感谢！
https://www.cnblogs.com/kiba/p/13596436.html
