ハッカソンの暗い側面

В 三部作の前の部分 ハッカソンに参加する理由をいくつか考えてみました。 多くの新しいことを学び、貴重な賞品を獲得したいというモチベーションは多くの人を惹きつけますが、主催者やスポンサー企業のミスによりイベントは失敗に終わり、参加者は不満を抱いて帰ってしまうことがよくあります。 このような不愉快な事件が少なくなるように、この記事を書きました。 三部作の第 XNUMX 部は、主催者の間違いに焦点を当てています。

この投稿は次のように構成されています。最初に、その出来事について話し、何がうまくいかなかったのか、そしてそれがどのような結果をもたらしたのか (または長期的にはどのような結果につながる可能性があるのか​​) を説明します。 それから私は何が起こっているのか、そして主催者の代わりに私が何をするかを評価します。 私はすべてのイベントに参加者として参加したので、主催者の真意は推測するほかありません。 その結果、私の評価は一方的なものになる可能性があります。 私が誤っていると考えるいくつかの点が、実際には誤っているように意図されていた可能性を排除しません。

ある時点で、読者には、作者が戦いの後に拳を振ることを決意したように見えるかもしれません。 しかし、そうではないと断言できます。 リストされているハッカソンのいくつかでは、なんとか賞を獲得しましたが、それでもイベントの組織化が不十分だったと言わざるを得ません。

主催者と参加者を尊重するため、投稿内では特定の企業への言及はありません。 ただし、注意深い読者であれば、誰が議論されているかを推測 (またはグーグル) することができます。

ハッカソンその 1. 厳格なフレームワーク

半年前、大手通信会社がデータ分析ハッカソンを企画しました。 20チームが賞金をかけて争った。 イベントでは、同社のサポートサービスへの通話、ソーシャルネットワーク上の活動、ユーザーに関するエンコードされた情報（性別、年齢など）に関する情報を含むデータセットが分析用に提供された。 データセットの最も興味深い部分であるユーザーのメッセージとオペレーターの応答 (テキスト データ) は非常に「ノイズ」が多く、さらなる作業のためにそれを除去する必要がありました。

主催者は、提供されたデータを使って何か興味深いことをするというタスクを設定し、ネットワークから追加のオープン データセットを使用したり、自分でデータを解析したりすることは禁止されました。 データセットに関係のないアイデアを提供することも禁止されました。 残念ながら、提供されたデータはかなり「貧弱」でした。彼らから興味深い製品を入手するのは困難でした。また、メンターとのコミュニケーションから、提案されたアイデアの多くがすでに実装されている（または近い将来実装される）ことが明らかになりました。会社で。

その結果、大多数のチーム (15 チーム中 20 チーム) がチャットボットを作成しました。 パフォーマンス中に、あるチームの決定は前のチームとほとんど変わりませんでした。 耐えかねた審査員の一人が、次にステージに入ってきたチームに「えっ、皆さん、チャットボットもお持ちですか？」と尋ねました。 その結果、XNUMX つの賞のうち、XNUMX 位と XNUMX 位はチャットボットの作成を開始していないチームに選ばれました。

比較のために、国際的なコンサルティング会社が XNUMX 年前にズベズドチカのために企画したハッカソンを見てみましょう。 Zvezdochka の活動の詳細は多くのハッカソン参加者には馴染みがなかったため、イベントの冒頭で主催者が社内で使用されている指標について話しました。 その後、さまざまな方向の XNUMX つのデータセット (テキスト、テーブル、地理位置情報) が提供され、すべての参加者にとって操作の余地がありました。 主催者は追加のデータセットの使用を禁止しておらず、そのような取り組みを支持さえしました。 コンテストの決勝戦では、さまざまなソリューションを使用した XNUMX チームが主要賞をめぐって競い合い、すべてのチームが (禁止事項がないにもかかわらず) 会社から提供されたデータを使用していました。これは、高品質の製品を入手できる可能性が高いことを示していました。

道徳的

参加者の創造的な流れを制限しないでください。 主催者として、資料を提供し、主催者のビジョンとプロフェッショナリズムを信頼する必要があります。 ハッカソンの参加者であれば、制限や禁止事項があると警告するはずですが、通常、これは組織化が不十分である証拠です (実際の例としては、どこかにフェンスを張り付けたいという欲求が常にあります)。 それでも制限に遭遇する場合は、競合が多いプールでプロジェクトを作成する必要があるという事実を覚悟してください。 この場合、リスクを取る必要があります。単調なプロジェクトの流れから目立つために、根本的に新しいことを行うか、珍しい「キラー機能」を提供する必要があります。

ハッカソン #2。 不可能なタスク

Amadora でのハッカソンは興味深いものとなるでしょう。 主催会社の大手携帯電話メーカーは開催日の４カ月前から準備を始めた。 イベントの PR はソーシャル ネットワークで行われ、参加候補者はこのイベントに選ばれるために技術テストに合格し、過去のプロジェクトについて書く必要がありました。 賞金は嬉しいことに多額でした。 ハッカソンの数日前にはメンターによる技術セッションが開催され、参加者が業界の特殊性を感じる時間を設けられました。

