В من چندین دلیل برای شرکت در هکاتون ها را بررسی کرده ام. انگیزه یادگیری بسیاری از چیزهای جدید و کسب جوایز ارزشمند بسیاری را به خود جذب می کند، اما اغلب به دلیل اشتباهات برگزار کنندگان یا شرکت های حامی، رویداد ناموفق به پایان می رسد و شرکت کنندگان ناراضی آنجا را ترک می کنند. برای اینکه چنین حوادث ناخوشایندی کمتر اتفاق بیفتد، این پست را نوشتم. قسمت دوم این سه گانه به اشتباهات برگزارکنندگان اختصاص دارد.
پست به صورت زیر سازماندهی شده است: در ابتدا در مورد رویداد صحبت می کنم، توضیح دهید که چه چیزی اشتباه بوده و به چه چیزی منجر شده است (یا می تواند در دراز مدت منجر به آن شود). سپس ارزیابی خود را از اتفاقاتی که در حال رخ دادن است، و اگر من جای برگزارکننده بودم، انجام می‌دادم. از آنجایی که من در همه رویدادها شرکت کردم، فقط می توانم انگیزه واقعی برگزارکنندگان را فرض کنم. در نتیجه ارزیابی من ممکن است یک طرفه باشد. من بعید نمی دانم که برخی از نکاتی که به نظر من نادرست به نظر می رسند، در واقع چنین منظوری بوده است.
در نقطه ای خاص، خواننده ممکن است فکر کند که نویسنده پس از دعوا تصمیم گرفته است مشت های خود را تکان دهد. اما می توانم به شما اطمینان دهم که اینطور نیست. در برخی از هکاتون های ذکر شده، من موفق به دریافت جایزه شدم، اما این مانع از این نمی شود که بگوییم این رویداد ضعیف برگزار شده است.
به احترام برگزارکنندگان و شرکت کنندگان، هیچ اشاره ای به شرکت های خاصی در پست نخواهد بود. با این حال، یک خواننده با دقت می تواند حدس بزند (یا گوگل) در مورد چه کسی صحبت می کنیم.
هکاتون شماره 1. چارچوب های دقیق
شش ماه پیش، یک شرکت بزرگ مخابراتی هکاتونی را در مورد تجزیه و تحلیل داده ها ترتیب داد. 20 تیم برای دریافت جوایز به رقابت پرداختند. در این رویداد، مجموعه داده ای برای تجزیه و تحلیل ارائه شد که حاوی اطلاعات تماس با خدمات پشتیبانی شرکت، فعالیت در شبکه های اجتماعی و اطلاعات کدگذاری شده در مورد کاربران (جنس، سن و غیره) بود. جالب‌ترین بخش مجموعه داده - پیام‌های کاربر و پاسخ‌های اپراتور (داده‌های متنی) - بسیار پر سر و صدا بود و برای کار بیشتر باید پاکسازی می‌شد.
سازمان دهندگان وظیفه ای را تعیین کردند - انجام کاری جالب با داده های ارائه شده، و استفاده از مجموعه داده های باز اضافی از شبکه یا تجزیه و تحلیل داده ها توسط خودتان ممنوع بود. همچنین پیشنهاد ایده های غیر مرتبط با مجموعه داده ممنوع بود. متأسفانه، داده های ارائه شده کاملاً "ضعیف" بود: به دست آوردن محصولات جالب از آنها دشوار بود و از ارتباط با مربیان مشخص شد که بسیاری از ایده های پیشنهادی قبلاً در حال اجرا هستند (یا در آینده نزدیک اجرا خواهند شد) در شرکت.
در نتیجه، تعداد قابل توجهی از تیم ها (15 از 20) چت بات ها را ساختند. در طول اجراها، تصمیم یک تیم با تیم قبلی تفاوت چندانی نداشت. یکی از اعضای هیئت داوران که نتوانست آن را تحمل کند، از تیم بعدی که روی صحنه می رفت پرسید: "بچه ها، شما چت بات هم دارید؟" در نتیجه از بین سه جایزه، رتبه های اول و دوم به تیم هایی تعلق گرفت که چت بات ساخته نشده بودند.
برای مقایسه، بیایید هکاتونی را که دو سال پیش توسط یک شرکت مشاوره بین‌المللی برای شرکت Zvezdochka برگزار شده بود، در نظر بگیریم. از آنجایی که ویژگی های فعالیت های شرکت Zvezdochka برای بسیاری از شرکت کنندگان هکاتون ناآشنا بود، در ابتدای رویداد برگزارکنندگان در مورد معیارهایی که در شرکت استفاده می شود صحبت کردند. پس از این، شش مجموعه داده از انواع مختلف ارائه شد: متن، جداول، موقعیت جغرافیایی - فضایی برای مانور برای همه شرکت کنندگان وجود داشت. سازمان دهندگان استفاده از مجموعه داده های اضافی را منع نکردند و حتی از چنین طرح هایی حمایت کردند. در فینال مسابقات، ده تیم با راه حل های مختلف برای کسب جایزه اصلی به رقابت پرداختند که تمامی تیم ها از داده های ارائه شده توسط شرکت (علی رغم عدم محدودیت) استفاده کردند که نشان دهنده پتانسیل خوبی برای دستیابی به محصولات با کیفیت بود.
اخلاق
نیازی به محدود کردن جریان خلاقانه شرکت کنندگان نیست. به عنوان برگزارکننده، شما باید مواد لازم را تهیه کنید و به دیدگاه و حرفه ای بودن آنها اعتماد کنید. اگر در یک هکاتون شرکت می کنید، هر گونه محدودیت یا ممنوعیت باید شما را نگران کند.معمولاً این نشان دهنده سازماندهی ضعیف است (نمونه ای از زندگی واقعی میل مداوم به چسباندن یک حصار در جایی است). اگر با محدودیت هایی مواجه شدید، برای این واقعیت آماده باشید که باید یک پروژه را در یک استخر با رقابت زیاد ایجاد کنید. در این مورد، شما موظف هستید که ریسک کنید: کاری اساساً جدید انجام دهید یا یک "ویژگی قاتل" غیرمعمول را ارائه دهید تا از جریان پروژه های یکنواخت متمایز شوید.
هکاتون شماره 2. کارهای غیر ممکن
هکاتون در آمادور وعده جالبی را داد. شرکت حامی که یک تولید کننده تلفن بزرگ است، 4 ماه قبل از تاریخ برگزاری این رویداد آماده سازی را آغاز کرد. روابط عمومی این رویداد در شبکه های اجتماعی انجام شد؛ شرکت کنندگان بالقوه برای انتخاب شدن در این رویداد باید یک تست فنی را پشت سر می گذاشتند و در مورد پروژه های گذشته خود می نوشتند. صندوق جایزه به طرز خوشایندی بزرگ بود. چند روز قبل از هکاتون، مربیان یک جلسه فنی برگزار کردند تا شرکت کنندگان وقت داشته باشند تا ویژگی های صنعت را درک کنند.
در خود این رویداد، سازمان دهندگان مجموعه داده ای از سیاهههای مربوط به تجهیزات را با حجم 8 گیگابایت ارائه کردند، وظیفه طبقه بندی باینری خرابی ها بود. آنها در مورد معیارهای ارزیابی پروژه ها - کیفیت طبقه بندی، خلاقیت در ایجاد ویژگی ها، توانایی کار در یک تیم و غیره صحبت کردند. این فقط بدشانسی است - برای 8 گیگابایت "ویژگی" فقط 20 نمونه در قطار و 5 نمونه در تست وجود داشت. آخرین میخ در تابوت هکاتون از داده ها بدست آمد: گزارش های تجهیزات دریافت شده در روز چهارشنبه حاوی خطا در عملکرد تجهیزات بودند، اما مواردی که در روز پنجشنبه ایجاد شدند این کار را نکردند (به هر حال، فقط دو تیم از این موضوع اطلاع داشتند، و هر دو از روسیه، وطن استخراج کنندگان داده با تجربه بودند). اگرچه حتی آگاهی از برچسب های واقعی آزمون به تعیین پاسخ کمک نکرد - این کار غیرقابل حل بود. برگزارکنندگان به نتیجه مطلوب نرسیدند؛ شرکت کنندگان زمان زیادی را صرف حل یک مشکل طراحی شده ضعیف کردند. هکاتون شکست خورد.
اخلاق
بررسی های فنی تکالیف را انجام دهید و تکالیف خود را از نظر کفایت بررسی کنید. بهتر است برای یک معاینه اولیه بیش از حد هزینه کنید (در این مورد، هر دانشمند داده بلافاصله اشاره می کند که حل این مشکل غیرممکن است) تا اینکه بعداً از آن پشیمان شوید.
در این مورد، شرکت علاوه بر اتلاف وقت و هزینه، اعتبار خود را نزد نامزدهای احتمالی از دست داد و احتمالاً نتایج را نوشت. به هر حال، نه تنها شرکت کنندگان، بلکه شرکت نیز باید در مورد نتایج موفقیت آمیز بنویسند و هکاتون را از نقطه نظر روابط عمومی به حداکثر برسانند. متأسفانه، همه شرکت‌ها این کار را انجام نمی‌دهند و تنها به یک پست اعلامیه و چند عکس از رویداد در توییتر محدود می‌شوند.
هکاتون شماره 3. یا بگیرش یا ولش کن
اخیراً تیم ما در یک هکاتون در آمستردام شرکت کرد. از آنجایی که من یک مهندس برق با آموزش (در زمینه منابع انرژی تجدید پذیر) هستم، موضوع فقط برای ما مناسب بود - انرژی. هکاتون به صورت آنلاین برگزار شد: شرح کار و یک ماه برای تکمیل آن به ما داده شد. برگزارکنندگان می خواستند پروژه ای تمام شده را ببینند که به افزایش بهره وری انرژی خانه های آمستردام کمک کند.
ما پروژه ای ساختیم که در آن مصرف برق پیش بینی شده بود (قبل از آن در مسابقه ای در این موضوع شرکت کردم که در آن یک راه حل تقریباً سوتا دریافت کردم که می توانید در مورد آن بخوانید. ) و تولید توسط پنل خورشیدی. بر اساس این پیش بینی ها، عملکرد باتری بهینه شده است (این ایده تا حدی از پایان نامه کارشناسی ارشد من گرفته شده است). پروژه ما هم با دستورالعمل های سازمان دهندگان (همانطور که در آن زمان به نظر ما می رسید) و هم با سیاست دولت آمستردام در زمینه منابع انرژی تجدیدپذیر برای چندین سال آینده مطابقت خوبی داشت.
در طول ارزیابی پروژه‌ها، مانند بسیاری از تیم‌ها، به ما گفته شد که این چیزی نیست که مشتری انتظار دارد، و اضافه کردند که اگر می‌خواهیم برای جایزه رقابت کنیم، باید پروژه را دوباره انجام دهیم. ما هیچ کاری را از نو انجام ندادیم و شکست را پذیرفتیم. از بین چهل تیم شرکت کننده، ما حتی به 7 تیم برتر هم راه پیدا نکردیم، اگرچه انتخاب برگزارکنندگان، به نظر من، نسبتاً عجیب بود. به عنوان مثال، آنها به تیم اجازه دادند تا به مرحله نهایی برود که برنامه ای برای محاسبه سرعت باد و تابش خورشیدی (SI) با استفاده از داده های حسگرهای گوشی های هوشمند ایجاد کرد: یک میکروفون برای باد، یک حسگر نور برای SI. ویژگی قاتل طبقه بندی هات داگ/نه هات داگ به سه دسته بود: خورشید، باد، آب و نمایش مقاله مربوطه در ویکی پدیا ().
اجازه دهید برای لحظه ای جنبه اخلاقی موضوع را رها کنیم: باج گیری از شرکت کنندگان با احتمال پیروزی صرفاً غیراخلاقی است. از آنجایی که یکی از انگیزه های شرکت در هکاتون ها (به ویژه توسعه دهندگان با تجربه) تحقق ایده های خود است، بسیاری از شرکت کنندگان قوی می توانند پس از شنیدن چنین بازخوردهایی (که نه تنها برای تیم ما، بلکه برای تعدادی دیگر که متوقف شده اند نیز اتفاق افتاده است) رویداد را ترک کنند. به روز رسانی پروژه صفحه خود پس از گوش دادن به مربی). با این حال، فرض کنید ما با خواسته های برگزارکنندگان موافقت کردیم و پروژه خود را مطابق با نیازهای آنها بازسازی کردیم. بعد چه اتفاقی می تواند بیفتد؟
از آنجایی که سازمان دهندگان درک خود را از "پروژه ایده آل" دارند، همه آرزوها (و بر این اساس، تغییرات) ما را به سمت این ایده آل سوق می دهند. رقبا وقت خود را تلف خواهند کرد و امتناع از مشارکت بیشتر برای آنها سخت تر و دشوارتر خواهد شد (زیرا آنها قبلاً تلاش خود را انجام داده اند و به نظر می رسد که فقط کمی با برنده شدن فاصله دارند). اما در واقعیت، رقابت برای جوایز افزایش می‌یابد و شرکت‌کنندگان به‌طور فزاینده‌ای مجبور می‌شوند پروژه را بر اساس ویرایش‌های سازمان‌دهندگان به امید برنده شدن یک جایزه انجام دهند. در نتیجه، بچه هایی که جایزه نگرفتند، با نگاه کردن به گذشته، متوجه خواهند شد که بدون پول در کار آزاد شرکت کردند: آنها ویرایش هایی را برای مشتری انجام دادند، اما در ازای این چیزی دریافت نکردند (به جز تجربه مربوطه، دوره).
اخلاق
اغلب آرزوها و بازخوردهای سازمان دهندگان به کمک پروژه می آیند. در عین حال، شرکت کنندگان نباید مانند یک مرد لنگ روی عصا به توصیه های مربیان اعتماد کنند. اگر بازخوردی از سازمان دهندگان در مورد پروژه خود با روحیه "آن را بردارید، ما این را سفارش ندادیم" می شنوید، شرکت شما در هکاتون را می توان تکمیل شده در نظر گرفت.
اگر در حال سازماندهی یک هکاتون با چشم اندازی واضح برای پروژه هستید، اما بدون مهارت یا توانایی اجرای آن، بهتر است دیدگاه خود را در قالب مشخصات فنی برای یک فریلنسر رسمی کنید. در غیر این صورت، باید دو بار هزینه کنید - برای هکاتون و خدمات فریلنسر.
منبع: www.habr.com