Возможно, вы уже знаете компанию Futurice, даже если сами об этом не подозреваете: она стоит за популярным списком «Android best practices», перевод которого пару лет назад собрал на Хабре почти 50 000 просмотров. За эту пару лет и оригинал текста был ощутимо обновлён, и с компанией произошло много интересного: она оплачивает вклад сотрудников в open source, активно работает с новыми мобильными технологиями вроде React Native (уже поделившись с миром своим starter kit для него), а к аутсорс-разработке добавила работу над стартапами.
На прошедшей в Петербурге конференции Mobius бизнес-директор компании Михаил Самарин рассказывал о трендах мобильной разработки за последний год: от взлёта того же React Native до дефицита нативных мобильных разработчиков. А мы отдельно расспросили Михаила для Хабра и о компании в целом, и о мобильной разработке. Поскольку он живёт в Хельсинки, в его русскоязычных ответах порой встречаются англоязычные слова — но так только интереснее.
О компании
— Вводный вопрос для тех, кто слышит о Futurice впервые: что компания собой представляет?
— Мы называем компанию «консалтинговой», но здесь есть терминологический нюанс в том, что называют консалтингом в Скандинавии. Более близким термином для России будет subcontracting или аутсорсинг. Нас уже почти 400 человек, два офиса в Финляндии, два в Германии, по одному в Швеции и Англии.
Наше главное отличие: 80% проектов проходят на территории заказчика, на время наша команда становится частью команды заказчика, и все наши специалисты, независимо от направления, напрямую работают с ним.
Сейчас есть очень много высококачественных subcontracting-агентств в Восточной Европе и в Азии, мы давно не соревнуемся с ними по многим причинам. Одна из причин — цена, нет никакой экономической возможности конкурировать в этом. Но наступает такой момент, когда заказчикам не хватает удалённых сабконтрактинговых агентств, им становится очень важно иметь специалиста у себя в офисе, с живым общением. И тогда они приходят к нам.
— Компания давно известна как аутсорсер, а недавно взяла и занялась также стартапами — со стороны это было неожиданно. Что стало причиной? Что это означает для разработчиков из Futurice?
— Сотрудники Futurice — это люди, которым важно верить в то, чем они занимаются. Нашим разработчикам важны не только технологические аспекты, но и social impact, влияние их работы на общество.
К сожалению, мы не всегда можем похвастаться тем, что абсолютно все наши проекты имеют действительно весомый social impact. Естественно, мы надеемся, что создаваемые нами сервисы упрощают жизнь, но порой прямое влияние на общество очень трудно определить, кроме упрощения повседневных задач.
При этом, поскольку мы достигли определённого статуса, в части случаев работаем с гигантскими компаниями, наши партнёры имеют потрясающую возможность влияния на мир. Эти компании тоже ищут новые пути и для бизнеса, и для того, как они могут сделать свой contribution в этот мир.
А кроме того, работа может выполняться на несколько горизонтов: то, что важно сегодня, завтра или 10-20 лет. Если мы начинаем участвовать в проектах, эффект которых будет не сегодня-завтра, а через 10-20 лет, то традиционная бизнес-модель консалтинговых агентств не подходит.
В связи с этим мы решили, что мы будем создавать startup ventures и кооперироваться с некоторыми нашими заказчиками для создания новых компаний с очень большим социальным импактом. Сотрудники Futurice, желающие попробовать себя в чём-то, отличающемся от традиционного консалтингового бизнеса, получают возможность стать частью таких инициатив — в качестве сотрудников или даже соучредителей. Первый такой наш проект, о котором мы недавно публично объявили: вместе с крупнейшей энергетической компанией Финляндии Fortum создаём joint venture по SAAS-инициативе, которая упрощает для обычных людей работы в тех местах, где есть возможность производить солнечную энергию.
— Futurice спонсирует вклад сотрудников в open source — это тоже история про social impact?
— Да, это еще одна наша инициатива со схожей идеей. Чтобы привлекать исключительных специалистов, недостаточно просто иметь обычную хорошую компанию с хорошими условиями. Нужно иметь компанию, которая делает больше, чем зарабатывает деньги для своих собственников. Особенно в ситуации, когда много молодых людей приходит с университетской скамьи: новое поколение гораздо более socially aware. И когда технические специалисты участвуют в open source-проектах — это то, что они как специалисты могут дарить в общество, развивая то или иное техническое направление.
Некоторое время назад мы решили активно спонсировать эти действия наших сотрудников и создали так называемую программу Spice. Если я правильно помню, «спайс» пошло из «Дюны» Френка Герберта, но интересным образом трансформировалось, с одной стороны, в перец чили как специю (spice), а с другой — в единорога, unicorn. Поэтому логотип, нарисованный в Microsoft Paint одним из основателей этого направления Тээму Туруненом — «chilicorn», единорог с перцем чили вместо рога.
И некоторое время назад мы решили, что вне зависимости от того, в каких опенсорс-проектах наши работники участвуют в нерабочеее время, мы в компании будем спонсировать определённое количество часов труда наших работников. У нас есть фонд и система, в которой работники сообщают, где и сколько часов они делают свои contributions, и мы считаем, что таким образом увеличиваем social impact компании. И главное: как компания, мы не претендуем ни на какие права тех open source-проектов, которые спонсированы нам через Spice. Финансирование — это просто наш социальный вклад, как говорится, no strings attached.
Наверное, не очень много компаний занимаются таким, если это не часть их основного бизнеса, и в результате мы привлекли этой программой внимание очень интересных людей. А в конце прошлого года решили продвинуть это дальше и организовали Chilicorn Fund — фонд, где мы выделяем определённое количество денег на спонсирование разных open source и non-profit проектов, которые создаются либо нашими работниками в рабочее время, либо другими компаниями, приходящими к нам за спонсированием.
Тээму не так давно написал обо всём этом книгу, рекомендую её.
— В блоге Futurice недавно был пост с громким заголовком «Почему я не нанял бы Дональда Кнута». Звучит провокационно, но если почитать аргументы, то они звучат убедительно. Тогда такой вопрос: окей, Дональда Кнута нанимать не стали бы, а каких людей хотите нанимать, кто лучше всего подходит Futurice?
— Для начала замечу вот что: в блоге компании каждый работник имеет право на свое мнение, и необязательно, что все остальные будут согласны с этим мнением — это тема для дискуссии. Мы не пытаемся цензурировать то, что работники пишут в блоге, это часть культуры компании. Так что конкретный пост не стоит автоматически считать официальной позицией компании.
Но да, есть важный момент, который отметил Якко в том блог-посте: если вы обладаете потрясающим алгоритмическим и глубоким техническим знанием в каком-то определённом направлении, то это вовсе не означает, что вы будете хороши в консалтинге.
Наверное, есть тип людей, которым лучше подходят консалтинговые, сабконтрактинговые компании по сравнению, например, с продуктовым бизнесом. Я бы сказал, что консалтинговый бизнес отличается от продуктового следующим: есть возможность позаниматься очень многими проектами с очень большим количеством разных технологий в разных ситуациях, с разными заказчиками и так далее. И чем больше компания, тем больше таких возможностей. Я думаю, для многих людей заниматься одним и тем же продуктом на протяжении многих лет может быть очень скучно. Но это зависит от вашей внутренней специфики.
Ещё хочу обратить внимание: часто считается, что разработчик в такой компании обязательно должен быть экстравертом, но это такой большой misconception. На самом деле необходимость постоянно коммуницировать с командой заказчика не означает необходимость постоянного общения в экстравертных ситуациях.
— В Guardian недавно писали о внутреннем проекте хельсинкского офиса Futurice, который сообщает сотрудникам офиса информацию вроде «занят ли сейчас туалет» — можете об этом рассказать?
— Да, интересный проект. Мы создали систему, которая может, например, определять местонахождение в офисе тех сотрудников, которые сами хотят быть определёнными. Там много сенсоров и компонентов, вплоть до такого controversial решения, как детектор метана в определённых местах :)
Но я бы хотел использовать этот вопрос, чтобы проиллюстрировать то, чем мы занимаемся в Futurice. Мы уже говорили про наше инициативы, связанные с внешним social impact, а это внутренние инициативы, которые снаружи могут быть не очень видны.
Некоторое время назад мы задумывались, каким образом люди учатся и экспериментируют с новыми технологиями. Безусловно, идеальный вариант — в проектах с заказчиками, но как правило, это более-менее традиционные мобильные или веб-проекты. Каким образом развивать знания специалистов, когда хотим попробовать те области, по которым либо вообще нет никаких проектов, либо это недавно появившиеся технологии? Мы создали внутреннюю инициативу Futulabs, где наши сотрудники могут покупать какие угодно новые гаджеты, сенсоры, VR-headsets и так далее, с тем, чтобы иметь аппаратную базу для экспериментиров с новыми технологиями.
IoT-эксперименты — часть этой инициативы, где сотрудники могут в рабочее время пробовать разные вещи и экспериментировать. Так у нас и появляются интересные эксперименты, которые потом оказываются в Guardian. Но есть ещё более интересный аспект этого. Когда вы разговариваете с многими компаниями, даже с техническими специалистами, и упоминаете термин IoT — это, к сожалению, buzzword, который очень часто не несёт смыслового наполнения. А когда вы пытаетесь разговаривать на каких-то более конкретных уровнях, то у вас нет предмета для разговора. Всем очевидно, что можно иметь какое-то количество сенсоров, микроаппаратуры, связывать их в компьютерную сеть, каким-то образом получать и обрабатывать данные. Это стало возможным ещё с появлением микроэлектроники. А каким образом непосредственно применить это к той или иной проблеме, которую компания пытается решить — это совсем другой уровень.
Мои коллеги создали IoT Service Kit. Эта инициатива началась так: когда мы разговариваем с заказчиками, как мы можем помочь им понять, что такое IoT и как они могут применить это в каком-то конкретном бизнесе? В итоге создали то, что можно назвать настольной игрой.
Набор canvases, которые описывают разные ситуации (офисные здания, магазины, индустриальная фабрика), и набор трёхмерных фигурок, которые представляют разные объекты: там есть сенсоры, камеры, автомобили, люди, участники движения и так далее. И всякие сценарийные карточки. И с помощью такого, казалось бы, довольно примитивного набора инструментов мы получили набор методик, воркшопов и способов общения с заказчиками, когда мы можем выкристаллизовать их идеи восприятия: где, как и в каких сценариях их конкретного бизнеса это может быть применимо, нужно ли это вообще. Недавно коллеги получили награду UX Magazine за эту работу. Мы сделали весь этот проект опенсорсным, на сайте можно всё это получить и увидеть наглядное видео.
О мобильной разработке
— Для начала хочется узнать: какое место мобильная разработка занимает в Futurice, сколько вы занимаетесь ей, а сколько немобильной? Является ли для вас какая-то мобильная платформа более приоритетной?
— Я бы сказал, что мобильная и веб — 50 на 50. Есть сезонность, бывают всплески активности, например, в связи с выпуском новых ОС и новых устройств, но в целом так. В отношении платформ — мы платформо-агностичные, стараемся быть во всех бизнесах, которые сейчас активны.
— Раньше у Futurice были громкие проекты на Windows Phone: например, в вашем докладе на Mobius 2015 было много таких примеров. За последние два годы рынок WP-разработки схлопнулся. Как на вас сказалось исчезновение важного рынка?
— Хороший вопрос, иллюстрирующий разные подходы. Очень ценный совет для разработчиков — быть прагматичными. Если для вас программирование — это профессия, которой вы собираетесь заниматься долго, то стоит очень прагматично относиться к рынку с его супербыстрым изменением технологий. Гигантские корпорации появляются и исчезают, а вы хотите оставаться востребованными.
Futurice всегда был исключительно платформо-агностической компанией. Мы всегда старались не поддерживать какие-то направления особенно сильно из-за того, что они «нравятся». Мы стараемся двигать индустрию, а не конкретное техническое направление. Нам важен конечный социальный или бизнес-импакт чего-либо, а не использование технологии только потому, что она «хорошая», а та «плохая».
Поэтому мы всегда, даже во времена Symbian, очень прагматично относились к взаимоотношениям с Nokia, хотя у нас с этим была связана значительная часть бизнеса, да ещё и сказывалась специфика Финляндии с большим проникновением телефонов Nokia. В результате, когда Nokia резко отходила от Symbian, другие сабконтрактинговые компании увольняли своих работников в этой области, а у нас никогда в жизни не было даже мысли, что если мы нанимаем специалиста технологии X, то при её исчезновении мы уволим его и наймём другого. У нас политика поиска и найма хороших талантливых работников, дизайнеров, консультантов, которые достаточно гибкие и готовы переключаться на другие технологии.
Когда Symbian, можно сказать, в числе одной недели исчез как бизнес и появился Windows Phone, у нас была очень мягкая transition между одним Nokia-миром и другим. И точно так же на протяжении последних двух лет, когда Windows Phone стал исчезать как бизнес, у нас происходит мягкая миграция наших проектов из одной сферы бизнеса в другую.
Это важный момент, особенно для людей, которые только начинают свою карьеру в программировании. Могут возникать мысли «есть технология такая-то, она лучше всего, потому что самая новая и никогда таких замечательных не было, она изменит мир и так будет всегда, а вы, старые разработчики, ничего не понимаете, потому что вы старые, и вот этой технологией я буду заниматься всю жизнь». Но в технологической области всё движется с дикой скоростью, поэтому важно осознавать, что ни одно технологическое направление в консалтинговом бизнесе не является постоянным.
— К вопросу о начинающих разработчиках. Вы в своём свежем кейноуте говорили про резкий взлёт React Native, также растёт интерес к мобильному вебу. В итоге у начинающих возникают сомнения «стоит ли вкладывать время в изучение нативной мобильной разработки, или теперь везде веб, JavaScript и кроссплатформенность, и с нативной я окажусь невостребованным». Что вы можете им сказать?
— Профессиональные советы такого уровня давать сложно, долгосрочные прогнозы — всегда гадание на кофейной гуще. Но вот что мы реально наблюдаем сейчас. Два-три года назад многие свежие выпускники приходили к нам из университетов в нативную мобильную разработку, причём с уже готовым багажом знаний. На протяжении последнего года мы видим, что катастрофически сократилось количество новых молодых специалистов, которые идут непосредственно в native. Все идут в веб-разработку, как в свой первый шаг в профессиональном программировании.
И в итоге возник такой дефицит «нативных» кадров, что в текущей ситуации как раз толковому нативному мобильному разработчику очень легко найти работу. Ему, в принципе, можно её не искать, достаточно просто заявить где-то публично «я — native мобильный разработчик», и через пять минут у него будет работа.
А также важно понимать, что при всём росте популярности кроссплатформенной разработки самый бескомпромиссный доступ ко всем возможностям платформы, всегда будет с native SDK или native tools, которые предоставляются производителем этой платформы. И если мы говорим о first day release features, если Google или Apple выпускают новую ОС или новое устройство, то их поддержка гарантирована именно их инструментами, их SDK. А если вы используете кроссплатформенные решения и через некоторое время решаете копнуть глубже, чтобы обойти какие-то компромиссы вашего кроссплатформенного решения, то native-знания всегда оказываются полезными и востребованными.
Кроссплатформенные решения вроде React Native и Xamarin обладают своими плюсами и минусами, которые не всегда очевидны, потому что скорость создания мобильных приложений или доступ к каким-либо определённым платформенным фичам — не всегда прямой показатель, нужно ли вам использовать данное какое-то решение.
— Вы упомянули Xamarin, в Futurice его используют, и хочется спросить о судьбе проекта. Видно, что в Microsoft не просто «купили Xamarin и забыли», а развивают купленное (например, сделали Visual Studio for Mac на основе Xamarin Studio) — а по тому, что вы видите, насколько их усилия приводят к результату, оказывается ли Xamarin востребован?
— Xamarin — интересная вещь в том смысле, что в зависимости от страны его популярность может быть исключительно большой или исключительно маленькой. В Финляндии интерес, пожалуй, минимальный по сравнению с другими странами. Не знаю, связано ли это с тем, что местное сообщество разработчиков устало от разных решений Microsoft от покупки Nokia до её исчезновения. Но одно знаю точно: в тех странах, где традиционно большое число разработчиков на ASP.NET и C#, для них это, естественно, самый естественный способ прийти в мобильную разработку.
И судя по разговорам как с представителями Microsoft, так и с бывшими сотрудниками Xamarin, которые теперь тоже сотрудники Microsoft, его популярность с момента покупки Microsoft начала расти экспоненциально, особенно в enterprise-средах.
Tools для Xamarin под Mac пока гораздо более стабильные, чем под Windows. Регулярно и с той, и с другой стороны что-нибудь ломается, но это, в общем-то, естественный процесс. В случае с React Native люди тоже зачастую испытывают проблемы не с идеологической точки зрения, а из-за того, что ломается при выходе новой версии, сколько времени тратится на переконфигурацию своей среды. Такие же проблемы есть и с Xamarin, так что тут вопрос личных предпочтений.
— Интересно следить за тем, как в iOS-мире идёт переход к Swift: кто-то уже переписал всё своё приложение, а кто-то не хочет использовать новый язык, пока его новые версии не перестанут ломать код. Что с этим переходом в Futurice?
— Практически все новые iOS-проекты начинаются на Swift. А про те, где мы поддерживаем уже существующую кодовую базу на Objective-C, я бы не сказал, что кто-то из наших заказчиков вдруг резко начал переписывать свои существующие iPhone-приложения на Swift, там медленная постепенная миграция по мере возникновения необходимости.
Этот переходный период может быть долгим, но, зная Apple как компанию, очевидно, что за Swift будущее, и рано или поздно выбора просто не останется. Можно проследить это по всем их подобным процессам вплоть до перехода с классической Mac OS на OS X много лет назад, когда разработали Carbon специально для переходного периода.
— Вопрос в связи с вашими best practices по Android, набравшими на Хабре много просмотров. Как они появились: сначала был создан документ для внутреннего пользования, а потом его решили сделать публичным? У вас ведь, кроме этого, есть ещё похожие инициативы?
— Да, эта не единственная, но самая популярная — видимо, в связи с тем, что большинство мобильных телефонов в мире на Android.
У нас никогда не было конкретной установки «так, нам нужно написать best practices документ для нашего внутреннего использования, это будет наша догма, а потом мы можем выложить её для всеобщего обозрения». Это самостоятельные инициативы наших программистов. Когда есть желание создать такой документ, и такой документ создаётся. И поскольку мы можем быть замкнуты в своём понимании доменной проблемы, а у кого-то другого будут полезные советы, наши разработчики никогда не задумывались, делать это закрытым или нет, это сразу были публичные инициативы.
Так как у нас есть энтузиасты разных платформ, то Android best practices стали изначальной inspiration, и следом возник аналог для iOS и аналог для Windows, который со временем трансформировался из Windows Phone-документа в Universal Windows Platform-документ. Теперь Microsoft вот ещё и сделала XBox таргет-платформой для UWP, получается, что Windows Phone исчез, а Xbox появился.
А также у нас возникли инициативы про кроссплатформенной разработке, там это не best practices, а starter kits, помогающие писать меньше boilerplate: по React Native это Pepperoni, а по Xamarin — Xalami.
— А внутри самой компании ваши best practices соблюдаются неукоснительно, или есть причины от них отходить?
— С этим очень по-разному, и в этом, конечно, есть плюсы и минусы консалтинговой работы: не всегда получается применять best practices, которые ты хочешь использовать, в тех проектах, в которых ты работаешь. Это связано с очень многими факторами. Например, есть ли возможность использовать ту или иную библиотеку, вдруг какие-нибудь внутренние программные конфликты и что-то невозможно использовать. Или, например, уже существует большое количество кода, который написан определённым образом, а мы подключаемся в середине проекта. Или, например, отсутствие какого-то определённого специалиста. Так что каждый из проектов может не следовать всем best practices как догме, а использовать часть из них в зависимости от конкретных обстоятельств.
— А каков фидбэк сообщества по этим инициативам? Бывает ли такое, что люди с другой спецификой работы предлагают что-то, что вы в свои документы не готовы включать, а в итоге это приводит к форкам ваших best practices?
— Да, в этом вся прелесть open source-сообщества. Если вы предлагаете какие-то изменения и мы считаем, что они в данном контексте не вполне подходят, но в вашем собственном контексте они будут весомы и значимы — делайте свой форк и работайте над ним, это очень здорово!
Автор: phillennium
