该帖子同步发自：(liang_193的博客  访问该博客)

一直以来，项目经理都是做技术出身的，尤其在IT这一行。于是在大家心里也就形成了一个默认的规则：选择项目经理，必定要看是否技术出身，因为其职责除了日常项目的一些管理、沟通外，最主要的还包括客户需求把握、系统框架、开发人员选择与培训、开发人员指导、开发进度控制等技术性工作。

本人，一个从未接触过开发的实施人员，在公司技术骨干缺少时，临危受命于一IT项目，担任了项目经理一职。同时，这也是自己第一次担任项目经理，在开始一切都是压力：项目计划、项目组成员、风险分析等工作如何展开，一切都是未知数，也就接受这份挑战……

根据自己以往做实施的经验，根据自己所学的项目管理知识，开始大刀阔斧的开展工作了：讨论合同、项目计划编写、调研准备、现场调研、需求确认、需求交接于开发、确定开发人员、框架讨论、详细开发、现场实施等

经过八个月的努力，带领项目组将一个100W左右的项目步入了最后正式运行阶段，算是一个比较完整的里程碑，回想这几个月来自己的工作，深深感觉到了不懂技术的痛处，总结了一下，主要有三个大方面：

1.      系统框架与技术的确定

经过项目的详细需求调研后，在形成需求分析文档时，多次与开发部主管开会讨论系统将用什么样的架构，虽然自己根据以往产品的框架写了方案初稿，但是自己对开发平台下，相关的技术不了解，在讨论时，得到更多的是问为什么这样做？一个接一个的问题让自己很多时候只能听其意见，而自己所了解的只是业务层面的操作与想法。同时有时转述的东西通过自己的理解与开发主管来分析的东西会产生一定的偏差，这样务必影响了将来系统的建设等，也即无形中给自己的风险加了一条。

根据需求规格说明书进行详细开发后，至现场实施进行修正时，技术人员需要沟通时，更多的是谈到技术上如何实现，而自己对后台实现技术不窍不通，所以有时牛头不对马嘴。

2.      项目团队组建、建设与管理

项目团队在组建时，因为开发部门同时很多项目在做，为了满足项目需要临时招聘了一批应届毕业生来进行开发，因为自己在公司时间不长，在很多地方沟通力度不够，在组建该项目团队时，得到的是别人不需要的人才，也从来没有接触过，但是自己坚信一点，无论其技术如何，先把团队融合到一个整体，团队力量是无穷的，同时想尽一切办法与公司沟通，获取其他相应的资源。

因为团队中大部分是新人，对公司的平台技术都不是完全了解，就直接拉出去现场做项目了，缺少的统一培训，造成了在现场很多任务修正时，延期。

项目团队中，大部分是新人，开发人员相对存在的个性，让团队管理变成了一场真人秀，同时自己对技术上的缺乏，造成了人员的技术工作管理、控制、交流上等造成了很多不必要的麻烦、损失

注：项目团队中，前期技术骨干赶上金融危机风暴，被卷走，后期实施中没有一个技术骨干，并且都是应届毕业生。所以项目在进行中就给自己挖了一个坑。

3.      开发时间、成本控制

对技术不熟悉了解，所以遇到开发问题或者客户的问题反馈需要讨论技术时，无法把握时间，这样造成相应的成本等都提升，这样也就自然影响了整个项目的进度等。

从整体来说，项目算在磕磕碰碰中进行中，走到了最后一个里程碑---正式上线，但是自己的未来在哪，值得深思！

所以试想未来项目中能否设立两个项目经理：一个技术方面的，一个做整体进度控制与管理？