В предыдущем посте мы рассказали о гибких методологиях разработки — Scrum и экстремальном программировании (если вы еще не читали о них — сделайте это!) Но на этом список Agile-методологий не заканчивается.

Бережливое производство подразумевает сокращение всех возможных потерь, экономичный и разумный подход к производственным ресурсам. Речь не только о потерях времени или растрате финансов и труда, но и нереализованном творческом потенциале сотрудников. Впервые эту систему использовала компания Toyota, а затем ее внедрили и многие другие производства. 

Для разработки ПО эту методологию адаптировали в 2003 году программисты Мэри и Том Поппендик. Они написали книгу «Бережливое производство программного обеспечения» («Lean Software Development: An Agile Toolkit»), в которой изложили принципы и практики бережливой разработки.

Принципов всего семь:

1. Ликвидировать потери.
2. Встраивать качество.
3. Создавать знание.
4. Откладывать необратимые решения.
5. Доставлять быстро.
6. Уважать людей.
7. Оптимизировать целое.

Рассмотрим их по порядку. 

Исключайте потери

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

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

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

Любую функциональность, которая не требуется пользователю, можно отнести к потерям, как и задержки в выполнении работы.

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

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

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

Как все гибкие методологии, бережливая разработка внимательно относится к потребностям и пожеланиям пользователей, поэтому сами по себе переделки не всегда можно записать в потери. По данным Мэри и Тома Поппендик, от 30 до 50 % изначальных требований к продукту к концу разработки обычно меняются. Но бывают и иные ситуации.

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

Но самой серьезной проблемой авторы считают избыточные возможности. По статистике, лишь 20 % функциональности в типичной программе используется постоянно. Около ⅔ применяется редко или никогда. Получается, что до 66 % программного кода создается бесцельно. Можно представить, каких колоссальных затрат времени и труда можно избежать, если просто не создавать эту ненужную функциональность. Неиспользуемый код не только делает программу сложнее и медлительнее — он требует тестирования, документирования, технической поддержки, доработки.

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

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

Разрабатывайте через тестирование

Для чего проводится тестирование программного кода?

Большинство разработчиков ответят: чтобы выявить ошибки и исправить их! 

И ошибутся.

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

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

Но есть и альтернативный взгляд: тестирование должно предотвращать дефекты в коде.

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

Для этого необходима дисциплина в коллективе и самодисциплина каждого члена команды — по принципам профессионализма в духе Agile. И тестирование следует интегрировать прямо в процесс разработки. Авторы методологии рекомендуют разработку через тестирование — Test driven development, или TDD. Автоматизированный тестовый модуль создается раньше участка кода, а разработка при этом разбивается на множество мелких фрагментов — и для каждого предусматривается собственный тест. Когда фрагмент создан, тестовый модуль запускается и проверяет, насколько результат работы соответствует ожидаемому. Такое тестирование выполняется максимально часто — каждый час или около того, — чтобы убедиться, что с момента прошлой проверки не появились ошибки. Если баг обнаруживается, код переделывают «по горячим следам», пока все не заработает идеально. В конце дня тестовая нагрузка запускается еще раз, а еженедельно выполняются более сложные комплексные тесты. Такая организация работы позволяет практически полностью исключить ошибки в программном коде. И финальная проверка при TDD проходит существенно быстрее.

Создавайте знание

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

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

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

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

Откладывайте необратимые решения

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

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

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

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

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

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

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

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

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

Доставляйте быстро

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

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

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

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

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

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

Уважайте сотрудников

Программист и IT-бизнесмен Джоэл Спольски в 1991 году, едва закончив колледж, устроился в Microsoft, где ему поручили разработать стратегию языка макросов на базе Basic для Excel. Он изучил требования и пожелания пользователей, но, составив спецификации, с удивлением обнаружил, что команда не спешит их выполнять. «Возможно, у них есть интересные мысли, и я должен это выяснить», — решил Спольски. Причины оказались прозаичнее: старшие и более опытные коллеги просто не хотели выслушивать мнение новичка. Один из руководителей проекта Excel, водивший дружбу с самим Биллом Гейтсом, даже организовывал совещания, на которых жаловался, что Спольски «вносит путаницу в создание стратегии макросов». 

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

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

