Управление проектами

[00:00:32]

Приветствие

Добрый день. С вами снова GeekSpeak. Меня зовут Александр Сагун. Думаю, вы уже видели меня в предыдущих выпусках, если смотрели их по порядку. Я исполнительный директор компании GeekBrains, в прошлом и настоящем связан с информационными технологиями. И сегодня у нас в гостях Сергей Артюхов — с радостью его приветствую. Сергей имеет большой опыт в организационных изменениях и является экспертом по Agile-подходу к управлению проектами.

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

Сергей, пару слов о себе расскажите: расскажите, чем вы занимаетесь, чтобы наши зрители поняли ваш опыт. Потому что ребята по ту сторону экрана, они как раз идут к тому, чтобы стать ИТ-специалистами, и им будет интересен ваш опыт.

[00:01:20]

Сергей коротко о себе и своём опытее

Да. Всем привет! Меня зовут Сергей Артюхов. И, как правильно сказал Александр, я консультант по организационным изменениям. Это если коротко, а если немножко подробнее, в моей работе несколько составляющих. Во-первых, всё связанное с производственным процессом: как «айтишники» работают, как CI/CD-процессы настроены, как всё выкатывается до промо, до пользователей. В конце концов, ИТ и продуктовая разработка нужны для того, чтобы мы создавали ценность для клиента.

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

Кроме организации процесса я ещё занимался анализом этого самого процесса, визуализацией и представлением для руководства того, как работает тот или иной кусок продуктовой разработки или бизнеса. Если коротко, это, наверное, всё.

[00:03:04]

О понятии производства в ИТ

Окей. Я думаю, сейчас понятно. Я чуть-чуть уточню. Сергей сейчас сказал о производстве. Во всех бизнесах производство — это там, где создаётся продукт. И я думаю, нам понятно, что Сергей работал с программистами, и все компании, которые он перечислил, — и Сбербанк, и М.Видео, и Крок — у них есть большой блок цифрового продукта, есть сервисы, которые они делают, и я думаю, частью из них вы пользуетесь.

Я тоже с М.Видео взаимодействовал и тоже пилил для них сервисы. Весь сервис работы их карт лояльности, связку с САПом написал я ещё в 2010 году примерно. Надеюсь, это работает, а, может быть, уже поменяли, не важно. Но мы где-то с Сергеем пересекались по предметной области.

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

[00:04:41]

О трендах разработки и актуальных методологиях

В связи с этим хочется понять. Вот вы работали с этими крупными компаниями достаточно продолжительный период времени. Какие вы со своей стороны видите тренды? Как меняется в принципе сам подход к разработке? Что новое появляется, что отмирает? Возможно, ребятам было бы интересно понять, куда эта вся махина движется. Потому что тот же Сбербанк и М.Видео — они стараются делать такие флагманы, приносят всё новое.

Смотрите, вот вы описали некоторый процесс, который в народе называется «Водопадом» или каскадной моделью — по-разному называют, но это Waterfall. Это от той идеи, которая зародилась в чьей-то светлой голове до момента, когда пользователь увидел это у себя, непосредственно в приложении где-то в телефоне или, например, на кассе Сбербанка.

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

Так вот, основной тренд, который наблюдается приблизительно с 2016 го года — это переход на так называемые Agile-рельсы, когда мы не пытаемся сделать большой каскад на годовом цикле или на полугодовом цикле, а хотим делать что-то каждые n недель. В индустрии сложилась практика, что этот период — две недели. Но не обязательно. У меня были команды, которые работали каждую неделю и что-то выкатывали, а в какой-то момент мы дошли до состояния, когда настроили все процессы CI/CD-тестирования, всё автоматизировали, и релизы были каждый день. И, мне кажется, что индустрия глобальная идёт именно в эту сторону — в сторону большей автоматизации производственного процесса, о котором вы рассказали.

То есть сокращение производственного цикла и сокращение итераций в Agile. Спринт сжимается до дня.

Вот со спринтом я бы не стал так делать, потому что, если мы говорим о спринте, мы подразумеваем Scrum как операционную модель, фреймворк создания продуктов. А Scrum тоже требует на своё обслуживание, и эти расходы становятся неприемлемы внутри дня. Если мы делаем ежедневные спринты, то слишком большой процент capacity съедает сам Scrum. Нам не очень эффективно.

А теперь я хотел бы сказать вот о чём. Во-первых, есть исследования DORA (DevOps Research and Assessment) — конторы, которую, если не ошибаюсь, купил Google в своё время. Они выпускают State of DevOps, в котором говорят, что проанализировали достаточно большое количество компаний и видят, что есть «медленные» компании, их становится всё меньше и меньше. Медленные — те, у которых цикл поставки от года. Потом есть средние — это полгода.

Поставки чего? Продукта?

Да. Это как быстро мы поставляем и как часто. Как быстро мы заканчиваем фичу — что-то, что непосредственно находится в поставке. Эти две метрики, о которых я сказал — deployment frequency (частота поставки) и lead time for changes — время от первого коммита до момента, когда мы всё собрали, «смёржили», протестировали и выкатили в промо.

И есть некоторые «быстрые» компании или команды, которые работают на цикле продолжительностью в неделю-две. Но в нескольких последних DevOps-отчётах стали упоминаться «элитные» компании: у них lead time — день, deployment frequency — каждый день или даже чаще. Вот это состояние, к которому необходимо прийти. И, на мой взгляд, автоматизация, то, внутри чего мы непосредственно все работаем: и вы, и я, и ребята, которые нас смотрят — это информационные технологии, направленные на то, чтобы снимать количество рутины с человека и делать так, чтобы он не пыхтел. Машина железная, она не устаёт. А люди, к сожалению, устают. Поэтому нужно , пусть это может быть дорого, сделать так, чтобы на долгом промежутке времени многие вещи автоматизировать и за счёт этого снижать потери на переключение, на передачу информации, и при этом ускорять поставку. Почему нужно ускорять поставку? Можно я ещё об этом скажу?

