Многие из исследователей данных изучают машинное обучение (МО) в основном с точки зрения практического специалиста. Как следствие, мы можем сосредотачиваться скорее на освоении как можно большего количества новых пакетов, фреймворков и методик, чем на глубоком рассмотрении основополагающих теоретических аспектов МО. Кроме того, в этом материале моё определение машинного обучения включает в себя обыкновенное статистическое обучение (т. е. не ограничивается глубинным обучением).

Однако пытливый, рассудительный и упорный ум может придумать множество чудесных вопросов по МО, разбор ответов на которые прекрасно способен обнаружить более глубокие его аспекты. В общем, такие вопросы могут помочь высунуть голову из кучи с картинки выше. Мы ведь не хотим целыми днями перемешивать данные — мы хотим нырнуть в глубины свойств, странностей и тонкостей методик машинного обучения и проникнуться ими…

В конце концов, в интернете хватает статей о «стандартных вопросах для собеседования по машинному обучению». Может, сделать кое-что другое, поинтереснее?

Сразу скажу: я публикую эти вопросы, просто чтобы вдохновить вас на размышления и разговоры. Готовых ответов не даётся. В некоторых вопросах есть подсказки, но они на самом деле больше для обсуждений, они не указывают на определённый ответ. Каждый вопрос заслуживает подробного обсуждения. Нет какого-то одного ответа. Некоторые вопросы заумные, а некоторые просто забавные. Приятного чтения :-) Вдобавок я вставил смешной мем после каждого 5-го вопроса…

Прикольные вопросы

• Я построил линейную регрессионную модель, показывающую 95%-ный доверительный интервал. Означает ли это, что существует 95%-ная вероятность, что коэффициенты моей модели верно оценивают функцию, которую я хочу аппроксимировать? (Подсказка: на самом деле это означает 95% времени…)
• В чём сходство между файловой системой Hadoop и алгоритмом k-ближайших соседей? (Подсказка: «лень»)
• Какая структура мощнее в смысле выразительных возможностей (т. е. она может достоверно отобразить заданную булеву функцию) — однослойный перцептрон или двухслойное дерево принятия решений? (Подсказка: XOR)
• А что мощнее — двухслойное дерево принятия решений или двухслойная нейронная сеть без активационных функций? (Подсказка: нелинейность?)
• Может ли нейронная сеть служить инструментом для понижения размерности? Объясните как.

• Все ругают и обесценивают понятие постоянного слагаемого в линейных регрессионных моделях. Назовите одно из его применений. (Подсказка: сборщик шума/мусора)
• LASSO-регуляризация сводит коэффициенты точно к нулю. Гребневая регрессия сводит их к очень маленькому, но не нулевому значению. Можете ли вы объяснить разницу между ними интуитивно, по графикам двух простых функций: |x| и x²? (Подсказка: острые уголки на графике |x|)
• Допустим, что вы ничего не знаете о распределении, откуда взят некий набор данных (непрерывнозначные числа), и вам запрещается предполагать, что это гауссово нормальное распределение. Приведите как можно более простое доказательство того, что, независимо от характера распределения, вы можете гарантировать, что ~89% данных лежат в пределах ±3 стандартных отклонений от среднего значения. (Подсказка: научный руководитель Маркова)
• Большая часть алгоритмов машинного обучения так или иначе связана с операциями над матрицами, например перемножением или обращением. Дайте простое математическое доказательство, почему мини-пакетная версия такого алгоритма МО может быть более эффективна с точки зрения объёма расчётов, чем обучение на полном наборе данных. (Подсказка: временная сложность перемножения матриц…)
• Не кажется ли вам, что временной ряд — это очень простая задача линейной регрессии с единственной переменной отклика и с единственным предиктором — временем? В чём проблема метода линейной регрессии (необязательно с единственным линейным членом, с многочленами тоже) в случае данных временного ряда? (Подсказка: прошлое указывает на будущее…)

• Приведите простое математическое доказательство того, что поиск оптимального дерева решений для задачи классификации среди всех возможных древовидных структур может быть экспоненциально сложной задачей. (Подсказка: а сколько вообще деревьев в джунглях?)
• Как деревья решений, так и глубокие нейронные сети являются нелинейными классификаторами, т. е. они разбивают пространство посредством сложной границы решений. Почему в таком случае модель дерева решений настолько интуитивно понятнее глубокой нейронной сети?
• Обратное распространение — рабочая лошадка глубинного обучения. Назовите несколько возможных альтернативных методик обучения нейронной сети без использования обратного распространения. (Подсказка: случайный поиск…)
• Допустим, что у вас две задачи — на линейную регрессию и на логистическую регрессию (классификацию). Какую из них с большей вероятностью упростит открытие нового сверхскоростного алгоритма перемножения матриц? Почему? (Подсказка: какая из них с большей вероятностью использует операции над матрицами?)
• Как корреляция между предикторами затрагивает метод главных компонент? Как с этим справиться?

• Вам поручили построить классификационную модель столкновения метеоритов с Землёй (важный проект для человеческой цивилизации). После предварительного анализа вы получаете 99%-ную достоверность. Вы можете быть довольны? Почему нет? Что с этим можно сделать? (Подсказка: редкое событие…)
• Возможно ли определить корреляцию между непрерывной и дискретной переменной? Если да, то как?
• Если вы работаете с данными по экспрессии генов, часто бывает так, что предикторных переменных миллионы, а замеров только несколько сотен. Приведите простое математическое доказательство, почему обычный метод наименьших квадратов — плохой выбор в такой ситуации, когда нужно построить регрессионную модель. (Подсказка: кое-что из матричной алгебры…)
• Объясните, почему k-проходная перекрёстная проверка плохо работает с моделями временного ряда. Что можно сделать по этому поводу? (Подсказка: ближайшее прошлое прямо указывает на будущее…)
• Простая выгрузка случайной выборки из обучающего набора данных в обучающую и проверочную выборку хорошо подходит для задачи регрессии. А что может пойти не так с этим подходом для задачи классификации? Что с этим можно сделать? (Подсказка: все ли классы преобладают в одной и той же степени?)