Уважение также проявляется в том, насколько свободно каждый из специалистов может высказывать и отстаивать свое мнение. Было бы крайне неразумно сначала набрать в команду квалифицированных и талантливых специалистов, а затем навязывать им чужое мнение. Наиболее эффективный подход — обозначить коллективу задачу и ожидаемый результат, а затем предоставить свободу в поиске решения. 

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

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

Оптимизируйте целое

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

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

В этом может помочь диагностический инструмент — карта потока создания ценности (value stream map). Это график работ, который начинается с получения заказа (технического задания на разработку программы) и заканчивается передачей пользователю готового решения. Таким образом, карта начинается с заказчика и заканчивается на нем, а между этими двумя точками располагаются в порядке выполнения все технологические этапы разработки. Для каждого указывается среднее время исполнения. 

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

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



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

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

Запишем продолжительность каждого этапа, сразу отмечая время, потраченное непосредственно на создание ценности (в первой строчке) и на простои и ожидание (в нижней строке). Посчитаем: всего на создание ценности ушло 160 минут (причем большая часть — на разработку и тестирование). А вот потери превысили это время вдвое: 325 минут! На весь цикл потребовалось 8 часов — полный рабочий день, из которого лишь 2 часа 40 минут было затрачено на реальную работу. 

В данном примере очевидно, что можно исключить из цепочки диспетчера, а обязанности по санкционированию передать ведущему разработчику. Это сэкономит в среднем два часа и повысит эффективность почти на 45 %.

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

Инструментарий бережливого разработчика

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

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

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

Еще есть специальная техника бережливости, нацеленная на обустройство рабочего пространства сотрудников. Это «Пять S» (5S) — по первым буквам слов sort (сортировать), systematize (систематизировать), shine (чистить), standardize (стандартизировать) и sustain (поддерживать). Поскольку методология бережливого производства возникла в Японии, там аналогичные понятия обозначаются пятью японскими словами, которые тоже начинаются звуком «с».

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

1. Сортировать — проведите инспекцию своего стола и жесткого диска. Удалите все ненужное: старые версии программы, неиспользуемый софт, устаревшие отчеты и документы (при необходимости можно создать резервную копию). 
2. Систематизировать — разложите все «по полочкам», наведите порядок. Создайте удобную и логично устроенную структуру папок, которая позволит быстро находить нужные файлы. Ярлыки часто используемых программ и документов следует разместить на рабочем столе или закрепить в панели инструментов, редко используемые — переместить в меню «Пуск» или соответствующие подпапки. Придерживайтесь одной системы на всех компьютерах. Рабочая среда должна быть такой, чтобы каждый специалист из команды мог найти в ней необходимое, войдя в систему с любого компьютера. 
3. Чистить — мусор надо отправлять в корзину, будь то бумажный стакан из-под кофе или временный файл с черновиком документа. Наброски алгоритмов и кода, сделанные на клочках бумаги, стоит перенести в файлы, а бумагу выбросить или подшить в папку (если нужно). И протереть монитор от пыли!
4. Стандартизировать — обеспечьте единую конфигурацию программных средств на всех рабочих станциях. У команды разработчиков, трудящихся над одним проектом, должна быть установлена одна версия среды разработки и программных средств — чтобы не было проблем с совместимостью. На всех машинах должен быть идентичный набор программного обеспечения.
5. Поддерживать. Навели порядок — соблюдайте его. 

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

Бывало ли с вами такое: смотришь на пассажиров в общественном транспорте, которые лопают шарики в телефонах или залипают в «2048», и думаешь: «Простая же игра! Тоже хочу подобное сделать»? Со мной — постоянно, поэтому я решила разобраться, как создать популярную игру для смартфонов. Разведала, что по минимуму нужно знать для разработки игр, каких ошибок избегать и на что обращать внимание.

Разберитесь в азах

Чтобы понимать, как разработать концепцию игры, как выстроить игровой процесс и сделать так, чтобы пользователю было приятно играть, нужно познакомиться с геймдизайном. Понять принципы создания видеоигр помогут книги из подборки The 20 Best Video Game Design Books. Читать все, конечно, не обязательно.

В части программирования нужно уметь писать native code для платформы, под которую разрабатывается игра. По мнению руководителя мобильной разработки DataArt Алексея Рыбакова, потребуются такие знания:

1. Понимать жизненный цикл приложения для iOS/Android внутри операционной системы — что происходит при старте и телефонном звонке, какие ресурсы и когда загружаются в память.
2. Программировать на Swift/Objective-C для iOS и на Java для Android.
3. Понимать форматы звука и графики (текстур) для iOS/Android.
4. Иметь опыт программирования на C/C++ для iOS/Android на OpenGL.
5. Понимать цикл игры от создания до появления в Store.

