如何改变草率的公司文化?[关闭]


28

有时,当我遇到需要解决的问题时,我发现解决该问题的最简单方法是编写一个小程序作为个人工具。我没有使它具有超级可用性或超强健性,因为我是唯一要使用它的人,而且我没有时间完善和全面测试它。

然后,一位同事看到了程序并提出了要求,因为他遇到了同样的问题,并且该工具可以提供帮助。我给他“这不是很漂亮,但可以完成工作”的免责声明,让他拥有。

我知道的下一件事,我的上司打电话给我,告诉我他正在尝试使该软件在客户的计算机上运行,​​但显示X错误消息。WTF ??该软件尚未发布,我也没有被告知需要发布。但是出于某种原因,我的上司认为它足够好,并在不通知原始开发人员的情况下发布了它。

现在,使用可以轻松解决此特定问题MessageBox.Show("DO NOT GIVE TO CLIENTS!");。但是,该问题表明存在更深层次的问题:我们的公司文化马虎。马虎软件可以,马虎进程也可以。不必担心未来-只需投入足够的精力使其几乎不能立即使用,将二进制文件放入.zip文件中,然后发货即可。足以胜任政府工作。

这是一家拥有10名全职员工的小型公司,正在成长,并且已经存在了一段时间。不要误会我的意思;我喜欢在这里工作,也喜欢公司。不要告诉我跑步;我想成为使公司变得更好的一部分。您如何开始为这种文化带来良好的变化?


8
古老的俄罗斯人说:“鱼从头臭了!”!

3
有一次您可以保证将在大型启动后实施流程。后果的一部分将是客户将要求对流程进行审查,以确保不会再次发生。当管理层发现正在发生的事情时,您很快就会发现一些闪亮的新过程。也许您可以设计一个插件。玩笑!请不要认真对待:)
Paul T Davies

这听起来好像这应该是一个测试(单位或集成),而不是一个应用程序....
devlife

2
我不想得罪你,但是你自己为草率的文化做出了贡献吗?如果您谈论的是客户和团队成员都遇到的问题,也许只有您拥有的现成工具并不是最草率的解决方案。
丹·奥尔森,

@DanOlson您说的很对,但是当时我不知道客户会需要它。如果有的话,我会把它变成一个成熟的软件项目。
菲尔(Phil)

Answers:


20

改变的唯一方法是让其他所有人看到草率文化的弊端​​,也许更重要的是,需要管理层的支持来解决它。但实际上,这不会发生,您将无法更改它。那可能不是您期望听到的答案,但是经过五年左右的尝试并未能完成几项工作来改变草率的文化之后,我可以凭权威说,通常不值得为此付出努力。

第一步是找出是否有人了解或关心草率的文化。如果您是唯一发现任何问题的人,那么您的努力是徒劳的。


+1以使管理层接受。我发现,如果没有上级主管继续前进并给要做的事情施加压力,大多数人将不愿意改变并坚持他们目前必须做的事情。
dreza 2011年

+1的原因与@dreza相同。但是,如果有管理层的支持,祝您好运
。– talonx

8

您可能需要与同事和老板坐下来坐下来,向他们解释一下您所拥有的只是原型,还没有准备好供客户使用。如果他们希望它可以供客户使用,则可以在足够的时间进行更改,但是请不要拿那些“快而脏”的东西传递给客户。仅仅因为有些事情行之有效就不能成为上课的好习惯。尽管您给出了免责声明,但要给予一定的尊重是要说些什么,否则会发生这种情况。


5
作为操作人员,我想解释一下为什么要降低投票率。
菲尔(Phil)

4
更不用说快速而肮脏的东西仍然可以保留重要信息,这些信息永远都不应离开建筑物(例如,用于测试的硬编码密码)
棘手怪胎

3

你不能解决愚蠢的问题。如果老板做的事情像您描述的那样,那您就不可能改变它。特别是如果他不是所有者,请记住,他承受着来自另一个方向的压力,并且该方向签了他的薪水支票。与您的其他同事相同。您可以采取的最好的第一步行动就是养成保护自己的习惯。使用您描述的消息框之类的技术。保留所有电子邮件。获得尽可能多的书面形式。这样,当蠢货来临时,您就不会首当其冲。然后,随着晋升,在您的监督下进行所需的更改。


我同意,这毕竟是一个可悲的策略。谁想在这样的环境中工作?从长远来看,这种文化将无声地扼杀创造力。努力做到最好,而不是最保护。如果文化不再适合,继续前进。
JensG 2013年

2