Давайте.

Потому что бывает такая ситуация, что вроде написано ТЗ и всё понятно, и «с той стороны» заказчик абсолютно согласен со всем, что там написано, всё подписали, у нас есть договор, мы пошли работать. Проходит полгода или год, в зависимости от того, какой объём работ, и, даже если мы успели в срок, что в ИТ, прямо скажем, не так уж часто происходит, но, допустим, мы успели. Приносим работу, а заказчик говорит: «Ребята, здорово, что вы пришли, но, к сожалению, бизнес изменился. И то, что вы принесли, уже не актуально». Но у нас есть контракт, обязательства — человек должен заплатить. Вот, чтобы снизить такие риски, вероятность того, что мы сделаем не то, нужно ускорять поставку. Чтобы можно было чаще инспектировать направление движения к цели и саму цель, и корректировать при необходимости. Например, когда от внешней среды поступает сигнал о том, что мы идём не туда и надо корректировать направление.

Хорошо. Вот, что я услышал. Первый тренд, который мы могли бы для себя отметить, — это ускорение поставки продукта конечному потребителю.

Да.

То есть сокращение производственного цикла и всё более частые поставки. Пускай это не какой-то большой набор фич, собранный в огромный релиз, а просто выкатка отдельных фич. Мы используем сейчас с Сергеем ряд терминов, конечно. Возможно, не все они понятны зрителям. Фичи — это новые возможности в рамках программного обеспечения того или иного сервиса. Релиз — это, соответственно, набор таких новых функций, которые собираются в единый пакет и выкатывают как некое обновление. Выкатывается — это значит, что с тестового стенда они выходят на стенд либо на сервер, который используют конечные пользователи, то есть на платный сервис, как правило. Когда новые фичи сервиса становятся доступны реальным клиентам — это и есть релиз. То есть мы отдаём новую версию программного обеспечения для пользования клиентам. Это первый тренд, о котором мы поговорили.

Вы упомянули несколько технологий, о которых я тоже говорил. Это Waterfall, когда мы детально понимаем, чего хотим, и способны это всё описать и сразу сказать. И мы коснулись Agile-подхода, ориентированного на то, что зачастую мы не знаем всего, что хотим. Часто бывает так, что идёт продуктовое исследование, продукт пилится за исследованием, собирается обратная связь от потенциальных клиентов и постоянно идёт «допиливание». Это гибкая технология разработки, она помогает подстраиваться. В каких проектах это имеет смысл? Чтобы ребята понимали. Ведь есть ещё канбан — другой совершенно подход. Может быть, вы поделитесь опытом, особенно с теми, кто хочет стать руководителем проекта, как понять, близок тебе проект или нет, какая методология в нём применима, когда приходишь, слышишь некий запрос, тебе брифуют, что это будет за проект? Потому что кто-то хочет работать с Waterfall: «Вы мне дайте [вводные], я всё распишу и шаг за шагом буду “закатывать” это». А кому-то Scrum интересен, когда постоянно что-то прилетает и весь менеджмент в компании «с колёс», так что каждый день меняются приоритеты. Кому-то такая движуха нравится, а кому-то нравится просто создавать новый продукт.

[00:14:05]

Как выбирают методологию управления проектом

По каким критериям вы, эксперт в этой области, выбираете методологию проекта? На какие факторы вы смотрите, снимая требования с заказчика?

Окей. Я попробую ответить с разных точек зрения. Первый ответ, который хочется дать, — это модель Cynefin. Есть такой дедушка Дейв Сноуден…

Зрелый мужчина.

Зрелый, да, мы против эйджизма, согласен. Так вот, Дейв Сноуден придумал модель «Кеневин» (Cynefin), название которой на валлийском языке его родном означает «среда обитания». Он выделяет четыре домена: первый — clear/simple («очевидный»), второй — complicated («усложнённый»), третий — complex («комплексный», «неочевидный») и четвёртый — chaotic («хаотичный»).

А это домены чего?

Это домены ситуаций, с которыми вы можете столкнуться в рабочем контексте и вообще в жизни. Но если мы говорим про бизнес...

Тогда вам описывают некую задачу.

Да. Вам говорят, что есть некая задача, и вы говорите: «Ага, мне всё понятно. Я могу взять документ, открыть, и там написано, что я должен сделать. И я могу просто всё это повторить. Более того, если вдруг, не дай бог, я отклонюсь от этой инструкции, потому что у меня есть голова на плечах, то мне дадут по рукам и правильно сделают, потому что там написана best practice — только так и никак иначе. Это simple-домен, его ещё obvious называют [сейчас переименовали в clear].

Его уже делали тысячу раз до меня.

Да.

Просто не надо думать.

Просто копипаст.

Да. Как говорил Генри Форд: «К сожалению, с парой рук я получаю ещё и голову». Вот для таких вот ситуаций…

Рук достаточно.

Достаточно рук.

Или военного человека, который делает всё чётко по инструкции.

Так точно. И здесь соответствующее лидерство. Например, продакт-менеджер здесь достаточно директивен. Может быть, вы слышали такое понятие, как супервайзер. Он следит за тем, чтобы всё выполнялось чётко по инструкциям. И он следит только за этим.

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

Продадут в начале.

Согласен! Если длинный цикл поставки, сначала нужно продать, потом идти разрабатывать. Так вот, всё понятно — в этом домене живёт «Водопад» и отлично себя чувствует.

А в первом домене?

В первом, если мы говорим о проектном управлении, там есть просто инструкции: бери и делай. А если нужно оптимизировать именно сам процесс следования инструкциям, то можно применить канбан…

