针对一般家庭，理财师会如下建议：
消费前列出消费清单，并在日常生活中养成记账的习惯，经过观察和分析，便可分辨出日常消费是否合理，便于做好节流工作。同时也可进修一些理财的课程和实践，以便提高自身的理财能力。
理财师讲的话大家能理解吧，不想做月光光、年光光这种很尴尬，很没面子的朋友肯定会去思考，去尝试或者已经在实行中。生活不容易，二八理论很遗憾的一直在我们身边起作用，对于20%，大叔只能仰望，80%随大流，为了生活更好点，慢慢折腾吧。
经验来自于生活，因此针对一般项目，大叔会如下建议：
需求实现前列出需求清单，并在日常工作中养成记录的习惯，经过和项目成员、销售、客户讨论确认，便可以得出哪些需求可做、要花多少人日实现、是不是需要额外收费，什么时候发布，哪些需求不做，便于做好版本规划和节奏控制。同时也可进修一些项目管理方法论、ISO，CMM的课程和实践，以便提高自身的项目管理能力。
我们看看描述中关键的字眼：需求清单、记录、确认、版本规划、节奏控制、方法论。再看看需求跟踪表有什么内容：变更编号、需求单号、问题来源、联系人、联系电话、用户提交时间、开发接到时间、用户要求时限、紧急程度、用户级别、变更类型、涉及模块、发布用户、影响用户、工作量（人日）、优先级、评估结果、计划发布时间、备注、发布编号、需求状态、备注、回复客服。需求跟踪表在某种场景下就相当于理财消费清单，理财很犀利吧，这个大家都有共识，那需求跟踪表在什么时候露出它犀利的牙齿呢，我们在分析项目场景的时候把它抓出来。
项目为什么会失控，大叔个人感觉是项目节奏没有控制好，为了更清晰的剖析，我们分2种场景来讲。
第一种场景，软件第一次发布给客户前，属于研发类项目：
1、如果一个项目开发周期很短，1-3个月内，短平快项目，一般都非常的成功。
2、如果一个项目开发周期在4个月或者半年，甚至在一年以上，大叔见过很多项目做的真是很够呛，很艰难，即使产品出来也是问题多多。
为什么会有这种现象呢？琢磨了半天，才恍然大悟，是节奏问题，你如果有研究ISO/CMMI，就会发现，这些标准实质上就是在控制节奏，可以让问题和风险尽早暴露，让我们及时纠正和解决，让项目目标和实际进展一致。
大叔的建议是把一个长周期的项目分隔成由1-2个月短平快项目组成，每个短平快就是一个版本规划，一个接一个做版本迭代，需求优先级分的越好，问题和风险越能提早发现。
如果你是老板，一个半年的项目，等半年后项目经理才告诉你，以前提出的技术解决方案实现不了，你的心情会怎么样，是不是黄花菜都凉了。节奏控制的好，在第一个版本的时候就会发现了。那个时候调整是来的及的。另外对项目成员来说通过节奏能保持有序的松弛工作状态，该加班就加班，该休息就休息。大叔不信有人会很有激情的持续加班半年以上，哦，20%的人要除外，那些人是用来仰望的。
第二种场景，软件第一次发布给客户后，一般就开始属于维护类项目：
在这个场景里面，最常见的就是客户没完没了的提需求，从客户的角度其实也很容易理解，客户也怕，怕担责任，也要做业绩，所以就拼命的提，让领导认为他在很认真很负责在做事情。这时候客户就像是银行的信用卡中心，拼命的鼓励持卡人消费、再消费，最好都是月光光、年光光，透支再透支。朋友，如果没有按理财的思路去控制，是不是就跟着走，做光光一族。后果是很严重的。没完没了，看不见结束期限的失控项目，过一个月谁也记不住这个月项目组做了什么，如果半年或者一年呢？项目组每个人都觉得很怨，做的越多被骂的越狠，怎么还做不完，老板骂、销售骂、客户也跟着骂。
需求跟踪表方法论就是为这种场景而诞生的。它就是在这种场景下为节奏控制做依据的。在源头上起到控制的能力。客户今天说改A，明天改B，后天又改回A，你是不是觉得很烦，很可恶，但大叔不怕，这些都会成为大叔的业绩，这个工作量可以给老板看，给销售看，给客户看，配合版本规划，报给老板的就是在某个时间段项目组做了多少个版本，花了多少人日，解决了多少客户需求，老板会认为项目组在很努力的给他干活，销售会理直气壮的到客户那里收取费用。有了这些数据客户会感觉项目组很专业。这就是小工具的魅力，这些工具后面就是一个个不可思议的方法论或思想，一个好思路加上简单的工具就很容易去使用，很犀利的。大叔使用的需求跟踪表其实就是一个Excel表格，表格内容在上面已经列出。
发一个需求跟踪表的截图
是不是很简单，哈哈，可是它的作用很大
对于深陷泥潭的项目，
只要老板觉得可以继续投入，给人，给费用
大叔都敢接，
无外乎就是通过项目管理的思想，需求跟踪、配置、版本规划、版本迭代、AB角、代码走查、任务单、BUG管理等方法论去组合，使用这些方法对应的小工具，完全可以把失控的项目调整为可控制的良性发展。
就是贫民窟，也会把它磨成锦绣花园。
