项目管理的繁杂

项目管理是一个非常综合的任务，里面用到的东西非常多。简单的打个比喻，如果纯开发工作是一个单线程的工作的话，项目管理是CPU的工作。CPU对比单线程的话，它强大之处在于可以包容多个线程，强大的调度能力。这也就是为什么从高级开发转向项目管理的困难之处，不仅仅是工作内容的重塑，还要重构思维方式。

现在的项目在进行过程中总是分阶段并且是分工的。项目分阶段进行，这说明项目本身也是一个比较复杂的任务。通常我们在做一件事情的时候，都是要分步骤处理的，尽管有时候我们没有注意到。项目参与的人很多，基本上也做不到有人可以知晓项目从头到尾的全部内容，从立项到代码，从测试到维护。随着越来越多的技术加入软件开发当中，随着业务规模的逐渐扩大，分工扩大化是无法避免的。这样就出现了现在项目当中懂业务的只了解业务，懂得代码的只知道代码的相关技术，懂得设计的不知道最后代码的细节和业务的成因，懂得测试的人不知道代码的具体逻辑等等，这些分工越来越细化的趋势非常明显。人的精力是有限的，为了满足要求就必须要更加的专业化，更长的学习时间。

为了保证项目的正常进行，需要有专业的客户代表，需要尽量模拟用户的使用场景。客户代表是使用项目服务的人，但是不是全部，怎么去选取客户代表却是一件超级麻烦的一件事情。无论采取随机抽样，分层抽样等等抽样方法，客户代表也是不可能覆盖到用户整体情况的，只能覆盖的一定程度。同样，不使用这种方法，采用假想方式生成用户需求的话，虽然看上去是减少了费用，不过却提高了项目的失败率，因为我们毕竟不是真实的客户，其心理状态、生活习惯等等因素相差很大的。模拟用户场景同样可以帮助我们进一步了解需求存在场景，找到隐性的一些需求设定，这个地方也是存在不可控因素的，模拟场景不是真实场景，可能在模拟场景时丢失了某些关键要素。这是来自客户方的风险，可以想办法去降低，但是无法消除。为了应对客户方存在的问题，系统分析的人来了。

从客户方得到需求之后，要进行分析和设计。现在技术发展速度越来越快，真正的可以把控全局的设计架构人员需要明白各种技术的优缺点，合理的组合技术并预留出技术的进步空间，制定出满足约束条件的架构，并能根据项目进行过程中约束条件的变化，调整框架，要求也越来越高。可惜的是国内好的技术人员大多被转到管理上了，而且是每当技术熟练了也差不多被推到管理岗位上了。这样也导致了有设计理念的技术人员在国内环境内也在减少。假如有这样的人，我只能说欧皇附体了。为了应对设计和架构的问题，设计架构的人来了。

拿到设计架构之后，具体的代码实施则需要程序员了。这个时候的工作量和进度其实是不可控的，如果客户方和设计架构师做的好，那么工期缩短并且进度加快，如果其中有一方做的不够好，进度和工作量基本上控制不下来。例如整天变来变去的需求，同一个需求今天加点这个明天加点那个，这个是客户方其实不知道自己想要什么。项目的架构今天出点什么问题，明天来些高并发的宕机，都是一些相当棘手的问题。假如前两步都很好，代码的实施工期还比较明确，如果没有人事给你往里面注水的话。实际上，在代码实施环节，不是每个人都能保证代码质量的，代码写的难读和bug一大堆的情况很多，这里是实施的最后一米，也是项目当中背锅最多的地方。其实这里出现的问题真正归属到代码上的很少，如果有也是因为这里是离客户方远的地方，沟通的效率决定了程序员对需求的理解与客户方提供的需求是有很大一段距离的。在项目代码实施工程中，一定要让客户方代表和程序员可以进行沟通。很多项目都是死在程序员见不到客户方的情况下，创业公司尤甚。

项目开发完成之后进入测试期，这个时候需要测试人员了，尽量保证测试人员不是当前测试功能的开发人员，除非要做白盒测试。测试案例的编写时需要详细的需求文档的，如果有客户方配合那就更好了。测试案例的步骤则需要跟设计人员沟通，如果满足不了，可以询问开发这个功能的开发人员去确定。测试人员的技术入门门槛实在是低，但是需要的沟通能力要比开发人员要高。其实这些都不是关键，关键是为了节省当前的费用没有测试人员，全部使用功能的开发人员测试其开发的功能。

项目的复杂源于各个环节的分离，分离的原因多样化的。这种分离会提高项目的规模，也会导致繁杂程度的提升。分离导致了瀑布模型的不适与对各个分离层级实时沟通的渴望，发展出了满足分离之后沟通需要的各种软件开发模型，迭代、螺旋等等。

Note:如果一名开发人员想转向管理，需要的条件如下：1.对要管理的内容熟悉；2.对人员的工作能力有很好的评估；3.会分解工作内容；4.会验收工作内容；5.沟通与获取外部资源。这些条件当中有些条件是可以在转向之前提前准备好的，有些则需要在实际工作中锻炼。