前言
前一篇文章讲了在 项目开始阶段，作为一个信息系统项目经理应该做好哪些内容，这一篇我们继续聊聊在 项目开发阶段，项目经理又需要做好哪些事情呢？_
二、项目开发阶段
在 项目开始阶段 ，你已经明白了要做哪些事情，也清楚了你手上的筹码以及你做这个项目的总体策略，就可以进行项目开发了，在这个阶段，作为一个做好一个信息系统项目经理，需要做好哪些事情呢？我的体会主要有以下几点：
1. 首先是成立项目小组，组建开发团队
成员的组成根据企业的规模和项目的不同，相差较大，很难有什么具体要求，大企业或者比较大的项目，成员配置会比较完整，比如有项目经理、行业专家、产品经理、系统分析员、系统架构师、美工、前端工程师、后端工程师、测试工程师等等，在中小企业或者比较小的项目，就享受不了这种待遇了，往往项目经理加几个前后端技术人员就是标配了，有时候还没有前端工程师，团队里每个人都需要身兼数职。
但是，不管怎么样，成员里一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家(Industry expert)，这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。
我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。
其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，所以要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，要多劝告我们的技术人员心平气和一点吧。
2. 其次是选择技术。
其实技术没有太多的选择余地，当前比较流行的高级开发语言如 Java、C# 等都大同小异，可能它们有各自侧重和擅长的方向，但基本上无论选择哪一个都能实现客户的目标，所以一般是团队熟悉哪一种技术就选择哪一种。
当然，要说没有太多的选择余地也不太正确，因为每一种技术都有新旧版本，我的建议是尽量选择稳定的旧版本，而不要选择最新的版本，因为最新的版本相关文档比较少，里面可能有些 “坑” 还没有被测试出来，用的人也不多，有时候踩到 “坑” 时，真的很难找到解决方法，很耽误进度。
在这一方面上，我是有 “血” 的教训的，很多年以前做过一个广交会的项目，当时微软新出的 Visual Studio 2003 有一项新技术叫连接池，微软当时在发布会和官方文档上极力推荐这项技术，认为是提高性能的不二之选，所以我们的项目组采用这项技术，项目顺利地开发完成了，也顺利地通过压力测试和验收，但没想到上线的第一天，程序就挂掉了，我们的技术人员认为是并发压力太大的原因，但诡异的是，服务器的 CPU 和 内存的占用率都不高，技术人员调试了很久也找不到原因，最后只好宣布项目失败，直到后来 N 年后，在另外一个项目也出现这种问题，偶然间才发现是连接池满了没有自动释放的原因，但当时真的怎么也没有考虑到这方面。
一般技术人员都喜欢钻研技术，展示自己的高超水平，所以他们总是倾向于采用最新的技术，作为项目经理的你一定要坚决杜决这种风险，当然，这需要项目经理懂一些技术，如果不懂，就比较被动了，只能依赖团队中比较成熟的技术人员的意见。
在选择技术上，问题也不全是来自团队内部，有些客户比较懂技术，有时候会被某种新技术打动，坚持要你采用那种新技术，这时作为项目经理的你就应该说服他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。_
3. 控制好项目进度和开发时间
合理分解工作任务是有效控制开发时间和项目进度的前提，有条件的话，可以找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作，比如项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里就是怎么做的问题。
在分解工作任务时，有一点是必须要注意的，就是最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查，又比如我见过一个计划，里面有一个任务【开发人员调研熟悉 Elasticsearch 搜索引擎】，这个任务，调研什么程度算熟悉，结果也很难被检查。所以，时刻考虑如何检查结果，是分解工作任务时一个重要的考量。
采用一个项目管理工具会让你的工作更加明确，比如 Jara、Worktile、禅道等之类的工具，通过这些工具，可以更清晰地知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。
按照我多年的经验，分解工作任务和评估时间之后，在项目管理工具上往往会惊奇地看到，甘特图上项目的结束时间通常会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的），所以需要想方设法进行时间控制，优化任务路径和加班是通常会使用的方法，但是加班太多会使团队成员变得更疲倦，长期来看不一定真的能提高工作效率，而任务路径再优化也不太可能把所有的工作任务安排到计划的时间结束，一个有效的方法就是对任务有所取舍，列出任务的优先级，集中精力完成优先级高的任务，对于优先级比较低的任务，可以考虑牺牲它们的时间（也意味着质量），比如有十件事情，如果什么都赶进度，其结果可能就是十件事情你一件也没做好，但如果按照任务的优先级投入资源，结果是有三件做成了精品，三件完成，还有四件因为某些原因延误，这样的成绩单就靓丽了很多，所以正确排列事情的优先级也是一个项目经理能力的主要体现。
如果提高开发效率？我的体会就是采用敏捷开发效果会比较明显，每天10 - 15分钟左右的站立会议会让团队成员的工作目标更加聚焦，可以每周或者每两周设置一个 Sprint，每隔一段时间就有成果出来，这样对于团队的士气会是很好的激励，对客户和公司领导来说，时不时就能看到成果，也是一个好消息。
另外我插一句：我是极其不主张到客户现场开发的，尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的），我的建议是软件开发人员还是在公司做项目，项目经理和项目实施人员到现场与客户交流沟通，做好客户和研发人员的桥梁，这样会比较和谐些，效率也比较高，我曾经见过一个公司，很喜欢让技术人员到客户驻场开发，结果人员流失非常严重，项目还没完成，人员已经换了两三波，这样项目进度肯定是要延误的，项目质量也不高。
未完待续
