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

С другой стороны, есть достаточно много адептов подхода “любая работа – это знания и практика, отличается только порог входа”. Поэтому они отчаянно пытаются сформировать движение “войти в IT”, по задумке которого каждый булочник или сантехник легко может освоить язык программирования и дальше жить “в шоколаде”. Думаю, только ленивый не видел подобного рода предложений и разнообразных курсов, поэтому ссылок не будет дабы не создавать лишнюю рекламу. 🙂

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

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

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

Вы заметили в предыдущем абзаце хотя бы намек на искусство? Нет! Это налаженный рабочий командный процесс, цель которого максимально снизить риски неопределенности и стать предсказуемым. Тут не место искусству. Представьте себе если бы в такой команде был бы разработчик-творец, который ждал вдохновения, переделывал свою работу много раз в поисках совершенного решения и никогда не укладывался в собственные оценки (да, искусство оно такое непредсказуемое). От него постарались бы избавиться, даже не смотря на большой талант и потенциал.

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

Резюмируя, 90% разработки – это просто работа (да, требующая больше знаний, навыков и особого мышления для успешности), а в 10% случаев (может даже меньше) есть место творчеству. И это важно понимать на всех уровнях от разработчика до менеджера. Потому что в большинстве проектов есть возможность выделять по какому-то кусочку этой самой творческой составляющей каждому члену команды, влияя таким образом на его мотивацию. И тогда все будут счастливы, наверное… 😉