Năm ngoái, tôi đã cố gắng chuyển nhóm sản phẩm của mình từ phương pháp SCRUM cổ điển sang phương pháp Shape Up của Basecamp. Đó là một trải nghiệm đáng kinh ngạc; Tôi đã học được rất nhiều điều từ nó và nghĩ rằng tôi sẽ chia sẻ một số phát hiện của mình với bạn. Nếu bạn đã tự mình thử nghiệm nó, tôi rất muốn biết nó diễn ra như thế nào. Nếu chưa, tôi rất muốn biết lý do tại sao bạn lại tránh xa. Phần 1: Tại sao phải định hình? Nhóm của tôi đã chạy trên SCRUM mãi mãi. Trong những ngày khởi nghiệp, chúng tôi đã sống theo chu kỳ công nghệ cổ điển: làm việc nhanh, hoàn thành và không nghĩ quá nhiều về các quy trình. Sau đó, chúng tôi đã có được. Khi tôi có thêm một chút thời gian để xem xét các lựa chọn phương pháp sản phẩm của mình, tôi quyết định dùng thử Shape Up. Có một vài lý do: Cho đến lúc đó, chúng tôi đã cố gắng chạy nước rút trong 2 tuần và liên tục không hoàn thành chúng. Mỗi tuần giống như một băng chuyền vé mà chúng tôi không bao giờ hoàn thành. Nhóm cảm thấy như những con khỉ mã. Chọn vé. Phiếu công tác. Giao vé. Bởi vì chúng tôi chưa bao giờ hoàn thành sprint nên các nhiệm vụ sẽ luôn tràn sang phần tiếp theo. Cuối cùng, con đập bị vỡ. Tất cả chúng tôi đều thiếu tập trung. Mỗi lần chạy nước rút là sự lựa chọn và kết hợp nhiều thứ để xử lý trên toàn bộ cơ sở mã. Rất ít tinh thần đồng đội. Mỗi nhà phát triển sẽ làm việc trên miếng bánh nhỏ của họ, để lại rất ít cơ hội để học hỏi lẫn nhau và nói thẳng ra là ý thức cộng đồng. Hầu như không có sự hiểu biết của khách hàng. Các nhà phát triển sẽ nhận các vé được giao, hoàn thành chúng và không biết tại sao/ai/cái gì. Sau khi đọc lại , Tôi nghĩ tôi sẽ thử vì nó tuyên bố sẽ giải quyết được hầu hết các vấn đề đó. Hình thành của Basecamp Phần 2: Quảng cáo chiêu hàng nội bộ Một trong những phần khó nhất khi chuyển sang Shape Up là trình bày ý tưởng trong nội bộ. Tôi đã dành thêm thời gian để tiếp thu hầu hết các khái niệm của Shape Up để đảm bảo rằng tôi sẵn sàng cho mọi câu hỏi. Không có gì đáng ngạc nhiên khi các nhà phát triển yêu thích ý tưởng về phương pháp mới này (nhiều thời gian hơn, tập trung hơn, cộng tác nhiều hơn; tại sao họ lại không làm như vậy!). Cũng không có gì ngạc nhiên khi hệ thống phân cấp lại kín đáo hơn. Cuối cùng, tôi đã thuyết phục được họ bằng cách: Đảm bảo rằng đó chỉ là một thử nghiệm. Nếu mọi việc không suôn sẻ, chúng tôi sẽ trở lại 'bình thường'. Đảm bảo rằng tôi sẽ luôn sẵn sàng giúp đỡ họ. Các nhà phát triển sẽ tập trung và không bị gián đoạn, nhưng tôi thì không. Làm nổi bật Shape Up cho phép chúng ta giải quyết những vấn đề lớn hơn đồng nghĩa với những cơ hội lớn hơn. Nhấn mạnh vào sản phẩm gây đau hiện đang gặp phải và nó ảnh hưởng như thế nào đến mỗi đội. Tôi đã chuẩn bị một bản trình chiếu rất rõ ràng và hướng dẫn từng trưởng bộ phận xem qua nó (dịch vụ khách hàng, bán hàng và C-Suite). Phần 3: Nỗi sợ hãi và mối quan tâm Kinh nghiệm của tôi với tư cách là người sáng lập, nhà tiếp thị và giám đốc sản phẩm đã dạy tôi rằng việc viết ra những mối quan tâm trước khi bắt đầu thử nghiệm luôn là điều đáng giá. Tôi đã có một vài thứ với Shape Up: Tôi biết tôi phải 'nói không'. 'Chúng tôi đang bận.' 'Chu kỳ tiếp theo, chúng ta có thể xem xét điều đó.' Đó là lý thuyết và nó sẽ hiệu quả nếu toàn bộ công ty áp dụng phương pháp này. Trong lần thử nghiệm chu kỳ đầu tiên của tôi, tôi lo ngại trường hợp khẩn cấp sẽ xảy ra. Làm thế nào để chúng ta xử lý phiền nhiễu? Shape Up khuyến nghị không tồn đọng (chương 7). Vì chúng tôi chỉ đang thử nghiệm tính năng này nên rõ ràng là tôi đã không thực hiện cmd+a+xóa hồ sơ tồn đọng của mình, nhưng vẫn vậy. Nếu chúng tôi áp dụng phương pháp này, tôi sẽ cảm thấy hơi lạc lõng nếu không có hồ sơ tồn đọng. Tồn đọng? Điều này thực sự làm tôi sợ hãi. Điều gì xảy ra nếu chúng ta đến cuối chu kỳ 6 tuần và chúng ta tạm thời ở đó nhưng chưa hoàn toàn? Basecamp nói 'bắt đầu lại' (trừ khi bạn quá thân thiết). Tôi lo ngại rằng chúng tôi sẽ bỏ lỡ mục tiêu ở mức 20-30% khó chịu. 'Gần như đã hoàn thành.' Cuối cùng, không có nỗi sợ hãi/quan ngại nào trong số này có thể ngăn cản tôi tiếp tục phiên tòa. Tuy nhiên, điều đó đáng để ghi nhớ chúng. Phần 4: Chu kỳ Và chúng ta đi thôi! Tôi bắt đầu chu kỳ đầu tiên vào sáng thứ Hai, xem xét sáu tuần tập trung cao độ và làm việc nhóm. Dưới đây là tóm tắt những gì đã xảy ra mỗi tuần: : Khởi động và... im lặng. Để nhóm tự do, để họ nghiên cứu và tìm hiểu mã theo thời gian riêng của họ đều là một phần quan trọng của phương pháp này. Thật khó để tôi buông bỏ trong tuần đầu tiên đó và không yêu cầu cập nhật. Tôi đã giữ vững! Tuần 1 : Cuối cùng thì cả nhóm cũng đã thoát ra khỏi vỏ bọc của mình. Giao tiếp đã bắt đầu. Thiết kế cho công việc bắt đầu xuất hiện, phải đưa ra một số phản hồi và làm việc cùng nhau. Tuần 2 : Về lý thuyết, tuần 3 phải là đỉnh của đường cong chu kỳ. Cuối cùng, nhóm sẽ có ý tưởng rất hay về cách họ sẽ xây dựng những gì cần xây dựng. Chúng tôi đã tạo một kênh Slack theo chu kỳ cụ thể khi hoạt động liên lạc bắt đầu được cải thiện một cách hợp lý. Đến cuối tuần đó, chúng tôi đã thấy các nguyên mẫu, thiết kế, đoạn mã, v.v. Chúng tôi đã đi đúng hướng! Tuần 3 : Im lặng trở lại. Tất cả những việc qua lại từ tuần 3 đã tạo ra một tuần 4 tập trung khi mọi người thực hiện công việc của mình. Chúng tôi đã bắt đầu chương trình 'show & Tell' vào thứ Sáu. Tuần 4 : Tuần bóng cong. Một trong những ống ngắm bắt đầu gây ra khá nhiều tranh cãi. Nó nhanh chóng trở nên rõ ràng là phạm vi không đủ rõ ràng. Tôi đã không đưa ra đủ chính xác các yêu cầu của mình và những gì ban đầu có vẻ tốt đẹp và đơn giản hóa ra lại phức tạp. Tôi đã phải đưa ra quyết định khó khăn để cắt giảm phạm vi này. Tuần 5 : Các phạm vi còn lại đang tiến triển tốt đẹp. Cường độ tăng lên đáng kể vào tuần thứ 6 khi tôi đang kiểm tra chất lượng ở mọi nơi và các nhà phát triển đang lặp lại phản hồi của tôi cực kỳ nhanh chóng; tất cả chúng tôi đã cùng nhau cố gắng để đạt được mục tiêu. Tuần 6 Cuối cùng, chúng tôi đã đạt được mục tiêu. Chúng tôi thực hiện nó! Nó cực kỳ căng thẳng và tôi rất thất vọng khi phải cắt một trong các ống ngắm, nhưng chúng tôi đã làm được. Thứ Hai tuần sau lúc 10 giờ sáng, chúng tôi bắt tay vào sản xuất. Phần 5: Một vài bài học Không theo thứ tự cụ thể nào, dưới đây là một số bài học và khuyến nghị: . Tôi nghĩ mình đã làm rất tốt việc tạo hình hầu hết các phần đáng sợ của chu kỳ. Hóa ra tôi đã bỏ lỡ điều gì đó hiển nhiên đến mức gần như làm trật bánh toàn bộ chu trình. Tạo hình thật khó khăn . Tôi hầu như tự mình định hình nó và đôi khi với sự lãnh đạo của nhóm phát triển. Sẽ rất có giá trị đối với tôi nếu có sự tham gia của các nhà phát triển khác. Bao gồm nhóm của bạn trong quá trình định hình . Dừng mọi thứ lại. Ưu tiên của bạn là tìm ra điều đó trước khi nó làm hỏng hoàn toàn mọi thứ khác. Nếu bạn thấy mình đang thảo luận hoặc định hình giữa chu kỳ thì có điều gì đó không ổn . Cho dù đó là giữa các thành viên trong nhóm hay trong suốt chu kỳ, cường độ làm việc sẽ rất khác nhau. Với tư cách là PM, vai trò của bạn là phát hiện ra những điểm mạnh này và đặc biệt chú ý đến những cá nhân đang trải qua chúng. Cường độ không được phân bố đều . Nó làm cho việc giao tiếp dễ dàng hơn nhiều nhưng cũng vui hơn nhiều. Nhóm đạp xe nhanh chóng phát triển một ngôn ngữ chung, các meme liên quan đến công việc chúng tôi đang thực hiện, v.v. Về cơ bản, nó có cảm giác giống như một người khởi nghiệp trong nhóm. Tạo một kênh Slack riêng . Chúng tôi đã chờ đợi quá lâu để làm điều này. Hết tuần 1 chắc có đủ show hay bàn luận. Đây cũng là cơ hội để gặp gỡ, trao đổi, học hỏi, v.v. Triển khai các cuộc họp trình bày và kể từ tuần 1 . Tất cả 'công việc khác' đã chồng chất trong 6 tuần; cảm giác như quay lại SCRUM. Đây là điều tôi vẫn đang nỗ lực cải thiện. Thời gian hồi chiêu hóa ra còn khó hơn nhiều so với chính chu kỳ đó Như bạn có thể biết, tôi đã bị bán bởi phiên tòa này. Việc triển khai Shape Up và áp dụng những đặc điểm riêng của nó chắc chắn không phải là chuyện một sớm một chiều. Tôi nghi ngờ đó sẽ là một quá trình học tập lâu dài. Tôi đặc biệt đánh giá cao sự thay đổi tư duy mà thử nghiệm này đã mang lại cho chúng tôi. Chúng tôi (và những nhóm khác, tôi hy vọng) đã học được cách nhìn nhận bản chất công việc: một thử thách thú vị mà chúng tôi sẽ cùng nhau vượt qua. Nếu bạn đã thử điều này (hoặc chưa), tôi rất muốn đọc một số câu chuyện hoặc phản hồi! Nếu bạn thích bài đăng này, bạn có thể thích . Tôi viết về quản lý sản phẩm, chia sẻ những hiểu biết sâu sắc có thể hành động và chấp nhận những thử thách về sản phẩm trong đời thực để giải trí (tôi biết, phải không?). bản tin của tôi