Есть смысл посмотреть на игровые кроссплатформенные решения:

1. Unity 3D.
2. Unreal Engine.

Разработчик игр, сооснователь студии FIFTYTWO, выпустившей игры JELLIES! (5 миллионов установок на iOS) и Kenshō («Выбор редакции» в App Store и Google Play) Михаил Шагин выделяет Unity и C#: «Изучите Unity и язык программирования C# — это стандарт в индустрии. Работая на этом движке, вы будете быстро развиваться. Для Unity существует Asset Store — магазин готовых решений от разработчиков. Он сэкономит вам много времени и предоставит технологии, которые ранее были недоступны небольшим студиям и начинающим программистам. Обучаться помогут туториалы, видео-уроки и онлайн-школы».

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

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

Подумайте, для кого будет эта игра

Нужно знать своего геймера на каждом этапе разработки и поддержки игры. Кто это? Что он любит? Сколько ему лет? Из какой страны? Определиться с географией особенно важно. «Азия, Европа, Штаты, СНГ — везде есть свои нюансы в реализации геймплея, графики и других аспектов. Простой пример: в азиатских странах все герои должны быть с большими глазами», — объясняет Алексей Рыбаков.

Геймплей прежде всего

Сначала разработайте core gameplay — основу игры: придумайте, что будет делать игрок, как и в зависимости от чего игровой мир будет на это реагировать. Он должен затягивать. К остальному переходите, только когда core gameplay будет готов на 100 %.

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

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

Попробуйте применить принцип "Easy to learn, hard to master"

Это классический совет в геймдизайне: научиться играть должно быть очень просто, но достичь совершенства — крайне сложно, практически невозможно. Это и приковывает к игре. «Этот принцип особенно важен для мобильных free-to-play проектов, потому что у разработчика есть не более 10 минут, чтобы зацепить игрока. Большинство пользователей удалят игру после первой же непонятной ситуации и больше никогда не запустят приложение. Человек сразу должен понять, как играть и в чем цель», — рассказывает Михаил Шагин.

Авторство этого принципа приписывают Нолану Бушнеллу, создателю компании Atari. В оригинале он звучал так: "All the best games are easy to learn and difficult to master. They should reward the first quarter and the hundredth". Нолан Бушнелл сказал это в 1971 году в контексте игровых автоматов Atari. «В те времена игровые автоматы были в новинку, и простота игр была критичной для пользователя. Особого игрового опыта ни у кого не было, и для коммерческого успеха было необходимо, чтобы у игрока были ассоциации из реальной жизни», — объясняет Алексей Рыбаков, руководитель мобильной разработки DataArt.

Прообразом известной игры Atari — Pong — послужил теннис. В ее основу заложены простые физические принципы: угол падения равен углу отражения и подобные. Она позволяла перенести реальный опыт в компьютерную игру, поэтому ее просто было понять начинающему игроку в 1971 году. Но с ускорением мяча при переходе на уровень выше она становилась все сложнее и сложнее (hard to master) и заставляла играть вновь и вновь.

Геймдизайнер Роб Прадо придумал еще одну вариацию принципа: "Easy to learn and almost impossible to master". Алексей Рыбаков объясняет: «Идея в том, что достаточно просто собрать стаф, необходимый для получения нового игрового предмета или уровня. На примере StarCraft — легко отправить все свои войска и разрушить базу. Но по мере продвижения по сюжету у игрока должны появляться новые возможности, предметы, юниты. Все это, плюс взаимодействие с реальными игроками, приведет к тому, что игру можно будет проходить в огромном количестве вариантов. Игрок будет возвращаться к ней многократно».

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

Сделайте геймплей простым и удобным

Думайте об особенностях платформы, под которую пишется игра, и о ситуациях, в которых люди будут в нее играть. Советует Михаил Шагин: «Игровая сессия, вероятно, составит всего 10–15 минут. Большой плюс, если игрок сможет безболезненно отвлечься от игры. В этом помогут пошаговые геймплейные механики. Телефон обычно держат вертикально в одной руке — а это значит, что в вашем распоряжении будет только один палец игрока, большой. Постройте геймплей на простых свайпах и тапах — этот принцип используется в большинстве казуальных хитов. Посмотрите на Voodoo и Ketchapp — французских издателей игр, чьи установки составляют 50 % среди аркад в App Store. Такие проекты делаются за одну–две недели, что не мешает им занимать первые строчки в топе».

