初創(chuàng)公司股本結(jié)構(gòu)

Until recently, I'd spent the last 4 years of my career at FinTech start-ups. I'd always worked for smaller companies, and being at a start-up was the next logical step in looking for roles where I could make the biggest difference. ?

直到最近，我在金融科技初創(chuàng)公司度過了職業(yè)生涯的最后四年。 我一直在較小的公司工作，而在初創(chuàng)公司是尋找可以發(fā)揮最大作用的角色的下一個邏輯步驟。

But a common problem with early-stage start-ups is that it's kind of a free-for-all in terms of how they're managed.

但是，早期初創(chuàng)企業(yè)的一個普遍問題是，就如何管理它們而言，這是一種萬能的。

These companies tend to be run by people who don't have a ton of experience running companies. And management tends to consist of founders and those who got in early, not necessarily those who excel in leadership roles. (No shade – good person + talented doesn't necessarily mean they're a good boss or leader).

這些公司往往由沒有大量運營公司經(jīng)驗的人經(jīng)營。 管理層往往由創(chuàng)始人和早起的人組成，不一定是那些在領(lǐng)導(dǎo)角色方面表現(xiàn)出色的人。 (沒有陰影-好人+有才華并不一定意味著他們是好老板或領(lǐng)導(dǎo)者)。

During my time at one such start-up, I was promoted from senior developer to lead developer.

在一家這樣的初創(chuàng)公司工作期間，我從高級開發(fā)人員晉升為首席開發(fā)人員。

The catalyst for this change was that the development team lacked leadership. The CTO had too many responsibilities, and the job of keeping the dev team engaged and productive was falling through the cracks.

這種變化的催化劑是開發(fā)團隊缺乏領(lǐng)導(dǎo)能力。 CTO肩負著太多的責(zé)任，保持開發(fā)團隊的參與度和生產(chǎn)力的工作正逐漸陷入困境。

On top of this, we didn't have a project manger, and our product managers were too inexperienced to introduce any kind of structure.

最重要的是，我們沒有項目經(jīng)理，而且我們的產(chǎn)品經(jīng)理經(jīng)驗不足，無法介紹任何類型的結(jié)構(gòu)。

This is the story of the wins and losses, and how to add process to a company that has none.

這是關(guān)于勝利與失敗以及如何為沒有一家公司的公司增加流程的故事。

導(dǎo)致變化的事件 (Events leading to the change)

First, a little bit of background. My previous job had been as a developer at a digital agency. This agency was a hard-core scrum shop that had trained all of their employees fairly thoroughly in scrum, and agile in general.

首先，有一點背景知識。 我以前的工作是在一家數(shù)字代理公司擔(dān)任開發(fā)人員。 該機構(gòu)是一家核心的Scrum商店，已經(jīng)對所有員工進行了相當(dāng)全面的Scrum培訓(xùn)，并且總體上敏捷。

So I came from an environment with a lot of process. That's partially why I left to pursue a start-up.

所以我來自一個有很多過程的環(huán)境。 這就是為什么我要去創(chuàng)業(yè)的部分原因。

About a year in, I started to notice some issues. Firstly, the developer turn-over was growing. Developers weren't feeling engaged. They were handed half-baked projects with no context on how it would aid the growth of the company, no input in the design or planning, and with nowhere near enough detail.

大約一年后，我開始注意到一些問題。 首先，開發(fā)商的營業(yè)額正在增長。 開發(fā)人員沒有參與的感覺。 他們是半熟的項目，他們沒有任何關(guān)于如何幫助公司發(fā)展的背景，沒有設(shè)計或規(guī)劃方面的投入，也沒有足夠的細節(jié)。

Then came a project that crystallized our problem. The product that I worked on had the concept of bills (payables) and invoices (receivables). We were working on a new feature that would allow users to upload an image of an invoice and have it input manually by a service.

然后是一個明確了我們問題的項目。 我研究的產(chǎn)品具有票據(jù)(應(yīng)付款)和發(fā)票(應(yīng)收款)的概念。 我們正在開發(fā)一項新功能，該功能將允許用戶上傳發(fā)票圖像并由服務(wù)手動輸入。

