张传波（网名：Fireball，大大大火球）

问题：某政府项目，三个月前就开始招标，因各种原因，流标三次，导致时间拖太长。原计划一期工期三个月+，1月底上线，但因为招投标影响直到一个月前签订了合同，上线时间不变，需求各种不明确，但是客户对上线时间卡得特别紧，范围在一定程度上不可变，时间因为某些原因固定，你们怎么处理？ Fireball的建议：（我的建议）1.对于需求各种不明确的问题这个可能是首先要解决的，可以让你们公司对业务最熟的人出手，或派...

今天有人提到了：大家怎样看迟到这个问题？如果迟到不扣钱的话，自然就没有问题，后面发生了什么事情？你懂的，就是群里炸锅了，可谓怨声载道，各种吐槽，以及“众志成城”的“群骂”（群中骂公司）！

两位美女（不同公司的）先后提出了绩效考核的话题，大致情况是：1）某领导下达任务，分派给质量部的一位女娃；2）领导的想法不太清楚，只是大概知道要提升公司管理水平之类的理由；3）质量部的女娃，没有更多的高层管理经验，软件研发一线工作经验和项目管理经验也比较欠缺。如果你是这位女娃，怎么办呢？

最近做一些小项目，预计是4天，结果几个人时间不合拍，花了一个月。 还有时间也不统一，沟通不方便 ，光沟通都花了不少时间。

老板问搞定这一堆事情要多久：开发说3天。测试说2天。 然后老板第五天来要货，测试提了一堆bug给开发......开发继续解决bug，测试继续测， 直到递归结束…… 如此尴尬的死循环，如何破呢？

群中有朋友提到“封闭式开发”的话题，结果炸锅了！所谓“封闭式开发”，就是无良加班的“雅称”而已……

不少朋友包括公司管理者有这样的美好愿望：1）能借鉴某大企业的现成流程和模板，最好能直接拿来用，期望能在短时间内提升自己公司的研发流程水平；2）希望能有一套研发管理流程工具，帮助将这些流程和模板等落地，降低流程实施的成本和管理的成本。但是理想很丰满，现实很骨感！

我将所有我的电子书汇总在一起，方便大家下载！（持续更新）文档保存在我的网站——软件知识原创基地上（www.umlonline.org），请放心下载。1）软件设计是怎样炼成的？（2014-4-1 发布）概述：有人曾经提出这样的一些问题，也请你思考一下：问题1：我不喜欢编程，但我想成为优秀的软件设计师，请问有什么途径呢？问题2：有没有一套系统分析或者是软件设计的方法论，我可以根据这套方法由需求逐步推导

软件设计是为软件服务的，要服从项目的商业目标。一味追求所谓的优雅设计，项目可能会死的很惨。客户购买的是软件而不是你的设计。如果你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入？那客户只能当你是火星人看了，客户并不会因为你的设计如何精妙而原谅你的推迟交付和增加费用。如果为了节省时间，忽略设计或者粗略设计，项目同样很可能会死得很惨！没有想清楚就动手，就相当于冒着大雾往前走，可能走错方向，可能跌入悬崖……

人类文明不断地进步，并不是现在的人比古代的人要聪明，而是我们能不断地“复用”前人的知识、经验。你能不能成为优秀的软件人才，也视乎你能不能不断地“复制”你的成功。一流的软件公司，关注的不止是在技术方面的复用，实际上软件开发过程中几乎所有的东西都可以复用！

为方便大家找到合适的文章，我将一些精华文章的索引汇总在一起，只需要轻轻一点就可以快速达到你想看的内容啦！目前已经汇总的文章又：“软件设计是怎样炼成的”系列文章、“神马是敏捷”系列文章、IT项目求生法则系列文章、需求分析挑战之旅系列文章、UML扫盲文章、设计模式扫盲文章、CMMI扫盲文章、IT职场求生系列文章等。

春运到了，12306被推上了风口浪尖，大家将买不到票的怨气全部吐在12306上！几年前火车票已经实名制了，那黄牛应该就找不到赚钱的空间了，但因为业务流程上的漏洞，造就了黄牛存在的空间。如何改善业务流程，让更多的票到真正需要的人手上呢？

计划赶不上变化，计划还要不要写呢？项目工期限死，估算有什么价值呢？只有项目经理紧张项目，其他人是打工心态，怎样办呢？PMP的知识能搭救项目吗？如何才能做出一个按期交付的完美计划呢？所有问题，将在这一篇中大爆发！

