课堂上对开发案例的见解

案例情况：
1、SS提出了一个称为销售奖励程序SBP（用来管理支付地区代理佣金的软件）的单机版软件产品建议书，预计开发周期为1年。
2、公司决策层审批通过，但要求实现网络通讯功能，将工期缩短为6个月，尽管SS认为没有多大可能在6个月内完成，但公司决策层主意已定，认为只要技术人员加倍努力应没问题，允许扩大项目组规模。
3、SS试图：
   （1）采用C++和面向对象的设计方法；
   （2）采用一种报表自动生成工具；
   （3）拥有更新、更快的硬件设备；
   （4）雇佣到顶尖的开发人员。
   公司进一步要求加班加点拼命工作，将项目计划压缩到6个月内。
4、SS组建了项目组，由于公司内部固定的开发成员无法完成一些特定任务，招聘了1个合同制开发成员，该合同开发者被面试人员建议不宜雇佣，但项目经理急于用人，而且觉得他具备了相应开发技能，还是雇佣了他。
5、在项目组的第一次会议上，公司高管向项目组阐明了ABC公司对于SBP项目的关注，如果项目取得成功，会获得丰厚的奖赏。接着，项目经理与成员粗略讨论了项目计划，并与测试经理约定5个月后交付功能完备并通过测试的版本。
6、项目组用不到1个月时间完成了需求分析报告和设计工作，似乎很好地发挥了C++的功能优势。然后开始了疯狂的编码，以满足在第4个月时发布第一个测试版本的要求。
7、项目进展并非一帆风顺，大家都不喜欢那个合同工，抱怨他不让任何人靠近他的代码，项目经理将这些归结于由于人们长时间工作所导致的个性冲突。
8、然而到了第4个月中旬，CS通知新的销售奖励制度已经发布，项目组发现他们必须改变输入对话框、数据库设计以及数据存取对象和通信对象，以适应新的结构。
   ※陷入修改的混乱当中
9、转眼间数周过去了，预计第5个月初交付测试通过的完全版的日期到来并过去了，项目组还是没能提交第1个测试版，存在许多遗留问题
   ※报表生成程序不如预想那样工作；人员互相埋怨和不协作；…
10、公司高管又召开了项目组会议，要求项目组努力工作以按时交付产品，每天工作10小时。每个人为了按期交付而加班加点，终于在在第7个月初提交第一个完整版本供测试。一个半月每周60小时的工作几乎压垮了他们，这期间个别开发人员被他以前的项目组经常叫去做一些技术支持工作（大约每天得为他们工作2小时）。
   ※2天后，测试经理发布了第1个问题报告，在程序中发现了200多个问题，包括必须处理的一类严重错误数十个。
   ※测试组每小时还在发现新的错误。
11、经过1天的讨论并估算修正每个错误所需要的时间，公司高管被迫同意项目计划延期4周，要求每个人被要求每天工作12小时，每周工作6天，高管则开始了自己为期1个月的年假去度假了。
12、接下的1个月时间里，项目组每天都要在办公室呆上12小时，但他们会花许多时间看杂志、电话聊天，他们每处理一个错误，测试人员就会发现2个新的错误，一些本来估计花几分钟就可以解决的问题由于牵扯到项目各方，变成需花数天时间才能解决。
13、这期间，那名合同工接受了另外一家公司的合约而离职，项目经理只好又紧急雇佣了一个程序员来帮助处理其所编代码，但经过1周的“鏖战”，发现程序中存在一些深层缺陷，被迫重新设计和编写程序。由于新人不了解团队的工作规则，经常覆盖其他成员的工作文件，导致工作的重复与时间的浪费。
14、半年后，项目终于正式发布，得到了市场及用户的认可。
   ※ABC公司向项目组每位成员颁发了250元的奖金，以感谢他们辛勤的工作。
   ※几周以后，部分人员跳槽到另外一家公司去了。

 

 

 

2010-12-13  组长工作日志

1.公司决策层，以砍半开发周期的前提下通过方案，方案提出者仅仅认为是凑合的前提下，草草接下项目  显然是公司决策层过高的为了工程进度而不考虑项目的投资与回报的双面关系。夸张的决策无不为最后  项目开发团队解散之事埋下伏笔。

 

2.SS经理试图采取的开发方案，太趋于完美开发条件（自动报表，更新、更快的设备、雇佣顶尖开发人员   ）作为开发经理能如此大的动作，当当项目风险评估不说，从投入与回报这个角度分析，这么大的投    入 作为项目的开发经理花费开销如此之大，必然给你带来巨大的压力，毕竟公司是一个盈利为目的的    企业，高投入肯定要带来高回报的效应。以微软的“MSF”开发模式来说，这么完美的开发条件风险系    数恐怕项目经理的在任时期不长。

 

3.项目经理单单为了赶工程进度而执意乱聘人员，急功近利最后往往造成无功而返。聘用技术人员不能单   看技术层面，更重要的是一个适应能力，开发是一个团队的集体的工作成果，单看个体他可能是一块冰
  个头十足，放在一杯水里当时看来效果满满，放在水里它迟早要化的，冰和水体积存在1/10之差，最终
  肯定会水满自溢。

 

4.项目经理在第一次会后，仅仅是粗略的跟下属人员项目计划，在没有充分征求项目团队人员的分析后草  率的与测试经理约定5个月后交付测试版本。项目经理再次犯了团队开发之大忌---一意孤行。团队还没  开发就对团队工作效率肯定是好事，但也不能太夸张。拔苗助长、好高顾远 最终肯定不成成大气候。

 

5.需求工作和设计开发周期缩短为一个月，而其目的是为了赶在4个月后交付测试版本，项目经理完全不  懂的开发周期的进程安排，把重点放在编写代码，完全没有考虑到项目前期开发编写文档的重要性，没  有一个统一标准，也没有开发完善的规格说明、概要设计、详细设计，初初的把前辈整理出来的先进的  开发模式犹如糟粕一样一一卡掉。这么草率的开发，必然会让团队开发走很多弯路，代码的增删改动作  时时发生，程序显得相当臃肿，后期维护费用暴增。这些都是开发软件不愿看到的。在这点项目经理做   的太草率了。

 

6.在团队开发过程中，团队成员出现矛盾，项目经理没有做到自己的责任，认为是个性冲突，成员代码不  开放在开发团队中，在我认为是非常严重的问题，怎么能一个个性来囊括的，在这个方面项目经理可以  说是极端的不负责任。在一艘木船上，哪怕只有一个乘客做热锅上的蚂蚁，船夫不及时调停，这个形成  可想而知。

 

7.CS接到通知客服需求发生变动，程序结构发生变化，陷入修改代码混乱中。仅仅是一个版本更新问题，  为什么会如此大的动作，在软件开发在版本升级方面是必须要做的一件事，因为每个程序员都想自己的  软件是活的，这就是这个团队在开发前期没有制定统一的标准，以及日后维护工作做好书面分析，只是   为了缩短项目开发周期，根基不牢，亡羊补牢就更困难甚至是人羊全毁。  

 

8.高管在开发发生严重的情况下，放开管理独自去度假，接下来的一个月员工群龙无首，没有统一的管理  开始散漫，无所事事，效率平平。工程进度严重滞后，错误频频。

 

9.在工程进行极度不顺的情况，人员变动，没有让新手了解工作规则就让新手着手工作。导致工作的重复  与时间的浪费。

 

10.半年后项目发布，得到了社会的认可。然后高层的奖励措施发生的相当有戏剧性。250元的项目奖金给   部分人员买了张车票，送走了他们。