Не изобретайте велосипед

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

Разберитесь в продвижении игр

Подборки в магазинах приложений, реклама или сарафанное радио — что сработает для вашего проекта? Нужно понимать, что и с какой целью делаешь с точки зрения маркетинга. Михаил Шагин знал, зачем игре красивое оформление: «В Kenshō мы сделали упор на качество и визуальный стиль, что принесло нам бесплатную поддержку от платформ. Мы получили отметку «Выбор редакции» App Store и Google Play, стали «Игрой дня» в App Store. Kenshō попала в подборки и на баннеры, что и дало нам основной трафик».

Помните, что ошибка — это информация, а не повод расстраиваться

Ваша игра будет сражаться за внимание игроков с разработками от Electronic Arts, Gameloft или Rovio. Это очень сложно. Но это стоит воспринимать только как вызов. А любую ошибку — как ценный опыт. В конце концов, прежде чем Angry Birds стала популярной в 2009 году, Rovio выпустила на рынок более 50 игр и была на грани банкротства.

Технологии сегодня меняют мир быстрее, чем когда-либо. В 70-х годах искусственный интеллект существовал только в фантастических романах. 20 лет назад разработки ИИ уже велись, но успехи не были впечатляющими. Но в середине нулевых случился качественный прорыв в машинном обучении, ставший Большим взрывом для искусственного интеллекта. И сегодня множество нейросетей помогают нам фильтровать и искать информацию в интернете, обрабатывать фотографии, переводить тексты. Одна из областей, где ИИ открывает потрясающие новые возможности, — это автотранспорт.

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

Искусственный разум рулит!

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

Беспилотные авто активно разрабатываются на протяжении последнего десятилетия, а кое-где даже используются в тестовом режиме. К их созданию подключились гиганты автомобильной промышленности: BMW, Nissan, Honda, General Motors, Volkswagen, Audi, BMW и Volvo — и новые игроки на авторынке: Google, Tesla и множество менее крупных компаний. До массовых продаж беспилотных автомобилей дело пока не дошло. Автопилоты делают успехи, но до совершенства им далеко. Так что по меньшей мере в ближайшие пять-десять лет искусственный интеллект едва ли сумеет заменить — или хотя бы серьезно потеснить — опытного водителя.

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

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

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

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

Менее очевидное, чем автопилоты, применение искусственных нейросетей в автомобиле — это помощники человека, делающие вождение более безопасным.

Безопасность вождения

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

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

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

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

Что это стучит в двигателе?

Еще одна сфера применения нейросетей в автомобиле — контроль за внутренними системами.

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

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

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

Разумное автострахование

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

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

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

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

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

ИИ управляет производством

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

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

В итоге уменьшатся расходы на ремонт и замену оборудования, потери из-за простоев. А значит, будет снижаться и себестоимость продукции.

Будущее не за горами. Уже никого не удивить умным навигатором, прокладывающим самый удобный маршрут. Через несколько лет привычным явлением будут автомобили под управлением ИИ, беспилотные грузовики, автобусы и такси, а наши путешествия станут как никогда прежде безопасными, легкими и комфортными.

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

На базе Arduino, Espruino и их аналогов можно создавать технику без инженерного образования и навыков низкоуровневого программирования. Для работы с Espruino и Tessel даже С/С++ знать не обязательно — весь код вы пишете на JavaScript. Сегодня мы расскажем об Arduino-подобных платах с поддержкой JS и о том, что можно делать с их помощью.

Что такое Arduino, Espruino и аналоги?

Это платформы для создания умных вещей и роботов в домашних условиях. У платформ есть:  

Аппаратная часть  — плата с микропроцессором, к которой можно подключать внешние модули: датчики, дисплеи, электродвигатели, адаптеры Bluetooth, WiFi и Ethernet и др.

Программная часть:

• прошивка — движок платформы, который позволяет запускать JS на микропроцессоре;

• среда разработки (IDE), где мы пишем код и откуда загружаем его на плату;

• стандартная библиотека, которая обеспечивает базовый функционал: работу с интерфейсами, светодиодами, таймерами, форматами данных (типа JSON) и т.д.

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