The problem was that the product manager kept saying "bills" instead of "invoices". There was no user story, no ticket, this was all in the mind of the product manager. Requirements were communicated verbally or in slack messages. The developer working on the project had only ever been told "bills".

問題是產(chǎn)品經(jīng)理一直說“帳單”而不是“發(fā)票”。 沒有用戶故事，沒有門票，這是產(chǎn)品經(jīng)理的全部想法。 需求以口頭形式或松弛信息傳達。 僅在項目開發(fā)人員中被告知“條例草案”。

It wasn't until the CTO overheard a conversation a few days before release that we realized that we'd targeted the wrong aspect of the system.

直到CTO在發(fā)布前幾天聽到了一次談話，我們才意識到我們瞄準(zhǔn)了系統(tǒng)的錯誤方面。

Luckily, bills and invoices were, for the most part, symmetrical in our system, so it wasn't much work to make the change. It just became very clear that we had a problem.

幸運的是，票據(jù)和發(fā)票在我們的系統(tǒng)中大部分都是對稱的，因此進行更改不需要太多工作。 很明顯我們遇到了問題。

Given my background and the fact that I was one of the most senior and tenured developers at the company, it made sense for me to take the lead.

考慮到我的背景以及我是公司中最資深，最任職的開發(fā)人員之一的事實，讓我?guī)ь^是很有意義的。

Since I was leading the initiative, I chose to implement a scrum-type process. ?In the remainder of this article, I'll outline what we did, how we did it, and why it was done, as well as my learnings.

自從我領(lǐng)導(dǎo)該計劃以來，我選擇實施一種Scrum型流程。 在本文的其余部分，我將概述我們做了 什么，我們如何做， 為什么做以及我的學(xué)習(xí) 。

獲得買入 (Getting Buy-in)

I'm gonna preface this by saying that I don't like handing commandments down from on high. I feel like a leader-team relationship is a collaborative one. I may occasionally play leader because it's my nature, but it's important that ideas are discussed and that people feel their opinions are heard and valued.

我要說這句話是我不喜歡從高處傳下誡命。 我覺得領(lǐng)導(dǎo)團隊關(guān)系是一種協(xié)作關(guān)系。 我有時會扮演領(lǐng)導(dǎo)者的角色，因為這是我的天性，但重要的是要討論想法，讓人們感到自己的意見得到重視和重視。

The first step was to gather the developers to have a discussion. ?In this initial discussion, I outlined what I felt our issues were. ?This included lack of clarity on requirements, sliding deadlines, and our complete lack of a testing strategy. ?The discussion validated my thoughts, because the team felt the same way. ?

第一步是召集開發(fā)人員進行討論。 在最初的討論中，我概述了我認(rèn)為我們的問題所在。 這包括對要求的不明確，截止日期的縮短以及我們完全缺乏測試策略。 討論證實了我的想法，因為團隊也有同樣的想法。

The rest of the meeting consisted of me outlining scrum, what elements I felt could benefit us, and what that would look like. I also discussed some things that I learned about test plans and systematic QA that I learned in my agency days. ?We then went around the table, giving thoughts, asking questions, and tweaking.

會議的其余部分包括我概述scrum，我認(rèn)為哪些元素可以使我們受益，以及看起來如何。 我還討論了我在代理期間學(xué)到的有關(guān)測試計劃和系統(tǒng)質(zhì)量檢查的一些知識。 然后，我們圍著桌子走來走去，思考，提問和調(diào)整。

I conceded that manual testing wasn't fun or ideal for the dev team, but until we could justify a full-time QA engineer, we had to do the best with what we had.

我承認(rèn)，對于開發(fā)團隊而言，手動測試并不是一件有趣的事情，也不是理想的選擇，但是在我們能夠證明一名全職QA工程師合理之前，我們必須盡力做到最好。

Learnings:

學(xué)到：

• If you have a good idea, all you need is a chance to prove its worth.
  如果您有個好主意，您所需要的就是證明其價值的機會。
• Enlist your team to help build this together, make everyone part of the solution and they'll own it with you.
  招募您的團隊來幫助共同構(gòu)建，使每個人都成為解決方案的一部分，他們將與您一起擁有它。

