Думай як програміст: чому вашій компанії потрібна своя мова

Думай як програміст: чому вашій компанії потрібна своя мова

Сьогодні більшість компаній вважають, що проведення аналізу — це написання формул в таблицях. Але у бізнесі багато що помінялося з моменту винаходу таблиць. Сьогодні організації повинні мислити в масштабах мільйонів індивідуальних клієнтів, а не тільки декількох сегментів, а способи рішення проблем мають бути такими, щоб їх можна було використати не один раз. Треба застосовувати останні досягнення в області машинного навчання і штучного інтелекту. Словом, компанії повинні навчитися писати код, а не формули, оскільки майбутнє праці пов'язане з умінням мислити не лише аналітично, але і алгоритмічно.


Така зміна перспективи дуже важлива. Більшість компаній сприймають код як щось, сховане в загадкових куточках ИТ-відділу, або як прерогативу обраної групи фахівців з обробки даних. Але організації, яким вдалося перекласти питання аналізу мовою програмування, часто ростуть і впроваджують інновації швидше за інших.


Опора на програмування принесе користь організаціям в трьох стосунках.

По-перше, мислення програміста дозволяє чітко відділяти дані від їх аналізу і покращувати кожного з компонентів. Коли дані і аналіз чітко розділені, різні відділи можуть зосередитися на одному аспекті, що призводить до швидшого прогресу.

По-друге, код набагато простіше поширювати і використати повторно. Прийнявши ключові принципи розробки програмного забезпечення, такі як контроль версій, корпоративні команди можуть працювати ефективніше і колективно, оскільки оновлення файлів відстежуються впродовж усього терміну їх служби, а зміни можна легко відмінити.

Нарешті, код підходить як для простого, так і для складного аналізу. Прорив в технологіях машинного навчання і штучного інтелекту реалізований у вигляді коду, і завдяки копіюванню коду, який використовують дослідники, люди можуть отримати доступ до найсучасніших методів аналізу швидко і безкоштовно.

Так що повинні зробити менеджери, щоб перенаправити працівників від формул до коду? По нашому досвіду, провідні компанії здійснюють три практичні кроки.

Руйнування "Вавілонської вежі". Спілкування — це запорука для співпраці. Мовні бар'єри створюють найсильніші перешкоди для ефективного обміну ідеями. Це стосується не лише обміну текстами або розмов, але і коду. Необхідність подумки переписувати ідеї на декількох мовах програмування вимагає додаткових знань.


У чому рішення?

Компанії повинні вибрати не більше двох, а в ідеалі одна мова аналітичного програмування в якості стандарту для усієї компанії — мова, на якій можуть "говорити" все. Проясню: жоден варіант не може бути ідеальним для будь-якої ситуації, і розумні люди можуть не погодитися з вибраним стандартом, тому треба готуватися до труднощів в управлінні змінами. Але можна заспокоїти скептиків, погодившись переглядати стандарти кожні декілька років.

В якості першого кроку добре б вивчити, що роблять експерти. Зрозумійте, що в ужитку у відділах, що займаються аналітикою, — наприклад, фінансовий відділ або маркетинговий. Одна глобальна компанія, що надає фінансові послуги, скористалася саме цим підходом і з'ясувала, що її провідні фахівці з даних зупинилися на мові Python.

Люди, які витратили роки, намагаючись відточити свої прикладні математичні здібності, мислитимуть консервативно, коли мова зайде про вибір інструментів і методів, і, ймовірно, прийдуть в захват, якщо їх неофіційні стандарти стануть офіційними. Ці люди стануть світочами і учителями в організації, тому посилення їх авторитету і впливу — це здоровий підхід і корисна стратегія управління талантами.

Створення сховищ із загальним кодом. Після того, як люди перекладуть свої ідеї однією мовою, треба створити репозиторії із загальним кодом і бази знань — за прикладом відкритих співтовариств. Це дозволить людям швидко і легко ділитися своєю роботою, і нікому не доведеться наново винаходити колесо.

Як і у разі будь-якої централізованої системи, треба ретельно продумувати питання безпеки і дозволів, конфіденційності і інтелектуальної власності. Але завдяки репозиторіям із загальним кодом декілька відділів однієї організації можуть використати один і той же код для вирішення схожих проблем. Наприклад, маркетингова команда банку хоче знайти клієнтів, які подумують про рефінансування іпотеки, щоб запропонувати їм певні продукти, а фінансовому відділу можуть знадобитися дані про тих же людей для проектування бюджетів і рахунків. Формулювання проблеми однакове в обох випадках — скільки людей і хто з них здатний до рефінансування? — то чом би не використати один і той же код, щоб отримати відповідь?

Щоб швидко почати роботу, треба вибрати проект, створити сховище коду і запросити більше учасників. Платформи для спільного використання коду, такі як GitHub і Bitbucket, легко з цим справляються. Корисно розпочати з широко застосовних суперечок проектів, що не викликають, таких як сегментація клієнтів або розрахунок цінової еластичності.


Деякі компанії, скажімо, Google і Microsoft, діляться своїм кодом публічно. Один оператор зв'язку опублікував частину своїх внутрішніх розробок, що дозволяє компанії користуватися допомогою людей, навіть не працюючих в ній, і це потенційно може стати стандартною платформою для телекомунікацій.

Зробити код звичайною частиною бізнесу. Компанії, які хочуть отримати максимальну віддачу від просунутої аналітики, стикаються із складним завданням: треба зробити моделювання на основі коду правилом, а не виключенням. Це повинно стати справою такою ж буденною, як прикріплення таблиці до електронного листа. А для цього необхідно змінити не лише підхід, але і звички. Але є прагматичні стратегії, щоб прискорити це зрушення.

По-перше, треба донести чіткі і конкретні очікування на усіх рівнях, від топ-менеджерів до рядових співробітників або інвесторів. По-друге, треба дати співробітникам час, щоб навчитися. Сьогодні є маса можливостей, доступних як для компаній, так і для приватних осіб, починаючи від учбового табору і закінчуючи масовими відкритими онлайн-курсами(MOOC) і індивідуальним навчанням. По нашому досвіду, будь-який з цих варіантів може бути успішним, якщо людям дають час на навчання без відриву на повсякденну роботу. Стати компетентним програмістом — зовсім не непосильне завдання, і менеджерам не варто думати, що їх підлеглі не впораються.

По-третє, люди повинні знати, до кого звернутися по допомогу. Страх перед навчанням значно знизиться, якщо ця допомога буде своєчасною і актуальною. І люди, які на крок попереду інших, можуть стати наставниками для початківців. Менеджери, що пред'являють підлеглим нові вимоги, мають бути готові самі допомагати їм — мало що дає сильніший стимул для вивчення чого-небудь, ніж розуміння, що вам доведеться навчити цьому інших.

Але не треба боятися. У цьому новому світі є багато підказок — популярні відповіді, знайдені через пошукову систему, учбові ресурси і тому подібне. І іноді в цих відповідях будуть посилання на великі репозиторії з відкритим початковим кодом з рішеннями всіляких проблем.


Пабліш Чарт