Теперь переходим справа налево, и у нас появляется уровень неопределённости. До этого у нас росла сложность, а теперь у нас растёт не только сложность, но и неопределённость. И это значит, что… Знаете советскую поговорку «знал бы прикуп, жил бы в Сочи», да? Тут ситуация такая же. Если бы кто-то мог сказать: «Сделай вот это и получишь Убер или Нетфликс, или Фейсбук» — надо идти сделать. Станем все миллионерами. К сожалению, в продуктовой разработке (тренд в том, что становится больше именно продуктовой, а не проектной разработки) нет определённости, что нужно сделать, чтобы на этом заработать. Если кому-то не нравится слово заработать, скажем «создать максимум ценности». Так вот, к сожалению, этого хрустального шара нет, куда можно было бы посмотреть, и поэтому необходимо экспериментировать.

Все эти прекрасные умные слова: гипотезы, проверки, статзначимость, А/Б-тесты и прочее — они о том, что здесь мы не знаем точно, что нужно, и здесь нужно просто пробовать. Потом, собирая данные, мы можем их проанализировать: у нас же светлые головы. А ИТ в целом, мне кажется, — это такая достаточно маленькая прослойка очень умных людей. Вот они проанализируют и скажут: «А, ну понятно, тебе нужно сюда идти». При этом они идут точно так же. То есть понятно, что есть какой-то следующий шаг, но мы не уверены на 10 шагов вперёд, мы не знаем, куда идти.

Ну и последний домен — «Хаос» — тут всё понятно, что ничего не понятно.

Соответственно, в третьем домене живёт Agile?

Да, живёт Agile, и сюда можно и Scrum, и канбан, и всё что угодно. Если мы говорим про масштабные разработки, есть фреймворки типа LeSS (Large Scale Scrum), Nexus — другой способ масштабирования Scrum; и SAFe (Skill Agile Framework). Собственно, вот это основные способы масштабирования. Есть ещё DAD и другие, не столь популярные в России. А в России популярны, по сути, два способа масштабирования: SAFe и LeSS.

[00:19:46]

Ключевые отличия между подходами к масштабированию разработки SAFe и LeSS

В чём между ними разница? Сейчас ребята услышали для себя новые термины, как им понять, каким путём идти? Есть два подхода. Вроде было всё понятно: слово Agile все практически слышали. Особенно спасибо Грефу, который везде с 2016 го года про это рассказывал. И для меня было удивлением, почему только в 2016 году это попало всё в бизнес. Потому что в программировании уже в 2010 году в России даже по Agile работали очень много компаний, и им было странно: чего тут нового? У них давным-давно это живёт. То есть как понять, каким фреймворком пользоваться? Что к чему применимо?

Скорее всего, что бы я сейчас ребятам ни сказал, за них уже выбор сделали, поэтому можно расслабиться. Но если попытаться очень кратко рассказать, чем отличаются эти два подхода, принцип очень простой. Есть Scrum-гайд — всего 17 страниц, и я прям рекомендую каждому прочитать. Желательно не один раз.

А где искать?

На сайте ScrumGuides.org. Читайте Scrum-гайд, там написаны очень простые вещи, прямо простые-простые. Должен быть владелец продукта — человек с видением, который максимизирует ценность. Есть команда, есть Scrum-мастер, они что-то делают, у них какие-то события, куда-то они приходят. У них какие-то артефакты, какие-то правила. Вроде понятно. А теперь возникает вопрос. Вот написано, что команда — это маленькая сущность. А что делать, если у меня сложный продукт? Большая часть энтерпрайз-разработки — это сложные продукты. Там заняты сотни и тысячи человек. Возникает вопрос: что делать с этим Scrum, когда мы хотим расширить разработку? Одни говорят: «Давайте разделимся и каждый сделает по кусочку этого продукта. У каждого кусочка будет свой владелец продукта. Мы этих ребят объединим в некоторый value stream, и, если будет несколько продуктов, будет несколько больших-больших групп, которые будут заниматься каждая своим направлением. Их ещё называют трайбами, value steam’ами — по-разному. И у каждого будет свой владелец продукта со своим бэклогом, со своими скрам-мастерами. Короче, будет много-много маленьких команд.

В общем, делим большое на маленькое. «Разделяй и властвуй».

Так точно. Что говорит подход LeSS? Он говорит, что если есть один владелец продукта со своим бэклогом, то, сколько разработки ни было, это один продукт. То есть требования к нашей работе мы получаем только из одного источника. Это раз. Второе — есть маленькие командочки. Они всё ещё маленькие, но они все объединены вокруг большого продукта и единого источника требований.

Теперь принципиальная разница. SAFe предлагает продукт разбивать по-всякому: можем компонентным образом разбить или по кусочку value stream — как угодно. То есть в целом у нас достаточно большая гибкость.

LeSS говорит: «Нет, ребята, это всё здорово, конечно, но нет! Конфигурация команды такова, что позволяет взять любую фичу из этого бэклога. Какие бы компоненты ни затрагивались, надо брать и делать.

И тут мы говорим про ещё один тренд, если вернуться к тому вопросу. Есть тренд на T-Shaped. Это заезженный термин. Вот T-Shaped — он вроде тренд, но такой немножко слабенький, потому что, с одной стороны, о нём почти все говорят, все слышали как минимум, что надо быть мультифункциональным, кросс-доменным и так далее. Но при этом, если вы открываете HH.ru или другой источник вакансий, там написано: «Мне нужен Java-разработчик со знанием Hibernate». Понимаете? И всё. А в другой вакансии, например: «Мне нужен тестировщик». Вопрос: что, автотестировщик не пишет код? Пишет. У него какое-то слишком сложное задание? Да вроде нет. Этот специалист и тот, этот инженер и тот инженер. Зачем это композирование? И вот, собственно, такой тренд в каких-то областях есть, но в целом — in general — опять-таки, в России он пока не очень силён. То есть он, может быть, зарождается.

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

Да, желательно.

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

Согласитесь, что скорость взаимодействия с этими ребятами высокая?

Да. Получается так: что-то быстро надо, ты прямо понимаешь, что «деньги здесь». Ты зовёшь специалиста: «Давай, Серёжа, вот это надо сделать. Вот на столько миллионов задача».

Отлично!