我們的Scrum版本 (Our Version of Scrum)

After describing what a "full" scrum process would look like, I laid out to the team what the purpose of each aspect and ritual was. ?I wanted to highlight where we could get the most gains. No one wanted 10 hours of meetings per sprint. ?

在描述了“完整”的Scrum流程的樣子后，我向團隊提出了各個方面和儀式的目的。 我想強調(diào)一下我們可以從中獲得最大收益的地方。 沒有人希望每個沖刺10個小時的會議。

Speaking of sprints, we decided to start with a 2 week time-box with an eye on moving it to 3 weeks if we wanted less overhead and could afford less frequent releases.

說到sprint，我們決定從2周的時間開始，如果希望減少開銷并減少發(fā)布頻率，可以將其移至3周。

The process I put in place was as follows.

我執(zhí)行的過程如下。

We'd have a sprint started with a 2-hour grooming/planning meeting on a Monday morning. In this planning meeting we (the dev team and the product manager) did a pass over the backlog. ?This pass consisted of clarifying the story to clear up misunderstandings; estimating using story points; and prioritizing based on company road-map. ?The team then picked out the amount of work we felt we could do, based on priority, and brought it into the current sprint.

我們會從一個星期一早上的2個小時的梳理/計劃會議開始沖刺。 在這次計劃會議中，我們(開發(fā)團隊和產(chǎn)品經(jīng)理)對未完成訂單進行了檢查。 此通行證包括澄清故事以消除誤解； 估計使用故事點； 并根據(jù)公司路線圖確定優(yōu)先級。 然后，團隊根據(jù)優(yōu)先級挑選出我們認(rèn)為可以完成的工作量，并將其納入當(dāng)前的沖刺中。

This work was a collection of user stories. The product manager would leave, and the dev team would break these stories down into tasks, get a general sense of who would work on what, and then we got to work. ?This gave the product manager transparency on what we could deliver, which was sorely lacking. ?It also gave the team their full workload for 2 weeks, which allowed us to plan and pace accordingly.

這項工作是用戶故事的集合。 產(chǎn)品經(jīng)理將離開，開發(fā)團隊將把這些故事分解成任務(wù)，大致了解誰將從事哪些工作，然后我們開始工作。 這使產(chǎn)品經(jīng)理可以透明地提供我們所能提供的東西，而這是非常缺乏的。 這也為團隊提供了2周的全部工作量，這使我們能夠做出相應(yīng)的計劃和進度。

The next week and a half were dev days. This included peer code reviews on feature branches before they were merged. Dev hands-off was the Wednesday of the 2nd week at noon. We would then prepare the QA build, QA spreadsheet (more on this in a bit), and start manual testing. ?

接下來的一周半是開發(fā)日。 這包括在合并功能分支之前對它們進行對等代碼審查。 開發(fā)人員交接時間是第二周中午的第二個星期三。 然后，我們將準(zhǔn)備質(zhì)量檢查構(gòu)建，質(zhì)量檢查電子表格(稍后對此進行詳細介紹)，并開始進行手動測試。

The idea was to finish the initial QA pass by the end of the Wednesday, and spend Thursday and Friday in a bug fix/test loop until we were satisfied with the build. ?

這個想法是在星期三結(jié)束之前完成初始質(zhì)量檢查，然后在星期四和星期五進行錯誤修復(fù)/測試循環(huán)，直到我們對構(gòu)建滿意為止。

At this point, the build would be handed off to the CTO for a final code review, and it would be deployed the following Tuesday. Issues found in the code review would be fixed and tested on the Monday if needed.

此時，該構(gòu)建將移交給CTO進行最終代碼審查，并將在下周二進行部署。 在代碼審查中發(fā)現(xiàn)的問題將在周一修復(fù)，并在需要時進行測試。

Friday afternoon we would have a blameless retrospective/postmortem. Here we laid things bare. It's important to acknowledge what went poorly, and to address the cause(s) so that we could avoid it in the future.

星期五下午，我們將進行無罪的回顧/驗尸。 在這里，我們把事情暴露了。 重要的是要確認(rèn)出現(xiàn)問題的原因，并解決原因，以便我們將來可以避免。