• Что для вас важнее — достоверность модели или качество модели?
• Если бы вы могли воспользоваться многоядерным процессором, вы бы предпочли алгоритм бустинга над деревьями случайному лесу? Почему? (Подсказка: если задачу можно делать 10 руками, стоит этим воспользоваться)
• Представьте, что ваш набор данных наверняка линейно разделим и вам нужно гарантировать сходимость и наибольшее число итераций/шагов в вашем алгоритме (из-за вычислительных ресурсов). Выбрали ли бы вы в таком случае градиентный спуск? Что можно выбрать? (Подсказка: какой простой алгоритм с гарантией обеспечивает нахождение решения?)
• Пусть у вас крайне мало памяти/места для хранения данных. Какой алгоритм вы предпочтёте — логистическую регрессию или k-ближайших соседей? Почему? (Подсказка: пространственная сложность…)
• Вы строите модель машинного обучения, и изначально у вас было 100 точек данных и 5 признаков. Чтобы уменьшить смещение, вы удвоили количество признаков (включили 5 новых переменных) и собрали ещё 100 точек данных. Объясните: правильный ли это подход? (Подсказка: на машинное обучение наложено проклятье. Слышали о нём?)

Перевод статьи Tirthajyoti Sarkar “25 fun questions for a machine learning interview”

25 прикольных вопросов для собеседования по машинному обучению was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ведущий инженер Spotify рассказывает о том, как отказался от летучек и ретроспектив и как это повлияло на работу его команды.

Примечание: ниже представлены мои ЛИЧНЫЕ убеждения насчёт Agile и командной организации. У вас всё может быть иначе.

Недавно я стал техническим менеджером продукта в своей компании, и это мой первый опыт руководства командой инженеров. Вплоть до января я был разработчиком, недовольным обилием совещаний.

Так что последние полгода я проводил эксперимент, состоящий из нескольких новых правил:

1. Нет летучкам (стендапам)
2. Нет регулярному планированию
3. Нет ретроспективам
4. Все совещания добровольны

Может показаться, что это чересчур. Но в этом безумии есть некоторая логика.

Я хотел, чтобы команда знала, что я ей доверяю. Знала, что справляться с техническим долгом, изучать новое и работать в собственном ритме — нормально. Я сформулировал задачи на квартал и положился на то, что работа будет сделана. А потом свалил в туман.

И вы таки не поверите — работа была сделана. Много работы.

Мы были чрезвычайно производительной командой, которая отвечала на изменения и великолепно справлялась с каждой поставленной задачей.

Но прежде чем подробно рассмотреть, почему эксперимент сработал, давайте взглянем на то, как действует обычная Agile-команда.

Обычная Agile-команда

Создадим вымышленную команду под названием «Суперзвёзды Agile».

«Суперзвёзды Agile» работают недельными спринтами.

Так, каждый понедельник они проводят час, планируя работу на неделю. Каждый день в 10 утра они встречаются на летучке, где каждый участник команды рассказывает, что сделал вчера, что будет делать сегодня, есть ли у него заблокированные задачи, и выступает с объявлениями. В конце недели они отводят час на ретроспективу, где обсуждают, что прошло хорошо, что прошло плохо, и создают задачи, чтобы решить найденные проблемы.

Звучит довольно логично, так?

Как этот рай производительности может разрушиться? Сейчас увидите.

1. Trello (или что вы там используете) должна быть синхронизирована с тем, что обсуждается на совещаниях. Часто это не удаётся. С ростом команды становится ещё сложнее.
2. Летучки ПООЩРЯЮТ ежедневную смену планов. Непоследовательность — отличный способ сломать разработчику состояние потока.
3. Летучки заставляют каждого участника команды быть производительным в установленном месте и в установленное время.
4. Экстраверты прекрасно чувствуют себя на летучках, планёрках и ретроспективах. Неудивительно, что технический долг — такая распространённая проблема. Разработчики не должны быть вынуждены РВАТЬСЯ погасить технический долг. Команды должны работать в устойчивом темпе.
5. Зачем поощрять обсуждение проблем раз в неделю? Нужно решать их незамедлительно, а не только на ретроспективах.
6. Спринты поощряют итеративную разработку. Это очень привлекательно для таких людей, как я, — приверженцев маленьких, сжатых запросов на включение кода, а не долгоживущих ветвей функциональности. Но это не одно и то же. Спринты поощряют приоритет функционала над техническим долгом. Часто ли вам приходилось уговаривать команду отвести целый спринт на погашение технического долга?

Что будет, если не планировать каждую неделю, не делать ретроспектив и не проводить летучек?

Прекратите проводить летучки

Летучки раздражали меня всегда. Эффект от них обычно такой: разработчики отвлекаются, чувствуют, будто их заставляют заниматься функционалом в ущерб техническому долгу, и к тому же они легко могут длиться дольше получаса.

Побочные эффекты отказа от летучек таковы:

1. Разработчики больше общаются
2. Команда лучше приспособлена к удалённой работе
3. Погашается технический долг
4. Разработчики чувствуют себя более уверенно и меньше напрягаются
5. Разработчики знают, что вы доверяете им и поддерживаете их

Моя должность в Spotify — технический менеджер продукта. Моя роль — «стоять у руля» (например, решать, над чем мы работаем). Если я каждый день меняю курс, у меня проблемы. Если вся организация каждый день меняет курс, исправить это — моя работа.

Реальность такова: я сказал своему руководству, что мы можем выполнить до конца квартала, и я предпочитаю верить, что моя команда знает, что для этого требуется, и подойдёт к задаче творчески.

Я хочу дать им как можно больше свободы.

Хочется на денёк отложить работу и посвятить его open source? Жги.

Хочется пару дней позаниматься чем-то совершенно другим? Развлекайся.

Думаешь, наш технический долг вышел из-под контроля, и хочешь это исправить? Давай дружить.

Я знаю, что ты приведёшь нас к цели, и кто я такой, чтобы повторять тебе каждый день: «ну, у нас в журнале пожеланий к продукту самые приоритетные — X, Y, Z»?

Нафиг этот шум.

Прекратите планировать каждый спринт

Регулярное планирование меня тоже всегда раздражало. Довольно редко, по моему опыту, обстановка меняется настолько радикально, чтобы всей команде понадобилось вместе разбираться, что делать. Но если уж случилась чрезвычайная ситуация, конечно же, созывайте совещание и обсуждайте на здоровье. При этом я не против планирования, я против планирования по расписанию.

Вот как всё выглядит, когда мы не планируем каждую неделю или две:

