初創公司股本結構_我如何向初創公司的開發團隊添加一些結構-以及從過程中學到的東西

初創公司股本結構

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

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

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.

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

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

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

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

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

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.

這種變化的催化劑是開發團隊缺乏領導能力。 CTO肩負著太多的責任，保持開發團隊的參與度和生產力的工作正逐漸陷入困境。

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

最重要的是，我們沒有項目經理，而且我們的產品經理經驗不足，無法介紹任何類型的結構。

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

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

導致變化的事件 (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.

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

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

所以我來自一個有很多過程的環境。這就是為什么我要去創業的部分原因。

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.

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

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.

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

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

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

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在發布前幾天聽到了一次談話，我們才意識到我們瞄準了系統的錯誤方面。

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.

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

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.

考慮到我的背景以及我是公司中最資深，最任職的開發人員之一的事實，讓我帶頭是很有意義的。

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.

自從我領導該計劃以來，我選擇實施一種Scrum型流程。在本文的其余部分，我將概述我們做了 什么，我們如何做， 為什么做以及我的學習。

獲得買入 (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.

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

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

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

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，我認為哪些元素可以使我們受益，以及看起來如何。我還討論了我在代理期間學到的有關測試計劃和系統質量檢查的一些知識。然后，我們圍著桌子走來走去，思考，提問和調整。

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.

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

Learnings:

學到：

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.
招募您的團隊來幫助共同構建，使每個人都成為解決方案的一部分，他們將與您一起擁有它。

我們的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流程的樣子后，我向團隊提出了各個方面和儀式的目的。我想強調一下我們可以從中獲得最大收益的地方。沒有人希望每個沖刺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周的時間開始，如果希望減少開銷并減少發布頻率，可以將其移至3周。

The process I put in place was as follows.

我執行的過程如下。

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個小時的梳理/計劃會議開始沖刺。在這次計劃會議中，我們(開發團隊和產品經理)對未完成訂單進行了檢查。此通行證包括澄清故事以消除誤解；估計使用故事點；并根據公司路線圖確定優先級。然后，團隊根據優先級挑選出我們認為可以完成的工作量，并將其納入當前的沖刺中。

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.

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

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

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

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

這個想法是在星期三結束之前完成初始質量檢查，然后在星期四和星期五進行錯誤修復/測試循環，直到我們對構建滿意為止。

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.

此時，該構建將移交給CTO進行最終代碼審查，并將在下周二進行部署。在代碼審查中發現的問題將在周一修復，并在需要時進行測試。

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.

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

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.

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

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.

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

Learnings:

學到：

Split and join meetings based on your team's needs. ?Don't do things "just because"
根據您團隊的需要拆分和參加會議。不要“僅僅因為”做事情
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. ?

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

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

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

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.

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

Learnings:

學到：

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

成功 (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.

結果如何？我沒有確切的數字，但是缺陷率急劇下降。不再匆忙修補生產。承諾的工作已經完成。功能已按時發布。

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.

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

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

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

Learnings:

學到：

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

突然結束 (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.

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

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

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

我們回到了筒倉。開發團隊推遲了，我們試圖做出讓步，以在團隊級別停止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.

這種變化與權力結構的輕微變化不謀而合，我作為首席開發人員的頭銜只不過是陳詞濫調，“領導”對開發團隊說了一些非常不友好的內容(類似于“上任或下班”) ，導致一半的開發團隊(包括我自己)在一個月內離開。

Learnings:

學到：

Good ideas don't always win out. ?Even in a situation like this, you can learn a lot.
好主意不一定總能贏。即使在這種情況下，您也可以學到很多東西。
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.

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

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.

我離開已經大約一年了，那時我學到了一兩件事。我們創建的過程中存在一些嚴重的差距。這些是我當時當時并不真正了解或了解的東西。這是由于我的缺點，但我們每天都在進步。

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.

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

過多的手動測試，不包含自動化。 (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測試套件。我們在接近尾聲時就開始進行這些工作，但是對它們的優先級還不夠高。我們在手動測試中發現的許多錯誤可能是在使用Cucumber的某些驗收測試或某些E2ESelenium測試中發現的。

大爆炸發布。 (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工作都被演示并一起發布。

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有多個版本會更好。協調測試和質量檢查比較困難，但最好還是經常發布。

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

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

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

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

結論 (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. ?

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

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

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

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

盡管結局很差，但這是我職業上的一大進步，確實鞏固了我的領導能力和渴望。

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

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