『讨论』研发项目性质的项目如何管理

终于有人开始论到正点上了，公司的组织架构其实不是我这样一般的teamleader所能改变的了，人在江湖，身不由已，只能是基于这样的背景来为公司、为员工做一点事情。

我从程序员上打拼上来，感感觉到一个team leader不仅要为公司负责，也要为程序员负责，不能一味保官要职，为公司从命，来压迫程序员。

真心的希望大家来能自己公司如何考核，如何激励的作法拿出来，让我也长长见识，我再也不想做那些没有操作性的考核指标了。

   说的好， 我提问的方式以后要向各位学习了。

我佛慈悲，楼主有一颗慈悲的心，善待下属，善待公司，你会收获善果的。:)

你是leader的话，一切都在于你的言行，对项目的把握。公司其实在考核的是你制定计划与执行计划的能力，下属的状态也在于你把握工作量，掌握进度的能力。用什么考核方法，如何激励，都是术，teamleader对项目对成员对客户对自己的把握能力是项目成功之道。另外补充楼上关于考核的建议，不是所有人都可以用物质来激励的，考核也是双刃剑，在没有把握的时候，不要轻易在管理上“创新”。而大多数时候让事情按照计划稳步前进，逐步达到每个里程碑是对团队最好的激励，不需要什么奖金，击掌相庆就可以了。

回头来说项目，其实你这个项目应该适合用传统软工模板来做，原因是航空公司的业务流程刚性很强，团队面临的挑战恐怕是没有一个人接触过行业领域的知识，可能的问题是理解不到位而造成的需求变更，这个多少是可以控制的（大多数被折磨的死去活来的团队是因为从开始到结束他们都没有彻底搞懂客户要什么，更要命的是客户可能的确不知道他自己要什么），拉客户专家进来，自己的人进去学，方法都不少。软工模板最大的诟病不是烦琐，而是跟踪变化的代价太大，而你这个项目算是比较乐观的，大概重量级的大虾说你的项目没有创新就是这个意思。

而对对那堆新名词的的提问方式多少让人不悦， 按照软工模板，那些框架的应用应该在足够迟的时间才考虑吧？ 用的顺手就用呗，不顺手或者担心吃不透就放放，又有什么关系？

至于测试驱动和敏捷方法，个人觉得应对需求不确定的时候最有用，面对无法确定的变化，最大限度保护已经做过的事情/现有的成果不会恶化，以快速叠代的形式把需求/程序逐步具体化。而你的项目有不这么做的理由，但敏捷开发里的工具和方法，也许你可以用在分析/设计阶段，加快团队的学习速度，尽快掌握用户业务逻辑。

可以用完成的任务来考核吧,把计划的任务细分,然后向大家招标.事前把任务的评价准则说明清楚.
事后根据任务完成的质量,时间等进行考核,一个任务n个工分.最后按工分给绩效.
重要的是要提供一个简单,持续,正向的回馈.

我没有管理过研发型的团队。
但根据楼主所言这应该是一个外包项目，对吧。
为别人做事，有一点很重要：
老板去关注交易金额与利润的问题；技术人员(项目经理在内)关注项目质量问题。

1、作为外包方(客户方)：严格的管理、严谨的文档、明确的里程碑这些是项目成功的保障，因为在东西出来前，客户如何评估你的工作情况？难道指望客户会说“好，你们去做吧，明年的这个时间我们来评估一下”
2、团队内的氛围是项目经理要去控制的，使用自己的权力为团队成员创造条件，不能说客户的要求不严，氛围就会好，压力就会小，这完全不是一回事。成员12小时工作还有保持高度热情不是不可能的。
3、考核是比较复杂的问题，建议项目经理评估与团队评估结合起来。分配的工作根据水平高低是有关系的，工作量+难度系数，不要总根据工作有没有完成来评估。


我们公司最近也把一个项目外包出去了，我做客户方项目管理(我这个项目经理就是什么都懂，但什么都不精的那种)，项目现在还没有完成，1/2进度的样子，感觉过程中的几个矛盾在于：
1、有时承包方会让客户需求左右了技术框架：我觉得这很危险，因为客户对技术的了解不够，客户不知道自己提出的需求(有可能只是一个非常不起眼的功能)，对框架的影响会有多大。所以承包方的项目经理应该负起这些责任
2、我本来要求现场开发，但承包方认为Sohu式的非现场开发也能保证工作质量。但半个月下来，做阶段评估，离要求还差很远。不是说不现场就不努力工作，而是沟通不及时，目标就会偏差很大，会要浪费更多时间来校正。
3、让客户知道如何尊重技术，但项目经理也要让团队知道，如何来尊重客户。

好多讨论，都看不完了。因为好像跑题的更多。

说说我的看法，希望对你有所帮助，也希望你的反馈能对我有所帮助。

目前我带的项目大部分是研发性质的，为此，我也好好思考过类似的事情。我觉得有几点比较重要：

- 让我们的程序员具备使命感
为什么google的产品总是能做到极致,他们每一个项目都具有一定的使命感，比如承担中国书法发扬之重任，等等。虽然很虚，但团队文化里面，本身就是虚实结合的。我们的使命是什么，是什么高度，往往根本的指导我们的决心。

