Whether you’re working on a startup or a big company, keeping your stakeholders and non-technical partners engaged and up to date on what the tech team has been building can be hard.

无论您是在初创公司还是大公司中工作，都要让您的利益相关者和非技术合作伙伴参与其中，并及时了解技术团队的建设情况，这可能很难。

Here are some of the things I’ve done with my work team and side project team to help keep stakeholders in the know and tightly engaged in our process.

我与我的工作团队和副项目团队一起做过的一些事情，可以帮助保持利益相关者的了解并紧密参与我们的流程。

创建一个演示页面 (Create a demo page)

While my work and side project team plans for the tasks/stories we’ll be working on for the next sprint(or whatever period of time you’ll be working), we add them to a demo page with a table containing each task, an easy to understand description, the name of the person who worked on it as well as a screenshot of the completed work.

当我的工作和副项目团队为下一个冲刺(或您将要工作的任何时间段)计划要处理的任务/故事时，我们会将它们添加到演示页面，其中包含包含每个任务的表，简单易懂的描述，工作人员的姓名以及完成的工作的屏幕截图。

Here’s an example in Notion, but this can be done in anything from google docs to confluence.

这是Notion中的示例，但这可以用任何方法完成，从google文档到合流。

Having a page like this gives 3 advantages:

拥有这样的页面具有3个优点：

1. Easy way to track progress and things that have been worked on for the team. You can go back and reference these things when future questions crop up.

   跟踪进度和团队已完成工作的简便方法。 当将来出现问题时，您可以返回并参考这些内容。

2. Allows stakeholders to see the progress easily and visibly: instead of getting asked a billion times what’s the status of the project or what’s been done so far, it’s much easier to send a link and have them read through the page.

   使利益相关者可以轻松，直观地看到进度：与其被问到十亿次项目的状态或到目前为止已经完成的事情，不如发送一个链接并使他们阅读整个页面要容易得多。

3. It provides a quick reference for other external teams to know what you’ve worked on. Some times if you’re cross collaborating with other teams, they would like to know the status of the project or what led you to this direction.

   它为其他外部团队了解您所做的工作提供了快速参考 。 有时候，如果您与其他团队进行交叉合作，他们想知道项目的状态或导致您朝这个方向发展的原因。

每两周进行一次产品演示 (Have a product demo every couple of weeks)

For my team, this means clearing out a 30-minute window every 2 weeks to present to our non-technical partners what we’ve worked on this past sprint. It’s best to choose a time frame that works for everyone but if that’s not possible, either do the demo twice or choose a time where the maximum number of people can attend. I recommend having a demo at least once a month or twice a quarter.

对于我的团队而言，这意味着每2周需要清理30分钟的窗口，向非技术合作伙伴展示我们在过去的Sprint中所做的工作。 最好选择一个适合所有人的时间范围，但如果不可能，请进行两次演示或选择一个可以参加最多人数的时间。 我建议至少每月一次或每季度两次进行演示。

The benefits of this are as follows:

这样做的好处如下：

• The stakeholders are aware of the team members. Putting a name and face to the online communication helps build camaraderie between the stakeholder and the development team. It will be helpful is minute ways and make non-technical partners more mindful when decisions are made, features are pushed, and just general awareness of how the product is evolving.

  利益相关者知道团队成员。 在在线交流中使用名字和面Kong有助于在利益相关者和开发团队之间建立友情关系。 微小的方法会有所帮助，使非技术合作伙伴在做出决定，推出功能以及仅对产品的发展有了一般认识时更加谨慎。

• The non-technical partners are aware of what is being worked on as well as any blockers that may have happened as they happen. This means there are no surprises at the end of the quarter for certain features not being completed. Everyone is on the same page and knows what’s been going on.

  非技术合作伙伴都知道正在进行的工作以及可能发生的任何阻止程序。 这意味着本季度末某些功能没有完成不会令人感到意外。 每个人都在同一页面上，知道发生了什么事。

• It gives you as a developer a deeper understanding of your task. Thinking about how you will communicate a deeply technical task to a non-technical person in an easy to understand manner is something everyone should practice. This allows you to do that.

  它使您作为开发人员对您的任务有更深入的了解。 每个人都应该考虑如何以一种易于理解的方式将深刻的技术任务传达给非技术人员。 这样可以做到这一点。

在关键警报渠道中包括非技术合作伙伴 (Include non-technical partners in critical alert channels)

My team has multiple slack channels(separated by environment and priority) where we get alerts about the status of our services. We usually only add our partners in the production channel and for critical alerts like when a service goes down. This has been the happy medium of them getting alerts they’re interested in without being overloaded by the noise.