Он всё бросает и говорит: «Сейчас сделаем». И мы с ним, например, вдвоём можем за несколько дней сделать вещь, которая какой-то рывок создаст бизнесу. А есть задачи, которые действительно пилятся с разделением: есть логика бэкенда, есть фронтендовая большая часть. И, действительно, задача напиливется на какие-то отдельные компоненты. Компоненты — это часть. Есть, например, сервис. Как правило, сейчас подход к разработке микросервисный. Можно либо микросервисом, либо компонентом эту часть назвать. Декомпозированная большая задача…

Доменная модель просто разбивается на разные кусочки, которые вы отдаёте людям.

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

Разница в этом: есть универсалы и есть специализированные люди, сбитые в команды, которые пишут отдельные задачи, и потом это всё собирается в один релиз. Вот это подходы разные в Agile — чтобы вы понимали, как этим можно пользоваться.

Вы знаете, мне кажется, что в плане доступности для понимания прямо отлично получилось, но, с точки зрения жизни, оно не совсем такое.

Давайте дополним.

Всё равно есть бэкенд и есть фронтенд, но просто, например, я бэкендом занимаюсь только в отдельном сервисе. И шаг влево, шаг вправо — там я уже не делаю. Понимаете? Я вот об этом больше говорю. Это про mind set — образ мышления или взглядов на жизнь. Один подход в том, что вот моя «поляна», там всё красиво, а что снаружи меня не очень волнует. А другой подход — это когда мне интересен мир вокруг, каким бы он ни был многообразным, сложным и, может быть, даже опасным. Мне это интересно. Мне кажется, что инженеры и разработчики как люди призваны бороться со сложностями, им должен быть ближе всё-таки второй подход.

Второй mind set в том, что не сейчас, не сегодня, но через месяц, два или три человек расширит свои компетенции и всё большую полянку будет «покрывать». Означает ли это, что он должен фронт писать? Нет, конечно! В этом зачастую нет необходимости. Мы можем найти человека. Вот у меня есть пара знакомых фронтендеров, которые в момент сложности с релизом в конкретной команде говорили: «Ребята, давайте я напишу чуть-чуть на бэке. Понятно, что я напишу как тираннозавр рекс: у меня такие маленькие лапки, я чего-то этими кривыми лапками сделаю — вы меня потом на код-ревью «замочите». Но я вам хоть чуть-чуть помогу, хоть маленькую сниму с вас проблему, чтобы вы двигались дальше». Вот я об этом скорее. Больше про отношение к тому, что «это не моя поляна, а твоя поляна». Есть ещё выражение not in my backyard.

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

И здесь получается, что, если говорить про трек специалиста, он обычно движется от узких задач к максимально широким. И в тех терминах, которые мы упоминали — бэк/фронт — кто-то начинает с фронта, кто-то с бэка, где-то ещё есть девопс-часть, и потом все двигаются к фулстекеру, который, в принципе, везде на твёрдую четвёрку может работать. Это как есть летняя резина и зимняя резина. А есть всесезонная. И вот фулстекер — это «всесезонный» человек, он всё может. Нельзя сказать, что всесезонная резина даст фору, например, летней на мокрой дороге или зимней на льду. Но всё в принципе качественно. И специалист-универсал решит задачу так или иначе. Если надо, чтобы прямо с блеском, как в Формуле-1, то под конкретную погоду надеваюм резину.

Это просто дороже стоит, требует большей команды и другого бюджета. И мудрые спонсоры всего этого банкета определяют, насколько шикарно они хотят его закатить. Есть проект, и если они хотят прям очень шикарно, они слайсами нарезают команды спецов и потом начинают «котлетами» отстёгивать приличные суммы, чтобы это всё реализовать.

А есть более скромные проекты, где говорят: «Мы в таких-то рамках, нам нормально будет, и так зайдёт, а если полетит, вот тогда уже мы разойдёмся». Да, окей, это мы шаг в сторону сделали, разобрали немножко термины, чтобы понятнее было.

[00:31:00]

О методологии в домене «Хаос»

Остался «Хаос», насколько понимаю, — четвёртый домен.

Да, в «Хаосе» есть только одна методология. Не знаю, насколько можно ругаться...

«Бери–бросай», да? Бери больше. Бросай дальше.

Идея в том, что «просто сделай это». Там есть некоторое слово на букву F, но я не буду его произносить.

Ну понятно, да. В английском языке только одно неприличное слово на букву F.

Вот это оно и есть!

Потому что ситуация хаоса… Что такое хаос? Банальный пример — наводнение или горит дом, то есть происходит какой-то катаклизм. У вас упал сервак, и можно, конечно, экспериментировать, но, извините, каждая минута стоит миллион долларов…

«Ну, неделю где-то будем решать…»

Да-да: «Вот сейчас нам нужно спроектировать эксперимент, собрать данные, всё продумать». Нет-нет, ребята, он горит! Вот прямо здесь и сейчас давайте поднимем, а потом вы будете анализировать, встречаться, делать фасилитации, мозговой штурм и анализы root cause — всё что угодно, но потом! Сначала заткнули дыру, выжили в ситуации, а остальное…

То есть это подход «тушение пожара».

Так точно.

Понятно. То есть появился ещё четвёртый подход, помимо всего, о чём мы говорили, — это тушение пожаров. И самое главное — чтобы в любом проекте вся работа не сводилась к тушению пожара.

Да, если вы постоянно в нём, то что-то не так.

Что-то явно не так, надо на какой-то момент откатиться, остановиться и начать заново, потому что так невозможно.

Знаете, мне очень нравится Максим Дорофеев. Он говорит, что «в любой непонятной ситуации — думай». К сожалению, даже в среде столь умных, казалось бы, людей, в среде, которая подразумевает наличие и необходимость применения мозгов, мы постоянно бежим и думать не получается. Есть язык — может быть, вы слышали — Clojure.

Нет.

