没头没尾--项目开发笔记：项目问题的阶段性总结，下一步…………

标题：没头没尾--项目开发笔记：项目问题的阶段性总结，下一步…………

关键词：分布式开发 C# 项目分工 DELPHI与C#的混合开发，项目管理

11月30号：得到了很多朋友的建议与意见，明确了目前我的水平以及项目管理水平所处的状态

 

写这个项目开发笔记之前，我至少还认为对于这个项目，我有很多的想法，也已经做了一部分的工作，虽然有些部分并没有达到我的目的，但是那些部分也是我在工作中经过碰撞与为了项目时间经过妥协之后的结果。也算是有点项目的经验（井底之蛙都这样L）。但是这几天我仔细的看看网上朋友们给我的留言，以及与身边的朋友直接进行交流，得出了很多清醒的认识。我真的可以清醒的认识对于这个项目中我所应该但任的角色已及实际上我对自己的要求。

 

这个项目本身是属于公司领导层直接进行管理。但是由于本身这个项目采用的是比较新一点的技术，以及我又通过与大家的讨论定义出与以往的开发步骤并不相同的开发方案。所以实际上对项目计划的制定提出一些意见；又由于我对开发人员的各自特点比较熟悉，所以我也参与了对项目人员分配的一些意见。下面的一些总结中将会对我在项目中具体所做工作作一些定义以及我现在所能想出项目进行过程中我实际的一些想法。

 

以下是目前项目阶段性的总结：

l         分配的任务完成很差的部分，或无清醒意识的部分

Ø         参与项目计划的制定

项目合同中对项目完成时间有非常苛刻的要求。客观上要求项目安排必须非常紧凑。但领导问我对项目计划的意见时。我实际上可能考虑比较多的是我们采用的新的开发方式后对开发小组的进度安排。或者说是被新的开发方式的前景冲昏头脑忽略了使用这种开发方式开发人员的适应期。可能会出现开发过程与网友BigTall所说的过程非常的相似：

从现有项目的管理经验来看，分模块开发是必要的，但是要记住，如果是横向分层的话，会增加很多的人员之间的沟通活动，…………纵向分层开发是小公司目前最好的选择。千万不要希望人员之间的沟通会狠顺畅，血的教训，切记切记！

虽然从目前的情况来看，项目还不至于出现沟通有问题的情况。但是初期的沟通的确是花费了比我想象要多的时间L。以及后面项目开发过程对测试影响的时间，都可能会与开始我定义的项目计划不符合。

Ø         参与项目Coding人员的分配

项目人员的分配中我出现的问题可能还是多从技术的角度去考虑问题。对每个参与项目Coding的人员主要从他的技术水平角度来考虑。而较少的考虑他们之间的兴趣爱好不同，沟通能力的不同等特性。我的项目经理朋友告诉我一个很好的例子：他在管理一个项目时，并不是完全根据项目小组中每个人的实际能力来分配任务，而是对应项目小组成员对项目各个方面不同的爱好，以及相应的潜在能力来分配任务。那么项目小组成员在设计开发过程普遍的感觉到学习到不少的东东，工作的热情非常的高涨。我几乎没有针对这种类型问题的思考。

Ø         项目的设计部分

这部分没什么好说的，有很多的网上朋友已经提出了很多意见（说实话，一开始我还对某些朋友的说话方式真有点接受不了J）。也许我以前用过UML，或IDEF之类的设计思想，以及对应的设计工具。但可能并没有对设计思路掌握好。特别是对如何合理的使用设计思想与客户或项目成员进行沟通没有仔细的考虑。出现设计问题的时候可能由于时间因素的原因将设计的粒度变粗，以至于开发很多的模块没有详细设计文档。

Ø         项目实施过程中的执行

执行项目的过程总体来说有两个部分的不足，对设计过程的粒度过粗以及对开发框架设计的过细。也就是说项目的执行时设计过程所花的时间过短。而对应讨论开发框架所花费的时间过长，希望可以达成开发小组成员的完全统一。从目前的情况来看，项目滞后的时间主要是由于讨论开发框架所拖延的时间。其实这个问题涉及到对技术问题的把握，很多时候技术问题是不可能得出一个完美的答案。这个时候需要多数人通过，以及大家对方案认可程度的统一就可以了，而不要去强求对技术问题的完全统一。

 

l         分配的任务中完成的部分，或有意识的部分

Ø         开发小组与其实项目相关的部门交互时的策略

这部分的问题我想我还是投入了很多的关注。由于开发小组讨论对分层开发中沟通问题有很多的定义。所以我也把这个沟通的方式应用到开发小组与其它项目相关部分进行交互时的考虑中。

Ø         技术会议时，试图去注意把握会议的进程，以及达到会议目标

这个技巧是以前看项目管理相关的书时特别感兴趣的一个部分，那么在实际应用我也想了一些办法。

Ø         通过讨论统一构建技术上的架构

可以参考《没头没尾--项目开发笔记：C#分布式工程的修改版本》，对技术架构的已经有比较细致的描述。

Ø         试图去寻找新的开发中的方式，以适应新的开发环境与项目时间的需求。

可以参考《没头没尾--项目开发笔记：分模块开发!!?? 分层开发!!??》

 

我想通过这样的方式来分析我已经出现和将会面对的问题是非常恐怖的一件事情。从这样角度来看有很多的事情我都没有做，没有做好。虽然我是项目中的一个技术经理。但是由于公司规模以及项目本身的限制，项目必须在缺少很多可以提升，可以完美的条件下继续前进。可能我还是必须要去按照我可能达到的水平来处理我所遇见的问题。项目按时完成才是最终的目的。

我想干过两三个项目的技术工作的人被领导推出来参与一部分项目管理的朋友一定也不少。我的这些经历可能会因为不同的环境有一些不同的特点。我想通过这些笔记与向朋友们请教与以及与朋友们进行交流。还有很多的朋友可能已经有过经历过的这种阶段的经验，但也还有很多的朋友也许正处在与我相同的阶段或者将要进入这个阶段。那么朋友们是怎么做的？我特别的希望知道。

前面写的很多项目笔记也许叫技术笔记更加恰当一些。我想这也是属于我认识中偏差。但是已经写成项目笔记了，我想也就没有必要再进行改变了。朋友们也就将这些记录统一当进行一个项目进行过程中项目成员的思考吧J