我的团队有多个闲置渠道(按环境和优先级分隔)，在其中我们会收到有关服务状态的警报。 我们通常只在生产渠道中添加合作伙伴，并在关键警报(例如服务中断)时添加合作伙伴。 这是让他们获得感兴趣的警报而又不会被噪音所淹没的快乐媒介。

We’ve found that doing this helps keep them in the know so that they have the necessary information to report to other impacted people or higher-ups.

我们发现这样做有助于使他们保持了解状态，以便他们拥有必要的信息来向其他受影响的人或上层人士汇报。

This is something that should be decided at your discretion. If you’re a startup you might not want your stakeholders hearing about every-time your service goes down, but if you are a team that has other teams depending on your product, it would be helpful to your partners if they have a bit of head's before they begin getting multiple angry messages from other people that the product is not available.

这应由您自行决定。 如果您是一家初创公司，则可能不希望您的利益相关者每次都遇到服务中断的情况，但是如果您的团队中有其他团队根据您的产品而定，那么如果他们的合作伙伴有点他们开始从别人那里收到多个愤怒的消息，表示该产品不可用。

有错误页面 (Have an errors page)

Tying into getting alerts, having a simple page where stakeholders can post the errors they may encounter while using the application rather than emailing the team or individual developers. It can be a simple page where they type out information about the problem or it could be a ticket service like JIRA’s where they fill out a ticket and track the progress to completion. When the problem is resolved, a simple description of the fix can be posted

为了获得警报，有一个简单的页面，供利益相关者在使用应用程序时可以发布他们可能遇到的错误，而不用向团队或个人开发人员发送电子邮件。 它可以是一个简单的页面，其中他们可以输入有关问题的信息，也可以是诸如JIRA的票务服务，他们可以在其中填写票证并跟踪完成进度。 解决问题后，可以发布该修补程序的简单描述。

The benefits of this method is that:

这种方法的好处是：

• Clear documentation of the errors as well as who it happened to.

  清除有关错误及其发生原因的文档。

• Central location to store those errors. It becomes easier to track and see if a similar error happened in the past.

  集中存储这些错误的位置 。 跟踪和查看过去是否发生过类似的错误变得更加容易。

• If multiple stakeholders are experiencing the same error, it is clear and they can follow the progress.
  如果多个利益相关者都遇到相同的错误，则很明显，他们可以跟踪进度。

可见的功能测试 (Visible functional tests)

This is a bit of a weird one and is not really for everyone as it depends on how involved and technical your stakeholders are. In my teams’ case, we had a pretty technical product owner and other non-technical partners who were familiar with writing business cases or rules.

这有点奇怪，而且并不是真正适合所有人，因为这取决于利益相关者的参与程度和技术水平。 就我的团队而言，我们有一个技术熟练的产品所有者和其他非技术合作伙伴，他们熟悉编写业务案例或规则。

Since most of our functional tests are written in gherkin/cucumber(chosen for how legible it is for non-technical people), we were able to have the functional tests written on JIRA. The tests were written in an easy to understand way.

由于我们的大多数功能测试都是用小Cucumber/Cucumber编写的(对于非技术人员来说，它的可读性是可以选择的)，因此我们能够在JIRA上编写功能测试。 测试以易于理解的方式编写。

Whenever a code merge happened, the JIRA tests were pulled and run against the new changes. The results were then published on JIRA which allowed our stakeholders to view at a glance which functionalities were passing and failing.

每当发生代码合并时，JIRA测试都会被拉出并针对新更改运行。 然后将结果发布在JIRA上，这使我们的利益相关者可以一目了然地查看哪些功能正在通过和失败。

Again this is not for everyone out there. Additionally, if you don’t use JIRA I’m sure there are other visualization tools to do this with or you could crank a quick one out.

同样，这并不适合所有人。 另外，如果您不使用JIRA，请确保还有其他可视化工具可以执行此操作，否则您可以快速使用它。

结论 (Conclusion)

These are some of the things my work team has incorporated in the past year that have helped build a great relationship with our stakeholders. We’ve noticed that they are more engaged, look forward to finding out what the team’s progress has been, really appreciate the effort we put in, and love having a central location for viewing the application progress.

这些是我的工作团队在过去一年中采用的一些方法，这些方法有助于与利益相关者建立良好的关系。 我们注意到他们更加投入，期待发现团队的进展，非常感谢我们付出的努力，并喜欢在中心位置查看应用程序进度。

If you have tips on other things to do to improve communication, I would love to hear them. If you’d like me to do a tutorial on how to link tests to JIRA using Java or any other language let me know.

如果您有其他可改善沟通技巧的提示，我很想听听他们的意见。 如果您希望我做一个关于如何使用Java或任何其他语言将测试链接到JIRA的教程，请告诉我。