需求做得好与坏直接关系着软件工程师生活质量
这个故事还得从去年换工作的事情说起，由于自己不太喜欢第一家公司的环境我选择了换一份工作。去年九月份我入职现在的这家公司，专门从事金融业内软件的开发。十一月份我们整个项目组前往北京做现场开发，从此苦逼的日子开始了。
系统背景：五月份就有同事前往甲方了解需求一直到6月份，后续几个月也完成了系统的基本结构设计，框架搭建，系统很多模块也能够粗略运行。
我身上肩负着一期和二期的重要模块：项目管理和流程管理。我们计划的一期完成日期是2012年1月份，由于前期做需求的时候不够详细，我们这边急于做功能，结果做出来发现和甲方所想的差距太大，看着时间一天天逼近，甲方越显紧张。每天要求我们加班，其实当时我也很纳闷，加班与否应该是我们自己项目部的事情，甲方或许还真没有权力加以要求甚至干扰。最后我们居然是妥协了，或许正是因为这样的妥协，让甲方内心的霸气越显嚣张，对我们的要求越来越苛刻。原本是说一期的时候系统很多验证方面的东西都不用做，只要能够保证系统能够跑起来即可，但是如今的甲方却丝毫没有记住他们曾经许下的承诺。另外对之前需求内尚未提及到的东西进行了口头上的扩充。此时的白纸黑字需求在我们看来只不过是一堆废纸。令人发指的是，又一次我跟一个同事和甲方一起演示项目这边的东西，不知道甲方吃错了什么药，要求我们就在会议室内修改，语气很强烈和坚决：立马给我改掉。我当时一听觉得内心真是很不爽，觉得没有丝毫的被尊重，那时才发现自己就TMD的一个干活的。还有一个更加苦逼的片段是当时有一个地方甲方要求第二天要看到效果，其实在说这句话的时候就是晚上十点半了。没办法，我搞了一个通宵，奶奶的。那晚我们这个项目组都在会议室内睡觉的。
二期的苦逼片段也是比较多的，说起流程这边就会一个最累人的活，就不谈需求频繁性地变更就已经是一个体力活了的，流程这边其实我们前期已经架设好了模板的设计以及相关环节所参与的用户均是可以自己自由配置的，灵活性很大，且便于后期维护和扩展。但是我们这样的设计还是未能说服甲方，他们还是依然贯彻着前期那样到处都想指指点点的思想，导致流程这边大大小小的改动很多很多。每天都是干一整天的活都觉得还做不完。
回忆这个项目的苦逼日子，我不禁有些反思，原因很多：
1、甲方几乎都是博士级以上，另外他们那边的负责人是一个及其强势的人，附加他们一天确实比较闲。如果每天不给你系统找几个不爽的点出来就会绝对的他们的人生毫无意义。倘若你是一个博士，每天就让你来跑跑系统，你心里也很不舒服。
2、甲方测试系统的人很多，每次和他们开会，他们几乎都会为了一个需求争论半天还搞不出一个结果，我们几个就在会议室看着他们争吵，同时也浪费了我们一大把的时间。每天这样的片段会出现一两次，会议相当地频繁。
3、我们自身的原因：没有一个完善的应对甲方无理需求的措施，总是一直被牵着走。几乎没有说过一个No。我们没有拿着需求这样一个有力的武器来保护自己的权益。
4、我们太想要这个系统顺利做完拿钱了，各种压力迫使我们如此苦逼着。
不管怎么样，需求做得好与坏直接关系着程序员是否有好日子过，附加一个有绝对领导能力和懂得决绝无理需求的Leader。
整个项目从你们入住开始，主导权就完全被客户把持住了。双方不是平等合作的关系，而是变成了你们被领导的关系。而且还是无责任的领导。有功是他们的，出了问题是你们开发的问题。
无原则的退让，则加剧了项目的混乱。过度加班、随意接受对方的时间点。表面上看好像是你们为了这个项目在牺牲。但是这种牺牲对项目其实并没有好处。只能让甲方对你们更加不满。因为无论对方怎么压榨，你们都能出油。所以就给了对方再压压，多半还有油的错觉。随意变更需求也是这个原因。因为你们无底线的接受对方的变更。那么对方就会认为，这样都能接受，那么更过分的也可能接受。
我认为如果要挽救这个项目。必须马上停止下来。最好双方高层进行沟通，给混乱的开发活动刹车。然后双方一起对已有成果进行确认。到底开发了多少，有多少是有价值的。还有多少需要开发，开发需要多少成本。然后重新安排开发计划，引入迭代周期的概念。任何需求的变更必须在迭代结束后提出。有了新需求，要么加时间，要么减去原来的需求。明确需求变更的成本。
当然，上面只是我一厢情愿的想法。是建立在双方都想把系统做好，只是沟通出了问题的前提下的。如果对方的负责人只是在过权利瘾，甚至在故意把项目搞砸（这个项目是其对头提出的）。那么就当我没说。您也赶紧找下家吧。
整个项目从你们入住开始，主导权就完全被客户把持住了。双方不是平等合作的关系，而是变成了你们被领导的关系。而且还是无责任的领导。有功是他们的，出了问题是你们开发的问题。
无原则的退让，则加剧了项目的混乱。过度加班、随意接受对方的时间点。表面上看好像是你们为了这个项目在牺牲。但是这种牺牲对项目其实并没有好处。只能让甲方对你们更加不满。因为无论对方怎么压榨，你们都能出油。所以就给了对方再压压，多半还有油的错觉。随意变更需求也是这个原因。因为你们无底线的接受对方的变更。那么对方就会认为，这样都能接受，那么更过分的也可能接受。
我认为如果要挽救这个项目。必须马上停止下来。最好双方高层进行沟通，给混乱的开发活动刹车。然后双方一起对已有成果进行确认。到底开发了多少，有多少是有价值的。还有多少需要开发，开发需要多少成本。然后重新安排开发计划，引入迭代周期的概念。任何需求的变更必须在迭代结束后提出。有了新需求，要么加时间，要么减去原来的需求。明确需求变更的成本。
当然，上面只是我一厢情愿的想法。是建立在双方都想把系统做好，只是沟通出了问题的前提下的。如果对方的负责人只是在过权利瘾，甚至在故意把项目搞砸（这个项目是其对头提出的）。那么就当我没说。您也赶紧找下家吧。
受教！