У грудні минулого року ми із шістьма іншими сколківськими компаніями провели власний стартап-хакатон. Без корпоративних спонсорів та будь-якої зовнішньої підтримки, силами программерського співтовариства ми зібрали дві сотні учасників із 20 міст Росії. Нижче я розповім як нам це вдалося, які ми зустріли шляхом підводні камені і чому відразу почали співпрацювати з однією з команд-переможниць.
Інтерфейс програми, що управляє модулями Watts Battery від фіналістів треку, «Мокрі волосся»
Компанія
Наша компанія Watts Battery створює модульні портативні електростанції. Продукт - портативна електростанція 46x36x11 см, здатна давати від 1,5 до 15 кіловат на годину. Чотири такі модулі можуть забезпечувати енергоспоживання невеликого заміського будинку протягом двох діб.
Хоча минулого року ми розпочали відвантаження серійних зразків, за всіма параметрами Watts Battery – стартап. Компанія заснована у 2016-му і з цього ж року – резидент Кластера енергоефективних технологій «Сколково», сьогодні у нас 15 співробітників та величезний беклог того, що ми хотіли б на якомусь етапі зробити, але зараз не до цього.
Туди входять і суто софтові завдання. Чому?
Основне завдання модуля – забезпечити безперебійне збалансоване енергопостачання за оптимальною вартістю. Якщо у вас виникає відключення електрики через незалежні від вас причини, у вас завжди повинен бути резерв для того, щоб повністю запитати необхідне навантаження мережі на час вимкнення. А коли з електропостачанням все гаразд, ви можете використовувати сонячну енергію, щоб заощаджувати.
Найпростіший варіант - ви можете заряджати батарейку від сонця вдень, витрачати ввечері, але до того рівня, який необхідний, щоб у разі блекауту, ви не залишилися без електрики. Так, ви ніколи не опинитеся в ситуації, коли весь вечір живили ви освітлення від батарейки (бо дешевше), а вночі відключили електрику, і у вас розморозився холодильник.
Зрозуміло, що людина рідко спроможна з великою точністю передбачити необхідну їй кількість електроенергії, а озброєна передиктивною моделлю система – може. Тому машинне навчання як таке для нас є одним із пріоритетних напрямків. Просто поки що ми сконцентровані на апаратній розробці і не можемо виділити достатньо ресурсів на ці завдання, що й привело нас на Стартап-хакатон.
Підготовка, дані, інфраструктура
У результаті ми взяли два треки: аналітика даних та система управління. Крім наших, було ще сім треків від колег.
Поки формат хакатону не було визначено, ми думали зробити «свою атмосферу» з бальною системою: учасники роблять якісь речі, які нам здаються складними та цікавими, отримуючи за це бали. Завдань у нас було багато. Але в міру будівництва структури хакатона, інші організатори попросили привести все до загального вигляду, що ми і зробили.
Тоді ми дійшли наступної схеми: хлопці роблять модель на основі своїх даних, потім отримують наші дані, які до цього модель не бачила, вона навчається і починає пророкувати. Передбачалося, що це можна встигнути за 48 годин, але це був перший хакатон на наших даних, і ми, можливо, переоцінили тимчасові ресурси чи ступінь готовності даних. На спеціалізованих хакатонах з машинного навчання такий таймлайн був би нормою, але в нас був не такий.
Програмно-апаратне забезпечення модуля ми максимально розвантажили, зробили спеціально для хакатона версію нашого пристрою з дуже простим і зрозумілим внутрішнім інтерфейсом, який будь-який розробник зміг би підтримати.
Для треку по системі управління була опція зробити мобільний додаток. Щоб учасники не ламали голову, як воно має виглядати і не витрачали зайвий час, ми дали їм дизайн-макет додатка, суперполегшений, щоб ті, хто хоче просто «натягнули» на нього, потрібні їм функції. Чесно кажучи, не чекали тут жодних моральних дилем, але одна з команд сприйняла це так, що ми обмежуємо їхній політ фантазії, хочемо отримати готове рішення безкоштовно, а не перевірити їх у справі. І вони знялися.
Інша команда вважала за краще з нуля зробити зовсім іншу програму, і все вийшло. Ми не наполягали, щоб програма була саме такою, просто потрібно було, щоб у ній містилися деякі елементи, які демонструють технічний рівень рішення: графіки, аналітику тощо. Готовий дизайн-макет був навіть підказкою.
Оскільки аналізувати живий модуль Watts Battery на хакатоні було б надто довго, ми дали учасникам готовий зріз даних за місяць, які були взяті з реальних модулів наших клієнтів (які ми попередньо акуратно анонімізували). Оскільки це був червень, сезонних змін в аналіз закласти було нема з чого. Але в майбутньому ми додамо до них зовнішні дані, типу, сезонних та кліматичних особливостей (сьогодні це галузевий стандарт).
Ми не хотіли створювати в учасників нереалістичних очікувань, тож уже в анонсі хакатона прямо сказали: робота буде максимально наближена до польової: гучні дані, брудні, які спеціально ніхто не готував. Але була в цього і позитивна сторона: ми в дусі agile постійно були в контакті з учасниками, і оперативно вносили зміни в завдання та умови прийому (докладніше про це нижче).
Крім цього, ми давали учасникам доступ до Amazon AWS (так активно, що Amazon нам заблокував один регіон, розбиратимемося, що з цим робити). Там можна розгорнути інфраструктуру для інтернету речей і на базі навіть простих темплейтів Amazon-а зробити за добу повноцінне рішення. Але всі в результаті пішли своїм шляхом, зробивши по-максимуму все самостійно. При цьому комусь удалося вкластися у тимчасовий ліміт, комусь ні. Одна команда Nubble використовувала Яндекс.хмару, хтось на своєму хостингу підняв. Ми були готові давати навіть домени (у нас є зареєстровані), але вони не знадобилися.
Для визначення переможців у аналітичному треку ми планували порівнювати результати, для чого підготували числові метрики. Але робити цього зрештою не довелося, оскільки з різних причин три учасники з чотирьох не дійшли до фіналу.
Що стосується побутової інфраструктури, – тут допоміг Технопарк «Сколково», який надав нам (безкоштовно) один зі своїх затишних модульних залів з відеостіною для презентацій та кілька менших приміщень під зону відпочинку і для організації кейтерингу.
Аналітика
Завдання: система самонавчання, яка ідентифікує аномалії споживання та роботи модуля за контрольними даними. Ми навмисно залишили формулювання максимально спільним, щоб учасники разом з нами подумали, що на основі наявних даних можна зробити.
Специфіка: більш складний із двох треків. Промислові дані мають деякі відмінності від даних у замкнутих системах (наприклад, цифрового маркетингу). Тут потрібно розуміти фізичну природу параметрів, які ви намагаєтеся аналізувати, дивитися на все як абстрактні числові ряди – не вийде. Наприклад – розподіл споживання електроенергії протягом дня. Адже це як ритуали: з ранку в будні включається електробритва, а у вихідні – міксер. Потім суть самих аномалій. І не забуваємо, що Watts Battery призначений для особистого використання, так що кожен клієнт має свої ритуали, і однією універсальною моделлю обійтися не вийде. Знаходити відомі відхилення у даних – це завдання навіть, інша справа – створити систему, яка автономно шукає нерозмічені аномалії. Адже аномалією може бути все, що завгодно, включаючи підступний людський фактор. Наприклад, у нас у тестових даних був випадок, коли систему було користувачем примусово переведено в режим живлення від батареї. Без будь-яких причин, користувачі, буває, роблять так (обмовлюся, що цей користувач тестує модуль для нас і саме з цієї причини має доступ до ручного керування режимами, для решти користувачів керування повністю автоматичне). Як легко передбачити, у такій ситуації батарея розряджається досить активно, і якщо навантаження велике, то заряд закінчиться раніше, ніж сонце постане або з'явиться інше джерело енергії. У таких випадках ми очікуємо побачити якесь повідомлення про те, що поведінка системи відхилилася від штатного. Або людина пішла, забула вимкнути духовку. Система бачить, що зазвичай у цей час доби споживання 500 ватів, а сьогодні – 3,5 тисячі – аномалія! Як Денис Мацуєв у літаку: «Я нічого не розумію в авіадвигунах, але дорогою туди мотор звучав по-іншому».
Графік предиктивної моделі на Opensource нейромережі Yandex CatBoost
Що реально потрібно компанії: самодіагностична система всередині пристрою, предиктивна аналітика, у тому числі без мережної інфраструктури (як показує практика, далеко не всі наші клієнти поспішають підключати батареї до інтернету – більшості достатньо, щоб просто все надійно працювало), ідентифікація аномалій, природу яких ми поки не знаємо , самонавчається система без вчителя, кластеризація, нейронні мережі та весь арсенал сучасних методів аналітики Нам потрібно розуміти, що система поводилася по-іншому, навіть якщо ми не знаємо, що саме змінилося. На самому хакатоні нам дуже важливо було побачити, що є хлопці, готові ступити в промислову аналітику або вже знаходяться в ній, і вони шукають для себе нові сфери застосування своїх здібностей. Спочатку здивувало, що охочих так багато: все-таки це дуже специфічна кухня, але поступово з чотирьох учасників відвалилися всі, крім одного, тому певною мірою все стало на свої місця.
Чому нездійсненно на цьому етапі: основна проблема датамайнінгових завдань - недостатньо даних. Сьогодні у світі функціонують кілька десятків пристроїв Watts Battery, але багато з них не підключені до мережі, тому наші дані поки що не надто різноманітні. Самих аномалій ми насилу наскребли дві – і ті мали місце на досвідчених зразках, промислові Watts Battery працюють досить стабільно. Якби у нас був внутрішній machine learning-інженер, і ми знали б – так, з цих даних можна вичавити ось це, а ми хочемо отримати більш круту якість передбачення – це була б одна історія. Але досі ми нічого з цими даними не робили. Крім того, це вимагало б глибокого занурення учасників у специфіку роботи нашого виробу, добу-півтори на це недостатньо.
Як вирішили: не стали відразу ставити точне фінальне завдання Натомість протягом усіх 48 годин були у діалозі з учасниками, оперативно дізнавалися, що вони спроможні отримати, а що ні. На основі цього, на кшталт компромісу доопрацьовували і завдання.
Що отримали за підсумками: переможці треку змогли почистити дані (принагідно знайшли «особливості» обчислення деяких параметрів, які ми раніше самі не помічали, тому що не використовували частину даних для вирішення наших завдань), виділити відхилення від очікуваної поведінки модулів Watts Battery, і налаштувати предиктивну модель яка в стан передбачати споживання електроенергії з великим ступенем точності. Так, це лише feasibility етап розробки промислового рішення, далі знадобляться тижні копіткої технічної роботи, але навіть цей прототип, створений прямо в процесі хакатону, може лягти в основу реального промислового рішення, що є рідкістю.
Головний висновок: на основі наявних у нас даних можна налаштувати передиктивну аналітику, ми це припускали, але не мали ресурсів перевірити. Учасники хакатону перевірили та підтвердили нашу гіпотезу, далі працюватимемо з переможцями треку над цим завданням.
Графік предиктивної моделі на opensource нейромережі Facebook Prophet
Порада на майбутнє: складаючи завдання, потрібно озиратися не лише на свій виробничий roadmap, а й на інтерес учасників. Оскільки наш хакатон без грошових призів, ми граємо на природній для датасайнтистів цікавості та прагненні вирішувати нові, цікаві завдання, в яких ще ніхто нічого не показав або де можна себе показати краще, ніж існуючі результати. Якщо відразу враховувати фактор інтересу, то не доведеться зрушувати фокус у ході справи.
Управління
Завдання: (Додаток) керуюче мережею модулів Watts Battery, з особистим кабінетом, зберіганням даних у хмарі, моніторингом стану.
Специфіка: у цьому треку ми не шукали якогось нового технічного рішення, у нас свій споживчий інтерфейс, звичайно ж, є. Вибрали його на хакатон для демонстрації можливостей нашої системи, занурення в неї, перевірки наявності у ком'юніті інтересу до теми розробки для систем smart та альтернативної енергетики. Мобільний додаток ми позиціонували як опцію, можна було робити чи не робити на власний розсуд. Але на наш погляд, воно добре показує, як людям вдалося організувати зберігання даних у хмарі, з доступом одразу з кількох різних джерел.
Що реально потрібно компанії: комьюніті розробників, які вигадуватимуть бізнес-ідеї, тестуватимуть гіпотези та створюватимуть працюючі інструменти для їх реалізації.
Чому нездійсненно на цьому етапі: обсяг ринку поки що занадто невеликий для органічної освіти такого ком'юніті
Як вирішили: провели в рамках хакатону якесь фізибіліті стаді, чи можна навколо нашого специфічного продукту вигадувати не просто фічі, але повноцінні бізнес-моделі. Причому, щоб робили це люди, здатні реалізувати прототип, все-таки тут – не хочу нікого образити – не рівень програмування миготливого світлодіода на Arduino (хоча і це можна робити з інноваціями), тут потрібні досить специфічні навички: розробки бекенд та фронтенд систем, розуміння принципів побудови масштабованих систем Інтернету речей.
Що отримали за підсумками: дві команди запропонували повноцінні бізнес-ідеї під свою роботу: одну, орієнтовану більше на російський сегмент, іншу на закордонний. Тобто у фіналі не просто розповіли, як вони вигадали програму, але по суті прийшли робити бізнес навколо Watts-а. Хлопці виклали, як бачать використання Watts-а в кількох бізнес-моделях, привели статистику, показали в яких регіонах які проблеми, які ухвалюються де закони, окреслили світовий тренд: немодно майнути біткойни, модно майнути кіловати. Вони цілеспрямовано прийшли на альтернативну енергетику, що дуже сподобалося. Те, що учасники, крім цього, змогли зробити технічне рішення, що ще працює, говорить про те, що вони можуть самостійно запустити і стартап.
Головний висновок: існують команди, готові взяти Watts Battery як основу своєї бізнес-моделі, розвивати її, стати партнерами/компаньйонами компанії. Деякі з них навіть вміють виділяти MVP бізнес-ідеї та працювати над ним насамперед, чого сьогодні не вистачає в індустрії повсюдно. Люди не розуміють колись зупинитися, коли потрібно видати на ринок рішення, нехай раннє, але працююче. По факту ж етап полірування рішення часто не закінчується, технічно рішення переходить межу розумної складності, виходить на ринок перевантажене, вже незрозуміло яка там була спочатку ідея, який націлення клієнтів, які закладені бізнес-моделі. Як у анекдоті про Акуніна, який написав ще одну книгу, коли підписував комусь попередню. А тут було зроблено в чистому вигляді: ось графік, ось лічильник, ось індикатори, ось пророцтво – все, більше нічого не треба для запуску. З цим можна йти до інвестора та отримувати гроші на запуск бізнесу. Ті, хто знайшли цей баланс і вийшли з треку переможцями.
Порада на майбутнє: на наступному хакатоні (ми плануємо його ), можливо, має сенс поекспериментувати і з «залізом». У нас своя апаратна розробка (одна з переваг Watts), ми повністю контролюємо виробництво та тестування всього, що робимо, але на перевірку деяких «залізних» гіпотез не вистачає ресурсів. Дуже можливо, що у співтоваристві системних та низькорівневих програмістів та апаратних розробників є ті, хто нам із цим допоможе і в майбутньому стане нашим партнером у цьому напрямі.
Люди
На хакатоні ми очікували швидше за тих, хто хоче спробувати себе в новій області (наприклад, випускників всіляких шкіл програмування), ніж тих, хто спеціалізується на подібних розробках. Але все ж таки ми розраховували, що перед хакатоном вони проведуть трохи підготовчої роботи, шанують, як взагалі передбачають споживання в енергетиці і як влаштовані системи інтернету речей. Щоб усі прийшли не просто фаном за цікавими даними та завданнями, а й з попереднім зануренням у предметну область. Зі свого боку ми розуміємо, що для цього необхідно заздалегідь публікувати наявні дані, їх опис та точніші вимоги до результату, публікувати API модулів та ін.
Технологічний рівень у всіх був приблизно однаковий, можливості плюс-мінус також. На цьому тлі не останнім чинником став рівень спрацьованості. Ряд команд не вистрілили, бо не змогли чітко розділитись за напрямками робіт. Були й такі, у яких всю розробку робила одна людина, решта займалася підготовкою презентації, в інших – комусь діставалися завдання, які вони робили, мабуть, уперше у житті.
Здебільшого учасники були молодими, це не означає, що серед них не було сильних machine learning-інженерів та розробників. Більшість приходили командами, одинаків практично не було. Усі мріяли перемогти, хтось хотів знайти роботу в перспективі, приблизно 20% її вже знайшли, гадаю, ця цифра зростатиме.
Нам не вистачило хардварних гіків, але сподіваємось компенсувати це на другому хакатоні.
Хід хакатону
Як я вже писав вище, більшу частину 48-ї години хакатону ми були з учасниками і, стежачи за їх успіхами на чекпойнтах, намагалися адаптувати завдання та умови прийому першого, аналітичного треку так, щоб, з одного боку, учасники змогли його доробити за те, що залишилося. час, а з іншого – він представляв для нас інтерес.
Останнє уточнення до завдання зробили десь у районі останнього чекпойнту, вдень у суботу (фінал було намічено на вечір неділі). Ми ще трохи спростили: прибрали вимогу перерахунку моделі на нових даних, залишили ті дані, з якими команди вже працювали. Порівняння метрик нам уже нічого не давало, у них вже були готові результати за наявними даними і на другу добу хлопці вже були втомлені. Тому ми вирішили їх менше мучити.
Тим не менш, троє з чотирьох учасників до фіналу не дійшли. Одна команда вже на старті зрозуміла, що їм цікавіше трек наших колег, інша перед фіналом зрозуміла, що в процесі обробки відфільтрувала потрібні дані раніше часу і відмовилася представляти свою роботу.
Команда «21 (Ефект мокрого волосся)» до останнього брала участь в обох наших треках. Вони хотіли охопити все: і машинне навчання, і розробку, і додаток, і сайт. Поки ми в останній момент не пригрозили зняттям, вони вірили, що все встигають, хоча вже на другому чекпойнті було очевидно, що з головним – machine learning – суттєвого прогресу досягти не змогли: вони в цілому впоралися з другим блоком, але передбачати споживання електроенергії. були не готові. У результаті коли ми визначили мінімальне завдання для кваліфікації на перший, вони все ж таки зробили вибір на користь другого треку.
У Fit-predict був збалансований, заточений під аналітику даних склад, тому вони змогли подолати все. Було помітно, що хлопцям було цікаво помацати реальні промислові дані. Вони одразу сконцентрувалися на головному: аналізували, чистили дані, розбиралися з кожною аномалією. Те, що вони за термін хакатону змогли збудувати робочу модель – велике досягнення. У робочій практиці на це зазвичай йдуть тижні: поки чистяться дані, поки що в них вникають. Тому ми з ними обов'язково працюватимемо.
У другому треку (управління) ми очікували, що всі за півдня все зроблять і прийдуть просити ускладнити завдання. Насправді ледве встигли доробити базове завдання. Працювали на JS, Python, що відображає поточний стан індустрії.
Тут також досягли результату спрацьовані команди, у яких поділ праці було збудовано, зрозуміло, хто чим займається.
У третьої команди - FSociety, здавалося, було рішення, але в результаті вони вирішили не показувати свою розробку, сказали, що вони не вважають його робітником. Ми поважаємо це і сперечатися не стали.
Перемогла команда "Стриптизери з Баку", яка змогла себе зупинити, не гнатися за "рюшечками", а зробити MVP, яке не соромно показати і яке зрозуміло, що можна далі розвивати та масштабувати. Ми їм одразу сказали: що додаткові можливості нас не надто цікавлять. Якщо вони хочуть реєстрацію через QR-код, розпізнавання осіб, нехай спочатку зроблять графіки у додатку, а потім беруться за факультативне.
У цьому треку «Море волосся» впевнено увійшли у фінал, і з ним та «Стриптизерами» ми обговорювали подальшу співпрацю. З останніми вже зустрілися у новому році.
Сподіваюся, що все вийде, і чекаємо на другий хакатон у березні!
Джерело: habr.com