管理中什么最重要？是那些甘特图，那些文档模版，那些例会制度，那些考勤吗？
人，只有人，项目管理的唯一内容：怎样面试，怎样确定角色，怎样管理需求，怎样识别风险，怎样争夺资源，怎样交流，怎样激励，怎样授权，甚至怎样写邮件……
匆忙从Engineer提拔到PM的可怜虫，一遍又一遍重复的错误，一个又一个焦油坑……
在Amazon软件开发图书排行里发现了Software Project Survival Guide。97年出版的老书，名气一直不大，我那本还是从打折旧书堆里翻来的，没想到如今又能成为畅销书。
下午16:36：
天津降雨达60mm，麦莎以15千米/小时的速度推进，预计18：00影响北京。
晚上23:23：
麦莎台风减弱后变成的热带风暴系统，虽然势力强，但个头小。而目前北京周围被一片高压带占据，高压系统是个头最大的，“麦莎”顶不过，其外围被挤压缩小覆盖面。目前麦莎转向西北，进入渤海，向辽东半岛前进。
而原有游荡在北京东南的副热带高压，由于受台风系统影响被北抬，正好像一帽子扣在北京头顶，造成下午的高温高湿“桑拿”天气。
补：
2005年的夏天是记忆中最疲惫闷热的一个夏天，工作也很辛苦，多次生病。这次博客搬家删掉了不少“疲惫”、“累”、“睡不醒”一类意思不大的文字。这两条同一天发的短BLOG比较好玩。8月8号那天一直在盼望麦莎台风杀进北京，电闪雷鸣狂风暴雨，可这家伙始终赖在天津没过来。
前天下班忘了关系统。夜里值班师傅报告：晚上睡觉，半夜莫名其妙听到人脸考勤系统说：“您好，请看摄像头”，“再见请慢走”，实验室没别人，夜深人静怪吓人的。于是办公室女孩子们谣言四起。
我的系统识别率相当高，一开始听到出这种事情也很诧异。
仔细计算一下，系统分别使用到了检测算法、定位算法和识别算法。状态策略是和检测算法、识别算法有关的。其中“您好，请看摄像头”是在连续三帧视频都检测到人脸后播放的，那么它只和检测算法有关。
检测算法在CASPEAL测试的FAR(错检率)是2%到3%之间，往少了算2%，连续三帧错误的概率就是百万分之八，看起来可能性很少啊。可是如果计算摄像头视频，1秒处理15帧，1小时3600秒，1天24小时下来总共处理1296000帧。那么1天内出现这种情况的概率为10次。
晚上不像白天，是人工光线，图象的明暗纹理很分明，的确有可能在统计上或者信号频域上和人脸类似；加上晚上视频画面基本上是不动的，一旦第一帧检测错误，后两帧很有可能也会错误，所以“闹鬼”概率更高了。
用数学算算，就不用大惊小怪了。最近更换了性能更好的摄像头和采集卡，以后出现这种事情概率会更低。当然，现在下班我都不会忘了关系统，免得给自己惹麻烦。
昨天晚上玩得很happy，现在工作热情很高。
我们最终采购的是点击的产品。这些天都忙着调试部署软件，发现IM联系人分组无法从服务器下推。自己费劲把上百帐号分好组，却又不能导出给别人用，联系厂商实施的项目经理，想要个导入导出工具，总没回音。早上研究了配置文件和数据库，做了两个试验，拷出了分组，替代了别人电脑上的文件，成功。由于是强行硬crack，只好到领导、组长和办公室秘书那里一个个亲手操作，免得出错，其他人就顾不上了。坦率地说，点击的产品技术和服务都有问题。27日是协同软件实施关键。
刚看到有人对点击老板王志东的评价：
“很沉稳、各方面都很投入，对家庭、工作、个人生活都安排得很均匀，这一点很难。这种状态很重要。看一个企业家能做多大的事情，只要看一个参数就可以看得出来，就是他放松到了什么程度。”
下午沉下心又做了次努力，居然查清了人脸识别考勤系统的故障原因：其实是两个很幼稚BUG的叠加。
系统很长时间不能工作，视频采集的驱动又给我捣乱，在VC7 debug环境下rebuild，会导致系统重启，组长怒了不止一次，郁闷了好几个月。
把代码依植回VC6，每个步骤中间结果都写到文件里去。重新生成一次特征写入数据库，半小时，然后憋口气查找，调试，再生成数据，再调试……bug虽然藏得很深，但如果更勤奋认真一点，不至于头痛这么久。反省。
昨晚下大雨，早上果然大堵塞，海淀桥、中关村、上地一线彻底瘫痪，上班族浩浩荡荡步行前进。已经多次出现下雨导致市政设施瘫痪，难道就想不到购买防水设施？
去年暴雨导致立交桥水泵失灵，涵洞被淹，连大公共都被没顶。据说不用潜水泵的原因是便宜，占地面积小，所以国家拨款（购买和修建泵站）就会少。
很多媒体习惯一遇到交通问题，就怪私家车。国内情况不同，即使北京这样拥有两百万私家车的城市，政府用车还是比私家车多。高收入阶层的确对交通恶化有责任，但不负主要责任。
交通不仅是工程技术问题，明确问责后，非典都能迅速扑灭，何况每年预算几百亿的项目。
移植人脸识别检测SDK的事情终于有眉目了。明天开始集成测试。
先把算法从VC6.0升级到7.1，尽量符合C++ ISO/98标准语法；然后去掉MFC编译头，自己实现必要的类；接着移植到Eclipse + CDT + CygWin环境下；最后才移植到Linux下 （还是用Eclipse + CDT 编辑）。
最初的检测部分算法依赖OpenCV。移植到最后一步，安装linux版OpenCV编译通过，可CppUnit单元测试总是红色。一步步检查回去，才发现原文大量修改了Windows版OpenCV库本身的代码。原作者修改时没有标记和注释原因，虽然仅过了半年，他已经记不清到底干了些什么，最终只好从头移植另一种检测算法。
大量类似问题都是不良风格造成的。不考虑代码会给其他人使用，不预计以后升级移植时怎么修改，写不出好气味的代码。
Eclipse + CDT 帮了大忙，无论是J2EE还是C++，Windows还是Linux，我已经离不开这个工具了。CppUnit在VC6.0、VC7.0和gcc下工作都很出色。红旗4.1扭转了我的恶劣印象，虽然还是更喜欢Magic。
技术上自信的原因之一，就是比较擅长阅读别人的代码。这的确是件苦差事，但能锻炼能力。
上周日应付两件事：图形学考试和863课题专家组验收。紧张。
周六加班到半夜0点才打的回家（幸亏负责的大哥帮了大忙），然后强打精神复习到凌晨4点，临睡还惦记着Bézier和B样条曲线的线性方程。直到早上提前去考场借到全国大纲例题和参考答案，看了一遍，才算踏实了。
幸亏没偷懒，考题量很大，复习的内容都是大题。写到最后实在太累了，差点把Bresenham图素生成算法的程序写错了。结束以后很多人愁眉苦脸，我还行。
下午参加863课题专家组验收，演示，专家的焦点不在工程产品演示，顺利过去了。
也算搞定了两件心腹大患。
虽然销售人员目的性很强，功利性气息多了难免不讨喜，但这本来就是彼此的工作，能成为合作者有效工作就很不错。事实上，好销售的性格一般都成熟大气乐于合作。
价格总是最敏感的，这方面都是老一套：试探对方的底线，对比并强调各种细节（实际上对比内容未必重要）。采购方的优势在于有多个竞争者，可以得到充足的各种论据难为销售方。
随时寻找机会把某个人（例如对方的上司）作为突破口，以接近对方的底线。反过来，谈判时应该随时拥有一个“上级”；但实际上，一开始就要求领导承认你的决定权。
很多著名的谈判技巧，例如保持沉默和耐心，不一定是必须遵守的教条。例如两人可以分别唱红白脸，前者适时泄漏些信息：“竞争对手报了更低的价格”、“领导对产品不太满意”……再由后者主导接下来的谈判。关键在于坚定和敏感，记住采购最初的核心目的。
管理最终归结到人，所以必然和绩效联系。
经济学的角度，人是贪婪的；行为学的角度，人是懒惰的。建立体制，确保企业对人力资源的投入和回报成正比，这就是管理。单纯树典型搞运动，要求每个员工阅读《把信送给加西亚》，而不改变工作流程和考核方式，都很表面，甚至被当作愚民政策。
好的绩效管理不会破坏信任感，而会激发一部分人的成就感，使他们愿意在职责外加倍投入，这些人恰恰是可以重点培养的骨干。
软件工程实施中，明确的考核倾向至关重要。没有谁完全喜欢规范化的东西，说到底，工程化管理是依靠增大个人工作量换来团队利益。所以需要管理层拿出态度和方案，让团队业绩和实施效果挂上钩。
当然培训也很重要，软件工程培训的重点，应该是强调现代软件工程的最新进展，让员工忘掉大学教材里的官僚主义，熟悉版本管理工具、自动Build工具、BUG追踪工具、单元测试工具、UML建模工具……