这个话题已经讨论很多次了，几乎每次都是血泪史，今天群中又有朋友提起了这个话题，具体内容可能会比较敏感，就不细说这位朋友的具体情况。下面简单谈谈我关于绩效考核的看法，以后有机会再为大家分享更多。

关于股票期权的话题，公司给股票期权员工购买，我买还是不买呢？文中的建议会比较“血淋淋”，一般人可能受不了噢，哇咔咔:D

本文有两个来自真实情况的案例，因为涉及到“私隐”，部分内容经过处理。两个案例分别是：1）新创业团队员工积极性差的问题；2）小股东在两大股东的斗法中的取舍。

会挑刺的人很多，会显摆的人也很多，能干活的人很少；能干活的人也不少，但很多是默默无闻的“老黄牛”；能干活，能领会领导意图，能和同事好好相处，能恰当地表现自己的人就很少了。被外派的工作是很复杂和高难度的，处于各方利益交集点。你可以利用利益掀起大波浪，成为逐浪高手！

问题1：做项目的时候，一般利益分配的比例是怎么样的？问题2：一般情况下，提涨薪应当在项目上线前提申请，还是上线后？问题3：公司有个老油条，天天不干什么事实，分配的任务也拖拖拉拉；问题4：老板变本加厉挑毛病，但我提出离职后态度好了。

战斗在第一线的，直接面对客户的实施，他们的反馈往往是最有价值的，但往往得不到重视；而直接开发产品的部门，确经常躲在后面，不能直接面对需求和客户。 这样的队伍配置其实是挺坑自己的。

对于维护型项目，是不是可不可以不用按照一般的软件开发流程走，有没有什么更简洁高效的流程来管理呢？每次都有计划，实际情况比较多，比如来个紧急需求，比如严重bug，导致不能按照计划进行，导致计划不断往后延，这中间怎么平衡呢。

部门赶工，团队成员都积累了上百个小时以上的调休时间，然后闲下来了，调休潮来了。批准太多，怕影响不好；不批准嘛，这些时间难消。采用每月每人只准调一次，每次同时调休人员不得超过20%的人数，这样处理，OK不？

团队里面不适合的人（能力不行），需要踢出，但这些人又是老板招的，你会怎么解决这个问题？这些人不是黄马褂的话，还是比较容易解决的。但如果是黄马褂呢？也是可以解决的！

做为一名现场实施人员，面对某x系统，一片空白。好不容易整明白点了，又发现x系统与某xx系统有关系，再深入一点，还与某xxx系统相连，后面还有更多的xxx..系统，没有源代码，没有文档，偌大一家公司管理上竟如此不规范。客户提出需求后，整理发给总部的开发人员，N久不能修复 ，还整天帮他更新调试，拿到输出结果再发邮件他，净瞎忙活，不指望开发之后，开始自己反编译、网络抓包、猜测数据库这些方式去搞了，干的全不像实施的活，这种情况怎么破？

有朋友问：软件系统上线后是运维流程还是开发过程，需求变更量较大的情况。回答：这不是二选一的问题，而是……

项目已经进入到运维阶段，公司安排了一个运维人员现场驻点，但已经多次接到客户的投诉，说运维人员做事没有交待，做事比较慢，要求换人！我应该如何处理呢？换的话对他不是很好啊~

曾经有几次系统集成（高级）项目经理课程，我发现学员当中有不少是没有项目管理或项目一线工作的经验的，但是他们是“项目经理”这样的头衔，你猜是怎么回事？有些公司是 “项目经理+技术经理”的模式，有些则项目经理需要身兼多职，有些公司有专门管项目的PMO（项目管理办公室）…… 总之情况很多，可能会烦死你！

坦白说听到要连续出差两三个月，期间还不能回家，差旅标准又很低，还来问怎样“人文关怀”员工，我就想开骂了。你能不能学学一些公司，出差期间每周都可以飞机回家（可以报销），实在不行两周回一次家？员工的后顾之忧你不解决，这叫什么“人文关怀”，你要压榨就压榨到底就是了，不要这么虚伪了！

项目立项后才会在项目管理系统上创建该项目，那么问题来了，项目前期的工作量就无法通过系统收集和统计了。似乎解决办法也很简单，就是在立项之前就在系统中创建这项目就行了，但研发老大居然不同意，难道立项前的成本不需要考虑吗？

