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

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

Тем не менее 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, и на архитектурных постановках.

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


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

👍НравитсяПонравилось16
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как программисту прокачивать креативность? Изучайте шаблоны :)

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

Тут є два моменти:
1) Найчастіше в ІТ під креативністю розуміється не те, що людина буде для кожного завдання придумати з дюжини рішень (на це просто немає часу), а те, що вона буде пропонувати нові ідеї для поліпшення продукту. Причому як в технічному, так і в функціональному плані
2) В аутсорсингу, де все жорстко розплановано, від весляра потрібне вміння виконувати завдання якісно і в строк. Тут креативність просто не знадобиться.

Завжди можна прийти в продуктову компанію, тут креатив просять і за результати дякують)

Не понимаю о чём статья. Вам нужна креативность? Без проблем
1. Найдите в чём вы её измеряете
2. Платите за этот скилл дополнительно

Пока-же не понятно чего хотим, но платить за это не хотим сильно

В ІТ, як і всюди в бізнесі, платять тільки за кінцевий результат

В чём конечный результат креативности? У меня есть таски в джире, креативности — нет

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

Тот 1% софта, что требует креативности в разработке — не отдаётся на аутсорсинг. Т.к. креативные вещи, как правило, составляют часть тщательно-оберегаемого «ноу-хау».

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

Если компании надо РАБ а зачастую это именно так то креативность не надо

А если ты решил создать свой бизнес без этого не как!

никто достоверно не знает, что же значит знаменитое «think outside the box»

Это когда посмотрев на твой способ решения проблемы/задачи/ситуации — >50% людей скажут: «Офигеть! А я бы до такого не додумался». Или не скажут (чтобы не терять авторитет), но хотя бы подумают.

Она либо есть, либо ее нет

Научиться можно всему — даже делать изобретения:
Теория решения изобретательских задач
ru.wikipedia.org/...​ия_изобретательских_задач
P.S. Плюс ВУЗовского инженерного образования в том, что я знаю о ТРИЗ. А минус работы на галерах что за много лет мне ни разу не потребовалось работать инженером и тем-более что-то изобретать.

Математика кажется скучной:

Якось вам не так її готували.

Математика дуже потребує як раз «out of the box» мислення. Адекватний викладач завжди готує завдання так, що кожна наступна задача вимагає вийти за рамки всіх попередніх — придумати щось, чого раніше не знав і не бачив — чистої води креатив.

на жаль, в більшості випадків шкільна математика так і виглядає, як її описала ТС:

вспоминаются нудные школьные уроки (зачитываем правила вслух, решаем на доске пример, «садись, три с плюсом» и поехали дальше)

хороших вчителів мало, як результат потім маємо, що коли випускники беруться за ЗНО з математики, то 30% не може розв’язати задачі рівня «6 конвертів коштує 3 гривні, скільки коштує 12?»

«У вас есть 2 ведра — на 3 литра и на 5 литров. Вопрос: сколько у вас ведер?»

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

В целом да, но на галерах нет

Это зависит от проекта, можно и на галерах. Есть разные заказчики с разными хотелками и разным видением.

В целом нет, а на галерах и подавно

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

В геймдев на написание движка на сях и opengl.

Чужого движка. Без документации.

Абы код был не сильно креативным)))

Подписаться на комментарии