mac 沒有所有開發者

by Sajal Sarwar Sharma

通過薩加爾·薩瓦·夏爾馬

為什么開發人員應該像產品所有者那樣思考 (Why developers should think more like product owners)

You have just deployed your long-awaited feature to production after a long and gruesome month of coding, reviewing, and testing (read: a lot of iterations, living the Agile Methodology to the core). You had an all-nighter just the last night and now you just want to take off and sleep peacefully in your cosy warm bed.經過漫長而艱苦的一個月的編碼，審查和測試，您才剛剛將期待已久的功能部署到生產中(閱讀：大量迭代，將敏捷方法學應用到核心)。 昨晚您有一個通宵的住宿，現在您只想起飛并在舒適的溫暖床上安靜地入睡。

In a fast moving startup culture, this is kind of normal for a software developer. Things move fast, the code moves faster, and the requirements — well we’ll just say: Mr. Light Photon, you’ve got a competitor.

在快速發展的啟動文化中，這對于軟件開發人員來說很正常。 事情發展很快，代碼運行更快，需求也越來越好–我們只能說： Light Photon先生，您有競爭者 。

在一開始的時候 (In the beginning)

I have been working with a healthcare startup for the past three years, and I have seen it grow over this time period. Today, I am going to share some of my learnings — but I am not going to bore you with the plethora of technologies we use to keep the wheels moving.

在過去三年中，我一直在與一家醫療保健初創公司合作，而且我看到它在這段時間內不斷增長。 今天，我將分享一些經驗教訓，但我不會讓您厭煩我們用來保持車輪運轉的眾多技術。

Rather, today I will be sharing some insights that I have learned over the years, working shoulder to shoulder with some of the most motivating and inspiring business leaders in the industry.

相反，今天，我將分享我多年來所學到的一些見識，并與該行業中一些最激勵和鼓舞人心的商業領袖并肩工作。

During my early days as a developer, all I used to do was:

在開發初期，我曾經做過的事情是：

Take requirements from the product manager, develop the feature/system, test it, deploy it, go home, sleep and reiterate.

從產品經理那里獲取需求， 開發功能/系統，對其進行測試 ， 部署 ， 回家 ， 睡覺和重申 。

Seems legit. That’s the job of a developer, right?

似乎是合法的。 那是開發人員的工作，對吧？

For two years of my developer life, I lived this routine. I was growing as a software developer, but running a business is not just software development. In fact, it’s just one wheel in the chariot, and there are other wheels that move the chariot along that I knew nothing about.

在開發人員生命的兩年中，我過著這樣的常規生活。 我成長為一名軟件開發人員，但是經營業務不只是軟件開發。 實際上，這只是戰車上的一個輪子，還有其他輪子使戰車沿著我所不知道的方向移動。

改變我的心態 (Changing my mentality)

I built stuff, I deployed, and I moved on. I suppose that was the biggest mistake I made. Though business moved along as usual, one day I sat down and contemplated:

我建造了東西，部署了，然后繼續前進。 我想那是我犯的最大錯誤。 盡管生意照常進行，但有一天我坐下來考慮：

“Why am I not caring about the product I have been building over these many months?”

“為什么我不關心我這么多年來一直在生產的產品？”

“Isn’t it my responsibility to move the business metric forward?”

“將業務指標向前推進不是我的責任嗎？”

“I have built the system from scratch, but is the system actually helping the end user?”

“我是從頭開始構建該系統的，但是該系統實際上對最終用戶有幫助嗎？”

You can safely console yourself by thinking “It’s not in my job description” and moving on. But the last question actually stuck me hard: am I doing anything for society, and is my product actually helping our users lead a better life?

您可以通過思考“這不在我的職位描述中”并繼續前進來安全地安慰自己。 但是最后一個問題實際上使我難以接受：我是否為社會做任何事情，并且我的產品實際上在幫助我們的用戶過上更好的生活嗎？

I was faced with a dilemma. Should I keep doing what I was good at (development) or should I start focussing on other areas as well, apart from my usual stuff? At this juncture, I remembered a poem I had read in my childhood by the legendary poet Robert Frost:

我面臨一個困境。 我應該繼續做我擅長的(開發)工作，還是應該除了平常的工作以外，也開始專注于其他領域？ 在此關頭，我想起了童年時期傳奇詩人羅伯特·弗羅斯特(Robert Frost)讀過的一首詩：

Two roads diverged in a wood,兩條路在樹林中分叉， and I took the one less travelled by,然后我走了一個少走的路 and that has made all the difference.一切都改變了。

What I did for the next few months completely changed my perspective on my work. I have learned so much from people I rarely interacted with before. I have started to break the cocoon I had entrapped myself in. There’s a lot to learn, and I’ve just started to scratch the surface.

在接下來的幾個月中，我所做的一切完全改變了我對工作的看法。 我從從未與之交往過的人那里學到了很多東西。 我已經開始打破自己困住的繭了。有很多東西要學，而我才剛剛開始摸索。

這就是我現在要做的 (Here’s what I do now)

第1步 (Step 1)

