为你的项目加入一个阶段--技术研究

为你的项目加入一个阶段--技术研究
    --项目管理的一种“最佳实践”

摘要：以一个明确的“技术研究阶段”来提高开发效率、规避开发风险、提高项目管理的可控性，是一个简便易行的“敏捷”项目管理手段。

1、什么是“技术研究阶段”
这是我在项目管理实践中总结出的行之有效的一种“最佳实践”，技术研究这个词很自然就能理解了，“技术研究阶段”通过本文的描述也很容易理解。关键是“实践”。

2、明确一个“技术研究阶段”的动力
   * 规避技术风险
   * 提高开发效率
   * 提高项目管理可控性
这是在项目管理中实行“技术研究阶段”最原始的动力。

3、“技术研究阶段”的适用情况
有几种比较典型的情况非常适合加入“技术研究阶段”：
   * 项目中引入新技术、框架
   * 项目有复杂的新型需求（比如：未遇到过，而且不确知与实现相关的性能问题，等等类似情况）
   * 项目开发团队“以老带新”
   * 锤炼、优化已有的相关技术积累，以应用到当前项目
这几种情况是我验证并收到良好效果的，并且我认为可以适用但不限于以上情况。

4、怎样开展“技术研究阶段”
4.1 什么时候实行“技术研究阶段”
项目的开发团队一组建，或者主要全职开发人员一到位，就可以开展“技术研究阶段”。可以和需求分析并行，最好开发环境、平台等已经选定。
4.2 “技术研究阶段”实行原则
一定要明确这个阶段，参与者有明确的目标和任务，可以动用“卑鄙”的考核手段（主要是提高重视程度，而不是考核）。
目标和任务由项目经理、teamleader、资深开发人员等共同讨论决定。以老带新的情况下，“老人”为主要责任人，同时也负责指导“新人”。至于指导手段，什么结对编程等等都可以。
目标任务要明确下来，你写在公示的白板上可以，用邮件发任务书也可以，总之要让每个人明确自己的研究任务、时限。
4.3 “技术研究任务书”
上面提到，用来明确目标任务。载体可以灵活，格式要简单明了，任务、时限、责任人是核心内容。不要放太多东西。
4.4 研究目标实现手段和提交物
一定要结合眼下项目的具体业务场景。
业务场景由项目经理、核心开发人员等（团队不是很大的话最好是全体人员参加）选定典型、难点场景，不要很完整，针对估计的技术实现难点最好。
所有类型的技术研究，提交物都是一个现实开发、运行环境下的demo，不关心界面友好等等一切修饰性东西，最关心的是实现该场景的技术难点，它不必是bug free的。
4.5 “技术研究阶段”的“研究结果宣讲”
这是非常重要的一个环节，每个人，或者每个研究任务都要有一个代表，讲解自己的“研究成果”，项目组开发团队都要参加。

这种最佳实践行之有效，你也可以在此基础上衍生自己的相关手段

评论

27 楼 cookoo 2006-11-06  

cm4ever 写道

那么得诺贝尔奖的科学家，他们技术的专利，是属于研究机构，学校，或者国家？

google的制度。每周20%的创新时间，而且专利还属于员工。

技术的升华，是人才能做到的，而不是什么机构。

公开发表的科学成果和专利是两码事。当然科学家也可以选择不公开成果而直接去申请专利。
不管在研究机构还是在公司，一般都事先有协议规定专利归属和专利的优先使用权归属。

26 楼 rocwon 2006-11-05  

"研究","研发","系统"等等词被用滥了

25 楼 Arath 2006-11-03  

那个何必再国内说呢？基本无效

24 楼 cm4ever 2006-11-03  

那么得诺贝尔奖的科学家，他们技术的专利，是属于研究机构，学校，或者国家？

google的制度。每周20%的创新时间，而且专利还属于员工。

技术的升华，是人才能做到的，而不是什么机构。

23 楼 Arath 2006-11-03  