Это функциональный язык на базе JVM. Мне он очень нравится, я такой себе программист, но мне нравится. И автор этого языка, Рич Хикки, ввёл термин Hammock Driven Development («разработка из гамака»). Гамак — это когда вы сидите, ничего не делаете, руки от клавиатуры убрали и думаете над задачей. Вот эта ситуация довольно редко встречается, потому что нужно здесь и сейчас, быстрее- быстрее, потому что бизнес поджимает. Но иногда хотя бы нужно выделять себе время для того, чтобы подумать.

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

Я приведу пример. У меня был продакт, у которого почти любая ошибка была крит[ической]. Вот что-то произошло в проме — продакт говорит: «Ребята, это крит! Надо срочно чинить!». Но мы при этом понимаем, сколько критов можно сгенерировать в единицу времени в команде, даже не знаю, криворуких мутантов. Crit — это critical.

Продолжаю режим «онлайн-переводчика».

Да, спасибо.

Критические ошибки — те, которые останавливают работоспособность системы. Они приносят существенные потери бизнесу. И тут важно, чтобы в проекте был человек, который может оценить, на сколько денег крит. Потому что я обычно спрашиваю: «Какими деньгами исчисляется этот вопрос?» Если это рубль в час, то подождём. У нас тут есть задача на миллионы — и её надо прямо сейчас. Здесь всегда вопрос ценности.

[00:35:11]

Про отличия между канбаном и продуктовым подходом

Супер. Мы разобрали домены, чуть-чуть приземлили для ребят сами подходы: что канбан лучше брать, когда всё по сути понятно, есть достаточно хорошая детализация, берётся Waterfall и последовательно всё это пилится. А когда есть неопределённость, мы занимаемся продуктовым подходом. Тут появляется как раз Agile: надо исследовать что-то, смотреть, как двигаться. И «тушение пожаров» — это уже когда в уже работающей системе какие-то критические ошибки происходят и надо решить, что с ними делать. Это приземлили.

Можно я один момент уточню?

Да.

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

Понятно. Супер. Надеюсь, всем понятно, зачем это уточнение было сделано. Это, опять же, из практического опыта. Потому что самое ценное, что любой специалист имеет — опыт. И мы стараемся приглашать экспертов, чтобы вам сэкономить время. Человек 10 лет проживал это, страдал, все эти «грабли» прошёл и говорит: «Тут направо, тут налево, тут два шага вперёд» — чтобы вы по этим граблям больше не ходили и быстрее дошли с минимальными потерями до желаемого результата.

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

Они чуть-чуть были. Например, Skyeng уже был, позиция продакта была, но популярности такой не было.

Да. Но, если говорить про Skyeng, там ребята это только начинали, Гоша начинал где-то в 2014 году, мы с ним общались, и они пилили, думали, как это всё разворачивать. Я первый раз с этим столкнулся, наверное, году в 2010. С продуктами в Мегаплане. То есть я пришёл в Мегаплан, и там ребята уже мыслили продуктом Мегаплана. Мы начали размножать этот продукт, то есть брать его фреймворк и создавать рядом новые продукты на базе той же функциональности. Для меня это было ново, потому что я пришёл тоже из энтерпрайза: мы работали с САПом, там было всё напилено по большей части. Берётся решение, и ты на него наворачиваешь сверху некую адаптацию под конкретные требования данного проекта. То есть натягиваешь систему на бизнес-процессы. Действительно, это была проектная деятельность. Вот бизнес-процесс, вот система — пожалуйста, соедините их так, чтобы они работали.

Тут нет конечного потребителя, кроме того несчастного бухгалтера или логиста, который страдает, потому что ему надо три дня заполнять отчёт в Excel. И надо сделать так, чтобы это было за две секунды. Вот и проект. Продукт непонятен.

А вот когда ты выходишь на рынок массового потребителя, где на той стороне сотни и миллионы людей, которые пользуются этим… В том же Мегаплане было 100 000 компаний, которые его на тот момент уже использовали. И любое изменение, которое ты им даёшь, либо критически улучшает их жизнь, либо критически ухудшает её. И тебе надо чётко понимать, как обеспечить первый вариант — критическое улучшение.

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

Слушайте, отличный вопрос. О причинах — мне кажется, это интересно. Давайте я начну «думать об вас». Первая причина, которая, кажется, лежит на поверхности, — это рост конкуренции во всех областях разработки. Если вы откроете телефон, там сотни и тысячи однотипных приложений борются за ваше внимание, за место на вашем экране. Это значит, что, если мы не будем смотреть на клиента, мы потеряем рынок. Почему раньше так не было? Потому что у вас не было такой скорости и такой доступности, я бы сказал. Это звучит странно, с учётом того, что в России, если я не ошибаюсь, порядка миллиона незакрытых вакансий. То есть достаточно большой спрос. Но всё равно, десять лет назад сколько айтишников было? Тогда и сейчас — несопоставимые вещи.

Но вакансии растут быстрее, чем вот эти специалисты вызревают, да?

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

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

Я пытаюсь придумать вторую причину, почему это вдруг стало так популярно. Я уверен, что, если бы мы с вами говорили вчера, я бы что-нибудь ещё придумал, но пока у меня почему-то нет идей, почему именно продуктовый подход.

[00:42:17]

О становлении специальности продакт-менеджера

Ну, я пока могу свою идею подкинуть, как я вижу это.

Можно я попробую сейчас? Я прошу прощения.

Да.

Мне кажется, что в какой-то момент… Ведь продакт-менеджеры появились, я боюсь соврать, — меня можно и нужно перепроверить, — в 1970–1980 годы. Они появились как бренд-менеджеры — люди, которые занимались брендами, и внутри продуктов уже были продакт-менеджеры. То есть это появилось не в двухтысячные и даже не в девяностые, а ещё там. Почему так случилось? Потому что проекты, они ведь тоже начали расти как на дрожжах. Вот оно всё растёт, и в какой-то момент, я сам наблюдал ситуацию, когда один проект снял другой или один проект ухудшал результаты второго. И нужен был человек, который бы смотрел на всю большую поляну, развивал бы в целом одно направление или одну продуктовую историю и мог сказать: «Ребята, мы выравниваем это вместе, бежим все на юг или на север. Мышка станет ёжиком». И вот эта роль появилась вследствие большого количества запросов на изменения в компании. Извините, я вас перебил.