1. Разработчикам доверяют, что они будут заниматься тем, чем надо
2. Разработчиков гораздо реже прерывают, поэтому они заканчивают начатое
3. Журнал пожеланий к продукту используется как очередь задач в порядке приоритета
4. Задачи добавляются в журнал по мере необходимости, непрерывно
5. Проблемы обсуждаются сразу же
6. Планирование происходит, когда меняются планы. Усталость от совещаний снижается, и команда понимает, что это крайняя мера и обсуждаются важные вещи

Прекратите проводить ретроспективы

Представьте, что у вас роман и всё идёт великолепно. Вам непременно надо начать ходить на еженедельную семейную терапию, так?

Нет, конечно. Так нахрена нам ретроспективы каждую неделю или месяц?

Кроме того, зачем нам ждать ретроспективы, чтобы обсудить проблему или похвалить кого-то?

Вот как всё выглядит, если отказаться от ретроспектив:

1. Разработчиков не прерывают, так что они фигачат
2. Проблемы решаются быстрее
3. Стикеры и маркеры не пропадают, и вместо них мы покупаем себе обед

Вот некоторые вопросы, которые, я знаю, вам хочется задать

«Как я пойму, над чем работать?»

Хорошо: выберите пункт из журнала пожеланий к продукту.

Лучше: журнал отсортирован по приоритету, и вы выбираете из него самую приоритетную задачу.

Отлично: вы работаете над техническим долгом или над open source, чтобы дать себе отдохнуть.

«Что делать, если задача заблокирована?»

Хорошо: выберите другую задачу из журнала.

Лучше: создайте в Trello колонку «Заблокировано», переместите туда задачу, потом выберите другой пункт из журнала.

Отлично: переместите задачу в колонку «Заблокировано», выберите другой пункт из журнала и скиньте команде сообщение в Slack, чтобы они знали о блоке.

«Как отслеживать прогресс?»

Хорошо: просто спросите у вашей команды, только не спрашивайте каждый день.

Лучше: обновляйте и актуализируйте журнал пожеланий к продукту. В Trello, блин, загляните.

Отлично: больше общайтесь с командой, если поставлена высокоприоритетная задача. В остальном доверяйте команде, пока она не обманет вашего доверия и не завалит задачу. Иногда непринуждённо справляйтесь, как дела, за обедом или кружкой пива.

«Погодите. У нас всё хорошо с техническим долгом, а летучки мы проводим!»

Шикарно!

Видимо, у вас разговорчивые разработчики, рвущиеся гасить технический долг, и руководство, которому глубоко небезразлично качество разработки.

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

Вывод

Эффективные команды всё ставят под вопрос. Ещё они доверяют друг другу. И ещё они много и результативно фигачат.

Эта статья — попытка поставить под вопрос обычное поведение Agile-команд. Ежедневные летучки, планирование раз в неделю или две и ретроспективы раз в неделю или две. И это мы ещё не обсудили оценку задач.

Мой совет всем командам: не усложняйте всё с самого начала.

Летучки, планирование и ретроспективы — инструмент, а к выбору инструментов надо подходить с умом.

Перевод статьи palmerj3: “You don’t need standup”

Вам не нужен стендап was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Мой главный аргумент в следующем. Разные виды тестов имеют разную стоимость и разные преимущества. Ресурсы, которые можно вложить в тестирование, конечны. Вам нужно получить от проведённых тестов как можно больше выгоды — так используйте наиболее экономичный подход. Для многих областей, например для графических интерфейсов, отдача от других видов тестов больше, чем от модульных.

Уверенность и тесты

В статье “Write tests. Not too many. Mostly integration” («Пишите тесты. Не очень много. В основном интеграционные») и сопутствующем видео Кента С. Доддса хорошо выражены идеи бережливого тестирования. Он приводит три измерения, по которым можно оценить тест:

• Стоимость (дешёвый или дорогой)
• Скорость (быстрый или медленный)
• Уверенность (низкая или высокая, то есть «не работает щелчок мышью» или «не работает оформление заказа»)

А это — «кубок тестирования», показывающий, как Доддс предлагает распределить отведённые на тестирование ресурсы.

В отличие от «пирамиды тестирования» Фаулера, добавлено новое измерение — уверенность. Другое различие в том, что модульные тесты не занимают наибольшую площадь.

Одно из главных прозрений Доддса — в том, что важно всерьёз задуматься об уверенности, которую обеспечивает тот или иной тест.

Kent C. Dodds on Twitter

The more your tests resemble the way your software is used, the more confidence they can give you.

Окупаемость инвестиций в тестирование

Окупаемость инвестиций в сквозной тест выше, чем в модульный. Ведь сквозной тест покрывает гораздо большую площадь кодовой базы. Даже с учётом более высокой стоимости, он обеспечивает несоизмеримо больше уверенности.

К тому же сквозное тестирование проверяет критические пути, по которым следуют ваши реальные пользователи. Модульные же тесты могут проверять исключительные случаи, которые на практике происходят очень редко или никогда. Возможно, отдельные части приложения работают, но приложение в целом — нет. Вышеприведённые аргументы можно найти в статье Мартина Сустрика “Unit Test Fetish” («Культ модульных тестов»).

Далее Кент С. Доддс утверждает, что интеграционные тесты обеспечивают наилучшее равновесие между стоимостью, скоростью и уверенностью. Я подписываюсь под этим утверждением. У нас, к сожалению, нет эмпирических данных, показывающих, что оно достоверно. Тем не менее, мои рассуждения таковы:

Сквозные тесты обеспечивают наибольшую уверенность. Если бы их не было так дорого писать и так долго проводить, мы бы использовали намного больше сквозных тестов. Впрочем, хорошие инструменты, такие как Cypress, уравновешивают эти недостатки. Модульные тесты дешевле писать и быстрее проводить, но они проверяют лишь малую часть и, возможно, не самую важную. Интеграционные тесты лежат где-то посередине между модульными и сквозными, так что они обеспечивают наибольшее равновесие. Такие образом, они обладают наивысшей окупаемостью инвестиций.

Отступление: терминология

Выражение «интеграционный тест» и тем более «сквозной тест», кажется, вызывает у некоторых людей острый ужас. Считается, что такие тесты хрупки, сложны в подготовке и медленны в использовании. Тут главное — просто использовать поменьше заглушек.

В контексте React в статье Кента С. Доддса под интеграционными тестами понимается отказ от использования неглубокой отрисовки. Интеграционный тест покрывает много компонентов сразу. Такой тест легче написать, и он более стабилен, потому что не требует такого количества заглушек, и менее вероятно, что вам придётся тестировать особенности внедрения.

