Реклама в Telegram-каналах DzikPic и dev.by теперь дешевле. Узнать подробности 👨🏻‍💻
Support us

«Жалуются, что университеты отстали от индустрии». Венкат Субраманьям про разработку, процессы и образование

Венкат Субраманьям, основатель компании Agile Developer, сотрудничает как разработчик и Agile-коуч со многими компаниями: «Я одновременно работаю в семи местах». А ещё занимает профессорскую кафедру в Хьюстонском университете, пишет книги и выступает на конференциях по всему миру без обуви, но в белых носках («это очень удобно, ведь покупает их моя жена»). Человек-оркестр рассказывает о философии Agile, видах корпоративной культуры, ИТ-образовании и фитнесе для ума и тела.

Оставить комментарий
«Жалуются, что университеты отстали от индустрии». Венкат Субраманьям про разработку, процессы и образование

Венкат Субраманьям, основатель компании Agile Developer, сотрудничает как разработчик и Agile-коуч со многими компаниями: «Я одновременно работаю в семи местах». А ещё занимает профессорскую кафедру в Хьюстонском университете, пишет книги и выступает на конференциях по всему миру без обуви, но в белых носках («это очень удобно, ведь покупает их моя жена»). Человек-оркестр рассказывает о философии Agile, видах корпоративной культуры, ИТ-образовании и фитнесе для ума и тела.

Журналист dev.by встречается с профессором после его выступления на Voxxed Days Minsk. Сабраманьям делится впечатлениями о Минске, в который приезжает уже третий год подряд:

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

15 лет назад Agile был интересным подходом, с которым с любопытством и, возможно, не без опаски экспериментировали многие компании. Какое место Agile занимает сегодня?

Последние плюс-минус пятнадцать лет были успешны для Agile-разработки. Но проблемы остаются. Многие компании и команды до сих пор стремятся вести разработку в наиболее предсказуемом русле — они уделяют ключевое внимание самому процессу. В то время как в духе Agile фокусироваться на результате. И пока мы не перестанем ставить во главу угла процесс разработки, проблема будет существовать. Здесь уже неважно, как мы называем методику работы: Agile, Waterfall или как-то иначе — нам нужно фокусироваться на результате.

До сих пор можно услышать мнение, что Agile — это философия, оторванная от практики, внедрение новых методик ради самого внедрения. Что вы ответите на это?

Я написал книгу «Приёмы работы Agile-разработчика» (Practices of an Agile Developer)! Поэтому, конечно, я верю в практическую сторону Agile. Да, Agile — это философия, но не только.  Важно понять, что мы имеем в виду под практической стороной? Не процесс разработки, а набор практик. Я очень хочу, чтобы Agile был гибким подходом. Для меня существенны три ключевые характеристики подхода: Agile получает фидбэк, Agile адаптивен, Agile реалистичен.

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

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

Да пребудет с вами Agile: гайд по основным терминам + курсы.
Да пребудет с вами Agile: гайд по основным терминам + курсы.
По теме
Да пребудет с вами Agile: гайд по основным терминам + курсы.

Как практикующему коучу, вам наверняка приходится сталкиваться со стереотипным отношением клиентов к Agile.

Конечно! Я прихожу в ту или иную компанию и часто слышу, как разработчики и другие сотрудники говорят:

«Мы нуждаемся в Scrum-мастере». Обычно я отвечаю: «Мне жаль это слышать!».

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

Как следует поступать Agile-разработчику, который разрабатывает ПО для традиционной компании, требующей классические строгие отчеты о каждом пройденном шаге?

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

За последние 30 лет я работал с самыми разными компаниями. И часто люди говорили мне: «Нет, ты не сможешь выполнить задачу, потому что ты никогда не работал с этими ребятами». Но я все равно справлялся с «невыполнимым» заданием. Так происходило, не потому что я столь умён — всё совсем наоборот. Я справлялся, потому что выстраивал отношения и завоевывал доверие.