Не-не, без проблем. Я просто дополняю. Как я вижу, рынок всех сервисов, если брать сектор b2c... Я начинал в b2b, потом мигрировал туда и, может быть, на этом переходе я и почувствовал отличие. Раньше заказчики были внутренние либо корпоративные, а тут заказчиками стали конечные потребители, которые платят деньги свои личные. И за счёт того, что изменилась сама инфраструктура взаимодействия: появились мобильные телефоны, смартфоны, развернулся полноценно Web 2.0, появились социальные сети, а у них — приложения и какие-то свои экосистемы. Из многообразия возможностей, которые стали предоставлять пользователям, родилась та самая конкуренция, о которой вы сказали, да? И, по сути, такие платформы, как Apple и Google, Facebook, ВКонтакте и прочие — они создали площадки и дали возможность людям проявить инициативу в создании этих продуктов. Дали простор для творчества. Они сказали: «Вот карандаши, вот бумага — малюем, чего хотим. У кого будет лучше, того и продадим потом через NFT» — это забегая вперёд, к текущим трендам. Появилась среда, в которой стали необходимы люди с компетенцией именно понимания, за что человек готов платить, какие проблемы ему надо решить, какие у него потребности.

Например, в 2007 году вышел Тим Кук и сказал: «Теперь телефон будет таким». Все сказали: «Так и с кнопками же нормально было». А потом — оп! — и через пять лет кнопок не стало. Что-то произошло. И он сказал: «А у нас внутри есть AppStore. Вы можете сами ставить приложения». Все говорили: «Так обычно Нокия сама что-то пилила и нам давала, и мы мучились, но пользовались». Он говорит: «А теперь нет. Теперь вот как бы свобода. Разработчики что придумают, то вы и сможете использовать». И, мне кажется, это технологическое изменение дало простор. И технологии вызрели, в том числе и разработческие технологии. То, что можно было делать, например, на PHP версии 4.0, и то, что можно делать в 7.0 и 8.0 — это принципиально разные технологические возможности. И вот здесь вышли продуктовые менеджеры, которые пошли со своими customer development’ами и начали спрашивать людей: «А чего вам надо? А сколько вы готовы платить? А вот вам триальчик, пожалуйста, — чтобы мы посмотрели, какая доплачиваемость, кто переходит на платную версию». К примеру, сначала бесплатно месяц пользуемся, потом смотрим, какая часть начинает за это платить. Вот эти все А/Б-тесты появились.

То есть, по сути, стёрлась грань между потребителем и разработкой: их как бы соединили. И вот здесь ценность продуктового менеджера, мне кажется, вышла на первый план, потому что до этого потребительская модель была такова, что особого выбора не была. Есть Нокиа, Моторола, Сименс — более или менее одинаковые. Выбирали цвет или форму скорее, а внутри начинка была одна и та же. Это если говорить про мобильники. Или, если про компьютеры, с Windows и Macintosh тоже очень похоже было. Не было такого многообразия: «Пожалуйста, пользуйся».

А вот в играх, наверное, сразу была история. Если вспомнить, о чём вы говорили, я абсолютно согласен насчёт бренд-менеджеров, они действительно были. Например, если взять какой-нибудь издательский сектор, где продукция — книги. Там бренд-менеджеры работают с автором и аудиторией, соединяют их, привносят идеи и так далее. Та же самая работа, что и у продакта.

Там тяжело делать А/Б-тесты, конечно.

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

И до сих пор нас часто спрашивают, чем вообще отличается проджект-менеджер от продакт-менеджера. На ваш взгляд, где граница, которая 100% к продакту, и какими качествами должен обладать человек, чтобы стать успешным продактом, в отличие от проджект-менеджера?

Я хочу добавить по предыдущей теме. Мне кажется, что есть ещё одна причина, почему вдруг появился продакт-менеджер. Мы уже говорили про четыре домена. С развитием технологий, с развитием ноосферы, биосферы и так далее — уровень неопределённости растёт. И, глобально… Мне кажется, это Джобс сказал, а не Тим Кук, но это неважно.

Ой. Джобс, да. А я сказал Тим Кук?

Да. Ну, просто он уже так давно, что он почти как Джобс.

Извиняюсь. Я уже привык...

Мы перестали понимать, какие потребности дополнительно надо закрыть, потому что, если уж быть максимально честными, у нас закрыты практически все потребности. И всё, что мы делаем, что делал ещё маркетинг до того, как это перешло в ИТ, — он создавал новые потребности. Так вот, создавая потребности, ты не понимаешь, «попал» ты в итоге в самое сердечко человека, ради которого всё делал, или «не попал». И вся продуктовая история заходит уже во внутренние продукты. Например, HR-система какая-нибудь. У вас же есть пользователи, которые приходят и они говорят: «Слушайте, мне как-то не нравится». Я как-то устроился в компанию, где вместо Outlook был Lotus. Я там не смог работать, серьёзно. То есть я пять лет сидел в Outlook. Это был нормальный Outlook, и потом вдруг появился Lotus, который как будто из 1990-х — это тогда ещё мне казалось. Это было достаточно давно.

Для наших зрителей: Outlook — это инфраструктура Майкрософта, часть Microsoft Office для базового взаимодействия через письма, календари. Он всё это автоматизирует. Ну а Lotus Notes — это действительно старая штука от IBM про электронный документооборот. Наверное, сейчас вы его уже и не встретите.

Есть компании. Ну да ладно… Так вот, я понял, что компания внутренне проиграла конкуренцию с другими такими же. Потому что в целом проблемы найти работу принципиально не было. Но была история, что ты приходишь и тебе некомфортно, неудобны площадки коммуникации, которые выстраивает компания внутри себя. Ты говоришь: «Нет, я не хочу. Просто не хочу».

