项目中需要时刻提醒自己的六件事

一些心得，写下来时刻提醒自己。

1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。

2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......

3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好

4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。

5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...

6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...

bullshi*!
建立在垃圾之上的只能是垃圾。花一天作出的砸碎，可能要花一个月去改


每个人只能熟悉自己做的东西。让最熟悉的人负责最熟悉的部分。


第一次听说客户还会这样


只要您充分实现了所提的第一条和第二条，这样的结果，丝毫不足为奇

呵呵，这些条目很容易被反驳，可是当你理解了，就是你的进步......

如果你还是只想着反驳，那你就当这是只写给我自己看的好了....

楼主的经验比较特别哦，表面上看起来是在提倡一些非最佳实践
我想你总结出这些经验都是有道理的，但这些道理的前提偏偏没提出来，难免招人批驳。能否花点时间细化一下，再次共享出来？

我要是理解了，我就退步了。。。

第一条第三条深以为然

总之，交流是第一位的，一天出来的杂碎，就可以作为进一步交流需求，进行下次迭代开发的基础，实现往往应该优于设计的，如果闷头想一个月设计一个月，说不定出来的东西和真正需要的是离题万里。

第三条，我总是发现我们做出来的东西和客户的需求有差距，绝大多数时候，是比客户想的多了，而我们做出来的这种比客户需求更多的部分，又会引导客户有新的想法，很多时候对客户需求描述的不贴切和实现上的差距，是需求变化的一个引发原因。

有litchi的见解，足证吾道不孤！！

第一、三条litchi已经解释的很清楚了，我再对剩下几条做个说明。

2.以人为本
作为技术人员出身，我经常会在项目中偏向于选择我喜欢或者熟悉的技术和架构，哪怕是新技术和新架构。或者在项目中炫耀自己某方面自以为高深的技术。可是作为项目管理人员，这样做是错误的。项目管理人员应该选择的是最适合团队的技术和方法，分配每个团队成员最适合的任务，这样不仅每个人都能干的轻松，项目也会有更好的质量保证。另外还要注意工作量的平衡，记住中国人的心态，“不患贫，患不均。”

4.每天都是一个成功
这一点是专门对付项目压力大这种情况的。有时候，上司催促，客户质疑，剩下工作还相当多，心态是每况愈下，每天“放弃”两个字都会在大脑里打转。这时候，定下一步一步走的计划，即使工期紧，但只要每天的任务都能完成，心理压力就会小很多，面对上司和客户也可以拿出成果有个交代。皆大欢喜。

5.量力而为
这个标题已经是很好的解释了，相信量力而为的道理大家都懂。该放弃的时候就不要死撑了。

6.横向储备
这一点是为了提醒自己要时刻记住学习，现在，新技术发展的速度太快，多掌握一些，项目中就会多一种选择，或许会更省力。人才也是一样，要经常补充团队中缺乏的人才，要不然，没人用的时候只能自己动手，没人可怜你的。

LZ很有见地。
对第一条，LZ表示的意思是：在条件尚不明的情况下，是可以先动手试试的。和XP的不预先设计一样。
不过我想如果能稍花些工夫（半天）想一想如何做，也是非常不错的。

XP有说不预先设计吗？ No big upfront design可不等于No upfront design

过尤不及，楼主只说了事情，没说程度，感觉是意识之争。
就如第一条：
谁都知道垃圾程序是项目杀手，但当然也不能花一个月去写一行所谓“完美”的代码。
这些所谓的“经验”不说也罢。