我带领小组产品开发的阶段性总结

[collioner]

7月以来，我们小组（算上我，就4个人，：-））开始开发一个产品，产品不复杂，需求比较稳定，我是第一次带队开发，还算顺利，没到一个月，第一个版本就出来了，今天写了个总结，大家帮着看看，望多提提意见和建议，谢了。
1、 在需求分析、设计和开发的过程中，通过小组讨论，列出所有需要完成的活动，区分出重点和难点，确定实现的优先顺序，统一认识，先啃难点，扫障碍，再实现那些必须而重要的功能，“抛弃”那些不关乎全局的功能，确立第一个迭代计划；
2、 通过小组会议，建立一些小的（时间间隔尽可能短，比如3天左右，不能太短，否则增加成本，也不能太长，否则无“警惕”作用）里程碑检查点，分配每个成员在里程碑结束的时候应提交的有明确要求的“成果”，让每个成员分别负责不同方面的任务。
3、 每次小组会议结束的时候确定下次会议的时间，检查的内容，以及要达到的目标。
4、 不要陷入写作文档的泥潭里面，文档是要写的，但关键是写什么，应该写那些总结和固定上一阶段成果，同时对下阶段开发有指导和参考的内容，需要说明的是，写作文档的过程本身就是整理思维的过程。
5、 先定义，后实现：一定要先定义清楚接口，功能说明，通过小组内部评审以后，再逐个实现，实现以后，小组再找个时间，一起来回想对比一下，设计和实现的差距，以及今后如何避免这些差距，通过这种不断的反馈，大家的经验值就提高了。

[zhf_karen]

恩，在项目过程控制方面作的比较细致了。

不过，有一点感想，提出来：如果仅仅为了汇报成果，和布置新的工作任务，我倒不倾向于开会议来完成，特别是项目中需要频繁地开会的。原则就是：如果不需要大家所有人的讨论，那么就不开会，如果没有发生大的问题，那么就不开会。

一般工作的下发和工作成果的回收是通过邮件完成的，工作任务如果有可能，可以建立一个公用的东西，让大家随时能够看见。回收工作成果，通过邮件通知所有项目组成员，可以激励人员信心，同时，及时提出所需要的支援，拉近团队成员之间关系。然后，从版本控制中，取出最新版本，打上版本信息以后，提交测试部门就可以了。

因为一般小型项目的会议还可以接受，但是，中型以上项目，在这种工作上，也采取会议，有点浪费时间的感觉了。毕竟，我们期待自己成为一个合格的项目经理，而不仅仅是一个合格的监工嘛。

[collioner]

我也在思考会议的价值。
其实我的初衷是希望，大家明确下阶段目标，清楚各自的任务和要求，明白自己在项目小组中的角色和作用，无形中也算一个在大家面前的表态，产生一些压力和动力。
我今天下午就要开一个会，是关于，1、代码走读的，找出几段典型的代码，看存在的问题，包括编程规范等，2，以及讨论设计和实现的差距的“反省”：为什么当初的设计无法完全在实现中贯彻，为什么在实现的时候要改动以前的设计，改了哪些设计？下次我们如何能够更好地做设计使得实现的时候少做修改？

[zhaoxichao]

2 中不能叫做里程碑检查点，只能算是例会评审什么的，一个里程碑一般是某个软件产品完成了一个稳定的版本
好像没有涉及到风险管理

[collioner]

可能不是一块真正的石碑，暂且算是在一段路途中的某个点放置的一个小石头吧，我觉得设置这些小的检查点很有好处，大家对要完成的任务，以及要求都“心知肚明”，而且完成以后还很有成就感。
关于风险管理，我记得刚开始“筹划”该项目时，我列了不下40项风险，包括技术风险、业务风险，市场风险、政治风险等等，公司也说找市场部给我们配合，可实际下来，他们没帮上什么忙，反正是老板说做就开始做了。我们开发小组能够控制的就是技术风险了，对技术风险，我们还是有很清楚的思路的，就是先扫除技术障碍，由技术能力最强的那个家伙去探索去研究。

另外我要说的是，建立起良好的小组的积极的文化太重要了，大家象一家人一样，和和睦睦的，充分沟通、建立起知识共享，共同学习和提高，感觉蛮好的，毕竟大家都是年轻人嘛。

[jkxt1234567]

up