一般意义上的研究只不过是学习
带创新的...国内有哪家公司会买？理由吗，你利用工作时间发明的公司有一般专利权

22 楼 cm4ever 2006-11-03  

技术研究的成果归谁呢？公司？个人？
貌似google是从员工手里买专利？

21 楼 Arath 2006-11-03  

这个阶段是否实施取决有公司在管理面上的宽容程度.
针对个人经历的过程，觉得有几点很重:
1. 技术研究要分类，比如那些是尝试性的、那些是专业性的
2. 技术研究的人选十分重要, 一定要找对人，否则只能是浪费时间或使这个人松懈下来，从而影响整个团队的士气
3. 技术研究需要有一个合理的时间计划
4. 技术研究的结果要整理成文档、程序等
5. 技术研究完成后必须针对所有人员作一个汇报和培训，授课是一个很好的方法，这样可以最快速的将新技术推广并且也可以考核研究人员的能力
6. 技术研究可以最为对员工的奖励措施

20 楼 cookoo 2006-11-03  

dongbin 写道

在《极限编程实施》这本书说，XP确实有一个新技术研究阶段，叫做“穿刺”，不知道怎么翻译过来的。

原文是spike，所以。。。

19 楼 dongbin 2006-10-27  

在《极限编程实施》这本书说，XP确实有一个新技术研究阶段，叫做“穿刺”，不知道怎么翻译过来的。

18 楼 抛出异常的爱 2006-10-19  

foxty 写道

要加入这些阶段，关键是看
1，公司是否支持。
2，公司能否培养出这种文化和氛围。

如果上面2条都能解决，不就好办了。

没有时间？ 其实工作中，真正100%投入工作中的时间会有多少？具我所观察的，一个工作日中，如果能保证4个小时的全心投入工作就不错了，很多时间都是浪费掉了，看看新闻，收收邮件，聊聊天，什么时候再开个小差，来个没有营养的会议。 

每天只要抽半个到一个小时，就足够了。不是有人说过么“时间就像海面里的水，只要你愿意挤，总会有的”。

一般公司的老总不太会全心支持技术研究
1风险
2不信任
3压力

17 楼 foxty 2006-10-19  

要加入这些阶段，关键是看
1，公司是否支持。
2，公司能否培养出这种文化和氛围。

如果上面2条都能解决，不就好办了。

没有时间？ 其实工作中，真正100%投入工作中的时间会有多少？具我所观察的，一个工作日中，如果能保证4个小时的全心投入工作就不错了，很多时间都是浪费掉了，看看新闻，收收邮件，聊聊天，什么时候再开个小差，来个没有营养的会议。 

每天只要抽半个到一个小时，就足够了。不是有人说过么“时间就像海面里的水，只要你愿意挤，总会有的”。

16 楼 tianxinet 2006-10-19  

hedonister 写道

很多时候来了项目，动不动就加班加点的赶，哪有时间技术研究？

这个最佳实践不解决项目管理是否“正常”的问题，如果有“特殊困难”，要用这个实践还真要自己想想办法，呵呵
比如：code review也是一种很好的最佳实践，如果没时间做，怎么办？

15 楼 hedonister 2006-10-18  

很多时候来了项目，动不动就加班加点的赶，哪有时间技术研究？

14 楼 tianxinet 2006-10-17  

foxty 写道

其实我觉得对技术研究，不应该仅仅只放在一个项目的一个阶段，更应该专门成为一种日常的行为活动，作为整个项目组，或者开发部门的活动。项目初期需要，平时更需要。

yhc0125 写道

技术研究应该分布在项目的任意阶段，我感觉在项目的中后期会发现前期的设计不够充分，或者有新技术可以很好地解决问题，这时候也是很有必要让一些技术核心人员来做一些技术研究的工作

这就是技术研究这种手段的另外组织应用形式了，呵呵

13 楼 yhc0125 2006-10-17  

技术研究应该分布在项目的任意阶段，我感觉在项目的中后期会发现前期的设计不够充分，或者有新技术可以很好地解决问题，这时候也是很有必要让一些技术核心人员来做一些技术研究的工作