В мире бэкенда интеграционный тест запускался бы на реальной базе данных и выполнял бы реальные HTTP-запросы (к контрольным конечным точкам). Несложно ведь заранее набросать Docker-контейнер с базой данных и настроить его на сброс состояния после каждого теста. Опять же, такие тесты можно быстро проводить, легко писать, они надёжны и устойчивы к изменениям кода.

Покрытие кода

Другой момент: покрытию кода свойственна убывающая выгода. На практике большинство с этим согласно, так как во многих проектах устанавливается нижний порог покрытия в 80%. Даже есть исследования, которые подтверждают это, например “Exploding Software-Engineering Myths” («Подрываем мифы о разработке ПО»). Далее приведены общие рассуждения.

Даже со 100-процентным покрытием кода вы доверяете зависимым объектам. Для них, по идее, покрытие кода может быть и нулевым.

Для многих продуктов считается приемлемым, когда типовые случаи работают, а необычные — нет (“Unit Test Fetish”). Если из-за низкого покрытия кода пропустить баг, актуальный в исключительных случаях и затрагивающий 0,1% ваших пользователей, вы, наверное, не умрёте. А вот если у вас увеличится время вывода на рынок из-за высоких требований к покрытию кода, это может быть смертельно. И ещё: «то, что вы запустили функцию или запустили строку, не значит, что она будет работать для разрешённого диапазона ввода» (источник).

Качество кода и модульные тесты

Есть такое утверждение, что код, пригодный для модульного тестирования, становится более качественным. Существует множество аргументов и кое-какие эмпирические свидетельства в пользу этого утверждения, так что я освещу другую сторону.

В статье “Unit Test Fetish” говорится, что модульные тесты — противоархитектурное приспособление. Именно благодаря архитектуре ПО поддаётся изменению. Модульные тесты делают внутреннюю структуру кода косной. Вот пример:

Представьте, что у вас три компонента, A, B и C. Вы написали исчерпывающий набор модульных тестов для их проверки. Позже вы решаете преобразовать архитектуру так, чтобы функциональность B распределилась между A и C. Теперь у вас два новых компонента с разными интерфейсами. Все ваши модульные тесты внезапно утратили смысл. Часть тестового кода, возможно, получится использовать, но набор тестов в целом придётся переписывать.

Это значит, что модульные тесты увеличивают затраты на обслуживание, так как они менее устойчивы к изменениям в коде. Появляется сцепление между модулями и их тестами! Тесты — тоже модули системы. Об этом подробнее в статье “Why Most Unit Testing is Waste” («Почему большая часть модульных тестов — деньги на ветер»).

Есть и психологические аргументы. Например, если для вас ценна пригодность к модульному тестированию, вы предпочтёте проект программы, который проще тестировать, проекту, который поддаётся тестированию хуже, но в остальном лучше первого, так как знаете, что потратите гораздо больше времени на написание тестов. Дальнейшие рассуждения можно найти в статье “Giving Up on Test-First Development” («Ставим крест на разработке через тестирование»).

Статья “Test-induced Design Damage” («Как тестирование вредит проектированию») Дэвида Хайнмейера Ханссона утверждает, что ради соответствия задачам модульного тестирования код ухудшают больше ни для чего не нужной косвенной адресацией. Вопрос в том, всегда ли предпочтительны лишняя косвенная адресация и расцепленный код. Разве они ничего не стоят? Пусть вы расцепили два компонента, которые всегда используются совместно. Стоило ли их расцеплять? Можно утверждать, что косвенная адресация всегда уместна, но невозможно, по крайней мере, отрицать, что становится сложнее ориентироваться внутри кодовой базы и во время прогона.

Вывод

Философия бережливого тестирования принимает экономическую точку зрения и пересматривает окупаемость инвестиций в модульные тесты. Задумайтесь о том, какую уверенность обеспечивает тот или иной тест. Интеграционные тесты обеспечивают наибольшее равновесие между стоимостью, скоростью и уверенностью. Будьте осторожны с покрытием кода, так как слишком высокие запросы к нему, скорее всего, контрпродуктивны. Относитесь скептически к улучшению качества кода, благодаря его пригодности к модульному тестированию.

Уточню, что я не выступаю за то, чтобы никогда не писать модульные тесты. Я надеюсь, что представил свежий взгляд на тестирование. В будущем я планирую написать статью, где расскажу, как конкретно можно внедрить хороший интеграционный тест и для фронтенда, и для бэкенда.

Если вам хочется чётких инструкций, пусть и без подробностей, вот что вам надо делать. Используйте типизированный язык. Сосредоточьтесь на интеграционных и сквозных тестах. Используйте модульные тесты, только когда в них есть смысл (например, чисто алгоритмический код со сложными исключительными случаями). Будьте экономны. Будьте бережливы.

Примечания

Одна из проблем обсуждения затрат и преимуществ модульного тестирования в том, что граница между модульными и интеграционными тестами размыта. Терминология не вполне однозначна, поэтому получается, что люди говорят о разных вещах.

Нужно подчеркнуть: низкое покрытие кода не подразумевает, что багов будет меньше. Как сказал покойный Дейкстра (1969):

Тестирование обнаруживает присутствие, а не отсутствие багов.

Есть исследования, где обнаружилось, что разработка через тестирование (TDD) не улучшает показатели сцепленности и связности. TDD и модульные тесты — не одно и то же, но в контексте данной статьи это всё же интересно: “Does Test-Driven Development Really Improve Software Design Quality?” («Действительно ли разработка через тестирование повышает качество проектирования ПО?»). В другой статье, “Unit Testing Doesn’t Affect Codebases the Way You Would Think” («Модульное тестирование влияет на кодовые базы не так, как вы думаете»), анализируются кодовые базы и обнаруживается, что код с большим количеством модульных тестов имеет большую цикломатическую сложность для каждого метода, больше строк кода на метод и такую же глубину вложенности.

Данная статья была сосредоточена на том, на какие виды тестов следует распределить бюджет, отведённый под автоматизированное тестирование. Но давайте сделаем шаг назад и задумаемся, не следует ли вовсе уменьшить этот бюджет? Тогда у нас будет больше времени, чтобы думать о своих проблемах, находить лучшие решения и экспериментировать. Это особенно важно для графических интерфейсов, так как там часто нет «правильного поведения», зато есть «хорошее» поведение. Парадокс, но снижение бюджета на автоматизированное тестирование может улучшить продукт. Больше об этом: “Hammock Driven Development” («Разработка через гамак»).