直到最后几天，测试工程师们才能见到软件的“庐山真面目”，但是不见不知道一见吓一跳，软件的问题巨多，甚至很多功能没有实现，然则距离“项目死期”（交付日）已经没有几天了！难道测试仅仅是项目后期的事情？曾经何时作为程序员的我是看不起测试的，不少程序员也不屑于去做测试这个职位，难道测试工程师真的比程序员低人一等？

安装部署系统、培训客户使用系统、推动系统上线等工作就是实施工作。实施工作的重要性有点象足球比赛的“临门一脚”，前面所有工作都做好了，如果临门一脚特别臭，前面的工作都会付诸一炬。实际上实施工作需要从项目一开始就要进行，并且对实施工程师的要求很高，除了技术要求，还有业务以及商务上的技能要求！

大家都喜欢用建筑工程与软件工程做比较，但我们常常所说的建筑工程只是指建筑施工部分，而不是一个完整的建设项目。一个完整的建设项目，由甲方提出需求，设计院根据需求设计出图纸，再由造价公司进行估价，然后公开招标，最后由建筑公司承担建设，建筑工程是典型的“瀑布模型”。而我们的软件项目管理可能是最复杂的一种项目管理，因为我们的软件项目需求不确定，设计（技术）也不太确定！

很多人问如何才能做好估算？这个问题是问如何正确做事情的问题，而实际上要回答好这个问题，先要回答估算要估算什么内容的问题，也就是什么是正确的事情问题。

软件项目经理往往是权力小而责任重大，软件项目的“两不明确两大限死”特点，让我们做项目犹如走钢丝，而且要高速地走钢丝！你的综合实力决定你能否成为优秀的项目经理，项目经理是练出来的。

计划做出来不是用来看的，而是要执行计划！跟踪计划执行的难度和工作量比起做计划要高出好多倍。计划跟踪并不是对照进度计划，按时间检查每个人的任务完成情况这么简单，本文将为你分享：1.建立便捷的项目组内沟通机制；2.建立项目组成员的自信；3.质量投资，减少返工；4.不断思考减少工作量的办法；5.密切留意需要客户和第三方完成的工作。

我们会常说“计划赶不上变化”，我们写出来的计划往往只有一个版本，写完就完了，没有更新，也没有人去用这个计划。计划不是纸上谈兵，更加不是写了就不变，计划其实就是应对变化的最好方法！我们做软件项目，首先要保证我们是在做正确的事情，然后才是如何正确高效地做事情。项目计划是保证我们做正确事情的重要手段，我们先来看看项目计划应该有什么内容，下一篇介绍如何写出这个计划，再下一篇是如何执行和跟踪计划。

计划不是摆设，上篇我们说了计划应该有什么内容，本篇将会分享如何写出实用的计划。写计划的几个要点：1.要站在战略的高度；2.明确计划的“输入”；3.用估算来控制计划，由计划来调整估算；4.制定可执行可检查的进度计划；5.细化近期计划，定下远期计划大节点；6.让项目组各成员详细计划自己的工作；7.持续更新计划。

俗话说“三个臭皮匠胜过诸葛亮”，但实际工作情况往往是“三个诸葛亮不如一个臭皮匠”！软件开发是智力型团队，如何发挥每个人的作用，并将所有人的力量扭成一股强大的项目团队战斗力，这是项目团队模型要重点解决的问题。

项目天天救火，疲于奔命，项目健康状况到底如何呢？我总结了11个问题，供大家自测一下，看看你的项目是活得舒适，还是要投胎转世呢？当然要诊断项目的健康状况，11个问题是远远不够的，但这11个问题应该有足够的代表性，希望对大家有帮助。

摘要：为了满足这个无理取闹的客户，你疲于奔命地处理大量的需求变更，几乎天天加班，做了大量的项目维护工作。但有一天老板告诉你，这个月工资不发给你了，因为你之前为客户做的维护工作是免费的！你会杀了老板还是客户？不要忘记了项目的利润，这是我们每一个做项目的人都应该记住的。事件回放：某项目已经终验好一段时间，但客户还是不断地有新的要求，尽管项目经理已经有点不耐烦了，但为了保持客户满

摘要：你的项目出了严重问题，客户向你公司的领导投诉，你的领导兴师问罪要追究责任！这是测试的错？开发的错？PM的错？还是研发流程的错？中国教育制度的错？社会的错？反正、总之、一定、必须不是我的错！事件回放：某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法