项目管理那些事儿

        项目管理首相要讲的就是管理二字，其实更多的PM我所经历和接触的都还没有脱离技术圈子，于是产生了所谓的项目指导，或者本身对技术没有追求或者缺乏技术经历的，更应该被称为项目委派，前者细致到已经提开发人员想好了技术细节，后者则是搞懂需求后一股脑的告诉开发人员，至于实现细节—放羊。

        当然，也还有一些人过于执着于一些形式化的东西，听说极限编程很好，于是极力按照细节行为去做云云。我抛出问题，绝没有讽刺的意思，其实出现上述问题都很正常，有些是迈向务实正确的大道上必须经历的路程。好的，有志于做管理的同志们，首先要回答自己这个问题：做项目管理到底是为了什么？

        控制项目，架构，人员安排，跟踪…

        项目管理其实就是一个目的：在项目成功交付的前提下，控制成本。说白了，就是钱。很多对于技术和管理有追求的人可能会有些反应不过来，很正常，大家都是做技术的，总习惯将自己的圈子看的很重要。做项目的载体是公司，公司的目的是什么？赚钱，你能通过项目管理做好项目，控制好成本你就能给公司赚钱。

         所以说做好项目管理首先你要跳出技术圈子，站在比项目本身还高的角度来理解问题，这个管理才算你半只脚买入了门槛。懂得了这个道理，你们就会正确的理解，所谓的OOD，OOA其实不是什么技术的升华，其实是成本的要求使然，期限编程云云其实都是为了通过灵活以及反复测试机制降低项目的风险，提高交付质量进而赚到钱。所以理解开发模式的核心在于理解这种模式解决的问题是什么，基于此再来使用，基于国情基于项目实际情况加以删减和修改，做IT的人很容易被人识别出来，因为他们的圈子更多的积聚在技术上面，这一点可以说做技术的一种局限。

         回到操作层面，我们到底要管理什么呢？我的角度，三方面：客户，项目，开发人员。做管理是一个接口岗位，其上是客户，提出需求的人，其下是开发人员，客户的需求如何贯彻到开发人员取决于你这个项目经理的分析和调度。对于客户，首先不能带有感情色彩，有的人鄙视，有的人敬畏，其实他们不过是拿钱免灾的人，对于他们应该采取的策略就是打拉结合。所谓打，就是对于他提出来的超越系统之初定义的需求一定要回绝坚决，最好找出足够充足的理由，比如逻辑上的不通，拉长工期导致项目质量问题云云，或者和他们谈二期。拉就是尽量和他们维持一种比较友好的关系，说实在的，小型民企不知道，中大型的民企和国企的接口人，你想要和他们维系一种良好的关系，要么你身上拥有者一种江湖的匪气兼具一种睿智，要么就是在某些领域专业的让他五体投地，每个人都有自己的气质，不要生搬硬套，我见过各种类型成功的项目经理。

        项目经理需要分析，需要思考。作为高层不需要做实际细节工作，但是却要求在高屋建瓴提出各种框架性的东西作为下层人员的指导，这种框架性的东西是真正开创性的东西，将一些抽象的，零散的东西整理归纳层可实现的，系统性的东西。做系统项目，首先是要有一个系统性的思想作为基础，开发出来才会系统。客户说希望点一个按钮出一个报表，你要抽象出来报表生成功能，这个生成功能相匹配则是计算，数据获取，计算需要规则，获取需要数据源等等。项目经理自己首先要把这些捋顺了，对于下面才有指引。

        从客户，需要一个项目分析作为过渡，到项目本身的管理，管理是一个很泛泛的概念，大而空洞的说教，但是也是包罗万象，看你的体会了。IT项目管理有几个主线一定要有，并且形成文档：

1.       计划。一个详细的计划，所谓详细我认为应该细化到天，一个以原子需求为单位的计划，计划是让人遵循的，但是不是死的，而是不断调整的，有新功能，新任务，添加，调整，大家至少要知道当下我们的目标怎么样，而且作为领导一定要有一个重视计划的意识，这种意识要让下属深刻的体会到。我从来都是反对团队加班，每个人负责自己的任务，能完成为什么要加班，没能完成任务，在分配时没有提出异议，就需要加班，经理安排任务要考量，成员接受任务也要评估。

2.       里程碑。计划是让大家知道任务量，里程碑则要求大家知道执行任务的阶段性时间点，里程碑之前的任务可以拖延，但是到了里程碑这一天，必须要完成指定任务，如果提前没有提出异议，那么责任就在完成人。

3.       项目人员架构/角色。项目比较忌讳扁平式，上面一个PM下面一群PG，这说明什么，职责都在PM这边，要么PM管的真的很多，要么PM实际没管什么，这两种结果都可怕。至少一个人负责技术，技术的解决方案，核心代码；至少一个人负责共通代码，他一定要十分熟悉共通代码，当有人想要向共同文件比如Helper文件添加方法时，必须要通过这个人，确定没有类似的方法再添加，一定要控制住代码的体积，减少冗余，项目的混乱多半源于冗余。一个人控制存储过程，这个人需要非常熟悉了解数据库中的存储过程，添加过程要加以指导，否则SP的庞大和实现方式的不经济也是项目糜烂的重要原因。至少一个人负责页面UI。可能项目的类型和要求不一样，核心分内容和模块也各有不同，大家根据自己的情况进行设置，总之一定要有人负责重要部分，有角色来承担责任，否则放羊，项目越到后来越可怕（短期项目可能还好说）。

        上述三点是必须开会指定的，有权才有责，清晰才有遵守，如此这个项目的管理框架算是搭建起来，所谓框架，就是大家都去遵循的准则，框架内部提供某种运行机制，对于遵循的行为产生结果，项目架构如此，管理架构亦是如此。

        管理另外一个方面就是开发，开发也要遵循一定的框架，首先就是技术框架，这个是硬框架，这个我就不多说了，那是架构师的事情，开发的软框架就是“约定”，一些无法依靠框架来实现的，这里我只想强调一件事情，就是，一定要重视第一本程序，第一次功能实现。首先是页面样式，第一本做出来的是以后大家要去模仿的，某种类型功能的第一次实现也是大家要模仿的，一定要开评审，或者一定要和负责技术的人沟通好，设计好，什么是项目的基础，第一本程序就是基础。

        项目是人干的，那么到了团队成员这个层面，这里对于团员我觉得关键要搞明白三个问题：

1.       什么时候该做什么事情。这一点通过订立计划和里程碑可以实现；

2.       怎么去干。我们创建的责任人制度就是要让一些人负责指导和规范的职责让他们知道项目的功能需要怎么来开发；

3.       为什么要这么干。这一点就有点培养人的意思，大家做一个项目一定是要有所获得，而且要知道为什么，通常都是需要交流，组织一些培训或者座谈，还有审核流程，这些都可以将信息在团队中流传。

        洋洋洒洒的写了一些自己的经验心得，有些可能说的有些抽象，知之者一听及明，不知者可能还需要一些经历，不过这些都是成长的过程，很多的问题我是在探索之中，欢迎大家互相讨论，抛开理论的焦灼，一些实际问题更有意义。