昨天我提了几个建议，但是我觉得让“技术人员尽早的参与需求”这个最为重要，可能在开会的时候，我没有表述明白，这里再补充一下。
我认为我们现在的情况因为“技术人员对需求理解有问题” 表现出来的有两点：
1.不能正确的实现需求，重复的返工。
我有时候问相关的技术人员有的需求为什么这样做，他们却说是运营让他这么干的，他也不知道为什么。这种情况在其他人身上应该也有。
有时候运营的人过来问上了吗？技术人员就说上了，确实是按运营说的去做的，但是由于双方之间的沟通或者表述没能达到100%
的传递，导致上线的功能并不是提需求的人真正想要的，于是有赶紧修改，赶紧的二次上线同一个功能。
这个问题除了应该强调双发之间应该将需求沟通清楚外，我认为最重要的是双方没有站在同一个对项目理解的层面上去思考，
去沟通，所以技术人员在实现细节的时候有可能就把握不好 跟项目的实际需求背道而驰。
2.大家对各自的项目没有激情，没有主动权
昨天也说了，希望负责各自模块的技术人员去发挥自己的想法，将功能或业务去尽量的完善。这个是对的，是好的，但是
我认为这个是我们想要达到的一个目的，一种表现形式而已，想要达到这种效果的前提是，大家对自己的业务有激情，有成就感，
有主动权。
现在的流程方式是，需求确定完成后，安排下来，然后技术人员开始实现。由于对需求的理解可能会有偏差，导致不断的重复上线，重复修改，这对技术人员来说也是一种不好的感受；对公司来说也是在浪费一种成本，并不是员工一直在做事情就能推动公司业务的发展，而是员工在做有意义的事情上才会对公司有实际价值，不停的重复修改，是在工作，但是未必对公司来说是有意义的。久而久之，“是他们让我这么做的”这种情况 就会愈演愈烈，还怎么能够谈上什么激情呢？由于对需求越来越糊涂，又怎么能去主动去想更合理的需求呢。
产品人员提的某种需求要实现一套东西，而技术人员实现的确实另一套东西，这在软件行业这种情况是非常普遍的，各种文章都在说这种情况。技术人员只是负责实现 这种方式是落后的，是错误的。第一 技术人员把握不住实现细节，易产生诸多bug。由于对项目未来的发展也不清楚，导致系统架构在项目初期就建设的不合理，导致发展到一定阶段，必须重构，拆了重建。第二 一般的技术人员都是互联网多年的从业者，无论是产品还是用户体验还是技术方面还是之前所做的成功的项目，他们都是有很多经验的，我认为在项目初期就让他们参与，他们相关的经验也会无形的来帮助产品的完善，而不是只做一个实现的工具，忽视了他们拥有的这些经验，这对公司资源也是一种浪费。第三 上面两点带来的副作用就是 技术人员对自己做的事情 越来越反感，越来越没有兴趣，导致一些不愉快的事情发生 比如 跳槽 或者 跟相关人员产生沟通上的冲突。
综上所述，我认为技术人员只负责实现，是项目开发流程中的一个误区，是错误的，是没有效率的。
我认为在项目需求的初期阶段，就让技术人员参与，让技术与产品有一个共同的目标，就是将这个项目做好，而不是之前的实现产品所提的功能就可以。让技术人员对这个项目的 意义 价值 以及 未来的发展方向 都应该清楚，其实不只是技术，所有参与这个项目的人 无论是运营还是产品还是技术，都应该对这些都了解，这样大家才会有同一个目标，同一个理想，在沟通的时候有一个共同的沟通基础，以至于提高大家的沟通效率，提高需求的准确率。大家在一起去讨论需求，确定需求，这样才能增加相关人员的对这个项目的认同感 和 最最重要的责任感，这样去做 大家才会有可能产生激情，最起码好过直接安排需求，然后糊里糊涂的去实现要好。
说这些绝对不是出于个人原因才会这么做的，因为在项目中我是尽我最大的努力去做到以上所述的几点，以达到对这个项目的了解以及避免需求实现错误。我想我的这个目的是对的。
这些情况是我在咱们现有的工作流程看到的 想到的，可能我的理解也是不对的，片面的，所以我说的不一定对，这些只是我个人认为正确的办法。无论是正确还是错误，但最终目的是好的。我希望我们这个团队的每个人都对自己的工作感兴趣有激情，工作的开心，工作的有效率，有意义。这样我们才是一支强大的队伍，才能有可能去做成功一件事情。才可能将公司的业务推向高峰，从而实现各自的人生价值。
其实我认为最好的流程就是，技术人员不仅仅要参与需求，而且对需求要有主动权，有控制权。像facebook 技术人员是可以拒绝实现自己不认同的任何需求的。
但是这些都是后话了，事情要一步一步的来，最终才会慢慢变好的。