|
锁定老帖子 主题：项目中需要时刻提醒自己的六件事
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (6)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-12-28
呵呵，每个人经历不同，见解也会不同，只能说，不敢苟同
|
| 返回顶楼 | |
|
发表时间：2007-12-29
在很多公司里楼主的建议很好啊。。。
和我们很多做法都不谋而合哈
|
| 返回顶楼 | |
|
发表时间：2007-12-29
唯一的问题是
6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人.
这个不是特别好做到：（
尤其俺们公司，不太容易的。。。。
|
| 返回顶楼 | |
|
发表时间：2008-01-18
第三条，demo中一定要有客户最为关心的的需求，围绕着这些客户的需求去做，尽量不要自作聪明，做一些多余反而会让客户疑惑和误解的工作，这样只会给项目带来没必要的麻烦。
|
| 返回顶楼 | |
|
发表时间：2008-01-23
很实在的经验，管理好自己，让成员管理好自己，教他们如何管理好自己，项目就好做了
|
| 返回顶楼 | |
|
发表时间：2008-01-24
timerri 写道 一些心得，写下来时刻提醒自己。
1.实现优先 这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。 记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。 2.以人为本 充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。 记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家...... 3.demo驱动开发 天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多.... 记住：让客户看到，永远比让客户听到要好 4.每天都是一个成功 与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。 记住：让团队不被压力压倒是每一个管理者最重要的责任。 5.量力而为 如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。 记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下... 6.横向储备 只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。 记住：项目总是会照顾那些有准备的人... 我就是如此做的.也许方法上有所偏差，但是以上的6条，都是我目前遵循的。有部分细节在我和o6z的问答中提到过 http://www.iteye.com/topic/145145 |
| 返回顶楼 | |
|
发表时间：2008-01-24
写的啥呀？
一天写个杂碎，客户会“杂碎”你1个月。 |
| 返回顶楼 | |
|
发表时间：2008-01-25
要这样做,实际上是考验 管理人员的控制能力. 不管是对项目,对客户需求,以及对人员的实际进度这些方面的控制力.
可以这么说, 如果自己没有规矩,那么客户会更加无礼. |
| 返回顶楼 | |
|
发表时间：2008-02-02
横向储备是经常需要提醒自己的并去行动.
|
| 返回顶楼 | |
|
发表时间：2008-02-04
一些心得，写下来时刻提醒自己。
1.实现优先 这个绝对支持。 我觉得楼主说的很对。 而且如果顾客没要求，就绝对不做。一份价格就是一份货。该做的我一定做，不该做的我绝对不做。头头是道说了很多设计啊，优化啊，都没有实现来的实际。 |
| 返回顶楼 | |
