项目的讨论
精确的项目目标
作为主管，值得你好好花时间去设定你的项目目标。目标定下来之后，你就会清楚哪些工作该做，那些工作不该做。例如你是基础函数库的主管，如果你确定了“只有所有模块都使用的函数才是要开发的函数”的原则，那么某个模块要求你开发的工作，就不是你的目标了。
每天花10－15分钟想想目标，并且想些解决的小窍门。例如作者某天是这样想的：
Diego负责该函数的开发，有可能需要一本技术手册。
于是他马上去买了一本。
就这样，明确项目目标，提前把影响程序员专心工作的障碍（包括不必要的会议，email，电话等）一一去除。主管才能把项目做好。
开会与报告
有些会是不得不开的。例如：
1 当某个人必须把信息传送给很多人时。
2 信息需要双向或多向交流，人们必须立即反问才能了解信息。
3 必须亲眼目睹或亲身经历，信息才能传达给接受者，如产品示例。
4 有些事情须通过讨论才能进行。
但开会中断许多人的工作。所以在开会之前，你必须动脑筋想想，你开会的目的是什么，有没有更好的方法达到同样目的。
会议时间应选择工作效率比较低的时段，并且不会打扰程序员顺序连续工作时间的时段为宜，例如早上刚开始上班，下午刚开始上班，快下班时。特别的，如果可以选择的话，在星期一早上或星期五下午开会。这是最没效率的两个时段。
如果会议确实召开了。一定要达到目的。即使是假设性的，有条件的结论。例如，如果其他小组的工作依赖于Diego的工作成果，那么你可以问Diego：“两个星期能完成你的工作吧？”如果他同意了，那么以此假定作为基础和其他小组讨论工作，例如进度安排等。
作为主管，避免在会后让与会者递交一份长长的发言报告。这是双重浪费时间。如果你觉得他们的发言值得记，那么你自己记下来。再次强调，写无用的报告浪费开发人员时间。如果你确实要报告，最好单独进行，并且尽量短。
进度
微软曾有过惨痛的教训，以进度作为项目完成的指导。任何进度落后都是不允许的，bug的不断增加不算严重问题，但只要工作没在排定的时间内完成，就是罪孽深重的。进度取代了项目目标和软件质量，变成了首要任务，每一个人都在疯狂的赶进度。
以Mac Excel项目为例，每周的进度检讨加上报告，是微软用来控制进度的主要手段。除了这些，开发人员害得每周和测试文件人员共同检讨原因和落后状况。可想而知，只要进度落后，文件小组和测试人员只好暂时没事做，所有目光和谈话，都集中在你的程序进度落后上了。
每周经理们会用更新的项目进度报告来更新项目总进度表，然后分发给组员。于是你一眼就会看到本周落后了多少，整个项目因此落后了多少。心痛之余，你翻到后
页看看还有多少未完成的工作，上周是几百项，现在还是几百项，拼命做事，结果似乎毫无进展。就像一个笑话：如果你每次咬一小口，多久才能啃完一只大象？这
张进度表就是一只大象，我们一辈子也无法吃完。
实在是太过分强调进度了。以至于无论我们做了多少了不起的事情，都没有半点成就感。我们被落后的威胁淹没了，再怎么努力，也看不到成功的彼岸。这不是工作本身的问题，实在是那种绝望无力的感觉所致。
更荒唐的是，进度表是基于如下原则设定的：
1 为期两年的项目所有该做的事情都在进度表中，没有任何遗漏。
2 每人每周实际工作时间40小时。
3 对于每件工作的时间估计完全准确。
4 所有程序第一次出来就是完美状态，没有bug，不需修改。
这真是天方夜谈。
教训：不要利用进程表来驱使项目前进，这实在太伤害小组士气了。
在这里，作者提出了他自己的观点：不应该deadline快到了才开始紧张，平时就应该保持适当的紧张状态。多想想如何聪明的工作，不要把时间浪费在没有
价值的工作上，不要浪费别人的时间，用积极的态度推动项目。总之，不应该在dealine快到来时，才动脑筋去想解决办法。平时就应该养成良好的工作习
惯。
如果你觉得时间紧迫，那么你开会总结一定不会说：“这个问题，我们留待以后再讨论……”你和组员一定无法容忍事情的拖拉，要不删除这项工作，要不立刻把它完成。
进度的急迫多数是由于不正确的考虑，不正确的工作方式所导致。如果你定的日程表让组员产生了落后恐惧症，为了赶上期限而牺牲了产品质量，那么该检讨的是这
个进度表而不是组员。如果你定出的日程表是个无法完成的目标，那只不过是打击团队士气。一旦组员发觉已深陷绝境，那你就永远无法让他们表现出最佳状态。他
们就会另某高就，找个是人做的工作。
项目控制
在完成对进度的讨论之后，作者提出了他对项目控制的见解：
1 进度是基于某些因素上软件的大致完成日期。不要迷信它。不要草率定出不可能的期限，导致组员为了赶进度而不顾一切。
2 把长期的大项目，分成几个完整而独立的小项目，各小项目必须有一个主题。这样既能营造适当的紧迫气氛，也让大家有完成目标的成就感。
3 制定测试和质量监控规范，这些规范可能涉及产品的速度，健壮性，安全性等，你必须考虑并定出标准。通过质量检测规范的小项目，才算真正完成。警惕，不要把小项目写成hello world之类毫无意义的测试程序。该有的功能绝对要有，该达到的要求绝对要达到。
4 产品的质量远比期限要重要。发现bug立刻清除。你不会知道一个bug到底有多严重，存在bug的软件产品，会让项目的完成比例被严重高估。更坏的情况下，由于bug的存在，你会不知道项目究竟什么时候能完成。
加班
如果进度落后，那表示有个地方出错了。在没有找到问题并解决之前，不要粗暴的要求组员加班。这种加班是没有用的。
如果你以进度落后为由，强迫组员每天工作12小时。那么他们很可能把私人活动也安排到工作时间里，并且在可能轻松的时刻尽可能偷懒。因为他知道每天必定工作12小时，不妨把私人活动如看新闻等也在上班时完成。加班，通常是浪费时间的面具。
事实上，拼命工作并不是成功的关键，成功的关键是有一个明确的目标，具体而切合实际的计划，以及每天不断的向这个目标迈进。
(微软不强制员工的上班时间，所以作者如此讨论。但事实上，在中国，加班一样是最没有效率的控制项目的方式。即使你强迫员工每天12小时坐在电脑前，他也很有可能面对屏幕发楞。疲倦的头脑是不可能产生任何创造性活动的。)
加班的目的只是为了赶上进度而已。为了改善我们的工作，还有许多手段可以达到这个目的：
1 明确工作目标：程序员是不是被太多的杂务打乱了开发工作？例如不必要的email，不必要的电话、讨论、会议。作为主管，你有责任把这些障碍找到并一一清除，还程序员一个专心开发的环境。
2 合理安排工作：例如，看email应该在早上，中午，快下班时看，不要在开发过程中让它打乱了你的思路。早上是最有效率的时候，让头脑完成有创意的工作，而其他时间用来编码等等。
再一次强调，你必须牢记自己的目标：按进度完成项目并让组员成长。只要你开动脑筋，你一定能想到更好的代替加班的方法来达到目的。加班并不是完成这个目标
的唯一手段，事实上它是最差的，能不能赶上进度且不说，肯定妨碍了组员的成长。它并不是你的救命稻草，如果你依靠加班来完成你的管理工作，或者你该考虑走
人了。
项目检讨
对项目进行检讨总结的意义不言而喻。但要避免大而无当的总结。检讨应该能做到：
1 指出项目的问题所在
2 根据问题，考虑防范措施和实际的解决办法（虽然有可能只是建议）
3 总结经验心得。将来如何利用。
以下是一个例子，给出了两个项目检讨的对比：
第一个：
问题：某软件包的Beta版使用者觉得他们的测试报告好像没人注意。因为bug在每一版都出现，这主要是因为我们没有建立一套系统的方法去追踪外部的Beta测试报告。所以我们将来应更小心的追踪外部的Beta测试报告，并加强后续处理。
第二个：
由于对β测试报告的疏忽。不仅影响了项目，也影响了关联的其他项目。经理已经同意重新考虑三个追踪Bug的系统，我们将在三者中择一使用，以便追踪项目的测试报告，我们还要把bug和清除bug的行动记录下来。
这个报告是很有效的。他提出了清楚的解决方案，详细的执行步骤，由谁负责，什么时候该完成，应用在哪几个项目。还建议了bug的查找方式。
值得一提的是，不要等项目结束了才想什么是值得一写的。应该养成平时经常记录的好习惯，积累是随时的。
管理艺术
评估方式
年终评估是最没用的评估。对员工的评估应该随时的进行。员工有什么不足应该立即指出，并为他尽量想个改善的方法，让他能立刻成长。不要单纯在年终评估记录员工的不足。
沟通技巧
有些员工看起来很依赖主管解决问题，其实不过是他们的沟通方式有问题。碰到这种员工，你可以要求他们：
1 清晰表达他们待解决问题是什么
2 有什么解决方法，包括他赞同的和否决的
3 陈述赞同和否决的理由。
这样下来，通过和员工多次沟通，或者你会发现你的员工并不笨，他们只是不懂得沟通技巧而已。
一句话，你和员工的一起成长是你的目标之一，所以不要采用生硬粗暴的方式去对待员工。动脑筋想些更好的法子。
人员培养
态度正确
你必须让你的组员态度正确。
1 发现bug立刻清除。越晚抓bug越难抓，并且能让程序员总结经验。还有，如果bug太多，那么程序员的功力高下立现。
2 除非我已经完全测试过了，没有bug了，否则程序不算完工。
3 以用户的观点来看待软件，尽善尽美。
4 改正“这不可能”的态度。最好的方法是明确目标，然后找出正确的解决方案。
5 鼓励提问。他可能不知道答案，但他有权提出问题。
6 未完成的功能，绝对不要给用户。
7 善于利用别人的成果。写好的测试过的代码，只要符合自己要求，就应该用。重复就是浪费。
8 注意提高自己代码的复用性。
提高技术
如果某个程序员在你的项目已经毫无进步，并且他渴望提高，那么让他到其他项目去吧，让其他接他的班。短期来看你损失了一个得力干将，长期来看，你为公司培养了两个人才。
新兵训练：先让新人学会一些通用性技术，这样他到其他项目组也能用。然后才让他们学会项目专有的技能。训练他们多思考。在设计阶段，他们要想得很缜密，确
定这样的设计没有纰漏，写程序时要动脑筋，要懂得怎么思考怎么测试这个程序才确保没有bug；遇到bug时，不要乱猜，要思考如何有系统的搜寻bug藏身
之处，要学会判断是否有相关bug没有现身；不但要学习如何对付bug，还要思考如何在一开始写程序时就避免它的发生。同时要了解这一行业新知识不断而
至，他必须不断学习提高，才能跟上产业的步伐。
工作价值
让组员明白，单纯的工作时间是不能衡量员工价值的，程序员对项目的贡献在于：
1 指出我们在哪里浪费了人力？
2 有什么地方可以引用别组的程序代码？
3 有什么自动测试程序的好主意？
4 想到一个符合用户使用习惯的界面？
等等诸如此类。简而言之，你必须开动脑筋定下规则，鼓励员工学习新的技术，养成好的工作习惯，做事更有效率，从而加快项目的进程。而不是用单纯工作时间来判断员工价值。
