工作至今，大大小小经历了一些项目，大多没有什么好结果，但是经验还是要总结的。
明确项目价值
每款产品都是基于一定的目标而设计研发的，无论是实体还是软件，而在走向产品甚至企业的终极目标的过程中，往往是分阶段来实现的，而各个阶段的具体工作则会划分为各个具体的项目。
所以，每个项目开始的第一步一定是明确项目的目标是什么，基于怎样的背景情况需要来做这些事情；而这个项目是否有存在的意义，是否能达成目标。还需要明确的是，项目在整个更大范围的价值链条中的位置是什么，需要发挥怎样的作用。
举例来说，比如现在企业要跟代理公司进行一项广告代理合作项目，需要团队承接广告合作相关功能的设计开发任务。
在这个例子中，项目的目标是什么，是要通过合作，利用代理商的市场开拓能力实现盈收的提升，从市场容量以及客户的价值考虑对于营收的提升空间，以决定是否应该做。而团队在整个价值链条中的位置和价值是什么，是完善基础建设，实现合作所需的功能。
沟通确认需求
接下来需要的是，从项目目标出发，根据已确定的大模块，与利益相关方妥善沟通，汇集需求。以实现目标为目的，考虑每项需求的当前价值，思考应该实现哪些需求。
结合产品的系统构成和目前的运作情况（这步工作需要在日常工作中细化完成），分析需要细化的需求，简单说就是哪些已经能直接提供了，而哪些还需要重新设计。
同时也能确定具体的需求具体是哪一方负责的，需求细化的过程中或具体需求通过后可以很明确的知道需要找谁沟通，不会像无头苍蝇一样，拿着一堆需求到处问人，到处跑。
细化需求的过程就不细述了，只说说其中的沟通关键点。在细化需求的时候就可以把各个部分负责人拉到一个讨论组里面去，内/外部的同事需要分在不同的组，根据项目给小组命名（这步很重要，因为总有一些核心开发或者公共资源，一个人跟好几个系统，好几个项目，避免他们乱套，最好分清在哪个组是讨论什么的，哪怕串错们的时候，项目组也会有人指出，避免不必要的精力消耗），出了问题，或者有需要沟通的内容，就能在对应的组里找到对应的人。
在涉及到多个利益方合作的时候，需求审核就变得很关键了，特别是当利益方来自外部，往往涉及到各种利益妥协，这个时候往往需求会改很多次，内外部都需要作出很多调整，甚至会影响到既有的工作进度，但是永远不要忘了项目的目标是什么，坚守能实现目标的事情。
下发执行-控制进度，合理取舍
确认需求之后，主要的事情就是具体下发执行了，这个时候关键的就是准确传达和跟进了。
需求传达要让每个工作相关负责人准确了解项目的背景，以及期望达到的目标，这样大家工作的时候可以有个标的，明确哪些工作是必要的，需要把工作完成到什么程度。这点很重要，每个人都希望在工作中能有更多的参与感，而不是执行机器，团队成员了解的更多，才更有利于最后达成一致的结果，而这部分工作从一开始沟通的时候就应该做好。
明确需求后，团队的每个部分需要估量好工作量，确定具体的项目时间表，这个时候如果有外部利益方，往往也需要再沟通，曾经试过本来评估好大约需要15天的工作，最后被压榨到只有7天，那么开发就需要去重新设计简化方案了，出来的结果。。。虽然会有这样的无奈，但是项目推进的节奏需要做到前紧后松，保证进度。
具体设计和编码，专业的事情交给专业的人处理，但是具体的结果需要审核监控，以免出现设计觉得美但是没有任何效果的产物出现。执行的过程中如果什么问题影响进度，应该让团队成员及时反馈沟通，那个讨论组又能发挥作用了，实在处理不完的事情，紧记目标，妥善取舍。对于出现的问题记录在案，事后分析清楚原因，转化为流程上的改进点，多数技术上的问题归根结底还是人的问题。
测试上线的时候有可能会出现bug列表从残留的1页飙升至10+页，唉，这时候应该把对项目目标影响大的先处理了，保证项目能正常运行，其他的该变成新增的残留物，就新增把，资源永远有限，问题时时都有，只能处理关键的。
上线后-数据监控，反馈调整
数据监测的需求需要在需求规划和细化的时候就明确好，上线后，数据对于项目是否能达到既定目标提供了一项标准，是一种验证假设的手段，也为改进提供了方向。
根据结果反馈确定当初的目标假设是否真的能达成，及时确定项目是否有继续投入的必要，该割舍的时候，大家应该站在实际价值的角度来思考问题，团队付出的越多，不能代表就能获得更多的回报，坦然面对真实的结果，及时斩仓，把精力投入到更有价值的地方是更优的选择。
项目总结
项目执行出来的结果，或得或失，无论对个人还是对团队都是宝贵的财富，应该及时转化为可用的认知，在以后其他项目的开展中运用起来。
而很多时候项目的开始并没有太多的决策权或选择权，很多想法值得尝试，是否有价值其实很难在没做过的情况作出合理评估，那么选择合适的迭代速度，及时总结反馈，对于项目负责人或更高层的决策人来说就变得异常重要。