イベント自体では、主催者は機器ログの 8 GB データセットを提供しました。そのタスクは故障のバイナリ分類でした。 彼らは、プロジェクトの評価基準、つまり分類の質、機能作成の創造性、チームで作業する能力などについて話し合いました。 これは単なる不運です。8 GB の「機能」に対して、トレインには 20 個のサンプルしかなく、テストには 5 個のサンプルしかありませんでした。 ハッカソンの棺に最後の釘を打ったのはデータ漏洩だった。水曜日に受け取った機器のログには機器の動作に関するエラーが含まれていたが、木曜日に作成されたものにはエラーが含まれていなかった（ちなみに、知っていたのはXNUMXチームだけだった）これについては、XNUMX 人とも経験豊富なデータマイナーの故郷であるロシア出身でした)。 テストの本当のラベルを知っていても、答えを調整するのには役に立ちませんでした。このタスクは解決できませんでした。 主催者は期待した結果を得ることができず、参加者は不十分に定式化された問題を解決するのに多くの時間を費やしました。 ハッカソンは失敗しました。

道徳的

課題の技術的なレビューを実施し、課題が適切であるかどうかを確認します。 後で後悔するよりは、事前検査に過剰な費用を支払った方が良いです (この場合、データ サイエンティストはすぐにこの問題を解決するのは不可能だと指摘するでしょう)。

この場合、時間とお金の無駄に加えて、企業は潜在的な候補者からの信頼を失い、結果について書かなくなる可能性があります。 ちなみに、成功した成果については参加者だけでなく企業側も書いて、PRの意味でもできる限りハッカソンを実施してください。 残念ながら、すべての企業がこれを行うわけではなく、Twitter での発表後の発表とイベントの数枚の写真に限定されています。

ハッカソン #3。 それを取るか、それを残す

最近、私たちのチームはアムステルダムでのハッカソンに参加しました。 私は教育を受けた電力技術者 (再生可能エネルギー源の分野) なので、テーマはまさに私たちにとってのエネルギーでした。 ハッカソンはオンラインで開催されました。タスクの説明と完了までに XNUMX か月かかることが与えられました。 主催者は、アムステルダムの住宅のエネルギー効率の向上に役立つプロジェクトの完成を見たいと考えていました。

私たちは電力消費量を予測するプロジェクトを作成しました (その前に、このテーマに関するコンテストに参加し、そこでほぼ sota ソリューションを受け取りました。これについては読むことができます) ここで）とソーラーパネルによる発電。 これらの予測に基づいて、バッテリーの性能が最適化されます（このアイデアの一部は私の修士論文から引用しています）。 私たちのプロジェクトは、主催者からの任務（当時私たちにはそう見えました）と、そして今後数年間の再生可能エネルギー分野におけるアムステルダム政府の政策の両方によく一致していました。

プロジェクトの評価中に、多くのチームと同様に、私たちも、これは顧客が期待していたものではないと言われ、同時に、賞を争うためにはプロジェクトをやり直す必要があるとも付け加えられました。 私たちは何も変えず、敗北を受け入れました。 参加した7チームのうち、私たちはトップXNUMXにも残れませんでしたが、主催者の選択はかなり奇妙だったと私には思えます。 たとえば、スマートフォンのセンサー（風にはマイク、SIには光センサー）を使用して風速と日射量（SI）を計算するアプリケーションを作成した最終チームを逃しました。 キラー機能は、ホットドッグ/非ホットドッグを太陽、風、水の XNUMX つのクラスに分類し、対応する Wikipedia 記事を表示することでした (デモ).

この問題の道徳的な側面はしばらく置いておきましょう。勝つ可能性を示唆して参加者を脅迫することは、単純に非倫理的です。 ハカソンに参加する動機の XNUMX つ (特に経験豊富な開発者) は、自分のアイデアを実装することであるため、多くの強力な参加者は、そのようなフィードバックを聞いた後、単にイベントから去ることができます (これは私たちのチームだけでなく、参加をやめた他の多くのチームにも起こりました)メンターの話を聞いた後、ページを更新します）。 それでも、主催者の意向に同意し、主催者の要件を満たすようにプロジェクトを再設計したとしましょう。 次に何が起こるでしょうか?

主催者は「理想のプロジェクト」について独自の理解を持っているので、あらゆる願い（そしてそれに応じて変化）が私たちをその理想に導きます。 出場者は時間を無駄にすることになり、さらなる参加を拒否することはますます難しくなるでしょう（すでに戦力が投入されており、勝利まであとわずかであると思われるため）。 しかし実際には、賞をめぐる競争は激化し、参加者は賞を獲得するために、主催者からの修正を受けてプロジェクトを手直しすることが増えていくことになる。 その結果、賞品を受け取らなかった人は、振り返ってみると、お金なしでフリーランスに参加したことに気づくでしょう。彼らは顧客に変更を加えましたが、同時にこれに対する見返りとして何も受け取っていませんでした（対応するものを除く）もちろん経験です）。

道徳的

主催者からの要望やフィードバックがプロジェクトに役立つこともよくあります。 ただし、その際、参加者は杖をついた足の不自由な人のように指導者のアドバイスに依存すべきではありません。 あなたのプロジェクトに対する主催者から「注文したわけではないので削除してください」というフィードバックを受け取った場合、ハッカソンへの参加は完了したと見なされます。

プロジェクトの明確なビジョンを持ってハッカソンを企画しているが、それを自分で実装するスキルや能力がない場合は、フリーランサーの規約の形式でビジョンをフォーマットすることをお勧めします。 そうしないと、ハッカソンの料金とフリーランサーのサービスの料金を XNUMX 回支払う必要があります。

出所： habr.com