All of the developers (including myself) learned a lot through this process. I feel like we're all better off after having gone through it. I actually overheard the CEO suggest doing blameless postmortems a few weeks after we started doing them on the dev team. It was nice to see that our ideas were catching on.

所有開發(fā)人員(包括我自己)在此過程中都學(xué)到了很多東西。 我覺得經(jīng)過這件事我們都過得更好。 實際上，我聽錯了CEO的建議，即在我們開始在開發(fā)團隊中進行幾周的無罪死后尸檢。 很高興看到我們的想法正在流行。

This was one of the big wins. We learned why a feature was needed, what the intention behind it was, and all of the details and expectations.

這是最大的勝利之一。 我們了解了為什么需要功能，其目的是什么以及所有細節(jié)和期望。

Learnings:

學(xué)到：

• Split and join meetings based on your team's needs. ?Don't do things "just because"
  根據(jù)您團隊的需要拆分和參加會議。 不要“僅僅因為”做事情
• Share your progress outside your department. ?Sometimes your ideas can provide benefits outside of your team.
  在部門外分享您的進度。 有時，您的想法可以為您的團隊帶來好處。

您可以相信的測試框架 (A Testing Framework That You Can Believe In)

This company had never had a formal testing process. This meant no test plan, no peer testing, just a developer verifying that it worked, and it going to production. ?

該公司從未有過正式的測試流程。 這意味著沒有測試計劃，沒有同行測試，只有開發(fā)人員驗證它是否有效并投入生產(chǎn)。

In my experience, developers are as good at testing as they are at estimating, so we needed to change that. We had a good suite of automated tests (unit and integration), but no end-to-end tests. I also prefer to have some exploratory testing as well. In the past, I've seen it uncover weird behaviors that automated testing can miss. ?

以我的經(jīng)驗，開發(fā)人員在測試和評估方面都擅長，因此我們需要對此進行更改。 我們有一套很好的自動化測試(單元和集成)，但是沒有端到端測試。 我也更喜歡進行一些探索性測試。 過去，我發(fā)現(xiàn)它揭示了自動測試可能會遺漏的怪異行為。

We set up a google doc with all of the tickets (including links to the user stories) in the first column, and all of the developer names (and the PM) in the first row. The idea was that every ticket had to have 2 X's, both from people who didn't work on the feature. This divide and conquer strategy allowed us to test very thoroughly in a fairly short amount of time.

我們在第一列中設(shè)置了所有票證(包括指向用戶故事的鏈接)，在第一行中包含了所有開發(fā)人員名稱(和PM)的Google文檔。 這個想法是，每張票都必須有2個X，都來自沒有使用該功能的人。 這種分而治之的策略使我們能夠在相當(dāng)短的時間內(nèi)進行徹底的測試。

Learnings:

學(xué)到：

• Lean hard on automated testing. ?It's reliable and finds many classes of bugs with no manual time.
  努力學(xué)習(xí)自動化測試。 它是可靠的，并且無需手動即可發(fā)現(xiàn)許多類別的錯誤。
• Test with a plan. ?You're going to waste a lot of time just wandering. ?A systematic approach can make manual testing more efficient.
  用計劃進行測試。 你會浪費很多時間只是在流浪。 系統(tǒng)的方法可以使手動測試更加有效。

成功 (Success)

What was the result? I don't have exact numbers, but the defect rate plummeted. There were no longer rushed hot fixes to production. The work promised was delivered. Features were being released on time.

結(jié)果如何？ 我沒有確切的數(shù)字，但是缺陷率急劇下降。 不再匆忙修補生產(chǎn)。 承諾的工作已經(jīng)完成。 功能已按時發(fā)布。

We were moving faster than ever, and the developers were happier. We were working as a team instead of in silos, we all knew each others' features intimately because we all went through the user stories and estimated together. There was no more of this "oh, I can't touch feature X, I didn't work on it" siloing stuff.

我們的移動速度比以往任何時候都快，并且開發(fā)人員更快樂。 我們是一個團隊而不是孤島，我們都非常了解彼此的功能，因為我們都經(jīng)歷了用戶故事并一起進行了估算。 沒有更多的“哦，我不能觸摸功能X，我沒有進行處理”的東西。

