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

Журналист 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Отлично.

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

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

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

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

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

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

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

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

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

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

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

Как понять, что сотрудник хочет уволиться. Объясняет психолог

По теме

Как понять, что сотрудник хочет уволиться. Объясняет психолог

16 лет dev.by — «дефолтный» источник информации о беларусском ИТ

Вы можете...