Giới thiệu về 20% thời gian trên mạng tại nơi làm việc [đóng cửa]

20% thời gian là văn hóa của một chủ nhân cho phép nhân viên của họ dành 20% thời gian để làm việc cho các dự án mà họ thấy thú vị - đó có thể là phát minh ra một ứng dụng mới hoặc cải thiện quy trình hiện có, v.v. Một số người có thể biết đây là chồn hôi công việc, tuy nhiên thuật ngữ đó có thể không có nghĩa gì (hoặc một cái gì đó hoàn toàn khác) với bạn.

Có rất nhiều trường hợp được ghi nhận về các sản phẩm tuyệt vời được sinh ra từ 20% / skunk làm việc tại một công ty. Có vẻ như một tình huống thắng / thắng; công ty có khả năng đạt được một sản phẩm hoặc ứng dụng mới tuyệt vời và nhà phát triển có cơ hội uốn cong cơ bắp sáng tạo của mình và đổi mới.

Tôi đã cố gắng nhiều lần để giới thiệu một số hình thức 20% / Skunk làm việc tại nhà tuyển dụng trước đây của tôi nhưng không thành công.

Làm thế nào tôi có thể biện minh tốt hơn cho quản lý? Cách "đúng" để tiếp cận kiểu sắp xếp công việc này là gì?

Lý do chính cho 20% thời gian là để giữ mức sử dụng công suất ở mức 80% thay vì 100%.

Bạn có thể nghĩ về một tổ chức phát triển phần mềm như một hệ thống biến các yêu cầu tính năng thành các tính năng được phát triển. Bạn có thể mô hình hóa hành vi của nó bằng cách sử dụng lý thuyết xếp hàng .

HỌC THUYẾT

Nếu các yêu cầu đến nhanh hơn hệ thống có thể phục vụ chúng, chúng sẽ xếp hàng. Khi khách đến chậm hơn, kích thước hàng đợi giảm. Bởi vì các quy trình đến và dịch vụ là ngẫu nhiên, kích thước hàng đợi thay đổi ngẫu nhiên theo thời gian.

Về mặt toán học có thể hỏi về "tính ngẫu nhiên" này: phải có một số phân phối xác suất, vậy kích thước hàng đợi sẽ trung bình là bao nhiêu? Toán học (lý thuyết xếp hàng) có câu trả lời cho điều đó: nếu cả hai quá trình đến và dịch vụ đều là Markov, thì N = rho ^ 2 / (1-rho).

(Trong đó rho là hệ số sử dụng bằng tỷ lệ của dịch vụ và tỷ lệ đến. Nếu các quy trình không phải là Markov, toán học phức tạp hơn, nhưng không thay đổi kết luận.)

Nếu bạn vẽ đồ thị của hàm này, bạn có thể thấy rằng độ dài hàng đợi trung bình vẫn thấp trong khi mức sử dụng lên tới 0,8 , sau đó tăng mạnh và chuyển sang vô cùng. Bạn có thể hiểu điều này bằng trực giác bằng cách nghĩ về CPU máy tính của bạn: khi mức sử dụng của nó đạt 100%, máy tính sẽ không phản hồi.

THỰC HÀNH

Tính kinh tế của phát triển phần mềm là do các công ty phần mềm phải chịu chi phí lớn khi hàng đợi của họ ở trạng thái xếp hàng cao. Điều này bao gồm các cơ hội thị trường bị bỏ lỡ, các sản phẩm lỗi thời, các dự án muộn và lãng phí gây ra bởi các tính năng xây dựng theo dự đoán nhu cầu.

Do đó, 20% thời gian là câu trả lời khoa học cho vấn đề tối ưu hóa kết quả kinh tế: tránh các trạng thái xếp hàng cao bằng cách tránh các tỷ lệ sử dụng gây ra chúng. Nó thực chất là sự chậm chạp giữ cho hệ thống đáp ứng.

Một số kết luận thực tế ngay sau đây:

• nếu bạn đang xem xét 20% thời gian và thực hiện kế toán chi phí (chi phí thời gian của nhà phát triển X, nhưng / và công ty có thể / không thể chi trả được), thì bạn đã làm sai.
• nếu bạn phân bổ 20% vào thứ Sáu hàng tuần, bạn đã làm sai
• nếu bạn đang thiết lập hệ thống đệ trình / đánh giá / phê duyệt đề xuất dự án 20% thời gian, bạn đã làm sai
• nếu bạn điền vào bảng chấm công, bạn đang làm sai
• nếu bạn đang sử dụng đổi mới làm động lực trong 20% ​​thời gian, bạn đã làm sai. Mặc dù các sản phẩm mới đã ra khỏi 20% dự án, nhưng chúng không phải là vấn đề. Nếu công ty của bạn không thể đổi mới trong giờ chính, đó là một vấn đề!
• 20% thời gian không phải là về sự sáng tạo. Đừng nói rằng bạn sẽ giải phóng khả năng sáng tạo của mình với 20% thời gian, hãy hỏi tại sao bạn chưa đủ sáng tạo trong giờ chính.

TRẢ LỜI CÁC CÂU HỎI TRONG NHẬN XÉT

Dan , bạn đã hiểu đúng và mô tả chính xác sai lầm của nhiều người. Bạn không thể chọn tỷ lệ sử dụng của mình, vì đó là biến đầu ra. Đó là một tỷ lệ đặc tính của hai quá trình, vì vậy nó là như vậy bởi vì các quy trình là như vậy. Một tổ chức có ảnh hưởng đến cả hai quá trình; khả năng phù hợp và nhu cầu là một trong những vấn đề khó giải quyết của cơ quan phát triển phần mềm nạc. Sử dụng là một trong những chỉ số giải quyết vấn đề này tốt như thế nào trong một tổ chức. Slack nổi lên khi sáng kiến ​​tinh gọn của bạn tiến triển và bạn loại bỏ chất thải khỏi luồng giá trị. Nhưng nếu bạn bắt buộc 20% thời gian, bạn sẽ rơi vào cái bẫy sử dụng tương tự với dung lượng khả dụng ít hơn.

Kim , nó vẫn là một phần của văn hóa. Tài liệu tham khảo văn hóa gần nhất mà tôi có thể nghĩ đến là mức độ hiệp đồng của mô hình được gọi là Marshall về thay đổi tổ chức. Nó xuất hiện vào cuối các biến đổi nạc thành công hoặc có mặt trong các tổ chức được xây dựng nạc từ đầu. ( Đây là một liên kết đến sách trắng của Bob Marshall (PDF) .)

TÀI LIỆU THAM KHẢO

Logic trên được hỗ trợ tốt trong tài liệu kỹ thuật phần mềm. Mary và Tom Poppendieck đã gợi ý về nó trong cuốn sách năm 2006 của họ Thực hiện phát triển phần mềm tinh gọn . Donald Reinertsen trong cuốn sách năm 2009 Nguyên tắc về dòng chảy phát triển sản phẩm (Chương 3) đưa ra cách xử lý tốt cho chủ đề này, với các công thức và đồ thị.

Mười bốn tháng sau khi tôi viết câu trả lời này, tôi đã nghĩ ra một câu trả lời hay hơn nhiều .

Tôi đã không làm việc ở một nơi mà những tác phẩm như vậy được chính thức công nhận. Nhưng từ những cuộc trò chuyện và nỗ lực tìm hiểu về thực tiễn này, tôi đã tìm thấy điều này - tốt, chủ yếu là "20% thời gian" không phải là:

• Đó thực sự là một văn hóa và không phải là một chính sách
• quản lý cấp cao không thể quyết định
• nó không thể được thành lập bởi một ủy ban của các nhà phát triển
• nó không phải là 32 giờ về điều này và 8 giờ về điều đó

" Skunkworks " không giống với 20% thời gian. 20% thời gian là như bạn đã nói - thời gian nhà phát triển tự chọn những gì để làm việc. Skunkworks là hoàn toàn khác nhau. Dự án skunkworks là một dự án có giá trị cao, chi phí cao được thực hiện bởi một nhóm (thường là một nhóm chuyên gia về kinh nghiệm) không được báo cáo cho quản lý cấp trên và nhóm tự quyết định cách dự án nên tiến hành mà không có hướng quản lý . Các dự án này thường được thúc đẩy bởi một nhu cầu chiến thuật hoặc kinh doanh để hoàn thành công việc, nhưng không có chỗ trong ngân sách cho nó. Nếu một cái gì đó phải được thực hiện , nó được thực hiện - ngân sách bị nguyền rủa.

Tôi đã quản lý một nhóm phát triển nơi tôi thực hiện 20% thời gian. Hoặc cố gắng, dù sao đi nữa. Tôi đã được sự chấp thuận của cấp trên, vì vậy đó không phải là vấn đề. Vấn đề là nhóm quá nhỏ và quá chuyên biệt. Bất cứ khi nào có vấn đề cần can thiệp ngay lập tức, 20% thời gian đã bị xáo trộn. Điều này đã kết thúc xảy ra rất thường xuyên.

