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的教程，請告訴我。