12 楼 foxty 2006-10-17  

其实我觉得对技术研究，不应该仅仅只放在一个项目的一个阶段，更应该专门成为一种日常的行为活动，作为整个项目组，或者开发部门的活动。项目初期需要，平时更需要。

11 楼 tianxinet 2006-10-17  

foxty 写道

...

4，嘿嘿，更能吹。。
   通过这个阶段，肯定会对一些新技术更了解、熟悉、深入。以后写标书的时候可有大大滴用处。

...

很好的扩展用途

10 楼 tianxinet 2006-10-17  

kryptonum 写道

有人带的话效果会好很多

没错，“以老带新”，结对等等，很有效的手段

fly_ever 写道

引用

可以和需求分析并行，最好开发环境、平台等已经选定。

对一个项目的技术研究，是不是在项目的开始，进行平台和技术的选型，这个时候需要对各个技术进行比较，权衡，考察各个技术实现项目需求的效果，这个时候也是应该需要对技术进行研究的吧。
因为我感觉在选择具体实现技术时，一个项目组可能在宏观上对某些技术有一些了解，觉得适合该项目，但是对更具体一点的需求，可能发现实现起来并非所想的那样简单，而某候选技术对这个的实现则更方便一些，不知道各位有没有这种感觉。
所以我觉得在选择平台，技术时也需要进行技术研究。
在项目的开发过程中，我觉得需要有一些人专门来负责整个项目的技术难点，这样的话才能很好的把握项目的进展。这是我的一些想法。

这个涉及一个“惊天秘密”了，在多个敏捷方法讨论帖中都有所披露，就是“经验”，呵呵
而且，对平台的选择也是值得研究的，在选择时，团队的技术、经验积累起到重要作用。另外还可能和需求、成本，甚至经营有关。

9 楼 tianxinet 2006-10-17  

wainwen 写道

感觉和XP中的探针试验有异曲同工之处，或许称之为“技术原型”更贴切。
快速搭建一个不依赖于业务、但是可以实现所需业务的系统框架，确定技术关键点，从而找出可能的技术风险，的确是提高项目成功率的好方法。

这是可以的。主帖并非提供一个“普适”的方法论，作为一种最佳实践，是可以根据不同情况灵活运用的，完全可以衍生。
名称是一个代号，不同的名称可能代表应用的侧重点有所不同。对照主帖的原意，“技术原型”这个名称感觉对“已有技术的锤炼、优化”有所忽略。并且在这个阶段目标和任务很具体，在涉及的技术点上要相当深入，“原型”感觉有些泛泛了。

8 楼 foxty 2006-10-17  

不错，以前在公司的时候，就是负责这部分的工作。

我觉得做这个工作有下面几个好处；
1，减少技术风险。
   很多时候，如果在项目前期加上这样一个过程的话，能够更全面把握项目中技术风险，而且会更加有把握。

2，为项目引入更合适的技术，还可以带动项目组内部的技术交流的习惯和氛围。
   研究出来新的东西，可以做成文档和PPT，每周和项目组成员交流，让大家共同学习进步。
   我在上个公司的时候，在空闲期间，会把整个team分成几个小组，然后每个小组去研究一个小的方向（当然大方向要限定，要不太泛了），然后每个星期由每个小组来给大家讲解研究的结果，然后大家来讨论，这种情况下学习的速度是最快的。很喜欢这种方式。

3，让技术人员会更有工作热情。
   不知道大家怎么认为，我觉得一个技术人员，肯定是热衷于学习新技术，研究技术的，如果公司内部，或者是项目组内有这么一个机会和氛围，肯定大家都会有工作热情。

4，嘿嘿，更能吹。。
   通过这个阶段，肯定会对一些新技术更了解、熟悉、深入。以后写标书的时候可有大大滴用处。

泛泛而谈，可能有点偏离主题，不过中心的思想还是一致的：）