随着
IT
日新月异的发展，现如今回头再浏览一下曾经光辉的程序员
1.0release
时代，曾经光辉但却原始。
既然现在的项目开发已经脱离了原始的自给自足时代，进入手工作坊或者工业时代，那必不可少的就要有团队内的交流和团队与团队的交流。尤其要提到的是项目前期的规划人员在得到用户需求以后交付实施之前（这个关节是用户需求与实际开发的一个接轨过程），会出现频繁的团队间信息传递。此时项目的一个关键的问题产生了，国内大多数软件公司在此时已经默认这个项目是有价值去做的，但是，由于项目提出人只是感觉到应该出一个这样的项目，至于业务点啦，针对性啦等等这些很重要的工作点尚没有被明确地提出来，或者提出了一部分也只是根据他们实际实施中常碰到的问题提出来的，（此时能做到这一点应该说已经很不错了，已经可以肯定的说你这个项目是有实施价值的，能为客户有目的地去产生价值，至于项目发布后是不是这样那的就是另一回事了）这些需求还不是很到位，打个比喻，就象一个人说话一样，他潜意识可能知道是什么但是用语言表达的时候打了折扣，所以就需要需求分析人员去进一步发掘。如果能从客户提交的需求里，或者在头脑风暴之类的会议中，能找到促使项目产生而隐藏的真正原因那就更加地理想了。
但在我们实际的开发中往往不是这样的，由于从客户交付需求到开发，往往要经过一个筛选的过程，所以开发人员接收到的资料和用户初期提出的相比，已经面目全非了。但是此时如果假设提供给开发人员的资料已经很全面、很详细，资料里的内容
“
所见即所得
”
，这也可以算做比较完美的。但是实际开发中往往是开发人员在拿到这份资料的时候反而不如客户直接对他说我就想要个什么什么的东东，而实际开发中这样的情况是不会有的，所以开发人员会反复问那个需求也尚没有完全清楚的需求人员，经验丰富的
IT
人会灵活解决这个问题，但也不会避免要出现和客户再确定的情况。而此时如果这个需求人员也不是很在行，那灾难就来了，需求人员会在开发人员的要求下直接与客户交流，在此之前可能会有相当长一段时间处于胶着状态。
我认为在现阶段的情况下适合担任需求分析的团队了至少要有一个人是经验老道的，起领头作用，外界输入的信息是要经过该团队人员去加工筛选的，而不是用户提什么就列出来什么。很可笑的事情是，在开始编码前，需求是由表示层的人员来向开发人员来阐述。更可笑的是，需求人员在向开发人员阐述需求的时候模棱两可、表达含糊直至旁人说出来答案，然后很谦虚地附和一声，不了了之、滥竽充数。
以上意见仅供参考，实属虚构、如有雷同、纯属巧合。