Чтобы игра стала хитом, нужны большие затраты (и огромное везение). Геймплей должен приносить удовольствие, сюжет должен цеплять, прогресс должен радовать, баги должны не появляться или хотя бы не быть критическими. Качественно сделанная игра выстрелит, а количество фанатов будет расти в геометрической прогрессии. Но есть один фактор, который может свести на нет все усилия. Это халтурная локализация. Даже шедевр может затеряться на фоне колоссального количества новых проектов, если получит несколько негативных отзывов при запуске.
Горячая тема! Я раньше очень много и тесно работал с основателями стартапов, а теперь и сам им являюсь, выпускник прошлогоднего батча Y Combinator S21 (так что есть внутрячки-инсайты-бенчмарки). Видел разные подходы к этому вопросу. Сколько платят себе основатели? Ниже речь пойдет прежде всего о pre-seed/seed компаниях.
Самое главное заблуждение обывателя про стартапы - в том, что закрыв раунд, например на несколько $млн, основатели сразу резко богатеют. Многим разумным людям это очевидно. Но менее интуитивная правда в том, что любой фаундер, способный привлечь немного денег в свой стартап, зарабатывает сильно меньше, чем если бы работал по найму или занимался фрилансом/агентством. Поэтому какой-нибудь ваш знакомый, привлекший несколько $млн (что звучит, безусловно, мощно) наверняка зарабатывает заметно меньше другого вашего знакомого - хорошего разработчика.
Недавно натолкнулся на статью в корпоративном блоге Home Credit Bank на Хабре.
Там есть ссылка на нашу статью на Хабре, статья в свою очередь ведет на наш проект, который опубликован под лицензией GNU Affero General Public License v3.0:
Вероятно вы уже поняли, куда это все идет. Данная лицензия подразумевает публикацию кода проекта, который использует наши модели. Но банк естественно этого делать не будет, потому что это банк. А значит лицензия де факто означает некоммерческое использование.
Но Home Credit Bank естественно не обращался к нам за коммерческой версией или лицензией для данной модели.
Программа получается отличной: Андрей Цветцких (Тинькофф), Дмитрий Цепелев (Злые Марсиане), Серёжа Попов (HTML Academy), Андрей Смирнов (X5), Алексей Бородкин (Ozon), Елена Насыбуллина (Selectel), Дмитрий Калаев (ФРИИ), Максим Рогожников (Тинькофф), Антон Назаров (Autodesk), Александр Кириллов (Evrone), Филипп Терехов (Уфимский городской планетарий) — и это не всё. Под катом — подробности программы.
Собирая команду, надо думать не столько про сеньоров и мидлов, сколько про распределение между теми, кого Ты наймёшь на фикс, кого на почасовку, а кому вообще будешь проектно задавать мелкие фишечки. Нужно думать про "командный пирог", в котором "ядро на фиксе" - только один из слоёв.
Январь этого года был для меня не только чередой праздников, но и поводом отметить год, как мы полностью переехали на новый платежный шлюз. Для нас, как для сервиса подписки на духи, это одна из ключевых систем и если с ней есть проблемы, то это касается всех в компании. Сам переезд можно сравнить с хорошей книгой: есть экспозиция - проблемы с прошлым сервисом, завязка как мы делали выбор между своей разработкой и готовым сервисом, развитие действия - когда мы начали работать над архитектурой и делать первые коммиты, кульминация - момент первого запуска и первые проблемы с ним и развязка, когда мы закончили миграцию всех клиентов. Звучит интересно? Тогда добро пожаловать под кат.
Принято считать, что умный человек всегда может договориться с другими умными людьми, к обоюдной выгоде. Они придумают правила, разделят ответственность, назначат исполнителей и будут сосуществовать спокойно и счастливо, наслаждаясь гармонией. По крайней мере, так должно быть в идеальном мире, существующем в воображении многих хороших людей.
Примерно так посчитал Творец некой библиотеки, создавая функционал книжных отзывов. Хороший и умный читатель, прочитав книгу, поделится впечатлением о прочитанном. Выскажет своё впечатление. Похвалит или поругает — не важно. Главное, что его мнение поможет сориентироваться в книжном море другим читателям. Ведь книги, как я уже писал, имеют высокий порог вхождения. Качество текста не очевидно с первой страницы — зачастую нужно потратить на книгу несколько часов, чтоб замысел автора раскрылся.
Конечно, наш Творец позаботился о защите от злого умысла. Для поддержания порядка, он роздал завсегдатаям библиотеки 200 конвертиков — особых прав, позволяющих им скрывать отзывы других читателей из ленты. Раздавая конвертики, Творец повелел распоряжаться ими мудро и ответственно — скрывая исключительно спам, спам и ничего кроме спама. После чего удалился, оставив созданный им мир на произвол судьбы.
Творцы — они такие.
Некоторое время библиотека существовала, работая в штатном режиме. Читатели писали и читали отзывы, редкие спамеры удалялись из ленты, в общем, сплошное благорастворение на воздусях и во человецех благоволение. Но вскоре в мир библиотеки проникло зло.
Привет, Хабр! Меня зовут Леонид Огрель, я работаю аналитиком в Джум Лабс. В этой статье я расскажу, зачем нужен эксперимент в ИТ-продукте, и на что нужно обратить внимание при его запуске.
Как понять, понравится ли пользователям изменение, которое мы хотим внести? Принесет ли оно пользу компании? Работает ли новый алгоритм ранжирования товаров лучше по сравнению с используемым? Снизится ли конверсия, если мы добавим дополнительный баннер на карточку товара?
Чтобы ответить на подобные вопросы, мы проводим большое число онлайн экспериментов, по итогам которыx ожидаем получить чёткий ответ: улучшает ли изменение метрики компании или нет.
Процесс подготовки эксперимента к запуску можно разделить на три этапа. Ниже остановимся подробнее на каждом из них.
Как социолог в IT, я регулярно провожу исследования среди тимлидов. И часто слышу от новоиспеченных лидов, что им была бы очень полезна подготовка к их новой роли. А более опытные для прокачки софт-скиллов хотят понятную систему инструментов. Подведя некоторые итоги, я составила топ-3 самых частых трудностей:
Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;
Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.
Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.
То есть многие просто не знают, что делать, когда становятся тимлидами: сначала им сложно и некомфортно, у них не получается или получается не то, а ожидания бизнеса и команды не очень понятны. А потом им непонятно, как можно те самые sotf skills развивать, если каждый one-on-one отнимает массу сил.
Меня зовут Сандра Урядова, и сегодня я хочу рассказать, как на этом пути тимлиду может помочь его собственная уязвимость, в которой, как ни парадоксально, лежит сила быть человеком. Да, иногда это очень сложно сделать, но эта сила позволит вам не только выйти из стрессового состояния, но и создать благоприятный фон в команде — вы покажете другим, что так можно: быть человеком, а не машиной.
На прошлой неделе компания Monotype — владелец прав на популярные шрифты Times New Roman, Verdana, Arial, Helvetica и Tahoma — объявила об ограничении доступа из России к своей библиотеке и сообщила о приостановке взаимодействия с российскими организациями. Новость стала еще одним поводом обратить внимание на специфику использования проприетарных шрифтов в бизнес-среде – проблему, которая выходит далеко за рамки ситуации с Monotype. Речь о возможных сложностях при отображении существующих документов и шаблонов, особенно при работе с различными таблицами, формами и автоматически формируемыми файлами из информационных систем.
Для минимизации подобных проблем мы в МойОфис еще шесть лет назад представили свои шрифты XO_Fonts. Они свободно распространяются и доступны бесплатно. Сегодня этот набор состоит из 11 шрифтов и 24 начертаний. Их особенностью является метрическая совместимость с распространенными проприетарными шрифтами, которая позволяет сохранить оригинальное форматирование и верстку документов, ранее созданных с использованием популярных иностранных шрифтов.
Некоторое время назад на D-Russia была опубликована история создания XO_Fonts. Теперь мы предлагаем ознакомиться с ней и читателям Хабра.
Привет, Хабр! Ранее я писал о том, как можно подружить разработчика и писателя в рамках единого процесса и о подходе Docs-as-code к документированию разработки. Здесь мне бы хотелось поразмышлять, как в условиях agile и постоянного развития одновременно перестраивать документирование под требования других процессов, зачастую не очень предсказуемых, и при этом сохранить максимальную целостность, качество и единообразие документации.
Успейте подать заявку на участие в нашей обучающей программе! 1 мая после 23:59 мы закроем анкеты. И откроем новый набор только в 2023 году :)
Мы подготовили для будущих стажеров отличный учебный план с практическими задачами и ворк-шопами. Кстати, напоминаем: по итогам прохождения стажировки вы можете получить оффер и работать у нас!
Чтобы не продалбывать задачи нужно следовать 47 правилам в работе и жизни… стоп. Так не работает, мы же знаем. Я решил формализовать свою систему контроля задач и описать её в пошаговом гайде – с порядком и постепенным усложнением. Хочется научиться работать как процессор? Добро пожаловать под кат.
Всем привет! Это вторая часть статьи об изменении подхода к рекомендациям в Delivery Club. В первой части я подробно описал текущие проблемы нашей рекомендательной системы: локально оптимальный баланс exploitation и cold start, а также недостаточно развитый механизм exploration. А также рассказал, как мы решали проблему exploitation через карусель «Вы заказывали», а проблему cold start — через карусель популярных фастфуд-ресторанов.