标签：io   使用   sp   问题   c   on   cti   代码   r   

组员工作安排

忙的时候，能够协调人员分担压力(这和专人专职冲突)
闲的时候，能够穿插任务避免浪费

第一种：
以5个人的小组为例，包含一个组长+4个组员，那么可以分为三部分：
组长：负责项目方案的设计把关、质量把关，以及搜集和发现团队现存的问题和改进意见，组织讨论，确定具体的改进方案。
3个产品开发人员：负责当前产品需求的实现
1个基础建设人员：和组长一起进行团队改进方案的具体实现。
这个基础建设人员并不是固定某个人，而是不断变动的。
比如前面三个产品开发人员完成了一个选股项目，那么从三个人中调一个人，给予其时间来进行选股类项目的组件提取、代码优化。
在这个阶段他不需要参与项目开发，由另外的三个顶住当前的产品需求。
等他组件提取完成，并通过组长审核后，再加入产品开发，由另外的积累了经验的同事，进行其他的基础建设工作。

第二种：
这种方案和第一种的区别，就是基础建设人员在项目初期就开始进行组件提取、代码优化等工作，直接加入开发之中，在当前项目中就开始使用。比如这次的商城，准备让陈明根编写日志记录的功能。这种方式，要求开发的组件功能不影响项目发布，也就是说，是属于锦上添花的功能，有了最好，没有也暂时不会有问题。这些功能可以剥离开来，和项目并行开发。

工作职责

我的工作

1.质量把关
2.改进方案的设计
3.发现、引导和培养新同事和助手(创造资源)
4.培养自己的原则性和判断(决策)能力
5.业务知识的传递
6.工具的改善
7.提升小组整体战斗力
8.提醒(进度监督，包括项目、小组交流、个人计划等等)
9.统计、总结、发现工作中的问题和风险点，并提出解决方案，或者组织大家讨论后得出解决方案
10.提升团队的主动性

组员的工作

1.具体的编码工作
2.项目的维护
3.具体改进方案的实施
4.对于有意愿的同事，需要接触更多的任务

如何才能接纳更多的需求？

前面我一直认为只要我们基础建设做好了，组件积累多了，自然就能接纳更多的需求。但是从这两年来看，需求接纳量的多少，和这些内容有关系，但却不大。起到关键因素的，是人，能够负起责任的人。
接纳需求的关键，在于对需求的理解、察觉需求中合理与不合理的部分，以及将需求转化为具体实现方案的过程、发现风险与问题等等。这些靠的不是基础建设，而是个人技能与经验。个人能力得到提升，每个人才能够负责起更多的工作内容。我想这也是为什么需要如此重视培养人的原因。

我们如何才能更高效的工作？

在这个问题上，我也存在理解的误区，以为效率是看完成单位工作的时间消耗。但是最近想到一个问题：组员和主管，谁的工作效率更高？主管写代码可能没有组员快，但是我们却不能因此判定组员的工作效率更高。因为二者的工作内容不同，所以在效率的计算上，也是不一样的。高效，应该是做有价值的事情，如果仅仅只是写一些垃圾代码很快，这并不是高效的表现。

工作职责与工作协调

标签：io   使用   sp   问题   c   on   cti   代码   r   

原文地址：http://www.cnblogs.com/zhouchangju/p/4009191.html