项目开发后的一些感想(2005-7-18 周一) 作者： TrampEagle 软件测试框架Web.net
程序员文章站
2024-01-13 09:53:04
...
主题: 项目开发后的一些感想(2005-7-18 周一) 作者： TrampEagle
链接地址：
已经换了两家公司了，加入时刚好都是开发一个新项目，对我来说确实是非常难得的学习机会，随着这近期一个项目的接近尾声，总感觉心里有点什么东西不吐不快。
近期的这个项目，给了我一些很深的体会：
一是如果项目任务紧，最好不要在陌生的领域搞，比方说：项目组对.net已经积累了大量的经验，但对于java来说还是门外汉，最好不要用java来设计开发这个较紧的项目。但从另一个方面来说，如果用户一定要使用这个平台环境，客户是上帝嘛，没办法，但千万不要在项目开发中招新手（如使用java，但招的新人对java并不熟悉），可能这样表面上会给公司剩下一笔钱，但其后期的埙失将不可估量：由于对这种语言不熟悉，其潜在的bug如果提前发现还好，否则当项目晚期出现时，叫天骂地的将不会仅仅是一个项目经理。
第二点体会是：开发之前的项目调研特别重要。也许在这里说有些画蛇添足了，因为任何一本软件工程的书本里对这个的重要性都是强调再强调的；但奇怪的是为何大多数的项目开发小组都没有好好贯彻？纳闷！接触过很多软件开发人员，差不多大家都在抱怨这个问题；往往是已到项目收尾期，大家都想着该轻松一把了，需求变更来了，有的根本就不是客户提出的变更，而是业务人员看到软件后的反应，当然用户提出的概率大些，有个同事搞了一个项目，即将交付时，用户提出的更改将他的设计全盘打乱，每当他给我提起，总气得要命，但有啥办法？顾客是上帝嘛，公司不可能说是因为你的劳累就放弃一笔单子的收入。
我们近期的这个项目这一点上并好不到哪里去，刚开始让几个特别熟悉业务的人搞需求分析设计，搞了一两个月，定下来后，就开始进行开发，其间并没有发现和其他任何业务员进行交流沟通，当问起时，回答说，这一方面他们是专家，很自信。确实在以后的日子里，我也确实发现没有比他们更熟悉业务的，但这就意味着不需要和他人交流了吗？很纳闷，总感觉这样有点像闭门造车！果不其然，在随后的日子里，经常碰到一些需要变更的东西，有很长一段时间，我感觉不是在开发新项目，而是感觉在维护已经漏洞百出，即将崩溃的快要死掉的项目。
第三点，如果某些事情在项目开发之初就感觉应该做的，绝对不要拖到后边做。举个例子，搞一个web项目，美工肯定是离不了的，因为这直接影响到客户的第一印象。当项目开发之初就应该先找美工把所需要的一切：样式风格，框架设计，界面布局等；不要为了赶任务，凑合着做项目，拖到后边来完善，留给程序员的无疑将会是一场恶梦。
第四点，感觉非常重要的就是项目质量的控制，这是一个较大的问题，也是一个难以衡量的问题，但有四点我感觉尤其值得注意：一是测试一定要跟上，不要拖到项目收尾时，单独专门搞测试，开发项目象盖房，最好的就是先搞测试（写测试用例），实在不行就一边开发一边测试，因为测试是一个度量，度量这个项目是否符合要求，否则，如果等到开发完毕再进行测试，就好比盖好房子再拿设计图检验，搞不好就要全部拆掉，据我所知很多项目虽不至于因此烂掉，但因此延误期限的病不在少数；二是，项目开发一定要按照开发之前的规范走，如果没有就一定要定一个出来，以后如果谁没按照规范走，后果就由他承担。绝对不能单纯的按照某一两个人的意见就私自更改一些设计或者一些文档，也许看上去这个似乎并不太重要，但项目的维护，以及项目开发过程中的大量的重复劳动都将因此为你带来无边的痛苦；三是一定要使开发人员高度重视所写代码的质量，不能简单的应付差事，或是为了赶任务仅仅满足于所实现的功能，还要多加考虑灵活性和可扩展性，否则以后项目的需求稍加变动便意味着你的劳动的不必要的但却是必须作的重复；四是，注释和文档一定不能少，更不能缺，项目成员的变动不是一两个人就能决定的，所以一定要考虑到项目的接管问题，最好的办法是文档不能少，注释也不能少，并且是越多越好。当然了，注释和文档一定要和项目保持同步，否则有不如无，相信大家对于这一点都不陌生，就不多说了！
第五点，也许有点垃圾，但感觉还是比较重要的，那就是作为一个项目经理，一定要密切注意整个项目的进度以及尽可能的了解每个项目组成员的情绪变化，要不断适时地给予一些鼓励，当然该批评的也不能姑息，要让整个团队在一个较好的气氛环境中进行作业。当项目遇到挫折时，千万不能急，要沉住气，要冷静，千万不要对项目组成员发火，因为发火不是解决问题的方法，不但不能解决问题，还可能激化矛盾，加剧项目开发的风险，有可能因此使得项目流产。
不早了，本来以为问题不会这么多，谁知越写感觉话越多，暂且到此吧，以后慢慢补充，要赶紧休息了，呵呵！
链接地址：
已经换了两家公司了，加入时刚好都是开发一个新项目，对我来说确实是非常难得的学习机会，随着这近期一个项目的接近尾声，总感觉心里有点什么东西不吐不快。
近期的这个项目，给了我一些很深的体会：
一是如果项目任务紧，最好不要在陌生的领域搞，比方说：项目组对.net已经积累了大量的经验，但对于java来说还是门外汉，最好不要用java来设计开发这个较紧的项目。但从另一个方面来说，如果用户一定要使用这个平台环境，客户是上帝嘛，没办法，但千万不要在项目开发中招新手（如使用java，但招的新人对java并不熟悉），可能这样表面上会给公司剩下一笔钱，但其后期的埙失将不可估量：由于对这种语言不熟悉，其潜在的bug如果提前发现还好，否则当项目晚期出现时，叫天骂地的将不会仅仅是一个项目经理。
第二点体会是：开发之前的项目调研特别重要。也许在这里说有些画蛇添足了，因为任何一本软件工程的书本里对这个的重要性都是强调再强调的；但奇怪的是为何大多数的项目开发小组都没有好好贯彻？纳闷！接触过很多软件开发人员，差不多大家都在抱怨这个问题；往往是已到项目收尾期，大家都想着该轻松一把了，需求变更来了，有的根本就不是客户提出的变更，而是业务人员看到软件后的反应，当然用户提出的概率大些，有个同事搞了一个项目，即将交付时，用户提出的更改将他的设计全盘打乱，每当他给我提起，总气得要命，但有啥办法？顾客是上帝嘛，公司不可能说是因为你的劳累就放弃一笔单子的收入。
我们近期的这个项目这一点上并好不到哪里去，刚开始让几个特别熟悉业务的人搞需求分析设计，搞了一两个月，定下来后，就开始进行开发，其间并没有发现和其他任何业务员进行交流沟通，当问起时，回答说，这一方面他们是专家，很自信。确实在以后的日子里，我也确实发现没有比他们更熟悉业务的，但这就意味着不需要和他人交流了吗？很纳闷，总感觉这样有点像闭门造车！果不其然，在随后的日子里，经常碰到一些需要变更的东西，有很长一段时间，我感觉不是在开发新项目，而是感觉在维护已经漏洞百出，即将崩溃的快要死掉的项目。
第三点，如果某些事情在项目开发之初就感觉应该做的，绝对不要拖到后边做。举个例子，搞一个web项目，美工肯定是离不了的，因为这直接影响到客户的第一印象。当项目开发之初就应该先找美工把所需要的一切：样式风格，框架设计，界面布局等；不要为了赶任务，凑合着做项目，拖到后边来完善，留给程序员的无疑将会是一场恶梦。
第四点，感觉非常重要的就是项目质量的控制，这是一个较大的问题，也是一个难以衡量的问题，但有四点我感觉尤其值得注意：一是测试一定要跟上，不要拖到项目收尾时，单独专门搞测试，开发项目象盖房，最好的就是先搞测试（写测试用例），实在不行就一边开发一边测试，因为测试是一个度量，度量这个项目是否符合要求，否则，如果等到开发完毕再进行测试，就好比盖好房子再拿设计图检验，搞不好就要全部拆掉，据我所知很多项目虽不至于因此烂掉，但因此延误期限的病不在少数；二是，项目开发一定要按照开发之前的规范走，如果没有就一定要定一个出来，以后如果谁没按照规范走，后果就由他承担。绝对不能单纯的按照某一两个人的意见就私自更改一些设计或者一些文档，也许看上去这个似乎并不太重要，但项目的维护，以及项目开发过程中的大量的重复劳动都将因此为你带来无边的痛苦；三是一定要使开发人员高度重视所写代码的质量，不能简单的应付差事，或是为了赶任务仅仅满足于所实现的功能，还要多加考虑灵活性和可扩展性，否则以后项目的需求稍加变动便意味着你的劳动的不必要的但却是必须作的重复；四是，注释和文档一定不能少，更不能缺，项目成员的变动不是一两个人就能决定的，所以一定要考虑到项目的接管问题，最好的办法是文档不能少，注释也不能少，并且是越多越好。当然了，注释和文档一定要和项目保持同步，否则有不如无，相信大家对于这一点都不陌生，就不多说了！
第五点，也许有点垃圾，但感觉还是比较重要的，那就是作为一个项目经理，一定要密切注意整个项目的进度以及尽可能的了解每个项目组成员的情绪变化，要不断适时地给予一些鼓励，当然该批评的也不能姑息，要让整个团队在一个较好的气氛环境中进行作业。当项目遇到挫折时，千万不能急，要沉住气，要冷静，千万不要对项目组成员发火，因为发火不是解决问题的方法，不但不能解决问题，还可能激化矛盾，加剧项目开发的风险，有可能因此使得项目流产。
不早了，本来以为问题不会这么多，谁知越写感觉话越多，暂且到此吧，以后慢慢补充，要赶紧休息了，呵呵！