需求阶段
在接到任务后，先与业务员（商务）进行需求沟通，多提出业务员当时未向客户提出的关键问题，详细了解需求并试图想到解决需求的方法，与业务员沟通解决方法是否可行，以及成本预算是否在合理范围内。
在了解需求清楚以后，进行需求的评估。出具需求详细列表，向业务员展示需求的内容，并由业务员进行确认，业务员确认不了的向客户进行确认。如果是数据接口方面，在不了解需求业务流程，则尽量和业务员进行多次的沟通，确定业务流程以及业务流程中数据获取的方法，客户系统的菜单流程等。
客户有可能急需一个评估价格和评估时间。在评估时间的范围内要加上20%到30%的时间。此时实际上只是一个需求列表，并没有一个进行原型设计，如果时间允许的话，最好是出具原型图，这样方便业务员和客户进行沟通及展示。
本次沟通要出具文档：《需求说明书》，并由业务认可。说明书在实际中即使确认了也有可能变更，则要出相应的新文档，并由业务员确认。在开发过程中是按需求分配任务和开发，没说到的更加细节的地方则需要有相应的《需求变更书》。如登录在需求中要说明是否进行录入框的验证，以及验证的要求，不能因此让业务员说这是常识要求而不是需求变更。在需求沟通时在要提出来并记录在需求文档中，同时提醒业务员是按需求文档进行开发，没说的就可能会造成延时或者后期再开发，一定要有需求变更书。
很多时候业务员并不了解实际完整的需求，则根据业务员的描述进行尽量的需求想像的描述，最好不要评估时间，否则业务员会以此时间向客户报价和时间，即使预增加了时间，在完全明确需求后会发现需求比当时要多很多，但时间不会增加。
此时可能业务员就将任务完全甩开，而由开发人员去进行现场沟通、客户确认直至开发结束、上线、实施，甚至收尾款。如果涉及集成产品，业务员也可能不会去处理，只是开发人员在不能获得实际结果（如当初业务员与集成商签订合约时，上面所说的一些功能没有实现，或者新的要求需要实现的话集成商提出费用问题）时才会去与集成商沟通协调。因为没有产品经理、项目经理的说法，所以全部由开发人员协调。即使有产品经理一职，也可能只是表面的业务员转化，产品或项目的一些具体工作是不会去做的。在这种情况下，一定要确认好需求，不能贸然答应相关任务，一定要回复说考虑一下并发邮件确认，并且出具需求变更书。
在日常的需求编写中进行知识积累，这样每当客户提出相关要求时候就可以重复使用。
这个阶段对于开发公司来说，实际上是需要一个产品经理来进行的，需求的了解，以及规划、设计产品应该是什么样子的，但在实际的公司运作当中，基本上没有或者是只是老板自己，或者让业务员来做产品的需求，或者让开发人员进行现场调研，做产品需求，做产品经理需要做的事情。而且在产品不是产品的情况下，叫做项目时（实际上是可以当作产品）进行产品的设计以及将来之后的项目分解，才可以更好地进行梳理。
无论是否将这个职责，或者说将这个责任指定给你，一旦接手进行需求分析，与客户沟通，实际上已经在作为一个产品经理了，并且在做产品经理该做的事情的大部分时，那么，既然做了，那你就该担当起相应的责任。如果不去担当起相应的责任，那么在开发当中，就会形成艰难的一个过程，而且在收益上你将达不到相应的收益，你只是一个开发人员的身份，拿到开发人员的收益而已。
