软件随想录(local.joelonsoftware.com/wiki)-2001年12月25日 小员工也能做大事 - Getting Things Done When You're Only a G

2001年12月25日
小员工也能做大事 -
Getting Things Done When You're Only a Grunt

 

The Joel on Software Translation Project:小员工也能做大事

From The Joel on Software Translation Project

Jump to:
navigation,
search

小员工也能做大事

作者：周思博 (Joel Spolsky)

译：Paul May 梅普华

Tuesday, December 25, 2001

属于Joel on Software, http://www.joelonsoftware.com
这个站应该是关于软件管理的，不过有时候你并没有那个权力去改变组织的行政命令。很显然的，如果你只是图腾柱底层的一个普通程序员，绝对不可能命令大家开始建立日程或问题追踪数据库。事实上当你成为经理之后，可能会发现管理开发人员很像养猫，不过没那么有趣。光会说「照这样做」并不真的能照这样做。

在约耳测试分数低的组织里工作可能会让人沮丧。不管你程序写得多好，同事还是会写出让你羞与为伍的烂程序。另外管理阶层在决定产品时也会作出烂决策，所以你只好被逼浪费自己的才能，去为针对儿童的AS/400版退休计划游戏除错(译注：谁家小孩会玩退休计划游戏，更别提能用到AS/400了)。

我建议你大可离开。不过万一你基于某些原因必须继续待著，比如股票选择权还没有到手，或是住的地方太小没有更好的工作，又或许老板抓了某个你爱的人作为人质。不管如何，在一个烂团队里讨生活实在叫人抓狂。不过还是有些策略能从底层改善你的团队，而我要与你分享其中几项。

策略一：去做就是了

有很多事一个人就可以改善项目。没有每日编译服务器吗？架一个。在你自己的机器上设一个定时的工作，在每天晚上编译并把用电邮发送结果。编译的步骤太多吗？写个makefile吧。没有人做可使用度测试吗？用几张纸或VB原型自己去找收发室的人来做吧。

策略二：利用病毒性行销的威力

约耳测试中很多策略都可以在不合作的团队中一个人施行，其中有几项做得好的话还能推广到整个团队。

举例来说，假设团队中没人愿意用错误追踪数据库。别因此觉得困扰，自己去用就是了。把你自己程序里找到的问题输进数据库。如果你找到确实是其他人该修的问题，就用错误数据库把问题指派给他。如果你用了好的问题追踪软件，这时候就会用电子邮件通知他。没有也不打紧，如果他们没有修正问题，你还是可以一直寄电子邮件提醒。最后他们总会发现问题追踪的价值，然后像自愿般地开始使用这个系统。如果QA团队拒绝把问题输入问题追踪数据库，你只要拒绝其他方式的错误回报就好了。等你重复告诉大家约三千次：「请听我说，我很想修好这个问题，不过我会忘记，能不能请你把问题输到系统里？」他们就会开始使用数据库。

团队里没有人要用源码版本管理吗？建立你自己的CVS储存库，必要时可以放在你自己的硬盘上。即使没有人合作，你还是可以把其他人的程序自己放进系统。然后当他们发生某些可以用版本管理解决的问题(通常是误把rm *~打成rm * ~)时，就会来找你帮助。最后大家都会知道他们自己也可以由版本管理取出程序代码。

策略三：建立一个卓越圈(Pocket of Excellence)

团队不排日程？不写规格？自己来写吧。花一两天针对你的工作写份小规格和日程，不会有人因而抱怨的。

找些更好的人进团队。想办法参与雇用面试过程并招募好的人选来加入团队。

找出那些愿意又有能力改善的人，想办法让他们支持你。即使是再烂的团队还是很可能有聪明人在，只是缺乏写出好程序的经验。帮助他们脱离困境，安排他们学习。看他们登入的程序，如果他们做了什么蠢事，不要写电邮高傲地指出他们的程序哪里不对。这样只会激怒并让他们更加护短。应该故作无知地回报该错误会导致的问题，让他们去找出原因。等他们自己找到问题，印象就会深刻多了。

策略四：让笨蛋无害

即使最好的团队都会有一两个笨蛋。团队里有烂程序员让人头痛的地方，就是他们的烂程序会搅乱你的好程序，另外就是好程序员得花时间帮坏程序员擦屁股。

身为底层工作人员，你的目标是损害最小化，也就是所谓的牵制策略。有时候这些天才会花两星期写出一点点程序，而且写出来的东西烂到不可思议，完全不可能用。这时候你会很想花15分钟把这段程序从头再写过。请忍住这种诱惑，因为这是个把这些白痴拖住几个月的大好机会。只要一直报告那个程序的问题，他们就只好一直在这段程序卡好几个月，直到你找不到其他问题为止。而这几个月他们就不会在其他地方造成伤害了。

策略五 ：远离干扰中断

所有好的工作环境都一样(个人办公室，安静的工作状况，优越的工具，很少干扰和更少的大型会议)。而所有不好的工作环境都各有不好的原因。

不幸的是，几乎在任何公司里都不太可能改变工作环境。长期租赁表示可能连执行长都无计可施。这也说明了为何只有少数的软件开发人员拥有自己的办公室。对公司来说这会造成两种伤害。首先是更难以请到顶尖的开发人员，这些人偏好能提供更佳环境(当其他条件相等时)的公司。其次是干扰的程度会让开发人员的生产力急速下降，开发人员会发现自己根本无法进入状况并专心工作。

想办法离开那个环境。拿台笔记型电脑到公司的餐厅去，里面有很多大多时候都空著的桌子(而且没人找得到你)。可以把某间会议室预约一整天然后在里面写程序，然后用工作成果来证明，独自在一个房间作业能完成的工作会多上许多。等下次出现紧急状况，经理要求在明天之前完成工作时，你就知道要说什么了。他们会找间办公室给你在那天用，然后不久他们就会开始觉得应该整年都保有这种生产力。

上下班都晚一点。其他人下班之后的时间生产力最高。如果所在的开发团队习惯晚到，你可以早上九点就来，在其他人上班干扰之后专心做事，这段时间的成果会比后面的时间加起来都多。

不要开著你的电邮和即时通讯。需要的话可以每小时去收一次信，不过不要一直开著。

策略六：提升自己的价值

如果你并不是真的很有贡献，这些策略通通都没用。如果你写不出好的程序，那么你「应该」正在写程序的时候，其实只是在问题数据库里浪费时间还惹人厌。如果你被挂上做不出东西却只关心流程的恶名，大概就没什么职业生涯可言了。

曾经一度当我在某家新公司开始当个底层程序员时，发现公司约耳测试大概只有两分，于是我决定要改善这种状况。不过我也知道良好的第一印象非常重要，所以安排自己在每天前七个小时都照大家的期望单纯只写程序。频繁地把程序登入版本管理，是让开发团队认为你很好的最佳方法。不过我会在每天下午回家前保留一小时改善流程，利用那段时间修正让产品难以除错的问题。我架了一台每日编译服务器和一台问题追踪数据库，还把所有长久阻扰开发的烦恼都解决掉。我针对当天要做的事撰写规格，也写了文件逐步解释如何从头建立一台开发用的环境。内部有个重要的程序语言没有任何文件，我也把它完整的文件做出来了。整个流程慢慢地变得愈来愈好。虽然除了我(还我带的小组)之外没有写规格或日程，不过除此之外约耳测试已经提高到十分左右。

即使你没有当家作主，还是可以让事情变得更好，不过你必须像凯撒的妻子一样无可质疑之处，否则就会一边进行一边树敌。

有其他想法吗？

这些网页的内容为表达个人意见。

All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.