Насколько часто американские разработчики сталкиваются с бюрократией, царящей в компаниях-заказчиках?

Каждый божий день! Я часто говорю о культуре. Своя культура присуща не только отдельным странам или отдельным регионам — культура присуща и каждой отдельной команде.

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

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

И я думаю, что такая культура замечательна… если вы работаете в военной сфере. Но большинство из нас всё же занимаются другими вещами.

На самом деле, крайне важно найти подходящий тип корпоративной культуры. Компании с разными видами культуры существуют в каждой стране мира, включая США. Возможно, для некоторых стран командный стиль управления более свойственен в силу более жесткой структуры общества, но это не значит, что в США нет подобных компаний. На самом деле, встречаются они довольно часто.

В Беларуси часто говорят, что наше техническое образование не поспевает за развитием индустрии. Насколько актуальна подобная проблема для американских университетов?

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

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

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

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

IT-курсов много, а времени мало? Выбирайте идеальную программу для вашего карьерного трека

Вы написали много книг, посвященных программированию и компьютерным наукам. Наверняка, это долго. Можете объяснить, зачем вам это?

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

— Не написать ли мне книгу? Я никогда не делал ничего подобного.

— Как у тебя идут дела?

— Отлично.

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

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

Это звучит очень по-американски.

Не знаю, насколько это в американском стиле, но в моем уж точно (Смеется). И каждую книгу я писал только потому, что мне хотелось рассказать ту или иную историю.

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

Вы постоянно в пути, посещаете какое-то невероятное количество мероприятий по всему миру. Как держите себя в тонусе с таким графиком?

Существует два типа фитнеса, которые очень важны для меня: физический и психологический.

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

Что касается психологического фитнеса, то у меня уже 35 лет существует правило: мыслить только в позитивном ключе. Конечно, все мы люди, и получается не всегда, но пытаться стоит. В нашей семье даже не принято говорить негативно о других. Это настраивает ум на нужный позитивный лад.

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

И еще одно — делать работу как можно раньше. Если у тебя запланировано дело на декабрь, а сейчас июнь, зачем ждать полгода, чтобы взяться за него?

Как понять что сотрудник хочет уволиться. Объясняет психолог
Как понять, что сотрудник хочет уволиться. Объясняет психолог
По теме
Как понять, что сотрудник хочет уволиться. Объясняет психолог
Новый рекламный формат в наших телеграм-каналах.

Купить 500 символов за $150

Читайте также
Agile испортился и больше не работает? Айтишники рассказали про свой опыт
Agile испортился и больше не работает? Айтишники рассказали про свой опыт
Bubble
Agile испортился и больше не работает? Айтишники рассказали про свой опыт
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
DevOps родился для того, чтобы команды разработки и поддержки работали эффективно и слаженно. Но иногда использование его практик может привести к реальным провалам. Как с помощью DevOps-практик не только не помочь, но и навредить проекту, рассказывает Александр Селезнёв, релиз-менеджер в Luxoft. 
2 комментария
Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны
Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны
Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны
Лид-архитектор OpenShift из британского Barclays Айэн Милл опубликовал свои рассуждения о развитии методологий программирования, свидетелем которому он стал в ходе 20-летней карьеры в программировании. Его описание основано на концепции коллективного воображения из книги «Sapiens: Краткая история человечества» Юваля Ноя Харари. Она объясняет существование религий, демократии и многих других вещей, в основе которых лежат взаимоотношения мужду людьми. Публикуем сокращённый перевод.
14 новых Agile&Scrum-курсов с сертификатами
14 новых Agile&Scrum-курсов с сертификатами
14 новых Agile&Scrum-курсов с сертификатами
Продолжаем знакомить с популярными курсами по Agile&Scrum. Предлагаем вам новую подборку курсов по Agile&Scrum, где мы собрали еще 20 интересных и разнообразных программ обучения по управлению проектами, которые подойдут как для руководителей, так и для рядовых сотрудников компаний.

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.