А ещё у производителей наготове наборы-конструкторы: плата + функциональные модули и заготовки кода под конкретные задачи.

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

15 идей для проектов на базе Arduino, Espruino и Iskra JS

Если вы раньше не инженерили, первая мысль: «Что с этим делать?» Это может на мгновение ввести в ступор. Но стоит посмотреть на чужие проекты, обзоры плат и модулей  — тут же возникает громадьё идей и планов.

Вот подборка проектов, которые могут разжечь ваше воображение  — со ссылками на примеры или описание реализации:

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

2. Перчатка-манипулятор — пульт дистанционного управления для техники и игр.

3. Игрушки, управляемые по Bluetooth с планшета или мобильного устройства, в том числе голосом.

4. Металлоискатель или дозиметр.

5. Сигнализация (в том числе для холодильника) или кодовый замок.

6. Динамическая задняя подсветка для ЖК-телевизора или монитора.

7. Система управления умным домом: открытие/закрытие жалюзи, управляемая с телефона дверная задвижка и др.

8. Робот-сортировщик предметов по цвету.

9. Автополив для дачных грядок.

10. Мусорное ведро с фотоэлементом.

11. Светильник с тачскрином для управления оттенком освещения.

12. Погодный информатор с детализацией по городам мира.

13. Портативные устройства на солнечной батарее, например, метеостанция с Wi-Fi.

14. Система сбора данных о чём угодно: о погоде, статистике вашего сайта, группы в соцсети или youtube-канала.

15. Интерактивный кофейный столик с реакцией на прикосновения или с тетрисом.

Arduino и JS — это совместимо?

Если у вас есть плата Arduino, но вы хотите писать код на JS, выход есть. Фреймворки типа Johnny-Five позволяют исполнять JavaScript на Arduino и других платформах:  Raspberry Pi, Tessel 2, pcDuino, Linio One, BeagleBone, BlendMicro, Particle Photon, Intel Galileo и других.

«Костыль!» — скажет кто-то. Отчасти да. Но для маленьких проектов и прототипирования это может быть удобно.

Почему JavaScript

Опытные программисты микроконтроллеров скажут, что C/С++ быстрее и ближе к «железу». Да, это мощные, но сложные и не самые лаконичные языки. Если вы их уже знаете — отлично. Но не всем они нужны, особенно в начале. Пусть выполнение JS-кода займёт на 10-15 миллисекунд дольше — для любительского проекта это не критично. Новичку важнее получать быстрые результаты и читать интуитивно понятный код.

Основные преимущества JS:

1. Этот язык востребован: за последние 5 лет он —  самый популярный ЯП на StackOverflow. В рейтинге TIOBE за апрель 2018 JavaScript   — восьмой по популярности.

2. Это один из самых простых в изучении языков, в отличие от С/C++.

3. JS ускоряет разработку: с ним код бывает в 4 раза короче, чем на Arduino (Си)  — можно быстро реализовывать и тестировать новые задумки. Краткий и понятный синтаксис упрощает знакомство с чужими наработками и их переделку под ваши задачи.

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

5. У JavaScript есть ясные перспективы развития, в том числе благодаря фреймворкам Node.js и Vue.js. Противостояние адептов AngularJS и React — один из увлекательных эпизодов истории языка, и сколько еще таких эпизодов нас ждёт! Пока web-разработка на подъёме, знание JS будет приносить доход.

Если вы недавно увлеклись робототехникой и ещё толком не умеете программировать, JavaScript — добрый помощник.

Бонусы JS-платформ

Большинство плат Arduino по умолчанию работают с урезанной версией C++, которую мало где применишь. Платформы Espruino и Iskra JS работают со стандартным JS, так что синтаксис и изученные приёмы можно использовать в других направлениях разработки.

Ещё один плюс Espruino и JS — автоматическое подключение библиотек. Сторонние С-библиотеки нужно компилировать и подключать вручную, что отнимает время. На платформе Espruino и Iskra JS библиотеки подхватываются по команде require в коде. Указываете имя библиотеки, и при запуске программы начинается её поиск: сначала на локальном устройстве, затем в интернет-репозиториях, в т.ч. на GitHub.

Консоль в  Espruino IDE позволяет отлаживать код в интерактивном режиме: вы видите результат выполнения программы и можете тут же вводить команды и экспериментировать.

Hello, LED! Простейший код для Espruino

