项目的讨论
精确的项目目标
作为主管,值得你好好花时间去设定你的项目目标。目标定下来之后,你就会清楚哪些工作该做,那些工作不该做。例如你是基础函数库的主管,如果你确定了“只有所有模块都使用的函数才是要开发的函数”的原则,那么某个模块要求你开发的工作,就不是你的目标了。
每天花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 想到一个符合用户使用习惯的界面?
等等诸如此类。简而言之,你必须开动脑筋定下规则,鼓励员工学习新的技术,养成好的工作习惯,做事更有效率,从而加快项目的进程。而不是用单纯工作时间来判断员工价值。
创建人:X公司程序员
yunshichen 这篇是我读《微软研发致胜策略》后整理的笔记。身为一个软件开发部门的主管,你的职责是什么?单单完成项目是不足够的,如果你的目标是这样,那么你会做错很多事。我认为准确的表述应该是: 带领程序员按进度完成项目,并且让他们能通过项目中在技术,工资,团队归属感等方面成长。 本文作者用轻松愉快的笔调讨论了作为一个主管,应该怎样管理项目,并且列出了他在微软的一些做法。或者他可能没意识到,他提出的解决方法,其实都是针对一个问题: 你究竟想要做什么? 小到编程,买菜,与人交流,大到管理,人生,无非都是弄清楚你自己究竟想要做什么。弄清楚之后,通常你就能找到相应的处理方法。 读完之后我没有单纯的记下要点,我把作者的观点归纳之后,重写成如下形式。希望能给喜欢读书的同行一点思考的火花。当然了,最好建议你还是去读读这本书,然后写下你自己的见解。当你,我,他都有了自己的理论,或者中国软件业的春天就不远了。
转载于:https://www.cnblogs.com/SoulStore/archive/2007/06/26/796379.html