One dev who was planning on leaving stopped looking. It was great.

一位計劃離開的開發(fā)人員停止尋找。 太好了。

Learnings:

學(xué)到：

• Keep adjusting your process based on results. ?It's an ongoing process.
  繼續(xù)根據(jù)結(jié)果調(diào)整流程。 這是一個持續(xù)的過程。
• Sometimes people don't want to leave a company, they want to leave a situation.
  有時人們不想離開公司，而是想離開一種情況。

突然結(jié)束 (An Abrupt End)

But nothing gold can stay :) Ok, that's a bit dramatic. While the dev team was gelling, increasing our velocity, and building more camaraderie, management was going in a different direction.

但是，沒有任何黃金可以留下：)好吧，這有點戲劇性。 當(dāng)開發(fā)團隊陷入困境，提高我們的速度并建立更多友愛關(guān)系時，管理人員卻朝著另一個方向發(fā)展。

The CEO had done a ton of reading and decided that OKRs were what was gonna get the company to the next level. Unfortunately, it was decided that OKRs would go down to the individual level, meaning that the team would no longer be pooling work, breaking it down and tackling it together. Instead, each developer would work out (or in practice, given) a set of KRs, and they alone would be responsible for delivering on them. ?

首席執(zhí)行官進行了大量閱讀，并決定將OKR提升到一個新的水平。 不幸的是，決定將OKR降到個人水平，這意味著團隊將不再集中精力，分解工作并將其解決。 取而代之的是，每個開發(fā)人員都會制定一套(或在實踐中給出)一套KR，而他們自己將負責(zé)交付這些KR。

We were back to silos. The development team pushed back, we tried to compromise, to stop OKRs at the team level, but it was no use. The dream was dead. Yes, again with the drama, but it was a little sad.

我們回到了筒倉。 開發(fā)團隊推遲了，我們試圖做出讓步，以在團隊級別停止OKR，但這沒有用。 夢想已死。 是的，這出戲又來了，但是有點難過。

This change coincided with a slight change in power structure, my title as lead developer became little more than a platitude, "leadership" said some very unkind things to the development team (somewhere along the lines of "get on board or get out"), which led to half the dev team, including myself, leaving within a month.

這種變化與權(quán)力結(jié)構(gòu)的輕微變化不謀而合，我作為首席開發(fā)人員的頭銜只不過是陳詞濫調(diào)，“領(lǐng)導(dǎo)”對開發(fā)團隊說了一些非常不友好的內(nèi)容(類似于“上任或下班”) ，導(dǎo)致一半的開發(fā)團隊(包括我自己)在一個月內(nèi)離開。

Learnings:

學(xué)到：

• Good ideas don't always win out. ?Even in a situation like this, you can learn a lot.
  好主意不一定總能贏。 即使在這種情況下，您也可以學(xué)到很多東西。
• Recognize when you can no longer make a difference.
  識別何時不再可以有所作為。

犯了錯誤 (Mistakes Were Made)

Given the way that last paragraph ended, you may thing that I was about to enumerate the mistakes that the company made. But I'm not going to do that.

鑒于最后一段的結(jié)尾方式，您可能想列舉一下公司所犯的錯誤。 但是我不會那樣做。

It's been about a year since I left, and in that time I've learned a thing or two. There were some serious gaps in the process that we'd created. These were things that I just didn't really understand or know about at the time. It was due to my shortcomings, but we all get better every day.

我離開已經(jīng)大約一年了，那時我學(xué)到了一兩件事。 我們創(chuàng)建的過程中存在一些嚴(yán)重的差距。 這些是我當(dāng)時當(dāng)時并不真正了解或了解的東西。 這是由于我的缺點，但我們每天都在進步。

In hindsight, here are some major things I'd missed:

事后看來，我錯過了一些主要的事情：

