如何远程提出改进建议

"人们经常会接受一些"好用"的东西，却没有意识到维护这样的代码是很耗费成本和时间的。作为开发人员，我们必须记住，产品所有者不是程序员，我们需要清楚地解释我们要做的改变。"- Mateusz Spiewak，X-Team。

当我们在传统的办公环境中提出改进建议时，我们有很多方法来帮助我们说服人们推进我们的想法。我们可以在走廊里拦住人们，在会议室里召集领导层并展示演示文稿，走进办公室，在快乐时光的酒吧里提出想法，以及其他各种利用个人关系和人际信任的方式来左右上级，从而实现变革。

由于是远程的，我们的工具箱中就没有了这些选择，同时也带来了自己的挑战和好处。但是，每个X-Teamer的一个独特特点是，他们非常积极主动地不惜一切代价提出明确、有力的改进建议（无论是否远程）。

因此，我们与X-Teamers进行了交流，他们发现作为一名远程开发人员，想要帮助推动团队前进并进行改进，获得成功的最佳方法是什么。

利用远程对于要求清晰的必要性

Ryan Chartrand:迫使我们尽可能向团队传达清晰的信息。当然，这也转化为我们提出改进建议的时候。

无论你是通过Skype/Slack/Hipchat、E-mail还是在电话中向别人提出建议，你的信息都必须非常清晰和简短，以吸引他们的注意力，并让他们推进你的想法。

比如说你想推荐开始做自动化测试。这是个广泛的话题，对吧？想要远程推销这样一个大概念并不容易。如果你要向的人是通过聊天信息或通过电子邮件来阅读这个想法，你只有很少的时间来传达这个概念。

所以，与其一开始就试图解释整个自动化测试的世界，不如从小处着手。从一些小事开始，与当前的需求/挑战非常相关，并且在一两个sprint内就能轻松实现。

例如，也许上周发现了一个bug，使整个主页瘫痪了几个小时。这是一种不应该再发生的bug（尤其是如果人们想保住自己的工作）。在你的下一次冲刺计划会议上，建议值得设置一个自动测试，在每次部署前进行检查，以确保该bug不会再次出现。

你没有从自动化测试这样一个非常模糊、宽泛的主题开始，而是从小处着手，用一个非常具体的用例，解决了一个非常相关的挑战，对人们有明确的价值（确保他们不会失业）。这些建议是明确的、有价值的，会让你走上实现你心中更大的改进之路。

通常在传统的办公环境中，我们会采用大而化之的会议室演示方式来影响变化。作为远程，迫使你更具体、更清晰、更有针对性，最终导致成功的机会更大。

所以，请记住：从专注于整个团队的价值开始，才能努力实现你所设想的改进。罗马不是一天建成的，但只要有恒心、清晰和专注，你可以建立任何东西。

建议取决于对同理心的理解

乔什-约翰斯顿。我认为这里最大的一个问题是：在你告诉别人改变之前，你必须了解他们是如何到达那里的。 如果你看别人的产品，发现有需要改进的地方，很可能不是因为你比他们聪明。 产品是在一个复杂的系统中诞生的，这个系统中存在着相互竞争的需求，以及有限的资源。

我们都希望我们的产品是完美的，但请记住，完美并不总是在各个部分。 完美的产品是在预算范围内按时发货，并让人们乐于使用它。 所以，任何你能做的了解背景和产品所有者的优先级的事情都会帮助你措辞问题。

一旦你有了一点这样的理解，你就可以开始问自己一些问题，比如"为什么他们会在意我们少了几个分号？"有些东西是对的，并不意味着它对这个特定的产品有价值（我在这里有意挖苦你，但希望你能明白我想表达的意思）。

也许你会发现，由于要修复大量的bug，团队的工作效率受到了影响。因此，与其进来喋喋不休地谈论分号和衬托，你可以从更相关的话题开始。"我想和你讨论一下我们面临的一些生产力/质量挑战，以及一些简单的解决方法"。

以改进作为管理团队的契机

Mateusz Spiewak开始使用"我们"这个词。不要说"我想改进"，而要用"我们应该改进"，甚至是"让我们一起想办法"，或者"如果我们这样做，我们的生活会更简单"_______。

使用"我们"这个词能给人一种团队合作的感觉，并激发出一种团结的意识，虽然远程团队很难做到这一点，但一切都要从使用正确的语言来实现。

不要老是抱怨，要努力提出明确的论点

Wojtek Zając:去额外的英里。当你提出改进建议时，你没有任何借口：专注于理想的场景。当你发送代码要点时，要遵循良好的实践和设计模式。关注好的文档。

用链接来支持它。应该有很好的证据证明你所说的东西确实得到了证实。研究、技术讲座和博客文章可以加分。

消极会让你很快被忽视

Wojtek Zając:避免负面情绪努力仔细地表达你的建议。在一个远程团队中，对方看不到你，可能会不恰当地理解你的意图。

永远不要把你的建议变成个人的。无论如何，要避免辱骂，永远不要把过错归咎于他人。

你的建议被批准了！现在，不要让它被搁置

Wojtek Zając:一旦你的建议被批准，就要监控进度。想象一下，你提议将schema.org数据添加到网站上；它被接受了，但事实证明，其他开发人员并不熟悉它，他们在签收任务之前没有验证结果。 订阅github问题，跟进，如有需要再补充建议。

或者......知道什么时候该接受失败的事实

Wojtek Zając：知道什么时候该停止，当你觉得进一步的讨论不会导致任何建设性的东西，就离开。"挑起你的战斗"这句话已经存在了一段时间，是有原因的。

最后，对于不可避免的某一天，有人会向你提出改进的建议，值得听听一些建议。

如何接受与如何给予同样重要

库巴-多布兰诺夫斯基：当你看不到别人的脸， 听不到他们的声音， 或感觉到他们的情感 在他们的心中震动， 这是很容易误读 他们的意图。

如果你今天心情不好，不要让它影响到别人想向你推荐的东西，因为建议意味着他们想帮助你--这反过来又能达到你越来越好的目的。从批评中学习是一种智慧的证明。

总是尝试着去接近你通过文字收到的建议，假设从他们那里得到最积极的情绪。