Есть разница между библиотеками и кодом приложений. У первых другие требования и ограничения, где 100-процентное покрытие кода модульными тестами, возможно, имеет смысл. Есть разница между кодом бэкенда и фронтенда. Есть разница между кодом ядерного реактора и игрой. Каждый проект — особенный. Ограничения и риски в каждом случае свои. Следовательно, чтобы быть бережливыми, вы должны приспособить свой подход к тестированию под тот проект, над которым работаете.

Перевод статьи Eugen Kiss: “Lean Testing or Why Unit Tests are Worse than You Think”

Бережливое тестирование, или Почему модульные тесты хуже, чем вы думаете was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Почему разработчики ПО не могут сосредоточиться на работе, и как можно помочь им?

Может показаться, что мы заняты только этим:

Но на самом деле всё несколько сложнее.

Обычно разработчики — целеустремлённые люди, многие из них сами научились писать код в свободное время, а затем это превратилось в их работу. Подавляющее большинство (81%) также программирует в нерабочее время в качестве хобби.

Я помню, как сидел до утра и что-то писал, просто потому что чувствовал: это нужно сделать здесь и сейчас, пусть даже я голоден, устал или забросил важные дела. Не было ничего важнее, чем довести текущую задачу до завершения.

Один раз, в компании, где я когда-то работал, я перешёл в другую команду.

Мои ожидания были высоки, ведь у всех вокруг стаж был гораздо больше моего, так что я рассчитывал узнать много нового.

Однажды утром, после летучки со Scrum-мастером, где она говорила нам о том, как важны наши текущие задачи и как мало у нас времени, один из моих коллег садится и начинает кодить.

Минут через 10 он кодить перестаёт, открывает YouTube и целый час смотрит видео о том, как точить стамеску.

Да-да, часовое видео о заточке стамески!

Пока он смотрел этот ролик, его внимания требовали другие сотрудники и случайный «офисный шум». За 60 минут видео его отвлекали раз пять, так что смотрел он его часа два. Вскоре после этого он ушёл на обед.

Если бы он всё это время писал код, его бы прерывали точно так же, но на переключение с творческой задачи и обратно тратится гигантское количество энергии, и чтобы сэкономить эту драгоценную энергию, его мозг подсознательно решает вместо программирования посмотреть видео на YouTube, потому что это проще.

Истинная цена отвлекающего фактора

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

Если переключать внимание между контекстами (сложными задачами разработки и тем, на что вы отвлекаетесь), можно потерять полдня, чтобы вернуться в точку, на которой вас прервали. Писать код сложно, на поддержание сложных мыслей уходит много драгоценной энергии.

Если в вашей рабочей среде процветают отвлекающие факторы (то, что обычно называют open space), то подавляющее большинство ваших инженеров будут перенапряжены до изнеможения и выполнять процентов 10 от той работы, которую они действительно могли бы выполнить.

Возвращаемся к нашему герою со стамеской: он знает, что не сможет сосредоточиться на задаче больше, чем на 20 минут, прежде чем его прервут, так что он за неё даже не берётся. Вместо этого он занимается тем, что требует минимальной концентрации, он отвлекает себя сам, чтобы избежать энергозатратного переключения контекстов.

Значит, через 20 минут после начала рабочего дня его мозг уже истощён. Энергия — драгоценный ресурс для творческой работы, без неё ничего не будет сделано.

Но вот что странно

Мне стало любопытно, так что я поспрашивал его. Оказалось, что в свободное от работы время он идёт работать над собственными проектами и очень ими увлечён.

То есть днём, когда ему платят за программирование, он смотрит видео на YouTube о том, что никому особенно не интересно, растрачивает часы своей жизни, которые никогда себе не вернёт, и растрачивает деньги работодателя.

А когда день окончен и он возвращается домой, он приступает собственно к программированию и работает продуктивно, в среде, которую контролирует сам, не отвлекаясь по лишним поводам.

Совпадение?

Не думаю. Сейчас рабочее место — худшее место для, собственно, работы!

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

А именно, согласно The Telegraph:

Отвлекающие факторы в офисе стоят работодателям до 3 часов времени ежедневно, а это 60 часов в месяц.

Это исследование не было нацелено конкретно на разработчиков ПО, так что я полагаю, что данные для разработчиков были бы ещё более возмутительными.

Давайте подсчитаем, сколько же эти отвлекающие факторы стоят в деньгах:

20 разработчиков получают по 30 € в час = 20*60*30 = 36 000 €

36 000 € тратятся зря, каждый месяц! И это ещё если предполагать, что 3 часа — реалистичная оценка для разработчиков ПО. А я сам разработчик и могу вам сказать, что она нереалистичная.

Где же решение?

Что ж, первый шаг — осознать, что у вас проблема. Многие компании либо не осознают этого, либо им всё равно.

Следующий шаг — поговорить по душам с сотрудниками. Я прошёл через это, когда был на руководящей должности, и все ответы сводились к следующему:

• Более гибкий график
• Больше работы из дома

Возможно, вы не получите честных ответов от ваших сотрудников — все зависит от обстановки в компании. Люди сложны, групповая динамика ещё сложнее, а вы, как босс/руководитель, меняете своим авторитетом динамику внутри группы, когда находитесь с ней в одном помещении.

Но я гарантирую вам: если вы не предлагаете очень гибкий график и возможность работы из дома, вы буквально выбрасываете деньги на ветер.

Я понимаю опасения по поводу удалённой работы, но если измерять продуктивность с помощью достоверного показателя (подсказка: число строк кода — показатель недостоверный), то вы сможете увидеть: растёт она или нет. С правильной стратегией продуктивность всегда будет возрастать.

Перевод статьи Amando Abreu: “You don’t understand your software engineers”

Вы не понимаете своих программистов was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Перевод статьи John Cutler: “Is Agile the Enemy (of Good Design)?”

Интеграция

Чтобы приступить к обсуждению, вначале надо поговорить об интеграции. Интеграция — это…

действие или случай объединения в единое целое.

Частая интеграция помогает людям более эффективно решать задачи:

• Вы и я заблудились в лесу. Мы договариваемся разделиться, исследовать обстановку и периодически возвращаться на условленную поляну, чтобы интегрировать наши находки (например, я нашёл воду, вы нашли убежище).
• Учитель проводит еженедельную проверочную работу. Оценки за неё не влияют на табель, но она предназначена для интеграции на нескольких уровнях: 1) для закрепления пройденного за неделю материала и 2) для проверки прогресса учеников, на основании которой планируются будущие уроки и выявляются слабые места. Эта проверочная работа помогает «свести всё воедино» и «понять, как у нас дела».
• IKEA закладывает интеграцию в конструкцию своей мебели. Собирая мебель от IKEA, можно на время зайти в тупик (если запороть какой-то шаг), но практически невозможно довести неправильную сборку до конца, разве что если проявить недюжинную фантазию.
• Проектировщик горных велосипедов собирает/изготавливает опытный прототип и делает на нём пробную поездку. Эта поездка интегрирует ряд дизайнерских решений с реальными условиями дороги.
• Команда из пяти человек пытается периодически интегрировать вклад всех участников в проект и «посмотреть, всё ли сходится». Команда дизайнеров регулярно встречается, чтобы покритиковать друг друга и «убедиться, что их дизайнерские решения имеют прочное и веское обоснование».

Проще говоря, интеграция снижает риск и помогает нам решать задачи. И так во всём.

Agile и интеграция

Вот мысль, которая может помочь UX-проектировщикам, пытающимся разобраться в Agile.

Как и многие из подходов к проектированию, которые вам знакомы и близки, Agile основан на частой интеграции. Самоорганизующиеся команды, работа напрямую с заказчиком, ретроспективы, ежедневные планёрки, самодостаточность, сосредоточенность на «рабочем продукте» и качестве, дробление работы на небольшие части, — всё это поощряет более частую интеграцию.

Существует, однако, ключевое различие, когда речь о разработке ПО, и об этом различии стоит поговорить. Недавно я описывал Lean и Agile своей подруге, которая занимается дизайном обуви. Она отметила:

Похоже на то, как мы проектируем обувь — тесно сотрудничаем с инженерами, придумываем прототип, проверяем его, оттачиваем дизайн и подготавливаем его к производству. Дизайнер проектирует обувь: у некоторых подход не очень технический и есть только замысел и набросок, а у других — более технический. Дизайнер выбирает материалы. Директор по материалам находит и закупает их. Инженеры занимаются подгонкой, затратами, маржей, возможностью изготовления такой модели, качеством и производством.

Звучит знакомо. Разница в «готовности к массовому производству».

Обувь итерационно проектируется, а затем массово производится. Некоторые пытаются распространить эту модель на ПО. Проектировщик может разработать и собрать прототип, периодически показывать этот прототип пользователям, постепенно совершенствовать его и — когда его всё устраивает — передать «этот проект» инженерам для «сборки» или «производства». В этом процессе присутствует интеграция, но в момент передачи — лишь частичная. У прототипа «нет потрохов»… он как здание без ОВКВ, канализации, электричества, без жителей и без структурной целостности.

В отличие от опытного прототипа обуви, который можно надеть на пробежку, прототип программы на самом деле ещё не «работает». «Писать код» — это и значит заниматься проектированием ПО. Код — это и есть «проект», готовый к «сборке» (многократной) сервером сборки. Так что без кода проектирование не завершено.

И это, возможно, не страшно. Произошло обучение (и частичная интеграция), и полученные знания достаточно ценны. Множество агентств работают таким образом, потому что их заказчики хотят увидеть продукт, «точно как он будет выглядеть». Но вы навлекаете на себя ряд знакомых рисков, принимая этот подход:

• Преждевременная сходимость
• Проект технически нежизнеспособен
• На стадии проектирования рассчитывали на «большой кусок»
• Прототип «хорошо ведёт себя на тестировании», но на самом деле не удовлетворяет потребностей пользователя
• Вы упускаете возможность ранней поставки заказчику продукта, имеющего ценность (и получения знаний)
• Вы упускаете возможность раннего вовлечения инженеров в обмен идеями
• Конечный продукт не полностью воплощает то, что технически достижимо

К делу

Так вот, перейдём ближе к делу. Теоретически, предназначение Agile — предотвращать эти риски. Но Agile — как и многие другие вещи в безжалостном мире бизнеса — зачастую не может тягаться с вездесущей угрозой помешательства на результате, театра успеха и сокращения издержек. Поверьте мне… она существовала задолго до Agile.

Как объяснила моя подруга — продуктовый дизайнер ПО:

Если у меня есть выбор — начать с подробного проектирования или попытаться работать по Agile, я всегда выберу начать с подробного проектирования. Почему?

То, о чём ты говоришь, происходит редко. Всегда надо «выкатывать, выкатывать, выкатывать». Мы не переориентируемся. Мы не совершенствуем. Владелец продукта хочет только поставить «Выполнено» в Jira. Минимально жизнеспособный продукт — это оправдание, чтобы выпустить фигню и забыть о ней. Я гарантирую, что если тщательно подойду к тестированию прототипа, то у меня получится лучше, потому что его увидят пользователи. Будет не НАСТОЛЬКО замечательно, как если работать по идеальному Agile, но лучше, чем ничего. То есть у меня сложности даже с тестированием удобства интерфейса. Так что, знаешь… да, в теории всё это прекрасно, но так не бывает.

Насчёт МЖП она совершенно права. Эту идею продают командам как якобы способствующую обучению, но на практике они привыкают выкатывать продукт БЫСТРО и сокращать ВСЕ ИЗДЕРЖКИ, а потом им говорят: «да всё отлично, едем дальше!» Идеальный пример.

Agile для проектировщиков (в теории)

В теории, закономерности вроде Agile должны быть огромным подспорьем для проектировщика. Можно работать итерациями и доставлять заказчикам штуки, которые работают (и не ломаются). «Первый проход», вероятно, будет труден и сосредоточен в основном на сборе данных по ключевым вопросам. С каждой последующей итерацией «штука» будет оживать, выполненная всё более добросовестно и гладко. Необязательно выпускать её для всех пользователей — сойдёт и закрытый бета-тест — но ПО по своей природе хорошо приспособлено к быстрым итерациям и совершенствованию. Это больше похоже на проектирование услуг и управление каким-нибудь рестораном, чем на проектирование товаров для массового производства. Еда не поддельная, услуга тоже… но вы продолжаете совершенствовать.

Что важно, никто не запрещает мыслить более целостно… просто вы будете итеративно откалывать по кусочку от вашего большого целостного комка (примерно так же, как в контексте Agile подходят к архитектуре). Команда вам скажет спасибо за целостную картину.

