Можно ли стать программистом без профильного образования? Нет, это не реклама очередных онлайн-курсов. Кандидат физико-математических наук Андрей Грицевич много лет назад, когда деревья были больше, трава зеленее и еще даже не вышел первый Angular, ответил для себя на этот вопрос однозначно: а почему бы и нет! И самоучкой пошел в UI. Сегодня он руководит отделом разработки Центра продуктов Dozor в нашей компании. Андрей уверен, что только счастливые люди выполняют свою работу хорошо, а значит, надо помочь им стать такими. Как этого добиться? Не бояться внедрять современные инструменты. Какие-то проблемы ушли в прошлое благодаря внедрению SCRUM, где-то сработали новые HR-практики, а для решения других задач вообще понадобилось убедить всех, что технологии самоуправления – это совсем не страшно. И все это в довольно консервативной команде, которая создает серьезные корпоративные ИБ-продукты.

Про образование

Я учился на физфаке МГУ, потом там же в аспирантуре, кандидат физико-математических наук. Когда поступал, я прямо хотел быть физиком. Когда я защитился, передо мной встал вопрос: а что делать дальше? Было понятно, что в России заниматься наукой можно, но ты должен быть прямо очень крутой чувак, мировой топ. Я понял, что я в этом смысле нормальный, но не суперзвезда. За рубежом моего уровня достаточно, чтобы заниматься наукой, даже профессорское звание можно получить при должном старании. В России же научная среда очень специфическая: я не хочу назвать ее бюрократической, но все научные разработки – по сути, государственные, и это мне не очень нравилось. Уезжать за границу я не хотел, потому что у меня здесь были друзья, семья, будущая жена. Нужно было решать, что делать дальше. Я подумал: «Ну, что я умею? Немножко умею программировать».

Про UI-разработку и начало карьерного пути

Я понимал, что у меня нет серьезной программистской базы в том, что касается алгоритмов, поэтому пошел в UI-разработку. С точки зрения знаний ее можно назвать более щадящей. Конечно, здесь тоже нужен большой пласт программирования, но все-таки более важно визуальное восприятие мира: чтобы ты понимал, красиво – некрасиво, удобно – неудобно. А еще в UI-разработке ты гораздо быстрее получаешь видимый результат.

Я изучал JavaScript сразу на практике, какого-то системного обучения у меня не было. Когда я начинал всем этим заниматься, из фреймворков были только jQuery, сейчас это вообще библиотекой называется. И все лабали как хотели – полная анархия. Потом появился первый Angular, который, честно говоря, был так себе. Второй был уже нормальный - полноценный фреймворк, который задает структуру проектов. Может быть, кто постарше из аудитории помнит, что еще был фреймворк Ext JS. На нем писали корпоративные приложения. Многокомпонентный фреймворк, даже со структурой. В нем немало багов было, но с точки зрения архитектуры, структуры он вполне себе приличный. На нем было приятно писать.

Какое-то время я совмещал работу и учебу, писал код на PHP и JavaScript. В 28 лет устроился на постоянную работу – обычным разработчиком в небольшую семейную компанию. Там были своеобразные процессы. Роста с точки зрения задач и ответственности не было. Проработал так два-три года, потом попал в «Инфосистемы Джет», где стал веб-разработчиком в команде «Дозора». Основная специализация – JavaScript. Стал расти. Был джуном, миддлом, сениором. К моменту, когда мы начали выделяться в «Солар», меня сделали архитектором. Параллельно я был тимлидом. Через пару лет мне предложили стать руководителем отдела разработки, и я согласился.

Про функциональные колодцы и другие проблемы, которые пришлось решать

В команде «Дозора» было довольно много разработчиков, но они все были разделены на так называемые функциональные группы. Были специалисты по Scala – и у них отдельный тимлид, у спецов по Clojure свой тимлид, по JavaScript – свой (как раз я). Такие же группы были у тестировщиков и аналитиков. В менеджменте это называется функциональными колодцами. Каждая задача проходила долгий и тернистый путь по этим отделам, периодически ее отфутболивали назад. Рано или поздно выстраивались очереди – классическая проблема функциональных колодцев. На тот момент я не знал этой теории менеджмента, просто чувствовал, что мы работаем как-то неправильно и долго. Если задача требовала участия только двух таких функциональных групп, мы научились делать все быстро. Если больше двух – начинался полный трэш: сначала одна группа сделает свою часть, потом вторая, потом третья, первая начинает заниматься чем-то другим и так по кругу. Договориться сложно.

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

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