Поэтому, мне кажется, что конкуренция идёт не только за клиента, но и за сотрудника. И сейчас мы, кстати, это наблюдаем. В результате появляется пространство, внутри которого бизнес готов платить деньги, зная заранее, что часть экспериментов не принесёт результата. Вот отсюда вся штука с продуктовым подходом и пошла. Это была долгая прелюдия к вопросу «проджект или продакт».

Есть разные точки зрения, я придерживаюсь той, что продукт мы создаём в серии проектов. То есть мы бежим от цели к цели, как в том же Скраме, при этом в работе над каждой новой целью вы создаёте дополнительный инкремент, который улучшает метрики, бизнес-показатели, удовлетворённость пользователя и вообще в целом ту ценность, которую мы несём потребителю с помощью данной серии проектов.

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

Если говорить про домены, которые мы разбирали, то продакт живёт внутри комплексного домена, а проджект живёт внутри complicated-домена («усложнённого»).

Проджект берёт экспертов, организует их работу, и они затаскивают результат. А продакт сначала проводит множество экспериментов, чтобы собрать статистику. Как известно, есть ложь, большая ложь, и есть статистика. Так вот, статистика такова, что каждые девять из десяти гипотез — в молоко. И задача продакта — придумать, как организовать процесс, чтобы как можно дешевле отбрасывать девять и выявлять одну, которую можно отдавать в процесс производства.

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

А ещё лучше — сразу из десяти брать ту, вероятность выстрела которой выявляешь, опираясь на свой практический опыт. Чтобы, когда у вас есть десять, первая из десяти выстрелила, а не десятая из десяти уже.

Это было бы неплохо, но…

Это идеальная картина.

Кажется, что это круче, чем у того венчурного инвестора.

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

Мне кажется, мы ещё раз Рубикон провели между продактом и проджектом. То есть, по сути, если человек хочет идти в новое, идти в неизвестность, если у человека есть предпринимательская жилка и его тянет на создание чего-то нового, — это продакт. Он сам по себе, может быть, чуть-чуть хуже организован, то есть более free-человек.

Да. Что есть, то есть.

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

И есть люди-проджекты, их обычно никто не знает. Ну, кто знает людей, которые затаскивают Теслу и отвечают, например, за Model S Plaid?

Там есть команда.

Кто знает, например, менеджера проекта, который работает с Porsche Cayenne? Ведь разрабатывают же сейчас новую версию Porsche Cayenne какого-нибудь или 911. Там есть конкретный руководитель этого проекта технологического, который работает с инженерами, с конструкторами, всех их соединяет, пушит постоянно, отвечает за бюджет и за всё остальное. И есть продакт-менеджер, который с дизайнерами что-то потягивает, возможно, в свободное время и придумывает, как же это будет всё круто выглядеть. И потом они это соединяют и говорят: «Будем делать вот так».

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

Это проджекты или продакты?

Проджекты. Это ещё было во времена моей работы там, с 2011 по 2014 год, вокруг меня были такие ребята. Они были очень ориентированы на результат и повёрнуты лицом к клиенту. Потому что, если ты один раз сделал хорошо, то в следующий раз ты апсейлишь, кросс-сейлишь и так далее, и ты в итоге зарабатываешь больше, растёт часть прибыли, которую ты кладёшь себе в карман. Потому что там были все предпринимательского склада — таких нанимали. А есть, конечно, проджекты, которые говорят: «Без ТЗ, без аналитиков я не работаю».

Да, то есть: «Давай, скажи, что делать и как».

«Как я могу коммитить на эти сроки?! Ну, о чём мы говорим?».

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

[00:56:22]

Рекомендации

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

Что студентам нашим смотреть, как себя дальше развивать, чтобы это максимально позитивно сказалось на их профессиональном будущем, чтобы они состоялись как специалисты в этой сфере? Может, есть какие-то принципы базовые, которыми вы руководствуетесь? На что обратить внимание?

Попробую несколько моментов проговорить. Первая мысль, которая, может быть, ещё не стала супертрендом, но я её чувствую: разница между бизнесом и ИТ очень сильно нивелируется. Они начинают проникать друг в друга. Айтишники начинают зарабатывать, бизнес начинает заниматься разработкой. Короче, это всё очень стало близко. Знаете, раньше между ними была прям стена. Вот я когда-то работал в Сбере, и там между разработкой и бизнесом была река, не только стена, но и целая река.

Бизнес — это подразделения, не относящихся к ИТ-департаменту.

Так точно. Это заказчики.

И ещё есть коммерческий департамент. Если это какая-то продуктовая сеть, там логистика есть, например, управление складами, закупками, ещё чем-то. В Сбере, например, есть, рисковики и прочие. Вот это всё бизнес. И есть отдельно ИТ-департамент.

Вот они — это айтишники, они там сидят. Раньше даже шутили про свитер с оленями. Вот это вот разделение потеряло актуальность. Сейчас айтишники — это модные ребята, да? Это не обязательно хипстеры.

Ну, на нас посмотрите…

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

А как смотреть в сторону бизнеса?

Задавайте вопросы. «Как я могу помочь компании сделать больше денег?». Включайте предпринимательский взгляд, проактивность. Это не навык, не то, что можно пойти прокачать на курсах, сделать чек-листы и посмотреть. Нет, просто будь активным — это мой совет в стиле Тони Робертсона. А если серьёзно, лично меня эта история спасала почти всегда из разных передряг. И, в частности, в карьере. Почти всегда я был просто активным. Может быть, я не самый умный, 100%, всегда были люди умнее, не самый опытный — были опытнее меня. Но это вот отношение, что мне не всё равно, мне хочется, мне интересно расширять зону своего внимания. Того, на что вы обращаете внимание. Это важный момент. Важно не перебдеть и не перетрудиться, потому что и тут и там интересно. Вам нужно иметь какой-то фокус. Например, в следующем месяце мы смотрим сюда, потом — туда, потом ещё куда-то. То есть мы расширяемся постепенно. Это мысль номер один.

