本文以笔者所在的公司架构和笔者所了解的业内的公司架构的情况和自身实际经历的案例浅谈一下软件开发中的产品部、项目组和实施部这三者之间的关系，希望对各位在实际运作和管理中能有所帮助，并在实践中尽可能地避免犯同样的错。文章是从作者本身的角度和经历总结的一些问题，并不一定正确，借此抛砖引玉以期和广大同行共勉共同进步。
国内成长起来的软件公司都想着做产品，因为销售软件产品就象批发水果一样快速地给公司带来大量的现金利润，虽然国内软件产商包括金蝶、用友在内都不能说完全实现了产品化的软件产品，但软件产品的前景却被极度看好，而国内的众多软件开发商都是以项目的运作为生存和发展的基石和跳板，项目的成败直接决定了公司的运营利润，项目组的成员对项目的成败有着最直接的关系，一般分为开发部和项目实施组并配一个测试文档编写小组。有些有实力的公司还专门成立有研发部门。
产品部一般由技术总监、项目总监直接领导并配有固定的比较有经验的开发人员以实现产品化的软件为开发目标；项目组一般是在产品部提供的软件产品再组织项目组成员根据客户的需求进行定制的开发；实施组则根据项目组提供的程序现场更新并和客户讨论需求并制作查询报表等系列的实施工作。
笔者对产品的观点是：产品部开发出来的产品不会是通用的十全十美的产品，它只是一个阶段性的相对较完善的可以适应比之前更多更广面的一个阶段性的软件。因为我们总是在不断地进步，而且实际的情况总是不断地变化发展前进的，作为开发人员有时会提出更有前瞻性的目标，软件只是一个实现的工具而已，笔者于 2003年6月份就提出了量化的人力资源软件设计的概念和设计思想，即便到了现在，笔者手中公司团队的程序代码所实现的功能还是不能让笔者满意。因为微软从Window32到Window2000，还加打SP6。
产品部配备了公司相对较强的开发实力，相对而言也潜在着一种风险，那就是开发人员的开发能力、经验和行业经验都比较多，作为开发人员在国内目前的管理体制下会不自觉得走向尽善尽美和唯技术论，甚至不自觉而且无意识地到了吹毛求疵的程度，使得每一段程序都非常完美，每一个功能在设计理念、功能、技术、算法各方面都达到了极致，但前端实现的功能却只是比以前多了一些，如果开发团队出现了这样的情况，而预期的时间来临时，却发现无法提供当初预期中想要的产品，虽然离产品只差一步，但就是差了这么一步，而无法提供于项目组转入项目，实施部的人员只好转入产品部帮忙做测试。当然这是最差的情况了，因为笔者是看过这样的团队，因此希望大家在实际的产品研发过程当中，要尽可能避免闭门造车百花齐放的局面，因为笔者更经常看到的百花齐放的结果是负责人被更换，而应当让目标明确，并不断地修正目标，保证每一个时间点都能有阶段性的成果出来，并保证提供的产品是可用的。
当产品提交出来后，一般的公司都会让产品部开发人员再进入项目组，因为公司穷啦：）。笔者的观点是：提交的产品只是做项目的基础，产品只是提供了一些基本的当然也有一些是功能相当强的。在实际的项目运作中会有着相当多的需求变更，那就需要项目经理现场把握和引导客户，使得程序做尽可能少的修改，并尽快地结束项目，并通过项目的历练使产品更完善。
项目组的人员不要期望产品部提交的软件就象是万能机器一样什么都可以实现，更多的是只是提供了一个基础，更多的东西要在项目中完善，甚至有些模块的程序只能用其中的四分之一或更少，笔者之前就看到产品部提供的产品进项目后，结果整个模块重新开发的局面，这当然和项目经理和客户有着非常大的关系；但笔者也经历过产品部提供的三个大模块，和客户谈时全部通过的局面。项目小组的项目经理和开发人员笔者认为还有着一项任务就是在项目推进过程中将产品完善，并使项目为产品服务，笔者就经常是在做项目的过程中开发的一些模块的程序最后被产品部全部吸收作为产品中的一部分并再下发到新项目程序中。这样将使得产品和项目更快地完善，而不是产品部和项目组脱节，项目的程序最后不可控，和产品没有什么太大的关系。因为项目做完后，后期维护也是非常重要的，一旦当初的开发人员换了职位，则只有再招一批新人熟悉项目的程序进行维护，而不是一般的开发人员就可以维护大多数的项目程序。
当实施组拿到项目小组根据客户需求定制修改的程序并经过测试时，就可到客户现场更新了，因此实施小组的工作是在项目开发组完成后的动作的延续，而项目实施过程中的问题也是千奇百怪的，明明开发组那经过无数次测试都没有发现的问题而到了客户现场就是冒出了这样那样的问题，有些甚至是想都想不到的问题，就比如笔者现在在做的广东省联通项目，组织结构图客户现场出现的情况是第一次能浏览到而关闭后再进去插件就被屏蔽了，最后大家都没有办法就建议客户重装 IE。项目实施过程中会遇到非常多的问题，既是对程序的挑战也是对程序的完善，如果实施组的工作只是更新程序并制作报表查询统计的话，则实施组的人员就成长不起来。实施人员在项目实施过程中还需学会对需求的控制，要学会如何引导客户向已开发完成的软件靠，而不是客户说什么就当个二传一样将客户的需求全部传于开发人员，这样只会导致整个项目失控，因为二传传一次最多只能吸收八成，甚至需求都变样了。因此实施人员在实施过程中学会引导客户的基础是首先要对自己的软件产品非常熟悉，因为如果你都不知道你的软件是怎么运作的，那你只好当个二传了，因为笔者认为每个人都可以成长起来的，笔者在出任多个项目经理的过程中，培养了两个实施人员而现在他们也都出任过项目经理这角色。
在项目推进过程中，除了团队的团结，还需注意的一些细节问题，如团队说话的口径一致，现场需求应有一个人总体负责，也就是所有的需求口径都需经过这个人。另外有些话更要注意说法，笔者在现场时就遇到这么一个场面，在项目转入验收时客户发现了一个和他们业务不合的需求，当时实施人员就说是程序的错，说开发人员的错之类的，我则立马截止，说这是我们根据我们做过的大多数的项目中总结的这样做更符合客户的要求和习惯，而且程序中还有专门的注释说明是特意这样写的。虽然我心里比我们的实施人员更清楚这是程序的错，程序中更不可能有这样的注释，但这样的说法笔者认为会更好一些，特别是在项目转入验收期时，虽然这程序的修改量不到十分钟，大家都应当还记得余世维成功经理人中的一个关于修电梯的故事吧！
产品的成功和成熟有两个标志，一是项目的成功，二是产品的热卖。产品不修改程序并象批发水果一样热卖的场面在国内好象很少看到，所以笔者认为产品部、项目组和实施组的关系是紧密相关的，因此在开发或研发新产品时笔者认为让第一线的实施、开发人员以及项目经理还有公司内其他部门如市场、销售人员一起参加讨论以确定产品的方向，当然最后还应当由技术总监在技术上把关。
作者：郑德辉，2000年毕业后一直从事MIS软件开发，近两年半一直从事人力资源软件的开发，参与负责主持了大小三十多个项目，希望和广大同行共同交流心得经验，联系方式dhuiz@sohu.com