Agile для проектировщиков (на практике)

Это была теория. На практике с помощью закономерностей Agile можно «выкатить» посредственный продукт очень скоро либо потрясающий продукт относительно скоро. Сокращаемые издержки можно сокращать быстрее. Возможности можно ловить и пускать в дело быстрее. Это такой чёрный ящик с силовыми функциями, подталкивающими к частой интеграции.

Проектировщики часто уверены, что:

• Проектировщик должен «определять и проектировать», а инженер должен печатать/собирать/строить
• За инженером нужен глаз да глаз, и без проектировщика он всё испортит
• В контексте спринтов и работы бок о бок с разработчиками ПО нет места глубокой, творческой, целостной работе над проектированием
• Agile — поскольку его проектировали не проектировщики — непременно каким-то образом настроен против потребностей проектировщика (и пользователя)
• Agile по своей структуре ориентирован на результат и поощряет работу в режиме фабрики функционала
• Agile поощряет мелочное, скучное мышление, и в итоге команда не видит дальше собственного носа
• «Технари» стремятся командовать парадом, все козыри у них на руках, а проектировщики должны защищать себя, чтобы хорошо работать

Страдание.

Agile (враг или же…)

Короче говоря, Agile — враг. По словам моего знакомого проектировщика:

По-моему, Agile, как его ни определи, на практике — именно то, с чем я воюю за эффективное проектирование в организациях, где/с которыми работаю.

На что я ответил:

С этого места поподробнее. А то в моей работе это — традиционные взгляды менеджеров среднего звена, косвенные метрики, театр успеха, управление по целям, фиксация на результате, недальновидность, недостаток измерений, традиционный подход к финансам и бюджету, противоречие между фокусом на человеке или на команде, короткие контракты, недостаток психологической безопасности и ментальность тянитолкая. Agile тут ни при чём.

А другой проектировщик поддакнул:

Давайте не будем толочь воду в ступе. Враг и настоящих Agile-энтузиастов, и специалистов по UX/проектированию в 2018-м — это, как говорит Джон, недальновидное, ориентированное на результат мышление, подстёгиваемое сосредоточенностью на краткосрочных финансовых целях, а также весь комплекс культурных последствий этого мировоззрения.

Я предвзят. Я согласен.

Что же теперь?

Так каково же наше положение? Проектировщики имеют право беспокоиться. По крайней мере, в каскадной модели никто не орёт «выкатываем» раньше времени, посреди проекта. У проектировщика есть время, чтобы работать, а не скакать по конвейерной ленте спринтов. А так как искомую «штуку» собирают большим куском, у них есть время на целостный подход к задаче проектирования с самого начала. «Хороший» каскад всегда лучше злоупотребления Agile.

«Хороший» каскад всегда лучше злоупотребления Agile.

Что же можно сделать? Я вижу два широких подхода:

1. Размежеваться
2. Расти над собой всем вместе

Размежеваться — значит продвигать процессы, где проектировщики окапываются выше по течению, чем разработчики ПО (старое доброе «проектирование, потом сборка»). В среде, погрязшей в работе на результат, это не самая плохая идея. Может случиться хороший проект. Разработчикам, возможно, даже понравится, ведь умеренно хорошее проектирование всегда лучше фигового.

Расти над собой всем вместе тяжелее. Это значит…

• Открыться всем возможностям частой интеграции.
• Прочно закрепить кроссфункциональные команды по разработке продукта.
• Продвигать качественное проектирование в контексте кроссфункциональных команд.
• Продвигать такой итерационный подход, который выгоден пользователю (не останавливаться, когда тестирование успешно пройдено и руководство требует перехода к следующему проекту). Результаты важнее итогов.
• Способствовать совместному проектированию с разработчиками ПО и другими заинтересованными лицами.
• Ограничивать работу «против течения» — вместо этого нужно стремиться сотрудничать с другими участниками команды и пройти этот путь вместе.
• Вникать и приспособляться в сотрудничестве с участниками своей команды, подстраивать свои рабочие договорённости и процессы под достижение наилучших результатов (и довольных участников команды). Раз вы проектировщик, то, вероятно, можете с этим помочь.

Вывод

В заключение я хотел бы поделиться личным наблюдением. Единственный способ побороть недальновидность и сокращение издержек — показывать прекрасные результаты. Если результат работы не ощущается, то, как её ни делай, появится чувство «движения к провалу» и отступление обратно к фиксации на результате. Любой «улучшенный» способ работать чреват злоупотреблением.

Я считаю, что проектировщики как никто другой способны помочь команде разработчиков ПО «расти над собой», прекрасно выполняя свою работу и помогая каждому стать (чуть-чуть) лучшим проектировщиком.

Что же касается ненависти проектировщиков к Agile… могу сказать, что Agile представляет собой некие закономерности, которые в определённый момент (и в определённом контексте) «сработали». Уверен, проектировщики могут понять, каково черпать вдохновение из многих традиций, чтобы разобраться со своей задачей. Акцент на частой интеграции, надеюсь, вам знаком. В Agile ключевой момент — использование этой частой интеграции для достижения высокого качества, а не посредственности.

Перевела Алиса Толстова.

Agile - враг (хорошего проектирования)? was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Перевод статьи Erik P.M. Vermeulen: How to Be Successful Now & In the Future

Цифровые технологии — писк моды. Это, положим, очевидно. Количество связанных с ними событий растёт с поразительной скоростью.

Каждый хочет узнать побольше о новых технологиях и их влиянии на его жизнь. У каждого есть мнение о них. Кто-то их обожает, а кто-то (до сих пор) не доверяет им.

Мне это стало совершенно ясно (в очередной раз) на конференции в Японии на прошлой неделе.

Наши жизни всё больше и больше вращаются вокруг цифровых технологий. Алгоритмы и соцсети уже сегодня «подавляют» нашу экономику, общество и культуру. Они всё в большей степени определяют, как мы работаем, общаемся и знакомимся. За каждой гранью нашей жизни сегодня стоят технологии.

Как это обычно бывает, не все участники того мероприятия в Японии были в этом убеждены. Они цепляются за «старый мир» и отрицают возможность изменений. Что интересно, они ссылались на непостоянство Bitcoin и потребление энергии его блокчейном в доказательство своего мнения. Было ясно, что они просто не желают верить в оцифровку мира.

Но они неправы. «Цифровое преображение» реально и происходит повсюду вокруг нас.