Вместо "Hello, World" для Arduino-совместимых устройств первым пишут программу мигания светодиодом. Примерно такую:

// Светодиод мигает с интервалом полсекунды (500 мс)

const LED = 2; //номер ввода (пина) для обращения к компоненту платы

var on = false;

setInterval(function() { // Задаём интервал мигания

   on = !on;

   digitalWrite(LED, on);

}, 500);

Выбор платформы и платы

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

Espruino

Это полностью открытая (open source) платформа: на её базе можно создавать новые платы, прошивки, средства разработки. По назначению она схожа с Arduino, но не совместима с последней технически. Нельзя комбинировать модули двух платформ или писать код для Espruino в Arduino IDE. Программы на JS вы пишете в среде Espruino IDE, которая доступна как:

• веб-приложение под Google Chrome;

• оффлайн-приложение для Windows (32-bit и 64-bit);

• исходные коды на GitHub.

В  Espruino IDE встроена консоль, где можно отлаживать код в интерактивном режиме. Вы видите результат выполнения программы, можете тут же вводить команды и экспериментировать.

Espruino поддерживает фреймворки Node.js и Electron. Первый позволяет использовать JavaScript на стороне сервера, второй  — создавать нативные приложения на JS.
Варианты плат:

• Оригинальная Espruino — универсальна по функционалу плата размером меньше кредитки (54 мм x 41 мм). Изначально работает как проводное устройство, но вы можете добавить модули Wi-Fi и Bluetooth. По умолчанию на плате есть разъём MicroUSB, слот для SD-карт и 44 пина.

• Espruino Pico — мини-плата (33 мм x 15 мм), похожая на USB-флешку. Её можно воткнуть в компьютер напрямую, удобно носить с собой, встраивать в корпуса разной формы. На её основе удобно делать измерительные приборы. Примеры проектов  — здесь.

• Espruino WiFi — плата с быстрым доступом в интернет и беспроводную сеть. Позволяет быстро запустить свой веб-сервис, собрать и обработать данные из интернета и/или наоборот  — отправлять данные исследований на сервер.

• Puck.js  — плата-таблетка в пластиковом корпусе, которая позволяет создавать миниатюрные беспроводные устройства с низким энергопотреблением. Например, можно сделать в автосалоне кнопку для перехода к следующей записи в плейлисте телефона. Вы пролистываете музыку, не отрывая взгляда от дороги.

• Iskra JS от российской компании «Амперка»  — логическое развитие оригинальной Espruino c дополнительными плюшками, о которых стоит рассказать подробнее.

Iskra JS

Плата на ядре Espruino и в форм-факторе Arduino. Вы можете использовать комплектующие Arduino и управлять полученной системой с помощью JavaScript!  Средой разработки служит уже знакомая Espruino WEB IDE. Плюс Iskra JS имеет собственные модули и платы расширения. Энтузиаст, которому понравилась одна платформа, рано или поздно захочет попробовать другую, и возможность комбинировать модули будет очень кстати.

Когда платы нет под рукой, вы можете тестировать код в онлайн-эмуляторе Iskra JS.

Подключить больше модулей поможет плата расширения, такая как Troyka Shield. Она позволяет перестановкой джампера выбирать напряжение на одной из линий питания, причем напряжение управляющей платы не важно.Вы можете  комбинировать пятивольтовые модули с трёхвольтовыми платами Arduino (Due, M0).

Tessel 2  

Плата работает с JavaScript, поддерживает фреймворк Node.js и менеджер пакетов NPM, из коробки обеспечивает работу с HTTP и web-сервером, отправку сообщений в Twitter, цветное освещение. Имеет два USB-порта для подключения внешних модулей, таких как:

• камера,

• средства воспроизведения звука,

• модуль сотовой связи (GSM),

• модуль Bluetooth LE,

• слот MicroSD.

Ещё целый арсенал модулей можно цеплять к свободным пинам на плате.

Arduino

Все варианты плат Arduino рассматривать сейчас не будем  — всё же они заточены под C++. Скажем только о нескольких интересных и компактных решениях, которые дружат с Python, а через Johnny-Five ладят и с JS.

Arduino Yún  — плата для тех, кто увлечён интернетом вещей. Может получать доступ к Google-почте, Twitter, Facebook, Dropbox и ещё сотне популярных веб-сервисов через библиотеку Temboo. Управляемый через Yún умный дом может связаться с вами, где бы вы ни находились.

