这两年经过不断实践，慢慢把自己从一个优秀的程序员，设计者向一个合格的项目管理者转化，除了必要的工作外，我的主要精力都放在了如何去控制项目风险，包括人，时间，和其它不可预见因素。

 

       目前已经基本解决的问题如下：

       1.到底需要什么样的设计才能真正指导程序员的开。其实感觉自己挺土的，设计的方法世面上那么多，原来总觉得难以真正应用到项目中去，并对项目的开发产生关键性的指导作用，笨？ 也许吧 XD  随着自己的摸索，思考与实践，目前已总结出从requirement analysis, platform-independant design, platform-dependant一系列流程中的实现方案，并在若干个有大有小的项目中实践成功，这几年也算在这方面对自己有个交代。

       2.不同的程序员如何估算他们在项目中的作用。我原来的公司拿到一个项目，总是像切西瓜一样直切一下，一人做一块，后来有个朋友就complain：怎样才能区分他们在项目中的贡献度？想想确实也是，比如一个财务系统，做记账的为啥比做对账的拿得多？ 我是搞不了ABC成本法这种复杂的东西，但现在也基本形成了一套区分新程序员，熟练的程序员，有业务经验的老程序员，设计者，“按人分层”的软件开发模式。

       3.注释与代码风格。改变人的代码习惯是很难的，我个人也不喜欢所谓的注释标准，这事一直到现在也是我对程序员们要求的重点所在，感觉自己跟个婆婆一样，天天说，实在不想拿抓一次罚多少钱来限制，所幸情况还是有所改善的。。。。。不过这个问题的直接后果就是现在我考量程序员的第一标准就是：顽固不顽固。。

      

      随着上面问题的解决，现在已经能很好地控制项目中出现的大部分问题，但出现的新问题是：

      程序员过于重视coding本身，忽略了UI，说明文字等其它辅助要素，我不是要求程序员们做到专业文字人员那样的水平，但至少文字清楚没错字，UI按钮摆放整齐美观总是应该能做到的吧。。。。。。有人跟我说这个控制不了，但我确实相信只要是项目中的风险就一定有解决的方法，无非就是慢慢想，慢慢实践。。。。

 

      无奈这几天心里比较乱，今天早上差点在当当上买了个握力器，因为怕自己把手机捏坏（我还真算不错的，中午还跟朋友说，人都不是神仙，家家有本难念的经，只不过我的经比一般人少一些而已；朋友回答：少多了），晚上约了康康喝酒，等过了这段日子再来考虑这个问题吧。