Пути назад нет. И нам всем следует задуматься о том, как технологии влияют на нашу жизнь и что нам с этим делать.

И дело тут не в понимании всех технических деталей, стоящих за цифровыми новшествами. Однако нам непременно нужно изменить своё мировоззрение и сообразить, как мы можем использовать огромные возможности, создаваемые цифровыми технологиями.

Если использовать их с умом, цифровые технологии могут сделать нас счастливее и успешнее.

Они способны «децентрализовать» и наделять нас большей автономией и выбором. Вот что такое «цифровое преображение» — культурный сдвиг, касающийся каждого из нас.

Так как же нам изменить своё мировоззрение?

Как нам развить «цифровое мировоззрение», необходимое, чтобы взять всё лучшее от нового мира?

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

Вот что я имею в виду.

Осознавать «риски» цифровой культуры…

Конечно, все мы видим «опасности», сопровождающие новые цифровые технологии и цифровую культуру, выросшую вокруг них.

Задумайтесь о некоторых возможных рисках, создаваемых этими технологиями:

• Мы тяготеем к излишней концентрации на краткосрочных целях. Например, мы сосредотачиваемся на мгновенном наборе «читателей», «лайков» и «положительных комментариев», чем больше — тем лучше. И да, это бывает очень увлекательно. Но обратная сторона такого «быстрого выигрыша» — в падении интереса к разработке осмысленных материалов или опыта, который мог бы вдохновить других или оказать благотворное влияние на сообщество или человечество.
• Мы постоянно занимаемся нездоровыми сравнениями с другими. Мы используем «читателей» и «лайки» как мерило успеха своей деятельности относительно окружающих, и мы привыкаем бояться «отрицательных комментариев». Отрицательные комментарии — причина, по которой некоторые из моих коллег и друзей опасаются соцсетей.
• Мы подвергаемся рискам «стадного поведения». Мы следуем за «толпой» в погоне за признанием или принятием окружающих, и мы лишаемся самобытности, теряя из виду себя, чтобы «вписываться».
• Цифровые технологии часто «очаровывают» нас и превращаются в помешательство, захватывающее всю нашу жизнь. Мы оказываемся в ловушке «времени перед экраном» и развиваем нездоровую зависимость (иногда подобную наркотической) от наших устройств.
• Иногда у нас даже развивается зачастую неоправданное ощущение собственной важности или заслуг на основании признания, полученного нашей «онлайн-маской».

Разумеется, я здесь обобщаю. Но, думаю, каждый — если он честен перед собой — может понять эти риски. Они постоянно заманивают любого, кто участвует в новой цифровой культуре.

Одним из возможных ответов на эти риски может быть «отторжение» технологии и отказ от взаимодействия с цифровым миром.

Или можно подождать, пока производители технологий не найдут «техническое» решение некоторых из этих проблем. Пример — технические меры, разработанные, чтобы ограничить время перед экраном и снизить риск излишней зависимости от цифровых устройств.

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

А эти цифровые возможности более чем реальны.

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

И подходить с умом к цифровым технологиям

И всё же я думаю, что нам необходимо подходить к новым технологиям с умом. Нам нужно «разобраться в них», чтобы снизить риски и максимизировать возможности для построения и создания такой жизни, которая будет приносить удовлетворение лично нам.

Также я убеждён, что это подразумевает развитие «цифрового мировоззрения» нового типа, над которым постоянно нужно работать. Нам всем нужно стать активными и позитивными пользователями технологий, создающих новые возможности, а не жертвами таких вредоносных процессов, какие описаны выше. И это относится ко всем нам (и к молодым, и к пожилым), а также к бизнесам.

Так как же нам в них разобраться?

Как подойти с умом к нашим взаимоотношениям с новыми технологиями?

Каковы важнейшие элементы нового цифрового мировоззрения?

Вот пять идей для начала обсуждения:

№1 — набирайте опыт

Нам нужно гнаться за моментом и накапливать как можно больше нового опыта. Именно через новый опыт можно выстроить лучшее ощущение того, «кто мы» и «что мы хотим делать со своей жизнью». И в этом отношении не следует чересчур концентрироваться на результатах — думать нужно о процессе.

№2 — экспериментируйте

Нам нужно «учиться, делая». То есть практиковаться и улучшать свои навыки, чем бы мы ни занимались. Разумеется, следует быть осторожным со стремлением к бесконечному самосовершенствованию, но подобная экспериментальная жизнь — единственный путь к обнаружению и созданию новых возможностей.

№3 — будьте терпеливы

Нам нужно быть упорными и последовательными. Надо избегать разочарования и досады, когда что-то идёт не так, как мы надеялись и планировали (например, когда профиль в соцсети не привлекает ожидаемого количества посетителей). Продолжать заниматься выбранным делом может быть нелегко, но это — лучший вариант.

№4 — сотрудничайте

Нам нужно осознать важность совместного, разделённого творчества. Цифровой мир платит сторицей «командам» за «командную работу».

№5 — выстраивайте сообщества

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

Все вышеперечисленные стратегии связаны с коммуникативными навыками, о чём я писал выше.

И напоследок

В цифровую эпоху технологии действительно становятся частью нашей личности. В этом смысле мы теперь все станем «киборгами». Но не нездоровым образом, а таким, который расширит наши возможности и создаст больше путей к удовлетворению собственной жизнью.

Вот, например, «социальные сети». Это идеальный способ стать заметным в нашем быстро меняющемся мире. Однако на удивление мало моих учеников относятся к соцсетям серьёзно. Да, у них есть профиль на Facebook или Instagram, они часто делятся какими-то событиями из своей жизни, но не прилагают серьёзных усилий к построению личной истории или бренда, который помог бы им в будущем.

Кроме того, всем нам нужно быть скромными и понимать, что мы сами постоянно учимся. Благодаря взрывному росту инноваций, «цифровую жизнь» невозможно освоить в совершенстве.

Ориентироваться в новом цифровом мире бывает непросто, но если «разобраться» в нём и вести себя умнее, выгода очевидна.

Наконец, одно из лучших свойств нового мира: возраст, предыстория и прошлый опыт больше не имеют такого значения, как раньше. Всё решает «цифровое мировоззрение». И именно это я стремился сообщить слушателям на том мероприятии в Японии.

Правильное мировоззрение действительно создаёт значительный потенциал для свободы, счастья и нового уровня человечности для всех нас.

Как быть успешным сейчас и в будущем was originally published in NOP::Nuances of Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.