В Tôi đã xem xét một số lý do để tham gia hackathons. Động lực học hỏi nhiều điều mới và giành được những giải thưởng có giá trị thu hút nhiều người, nhưng thường do sai sót của ban tổ chức hoặc công ty tài trợ nên sự kiện kết thúc không thành công và người tham gia ra về không hài lòng. Để những sự cố khó chịu như vậy xảy ra ít thường xuyên hơn, tôi đã viết bài này. Phần thứ hai của bộ ba dành riêng cho những sai lầm của ban tổ chức.
Bài đăng được tổ chức như sau: lúc đầu tôi nói về sự kiện, giải thích những gì đã xảy ra và nó dẫn đến điều gì (hoặc có thể dẫn đến về lâu dài). Sau đó, tôi đưa ra đánh giá của mình về những gì đang diễn ra và tôi sẽ làm gì nếu tôi là người tổ chức. Vì tôi đã tham gia tất cả các sự kiện nên tôi chỉ có thể thừa nhận động cơ thực sự của ban tổ chức. Kết quả là, đánh giá của tôi có thể là một chiều. Tôi không loại trừ rằng một số điểm mà tôi thấy có vẻ sai lầm thực ra lại có chủ ý như vậy.
Ở một thời điểm nào đó, người đọc có thể nghĩ rằng tác giả đã quyết định vung nắm đấm sau một trận đánh nhau. Nhưng tôi có thể đảm bảo với bạn rằng đây không phải là trường hợp. Trong một số hackathon được liệt kê, tôi đã giành được giải thưởng, tuy nhiên, điều đó không ngăn cản chúng tôi nói rằng sự kiện này được tổ chức kém.
Để tôn trọng ban tổ chức và người tham gia, bài viết sẽ không đề cập đến các công ty cụ thể. Tuy nhiên, một người đọc chú ý có thể đoán (hoặc Google) chúng ta đang nói về ai.
Hackathon số 1. Khuôn khổ nghiêm ngặt
Sáu tháng trước, một công ty viễn thông lớn đã tổ chức cuộc thi hackathon về phân tích dữ liệu. 20 đội tranh tài để giành quỹ giải thưởng. Tại sự kiện này, một tập dữ liệu đã được cung cấp để phân tích, trong đó chứa thông tin về các cuộc gọi đến dịch vụ hỗ trợ của công ty, hoạt động trên mạng xã hội và thông tin được mã hóa về người dùng (giới tính, độ tuổi, v.v.). Phần thú vị nhất của tập dữ liệu—tin nhắn của người dùng và phản hồi của nhà điều hành (dữ liệu văn bản)—khá ồn ào và cần được làm sạch để tiếp tục công việc.
Ban tổ chức đặt ra nhiệm vụ - làm điều gì đó thú vị với dữ liệu được cung cấp và cấm sử dụng các bộ dữ liệu mở bổ sung từ mạng hoặc tự phân tích dữ liệu. Nó cũng bị cấm đề xuất những ý tưởng không liên quan đến tập dữ liệu. Thật không may, dữ liệu được cung cấp khá “kém”: rất khó để có được bất kỳ sản phẩm thú vị nào từ họ và qua trao đổi với những người cố vấn, người ta thấy rõ rằng nhiều ý tưởng được đề xuất đã được thực hiện (hoặc sẽ được thực hiện trong tương lai gần) trong công ty.
Kết quả là số lượng đội áp đảo (15 trên 20) đã tạo ra chatbot. Trong các buổi biểu diễn, quyết định của một đội có chút khác biệt so với quyết định trước đó. Không chịu nổi, một thành viên ban giám khảo hỏi đội tiếp theo lên sân khấu: “Sao vậy các bạn, các bạn cũng có chatbot à?” Kết quả, trong XNUMX giải, giải nhất và giải nhì thuộc về đội không làm chatbot.
Để so sánh, hãy lấy một cuộc thi hackathon do một công ty tư vấn quốc tế tổ chức cho công ty Zvezdochka hai năm trước. Do nhiều người tham gia hackathon không quen thuộc với các chi tiết cụ thể về hoạt động của công ty Zvezdochka nên khi bắt đầu sự kiện, ban tổ chức đã nói về các số liệu được sử dụng trong công ty. Sau đó, sáu bộ dữ liệu thuộc các loại khác nhau đã được cung cấp: văn bản, bảng, vị trí địa lý - có chỗ để điều động cho tất cả những người tham gia. Ban tổ chức không cấm sử dụng các bộ dữ liệu bổ sung và thậm chí còn ủng hộ những sáng kiến như vậy. Trong vòng chung kết của cuộc thi, XNUMX đội với các giải pháp khác nhau đã tranh tài để giành giải chính, tất cả các đội đều sử dụng dữ liệu do công ty cung cấp (mặc dù không có hạn chế), điều này cho thấy tiềm năng tốt để có được sản phẩm chất lượng.
Đạo đức
Không cần phải giới hạn luồng sáng tạo của người tham gia. Với tư cách là người tổ chức, bạn phải cung cấp tài liệu và tin tưởng vào tầm nhìn cũng như tính chuyên nghiệp của họ. Nếu bạn là người tham gia hackathon, bất kỳ hạn chế hoặc lệnh cấm nào cũng sẽ khiến bạn cảnh giác. Thông thường đây là bằng chứng của việc tổ chức kém (một ví dụ từ cuộc sống thực là bạn thường xuyên muốn dựng hàng rào ở đâu đó). Nếu bạn gặp phải những hạn chế, thì hãy chuẩn bị cho thực tế là bạn sẽ phải tạo một dự án trong một nhóm có rất nhiều sự cạnh tranh. Trong trường hợp này, bạn buộc phải chấp nhận rủi ro: làm điều gì đó mới về cơ bản hoặc đưa ra một “tính năng sát thủ” khác thường để nổi bật giữa dòng dự án đơn điệu.
Hackathon số 2. Nhiệm vụ bất khả thi
Cuộc thi hackathon ở Amador hứa hẹn sẽ rất thú vị. Công ty tài trợ, một nhà sản xuất điện thoại lớn, đã bắt đầu chuẩn bị 4 tháng trước ngày diễn ra sự kiện. Việc PR cho sự kiện được thực hiện trên mạng xã hội, những người tham gia tiềm năng phải vượt qua bài kiểm tra kỹ thuật và viết về các dự án trước đây của họ để được chọn tham gia sự kiện này. Quỹ giải thưởng rất lớn. Vài ngày trước hackathon, các cố vấn đã tổ chức một buổi kỹ thuật để những người tham gia có thời gian hiểu các chi tiết cụ thể của ngành.
Tại sự kiện này, ban tổ chức đã cung cấp một tập dữ liệu nhật ký thiết bị có dung lượng 8 GB, nhiệm vụ là phân loại nhị phân các sự cố. Họ nói về các tiêu chí đánh giá dự án - chất lượng phân loại, tính sáng tạo trong việc tạo ra tính năng, khả năng làm việc nhóm, v.v. Thật là xui xẻo - đối với 8 GB “tính năng”, chỉ có 20 ví dụ trên tàu và 5 mẫu trong thử nghiệm. Chiếc đinh cuối cùng trong quan tài của hackathon đến từ dữ liệu: nhật ký thiết bị nhận được vào thứ Tư có lỗi trong hoạt động của thiết bị, nhưng những nhật ký được tạo vào thứ Năm thì không (nhân tiện, chỉ có hai đội biết về điều này và cả hai đều đến từ Nga, quê hương của những người khai thác dữ liệu giàu kinh nghiệm). Mặc dù ngay cả kiến thức về nhãn thực sự của bài kiểm tra cũng không giúp xác định câu trả lời - nhiệm vụ này là không thể giải quyết được. Ban tổ chức không đạt được kết quả như mong muốn, những người tham gia mất nhiều thời gian để giải một bài toán được thiết kế kém. Hackathon đã thất bại.
Đạo đức
Tiến hành đánh giá kỹ thuật của các bài tập và kiểm tra tính đầy đủ của bài tập của bạn. Thà trả quá nhiều tiền cho một cuộc kiểm tra sơ bộ (trong trường hợp này, bất kỳ nhà khoa học dữ liệu nào cũng sẽ chỉ ra ngay rằng không thể giải quyết được vấn đề này) còn hơn là hối hận về sau.
Trong trường hợp này, ngoài việc lãng phí thời gian và tiền bạc, công ty còn đánh mất uy tín với các ứng viên tiềm năng và có thể viết về kết quả. Nhân tiện, không chỉ những người tham gia mà cả công ty cũng nên viết về những kết quả thành công, tối đa hóa hackathon từ quan điểm PR. Thật không may, không phải tất cả các công ty đều làm điều này, chỉ giới hạn ở một bài đăng thông báo và một vài bức ảnh về sự kiện trên Twitter.
Hackathon số 3. Hoặc là lấy đi hoặc là bỏ lại
Gần đây nhất, nhóm của chúng tôi đã tham gia hackathon ở Amsterdam. Vì tôi là một kỹ sư điện được đào tạo (trong lĩnh vực nguồn năng lượng tái tạo) nên chủ đề này rất phù hợp với chúng tôi - năng lượng. Cuộc thi hackathon được tổ chức trực tuyến: chúng tôi được cung cấp bản mô tả nhiệm vụ và thời gian hoàn thành nó trong một tháng. Ban tổ chức muốn thấy một dự án hoàn thiện có thể giúp nâng cao hiệu quả sử dụng năng lượng của các ngôi nhà ở Amsterdam.
Chúng tôi đã thực hiện một dự án trong đó mức tiêu thụ điện được dự đoán (trước đó, tôi đã tham gia một cuộc thi về chủ đề này, nơi tôi nhận được giải pháp gần như sota, bạn có thể đọc về giải pháp này ) và sản xuất bằng tấm năng lượng mặt trời. Dựa trên những dự đoán này, hiệu suất của pin được tối ưu hóa (ý tưởng này một phần được lấy từ luận văn thạc sĩ của tôi). Dự án của chúng tôi đã phù hợp tốt cả với hướng dẫn của ban tổ chức (có vẻ như đối với chúng tôi lúc đó) và với chính sách của chính quyền Amsterdam trong lĩnh vực nguồn năng lượng tái tạo trong vài năm tới.
Trong quá trình đánh giá các dự án, chúng tôi cũng như nhiều đội, được thông báo rằng đây không phải là điều mà khách hàng mong đợi, đồng thời nói thêm rằng chúng tôi phải làm lại dự án nếu muốn cạnh tranh giải thưởng. Chúng tôi không làm lại bất cứ điều gì, chấp nhận thất bại. Trong số 7 đội tham dự, chúng tôi thậm chí còn không lọt vào top XNUMX, mặc dù đối với tôi, sự lựa chọn của ban tổ chức khá kỳ lạ. Ví dụ: họ đã đưa nhóm vào vòng chung kết tạo ra ứng dụng tính toán tốc độ gió và bức xạ mặt trời (SI) bằng cách sử dụng dữ liệu từ cảm biến của điện thoại thông minh: micrô cho gió, cảm biến ánh sáng cho SI. Tính năng hấp dẫn là việc phân loại hotdog/không phải hotdog thành ba loại: Mặt trời, gió, nước và hiển thị bài viết tương ứng trên Wikipedia ().
Chúng ta hãy tạm dừng khía cạnh đạo đức của vấn đề: tống tiền những người tham gia với khả năng chiến thắng đơn giản là phi đạo đức. Vì một trong những động lực tham gia hackathons (đặc biệt là các nhà phát triển có kinh nghiệm) là để hiện thực hóa ý tưởng của họ, nhiều người tham gia mạnh mẽ có thể đơn giản rời khỏi sự kiện sau khi nghe những phản hồi như vậy (điều này không chỉ xảy ra với nhóm của chúng tôi mà còn với một số người khác đã dừng lại). cập nhật dự án trang của họ sau khi nghe người cố vấn). Tuy nhiên, giả sử chúng tôi đã đồng ý với mong muốn của ban tổ chức và làm lại dự án của mình cho phù hợp với yêu cầu của họ. Điều gì có thể xảy ra tiếp theo?
Vì ban tổ chức có hiểu biết riêng về “dự án lý tưởng” nên mọi mong muốn (và theo đó là những thay đổi) sẽ dẫn chúng ta đến lý tưởng này. Các đối thủ sẽ lãng phí thời gian và họ sẽ ngày càng khó từ chối tham gia thêm (vì họ đã đầu tư công sức và có vẻ như chỉ còn cách chiến thắng một chút). Nhưng trên thực tế, sự cạnh tranh để giành giải thưởng sẽ ngày càng gia tăng và người tham gia sẽ ngày càng phải làm lại dự án dựa trên những chỉnh sửa từ ban tổ chức với hy vọng giành được giải thưởng. Kết quả là, những người không nhận giải thưởng, nhìn lại sẽ hiểu rằng họ đã tham gia làm việc tự do mà không cần tiền: họ chỉnh sửa cho khách hàng, nhưng không nhận được bất cứ điều gì đổi lại (ngoại trừ kinh nghiệm liên quan, về khóa học).
Đạo đức
Thông thường những mong muốn và phản hồi từ ban tổ chức sẽ hỗ trợ dự án. Tuy nhiên, đồng thời, người tham gia không nên dựa vào lời khuyên của người hướng dẫn như người què chống gậy. Nếu bạn nghe được phản hồi từ ban tổ chức về dự án của mình với tinh thần “mang đi, chúng tôi không đặt hàng cái này”, việc bạn tham gia hackathon có thể coi là đã hoàn thành.
Nếu bạn đang tổ chức một cuộc thi hackathon với tầm nhìn rõ ràng về dự án nhưng không có kỹ năng hoặc khả năng tự thực hiện nó, thì tốt hơn là bạn nên chính thức hóa tầm nhìn của mình dưới dạng thông số kỹ thuật cho một freelancer. Nếu không, bạn sẽ phải trả tiền hai lần – cho hackathon và cho các dịch vụ của freelancer.
Nguồn: www.habr.com