利益相關(guān)者軟件工程

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.

無論您是在初創(chuàng)公司還是大公司中工作，都要讓您的利益相關(guān)者和非技術(shù)合作伙伴參與其中，并及時了解技術(shù)團(tuán)隊的建設(shè)情況，這可能很難。

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.

我與我的工作團(tuán)隊和副項目團(tuán)隊一起做過的一些事情，可以幫助保持利益相關(guān)者的了解并緊密參與我們的流程。

創(chuàng)建一個演示頁面 (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.

當(dāng)我的工作和副項目團(tuán)隊為下一個沖刺(或您將要工作的任何時間段)計劃要處理的任務(wù)/故事時，我們會將它們添加到演示頁面，其中包含包含每個任務(wù)的表，簡單易懂的描述，工作人員的姓名以及完成的工作的屏幕截圖。

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個優(yōu)點：

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.

跟蹤進(jìn)度和團(tuán)隊已完成工作的簡便方法。 當(dāng)將來出現(xiàn)問題時，您可以返回并參考這些內(nèi)容。

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.

使利益相關(guān)者可以輕松，直觀地看到進(jìn)度：與其被問到十億次項目的狀態(tài)或到目前為止已經(jīng)完成的事情，不如發(fā)送一個鏈接并使他們閱讀整個頁面要容易得多。

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.

它為其他外部團(tuán)隊了解您所做的工作提供了快速參考 。 有時候，如果您與其他團(tuán)隊進(jìn)行交叉合作，他們想知道項目的狀態(tài)或?qū)е履@個方向發(fā)展的原因。

每兩周進(jìn)行一次產(chǎn)品演示 (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.

對于我的團(tuán)隊而言，這意味著每2周需要清理30分鐘的窗口，向非技術(shù)合作伙伴展示我們在過去的Sprint中所做的工作。 最好選擇一個適合所有人的時間范圍，但如果不可能，請進(jìn)行兩次演示或選擇一個可以參加最多人數(shù)的時間。 我建議至少每月一次或每季度兩次進(jìn)行演示。

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.

  利益相關(guān)者知道團(tuán)隊成員。 在在線交流中使用名字和面Kong有助于在利益相關(guān)者和開發(fā)團(tuán)隊之間建立友情關(guān)系。 微小的方法會有所幫助，使非技術(shù)合作伙伴在做出決定，推出功能以及僅對產(chǎn)品的發(fā)展有了一般認(rèn)識時更加謹(jǐn)慎。

• 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.

  非技術(shù)合作伙伴都知道正在進(jìn)行的工作以及可能發(fā)生的任何阻止程序。 這意味著本季度末某些功能沒有完成不會令人感到意外。 每個人都在同一頁面上，知道發(fā)生了什么事。

• 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.

  它使您作為開發(fā)人員對您的任務(wù)有更深入的了解。 每個人都應(yīng)該考慮如何以一種易于理解的方式將深刻的技術(shù)任務(wù)傳達(dá)給非技術(shù)人員。 這樣可以做到這一點。

在關(guān)鍵警報渠道中包括非技術(shù)合作伙伴 (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.

我的團(tuán)隊有多個閑置渠道(按環(huán)境和優(yōu)先級分隔)，在其中我們會收到有關(guān)服務(wù)狀態(tài)的警報。 我們通常只在生產(chǎn)渠道中添加合作伙伴，并在關(guān)鍵警報(例如服務(wù)中斷)時添加合作伙伴。 這是讓他們獲得感興趣的警報而又不會被噪音所淹沒的快樂媒介。

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.

我們發(fā)現(xiàn)這樣做有助于使他們保持了解狀態(tài)，以便他們擁有必要的信息來向其他受影響的人或上層人士匯報。

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.

這應(yīng)由您自行決定。 如果您是一家初創(chuàng)公司，則可能不希望您的利益相關(guān)者每次都遇到服務(wù)中斷的情況，但是如果您的團(tuán)隊中有其他團(tuán)隊根據(jù)您的產(chǎn)品而定，那么如果他們的合作伙伴有點他們開始從別人那里收到多個憤怒的消息，表示該產(chǎn)品不可用。

有錯誤頁面 (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

為了獲得警報，有一個簡單的頁面，供利益相關(guān)者在使用應(yīng)用程序時可以發(fā)布他們可能遇到的錯誤，而不用向團(tuán)隊或個人開發(fā)人員發(fā)送電子郵件。 它可以是一個簡單的頁面，其中他們可以輸入有關(guān)問題的信息，也可以是諸如JIRA的票務(wù)服務(wù)，他們可以在其中填寫票證并跟蹤完成進(jìn)度。 解決問題后，可以發(fā)布該修補程序的簡單描述。

The benefits of this method is that:

這種方法的好處是：

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

  清除有關(guān)錯誤及其發(fā)生原因的文檔。

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

  集中存儲這些錯誤的位置 。 跟蹤和查看過去是否發(fā)生過類似的錯誤變得更加容易。

• If multiple stakeholders are experiencing the same error, it is clear and they can follow the progress.
  如果多個利益相關(guān)者都遇到相同的錯誤，則很明顯，他們可以跟蹤進(jìn)度。

可見的功能測試 (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.

這有點奇怪，而且并不是真正適合所有人，因為這取決于利益相關(guān)者的參與程度和技術(shù)水平。 就我的團(tuán)隊而言，我們有一個技術(shù)熟練的產(chǎn)品所有者和其他非技術(shù)合作伙伴，他們熟悉編寫業(yè)務(wù)案例或規(guī)則。

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.

由于我們的大多數(shù)功能測試都是用小Cucumber/Cucumber編寫的(對于非技術(shù)人員來說，它的可讀性是可以選擇的)，因此我們能夠在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.

每當(dāng)發(fā)生代碼合并時，JIRA測試都會被拉出并針對新更改運行。 然后將結(jié)果發(fā)布在JIRA上，這使我們的利益相關(guān)者可以一目了然地查看哪些功能正在通過和失敗。

Passing functional test execution set in JIRA通過JIRA中的功能測試執(zhí)行集

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，請確保還有其他可視化工具可以執(zhí)行此操作，否則您可以快速使用它。

結(jié)論 (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.

這些是我的工作團(tuán)隊在過去一年中采用的一些方法，這些方法有助于與利益相關(guān)者建立良好的關(guān)系。 我們注意到他們更加投入，期待發(fā)現(xiàn)團(tuán)隊的進(jìn)展，非常感謝我們付出的努力，并喜歡在中心位置查看應(yīng)用程序進(jìn)度。

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.

如果您有其他可改善溝通技巧的提示，我很想聽聽他們的意見。 如果您希望我做一個關(guān)于如何使用Java或任何其他語言將測試鏈接到JIRA的教程，請告訴我。

翻譯自: https://blog.prototypr.io/ways-to-improve-communication-between-developer-teams-and-non-technical-stakeholders-508dbdad7e0e

利益相關(guān)者軟件工程

總結(jié)

以上是生活随笔為你收集整理的利益相关者软件工程_改善开发人员团队与非技术利益相关者之间交流的方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。