- 清晰的目标
研发往往我们只能设想出一个目标，一个场景，至于怎么实现，如何实现，我们都不知道。也许有很多路可以走，也许根本就是死路，我们不知道。于是，清晰的目标则指导我们前行，要让每个人都清晰的理解目标是很重要的。不管是程序员还是其他人员，用一句话，能清晰地说出我们最后要什么，不要有技术名词，不要有二意性。而且，要每个人都记得住。出去航海至少得配个指南针吧。

- 结果管理为主，里程碑管理为辅
研发往往就是去走我们认为能走通的路，也只是认为而已，失败的可能性远远大于成功，所以时间和成本往往很难估计。但是，结果管理就显得突出，方法大家都不知道，但能拿出结果来的一定是最有说服力的。而阶段性成果会让我们知道这条路是不是死胡同，让我们逐步揭开谜团，揭开的每层纸都值得祝贺。

- 分享式的沟通
参加过安利的培训课吗，那就是分享式沟通。每个问题都有可能成为一颗炮弹让整艘船沉没，如果这时命也无可厚非，如果答案在身边，只是没有想到，那就太冤了。团队的每个人，每个小角色都身背不同的经历(否则他们也不会进入这个组)，任何人都会有奇思妙想，也许能帮助团队解决问题。永远不要忽略任何人的任何想法。

- 开心的环境
你的老板决不会因为你的项目性质给你的兄弟们加薪，所以，我们要创造好的环境给他们。开心，是很重要的一点。不开心，谁愿意受这个罪啊。所以，我们的团队中总是会有搞笑的事情出现。像，人品不好啦，显示器上挂大悲咒会没bug啦，你写了一个跨平台的病毒阿等等。当然，要把握住火候，不能让团队具有优越感，否则团队会背离生存的环境，那绝不是职场上的好事情。

however,xp中有很多好的实践，会有很多帮助，可能这些都不在书里面写到，但tw的项目组就有好多，当然我看到的也许只是冰山一角。

以上思考，趁这个机会写写，省得我回头就给忘了。也希望对你有用，也希望对我自己有用。

ps:我也看过类似电子客票给市场带来的冲击的文章，虽不多，但也能感受到这个行业将会有翻天覆地的变化，为此5/1还亲身体验了一下。这应该是个好机会，对你，对你的兄弟们，希望你的系统能让我以后不再买如此昂贵的飞机票了。加油.

所谓项目经理就是老板和程序员之间的buffer和润滑剂，老板还没有信任你到把任务交给你就等到时候收钱也是有情可源的。他需要什么样的information你给他就是了。老板的压力是需要你来抗的，程序员的宽松环境是需要你来创造的。

哈～真是热闹，也随便说两句，不对的话也请不要介意。
1.看的出楼主是个真正想做事的人，这很关键，是成功的基础。
2.看的出楼主是刚刚担任项目管理的人，如果是的话，我建议首先对自己的定位要准确，别把管理两个字看的太重，重要的是组织，协调，帮助和服务，让每一个同事都快乐的发挥他的长处。说白了，项目管理不是官职，那种心态不能要。
3.多跟客户交流。
4.让老板相信你能很好的完成任务(这是他最关心的)，至于细节请老板不要过多参与。
5.了解每一个人特长，并真心的相信并依靠每一个成员的努力来完成这个项目（说来容易，做好很难，但很重要）
6.如果你技术好，一定要跟团队沟通，分享，如果技术不好，一定要给技术好的同事充分的发挥空间。
7.任务要分阶段，把每一个的目标告诉每一个成员。每一个阶段成功交付后，要把阶段性成功的消息告诉每一个成员，这时要有个小小的庆祝或休闲。
8.把握进度，有张有弛，必须加班的话，时间最好由每一个成员自己定。做好加班时的辅助工作。


顺便说一下，我说的是一般的项目管理，不是研发类的，因为我觉得你说的这个项目的确不属研发。

每个人对研发的定义似乎都不同，楼主说是研发项目并不为过。我同时在做普通开发项目，以及研发项目，说说我的看法。

假如楼主的团队完全没有所要开发的系统的经验，当然，包含业务上的和技术上的，但偏重技术，且对项目目标不能有效识别，或者项目风险远超过组织其他的项目，都可以界定为研发项目进行管理。

在管理上，我们的研发项目是区别于普通项目的工作程序，但明显楼主这个时候是被工作程序限制的。在这个时候需要做的是，和BOSS讨论争取支持，获得更多的对项目过程的控制权。顺便说一下，我们的研发流程是强制做迭代的，而普通项目是不规定的。

在绩效考核上，如果没有研发的考核经验，在初期的考核设计上，可以减少区分度，使团队成员都有获利的机会，然后在项目进展中逐渐修正考核方式，当然，这个绩效考核的改进，最好是给BOSS单独提供一个时间表。其实，这个时候你可以在这个方面和BOSS提，属于管理创新方面的，一定要获得BOSS的支持。所谓减少区分度，比如，可以采用比较感性的绩效考核方式，比如工作积极性，团队沟通能力等等，在你没有办法量化工作项的情况下，可以先缓一缓。当然如果你是激进性的管理风格，开始的时候也可以尝试进行量化。
补充：开始的时候减少区分度的原因还有一个是:国人是“不患寡而患不均”的。

最近比较流行老贴新顶阿...