Вторая мысль: ИТ — такое место, где нет точки, когда ты можешь сказать, что научился всему и тебе надо дать медальку. К сожалению, так не получится. Поэтому, например, я как разработчик не получился, в отличие от вас, я так понимаю.

У меня получился и уже всё, вышел на пенсию. Я на разработческой пенсии.

Хорошо. Так вот. А из меня не получился. Я каждый раз думал, что надо вернуться. Потом понял, что то, что я знал, когда я что-то писал, оно не просто устарело, оно вредно. Надо просто забыть, закопать и больше не возвращаться к этому. Надо начать с нуля. Это немножко пугает. Пугает, что ИТ постоянно развивается — надо быть к этому готовым. Если вы идёте в true IT, надо быть готовым к изменениям, не то чтобы приветствовать их, но, по крайней мере, не пугаться. Это немножко другое. Вы не обязаны говорить: «Слава тебе, господи! Опять всё с нуля». Нет.

Супер. Хорошая мысль.

Должно быть так, что: «Я открыт, я готов». Если открыть Agile манифест, то мы приветствуем изменения даже на поздних этапах разработки программного обеспечения.

И в позднем возрасте.

Хорошая шутка. И, наверное, последний момент. Я у Макса это подсмотрел и у себя в канальчике об этом написал. Мне очень нравится мысль, что настоящее обучение — это не столько потребление контента, который, конечно, важен, но ещё и рефлексия, и применение изученного. Без второго и третьего первое — бессмысленная трата времени. Это похоже на edutainment, когда вы развлекаетесь, как бы обучаясь, но это больше похоже на потребительство.

Культ карго такой.

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

Я заметки делаю тезисно.

Да, меня в своё время жена за это ругала даже, говорила: «Ну как же так? Это же книжка». А я говорю: «Понимаешь, мне просто надо думать об этом, потому что иначе это всё в пустоту». У меня очень короткая память — я забываю, что вчера было. Мне надо записать. И этап применения — нужно сделать конкретный action item, совершить конкретные действия или составить план того, что вы собираетесь делать с тем, что вы прочитали и изучили. Вы увидели какой-то template документа — примените это завтра.

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

Супер.

Наверное, всё.

[01:03:24]

Короткое резюме рекомендаций

Отлично. Короткое резюме. Три вещи. Первое. Сергей нам сказал, что стирается грань между ИТ и бизнесом, поэтому важно быть человеком проактивным и заботиться о пользователях вашего продукта и стараться сделать его как можно удобнее, чтобы создать «обратную тягу», когда тебе говорят: «Давай ещё! Сделай ещё что-нибудь хорошо».

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

Третье. Обучение без практики — это деньги на ветер, то есть смысла нет никакого. Потому что услышанное не становится навыком, к сожалению. Хотелось бы, чтобы ты спал и просыпался, и уже всё вдруг умел, да? Загрузил себе знание джиу-джитсу — всё, через две минуты ты мастер джиу-джитсу.

Было бы неплохо, да.

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

Надеюсь, ребята, вы это себе тезисно выписываете. Я себе заметки пишу и рекомендую записывать мысли, чтобы потом можно было к ним вернуться и быстро, не слушая все 40–50 минут нашей беседы, прочесть страничку и понять, к чему надо вернуться.

[01:05:53]

Эксперты, с которыми возможны новые интервью

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

Можно копать в сторону исследований и продуктовой истории. Я бы посоветовал поговорить с Лизой Пшеницыной: мы с ней ведём программу по управлению проектами в одной компании образовательной. Это раз. Второе: мне кажется, если говорить о разработке, я могу найти человека, который круто разбирается в Java, Scali и машинном обучении — это Серёжа Виноградов.

Вот это было бы очень интересно.

Это мегаспециалист, он такой большой мишка, рыжий. Огромный дядька с ножами. Прекрасный.

Надеюсь, он не достаёт их на интервью.

Нет-нет. Он после.

Хорошо. Буду ходить по лезвию.

Если смотреть на тестирование и тему автоматизации тестирования, а именно на разработку фреймворков, то есть Константин Рассафонов, по-моему, так его фамилия. Он из ДомКлика. Его ещё называют профессором, потому что, во-первых, он похож на него, прямо скажем, а во-вторых, он прекрасный разработчик, который сделал фреймворк автотестирования, на котором могут автоматизировать приёмочные тесты даже аналитики, даже продакты. Ладно ещё аналитики, но даже продакты могут. И, на мой взгляд, это штука, которая просто недооценена рынком очень сильно.

Ну, автоматизация тестирования вообще недооценена.

Это очень крутая штука, которая… Вот я буквально недавно разговаривал с одним из продактов, он говорит: «Мы по кругу бегаем и ищем баги. Тут починили — там сломалось. И мы вот так бегаем-бегаем-бегаем». Так вот, чтобы этим не заниматься, тестирование нужно автоматизировать.

Чтобы регресс-тестирование было автоматизировано...

Я с вами полностью согласен.

Окей. Мы зафиксировали. И как-то контакты сможем получить?

Да, легко.

Чтобы мои коллеги связались и попробовали договориться с этими людьми. Супер.

[01:08:17]

О перспективе записи экспресс-курса по Agile

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

Потому что мы понимаем, что сейчас есть тысячи всяких слайсов, очень разных даже в проджект-менеджерстве. Кто-то, как мы говорили, хочет работать только по Waterfall и по-другому не хочет. А кто-то нет: «Мне больше Agile-подход нравится». И вот для таких можно дать углублённо, чтобы они погрузились в манифест и могли разобрать детали, которые им можно дать из практики. Есть вероятность, что можно будет вас немножко ещё побеспокоить?

Я думаю, что мы можем это обсудить. Это более чем реалистично.

Хорошо. Всё. Там записано на камере, так что мы к вам с этим придём. Спасибо большое. Я думаю, что тема исчерпана. Мы всё рассказали. Было приятно общаться.

Спасибо большое. Аналогично.