我們沒有測量。 (We weren't measuring. ?)

How do you know you've done it right if you didn't take measurements before and after? We had no telemetry, very little alerting, and frankly, if a feature had negative impact, we didn't know about it.

如果您前后沒有進行測量，您怎么知道您做對了？ 我們沒有遙測功能，很少發(fā)出警報，坦率地說，如果某個功能產(chǎn)生了負面影響，我們對此一無所知。

過多的手動測試，不包含自動化。 (Too much manual testing, not embracing automation. ?)

What we were really missing was a nice suite of automated E2E tests. We started working on these near the end, but we didn't prioritize them enough. Many of the errors we found during manual testing could have been caught during some acceptance tests using cucumber, or some E2E selenium tests.

我們真正缺少的是一套不錯的自動化E2E測試套件。 我們在接近尾聲時就開始進行這些工作，但是對它們的優(yōu)先級還不夠高。 我們在手動測試中發(fā)現(xiàn)的許多錯誤可能是在使用Cucumber的某些驗收測試或某些E2ESelenium測試中發(fā)現(xiàn)的。

大爆炸發(fā)布。 (Big bang releases. ?)

I know a common part of scrum for many companies is the idea that all of the sprint work is demoed and released together.

我知道，對于許多公司而言，Scrum的一個共同部分是這樣的想法，即所有sprint工作都被演示并一起發(fā)布。

The problem with this is two-fold. Firstly, at a start-up you need to move quicker. You need to beat others to the punch and get value out to customers and feedback from customers as quickly as possible. And the tighter that feedback look is, the better. ?

這個問題有兩個方面。 首先，在啟動時，您需要更快地移動。 您需要擊敗其他人，并盡快將價值傳遞給客戶并獲得客戶的反饋。 反饋看起來越緊密越好。

Therefore, multiple releases per sprint would have been better. It's more difficult to coordinate testing and QA, but it's still better to release quickly and often.

因此，每個sprint有多個版本會更好。 協(xié)調(diào)測試和質(zhì)量檢查比較困難，但最好還是經(jīng)常發(fā)布。

Secondly, the larger the release, the more risk is involved. Releasing smaller chunks means that fewer changes are released at one time. If there's any issue, it's easier to identify and fix, and a rollback won't affect other, correctly functioning features. ?

其次，釋放量越大，涉及的風(fēng)險就越大。 釋放較小的塊意味著一次發(fā)布較少的更改。 如果有任何問題，則更容易識別和修復(fù)，并且回滾不會影響其他功能正常的功能。

So I've learned that releasing in verticals that are as small as possible is the safest, least coupled way of releasing software.

因此，我了解到，垂直發(fā)行越小越好，這是發(fā)行軟件最安全，耦合最少的方法。

結(jié)論 (Conclusion)

For all of the missteps and the unfortunate ending, I feel like the experience was a success. I learned what it meant to guide a team of developers through a process, to take feedback and apply it, and to try and discard ideas that, even though they are "supposed to be there", just didn't fit our team. ?

盡管經(jīng)歷了所有的失誤和不幸的結(jié)局，我覺得這次經(jīng)歷是成功的。 我了解了指導(dǎo)一個開發(fā)人員團隊進行整個過程，獲取反饋并加以應(yīng)用以及試圖丟棄那些即使它們“應(yīng)該存在”但又不適合我們團隊的想法的含義。

It's important to cater your process to your team and organization. You have to add enough process to guide, but not so much to hinder. It taught me how to implement process, to push ideas forward, to help others be heard, and how to lead from within a team. ?

為您的團隊和組織服務(wù)是很重要的。 您必須添加足夠的過程來進行指導(dǎo)，但沒有太多阻礙。 它教會了我如何實施流程，推動思想前進，幫助他人發(fā)表意見以及如何在團隊中發(fā)揮領(lǐng)導(dǎo)作用。

Although it ended poorly, it was a big step forward in my career, and really solidified my ability and desire to lead.

盡管結(jié)局很差，但這是我職業(yè)上的一大進步，確實鞏固了我的領(lǐng)導(dǎo)能力和渴望。

You can find more of my articles on my medium blog.

您可以在我的中等博客中找到更多我的文章。

翻譯自: https://www.freecodecamp.org/news/how-i-added-some-structure-to-a-start-up-dev-team/

初創(chuàng)公司股本結(jié)構(gòu)

總結(jié)

以上是生活随笔為你收集整理的初创公司股本结构_我如何向初创公司的开发团队添加一些结构-以及从过程中学到的东西的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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