Как понять, чему учиться взрослому: 7 моделей для профессионального развития

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

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

Заполнять таблицы или составлять их

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

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

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

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

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

Результат без узнаваемости — не результат

Есть исследователь по имени Альберт-Ласло Барабаши, специалист по теории сетей. Он много лет изучал успех как научную категорию — начал с науки, потом расширил модель на спорт, музыку и бизнес. И пришёл к выводу, что результативность работает вместе с сетевым эффектом. Человеку нужно хорошо выполнить свою работу и сделать её заметной для подходящей аудитории.

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

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

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

Из этих двух факторов складываются четыре ситуации.

1. Хороший результат плюс широкая известность — это ChatGPT от OpenAI и DeepSeek: оба продукта были качественными сами по себе, и оба стали настолько заметны, что DeepSeek на время уронил стоимость акций других AI-компаний.
2. Хороший результат без известности — судьба пенициллина, который открыли, но начали массово использовать в медицине только спустя десятилетия: результат был, а сетевого эффекта долго не было.
3. Слабый результат без известности проходит незамеченным, и в этом нет большой трагедии, просто вас никто не заметил. 
4. Слабый результат с раздутой известностью на первый взгляд выглядит успехом, но долго на нём не продержаться — рано или поздно разница между шумом и содержанием становится видна.

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

Дальние знакомые полезнее близких друзей

Рид Хоффман, один из основателей LinkedIn, вывел на своих данных не самую очевидную закономерность про нетворкинг.

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

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

Большая система вырастает из маленькой рабочей

Закон Галла звучит просто: любая крупная работающая система выросла из системы поменьше, которая тоже работала. Идея настолько очевидна, что кажется банальной, но именно её обычно игнорируют, когда запускают крупные проекты с нуля. МТС в своё время запустила собственный сервис для видео как конкурента YouTube — и закрыла его примерно через полтора года. Причин там, скорее всего, было несколько, но нарушение этого принципа точно было одной из них: систему попытались построить сразу большой без этапа небольшой рабочей версии, чтобы протестировать спрос.

Если компания или продукт уже работают в небольшом масштабе, вырасти можно двумя путями:

1. Развивать то, что уже работает;
2. Объединиться с другой системой, которая тоже работает. 

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

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

Учишься быстрее, когда учишь сам

Расселл Акофф, один из основоположников системного подхода в менеджменте, много занимался не только бизнесом, но и образованием. У него есть интересное наблюдение: название системы редко совпадает с тем, что она на самом деле делает.

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

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

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

Если нечего предложить сейчас — предлагай будущее

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

Логичный первый шаг — пойти к тем, у кого этот ресурс есть, и попросить. Проблема в том, что в моменте предложить обычно нечего: то, что делает проект, начнёт приносить пользу и деньги позже, а не сейчас. Банк в такой ситуации спросит про залог, а у только что созданного стартапа заложить особо нечего — банку это неинтересно.

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

DevOps — это не только про IT

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

DevOps придумали именно для того, чтобы убрать этот разрыв: разработку и эксплуатацию свели в один процесс, чтобы люди, которые пишут код, и люди, которые его поддерживают в работе, действовали заодно, а не перекидывали проблему друг на друга. Это буквально перевод названия должности: development — создание нового, operations — поддержание уже созданного в рабочем состоянии.

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

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

Куда идти, если хочется собрать это в систему

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

Как раз на этом строится онлайн-магистратура МФТИ+Сколково «Технологическое предпринимательство» при кафедре технологического предпринимательства: вебинары с преподавателями, персональный ментор и около 1000 часов практики над собственным проектом — своим или корпоративным. Средний возраст студентов — 34 года: продакты, CEO стартапов, руководители R&D. На выходе — диплом магистра МФТИ государственного образца, плюс отсрочка от армии и выход на сообщество Физтеха.

Приём заявлений идёт до конца августа, старт обучения — 1 сентября, для поступления нужно пройти собеседование и вступительное испытание, но его можно обойти: если пройти онлайн-школу «Предпринимательское планирование» — она даёт минимальные проходные баллы в магистратуру без экзаменов. Программа по семестрам и условия — на techpredonline.ru, общая страница кафедры со всеми программами — на сайте МФТИ.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJmj8K3