*职业后对项目管理的一些粗浅理解

“ 大部分的项目管理都是用网络和视频会议来处理的，偶尔也有见面处理。对项目的整体平稳运行方面，有一些想法整理一下。”

首先一个软件项目的开始是从与客户的需求分析开始的，这段时间一般都是看看客户想要做什么，一般客户都会提供一个他想要做的已有app软件。然后说我大概想做称这个样子。虽然具体他也不知道想要什么样的app，但通过交流的过程能够不断发现它需要的功能场景，业务需求。

一般客户都是想要尽快的作出一个app，这样后续的业务开展都会有基础。所以前期的功能开发可以尽可能缩减，先主要保证产品的开发速度和主要功能，这个意思不是说设计阶段的时间可以减少，我们既要保证产品的架构可以满足后期扩展性的要求，也要保证系统的稳定性。所以设计阶段的时间建议不要缩短，要留出尽可能多的时间可以充分保证当迭代了5，6个版本后可以无限接近客户最初的需求和期待，甚至高于这个期待。

但前期为了保证基本功能的使用，和线下业务开展的需要，一期要尽可能简洁，这样在编码阶段可以缩短一些时间。测试阶段也是可以缩短一些时间。毕竟，市场的趋势瞬息万变，赶在风口中推出项目可以吸引很大的关注量。如果错过风口，想要再次保持用户关注的话，所需要的各种成本都会大幅增加，而且效果并不好。

前期的设计工作，主要的功能点的设计，以及这些功能点可不可以满足具体的业务需求。当整体设计结束后，就可以采用敏捷开发了。当然敏捷开发的核心并不是只是为了快，敏捷开发的核心在于沟通，也就是这种方式的开发会不会被每一个团队成员学习并且接受。虽然敏捷开发本身会带来效率的提高，但也会有协调成本在里面。不是每一团队每一个业务场景都适合敏捷开发。这需要团队成员的自我学习和练习才可以真正达到高效的目的。另外，主导敏捷开发的领导也会是关键因素。

对于项目的编码阶段，一个项目再怎么快，都是需要编程人员实打实的敲码来实现的。所以一个项目都是会有一定的编码时间的。快的也不会快到哪里去，快一两个礼拜，那都是消耗团队精力的牺牲才能办到。这样的时刻需要吗？也需要，为什么呢？因为可以检验一个团队的抗压能力。但是建议工期还是按部就班的来，这样的牺牲的次数越少越好，从长远看，如果只为了快一两个礼拜，就经常透支团队的精力的话。会产生非常不好的影响，团队的稳定性，准确性，高质量能力都会被单纯强调速度所消耗。而且很少有因为快了一两个礼拜就获得非常大的优势，一切都是复杂多变的，一个项目的成功是多因素的结果，时间也重要，但是只要在合理范围内，不会产生决定性的影响。大多数的软件工程都不会因为一两个礼拜的时间而产生关键性的影响。

我们应该从设计阶段来减少编码时间的长度。而不是通过加班来加快项目进度。

一般编程阶段，我们不会总是提醒，监督成熟的程序员工作进度。经过很长时间的工作训练，他们已经知道了自己工作的责任范围，期限，大部分也会非常主动的工作，并在限期内完成。所以只需要在几个关键节点上把控。根据情况提醒和帮助其工作进度就可以。其实他们已经完全可以处理工程节点的完成度。

对于新进人员，侧需要更多的耐心和帮助。我们不是监督他们完成工作，作为知识工作者，我们根本没有办法监督其工作的情况。所以我们需要帮助他们在工作中培养起按时完成的工作习惯。当然分配工作的时候，也要考虑他们技能水平和经验。给他们一定的时间。也要允许他们反复犯错。但是在这个过程中，要让他们养成团队意识，让他们意识到不要因为自己的原因而拖累整个团队的工期。这是需要时间的。

最后测试阶段，可以说是整个项目中最重要的阶段。这个阶段属于收尾工作。但一个项目能从一个优秀项目变成卓越。关键就看这最后的测试做的怎么样。往往最后的%5的工作才是决定一个项目是否成功的关键。