Arduino Tian — плата на базе Arduino Yun, но более производительная, с Wi-Fi, Bluetooth, Ethernet-модулями и ОС Linux на борту. Поддерживает Node.js, чтобы вы могли писать на JS и front-end и back-end. Позволяет быстро развернуть сервер для видеотрансляций или оригинальный веб-сервис для дома.

Мозги  — решают!

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

 Где искать вдохновение и мотивацию? Рассказывают те, кто нашел.

Виктор Яблоков, руководитель управления разработки мобильных решений в «Лаборатории Касперского»:

Польза для людей

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

Сергей Юзефович, технический директор кешбэк-сервиса «Мегабонус»:

Спорт

— Мы мало двигаемся и много думаем. Поэтому стараюсь держать себя в форме. Прежде всего, утренняя зарядка. Раньше увлекался стрельбой из лука — помогает сконцентрироваться и расслабиться одновременно. В последнее время начал активно плавать. Если по работе возникает сверхсложная задача, плавание помогает очистить мысли, морально и психологически расслабляет, а тело, наоборот, наполняет энергией. Обычно мне хватает 30–35 минут. Затем минут на десять в финскую сауну — и просветление обеспечено.

Книги

— По специальности или мотивирующие. Из того, что читал недавно —  «The Pragmatic Programmer: From Journeyman to Master». Идеи из этой книги актуальны до сих пор. Перечитываю на английском, кстати. Также «Совершенный код» Стива Макконнелла. Это энциклопедия, в которой есть ответы почти на все вопросы. Помогают мотивирующие книги Карнеги.

Музыка

— Слушаю популярную музыку — в основном, подборки от «Яндекс.Музыки».

Экзотические страны
— Периодически надо отрываться и проводить полную перезагрузку. Поэтому люблю путешествовать по экзотическим странам. Последний раз был на Филиппинах. На местных авиалиниях облетел почти все острова — Палаван, Себу, Бохоль. Вдохновился на все 100 %.

Ренат Сарымсаков, руководитель мобильной разработки продуктов FL.ru:

Конференции

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

Данил Юсупов, инженер-программист компании ICL Services:

Общение в кругу программистов
— Это может быть как кофе-брейк с коллегами, так и конференция. И не важно, разработчики это, аналитики или проектные менеджеры. Часто у других есть мысли, которых нет у меня. Совокупность всех этих идей дает мне свежую перспективу в работе.
Работа над «toy» projects
— Очень здорово иметь «игрушечные» проекты, на которые ты можешь переключиться, когда расстраиваешься из-за рабочих задач. И совершенно неважно, какой это проект.
Приятная атмосфера
— Люблю сидеть в тихой и уютной кофейне с ноутбуком, фантазируя над своими «toy» projects. Здесь все дело в атмосфере. Особенно если в этой же кофейне фантазируют дизайнер, разработчик и архитектор. Ведь общение в кругу программистов никто не отменял :)
Изучение нового (старого)
— Учить новый язык или фреймворк для меня всегда интересно, особенно если он популярен. Удачные попытки переписать свои «toy» projects или создать новые здорово мотивируют. А еще неплохой трамплин — изучать best practices для языка или фреймворка, которым ты владеешь, и углубляться в него.
Чужие успехи
— Мне нравится искать истории успеха, смотреть видео о великих программистах или о том, как работают ребята из известных компаний. Вдохновляет библиотека Redux, которую написал Dan Abramov всего в 99 строк кода. Люблю наблюдать за креативными работами других, даже просто вбив в поисковике «Top sites 2019».

Кирилл Меженцев, программист группы разработки карты рассрочки «Совесть»:

Чувство влияния на опыт пользователей

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

Понимание, зачем я вообще программирую

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

Петр Краснощеков, руководитель управления информационных технологий Galileosky:

Биографии выдающихся людей

— Программист может найти вдохновение в биографиях выдающихся людей. Многих коллег, например, мотивирует пример Илона Маска. Он не боится ставить перед собой сложные цели, которых никто до этого не достигал.

Сергей Бурыкин, разработчик Getintent:

Развитие, деньги, конкуренция

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

Михаил Кауфман, директор проекта Galenos, ИТ-компания «ТехЛАБ»:

Осознание ценности труда

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

Александр Сибречный, ведущий frontend-разработчик TalentTech:

Сам процесс работы

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

А вы согласны, что вдохновение не ищут? Что мотивирует вас программировать?