rest001555的专栏

我们的软件开发存在着巨大的风险，当我们经历了数月的辛苦工作后才发现，我们的软件并不是客户满意的软件。这时候往往出现几种情况： 1.客户开始频繁挑刺，大量的需求变更在很短的时间发生，加班再所难免，团队士气降到最低点； 2.甲乙双方开始相互推诿，谁是谁的责任，争吵不可避免，甚至最终谈判破裂，项目失败，双方不欢而散。 这些都是我们不愿看到的，却不得不面对。到底问题出在哪里呢？就在

其实做一个项目经理真不是一个好的职业，它需要太多的千锤百炼才能修炼出来。这不仅需要反复经历“失败-总结-再失败”的轮回，而且需要有一颗无比坚强的心，能够在无数次经历无比艰难并且令人沮丧的时刻而能坚持不懈、毫不气馁。一个项目经理就像一位将军。将军百战死，而项目经理呢，经历无数项目以后沉淀下来的，更多的是疲惫与沧桑。 但凡一个好的项目经理都是要经过一次又一次项目失败的教训，似乎只有失败才能留

前面我们提到了迭代式开发的巨大优势，它可以降低我们软件开发的巨大风险，它可以使我们把握用户的真正需求，它可以使我们从错误与偏差中及时纠正过来，那么我们应该如何进行迭代式开发呢？要回答这个问题，我们首先要弄清迭代式开发与传统的瀑布式开发的差别在哪里。 1.需求分析的差别 与传统的软件开发一样，迭代式开发同样需要与客户进行一个充分的需求分析。但与传统的软件开发不一样，迭代式开发不要求初期

我们的软件开发存在巨大的风险，但问题到底出在哪里呢？这对于问题的解决至关重要。 1. 我们在没有深刻理解业务需求的情况下就必须完成需求分析； 2. 客户在没有弄明白自己的真正需求的情况下就被要求确定软件的业务需求； 3. 我们在没有与客户再次沟通的情况下埋头苦干，直到完成开发并交付客户。 既然问题出在这里，我们就可以制订我们的解决办法： 1. 业务需求的分析不再是一

在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工作时间的30%。无论是管理一个团队，还是一个分部，还是整个公司，当技术经理用在编程上的时间低于30%时，他执行职责的能力就会发生严重退化。 我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。每次晋升，程序员们都期待花在编码上的时间会大幅度减少，当从“leader”爬到“经理”职位时，就应该彻底脱离编码活动

也许你是一位项目经理，也许你是一位项目骨干成员，或者开发小组长。在我发表“如何提高代码质量”的这一系统文 章后，有许多网友都向我抱怨，说他无法把握整个项目组成员的代码质量。我想，这也是所有项目组普遍存在的问题吧，它通 常表现为以下几个问题： 软件项目普遍存在的问题 1）新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太 短，往往技...