前几天,一位同事告诉我一个简单的测试工具的故事,该工具使实验室的工程师可以向小部件发出单个命令,并更改随该命令附带的变量。这是9年前写的,最后他知道,它至今仍在使用。经过数小时的编写,经过最少的测试即可证明在实验室中可以正常工作的工具是整个工程实验室测试工具的基础。一旦编写代码,它就存在。如果它做有用的事情并且被其他人看到,那么人们会想要它。如果它擅长于做某事,那么人们会要求它做X。接下来,您知道,您的简单工具是重要的组成部分。

我认为,软件开发人员的首要责任是确保查看代码或使用该工具的任何人都了解这是原型还是生产系统,并说明为什么会这样。听起来您确实这样做了,但是您的同事却忽略了履行这一责任。为了解决这个问题,我建议与他们交谈,重申这不是生产代码,仅是为了方便您的工作而编写的。如果他们觉得有用,也许会提供使用该工具或支持其他人使用该工具的功能,以增强它并使它更适合生产。

至于组织过程或文化的变化,预计需要一段时间。首先举一个例子。如果您还没有阅读The Pragmatic Programmer,请阅读。记下一些技巧,例如“关心您的手艺”,“成为变革的催化剂(向人们展示更好的方法)”,“不要与破损的窗户一起生活”,“解决问题而不是责备”。听起来您已经意识到这些提示解决的一些问题,因此开始工作并为您的同事树立榜样。


我完全同意你的看法。我的想法是,当您编写代码时,尽可能地编写代码,通常需要花费相同的时间来编写错误的代码。质量是项目中期无法获得的。
Andrea Girardi

1

直到决策者不再忍受错误代码的后果,并愿意为解决问题付出/改变他们的方式。

对于成长中的小型公司而言,这是艰难的决定。他们不知道将所有精力放在哪里。当业务规则以及有时整个业务线在一夜之间出现,更改和消失时,会使代码过于健壮是有风险的。

努力编写好的代码。确保您将后果告知每个人,以便他们做出明智的决定。如果将不良代码投入生产,请尽可能保持密切关注,并继续提出改进建议,尤其是在那部分业务变得至关重要的情况下。

让人们等待您认为最小可行的代码似乎超出了他们当前的期望。


+1表示“让人们等待您所看到的,因为最低限度的可行代码似乎超出了他们目前的期望。” 可悲的是。
菲尔·

@Phil-大多数人只是不想进入细节。有时,您可以通过轻松地在将来进行更改,提高安全性或处理更多用户的能力来吸引他们。
JeffO

1

我要指出的一部分问题是,您首先编写了一个快速而又肮脏的工具。当然,有充分的理由。当然,它做到了。但是,我发现,如果您开始提出解决方案,那么任何能够解决问题的方案都将落入“足够好”的解决方案的陷阱。

如果您的同事想要它,要么礼貌地告诉他它没有完全正常运行,而您则保留了钥匙。您可以不时为他运行。或者,最好在项目开始时添加额外的功能。

此时,我所有快速而又肮脏的工具都来自经过严格测试的框架文件。它可以让我快速上手,为我提供了一个可行的起点,并且让我忘记添加所有这些必要的钝边缘。我不必担心getopts库及其怪癖。使用python时,不需要记住有关内存管理的详细信息。编译程序,以便它一个简单的任务,只有一个。这样可以轻松测试他们是否尝试使其变形。

最后,利用有限状态机架构。如果您知道要进入所有可能的状态,那么无论如何确保用户永远都不会跳过曲目,要容易得多。我有一个编写的程序可以遵循这种范例。它接受任意输入文件,逐字节读取。即使客户端告诉它读取二进制可执行文件,也不会有任何问题。由于它找不到所要查找的任何内容,因此它将填充内部缓冲区。这将导致它优雅地清理,关闭并向用户报告他们需要我查看它。


0

好吧,答案与编程没有太大关系,只是软件是一种好东西,很难轻易判断其质量。

你可能不能够改变这种文化,因为人们可能没有真正的动机并非是草率的,因为受影响的软件质量的人没有太多做的过程。例如,您的客户可能需要购买和使用软件来完成工作,但对软件的有效性却没有什么个人兴趣,因为他们不会因自己的问题而受到指责,也不会因为自己的美德而得到回报(大部分情况下)因为没有人真正知道竞争软件是否会更好)。因此,您可能只需要花长时间即可满足他们的功能要求,而不必担心它是否有故障。因此,你们所有人都可能相当草率而没有后果(对任何影响您的决定的人)。

我不知道是否会发生这种情况,但是如果是这样,您可能很难改变文化,因为您试图改变的人实际上做不到。

如果他们会过得更好,那么您可能会更轻松一些,因为您可以说服他们为什么这样做。不幸的是,如果没有某种可以使人草率行事的政治局势,他们可能不会成为摆在首位马虎,所以它很可能是艰难的。您总是可以尝试使用“有一天您可能需要做正确的事情”这一论点(也许在外交上用措辞更多……)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.