原文：http://www.javaeye.com/topic/600042
一年来很少写日志，更多地是项目开发和研究他人的经验和知识。
做开发4年来，给我一个总体的感觉是痛苦并且快乐着。相信很多朋友和我一样，解决了一个棘手的问题，更有甚者这个问题他人不能解决时，成就感油然而生。至于痛苦的方面，这可能和他人不同，我很少会为不能解决的问题而困惑，更多的是来自于团队合作和团队工作质量。有时候，会对队友很失望，无论是经验程度，还是处理人事的方法。
对于软件开发，笔者一点体会，简单地说，为了一个共同的目标，一个或多个团队相互合作，产生一定“结果”的社会过程。个人偏好地认为是一种过程，通常来说，由项目立项、可行性分析、需求分析、架构设计和技术选型等等。在不同的场合，这些过程增加或者减少。无论怎么样的变化，其决定性因素的还是人，处理好人事等于成功了一半。在软件工程，没有{zh0}，只有更好，永远牢记着只做正确和适合自身的开发方法，尽量不要教条主义和理想主义。笔者曾经就犯过错误，严格地按照敏捷那套执行，开始就遇到了同事的反对，理由是他不能理解，执行起来困难重重，照搬是不行的。
万事开头难，尤其是软件项目，把握需求是困难的，一般而言，很难做到所有的需求细节一一列出，只可能在一个相对抽象的需求上不断地“演化”，甚至发生变化。开发人员最苦恼的地方莫过于需求变迁所带来的反复开发或者修改，所谓的“Change is welcome"，那是“Communism”。若要把项目致力于灵活多变，无疑是困难的。从事多年开发的同仁会感觉，如果有一个不需要编码，只需要简单配置，能够完成需求，那该多好。不过，据我所知，不管模型化建模，还是代码自动产生器都不能很好完成需要，毕竟需求是各异的。
找不到理想中的“乌托邦”，最终还是回到现实。重担还是落在开发人员身上，开发人员面对“脆弱的”需求，尤其是架构师团，更需要抽象业务逻辑，构建需求的蓝图和界限。笔者认为成功的架构师是务实的，我见过不少“理想主义“的架构师，写出来的方案有点像“八股文”，甚至一些方案在实际情况中是“死胡同”。
架构设计并不是越抽象越好，更不是越技术先进越好，成熟大于高新，务实大于花哨。
说句题外话，我看到过很多同学，尤其是初出茅庐的，在简历上面写了不少的“高新”技术，动不动就是“精通”的字样，有经验的HR看都不会看这样的简历。反思一下，为什么不少公司招聘信息注明，行业经验优先考虑。不难看出业务理解优先于技术实力。技术是要落到实处来解决实现的问题的。好比钞票，如果不流通，它就是废纸。
架构设计和技术选型之后，详细设计，一个和客户或者和开发人员内部讨论过程，无论你的角色是什么，沟通的素质是必须的。作为开发人员，要了解自己的输入和输出。作为项目经理，需要合理安排人力资源和协调团队，同时和客户互通。
人力资源安排是一门大学问，首先需要了解团队人员的素质，主要是技术实力和需求理解能力，其中需求理解至关重要。
项目经理好比xx中的“帅”，架构师好比“参谋”，开发人员则是前线将士。团队的执行力，往往决定项目的成败。首先，需要了解部下，一个稳定的团队是相当重要的。众所周知，IT行业是一个流通性相对比较大的行业，尤其在时间拮据的情况下，大多数通过面试手段来招募贤士，少数则是通过推荐。无论哪种方法，在短期内，知人善任是困难的，项目经理很难全面的了解开发员的才能。笔者就遇到了这个问题，开始觉得挺不错，感觉后来越来越差，人才真是凤毛麟角。当项目进行到一定阶段的时候，临时“易将”是不明智，重新招募和培训新的员工，无论是时间成本还是人事处理都是不合适的。一个权宜的方法就是培训员工，因为技术和素养是可造的。一些上了年纪或者有家庭的员工很难进行“培训”，其兴趣和精力不在于此，处理这样的问题比较棘手，至今效果不理想。
事情不能改变的时候，只能适应其规律。
接下来，沟通和协调团队。它是双向的，逐渐地了解队友的习惯和素质，合理地安排任务的分配。笔者举一个二期开发项目的例子，见到的一个常景就是，各个队员开发个自己的小模块并且保留接口，接口之间可用性和风格各异。由于笔者偏好开发，因此有“Code review”的习惯。出于尊重前辈（笔者的年纪最小，平均小了10岁），时常在代码上面添加注释，建议修改或者改进。由于项目前期，测试用例极少，导致了目前修改后的bug不断，项目中出现了相互职责的问题。经过一段时间的调整，最终统一了意见。过程可以说是步履维艰，其消耗了大量的开发时间。在一个团队中，很少的人对软件的思考，过多的是实现功能性。软件作为一门艺术，开发是苦难的。如果仅仅停留在功能性实现的层面上，可以说没有什么价值。若把它定位到哲学高度，则是力于美的结合。虽然软件是虚拟的，但是它能够体现一个团队背后的智慧，从学术的角度，就是软件的制造工艺。工艺水平直接或间接地体现了软件的架构能力。提升团队的素质，应该从这个方面入手，有限地提高。
顾客就是上帝。
有时候这些上帝也比较“疯狂”，提出来很多不合理的需求。相信大家喜欢技术型出身的客户，那样会更有“人情味”。推掉不合理的需求也是一门学问，如果能够化 “被动”为“主动”，那更是“艺术”。处理顾客关系，使用软件技术手段是行不通的。有意思的是，软件工程里面很少有“人文关怀”，而是过多的“工程实践”。笔者认为“人文”方面是不可少的。事实上，项目经理多不是“技术”官，而是“行政”官，不少人误解了其作用。
由于时间和经验的关系，只能写到这里。针对一些问题，我会做“专题”，从行政管理到软件架构，甚至到开发实践方面，相当地欢迎朋友们一起讨论或者指点迷津。
一年来很少写日志，更多地是项目开发和研究他人的经验和知识。
做开发4年来，给我一个总体的感觉是痛苦并且快乐着。相信很多朋友和我一样，解决了一个棘手的问题，更有甚者这个问题他人不能解决时，成就感油然而生。至于痛苦的方面，这可能和他人不同，我很少会为不能解决的问题而困惑，更多的是来自于团队合作和团队工作质量。有时候，会对队友很失望，无论是经验程度，还是处理人事的方法。
对于软件开发，笔者一点体会，简单地说，为了一个共同的目标，一个或多个团队相互合作，产生一定“结果”的社会过程。个人偏好地认为是一种过程，通常来说，由项目立项、可行性分析、需求分析、架构设计和技术选型等等。在不同的场合，这些过程增加或者减少。无论怎么样的变化，其决定性因素的还是人，处理好人事等于成功了一半。在软件工程，没有{zh0}，只有更好，永远牢记着只做正确和适合自身的开发方法，尽量不要教条主义和理想主义。笔者曾经就犯过错误，严格地按照敏捷那套执行，开始就遇到了同事的反对，理由是他不能理解，执行起来困难重重，照搬是不行的。
万事开头难，尤其是软件项目，把握需求是困难的，一般而言，很难做到所有的需求细节一一列出，只可能在一个相对抽象的需求上不断地“演化”，甚至发生变化。开发人员最苦恼的地方莫过于需求变迁所带来的反复开发或者修改，所谓的“Change is welcome"，那是“Communism”。若要把项目致力于灵活多变，无疑是困难的。从事多年开发的同仁会感觉，如果有一个不需要编码，只需要简单配置，能够完成需求，那该多好。不过，据我所知，不管模型化建模，还是代码自动产生器都不能很好完成需要，毕竟需求是各异的。
找不到理想中的“乌托邦”，最终还是回到现实。重担还是落在开发人员身上，开发人员面对“脆弱的”需求，尤其是架构师团，更需要抽象业务逻辑，构建需求的蓝图和界限。笔者认为成功的架构师是务实的，我见过不少“理想主义“的架构师，写出来的方案有点像“八股文”，甚至一些方案在实际情况中是“死胡同”。
架构设计并不是越抽象越好，更不是越技术先进越好，成熟大于高新，务实大于花哨。
说句题外话，我看到过很多同学，尤其是初出茅庐的，在简历上面写了不少的“高新”技术，动不动就是“精通”的字样，有经验的HR看都不会看这样的简历。反思一下，为什么不少公司招聘信息注明，行业经验优先考虑。不难看出业务理解优先于技术实力。技术是要落到实处来解决实现的问题的。好比钞票，如果不流通，它就是废纸。
架构设计和技术选型之后，详细设计，一个和客户或者和开发人员内部讨论过程，无论你的角色是什么，沟通的素质是必须的。作为开发人员，要了解自己的输入和输出。作为项目经理，需要合理安排人力资源和协调团队，同时和客户互通。
人力资源安排是一门大学问，首先需要了解团队人员的素质，主要是技术实力和需求理解能力，其中需求理解至关重要。
项目经理好比xx中的“帅”，架构师好比“参谋”，开发人员则是前线将士。团队的执行力，往往决定项目的成败。首先，需要了解部下，一个稳定的团队是相当重要的。众所周知，IT行业是一个流通性相对比较大的行业，尤其在时间拮据的情况下，大多数通过面试手段来招募贤士，少数则是通过推荐。无论哪种方法，在短期内，知人善任是困难的，项目经理很难全面的了解开发员的才能。笔者就遇到了这个问题，开始觉得挺不错，感觉后来越来越差，人才真是凤毛麟角。当项目进行到一定阶段的时候，临时“易将”是不明智，重新招募和培训新的员工，无论是时间成本还是人事处理都是不合适的。一个权宜的方法就是培训员工，因为技术和素养是可造的。一些上了年纪或者有家庭的员工很难进行“培训”，其兴趣和精力不在于此，处理这样的问题比较棘手，至今效果不理想。
事情不能改变的时候，只能适应其规律。
接下来，沟通和协调团队。它是双向的，逐渐地了解队友的习惯和素质，合理地安排任务的分配。笔者举一个二期开发项目的例子，见到的一个常景就是，各个队员开发个自己的小模块并且保留接口，接口之间可用性和风格各异。由于笔者偏好开发，因此有“Code review”的习惯。出于尊重前辈（笔者的年纪最小，平均小了10岁），时常在代码上面添加注释，建议修改或者改进。由于项目前期，测试用例极少，导致了目前修改后的bug不断，项目中出现了相互职责的问题。经过一段时间的调整，最终统一了意见。过程可以说是步履维艰，其消耗了大量的开发时间。在一个团队中，很少的人对软件的思考，过多的是实现功能性。软件作为一门艺术，开发是苦难的。如果仅仅停留在功能性实现的层面上，可以说没有什么价值。若把它定位到哲学高度，则是力于美的结合。虽然软件是虚拟的，但是它能够体现一个团队背后的智慧，从学术的角度，就是软件的制造工艺。工艺水平直接或间接地体现了软件的架构能力。提升团队的素质，应该从这个方面入手，有限地提高。
顾客就是上帝。
有时候这些上帝也比较“疯狂”，提出来很多不合理的需求。相信大家喜欢技术型出身的客户，那样会更有“人情味”。推掉不合理的需求也是一门学问，如果能够化 “被动”为“主动”，那更是“艺术”。处理顾客关系，使用软件技术手段是行不通的。有意思的是，软件工程里面很少有“人文关怀”，而是过多的“工程实践”。笔者认为“人文”方面是不可少的。事实上，项目经理多不是“技术”官，而是“行政”官，不少人误解了其作用。
由于时间和经验的关系，只能写到这里。针对一些问题，我会做“专题”，从行政管理到软件架构，甚至到开发实践方面，相当地欢迎朋友们一起讨论或者指点迷津。
| 已投稿到： |
|
|---|