Tôi cũng thấy rằng một số nhà phát triển của tôi thấy sự thiếu định hướng của tôi không ổn định. Mặc dù tôi đã nói "làm việc trên bất cứ điều gì bạn muốn, miễn là nó liên quan đến lập trình", họ vẫn khó chấp nhận phần "bất cứ điều gì". Họ nghĩ rằng một số dự án sẽ tốt hơn những dự án khác, vì vậy họ chắc chắn đã làm việc với các yêu cầu triển khai cấp thấp trong sản phẩm chính, những thứ như vậy. Tôi muốn chúng phân nhánh và phát triển, nhưng thay vào đó chúng đào sâu vào chuyên môn chính của chúng.

Tôi sẽ làm điều đó một lần nữa, nhưng tôi rõ ràng sẽ cấm làm việc trên sản phẩm chính và tôi có thể bắt đầu chúng với một số ý tưởng để lựa chọn để bắt đầu.

Tôi đang làm việc cho một start-up đã thực hiện chính sách 20%. Đây là người chủ đầu tiên của tôi làm điều này và khi anh ấy đưa nó vào buổi phỏng vấn xin việc, tôi thực sự ngạc nhiên, vì hầu hết các nhà tuyển dụng khác đang cố gắng không "lãng phí" một giờ.

Tôi đã tham gia khởi nghiệp khi nó được thành lập và trong gần một năm tôi là nhà phát triển duy nhất. Tôi đã dành 20% của mình với một vài điều cơ bản:

• Báo cáo / sửa lỗi trong các dự án nguồn mở ngẫu nhiên - điều này có thể nhỏ như việc tạo ra một dự án thú vị trên Github và sửa một vài lỗi chính tả trong tài liệu.
• Viết "công cụ" nguồn mở - những thứ như thử thách lập trình, chỉ để giải trí.
• Đi đến hội nghị và chạy nước rút - cứ vài phút tôi lại đi nước rút, nơi tôi có thể làm việc trong các dự án (một số có thể được sử dụng bởi ứng dụng chính, một số khác thì không) và có được một số kinh nghiệm. Có một vài thư viện được sử dụng bởi ứng dụng của chúng tôi và bởi các ứng dụng được phát triển bởi các công ty khác gửi nhà phát triển đến hội nghị, vì vậy nó có thể được coi là lợi ích trực tiếp cho công ty của chúng tôi.
• Học các công nghệ mới - đây là cách tôi học Go , mặc dù chúng tôi không sử dụng nó trong công ty. Điều này đặc biệt được khuyến khích bởi chủ nhân của tôi. Gần đây tôi đã theo dõi một số lớp học trực tuyến miễn phí của Stanford.

Thời gian không được đo chính xác, chắc chắn không phải là 32 + 8 giờ, đôi khi có những việc khẩn cấp phải làm khi không có đủ thời gian để cắt giảm 20% đó, những lần khác tôi có nhiều thời gian rảnh rỗi hơn.

Tôi đang làm việc từ xa và chúng tôi sử dụng trò chuyện Campfire của 37s để liên lạc và theo dõi sự hiện diện của nhau một cách lỏng lẻo và những giờ này được theo dõi là giờ "làm việc", tôi đã đăng nhập vào trò chuyện và có sẵn cho đồng nghiệp, mặc dù thực hiện rõ ràng là tôi không làm việc với dự án của chúng tôi ngay bây giờ.

Từ kinh nghiệm nhỏ bé của tôi, rất nhiều dự án của chúng tôi thực sự bắt đầu theo cách này. Chúng tôi có thời gian rảnh và băng thông để thực hiện các dự án mới, chúng tôi đã cùng nhau và đưa ra những ý tưởng tư duy tuyệt vời / chuyển tiếp tiềm năng cho bộ phận của chúng tôi. Trong thời gian rảnh rỗi, chúng tôi đã phát triển một nguyên mẫu và một khi nó được đánh bóng khá tốt, được trình bày cho cấp trên và thường thì họ thấy lợi ích.

Dường như với tôi, cấp trên biết họ muốn gì nếu họ thấy nhưng không biết họ cần / muốn gì cho đến khi họ nhìn thấy. Prototyping đã cho phép chúng tôi tạo ra các dự án của riêng mình, đề xuất chúng và sau đó một khi được phê duyệt sẽ chuyển hướng thêm thời gian để chúng hoàn thành.