Александр Бындю — IT-архитектор, вел тренинги в ScrumTrek, был тренером на AgileCamp на инженерном треке, 11 лет преподавал в двух вузах. В 2022 году написал книгу «Антихрупкость в IT», вдохновившись идеями Нассима Талеба. В книге он описал практики, позволяющие выстроить внутреннее качество IT-систем и процессы разработки, объяснил, почему важно использовать их в работе, при обучении в вузах, на курсах и тренингах.
- Джуниоры-груднички и первые шаги в разработку
- Инженер — в душе, а не в дипломе
- Почему «антихрупкость»?
- Моя книга — для разработчиков, бизнеса и студентов
- Будете знать, куда ударить
- Добавить в образование антихрупкости
- Руки или головы разработчиков
- Узкие горлышки плохого кода
Ссылки: Twitter, сайт, LinkedIn
Джуниоры-груднички и первые шаги в разработку
У меня высшее образование инженера-программиста, я программирую всю жизнь, кроме последних лет, и это до сих пор приносит мне удовольствие. Однажды мне даже приснилось, что я сел в тюрьму, и первая мысль была: «Как же теперь программировать?»
Сразу после института я устроился разработчиком в российское представительство английской компании Fuse8 и начал читать правильные книжки. В таких компаниях проекты стоят на потоке — в приоритете скорость, а не качество. Но мой коллега Алексей Абрамов порекомендовал прочесть про экстремальное программирование, разработку через тестирование — достал для меня книги практически из-под полы, как запрещенку. Я прочитал и решил применять новые знания на практике. В итоге за полтора года стал одним из самых сильных программистов в коллективе и, чтобы продолжить развиваться, перешел на должность технического директора в другую компанию. Там около трех лет работал над проектированием и созданием больших систем.
Параллельно я писал много статей в блог и выступал. Так я познакомился с основателем «Хекслета» Кириллом Мокевниным и получил от него приглашение стать спикером на крупной конференции в Ульяновске. Перед студентами в огромном зале я вещал о том, как устроена жизнь в IT. После доклада слушатели признались, что шокированы — особенно тем, что я рассказал про развитие в профессии.
В моем понимании, джуниоры беспомощны и зависимы — как младенцы. Потом они вырастают в подростков и считают себя независимыми, будто никаких преград на свете не существует — это мидл-разработчики. А дальше, побившись головой об стену из-за разных жизненных обстоятельств, понимают, что все в мире взаимозависимо, все друг на друга опираются, а все концепции следуют одна из другой, и ничего само по себе в воздухе не витает.
Возможно, студенты как раз были на стадии: «Я научился печатать код и теперь все могу». Но создавать классы и объявлять функции — это даже не быть ребенком, который научился ходить. Это уровень грудничка, который увидел, как ходят другие.
Продолжайте учиться: На Хекслете есть несколько больших профессий, интенсивов и треков для джуниоров, мидлов и даже сеньоров: они позволят не только узнать новые технологии, но и прокачать уже существующие навыки
Инженер — в душе, а не в дипломе
Когда провожу собеседования, сразу понимаю устремление человека. У одного вся жизнь крутится вокруг хобби, например велосипеда, что само по себе неплохо. Но он устраивается на работу, только потому что ему нужны деньги на велоспорт. А другой любит создавать и видит творчество в работе инженером.
Творчеству нет предела, но есть определенные границы реального мира, в рамках которых ты творишь. Моя жена — имиджмейкер-стилист. Казалось бы, просто наряжает людей. Но в этой творческой профессии тоже есть критерии-ограничения: разные цели, стили, типажи. Это тоже инженерное искусство — как и строительство моста. Ведь при строительстве тоже нужно учесть множество факторов: сопротивление материалов, особенности грунта, окружающий ландшафт.
Так же характеризует инженерные искусства Георгий Щедровицкий в книге «Оргуправленческое мышление. Идеология, методология, технология»: творчество в определенных моделях и границах — и есть инженерное искусство. Частая проблема джунов в том, что они не знают особенности бизнеса, а значит, не видят границ и творят безгранично. Получается, может, и симпатично, но абсолютно бесполезно. Конечно, бывают сумасшедшие изобретатели, которые пытаются соединить утюг с лампочкой, и у 0.1% есть шанс создать что-то гениальное. Но в бизнесе это обычно не работает.
Почему «антихрупкость»?
Мне понравились размышления Нассима Талеба в книге «Черный лебедь. Под знаком непредсказуемости». Это довольно смелое произведение, и мне по душе честность концепции Талеба. Это не одна из тех далеких от реальности теорий, за которые умные люди получают премии. Книга «Антихрупкость» — про жизнь и про то, какие механизмы в ней действительно работают. Я в своей практике придерживаюсь такого подхода: любую концепцию проверяю на применимость в реальной жизни. Если она не работает, то пусть ее презентует хоть сам Мухаммед Али или Папа Римский — на меня не повлияет никакой авторитет, я не буду эту концепцию использовать.
Проникшись идеями антихрупкости, я начал создавать продукты, которые устойчивы к изменениям и не разрушаются из-за смены контекста или новых вводных. Моей компании уже 11 лет, мы создаем IT-продукты, которые реально работают. Когда меняются условия, мы можем внести изменения, и наш продукт железобетонно продолжит функционировать, выполнять свои задачи. Я начал писать об этом статьи в блог, делать доклады. Когда число статей достигло критической массы, родилась книга. Я отредактировал эти посты, добавил больше смыслов про антихрупкость и проверил концепцию на собственном бизнесе.
Когда я консультирую другие продукты, разработчики часто жалуются: «Здесь поменяли — там отвалилось. Рынок поменялся — все пришлось переписывать». Но как же так? Почему нельзя сделать нормально? И однажды я понял: мы в компании как раз закладываем антихрупкость в IT-продукты, продумываем готовность к изменениям на всех стадиях: от бизнес-целей до названия переменных. Мне показалось, что концепция перекликается с тем, что я делаю и что хочу донести. Поэтому я и назвал так свою книгу.
Моя книга — для разработчиков, бизнеса и студентов
Я писал книгу не только для владельцев бизнеса и техлидов, но и для разработчиков, и даже студентов.
Я долго преподавал в университете и знаю, насколько студенты восприимчивые, клевые, насколько их разум открыт новому. Мне говорили, что студенты не хотят ничего делать, не хотят думать. Но, начав с ними заниматься, я обнаружил, что им все дается легко: даже те концепции, которые наше поколение освоило лишь за 5-6 лет опыта работы, они осваивают за семестр.
Конечно, есть люди, которых заставили учиться на айтишников, но таких мало. Обычно это семейная трагедия, когда родители реализуют свои амбиции через детей. Таким студентам я предлагал: «Давай я поставлю «два», пусть тебя отчислят, и ты начнешь заниматься тем, чем хочешь».
Одна студентка призналась, что родители заставляют ее учиться, а сама она играет на арфе и мечтает выступать. Я поставил ей двойку, но оценку исправили в деканате, и студентку не отчислили. Через два года она все равно устроилась в Московскую филармонию играть на арфе. Когда она написала мне об этом, я очень обрадовался.
Но большинство пошли в IT не из-за хайпа или родителей, а потому что они инженеры в душе. Я вижу в них это, потому что сам такой же. Если дать им знания, которые они не могут получить из других источников, это обязательно принесет пользу.
Книга знакомит с тем, какие проблемы возникают в разработке и почему. Важно, чтобы в картине мира моих читателей появился тот самый черный лебедь, о котором они не знали — редкие, но неизбежные обстоятельства, радикально влияющие на процессы и результаты. Я даю много ссылок, а читатели решают сами: просто пребывать в шоке или рассуждать, как действовать с новыми знаниями. Главное, чтобы люди вообще задумались о том, что продукт можно создавать изначально антихрупким и жизнеспособным.
Многие заказчики, к сожалению, даже не знают, как это возможно. Они привыкли, что все плохо, не работает и требует постоянных переделок. Год от года работая в таком стиле, они привыкают, что это норма. Моя цель — донести, что может быть по-другому. Пусть мне миллион человек скажет, что я не прав. Но если найдется хотя бы тысяча специалистов, которые начнут действовать, это будет для меня огромным успехом.
Будете знать, куда ударить
Хочется сказать, что книга поможет повысить эффективность, но здесь есть нюанс. Можно быстрее печатать код, лучше понимать шаблоны, но книга не об этом. Ее цель — повысить эффективность в том понимании, которое я проиллюстрирую одной байкой. Ее рассказывают то о Леониде Капице, то о Томасе Эдисоне:
Владелец фабрики не мог починить свой паровой генератор. Пришел рабочий. Используя всего лишь молоток, быстро устранил проблему и выставил за эту десятиминутную работу счет на 10000 фунтов стерлингов. Фабрикант ошеломлен. Секретарша просит рабочего подробно расписать стоимость оказанных услуг. Вскоре приходит ответ: «За десять минут простукивания — 1 фунт. За знание того, куда нужно ударить — 9999 фунтов. Итого: 10000 фунтов».
Я хочу, чтобы люди пришли именно к такой эффективности, перестали суетиться, а вместо этого увеличили свою осознанность. На самом деле в IT-продуктах не так много задач, как может показаться. Например, Impact Map — это та же Mind Map, ментальная карта границ и целей проекта. Внутри — карта влияний, которые должны подтолкнуть бизнес заказчика к достижению целей. Если понять, какие гипотезы реально влияют на цель, и сосредоточиться на них, можно оставить 20% работы, которые приведут к тем самым 80% результатов. А люди обычно делают слишком много лишнего.
Эффективность для меня — это спокойно анализировать, понимать, что даст результат, вместо бесконечных итераций и планирования на год вперед. Я хочу, чтобы разработка была более расслабленным и эффективным процессом. Надеюсь, у меня получилось описать в книге, как я это вижу.
Это будут те же самые восемь часов в день, но в расслабленном режиме и осознанном состоянии. Разработчики будут понимать, что и зачем они делают — а это придает жизни смысл и ценность. На работе, наконец, перестанут страдать и начнут делать что-то действительно полезное и ценное. Или поймут, что делают бессмыслицу, уволятся, найдут другую работу — тоже хороший результат. Потому что, пока все в огне, можно даже не осознавать, что занимаешься полным бредом, а жизнь проходит мимо. Да, тебе платят зарплату, возможно, высокую, но если посмотреть на свою жизнь со стороны, то зарплата — это не то, чем ты будешь в итоге гордиться.
Если бизнес-оунеры и техлиды прочтут книгу и обнаружат, что у них в компаниях все выстроено неэффективно, то могут расстроиться. Но впадать в депрессию контрпродуктивно.
Я приведу пример. Один читатель моей книги, работающий над интересным продуктом из области продажи электроники, написал мне: «У нас проблемы на проекте. Никак не можем собраться, не можем понять, где сфокусироваться. Инвесторы уже недовольны, подгоняют нас, а мы не можем выдать результат». Я предложил провести Impact Mapping для этой команды.
Собрались: владелец компании, технический директор, операционный директор, директор по продажам. Я предложил описать бизнес, стал спрашивать про цель проекта: все собравшиеся назвали разные цели, и мы записали их все. Я спросил про гипотезы достижения целей — и тут началась мыслительная работа. Наверное, первый раз за долгое время они задумались, как представляют свое светлое будущее, и мы начали это формулировать. Так они поняли, что одна гипотеза позволяет охватить всего 10% рынка, а другая — до 90%, и решили полностью сосредоточиться на ней. Вот и вся магия — стало понятно, куда вкладывать деньги и время.
Я рассказывал про Impact Map еще шесть лет назад на Agiledays, вел там практику, проводил тренинги. При всей кажущейся простоте Impact Mapping у него есть множество нюансов, которые мы в компании прорабатывали годами. Большинство подводных камней и фишек я описал в статье. А еще мы переосмыслили Customer Journey Map как «Схематизацию опыта с CJM и Service Blueprint. Практика гибридной нотации» — делаем ее по-своему.
То, что я описал в книге, можно брать и использовать. Сейчас это особенно актуально, потому что нужно обеспечивать стабильность бизнеса, а погоня за эффективностью осталась в прошлом.
Добавить в образование антихрупкости
Многие утверждают, что система образования сейчас не гибкая, но она и не враждебна: вузы открыты к новым концепциям. Приходите и преподавайте все, что подходит для студентов-айтишников и управленцев. Я ни разу не встречался с ограничением, что про Impact Map нельзя рассказывать из-за того, что это не входит в программу.
Проблема том, что научная карьера не всегда предполагает практику: нужно вкладываться в публикации в профильных журналах, защищать диссертации, проводить исследования. В итоге в науке часто остаются те, кто знает очень много теории, но мало практикует. Так сконструировано образование во всем мире.
Такие люди могут прочитать мою книгу и не согласиться с концепциями, потому что их цель — не столько подготовить студентов, сколько продвигать теоретическую науку. Из-за этого некоторые концепции в мире тормозят, но остается много преподавателей, открытых к новому. Тем более в России пару лет назад были приняты стандарты по IT-архитектуре, UX, QA, по разным грейдам. Это крутые программы, общероссийские стандарты, которые хорошо прописаны. То есть в целом рамки заданы, и внутри них можно делать, что пожелаешь.
Я продолжу договариваться с разными вузами о том, чтобы приезжать с лекциями и рассказывать студентам о своей концепции. Люди должны знать про эти идеи — на самом деле, очень простые, и в этом их сложность. Я постарался предложить сообществу не только инструменты, но и тонкости, которые повышают эффективность их использования. Не знаю, как книга повлияет на деятельность разработчиков. Может быть, они попробуют делать не так, как я описал, и у них ничего не получится. А может быть, получится эффективно, и они решат внедрять практики и дальше. По крайней мере, я на это надеюсь.
Читайте также: 8 самых востребованных языков программирования в 2023 году
Руки или головы разработчиков
В своей книге я написал: кто-то покупает руки разработчиков, а кто-то — головы. «Руки» — это джуны, которые умеют писать код. Но не только они.
В Москве есть одна большая компания, которая делает продукты для телекомов. Я их консультировал и столкнулся с классической проблемой. По их словам, у них есть работающий продукт, с которым все хорошо, но не функционирует одна деталь. Мне часто приходится такое слышать: «Все работает, кроме одной маленькой штучки».
Я попросил позвать человека, который написал этот код. Его представляли как специалиста с миллиардом лет опыта — 20 лет из своих 50 он делает в компании какие-то формочки. Оказалось, что он не очень разбирается в своей работе, а, открыв код, я увидел, что там вообще ничего не готово и этот проект работает чудом. Это как идти с закрытыми глазами над обрывом по тонкому бревну. Если невероятно повезет, то не упадешь. Но стоит чуть-чуть оступиться, полетишь вниз с вероятностью 100%. Примерно так эта система и работала.
Мой вердикт был такой: сесть и создать новую систему с нуля. Да, они продали заказчику MVP, который оставалось «немного доработать». Но по факту никакой системы внутри не было, только набор функций, которые как-то работают при прямых сценариях. Разработчик не смог его спроектировать: руки есть, а головы нет. Если оценивать его по годам стажа, то это сеньор. Если судить по экспертизе, системному мышлению, умению понять, как помочь бизнесу через IT-решение, то джун. Умеет ли он создавать классы, писать алгоритмы? Умеет. Есть ли от этого польза? Нет.
Узкие горлышки плохого кода
К сожалению, в некоторых компаниях запрос именно на людей, которые работают руками. Руководство не хочет, чтобы разработчики предлагали свое понимание, какой должна быть архитектура. В крупных корпорациях финансовые решения принимают не владельцы бизнеса, а линейные менеджеры, у которых есть свои KPI — показатели эффективности, и нужно потратить все выделенные на проект деньги. Если сделать это не удастся, то в следующем году средств не выделят или выделят меньше.
Так происходит во всем мире: нужно потратить деньги, а эффективность вложений посчитать и оценить сложно. Поэтому, если проект не выполнят в срок, просто попросят еще денег и пару лет на разработку. Так может продолжаться долго. Люди, занятые на этом проекте, формально будут иметь по 10 лет стажа. Но они не будут знать ничего про создание приложения под бизнес.
Есть и другие странные модели. Один из моих друзей работает в американской компании, которая заказывает услуги по разработке в Индии. Я видел видеоролики, как там учат программистов: лектор вещает на зал в 100 индусов. Все они громко повторяют за лектором: «QA — это инженер, который занимается тестированием». Так они обучаются тысячами. В аутсорсинговых компаниях в Индии (такие еще называют «галерами»), которые продают разработчиков другим компаниям, нормальный штат — от 15 до 150 тысяч человек. Сотрудникам выдают скрипты, чтобы они прошли собеседование, и с помощью такого нехитрого испытания из сотен тысяч человек отбирают около 1000 сотрудников для работы на проекте.
В процессе работы у них получается очень низкокачественный код: все работает, но постоянно появляются баги, которые эта же команда чинит — за деньги, естественно. И это бесконечный процесс. Когда это надоедает, руководство нанимает 20-30 инженеров из России, Беларуси, Украины, Израиля, которые занимаются исключительно рефакторингом этого кода. То есть 1000 человек генерируют плохой код, а 20-30 человек бесконечно его исправляют — вот такое «узкое горлышко».
Невероятно много денег в мире тратится впустую. Сейчас экономика всех стран падает, раздутый рынок начинает сжиматься. И я надеюсь, что адекватные люди станут более востребованными, а неадекватные займутся чем-то другим.
Моя книга работает на этот результат — чтобы головы инженеров стали предпочтительнее рук, а качеству продуктов уделялось больше внимания еще на стадии проектирования, и они получались действительно антихрупкими. Для этого нужно выстроить внутреннее качество IT-систем и сделать процессы разработки адаптивными под внешние изменения и потребности заказчика. Для этого есть много способов, в книге я описал практики своей команды и коллег. Если у вас есть личный опыт, как разрабатывать действительно устойчивые к изменениям продукты — поделитесь в комментариях.
Читайте также: Как эффективно читать профессиональную литературу