Rather than just taking the requirements from my Product Manager, I brainstorm with him. I started asking the hard questions: Why? Why not? How will it work for the end user? How will it affect the business metric? What are your assumptions and expectations?

我不僅要聽取產品經理的要求，還和他一起暴雨 。 我開始問一個棘手的問題： 為什么？ 為什么不？ 最終用戶將如何工作？ 它將如何影響業務指標？ 您的假設和期望是什么？

Effect: There is a lot more clarity during the planning phase of the product’s development.

效果 ：在產品開發的計劃階段有很多清晰度。

第2步 (Step 2)

If possible, I ask someone to talk to our end users to see whether they would like such a change in the system. We get their feedback. If it is not possible to reach out to the end user, we ask people randomly whether they would like to have x, y, or z feature. Getting feedback before building the system is the most important part.

如果可能，我請某人與我們的最終用戶交談，以查看他們是否希望對系統進行這種更改。 我們得到他們的反饋 。 如果無法與最終用戶聯系，我們會隨機詢問人們是否希望具有x，y或z功能。 在構建系統之前獲取反饋是最重要的部分。

Then I brainstorm again with the Product Manager and refine the requirements according to the feedback received.

然后，我再次與產品經理進行頭腦風暴 ，并根據收到的反饋 細化要求。

Effect: We are closer to getting the complete picture and having a clearer perspective now.

效果 ：我們現在更接近完整的圖片并擁有更清晰的視角。

第三步 (Step 3)

Develop the system/feature, test it, and then deploy it to the end user.

開發系統/功能，對其進行測試 ，然后將其部署到最終用戶。

Track the journey of the feature just launched, and crunch the numbers every other day. Compare it with the previous business metric.

跟蹤剛剛推出該功能的旅程，隔日緊縮的數字 。 將其與先前的業務指標進行比較 。

Effect: We see the deviation of expectation from reality, and that helps us plan better the next time. Every failure is a new learning.

效果 ：我們看到期望與現實的背離 ，這有助于我們下次更好地計劃。 每一次失敗都是新的學習。

第4步 (Step 4)

Track the user issues on a daily basis. Go through the user tickets twice a day. Listen to their conversations with the operations people. A furious customer will often give you more insights into your product than your product manager, engineering manager, analyst, and product owner combined.

每天跟蹤 用戶問題 。 每天兩次通過用戶票證 。 聽取他們與操作人員的對話。 與產品經理，工程經理，分析師和產品所有者的總和相比，憤怒的客戶通常會為您提供更多有關產品的見解。

Listen to them, reiterate over the solution, sort it, fix the issue, and apologize. I have heard users swear, and trust me — they swear really badly.

聽取他們的意見，重申解決方案，進行排序，解決問題，并道歉。 我聽說用戶發誓并信任我-他們發誓非常糟糕。

Effect: We know which are some of the most painful points in our system and what our users don’t want.

效果 ：我們知道哪些是系統中最痛苦的一點，以及用戶不想要的 。

And at the end of the day: go home, sleep, reiterate.

歸根結底， 回家 ， 睡覺 ， 重申。

我學到了什么 (What I’ve learned)

Doing this, I have gained a lot of insights into my own product.

這樣做，我對自己的產品有了很多見識。

My product manager has taught me how to get the answer to “What my end user actually needs.”

我的產品經理教我如何獲得“最終用戶的實際需求”的答案。

The Engineering team has taught me how to track the user’s journey and how to crunch numbers on a daily basis.

工程團隊教會了我如何跟蹤用戶的旅程以及如何每天處理數字。

The operations team has been the voice of my end users. They have taken all the thrashings I would have gotten because of bugs I had put into the system.

運營團隊一直是我最終用戶的聲音。 由于我在系統中放入的錯誤，他們承擔了我所有的苦惱。

The product owner has taught me how to think long term and how you can achieve success if you develop a good thought process about the product.

產品負責人教會了我如何長遠思考，以及如何開發出對產品的良好思考過程才能取得成功。

And what made me do all this? That one question:

是什么讓我做這一切？ 那一個問題：

Why am I doing all this?我為什么要做這一切？

This is all my perspective, and it might differ from yours. I completely respect that. But ask the above question to yourself whenever you have some free time. If money is not the only motivator you get as a reply, think again and try to reiterate.

這是我的全部觀點，可能與您的觀點有所不同。 我完全尊重。 但是，只要有空閑時間，請向自己問上述問題。 如果金錢不是您獲得答復的唯一動機，請再三考慮并嘗試重申。

I am thankful to a lot of people who have helped me in my journey, which includes my engineering team, my product team, my operations team, and a lot of other people.

感謝許多在我的旅途中為我提供幫助的人，包括我的工程團隊，產品團隊，運營團隊以及許多其他人員。

翻譯自: https://www.freecodecamp.org/news/why-should-a-developer-think-like-a-product-owner-c3f813e4ea93/

mac 沒有所有開發者

總結

以上是生活随笔為你收集整理的mac 没有所有开发者_为什么开发人员应该像产品所有者那样思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。