Николай, Independent Consultant at XP Injection - компания, занимающаяся организацией образовательных по инженерным практикам, Agile методологиям и технологиям разработки в мире Java, JavaScript, .NET.Также Николай больше 14 лет в отрасли и является Java Tech Lead и Delivery Manager

https://www.facebook.com/profile.php?id=100004612667197
https://www.linkedin.com/in/alimenkoumikalai/
https://twitter.com/xpinjection

«Разработчики на то время зарабатывали явно не больше бухгалтеров»

Хочется отметить твой многолетний опыт и два профильных образования, изначально ли ты готовился к сфере IT?
Исторически так сложилось, что я с детства увлекался математикой. Причем, помню, что интерес возник еще в младших классах и математика мне давалась достаточно хорошо.
Жил я на то время в Беларуси, это были времена постсоветского пространства, когда профессии и специальности становились модными по принципу волны. Я застал волну моды на юристов, экономистов, на специальности по международным отношениям.

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

«Тогда эта профессия была похожа на «черный ящик», разрыв между реальной практикой и теорией в университетах был просто невероятный»

Забавно было то, что на тот момент (поступал я в 2000 году) вообще было непонятно, станет ли это направление перспективным и прибыльным, тогда только зарождалось понятие коммерческого программиста. И разработчики на то время зарабатывали явно не больше бухгалтеров. Тогда эта профессия была похожа на «черный ящик», разрыв между реальной практикой и теорией в университетах был просто невероятный. Это уже сейчас меняются тенденции и компании даже инвестируют в то, чтобы в ВУЗах преподавали материал, близкий к реальным проектам. Знаю несколько преподавателей из крупных компаний. Было и у меня желание внести свой безвозмездный вклад и найти университет, где мог бы преподавать. Но столкнулся с безразличием, и принял решение, что через навязывание эту идею точно не стоит реализовывать. Правда, я все равно решил заполнить эту нишу и взялся за то, чтобы ревьювить одну из книг на технологическую тему.

Как отбираются книги для печатного издательства, ведь отрасль стремительно развивается?
Есть специфика работы с книгами для печати. Когда идет работа над такой книгой, заведомо ожидается от автора, что он не будет писать материал «на сейчас». Чтобы написанная книга не устарела завтра же, чтобы были в ней обязательно какие-то отправные точки на будущее развитие данной тематики. Плюс, сейчас у автора нет того времени для раскачки и чтобы собраться мыслями, как это было раньше.

«Зарабатывать на конференциях, как на пустом инфобизнесе, у нас нет цели»

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

«Думаю, мы оказали очень существенное влияние на украинское IT того времени»

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

«Зарабатывать на конференциях, как на пустом инфобизнесе, у нас нет цели»

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

«Видел компании, в которых тайтлы — бюрократическая необходимость, дающая сотрудникам полномочия, доступы и определенные рычаги управления, уважение»

Что ты думаешь об «инфляции» тайтлов, и какая твоя позиция по этому поводу?
Моя позиция весьма интересна, но ее будет сложно понять, не имея контекста, в котором я нахожусь. Была возможность поработать консультантом в разных окружениях. Видел компании, в которых тайтлы — бюрократическая необходимость, дающая сотрудникам полномочия, доступы и определенные рычаги управления, уважение. И выдуманная шкала тайтлов в таких компаниях работает именно для этого контекста. И разве можно говорить, что Senior Developer этой компании, будет на одинаковом уровне по отношению ко всему рынку? Абсолютно нет. Выходит, что тайтлы вполне абстрактны. Взять даже историю с происхождением такой должности, как Delivery Manager. Одна из компаний решила таким образом расширить должность Project Manager. И это подразумевало техническую составляющую должности и шире круг обязанностей по развитию направления бизнеса клиента. А рынок активно подхватил этот тайтл, так как он звучит несколько моднее и интересней. Хотя если дословно сделать перевод, то звучит весьма странно и непонятно, о чем позиция. Мы потом столкнулись с проблемой, что в разных компаниях эта должность подразумевает абсолютно разный спектр обязанностей и не всегда несет в себе техническую составляющую, как было изначально заложено. И эта разница не дает возможности рассуждать о тайтлах вообще. Мое отношению к ним поэтому абсолютно спокойное. Работая в разных компаниях, могу подстраивать свой тайтл под то, как это удобно в рамках конкретной компании.

«Системное мышление необходимо уже на позициях архитектора, технического лидера, системного аналитика и т.д»

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

«Микроменеджмент порождается отсутствием доверия»

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

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

«Прежде всего нельзя делать так, чтобы увольнение для человека было сюрпризом»

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

«Задачу можно оценивать тогда, когда полностью понятен контекст»

Какие твои подходы к оценке задач?
Это очень обширная тема, потому ограничу ее таким примером. Задачу можно оценивать тогда, когда полностью понятен контекст. Именно на этом принципе основаны Agile подходы: качественная оценка возможна только тогда, когда все вопросы уже заданы и ответы на них получены. Примерную же оценку можно давать всегда. Она будет базироваться, конечно, на наборе предположений и на технической экспертизе человека или группы, которые оценивают. А это значит, такая оценка будет очень субъективной. И нужно осознавать, что будет присутствовать определенный процент относительности.

«Если ожидают, что придет консультант и «Вжух!», я не работаю с такими клиентами»

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

Какие книги, которые тебя впечатлили, ты можешь посоветовать?
Из книг по разработке сразу же приходит на ум «High-Performance Java Persistence» от Vlad Mihalcea. Впервые увидел человека в индустрии, который взял не сильно популярную тему, глубоко разобрался и написал мега полезный, качественный и крутой контент.

Второй я бы выделил «Проект «Феникс»: роман о том, как DevOps меняет бизнес к лучшему» от Джина Ким, Джорджа Спаффорд, Кевина Бер. Эта книга о культуре совместной работы разных специалистов в команде разработки, которая помогает добиваться меньшими силами лучших результатов и не терять время на активности, не приносящие пользу.

И последняя третья книга будет из другой области: «Открывая организации будущего» Фредерика Лалу. Эта книга как раз о тех самых бирюзовых организациях, о которых так часто говорят. Не могу сказать, что она самая простая к прочтению, потому как местами она касается таких неочевидных тем, как мировоззрение человека и его ценности. Книга дает возможность проанализировать, совпадают ли твои ценности с ценностями компании, с которой ты работаешь. И много еще интересных тем затрагиваются, которые обычно обходят стороной многие люди в нашей сфере.

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

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