研发项目管理问题（精选6篇）
研发项目管理问题 第1篇
几个软件研发团队管理的小问题
最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的遇到的问题，包括：
.现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
.重构会造成回退，怎样避免？
.有些开发人员水平相对不高，如何保证他们的代码质量？
.软件研发到底需不需要文档？
.要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？.当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？.如何提高开发人员的主观能动性？
其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。
1.项目不能按时完成，总要一拖再拖，怎么改变？
找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有需求要改变和新需求提出来，使原来的开发计划不得不延长。”原来如此。知道根源，当然解决办法也就有了，那就是“敏捷”。敏捷开发因其迭代（Iterative）和增量（Incremental）的思想与实践，正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷”的认同。
其实仔细想想，这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间，往往由高级管理层根据市场情况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那就是团队的生产率（Velocity）。生产率需要量化，而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的Jeff Sutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投资企业问同一个问题：“你们是否清楚团队的生产率？”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。
2.现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
这可能是很多软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读的头疼。这说明什么？排除接手人个人水平的因素，这说明旧代码可读
性、可扩展性比较差。怎么办？这时，也许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写代码带来的时间上的风险。从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的作者Mike Cohn写到过：“我的女儿们画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个明显的位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲地将它和孩子的艺术品一样展示在冰箱上，那不是很好吗？”所以这个积极的促进作用，将使得接手人感觉修改的代码是自己的了，而且期望能够找到更多的可以重构的东西。
3.重构会造成回退，怎样避免？
重构确实很容易造成回退（Regression）。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前，增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则（见《重构》第4章：构筑测试体系）：
-编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。
-考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那一部分，积极思考如何破坏代码。
-当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。
-不要因为“测试无法捕捉所有Bug”，就不撰写测试代码，因为测试的确可以捕捉到大多数Bug。
-“花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后，测试效益就会呈现递减态势，而非持续递增。
说到《重构》这本书，其实在每个重构方法中都有“作法（Mechanics）”一段，在重构的实践中按照上面所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。
4.要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？ 如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢？团队管理者需要一些手段促使其有效地进行Code Review。首先，我们采用的Code Review有2种形式，一是Over-the-shoulder，也就是2个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式，在提交代码时，必须注明关于审查的信息，比如：审查者（Reviewer）的名字或审查号（Review ID，Code Collaborator自动生成），每天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和审查者都要一起来解决出现的问题，以最大限度避免审查过程敷衍了事。
博主Inovy在某个评论说的很形象：“木（没）有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查就提交，或审查时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做Code Review就提交代码，而到年底加薪时比别人少涨500块钱。
5.软件研发到底需不需要文档？
软件研发需要文档的起原可能有2种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。
对于第一种，根源可能来自于两个方面：
-原开发人员设计编码水平不高，其代码可读性较差。
-设计思想和代码只有一个人了解，此人一旦离职，无人知道其细节。
在编码前写一些简单的设计文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提高开发人员的编码水平增加其代码的可读性，比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等，以减少不必要的文档。另外推行代码的集体所有权（Collective Ownership），避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。
对于第二种，情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。
对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、保存后，可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败（类似assert(false)的断言）的测试后，则可以通过审核。
CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。
所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：
-制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。-将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。
-使用检查列表，以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。
-使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。
总而言之，软件研发需要文档（但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时我们只需写够用的文档。
6.当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？ 这也是个常遇到的问题。如果管理者对于某个工程师的具体问题进行指导，就会陷入过度微观管理的境地。我们需要找到宏观解决办法。一，我们基于Scrum的“团队有共同的目标”这一规则，利用前面提到的集体所有权，当出现这些问题时，用团队中所有可以使用的力量来帮助其摆脱困境，而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题，比如：提供帮助的人会觉得，他的帮助无助于自己绩效评定的提高，为什么要提供帮助。这需要人力资源部门在使用Scrum开发的团队的绩效评估中，尽量消除那些倾向个人的因素，还要包含团队协作的因素，广泛听取个方面的意见，更频繁地评估绩效等等。
二，即使动用所有可以使用的力量，如果某个难题真的无法逾越，为了减少不能按时交付的风险，产品负责人应当站出来，并有所作为。要么重新评估Backlog的优先级，使无法继续的Backlog迟一点交付，先做一些相对较低优先级的Backlog，以保证整体交付时间不至于延长；要么减少部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降，产品负责人必须作出取舍。
7.有些开发人员水平相对不高，如何保证他们的代码质量？
当然首先让较有经验的人Review其要提交的代码，这几乎是所有管理者会做的事。除此之外，管理者有责任帮助这些人（也包括水平较高的人）提高水平，他们可以看一些书，上网看资料，读别人的代码等等，途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是，在每年大约3月份为每个工程师制定整个的目标，每个人的目标包括产品上的，技术上的，个人能力上的等4到5项。半年后和一年后，要做两次Performance Review，目标是否实现，也会跟绩效评定挂钩。我们在制定目标时，遵循SMART原则，即：
Specific（明确的）：目标应该按照明确的结果和成效表述。
Measurable（可衡量的）：目标的完成情况应该可以衡量和验证。
Aligned（结盟的）：目标应该与公司的商业策略保持一致。
Realistic（现实的）：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。Time-Bound（有时限的）：目标应该包括一个实现的具体时间。
比如：某个人制定了“初步掌握本地化技术”的目标，他要确定实现时间，要描述学习的途经和步骤，要通过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化作一些探索，并制作Presentation给团队演示他的成果，并准备回答其他人提出的问题。团队还为了配合其实现目标，组织Tech Talk的活动，供大家分享每个人的学习成果。通过这些手段，提高开发人员的自学兴趣，并逐步提高开发人员的技术水平。
8.如何提高开发人员的主观能动性？
提高开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业（Career），而不只是一份工作（Job）。否则，他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类（Managerial Path）和技术类（Technical Path），6个职业级别（1-3级是Entry/Associate，Intermediate，Senior。4级管理类是Manager/Senior Manager，技术类是Principal/Senior Principal。5级管理类是Director/Senior Director，技术类是Fellow/Architect。6级是Executive Management）。每个级别都有13个方面的具体要求，包括：范围（Scope）、跨职能（Cross Functional）、层次（Level）、知识（Knowledge）、指导（Guidance）、问题解决（Problem Solving）、递交成果（Delivering Result）、责任感（Responsbility）、导师（Mentoring）、交流（Communication）、自学（Self-Learning），运作监督（Operational Oversight），客户响应（Customer Responsiveness）。每年有2次提高级别的机会，开发人员一旦具备了升级的条件，他的Supervisor将会提出申请，一旦批准，他的头衔随之提高，薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”，自然他们的主观能动性也就提高了。
上面的“套路”涉及了软件研发团队管理中的研发过程、技术实践、文档管理、激励机制等一些方面。但只是九牛一毛，研发团队管理涵盖的内容还有很多很多，还需要管理者在不断探索和实践的道路上学习和掌握。
研发项目管理问题 第2篇
测试：
1、开发项目计划变更通知不到位，导致测试人员从其他项目剥离后无任务安排；——项目变更通知不到位
2、测试组处于被动告知，个别项目需求测试内容是与开发多次交流后得知，需求与开发内容脱节；——项目需求开发过程设计发生变更甚至推翻原有方案
研发：
1、能够直观获取了解前后版本修改内容的对比，便于更快确认修改的内容；
产品：
1、需求既定的情况下，并且经过内部开发技术评审，在时间允许的情况下的开发内部变更都必须互相知晓，保证开发过程中产品需求与用户真实需求的落实的一致性。
2、评审会议是内部明确需求的会议，不是产品的独角戏，所有与会者必须高度的熟悉需求及方案，评审通过后，原则上不允许变更；
3、希望研发内部也能尽量有详细开发文档的留存；
4、研发在熟知需求，开发完成之后要求自测，测试组能有一定的决策，并能对开发提测内容有初步用户体验，对不符合使用习惯或业务逻辑有偏差、样式有区别原型的功能需求提出整改建议。
5、在有产品人员出具的需求文档中，应该以需求文档为业务文档为用户需求，并以之为蓝本，进行开发，研发进行不对该需求中的方案及逻辑、规则进行随意变更；
陈莹莹
1、小池展示的原型文档相对完整，且有益于项目交接，但此文档单次输出时间较长，是否能适用于我们现有的开发流程？对开发和测试的工作是否有很大的推进作用？
2、如何解决项目开发时间紧的情况下保证开发流程的完整性？
3、如果解决开发与测试在需求评审过程中的主动性？
陈家辉
1、对已有系统业务细节无法很好的掌握，一个是历史的需求文档缺失或者记录的不够详细，第二个是代码那边的提交记录，好像代码迁移之后就没了，一些不明确的改动不知道是因为哪个需求改动的 张夏胜
1、需求评审过程中，较难的发现细节问题所在，会出现由开发提起需求变更，有时没有通知测试，造成信息不对称。
2、研发过程中，对外的对接工作出现外部责任不明确，导致研发过程出现等待和返工现象。
3、多人提测会出现版本冲突和遗漏现象。
4、WebApp开发过程中，如果以“浏览器+web工程”的方式很难对应将来客户需求和用户体验，需终端开发人员配合，改进这种搭配方案。
5、需求评审时，测试人员参与时，可以适当的提测改进意见，包括模块命名，按钮命名，用户体验等，不要在开发提测后，出现较多的建议性bug，或者在需求评审时，也动动脑筋，想想这些改动会影响到什么地方，是需求和开发没有想到的陈君耀
测试组存在的问题与解决建议
测试组存在的问题如下: 1.测试需求不明确，导致测试过程经常走弯路或者多花时间。2.工作环境太沉闷，没有学习与提高的动力。3.测试项目太单一，工作过程没有团队的感觉。
4.测试学习不明确、经验不足，没有准确的提高方向。
5.测试方式太保守、测试知识太局限，不敢或者不想接触新事物。6.测试内部沟通太少，导致成员不敢表达意见与问题。
7.项目测试安排不合理，导致参与者会测试部分模块，对项目熟悉较慢。8.测试组没有一个团队凝聚力，没有一个团队的意义（散兵游勇）。9.提测邮件的优化
针对以上问题解决建议
1.测试需求不明确，导致测试过程经常走弯路或者多花时间。
解决建议如下：
1.建议项目经理与开发人员（需求源头），先精确分析提测需求的内容与测试修改点。
2.一个项目有多个开发人员，每个开发人员只了解自己负责的开发需求，有部分开发人员不了解整体需求。（建议项目经理与项目开发人员增加沟通、建议项目中几个开发参与者增加需求沟通）
3.测试人员在测试需求不明确时主动发起需求评审，反向推动。
2.工作环境太沉闷，没有学习与提高的动力。
解决建议如下：
1.优化工作环境，测试全体成员工作过程尽量少发出“叹气”语言。
2.工作过程控制沟通音量，不建议有太大的情绪波动和瞬时高8度的音量。
3.建议每个固定（1~2）个时间进行全体休息（5~10分），主要目的有3个（缓解工作压力、增加所有成员的沟通机会、整调工作状态）。可以先从测试组试点。
4.组建学习小组，定期更新一些专业知识与测试技能。学习小组已经组建，目前学习小组负责人：邱珊珊。
3.测试项目太单一，工作过程没有团队的感觉。
解决建议如下：
1.先执行1岗双人制度，花半年时间让每个人符合要求
2.定期进行各项目内部参与者培训（时间：半年）
3.定期进行软件测试与产品测试的交互培训（时间:1年）
4.2018年培训方向如下：1.提高沟通能力，提高所有成员个人组织能力、2.提高所有成员对项目深入了解、3.提高所有成员的测试能力（测试方法、测试工具、测试技能）、4.引进自动化与性能测试。
4.测试学习不明确、经验不足，没有准确的提高方向。
解决建议如下：
1.针对所有成员历史成表现进行能力分析，给每个所有在2018年定制不同的目标（可以完成的目标）
2.测试组工作2年以下或者测试新人，当前工作状态就是测试机器人，测试过程没有太多的工作思考与提高方向。各项目负责人工作安排需要调整，给新人与参与者经常做出不同的调整，让所有人尽快了解整个项目系统。（正在引导）
3.所有成员要主动发出疑问（正在引导）
5.测试方式太保守、测试知识太局限，不敢或者不想接触新事物。
解决建议如下：
1.当前软件测试与产品测试互相不了解，在测试过程遇到对方测试知识点就要寻求帮忙。在2018年需要打破这个格局，增加两种测试的交流。
2.优化测试流程、尝试各种测试方法缩短测试时间并提高测试质量。（如下：性能测试、比较测试、安全测试、极限测试等等）
3.精确制定学习小组培训与学习方向，增加日常工作以外的测试知识。
6.测试内部沟通太少，导致成员不敢表达意见与问题。
解决建议如下：
1.固定时间开展例会活动，例会主要内容：项目完成情况、日常工作中的问题、个人组织与分享（主要提高成员组织、沟通、表达能力）
2.不定期开展学习小组活动，由邱珊珊来组织。
3.总结测试中未知或者无法解决的问题，组织资深开发人员进行讨论。
7.项目测试安排不合理，导致参与者会测试部分模块，对项目熟悉较慢。
解决建议如下：
1.各项目测试负责人或者测试主管定期考核与分析项目参与者测试水平。
2.各项目测试负责人每个月调整一次参与者工作内容，让所有参与成员尽量熟悉项目。3.参与者在测试过程发现测试阻碍或者测试盲点，需要主动提出问题。项目测试负责人与测试主管第一时间介入处理。
8.测试组没有一个团队凝聚力，没有一个团队的意义（散兵游勇）。
解决建议如下：
1.组织测试组成员定期学习与论讨 2.组织测试组成员定期工作外活动
3.测试主管每个季度分析所有成员工作状态与工作环境
4.测试主管合理的安排工作，减小各项目加班情况、平衡每个人的工作量、提高成员之间工作交流机会。
9.提测邮件的优化
优化建议如下：
1.开发与项目经理提测邮件：1.收件人：项目测试负责人、项目所有参与测试成员；抄送人：项目所有参与开发人员与项目相关需要知晓人员；2.提测内容：提测需求内容、需求对应开发人员、建议测试重点、需求预估截止日期等等。
研发项目管理问题 第3篇
一、科学规范的核算和管理高新技术企业研发费用的重要意义
高新技术企业研发是企业的核心与灵魂,也是企业生存和发展的必由之路。在技术研发的过程中,往往需要大量的人力物力,因而,研发费用自然也就成为高新技术产业的重要支出项目之一,因此,合理核算和管理高薪技术企业的研发费用,自然成为降低生产成本,提高企业经济收益的有效方法之一。换言之,如果企业在研发费用的管理和核算中出现问题,那么必然为企业带来不小的损失,甚至导致新产品研发成本过高以致企业不能盈利、甚至亏损。因此,高新技术研发费用核算与企业管理在企业生存和发展的过程中具有十分重要的意义和价值。
二、高新技术企业技术研发如何合理避税
我国新税法针对企业新技术研发推行了一系列保护措施,其中包括新型研究开发费用加计扣除计算方法等。新规定表明,企业人文、社会金额学科类的研究开发活动不属于可以加计扣除的研发费用,而对本地区省市相关行业的技术、工艺领先具有推动作用的研究成果其费用符合加计扣除条件,同时,加计扣除还需要满足《国家重点支持的高新技术领域》以及《当前优先发展的高技术产业化重点领域指南(2007年度)》(国家发展改革委员会等部门2007年度第6号公告)的相关规定。明确以上法定条款,企业就可根据条款进行相应的企业新技术研发合理避税,从而减少研发成本核算,减少不必要的开销。但这里,企业管理者要注意一点,合理避税不是偷税漏税,企业还应依据国家相关规定,对该缴税的项目和部分诚实对待,在遵守法律法规的情况下合理纳税,才是能够真正适合高新技术企业发展利国利民的合理税收管理。
三、高新技术企业研发费用核算中常出现的问题
除了税收的合理规划管理,企业在各研发费用核算的过程中,还会不时出现其他问题,这些问题同样会增加企业研发成本和研发费用,对企业的发展有所影响。以下是笔者对一些高新技术企业进行研发和核算费用分析的过程中发现的一些相应问题,希望为以后企业研发和管理提供参考。
(一)研发项目没有预算或预算的准确性、合理性难以确定
一些企业在研发项目的过程中往往会出现没有预算或预算准确性和合理性不确定的情况,笔者研究这种情况出现的主要原因发现,之所以有此类现象产生,一是由于研发工作本身所固有的创新性强、可比性差、不确定性强的特点,难以像成熟的工程和产品一样能够比较准确地开展预算;二是有些研发成果是伴随企业生产过程中产生的,是产品生产过程中的衍生产品,这部分专利技术费用无法从直接生产成本中分离;三是研发人员的知识结构、素质水平,企业的研发设施、仪器设备等技术基础条件以及受企业研发管理水平的制约,对研发预算编制都会产生重要影响。以上情形的产生和出现,直接导致企业研发过程中不确定因素的出现,为财务和经济管理工作带来了极大的困难,同时这种不确定因素也会对研究成果产生影响,大大增加企业财务管理的难度和风险,对企业的影响十分巨大。
(二)成本核算的不确定性,给费用划分、分摊带来困难,使企业无法充分享受税收优惠带来的益处
对于成本核算的不确定性以及费用划分和分摊给企业带来的困难等问题,笔者认为,主要表现在如下方面。一是由于研发项目组织实施方式、研发人员来源结构的多样性,给费用划分、分摊带来困难。二是有些研发项目的费用没有单项列支,从而无法享受研发费用加计扣除的税收优惠政策。三是企业研究开发一项新技术,往往需要很长时间,跨越几个会计报表周期,因此,对于开发成功形成的无形资产,如果仅仅以开发成功年度的开发支出计入资产,则其无形资产价值既不真实也不全面,而如果将以前年度发生的研究开发费用计入无形资产,这就要求对以前年度发生的研究开发费用进行重新计算,会给会计核算带来麻烦,若不予以资本化,则无法按照无形资产成本的150%进行摊销。特别是大的研发项目,组织结构十分复杂,在这种情况下,企业很难对项目进行有效的预算和管理,研发费用的划分和分摊状况也十分复杂,难以制定一个统一的标准,对企业的财务管理和研发成果转化也是十分不利的。
四、合理的企业研发核算管理方法
针对上述在企业研发核算问题的管理中出现的问题,笔者根据成功企业的相关经验加以分析,归纳出几点可行性方案。
(一)建立与完善研发费用管理制度
想要有效管理企业研发费用核算,首先要做的就是建立与完善研发费用管理制度。企业应充分利用自身内控系统的特点和作用,积极组织建立管理制度,并进行有效的监督,保证企业在开展某一研发项目前,准确、规范的核算其研发费用,并充分考虑研发过程中可能出现的问题,合理避免企业研发过程的不确定性,将复杂主体简单化、合理化,从而保证企业对研发过程和费用的掌控作用。
(二)加强对研发项目的预算管理,强化对研发成本进行控制
由于研发工作固有的不确定因素,应加强对研发项目在研发前期进行可行性研究,在研发投入前做好研发项目总预算;对于大额的研发费用支出,企业应加强授权审批制度;在项目实施过程中,应当根据实际情况调整项目预算,使项目预算更合理更贴近实际。必要时,企业可通过与项目组签订研发协议的方式明确相应的责任和义务。
(三)通过完善研发管理流程,增强研发项目全过程的管控
考虑研发工作在实施过程中的复杂性,特别是大型研发项目,应采用项目外部监督与内部监督相结合的方式,对研发过程进行管控。外部监督即当研发项目转化为经营成果时,可以对研发成果聘请外部中介机构进行评审;内部监督即建立项目负责人责任制,形成自我约束机制。
(四)规范研发费用核算科目设置,兼顾不同规范要求和管理需要
对《企业研究开发费用税前扣除管理方法(试行)》(国税发[2008]116号)中明确规定的费用科目,应在设置科目时按不同类别的研发项目单独设置费用科目和可资本化科目,然后分别按费用科目和可资本化明细科目进行核算。从企业利益最大化出发,制定合理的研发费用分摊标准,按研发项目正确归集费用并设置明细分类账,兼顾不同规范要求和管理需要,充分享受税收优惠给企业带来的利益。对于大型研发项目,应按项目建立备查明细账,更好地满足国家有关部门、中介机构的审核、审计和企业管理需要。
五、结语
药品研发质量管理问题研究 第4篇
【关键词】药品研发;项目管理;全面质量管理
1.起源与现状
现代质量管理起源于工业部门，产业界基于过程管理的R&D项目质量管理已较成熟。从20世纪90年代开始，国内研究机构就开始了科研质量管理体系的建设，开始认识到科研质量和信誉对于科研工作的重要性，并逐渐开始在科研工作中借鉴和采用质量管理的一些方法。目前国内医药企业的药品研发，一般是以项目管理的模式运作的，其中很重要的就是项目的质量管理，由于质量管理同时还涉及项目的其它内容，包括范围管理、时间管理、费用管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等8个方面。尽管有些研发人员认为对质量的关注主要针对产品或服务的功能，研发活动无法实施质量管理，但当研发部门采取了大量质量改进的措施，在考察具体效果后发现事实并非如此。从寻求减少研发流程中缺陷的各种方法开始，通过杜绝可见的损耗和隐藏的风险，在研发活动的成本上做出了实质性的改进，缩减了开发周期中各环节所需的时间，从而提高了整体效能。这两年药品研发项目所体现出来的问题，是在新的药品注册管理办法实施过程中逐渐暴露出来的。比如：实验设计不科学；研发实验记录不完整；实验结果不准确；方法研究草率；实验用原辅料来源随意，没有经过有效资质审查，无法溯源；实验用原辅料及各类试剂使用随意，没有相应科学妥善的管理；实验室的温湿度控制不达标；实验的规模及批次的重复上不具备实用性等。这些弊端造成的后果是实验室产品和最终上市产品的质量不具备同一性，生产不能按实验室得出的工艺条件实施，实验室处方在工业生产中不可行，结果导致按批准的处方和工艺不能组织有效的生产，给企业造成极大的浪费。
所以有必要在药品研发企业建立相应的质量管理体系，可以参照GMP和150的要求进行组织和实施，以生产出符合研发目的的产品为目标，以药品管理法、药品注册管理办法、GMP以及相关的法律法规为依据，组织研究和试验。
2.药品研发项目的流程与相应的问题
2.1在研发甄别和立项阶段，应重视前期调研，避免专利侵权和违法违规现象的出现
这几年国内出现的各类专利纠纷，如“氨氯地平对映体的拆分专利侵权纠纷”、“奥氮平专利侵权纠纷案”、“醋酸奥曲肤权利纠纷”、“江苏恒瑞医药股份有限公司多西他赛案”、“万生与三共奥美沙坦官司”、“盐酸吉西他滨专利无效案”、“伟哥应用专利中国无效案”等，都是大家很关注的案子。这些案例给了大家很多启示，专利意识在各公司也都已深入人心。产品开发前期，对药品专利情况的调研至关重要。
2.2临床前研究阶段应关注实验室记录、规范以及文档完整性
并重视实验设计的确认，组织部门的专家对实验设计的审核尤为重要，可防止发生缺项漏项，确保实验设计有效合理。药品研发的后期，形成产品的主要问题是没有经过中试或中试时间很短，产品没有生产文件或文件不足以指导生产、没有中控标准、生产现场出现问题没有相应的解决方案。有些企业希望在中试阶段解决产品的质量问题，但中试的定位与运作也很矛盾，发生质量与进度的冲突时，如何取舍与平衡。以前研发与制造的矛盾转化为研发与中试、中试与生产的矛盾，中试成了矛盾的集散点。量产后才发现产品可生产性差、成品率低、经常返工，影响发货。所发生的大量设计变更，导致研发人员须到处去“救火”。以上问题提醒我们，在研发过程中应重视中试的重要作用，在处方和工艺基本确定后，就应该进行适当数量及规模的中试，并及时解决中试中暴露的问题。
2.3临床研究阶段应注重对临床研究基地的资质选择及质量管理
前期的重点是对临床研究基地资质的审核及临床项目的授权。进入临床研究后，受试者权益、安全、健康必须高于对科学性和社会利益的考虑。临床研究基地的伦理委员不能仅限于形式，应确保受试人员的安全健康、实验数据的合法性。研究者必须严格遵从试验方案，不得随意更改；如需变更，须经伦理委员会的同意并告知申报者。应彻底杜绝研究者编造试验数据、隐瞒不良反应事件、提前破盲及改变试验结果等作弊行为。临床研究方案应由申办者与研究者共同设计完成，明确在方案实施、数据管理、统计分析、结果报告、发表论文等方面的职责及分工。申办者同时应任命合格的监查员，监查和报告试验的进行情况、核实数据等；还应建立对临床研究的质量控制和质量保证系统，必要时还可组织对临床研究的稽查以保证质量。有些申办者在临床研究中往往缺乏主动性，过分依赖研究者。如对试验方案的设计基本上托付于研究者，不懂得共同参与协商；缺乏对试验数据的监查，直到试验接近尾声也未有监查员参与试验过程；未建立相关的质量控制和质量保证系统。实验的设计、实验记录的保存、實验药物的来源发放销毁等、受试人员的原始文件等所有这些记录的建立及保存必须准确、可靠、可溯源。
2.4提交申报阶段应重视实验记录、档案的整理和维护
现在很多企业在面临现场核查的时候就出现档案资料缺损。在药品研发项目的管理方面，过程文件和记录的完整保存对保证研发活动的持续顺利进行非常重要。文件记录要有人进行管理，更改要有程序规范。加强各类管理程序和流程的建设以及关键节点的确认。做到每项工作有文件规范、有记录、有人负责、受到监控，特殊事件有审批程序，凡事都要做到可控、可溯源。
对药品研发结果的综合分析、整合与升华对提升药品开发质量也至关重要，决定了项目的质量和使用价值。申报资料的撰写、研究报告、技术资料等文件是药品开发产出的主要载体，申报资料、档案整理、成果推广等后续工作对提高今后的药品研发质量具有重要作用。在最后阶段的有效总结，发掘潜在的有价值的技术内容，也是此阶段的重要工作之一。
2.5全面质量管理（TQM）、更加关注并满足顾客需求
TQM是研发质量管理体系建设并取得成功的关键。首先是要建立全员质量意识，以规范化的工作模式开展科研工作。质量管理部门应从协助科研人员工作的角度出发，找出项目管理的不足，阐明采用质量管理的好处。通过充分的培训和自下而上的讨论，使研究人员真正对质量管理产生兴趣，从被动机械接受到产生疑问，直至开始探究质量管理的真正涵义和具体做法，并主动参与其中。这样才能真正使质量管理为科研活动增加价值。药品研发产生的成果最终直接服务于生产部门的应用需求。对于研发成果的评价，一方面（下转第189页）（上接第152页）要考虑依托企业本身的评价体系，同时也要考虑提供资金的顾客及利益相关方的需求。没有经济上的支持，研发也无法进行。这就要求科研人员能主动收集各方的反馈意见并能持续改进。
3.结论
药品研发质量管理的核心就是“事前布控，事后可溯”。关键就是有效的文件记录管理，建立可实施并行之有效的规范流程。■
【参考文献】
研发人员面试问题 第5篇
通讯系统设计角度出发，
1、 做过的通讯系统中最大的客户端有多少?支持多少并发数?
2、 如何设计通讯服务程序的软件负载均衡
3、 对地理信息系统及GPS的.了解
4、 ORACLE数据库分区表的作用
5、 写出你所知道的设计模式
6、Windows应用程序如何通过HTTP与互联网上的服务器交互数据?
7、有10000台车载终端通过GPRS无线网络与服务器建立连接(tcp/udp)，传递GPS定位信息并由服务器解析，系统该如何设计?
8、DLL有多少种?简单的描述一下如何实现程序插件
研发项目管理问题 第6篇
新产品研发流程优化与研发项目管理
2010年7月8--9日（深圳）
2010年7月27--28日（上海）
2010年8月12--13日（北京）
2010年8月21--22日（深圳）
========================
【主办单位】：上海普瑞思企业管理咨询有限公司
【学员对象】：企业产品研发部门项目经理、主管、项目组核心成员；技术部经理、主管；（副）总裁、（副）总经理、研发总监、研发组织主管项目的高层、项目投资部经理、总工程师、产品经理等及有涉及到产品研发项目管理负责人等。
【费====用】：2600元/2天/人(包括培训、培训教材、两天午餐、以及上下午茶点等)========================◇课程背景curriculum background
========================当今的研发已成为企业竞争的主战场，研发项目管理是极具挑战性的一项工作：研发面临市场、客户的压力，需要与内外部的各大部门协调，这些对项目经理和项目组成员都提出了更高的要求。因此研发项目经理的工作不仅仅是技术层面的产品开发工作，而是技术与管理相结合的工作，甚至更多是管理工作，项目经理的任务将不再是个人英雄般地拼命完成个体任务就行了，而应该是率领团队（项目组）完成整个团队（项目组）的任务。科技型企业在新产品/新服务的研发和项目管理过程中面临着如下一些长期困惑的问题：
1.如何平衡市场竞争的压力和客户多变的需求，快速将产品推向市场；
2.如何建立一个真正的“以客户为中心、以市场为导向”的研发组织体系，快速响应市场需求；
3.产品开发的过程中研发如何与市场、财务、生产、采购等相关职能部门协同工作；
4.研发资源管理中的“会哭的孩子有奶吃”、一个人做多个项目资源冲突、公司优先级高的项目在每个部门却无法保证资源优先、开始了很多项目却总是不能上市、立项评审会上为何总是问题不断
5.如何在保证产品质量的同时又要降低产品的研发费用和设计成本；
6.如何在产品开发的过程中积累技术和管理的经验，从制度上保证公司的成功；
课程在总结大量中国企业从“作坊式”的研发模式向“产业化”研发模式转变的过程中的成功经验和失败教训的基础上，提出一个有竞争力的科学的研发管理体系，同时分享业界企业在研发管理变革过程中应该注意的风险，确保企业的研发管理变革能够真正落地实施。
========================◇培训收益training income
========================★.了解如何正确地制定新产品研发战略；
★.学习选择正确的新产品项目的技术和方法；
★.探讨新产品研发项目的资本运作和风险投资方式；
★.学习如何建立新产品研发项目管理体系；
★.掌握建立和应用正确的新产品开发的流程；
★.学习新产品研发的风险控制和管理的要旨；
★.学会评价和改善新产品开发项目绩效的途径；
★.新产品研发的项目模板与工具介绍；
★.分享讲师上百场研发管理培训的专业经验，通过现场互动帮助学员理清适合自己企业的研发管理思路；
★.掌握业界最佳的研发管理模式与实践，并总结如何与公司的规模相适应来建立研发管理体系；
★.掌握研发管理的决策体系、组织体系、流程体系、项目管理体系等关键构成要素； ★.掌握科学的新产品开发流程和研发项目管理操作方法；
★.分享中国企业推行研发管理体系建设、优化、变革过程中的经验和教训；
★.分享讲师团队数十个研发管理咨询项目的案例资料（模板、表格、样例„„），帮助学员制定Action Plan，使得学员参训后回到自己的公司能够很好实施研发管理体系的优化。========================◇课程大纲curriculum introduction
========================
一、研发管理业界最佳模式及案例分析
1.“微笑曲线”的含义
2.做正确的事情（市场管理体系）
3.正确地做事（开发流程与项目管理体系）
4.找合适的人做合适的事（研发人力资源管理体系）
5.术语解释（平台－技术－产品、样品－商品、项目－产品、项目管理的领域、流程－项目管理）
6.技术开发与产品开发相分离
7.商业决策同技术评审相分离
8.产品成功的标准是什么？
9.新产品开发流程与研发项目管理的关系
10.案例分析：《我的项目为什么会失败》
二、产品开发的组织与团队
1.产品开发组织存在的典型问题
2.典型的研发组织模式：职能型、项目型、矩阵式
3.成功的产品开发团队具备的典型特征
4.跨部门的产品开发团队构成及角色定位
a)核心小组组长的角色和职责、技能、领导资格、知识、经验及实例讲解
b)核心小组组长的培养和任职资格管理及实例讲解
c)核心小组成员的角色和职责及实例讲解
d)扩展小组组员的角色和职责及实例讲解
e)职能部门经理在产品开发中的角色和职责及实例讲解
5.矩阵式组织运作容易出现的问题和原因分析（一个人两个主管听谁的、怎么考核、项目经理调不动其他部门资源、是否要给项目经理考核权重）
6.跨部门的产品开发团队的汇报模式与考核机制
7.实例讲解：某IT公司跨部门的产品开发团队的组织运作
8.演练与问题讨论：贵公司的跨部门团队角色有哪些？
三、产品开发的结构化流程
1.产品开发流程优化的方法论（Design Flow）
2.开发流程需要结构化的征兆
3.开发流程优化的“七步成诗”
4.产品开发流程如何结构化：分层分级
a)结构化流程的层次划分
b)业界的产品开发流程架构示例
c)业界的产品开发详细流程示例
d)业界的产品开发子流程示例
e)业界的产品开发操作指导书、模板、检查表示例
5.产品开发流程结构化过程中的常见问题分析
a)结构化的时机
b)结构化的程度
c)结构化容易陷入两个极端
d)结构化如何与企业实际情况相融合6.咨询案例分享：如何把产品开发变成不仅仅是研发部的事情？－流程中固化其行为
7.咨询案例分享：基于业务的研发项目管理的构造过程
8.研讨：用黄纸贴和Workshop方式完成某研发流程
四、产品开发中的商业决策（公司高层对研发管理的具体操作）和技术评审
1.企业在业务决策管理中存在的典型问题（“会哭的孩子有奶吃”、一个人做多个项目资源冲突、公司优先级高的项目在每个部门却无法保证资源优先、开始了很多项目却总是不能上市、立项评审会上为何总是问题不断）
2.产品开发中业务决策的意义
3.为什么会有领导“该管的时候不管、不该管的时候乱管”
4.高层领导在产品开发中扮演的角色（“杀贫济富”、什么时候该管、怎么管）
5.业务决策团队的角色构成与职责定义
6.产品开发中决策评审点的设置
7.各业务决策点的评审要素
8.产品开发中业务决策支撑
9.业务计划实例讲解
10.项目任务书实例讲解
11.项目管理办公室（PMO）
12.如何建立高效的业务决策机制
13.实例讲解：某IT公司产品业务决策的实际操作
14.产品开发过程中的技术评审有哪些？
15.如何建立技术评审的Check List，从而使得经验固化
16.实例讲解：某IT公司技术评审的实际操作
五、项目的立项管理
1.研讨：目前立项时遇到的问题
2.项目立项基于何处而来？产品规划？客户需求？„„
3.项目立项时要避免“师出无名”-《项目任务书》
4.项目立项时应关注“四项基本原则”
a)市场可行性
b)技术可行性
c)商业模式-如何赚到钱？
d)风险管理：定性描述
六、研发项目的计划控制
1.研发项目的计划模板如何制定？
2.咨询项目演示：计划模板同流程的关系
3.项目计划控制中常见问题和解决办法
4.项目的分层实施与分层监控
5.监控计划
a)监控点设置原则
b)监控计划总揽图
c)监控计划一览表
6.项目控制手段：项目报告
a)项目报告种类
b)项目报告机制
7.项目控制手段：项目例会
a)项目例会种类
b)例会议程和内容
8.项目控制手段：计划变更控制
a)变更控制流程
b)计划滚动刷新
9.项目控制手段：状态转移
10.项目控制手段：业务决策评审
11.项目控制手段：状态转移
12.项目控制手段：业务决策评审
13.产品规划要合理、且有节奏感
14.项目多时，高层领导从事该做的事情
15.质量管理：业务评审、技术评审
16.计划监控：演示PERT图等，找关键路径
17.计划模板
18.情景化的知识管理
19.项目资源使用曲线
20.人员梯队化
21.时间的阶段分布
22.咨询项目演示：《某家电企业的研发项目管理手册》
七、研发项目的风险管理
1.风险和问题的区别
2.风险的定性分析
3.发生概率、影响程度
4.演示：风险管理计划模板
5.研讨：定性的风险分析描述
八、如何成功实施产品开发管理体系的优化
1.如何根据企业的实际情况选择产品开发管理体系优化的三个模式（小改进、优化、变革）
2.案例分析：某IT公司产品开发流程变革失败的案例研讨
3.变革失败的八大原因分析
4.成功实施变革的关键要素
5.企业如何实施变革管理
6.如何处理变革管理中人的问题
7.成功实施管理变革的案例分享
========================◇讲师资历lecturer synopsis
★主讲专家：张永杰 先生
张永杰 研发管理资深顾问（原深圳某大型世界知名高科技企业研发管理部经理）◆教育背景及曾任职务：
==>教育背景：西安交通大学 工学学士、管理学硕士，1999年硕士毕业后先后任职于深圳某大型世界知名高科技企业 和 某生物医疗设备公司。
==>曾任职务：项目经理、项目管理部副经理、产品经理等
◆工作经验：
实战派研发管理专家，长期受邀于广东省企业联合协会、深圳高新技术产业协会等行业协会，主讲研发管理类的课程。
多年高科技企业产品研发和研发管理、产品管理工作经历，先后担任过项目经理、项目管理部副经理及产品经理等职位，在长期的研发管理实践中积累了丰富的技术和管理经验。在国内某知名通信企业工作期间，先后从事产品开发、项目管理和市场营销策划等工作，并作为推行组成员与国际研发管理顶尖咨询顾问在研发及售后服务系统推动公司级研发管理变革。
在某生物医疗设备公司工作期间，担任研发管理部副经理，任职期间有针对性地将研发管理的业界最佳实践同公司现状相结合，全面建立并优化研发管理体系。同时兼任内部讲师，具有丰富的研发管理实战经验。
后从事研发管理咨询，先后作为项目核心成员和项目经理成功完成了近20个研发管理咨询项目体系的建设和落地（含市场需求与产品规划、产品开发流程体系、研发项目管理体系、研发人力资源等模块），在产品开发流程设计、研发项目管理和体系推行方面具有丰富的咨询经验。