我是一个对日软件的项目管理者，从事软件工作已经8年有余，我从普普通通的Programer到项目经理，经历了被人管理和管理别人。我赴日当过IT“民工”，体会了国内软件管理模式和日本软件管理模式的相同与不同。下面我跟大家分享一下我在管理过程中的一点点心得。
软件开发，归根结底是让客户满意，看到高质量的产品。所以对于管理者来说，如何在规定的时间，规定的成本，规定的范围内，完成高质量的产品，成为评价一个管理者是否优秀的基本标准。
现实管理过程中，作为项目经理的我们很少有机会接触到成本，我们看到的只是时间和范围，我们的组员天天也都是各担其职，在规定的时间做好项目经理分配的任务。但是组员按期不能完成任务，是我们平时工作中经常会遇到的问题，模块担当者由于经验不足，能力不足等等原因，在开发中前期没有足够的能力判断自己能否胜任分配的工作，以至于时间马上就要到了，才发现已经无法在规定的时间做完。这时候才报告给项目经理，为时已晚。
轻者可以通过增加人员，加班加点把进度赶回来，重者影响到这个项目的成败。所以跟踪进度，召开定期的进度会，能够有效的使项目经理了解项目整体以及各模块的进展状况，提前做好预防措施，避免项目整体质量受到严重影响。
开会，有些人喜欢而有些人认为是浪费时间。从我个人的角度，作为一个项目管理者，很好的了解你的组员，很好的了解你的组员担当作业的状况，定期开会是必不可少的。
好多IT业的项目经理，大学学的都是计算机专业，而且大多都是技术上的尖子，对技术的研究胜过对于“管理”的思考。他们有时候会把较难的工作分配给自己，每天埋头苦干，加上管理上的琐碎事情，好多这样的项目经理，总是感觉一天满满的，压得自己喘不过气，根本没有时间开会或者思考项目中的不足和需要改善的事项。
我想对这样的管理者说，既然我们走上的管理，我们就需要足够的信任自己的组员，让他们茁壮成长，慢慢的担起重任，也给我们自己喘息的时间，发现项目中的缺点和不足。完善自己的队伍，这才是我们应该注重的工作重点。
对于项目经理来说把握好了时间，想要得到高质量的产品，另一方面就是把握好范围了。
东西做完了，东西做的好不好?是不是客户想要的东西?是不是完成了所有式样书的功能?功能上是否还存在缺陷?这除了需要我们更精细的测试，还跟需要完善项目的确认流程。
组员向你汇报“程序写完了”，你的第一反应是什么呢?继续测试?还是先确认代码?
好多国内公司缺少代码确认环节，同样是一个项目编出来的代码，代码样式形形色色，花样百出，而且有时候实现同样功能的代码，会出现在不同的代码文件中。组员完成的代码，功能可能都不会有太大问题，但是代码的质量是一个不能被我们忽略的课题。
我们反复强调代码的一致性，代码的共通性，其实就是为了使我们编码的流程更加规范，编出来的代码效率更高，可读性更好，更便于维护。所以在程序完成后，开一个代码确认会，我认为还是比较必要的。尤其在项目初期，模板代码的质量可能直接决定以后编码的工作效率及代码的规范程度。
在代码确认会上，担当组员主讲代码实现功能，其他组员随时参与意见，会后整理代码的指摘事项，作成checklist，以便后人能够参照，避免同样类似问题的发生。
UT结果更是同样，担当者往往都认为自己的代码不会有什么大问题，测试有时候过于敷衍，有些测试事项可能都没有实际执行，出于自信，写上“确认完了”。这样的事情，我相信在每个项目组都会出现。所以最好的解决
办法是，找一个担当以外的人进行测试结果的确认。而且确认后往往需要对于发现的问题，横向的展开调查，以防同样类似问题的发生。
现在我管理的项目人数较少，人员能力比较平均，项目组气氛比较柔和，管理压力相对较小。
因为一直没有系统的学过管理方面的知识，所以去年参加了PMP培训，补了补管理的基础知识，受益匪浅。管理是门学问，自从参加了PMP学习，我才发现我的管理之路才刚刚开始，需要走的路还很长很长。