一线架构师的一些项目管理心得

项目管理

现代的项目管理一般是4个部分：需求、软件设计、软件开发、产品交付与维护。一般状况下，整个过程是中间重两头轻。

1，需求

每一个项目都是要明确需求的，由于没有明确的需求，就没有项目结束的时间。

需求须要分享

在项目的初始阶段，是进行需求整理和需求分析，把需求整理和分析的结果分享给团队，可使团队对产品的愿景拥有清晰的认识，同时，由于有明确的需求，团队成员会对产品有更高的认同感。

需求须要管理

在项目中，需求常常是不断变化的，或增长、或改动，而沟通需求的时间一般是不充分的。因此，须要对需求进行等级规划，等级高的优先处理，进而造成阶段性开发，造成开发节点，即里程碑。这样能够在不一样的阶段结束时，对需求进行再讨论，使交付产品更接近客户需求，同时规避需求频繁改动带来的风险。

2，软件设计

软件开发前，一般须要进行软件的概要设计，经过概要设计来指定开发，从而能够提升开发效率。

软件设计时一般会参考一些设计标准，好比ADMEMS设计方法。

ADMEMS矩阵以下图，理论上是先上后下，先左后右。

除了设计架构理论外，还要思考三个W。

Who：为谁设计？What：要解决用户的什么问题？Why：为何要解决这些用户问题？

一般在项目启动前是没有成功的设计模式的，成功的设计模式都是完成后，回头总结的，即，实际开发过程当中也都是靠摸着石头过河的。不过有些经验能够借鉴。

3，软件开发

在资源充分的状况下，软件开发是依托于概要设计拓展出来的详细设计来指定代码编写的。不过，资源充分状况相对较少，因此，多数状况会取消详细设计阶段，直接代码编写。这样，就须要良好的框架予以支撑。一般软件开发进度随着项目越大越完整，而变的越慢，良好的框架也不能解决这个问题，不过它能够延缓研发效率变慢的出现时间。

在具体的代码编写实施中，有不少规则能够参考，如ABSD（基于体系结构的软件设计）、XP（极限编程）。一般来说，软件开发方法就是指资源的合理调配。好比，项目功能分配，项目功能工时决策权分配，项目需求决策权分配等。

举个敏捷开发的需求决策权分配方法，该方法的好处是研发人员即项目经理，能够减小人员投入。

具体实施以下：

需求具体分为【常规需求】和【审核需求】

【常规需求】：【常规需求】由研发人员直接对接，研发人员拥有需求否决权。

当研发人员接到需求超出常规需求要求，则将【常规需求】转为【审核需求】，转交给项目负责人，由项目负责人审核后，从新分配任务。研发人员拥有需求升级权。

【审核需求】有项目负责人进行审核、或组织会议审核，最后将其量化，从新分配。

流程图以下：

4，产品交付与维护

产品交付后，软件的生命周期正式结束，一般，维护工做会转交给运维部门负责，研发人员转投下一个项目。运维部门对交付后的需求进行整理，统一转交研发负责人，由研发负责人调整工期，统一应对产品交付后的需求。

团队管理

常规团队中一般包含四个角色：架构师、项目经理、组长、组员。其中架构师、项目经理、组长为管理者或协助管理者。现实中，因为资源紧缺，一人身兼多角色的状况也很常见。对这个四个角色进行管理，就是团队管理了。

团队管理是为了提升团队效率，所以不少公司会对团队成员使用KPI(关键绩效指标法)来进行绩效考核，KPI遵循二八原则，重点关注关键任务，对普通任务进行取样计算，这样就对一些不可量化的任务作出了很好的考量标准。

不过现实中，KPI最好的应用，一般是在中小型团队，而在微型团队和大型团队中，常常会出现反效果。

对微小团队管理起最大做用的一般是领导力，而不是绩效。对大规模团队管理起最大做用的，一般是流程。不过，如今主流公司也常常采起团队切割的模式，将大团队切换为更灵活的多个小团队，来提升效率。

团队管理中，除了绩效考核外，还有一个重要部分是团队建设。

团队建设是为了实现团队最大化产出而进行的一系列结构设计及人员激励等行为。

合理的结构设计一般会让团队变的更加稳定。

好比当下流行的鱼群管理。

鱼群自己就是一个复杂的体系，是一个没有核心管理的自组织，但规则简单清晰。

鱼群的基础规则。

1，与其余鱼保持距离。

2，跟上周围鱼的速度。

3，5%的鱼受到奖励，能激发整个鱼群的强烈反应。

即，管理者利用简单清晰的规则，让高度复杂的庞大鱼群得被管理。

----------------------------------------------------------

注：此文章为原创，任何形式的转载都请联系做者得到受权并注明出处！
若您以为这篇文章还不错，请点击下方的【推荐】，很是感谢！

http://www.javashuo.com/article/p-vpibtaqx-nh.html