«Она либо есть, либо ее нет». Нужна ли креативность в программировании

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

Тем не менее LinkedIn уже второй год подряд называет креативность самым востребованным soft skill’ом. Компаниям критически необходимы люди, которые смогут привнести инновационность в любую работу — и особенно в разработку.

Так ли важно творчество в программировании, где оно проявляется и как его развивать — об этом мы, команда HR Marketing Terrasoft, спросили у шести опытных разработчиков компании.

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

Иллюстрация Алины Самолюк

Творчеству все люди покорны

Многие бизнес-лидеры и эксперты по развитию креативности отмечают две вещи:

• никто достоверно не знает, что же значит знаменитое «think outside the box»;
• большинство верит, что креативные решения — это удел узкого круга избранных.

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

Давайте определим, что такое креативность с помощью критериев Ереза Цалика, фасилитатора в сфере инноваций. В своём выступлении он выделяет несколько признаков:

• Инновационные идеи используют только существующие ресурсы. То есть, если перед вами стоит тарелка с лапшой, а приборов нет, вы находите способ съесть её с помощью подручных средств. В программировании это часто выражается в поиске компромисса время/цена/качество, поэтому команды фокусируют креативность на решении задач бизнеса. Некоторые собеседники отмечали, что большинство проблем программирования можно решить покупкой новых ресурсов. Но беда в том, что цена устройств экспоненциально растет с каждым улучшением. Поэтому нужно использовать именно существующие ресурсы.
• Креативные идеи решают очень конкретную задачу. По этой причине все маркетологи мира ищут инсайты — специфический конфликт между «хочу» и «могу», который удивительным образом решается рекламируемым продуктом. То же происходит и с разработкой: согласитесь, программирование бессмысленно, если это просто никому не нужный код. Это как строить мост, которым не будут пользоваться.
• Они просты и прекрасны. По словам Цалика, увидев такое решение, вы сразу жалеете, что сами до него не додумались. В этом замечательный парадокс инновационных идей: программисты каждый день решают множество задач, но назвать решение инновационным никогда не могут, поскольку для них оно очевидно.

Кради как художник, или Где здесь креативность

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

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

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

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

Фабрика создания идей

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

Брейншторм

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

Пример: команда Service Creatio в течение технического дня создавала подходы к структуре работы чат-ботов. Изначально рассматривали вариант реализации на классах, так как он казался самым простым и рабочим. Кто-то из команды предложил посмотреть в сторону бизнес-процессов и поддержания парадигмы low-code. В результате получили классы-конвертеры сообщений ботов и передачу их на бизнес-процессы.

Метод Дельфи

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

Пример: в команде используют SonarQube — статистический анализатор кода, который помогает сделать его более качественным. Проблема стандартной версии в том, что она анализирует только одну ветку кода, а значит в момент слияния (мёрджа) основной ветки и ветки с внесёнными изменениями есть риск получить сообщение об ошибке. Ребята искали решения отдельно друг от друга: кто-то сразу писал чисто, кто-то анализировал локально, а кто-то нашел плагин, который позволяет проанализировать все ветки до мёрджа. Команда сэкономила время, деньги и получила качественный код.

Метод «пяти почему»

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

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

Непризнанные творцы

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

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

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

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

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

Как программисту прокачивать креативность

С креативностью, как и с любым навыком, главное — желание и практика. Вот несколько полезных лайфхаков:

• Изучайте теорию и шаблоны. Чтобы создавать что-то новое, нужно понимать, что было создано до вас. При этом в случае с программированием вы должны четко понимать, как это конкретное решение работает и какие у него есть плюсы и минусы.
• Старайтесь смотреть на проблему с разных точек зрения. Например, можно использовать метод «шести шляп» или же попросить Scrum-мастера или Project-менеджера выступить фасилитатором на брейншторме. Один из техлидов акцентировал внимание на умении понимать, что представлял себе человек, когда предлагал свою идею. Все люди разные и образное мышление работает таким образом, что одни и те же слова рисуют абсолютно разные картинки в умах людей.
• Не переставайте работать над проблемой после первого рабочего решения. Инновационные идеи не приходят по расписанию. Продолжайте обдумывать варианты, озвучивать и записывать их. Постоянно спрашивайте себя «А это точно лучшее решение из всех возможных?».
• Создавайте благоприятную среду. При постоянном аврале и стрессе сложно войти в состояние потока и выдать что-то инновационное. Нужно настраивать процессы и организовывать свой режим дня таким образом, чтобы у вас регулярно появлялись возможности и время для креатива. Например, в департаменте разработки low-code инструментов плюсы и минусы идей принято челленджить и штормить и на дизайн-сессиях, и на code review, и на архитектурных постановках.

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

Хотим поблагодарить Диму Павлова, Лешу Юшко, Сашу Гилевого, Ваню Шупеня, Полину Михайленко, Сашу Бондаренко за время, мнения, инсайты и примеры из жизни.