工作型管理者的产品杂记

从工程师到管理者所经历的最大变化之一,是重新认识我平常看待的问题:我们打算怎样搞定?做为工程师,我把问题分解为:我们需要开发的软件是什么,为了完成目标、我们需要解决的技术壁垒是什么。做为管理者,我把问题分解为:我们完成目标的过程是什么。

当我担任管理者角色、去问“我们打算怎样搞定?”、得到的答案是“我不知道”时,我有些沮丧。但这是不公平的——总有一些我们不知道答案的问题。让我感到沮丧的是当答案来得太快、当某人说“我不知道”时,因为他们正错过了一些东西,那就是他们觉得需要找到答案。我不知道,因为在我们知道想法是否可行之前,我们不得不写一些代码。我不知道,因为决定在其他人手里,等等。

你知道!如果决定在其他人手里,那么问题的答案就演变为:我们打算问问其他人,他们想要什么以及他们打算如何做决定,然后再去做这件事。如果我们不知道想法是否可行,那么问题的答案就演变为:我们打算探索技术可行性,一旦我们掌握更多情况、我们将进行下一次迭代计划。“我不知道因为……”是没有错误的,因为它就是某种答案,它让团队以过程的形式作出了决定。“我不知道。”——以句号结尾——还算好些,如果你把它理解为“我不知道,所以我们打算通过学习来完成”。这是我不喜欢的“我不知道,让我们继续吧”。

但我正有些不公平。做为管理者,在过程这一层回答问题是我的职责。然而我非常努力地把人们划分开,或许我还应当努力地接受人们在什么时候建立了他们角色的绑定。当你在尽量创作时,保持专注、抵御分心是有必要的。当你在团队工作时,你应该依赖团队成员的各种技能、以放手项目的某些部分。保持低调是不错的。(有时候;有时候团队里的每个人必须抬头并对环境作出响应。)

说来话长,我体会到在工程师和管理者的角度之间有着太多的不同。很难同时站在两个角度,从两个角度行动就更难了。

在我的新项目,我重回到开发,进入工作型管理者的角色,我正在执行我还在管理的相同任务,这是一种古怪的方式。当我开始管理时,我把自己从编程上剔除出来,使自己不会因新角色和不得不要做的大量学习而分心。回到编程,我可以辨别出我做的是正确的。

在这两种心态、这两种非常不同的工作模式之间切换,是有挑战的。无论哪种角色,我想具有前瞻性,只不过一个是面向人的管理者,一个是面向代码的工程师。我投入了小块时间,尽量保持最佳频率的沟通,留意出现的问题,因此回报是非直接的、有滞后的。直接的和立即出现的回报就是:工作代码。只要我知道哪种方式是正确的,这种受限制的专注就能够更加稳步地向前推进。

但我是一名工作型管理者。现在是调查这种奇怪日志信息的时间吗,或考虑我应该和谁讨论产品机会吗?

你不可能为所有人解决所有问题

我看到一条让我哭笑不得的 tweet,它建议“不要造一把瑞士军刀,而要造一把外科手术刀”。我明白这条信息背后的意思(比如,要建立专注的产品),但这是一条极容易被误解和误用的信息。它过早地关上了思想和实验的途径,它让人们因为害怕愚蠢而不敢尝试……哦,这完全是瞎扯。

这是你在 Twitter、Facebook以及全球创始人和“导师”的博客 上可以找到的千分之一的信息(是的,也包括本博文)。这些零星建议已变成了创业氛围里的箴言,变成了人们反复琢磨而没有真正思考的精神食粮。判断这种建议依据的不是客观性,而是被 Retweet 的数量,拜托!在把这条建议应用到你的业务之前请停一停!

正如你在互联网上看到的很多东西一样,大部分都是胡说八道。那些不是胡说八道的东东应该有着冗长的免责声明,还有更多的语境。

...

软件测试是失败者的赌注

原文地址(original source):http://spage.fi/software-testing

在看本文时,切记测试不是为了提高质量。提高质量的唯一方式是修改产品,测试不会改变产品。

测试的目标是收集产品信息,当然,这种信息在改善产品时可以被用到。

对于软件测试,我的意思是在产品开发阶段之间和之后的某些情况下,我们测试工程师所做的检查。管理员可以创建新用户吗?自动同步可以从连接问题中恢复吗?这个输入框接受多字节的 UTF-8 字符?等等类似的问题。

或许软件测试最重要的不是单元测试、可用性测试、性能测试、验收测试或任何其它非功能性的测试。

检查与 90 年代的相关性

关于测试工程师在开发阶段做了大量检查而没有在其它地方做太多的当前模式,是来自于早期的人为现象,在互联网之前的日子赢了每一场战斗。

在一切都是网页以及我们所有设备都能不间断地访问互联网之前,收集产品信息的唯一方式就是测试。没有可查的服务器日志、崩溃报告和 UI 标准。

在过去,如果你一周能够得到一个版本就是幸运的。第一个可行的单元测试框架诞生于 1998 年(SUnit,xUnit家族第一成员【注1】),因此,“如果它编译了,那么它就没问题”成了标准。

...