先简单的介绍情况：小城市，小公司，小项目（20-40w左右），也做过几个大项目。但无论项目大小，其管理模式还是很low，简单、粗犷。
业务对口的是国企在地方处级单位的信息化项目，这类单位有个特点是：每年有一定的科研经费，做项目不差钱。一般流程是：甲方单位内部立项、招标投标、和开发商签合同。当然具体的细节比这复杂。这里想说的是在这个过程中涉及到的需求问题。
先说这个过程中需求是怎么产生的。一般是甲方各职能部门根据生产需要、管理需要、基层人员平时反映的问题来决定立个项目解决目前的需要。部门领导可能会开个内部会，调研下有哪些问题需要解决，安排个人收集整理下，写个立项报告（这个人也基本是后来和我们进行项目沟通的甲方联系人），再报给公司进行审议等等流程。通过后就是招投标阶段，这时我们通过招标书可以看到原始的需求。而我们在投标并中标后，在准备的合同中对这部分的原始需求没有进行过多的解读分析，基本就是照搬过来，添加下费用构成、进度安排。合同一签就开工了。
隐患在这时就已经种下了。查看招标书、准备投标书到后面的拟定合同，这些都只有项目经理或是商务性质的人在做，其中的原始需求也只是粗略的看下觉得可以做，即便有少量难点觉得也可以变通解决。偶尔就其中的一两个需求点，询问下技术人员是否可做。大体上没什么问题就准备拟定合同，签合同了。暴露的不足之处就是对需求分析不够深入、不够重视。
可能有人会说很多项目经理都是从以前的技术岗转过来的，而且还是技术比较好的，否则也不会任命为项目经理。他们对需求的把握不会有大问题。但实际情况是，技术更新迭代快，项目经理如果还以以前的技术经验来评估需求是有风险的。
其次项目经理以前的技术经验和当前项目所要采用的技术是有差别的。拿桌面软件的经验去评估B/S系统的需求也有偏差、风险。即便没有这种偏差，项目最后也不是由项目经理来开发，而是交给下面的程序员、架构师来完成的。这又有一种偏差，项目经理在评估需求时认为3个月可以完成，而开发人员因为技术能力、经验与项目经理不同或者没达到他的预期，可能认为需要5个月才能完成。但经理并没有征询这个5个月，已经按3个月的进度安排写进了合同。这在后期开发时会形成风险。
这就是我为什么要提出：项目谈判，请带上我！这个我指的是：项目开发核心人员或者叫项目技术负责人，越早越好。
作为开发人员首先关心的是需求。了解了需求才能知道自己能不能做，怎么做，有多少风险，大概什么时候可以做完。从立项开始，尽早的让你的主力、核心开发人员参与到需求收集整理、分析确认过程中来。当然大公司，有正规、完整做项目流程的公司这方面做的好些，会配有专职需求人员及需求管理制度。而小公司基本上都是项目经理兼任。后期也没有正式的需求管理。项目经理很多时候主要精力是放在招投标、商务谈判上，后期也是放在人员管理、进度管理上。
项目技术负责人在合同签订后才拿到全部需求（还是原始需求），已经很被动了。估计还会傻眼。在前期投标，谈判等环节是由项目经理或商务人士评估的需求，他们大多也是从技术可行性上分析，能不能做。需求中包含的范围没有深入研究，只是按照其他项目经验自己预估的一个，并没有去和甲方确认也没体现在合同上。等到技术人员开发时就知道这个范围不好把控，甚至成为了一个坑，导致项目延期，验收不过，产生纠纷。
需求中两个要点：做什么，做到什么程度什么范围。第一点决定了你有没有技术能力做，后面一点决定了做多久，投入多少人。都是对项目有重大影响的，都要重视。
让技术负责人今早参与到需要中来，也本身也很好理解。毕竟项目以后是要交给他来做的，他的评估意见才是最接近实际情况的。除非你对下面人的技术能力、效率、心理素质非常了解，才可以自己评估。否则还是特定问题交给特定人士解决。
可惜的是，我们一遍遍给自己挖坑，一拨换一拨的来填坑。好的开发人员也留不住，谁也禁不起这样的折腾。做项目的声誉也受损。
当然这里并不是把责任全推给项目经理和商务人士。有些现实原因。中标完后甲方有要求尽快拟定合同，开工建设。长期合作，有基本信任，细节上就没有不厌其烦的去沟通确认。还有一个重要原因是，甲方在内部立项时有些是基于几个领导的一些想法，或者内部开立项审议会时到场的只是领导、几个关键人员，而这些人员并不是系统的主要使用者或频繁使用者，提的需求也是比较抽象，目标化的。如：
满足生产报表的数据自动提取；
快速响应
与现有的系统进行数据互通
实现报表的自动生成
看到这样的需要，任何一个都需要去深究。数据自动提取，怎么提取，现有的数据在哪，什么格式，多少量，任何一个维度都左右着完成时间。快速响应，什么叫快速？1秒叫快，0.1秒叫快。可能达到1秒很容易，但要达到0.1秒却很难。
需求重要的一点就是要指标化，能验证（能通过具体的数据、表现验证需求是否达到）。否则验收时就知道这些抽象的需求，解释权在甲方那。达没达到是人家说了算。
我们的项目还有个特点就是，开工后，基本就是开发人员与甲方的终端用户沟通了。这就是痛苦的开始。那些抽象的需求，经过这些最终用户的发散、扩展，早已不是当初预估的工作量了。而且还会经常变动，需求确认过程慢，他这块业务不熟还得等他找人确认。这些最终用户在提需求时，也不会考虑什么项目范围的，只要扯得上边就提。包括个性化的要求，并不是我们当初分析时的通用设计、一般使用方式。不会想到一分钱一分货，叫我提需求的，那我就可劲的提。如：能不能在你们网站做个像QQ那样的功能，不要那么多功能，能聊天，能传文件就可以。那个word有这样的功能，你们也照着做个嘛。就问你想哭还是想笑。
太多这样的经历，碰到好说话的，懂技术的还好。否则让你怀疑进错了行。这又涉及到开发过程中需求变动没有控制，靠开发人员与终端用户沟通。沟通不好，一边向领导反映说功能没实现，接着投诉过来了。一边觉得做不下去，没法做，情绪激动，军心不稳。
原因还是在开始阶段需求不够细化，收集不全。现实中也不大可能等你把所有用户的需求收集完，分析完，再一个个找人确认。全部确认完了再来报进度、报价。但我们还是要尽量把需求做完善，技术负责人一开始就参与进来。没法找用户去量化需求的，先给个基础量化值，留些余地。如要做报表，却没给出具体数量，就先给个值：20张（50个数据项），超过的经过协商确定时间和费用。
需求明确了，后面的工作才有据可循，各自完成本职工作，项目的成功率才有保障， 这才是对双方有利的事。