Slack không cần giới thiệu, vì vậy tôi sẽ đi thẳng vào. Cảm ơn Cal Henderson , Keith Adams và Ali Rayl vì đã giúp tôi thực hiện điều này.
Đây là một vấn đề từ bản tin miễn phí của tôi, Monolith . Tôi viết về cách các công ty thành công xây dựng sản phẩm của họ (và phá vỡ các quy tắc) trước khi họ có sản phẩm phù hợp với thị trường.
Tóm tắt lịch sử: Sự ra đời của Slack từ một công ty trò chơi điện tử thất bại là truyền thuyết của Thung lũng vào thời điểm này. Câu chuyện thông thường, cũng như với tất cả các truyền thuyết, được giật gân hóa.
Năm 2009, những người đồng sáng lập Stewart Butterfield, Cal Henderson, Eric Costello và Serguei Mourachov bắt đầu xây dựng một trò chơi điện tử mà trước đó họ đã thất bại trong việc xây dựng vào năm 2002. Stewart và Cal tại một hội nghị năm 2010: (bảng điểm):
Chúng ta có cơ hội tuyệt vời để thành công vì trước đây chúng ta đã từng thất bại và khả năng thất bại hai lần cùng một việc là khá thấp, đúng là một điều phi thường. Năm 2002, chúng tôi thành lập công ty có tên là Ludicorp và chúng tôi đang cố gắng tạo ra một trò chơi có tên là Game Neverending. Điều tương tự: một trò chơi nhiều người chơi dựa trên web ngoại trừ năm 2002. Rất nhiều thứ đã khác. Chủ yếu trong số đó là không thể huy động tiền cho các công ty khởi nghiệp internet phải đối mặt với người tiêu dùng vì đó là sự cố sau dot-com, sau ngày 11 tháng 9, WorldCom, Enron, bạn biết đấy, thực sự là một thời gian khó khăn hơn nhiều để huy động vốn nên chúng tôi đã hết tiền khi chúng tôi đang thực hiện một phần quá trình tạo trò chơi và cố gắng làm điều gì đó khác với công nghệ. Đó là một cái gì đó khác là Flickr. Flickr đã được Yahoo mua lại và chúng tôi đã dành vài năm để làm điều đó. Bốn người chúng tôi từ nhóm Flickr đã thành lập một công ty mới, Tiny Speck, và chúng tôi đang tạo ra Glitch.
Với lối thoát thành công dưới vành đai của họ và một môi trường gây quỹ khác, tiền thật dễ dàng: (bảng điểm):
Chúng tôi có thể huy động bao nhiêu tiền tùy thích. Vì vậy, đó là dễ dàng. Chúng tôi thậm chí còn không làm một bộ bài. Chúng tôi chỉ nói “chúng tôi muốn một số tiền” và mọi người đã cho chúng tôi tiền.
Nhóm đã huy động được 5 triệu đô la từ Accel vào năm 2010 và 10 triệu đô la khác từ Accel và a16z vào năm 2011. Trục trặc ra mắt vào tháng 9 năm 2011. Đến cuối năm 2012, rõ ràng là trò chơi sẽ không hoạt động. Họ tắt Glitch xuống. Họ còn lại 5 triệu đô la và một công cụ liên lạc nội bộ.
Ngay từ đầu, nhóm của Tiny Speck đã được phân bổ :
Nhóm điều hành của Tiny Speck đã có trụ sở tại các thành phố khác nhau trên khắp Bắc Mỹ. Butterfield và Mourachov sống ở Vancouver, Henderson dựng trại ở San Francisco và Costello quản lý việc phát triển khách hàng từ Thành phố New York.
Để giao tiếp dễ dàng hơn, họ đã xây dựng một hệ thống nội bộ xung quanh IRC: (bản dịch):
Dần dần, chúng tôi đã phát triển một hệ thống là nền tảng của tất cả các cách thức giao tiếp của công ty và thực sự có lợi và nhận ra, huh, không ai trong chúng tôi sẽ làm việc mà không có thứ gì đó như thế này nữa và các nhóm 8 nhà phát triển phần mềm khác có lẽ cũng sẽ thích như vậy . Vì vậy, chúng tôi quyết định đó là những gì chúng tôi sẽ làm.
Hai năm tiếp theo là một tên lửa:
Slack ra mắt công chúng vào năm 2019 với mức định giá 15,7 tỷ đô la.
Phiên bản nội bộ ban đầu của Slack chỉ là một trình bao bọc xung quanh IRC: Internet Relay Chat (IRC) là một giao thức từ cuối những năm 80. Nhóm Tiny Speck đã sử dụng IRC, nhưng nó có một số sai sót lớn. Giao thức không hỗ trợ các tin nhắn liên tục, tìm kiếm hoặc tải tệp lên nên nhóm đã xây dựng các tính năng họ cần xung quanh một máy chủ IRC có sẵn. Từ Stewart: (bản ghi):
Chúng tôi đã phát triển một hệ thống là proto-Slack. Một lần nữa, vào năm 92, một trong những công cụ mạng mà tôi đã sử dụng là IRC hoặc Internet Relay Chat. Chúng tôi đã sử dụng IRC tại Tiny Speck và đó là một công nghệ rất cũ.
Với hầu hết các hệ thống nhắn tin, có một khái niệm về lưu trữ và chuyển tiếp. Nếu tôi muốn gửi tin nhắn cho bạn nhưng không có kết nối với ứng dụng khách của bạn, tin nhắn đó sẽ được giữ lại và sau đó được chuyển tiếp cho bạn vào lần kết nối tiếp theo. IRC không có điều đó. Nếu bạn không kết nối vào thời điểm tôi gửi tin nhắn, bạn sẽ không bao giờ nhận được nó. Vì vậy, chúng tôi đã xây dựng một hệ thống để ghi lại các tin nhắn. Nhưng một khi chúng tôi có các tin nhắn trong cơ sở dữ liệu, chúng tôi muốn có thể tìm kiếm chúng. Vì vậy, chúng tôi đã xây dựng tìm kiếm. Và sau đó, từng chút một, từng tính năng, chúng tôi đã xây dựng mọi thứ để tích hợp với máy chủ tệp của mình để khi ai đó tải tệp lên, tệp đó sẽ được thông báo vào IRC hoặc nếu có cảnh báo trong trung tâm dữ liệu thì tệp đó sẽ được đưa vào IRC.
Khi nhóm phát triển Glitch, họ sẽ định kỳ gửi một tính năng cực kỳ cần thiết để cải thiện IRC. Một lần nữa từ Stewart: (bản dịch):
Khi có một cơ hội rõ ràng đến mức chúng tôi không thể không tận dụng nó, chúng tôi sẽ dành số phút tối thiểu cho cơ hội đó và sau đó quay lại với nó (phát triển Trục trặc). Vào cuối quá trình đó, chúng tôi đã có sản phẩm được thiết kế hoàn chỉnh này mà chúng tôi đang sử dụng, đó là một triển khai tồi tệ, không phải là điều bạn sẽ làm nếu bắt đầu lại từ đầu, nhưng rõ ràng đây là thứ có giá trị to lớn.
Khi nhóm xoay trục vào cuối năm 2012, họ tiếp tục sử dụng phiên bản IRC nội bộ trong hai tháng trong khi xây dựng Slack từ đầu. Họ chuyển qua khi sản phẩm đã sẵn sàng để sử dụng nội bộ.
MVP gặp vấn đề về UX đối với các nhóm lớn hơn ~10 người: Ban đầu, họ “năn nỉ và thuyết phục” bạn bè của họ ở các công ty khác dùng thử và đưa ra phản hồi. Họ bắt đầu với sáu đến mười công ty. Rdio là công ty lớn nhất với khoảng 120 nhân viên. Rõ ràng là sản phẩm hoạt động rất khác đối với các nhóm lớn hơn so với của Slack.
Từ Cal: (bản dịch):
Những ngày đầu tiên được người khác sử dụng là khoảng thời gian nhận được rất nhiều phản hồi phong phú. Có rất nhiều điều mà chúng tôi chưa nghĩ tới vì chúng tôi đã quá quen thuộc với cách làm việc nhưng cũng có những điều thực sự ngớ ngẩn. Nếu bạn có hai người trong công ty của mình tên là “Matt” thì không có cách nào để phân biệt giữa họ hoặc nếu bạn có 20 người trong nhóm của mình thì không có danh sách cuộn vì chúng tôi là một nhóm 8 người.
Nhóm Slack đã kết hợp phản hồi đó vào sản phẩm, giới thiệu nhiều nhóm hơn và tiếp tục kết hợp phản hồi đó vào sản phẩm. Chu kỳ sản phẩm lặp đi lặp lại này là điều họ học được từ Flickr.
Một lần nữa từ Cal: (bản dịch):
Một bài học rõ ràng mà chúng tôi rút ra từ Flickr là khi bạn nhìn vào những sản phẩm phần mềm tuyệt vời, những sản phẩm tuyệt vời không bắt đầu theo cách đó. Họ bắt đầu theo một cách rất khác, sản phẩm được trình bày rất khác, người dùng tương tác theo những cách khác nhau và nhóm đôi khi lặp đi lặp lại một cách ồ ạt để đạt được vị trí như ngày hôm nay. Đó là tất cả về vòng phản hồi để hiểu những gì khách hàng của bạn đang làm, những vấn đề họ đang gặp phải, những gì họ đang cố gắng đạt được và đưa điều đó trở lại thiết kế phần mềm của bạn và lặp lại hướng tới một sản phẩm có thể tuyệt vời và mọi người có thể yêu thích .
Kiến trúc của Slack giống với kiến trúc của một trò chơi trực tuyến: Các ứng dụng khách của Slack đã lưu trữ mọi thứ vào bộ nhớ cache. Khi khởi động, họ sẽ thực hiện một yêu cầu API duy nhất, được gọi là rtm start. Thao tác này sẽ tải xuống mọi thứ về không gian làm việc của người dùng bao gồm kênh, thành viên và tư cách thành viên của kênh. Sau đó, máy khách sẽ mở kết nối WebSocket để gửi và nhận các bản cập nhật cho bộ đệm cục bộ.
Từ Keith Adams, kiến trúc sư trưởng của Slack từ năm 2016 đến năm 2020, nói về việc giới truyền thông thích kể câu chuyện xoay trục của Slack từ một trò chơi trực tuyến như thế nào: (bản ghi):
Thông thường, mọi người chỉ đề cập đến điều này như một điều buồn cười: “Ồ, họ là một công ty trò chơi, đôi khi bánh quy bị vỡ vụn có buồn cười không?”. Điều đó đúng, nhưng nó thực sự quay trở lại theo những cách nhất định. Nếu bạn nheo mắt và nghiêng đầu, kiến trúc thực tế của Slack giống với kiến trúc của một trò chơi trực tuyến nhiều người chơi. Bạn gần như có “thế giới” mà bạn hoạt động, đó là nhóm của bạn và để làm cho thế giới đó vừa bền bỉ vừa có thể thay đổi tương tác với những thứ khác trên thế giới, cuối cùng bạn sẽ tạo ra một bộ đệm khá dày về những gì đang diễn ra trong đó. thế giới đó và sau đó bạn có cách để nhận các bản cập nhật có độ trễ thấp cho những thay đổi trong thế giới đó. Kiểu mô hình tinh thần “ồ, nó giống như một trò chơi trực tuyến” giải thích rất nhiều điều về Slack. Đó là lý do tại sao chúng tôi có màn hình tải chẳng hạn. Đó cũng là lý do khiến trò chơi điện tử có xu hướng tải màn hình.
Slack được xây dựng để giải quyết vấn đề của chính họ. Tương tự như Nomad List , phiên bản ban đầu của sản phẩm xuất phát từ nhu cầu thực sự của (những) người sáng tạo.
Những điều đơn giản có thể mang lại giá trị to lớn. Slack chỉ đơn giản là một phần mở rộng của một giao thức mở, nhưng nó mang lại giá trị to lớn cho đúng người dùng. Đây là một trường hợp khác khi không cần đổi mới kỹ thuật để tạo ra thứ gì đó có giá trị lớn.
Không phải ngẫu nhiên mà Slack được sinh ra từ một công ty game. Điều này có liên quan ngoài kiến trúc kỹ thuật. Slack không giống như công việc. Đó là một trong những lý do mọi người yêu thích nó. MetaLab đã thiết kế phần lớn giao diện người dùng ban đầu của Slack. Từ người sáng lập MetaLab, Andrew Wilkinson :
Để gây được sự chú ý trong một thị trường đông đúc, chúng tôi phải tìm cách thu hút sự chú ý của mọi người. Hầu hết phần mềm doanh nghiệp trông giống như một bộ đồ dạ hội rẻ tiền của thập niên 70 — màu xanh lam và xám nhạt ở khắp mọi nơi — vì vậy, bắt đầu với logo, chúng tôi đã làm cho Slack trông giống như một khẩu pháo hoa giấy đã nổ. Màu xanh điện, màu vàng, màu tím và màu xanh lá cây ở khắp mọi nơi. Chúng tôi đã cung cấp cho nó bảng màu của trò chơi điện tử, không phải sản phẩm hợp tác doanh nghiệp.
Cũng được xuất bản ở đây .