Про повышение и счастливых разработчиков

Но пока всего этого не было, разработчики стали уходить со словами, что задачи одинаковые, неинтересные. И тимлиду не скажешь: «Почему ты не занимаешься развитием человека, не растишь его?» Потому что мы тогда реально были перегружены менеджерскими вещами. Мне тоже стало скучно в роли тимлида, я не видел, куда мне дальше развиваться. Я пришел с этим к руководителю проектов. Она сказала: «Андрей, у меня есть идея сделать тебя руководителем всех разработчиков, ты будешь отвечать за их развитие, за то, чтобы они были счастливы».

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

Про творчество

Раньше у нас только архитекторы участвовали в проработке бизнес-решений, а сейчас мы внедрили PBR (Product Backlog Refindment). У нас любой разработчик, любой тестировщик предлагает какие-то варианты решений. Мы собираем людей вместе (иногда это называют «Три Амиго»), и маленькая команда предлагает решение. Продукт сложный, и поначалу коллегам просто не хватало знаний, чтобы придумать что-то толковое, но за последние два года ребята этому научились. Да, они обращаются к архитекторам за помощью, когда это нужно, валидируют у них решения. Но я вижу, что уровень задач, которые они решают, все выше и выше. Это добавляет им счастье творчества. И это то, что важно для меня.

Про совместную работу

Сейчас мы двигаем тему с OKR (Objectives and Key Results – цели и ключевые результаты). Это своего рода фреймворк, который позволяет ставить общие цели на все большое подразделение. И каждая из команд, каждый из отделов может поддерживать эти верхнеуровневые цели своими нижнеуровневыми. А ключевые результаты нужны для того, чтобы определить некие измеримые показатели достижения целей. Мы отслеживаем эти метрики, идем по ним вместе с остальными командами, периодически синхронизируясь. Это тоже очень прикольно – становится больше совместной работы.

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

Про полезные HR-инструменты

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

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

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

Недавно вот узнал про Коллегиальный Обзор – практику из Социократии 3.0. Это такой Performance Review на максималках. Мы сейчас его активно применяем и получаем очень хорошие отзывы. Этот формат позволяет коллегам давать обратную связь очень бережно и при этом конструктивно. Заодно получается сессия по командообразованию, полная позитивной энергетики. После нее тот, кто проходит Коллегиальный Обзор, строит свой План развития. Те, цели, которые ребята пишут в этих планах, а главное, как они потом двигаются к ним, очень вдохновляет. Дело в том, что они создают его вместе с коллегами (а не как в Performance Review – сугубо с руководителем) и в итоге ощущают его полностью своим. Всем советую: https://patterns.sociocracy30.org/peer-review.html.

Про мотивацию

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

Про самоуправление

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

В общем, уже больше полугода мы в подразделении разработки активно экспериментируем с элементами самоуправления. Самый распространенный фреймворк – Холакратию – решено было не использовать. Она должна внедряться на уровне всей компании, а в наших условиях это нереально. Но зато я нашел уже упомянутую тут Социократию 3.0 (S3). Она появилась чуть позже и учла эту проблему. Основной подход S3 – это встречать организацию в том виде, в котором она сейчас существует, и двигаться с комфортной для всех скоростью. То есть не надо устраивать революцию и ломать людей через колено. Достаточно начать с того, чтобы определить основные проблемы, которые не получается решать обычными способами, и найти в S3 практики, позволяющие их закрыть. Попробовать и, если зашло, двигаться дальше, пробовать что-то еще.

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

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

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

И в конце один из моих любимых паттернов S3. Звучит он очень просто: сами станьте изменениями!

Все в ваших руках!