0:03 Подкаст для тех, кто создает цифровые продукты.
0:06 Разговор с дизайнерами, исследователями, маркетологами и руководителями о том, как дизайн влияет на бизнес и пользовательский опыт.
0:13 Реальные кейсы, процессы и мнения от экспертов индустрии.
0:23 Меня зовут Олег, я дизайнер в Би САС-продукте.
0:26 Сегодня у меня в гостях Иван, тим лит команды разработки в том же Сан САС.
0:32 Мы с Иваном видимся каждый день и обсуждаем рабочие задачи, но сегодня решили поговорить на более общие темы, которые могут быть интересны нашим слушателям.
0:41 В этом подкасте мы поговорим о том, как разработчик взаимодействует с другими ролями в команде, обсудим, как размер команды влияет на процесс разработки, и еще выясним, действительно ли разработчики думают только о коде или все же держат в голове пользовательский опыт?
0:59 Рад видеть тебя в качестве гостя на подкасте.
1:02 Да, Олег, привет, спасибо за приглашение большое.
1:05 Иван, в этой серии подкастов у меня есть традиция, я прошу гостя в начале немного рассказать о себе.
1:12 И по этой традиции хочу попросить тебя: расскажи, пожалуйста, немного о себе, как ты попал в би2биса и какой путь прошел до позиции Тим Лида, да, я на третьем курсе в университете по специальности информационной системы и технологий на третьем курсе у нас начался предмет, который назывался веб-разработка или веб-технологии, что-то в этом духе.
1:35 А я уже на третьем курсе пытался устроиться.
1:38 Пытался устроиться, кстати, тестировщиком с самого начала.
1:41 Как-то интуитивно казалось, что это проще.
1:43 Кому мне сказали: тестировщик уже найден, давай попробуешь верстальщиком.
1:48 Я попробовал что-то сделать, у меня получилось плохо.
1:51 Ведущего разработчика не устроил мой код, так как я это все начал учить, понятное дело, хорошо я сделать не мог.
1:58 И после третьего курса я оставил попытки начать работать во время учебы.
2:03 А потом, после того, как универс закончил, точнее, даже перед окончанием, нужно было проходить производственную практику.
2:10 И я пришел туда, где, собственно, сейчас и мы с тобой работаем, в качестве проходящего практику.
2:15 Но меня взяли, по сути, как стажера сразу.
2:18 Я несколько месяцев побыл стажером, мне хоть и стажерская была должность, но мне сразу дали живую задачу - прям с порога.
2:27 Конечно, мне там помогали и подсказывали, но это была сразу работа.
2:32 Ну и с тех пор я здесь работаю.
2:36 Четвертый проект сейчас крупный, в котором я участвую.
2:39 Первые полгода я был стажером, потом, много лет разработчиком, но потом так случилось, что Тимлит, который у нас был три года назад, перестал им быть, но шел из компании.
2:50 Некоторое время мы работали без тем леда - два или три месяца, может быть, примерно так, вот.
2:56 Потом я предложил себя в качестве тимледа, потому что чувствовалось, что все-таки нужен кто-то, кто не просто будет хотеть как-то дирижировать, назовем это так, а еще и чтобы у этого дирижера была санкция на это.
3:11 Хотелось, чтобы это как-то было оформлено, всем было понятно, что я что-то прошу сделать, например, или какие-то мои пожелания они не просто так озвучиваются, чтобы это как-то можно было оформить и уже побуждать к действию остальных - к тем действиям, которым мне казались правильными.
3:27 Тимлит я уже третий год.
3:29 Тимлит на одном проекте, только вот на самом последнем.
3:32 Все остальные три я в них участвовал в роли разработчика.
3:37 От стажера до Тимлида.
3:39 10 лет в компании 4 продукта, и пришел к тому, что начал координировать команду.
3:45 Я хочу с тобой как раз поговорить о коммуникации в целом - разработчиков внутри компании.
3:51 Можешь рассказать, с какими ролями в команде взаимодействуешь, и какие задачи при этом решаются?
3:57 Роли сильно отличающиеся друг от друга - это заказчик, продукт оуне, как принято говорить сегодня, и подчиненные.
4:06 То есть, у нас бизнес небольшой, нет подразделений, которые являются частью подразделений, над ними еще какие-то там структуры.
4:16 Вот у нас директор, потом несколько руководителей отдельных отделов: это продажи, разработка, бухгалтерия, поддержка.
4:24 Может быть, даже они сливаются, местами сливаются, поэтому да, основные роли, с которыми приходится взаимодействовать - это непосредственно начальник, заказчик продукта нашего и мои непосредственные подчиненные.
4:37 Разработчики, дизайнер, Олег дизайнер, привет, автор подкаста, и тестировщик.
4:44 У нас тестировщик, он же и разработчик временами, но тем не менее мы сохраняем эту функцию как отдельную, так просвечивается - это нам очень помогает в работе.
4:56 Да, еще хочу тебе дополнить,.
4:58 То есть у нас тимлит разработки взаимодействует практически со всеми поддержкой, менеджерами, маркетингом, основателем.
5:06 И задачи решаются совершенно разные.
5:08 Могут быть и задачи для менеджеров то, что у них там происходит в админке.
5:13 В админке или в админке, кстати?
5:15 Мы привыкли называть админка, но можно по-разному.
5:22 задачи там, я не знаю, с поддержкой, чтобы прикрутить нормально регистрацию.
5:27 Маркетинг - тоже самое, да.
5:29 То есть, кросс-ролевое взаимодействие.
5:32 И здорово, что у нас бывают командные со звона, когда мы собираемся не просто в кругу разработки, был случай, когда мы приглашали менеджеров на дизайн-ревью, и было довольно продуктивное дизайн-ревью, мне очень понравилось.
5:46 Пришли как раз к каким-то таким хорошим решениям у нас основатель был в отпуске, и после этого продуктивного обсуждения мне на встрече с основателем уже удалось наше дизайн-решения классно защитить, потому что здорово обсудили тогда.
6:02 Я бы хотел с тобой сейчас остановиться подробнее на взаимодействии с основателем продукта.
6:08 Можешь рассказать, в чем заключается взаимодействие, где сотрудничество, а где противостояние?
6:14 Если абсолютно рабочий момент обратить, то это какое-то планирование развития продукта.
6:20 Я в нем тоже участвую.
6:22 Конечно, основная масса идей хранится в голове, так сказать, основателя, и он сам решает за приоритеты, срочность каких-то вещей, но и совместного обсуждения тех же приоритетов, например, что зачем выпускать, оно тоже есть, так сказать, обзор ближайшего плана развития.
6:40 Все остальное взаимодействие - оно такое уже оперативное по текущей работе.
6:46 Какой-то он спрашивает, как там у нас это фича, например, как у нас разработчики - кто как справляется, ему это тоже понятное дело интересно.
6:54 Насчет противостояния и сотрудничества, тут
6:59 очень интересная тема.
7:00 На самом деле очень интересный вопрос.
7:02 С одной стороны, вроде как, управленцы, и я и он.
7:06 Ну, я сколько-то, да, отчасти.
7:08 Вроде как по одну сторону баррикад.
7:11 Но на самом деле, вот, кстати, сложно сказать сложно сказать, чего больше.
7:16 Примерно 50 на 50, наверное.
7:18 Противостояние в основном такое, что понятно: бизнесу хочется побыстрее, и очень часто непонятно, а почему так долго.
7:27 Например, и не всегда очевидно, что чтобы что-то сделать хорошо, скажем, более-менее качественно, все-таки нужно какое-то время.
7:36 Вот основная заруба, так сказать, происходит здесь по поводу времени для каких-то фич, например.
7:43 Еще Тим Лит - он, как правило, таким барьером служит между бизнесом и своей командой.
7:50 Он должен ее защищать настолько, насколько он это может делать: от лишних внешних стрессов, так сказать, в том числе и со стороны бизнеса.
7:58 Поэтому тут тоже у нас с директором нашим роли противопоставлены друг другу.
8:05 Но сотрудничество, если все это противостояние таки откинуть, оно заключается в том, что мы работаем над одним продуктом.
8:13 Я должен понимать основные идеи: то, куда мы идем, не просто сесть и код какой-то писать, а понимать, для чего мы это делаем, для каких клиентов, насколько широкая там аудитория у каких-то фич, например, как быстро у нас клиенты прирастают, как быстро они отпадают, все это мы обсуждаем, все это я тоже к своей работе учитываю.
8:37 Да, ты упомянул и пользовательский опыт, к которому мы с тобой перейдем чуть позже.
8:42 Также ты упомянул даже и такие маркетинговые вещи, как прирост и отток клиентов.
8:48 Еще хочу по сотрудничеству от себя добавить: помимо того, что мы работаем над одним продуктом, имеем какую-то одну идею с основателем.
8:56 А еще есть элемент сотрудничества в том, что разработка помогает основателю найти оптимальная решение той или иной функции.
9:05 Часто основатель хвалит разработку за то, что разработка предлагает более дешевые решения, потому что это экономит время.
9:12 И еще здорово, когда основатель приносит какие-то новости, например, ему позвонил крупный клиент, он с ним пообщался, и в каком-то виде этот диалог доходит до нас, до разработки, и мы лучше понимаем клиента, лучше понимаем бизнес.
9:28 А про противостояние тоже хочу дополнить.
9:31 Еще бывает такое, когда внезапно прилетает новая фича посреди спринта, и основатель пытается как-то поменять приоритеты.
9:39 И тут, конечно, мотив такого поведения основателя в том, что он мыслит более стратегически, он видит бизнес целиком и онслит как бы результатами, он видит проблему и он представляет себе результат.
9:53 А мы находимся внутри процесса, потому что нам своими ручками этот результат реализовывать.
9:59 И когда прилетает что-то новое для нас внезапно, то может создавать напряжение.
10:04 Продукт надо понимать, что он сталкивается с реальностью, которая меняется.
10:09 И основатель реагирует.
10:10 Основатель тут можно понять, потому что он ответственный за продукт, он ответственный за всю команду.
10:16 В конце концов, он платит зарплату.
10:18 И тут здорово нас выручает процесс скрама, потому что мы можем здесь объяснить: смотри, у нас есть цель текущего спринта, а вот эту фичу мы давай с тобой перенесем на следующий спринт и возьмем ее в приоритет, да, и когда основатель делает презентацию на всю команду, где он рассказывает какие-то новости, сообщает о том, как идут дела у бизнеса, продукта - хорошо или плохо, это классно, здорово, потому что как раз дает прозрачность, понимание, откуда прилетают эти задачи, почему такие приоритеты.
10:51 И родмап ты тоже здорово упомянул, потому что он дает больше предсказуемости и более спокойный взгляд на вещи.
10:58 Какой бы этот родмап ни был, да, пусть самый самый простой, но это уже лучше, чем работать, не понимая, а что прилетит завтра.
11:08 А скажи: вот ты лидировал команды разного размера?
11:11 Можем мы с тобой сейчас сравнить, в чем плюсы и минусы работы с большой и маленькой командой?
11:17 Да, на самом деле для меня есть и плюсы, и минусы, и там, и там.
11:21 Более-менее для себя осознал, все-таки, какой-то предел управляемости команды на одного тем леда.
11:27 И я обсуждал эти вопросы с коллегами своими тоже тем ледами, и примерно мы сходимся на том, что это 5-6 человек.
11:36 Если их больше, то уже нужно как-то составлять какой-то отдел и делать несколько команд.
11:42 Когда у меня было 7 человек, конечно, было интересно то, что контекст постоянно переключается - вот с одной стороны, это вроде как сложно, с другой стороны, это интере и не скучно.
11:53 Мне это наверное больше нравилось, чем не нравилось, потому что это прям бодрит.
11:59 Конечно, стресс тут тоже появляется, когда что-то не успеваешь.
12:04 Я, как Тимлид, должен, скажем, уделить в один момент времени внимание нескольким людям, а получается, например, не всем.
12:13 Если команда побольше, то времени на разработку мою собственно.
12:18 Вот есть такая фраза: играющий тренер.
12:22 Вот играть тренеру с семьей людьми в команде почти нет времени, вообще никакого.
12:29 Что-то проектировать, да, подсказывать, какие-то решения, да, но делать самому уже нет.
12:35 Вот эта смена контекста часто, вот эта не скучность этому не нравилась, но мне не очень нравилось то, что я перестал программировать по сути.
12:44 А когда людей поменьше, то программировать уже успеваешь.
12:48 Скажем, если три человека как сейчас, то я уже успеваю программировать сам, но менеджерских задач ка,ких-то управленческих, их меньше, просто потому что меньше людей.
12:58 Чуть-чуть в этом плане спокойнее, но чуть-чуть по скучнее, но если разработку возвращаться и заседать с какими-нибудь техническими штуками на полночи, то в общем-то, сколько и здесь отпадает тоже потом быстро.
13:16 А еще я помню, что в большой команде была запара с дейриками, и мне даже как-то я включал таймер, потому что мы тупо не укладывались по времени.
13:25 И еще: если вспоминать большую команду, я помню: у нас был момент, когда мы выкатили сразу несколько больших фич, но тогда много довольно прилетело фидбэка в поддержку.
13:36 А с маленькой командой по наблюдениям цели у нас более умеренные, но звучало мнение, что они прорабатываются более качественно.
13:45 Как ты считаешь, есть ли отличия в продуктивности?
13:49 Вообще, из-за того, что у нас по сути была одна команда, когда было много человек, и тот же самый один тестировщик, наверное, в целом, может быть, было чуть менее качественно в каких-то местах.
14:01 То есть на тестировании может быть было времени чуть меньше.
14:05 А насчет продуктивности мы вооружились с крамом, и у нас есть оценка задач в сторипоинтах, довольно известная, есть такой параметр: сколько команда закрывает сторипоинтов в день на человек.
14:20 Этот параметр у нас не падает.
14:22 То есть он рос в первые недели.
14:25 Сейчас он примерно где-то остановился, но он не падает.
14:29 Поэтому просто по количеству фич, когда людей меньше, их действительно получается делать меньше, но в расчете на человека хуже не стало, а стало чуть-чуть лучше, может быть, по ощущениям и чуть-чуть быстрее, по ощущениям, просто потому что людей стало меньше, им это все как-то виднее.
14:46 Людей меньше, все в большем контексте относительно друг друга и кажется, что вот все как-то быстро делается, потому что каждый знает про каждого, когда было больше человек, там каждый из разработчиков не особо успевал за всеми остальными следить, кто там что сделал, Поэтому, может быть, такая иллюзия есть, что как-то стало быстрее.
15:08 Но в расчете на человека примерно так же.
15:11 То есть, когда людей меньше, процесс дает как бы больше прозрачности, больше понимания того, что происходит, возможно, даже больше какой-то сплоченности.
15:19 И поскольку мы с тобой уже не раз упоминали скрам, давай немножко на нем остановимся.
15:24 Если я не ошибаюсь, ты долгое время работал в продукте еще до внедрения СКРМ методологии.
15:30 Можешь поделиться ощущениями, сравнить процесс работы команды до Скрама и сейчас после внедрений?
15:36 Да, скрам, конечно, нашу работу украсил и упорядочил.
15:40 Это отмечаю не только я, но и остальные ребята тоже.
15:44 В нашем случае это больше добро, чем зло.
15:47 Ну, можно вспомнить, как мы работали до, чтобы просто с чем-то сравнить: до явного скрама у нас частотность релизов была примерно той же, что и сейчас.
15:57 Может быть, они могли быть чуть более хаотичными.
16:01 Просто например, мы доделали какую-то фичу, протестировали и мы могли ее пульнуть на продакшн тогда, когда это было удобно, просто технически, если ничего другого не мешало.
16:11 Не было вот этого ожидания.
16:13 Ну, давайте до конца спринта подождем - потому что у нас в спринт еще включено еще что-то, обычно выкатывалось просто по готовности какая-то фича.
16:23 Еще из-за атрибутов с крама что-то было и до те же самые стендапы дейки планерки.
16:29 Какое-то время они у нас были наверно до ковида, никакого такого планирования строго на две недели четкого не было, ретроспектив как таковых не было.
16:39 Но жилось при этом нормально.
16:41 Не скажу, что я сейчас с ужасом каким-то вспоминаю то, как мы работали.
16:46 Б даыложе чуть-чуть повеселее местами, потому что можно было просто пульнуть в продакшн, то, что ты уже сделал, хоп, и сразу смотреть за реакции людей, например.
16:55 Не то чтобы как бы тяпляп, но не было никакой строгой цикличности.
17:00 А сейчас появился процесс.
17:02 Очень многие разработки родеют за процесс.
17:06 Вот он у нас таки появился.
17:09 Появилась какая-то периодичность релизов, появился порядок планирования к конкретным релизам, и в этом такая появилась упорядоченность.
17:18 Еще очень хороший атрибут скрама - это ретроспективы.
17:22 Раньше можно было тоже внести свои пожелания тем лиду директору кому угодно по поводу чего-то.
17:29 Но теперь есть время и место, где это можно сделать и нужно сделать.
17:34 У тебя есть мандат на то, чтобы сказать все, что ты думаешь, обо всем: и о процессах, и о работе непосредственно, и о взаимоотношениях - вообще и о чем угодно.
17:46 У нас ребята не стесняются, говорить то, что они думают.
17:51 И это тоже хорошо, потому что можно ретроспективы превратить в некий формализм, где люди собрались.
17:58 Ну что у нас все окей, все окей, ну все, пошли дальше работать.
18:01 У нас все-таки проблема озвучивается, и это мне очень нравится.
18:05 Прям одна из ключевых вещей - полезных для команды больше.
18:08 Это прям вообще мст хев, что называется.
18:11 Вот когда было 7 человек, это прям со скрамом заметь не лучше, чем без него, но как.
18:16 когда нас было три человека, скажем, в команде до скрама, тоже было неплохо.
18:21 Мы работали как привыкли.
18:23 То есть процесс он тоже какой-то был на самом деле.
18:26 Наверное, не бывает или почти не бывает, чтобы прям не было вообще никакого процесса.
18:31 Он есть в любом случае.
18:32 Тут он просто оформлен, публично оговорен, и все знают, че от них ждут и чего ожидать вообще в целом по принципам работы.
18:41 Да, действительно, скран дает предсказуемость, и вот по своим ощущениям хочу тебя дополнить, что вот эти ритуалы скрама они невероятно стабилизируют.
18:51 В каком бы ты состоянии ни был, с какой бы ты ноги ни встал, ты попадаешь в этот рабочий процесс - вот как автомобиль в потоке машин.
18:59 Он движется со скоростью потока, ты ловишь этот рабочий ритм, и это психологически очень здорово настраивает на рабочий лад.
19:08 И еще хочу с тобой вспомнить, что у нас все-таки немножко было сопротивление искраму, и даже звучало такое, что не стоит уподобляться этим глупым америкашкам.
19:18 По-моему, такое что-то звучало.
19:20 И еще были сопротивления по поводу того: а почему так долго, почему так долго ретро, почему так долго рефаймент?
19:27 Но сейчас все зашло за милую душу, и скорее всего, ни у кого из команды нет желания все это откатить назад, давай с тобой немножко еще поговорим об оценке задач.
19:38 В скраме мы оцениваем задачи в сторипоинтах - ну, это такая относительная оценка, скажи: насколько критично ты считаешь, то, чтобы результат спринта совпадал с планированием по закрытым сторипоинтам.
19:52 Да, мы спринт планируем, и при планировании у нас есть некий расчет по количеству сторипоинтов, которые мы должны покрыть в том или ином спринте.
20:04 А по его результатам, ты прав, смотрим, сколько получилось по факту, и сравниваем с тем, сколько же было заявлено при планировании?
20:14 У нас эти цифры, в общем-то, бьются.
20:17 Мы не доходим до абсолютного формализма, когда, например, спланировали 50, а получилось 49, ой, как же так?
20:26 В тревогу не бьем, потому что тут все очень зависит от того, сколько задач, скажем, почти готовых, попало в текущий спринт из предыдущего.
20:38 Это зависит от того, как мы оценили те или иные задачи.
20:42 Да, мы их оцениваем уже примерно все одинаково, но все равно есть некоторый люфт.
20:49 Основное, зачем мне интересно следить, это чтобы количество сторипоинтов от спринта к спринту на человека в день не падало.
20:59 От спринта к спринту.
21:00 И оно у нас не падает.
21:02 Вот за этим, да, за этим интересно и важно следить, потому что если вдруг в какой-то момент окажется, что случился какой-то провал, то на это обязательно должна найти причина, потому что что-то случилось.
21:15 А по поводу того, чтобы сравнивать то, что мы спланировали, и то, что получалось по факту, получается так, что примерно оно совпадает.
21:25 Это говорит о том, что мы и спланировали довольно качественно.
21:29 Планируем мы все-таки задачи, так чтобы работа была на каждый день, так сказать, планируем плотненько и закрывать получается.
21:39 Ты хорошо упомянул то, что есть задачи, которые почти готовы?
21:43 Да, то есть, если задача у нас находится на стадии код-ревью или тестировании, под конец принта, это значит, что в следующем спринте мы эту ценность пользователю в любом случае дадим.
21:54 Лучше хорошенько проверить, все протестировать, чем выкатывать что-то сырое.
21:59 И еще я хочу знать, что у тебя спросить: можешь поделиться тем, как команда разработки принимает решение о дне недели и времени выкатки релиза, да, тут самое главное правило, которого придерживаются все или почти все, это не выпускать релиз в пятницу.
22:17 Потому что пятницу вечером релиз выпускаешь, а в нем в него закрадывается какой-то неочевидный баг, а в выходные никто его не чинит.
22:28 То есть мы действительно не релизим в пятницу.
22:31 Ну, просто потому что действительно, бывают какие-то ошибки, которые может быть сходу не видны пользователям.
22:37 То есть нет такого, что люди заходят на сайт, а там вообще ничего не работает.
22:42 Скорее всего, такого не произойдет, потому что тестирование перед релизом оно так или иначе осуществляется.
22:48 Но бывают все равно какие-то внутренние ошибки, серьезные, которые, может быть, даже пользователь не увидел, а увидели мы.
22:55 И это надо исправлять очень оперативно.
22:57 Ближайшие часы или даже минуты после релиза, поэтому да, основное, чего мы придерживаемся всю жизнь - то до скрама, что после, что во время него теперь да это не релизить в пятницу.
23:12 Понятное дело, что если не релизить пятницу, значит релизить в воскресенье, если к концу недели что-то готово.
23:17 В воскресенье, ночью, да, в понедельник все пришли на работу и начали исправлять, если что-то произошло.
23:23 Но у нас еще есть такой любимый день четверг, так уж случилось, что не то чтобы это специально, мы разложили там карты, погадали на кофейной гуще и решили, что это будет четверг.
23:35 Но так получается, что к концу недели ты завершаешь какую-то работу и бывает да что вот в четверг вечером например мы все заготовили чтобы релиз выпустить и мы можем его выпустить в четверг потому что пятницу все еще работают и как правило вот одного рабочего дня хватает, чтобы закрыть какие-то критичные ошибки, если они случаются.
23:56 Но это, конечно, не для всех правило, потому что в больших компаниях корпорациях релизы могут происходить по несколько десятков раз в день.
24:08 В системах выпуск релизов он автоматизирован не так, как у нас руками системный администратор выпускает.
24:14 Понятное дело, что там не все релизится вот так вот на лету, но какие-то некритичные вещи так выпускаются по сути в автоматическом режиме.
24:25 Поэтому этот совет про пятиница не для всех, плюс есть в некоторых крупных проектах, даже если релиз не выпускается, просто кто-то дежурит там какой-нибудь системный администратор или Девоп-специалист сидит дежурит по выходным.
24:40 В случае чего, если что-то ломается, он это оперативно чинит.
24:44 А у нас так: в конце недели, но не в пятницу.
24:49 Ну, то есть, наша концепция такова, что мы не хотим нарваться на негатив пользователей.
24:54 Если после релиза будет очень много багов, пользователи будут никотивить, и это нужно будет срочно исправлять.
24:59 И здесь я бы хотел с тобой переключиться к такой теме, как пользовательский опыт.
25:04 Ты его в самом начале подкаста уже упоминал.
25:07 Я знаю, что для тебя эта штука не нова, и ты на это смотришь всегда.
25:13 Мне вот интересно: в целом, вот ты вращаешься среди разработчиков, не так давно ты ездил в Питер на конференцию и скажи: среди основных обсуждаемых тем, как-то затрагивается пользовательский опыт, или фокус все-таки на коде, архитектуре, технических деталях?
25:30 Да, ну насчет конференции был я на конференции для тимлидов, Тимлид.конф СПБ - конференция, которая заточена именно под руководителей.
25:40 Поэтому там сама по себе разработка обсуждалась очень по касательной и косвенно.
25:46 Понятное дело, что ее совсем не обсуждать было нельзя, потому что, хоть и было заявлено, что могут люди участвовать не только из айти, но так сложилось исторически, что это конференция для айти-руководителей.
25:59 Поэтому да, вопросы разработки было не миновать, но не в этом была главная соль.
26:05 А у нас пользовательский опыт, ребята про него думают, но может быть не так много, как хотелось бы иногда, с одной стороны, понятно, что разработчик должен уметь написать программу хорошо, если он при этом думает, а как этим пользуется какой-то конкретный клиент, какой сценарий использования той или иной фичи?
26:30 Это только плюс к такому разработчику, как в целом, к специалисту.
26:34 Но иногда бывает, что в процессе решения какой-то задачи - ты очень сильно зарываешься в технические детали, и бывает, да, взгляд замыливается, и не остается уже просто времени и сил думать про то, как там, что будет использовать.
26:49 Но по крайней мере, когда ребята что-то начинают делать,
26:57 сценарий пользователя они прокручивают, и ценность в том, что они делают для пользователя, тоже в целом понимают.
27:04 Не могу сказать, что это не обязательно, это очень желательно и хотелось бы.
27:09 Но не всегда получается от всех это требовать, какого-то четкого понимания, осознания.
27:16 Ну вот сейчас у нас скрам появился, и поэтому все ребята, разработчики в большом контексте, находятся относительно друг друга.
27:25 Это кстати - было одной из целей - вообще - внедрение Скрама, чтобы повысить контекст.
27:32 Но если скажем, скрама нет, или просто люди не в контексте друг друга, то тогда можно дать какую-то техническую подзадачу, так что разработчик в целом, даже не будет понимать, например, зачем ты его что-то просишь сделать, например, я что-то делаю, я понимаю, что мне нужна помощь, кого-то прошу, сделать часть какой-то задачи и в общем-то могу не озвучивать даже для чего это надо, но если при этом тот, кто будет делать эту подзадачу, поинтересуется, а что вообще я сейчас буду делать?
28:02 Зачем это никому надо, вот это хороший сигнал.
28:05 Ты хорошо упомянул тот момент времени, когда мы начинаем что-то делать, да, то есть у нас есть идеи, это говорит о том, что разработчик, как роль, он в принципе участвует в полном цикле создания продукта от идеи до реализации и последующих улучшений.
28:22 И особенно важно, на мой взгляд, как дизайнер, участие разработчика в дизайн ревью, потому что здесь разработчик может дать классную обратную связь с технической точки зрения реализации того или иного дизайна решения, чтобы мы не начали фантазировать какую-то нарнию у себя в продукте, и чтобы мы знали, насколько это технически мы можем осиять и с какими ресурсами мы можем увидеть какие-то проблемы заранее.
28:50 Мы можем предположить заранее, насколько дорогой будет в разработке фича.
28:54 И еще хочу отметить один классный момент: здорово, когда в команде есть разработчик, который иногда смотрит на конкурентов, вот как у нас Иван.
29:04 Взгляд разработчика на продукты конкурентов может довольно сильно отличаться от взгляда дизайнера, потому что разработчик увидит те вещи, на которые дизайнер не обратит внимания в силу специализации.
29:16 И вот эти технические вещи - то, что видит разработчик, и уикс решения, те, что видит дизайнер, они здорово могут дополнять друг друга и давать более объективную картину того, как эти решения работают у конкурентов.
29:30 А с тобой, Иван, я хочу сейчас переключиться на такую тему: как ты считаешь, отличается ли работа разработчика в малом бизнесе и в корпорациях?
29:42 Да, конечно, отличается.
29:43 И малые бизнесы друг от друга могут сильно отличаться, потому что есть, ну, скажем, продуктовая разработка, как у нас, когда команда ведет?
29:52 Пусть это будет один, два, или даже несколько продуктов, которые компания развивает как САС, например.
30:00 Да, а есть заказная разработка, когда компанию кто-то приходит, например, просит сайт, сайт производится, потом отдается заказчику, и или сопровождается, или даже не сопровождается, например, никак.
30:15 Поэтому, наверное, большая разница в работе кроется в этом: то, какая это компания, занимающаяся заказной разработкой или продуктовая.
30:24 Ну а еще аспект различия, теперь уже, если посмотреть на большие корпорации маленькие компании - это то, что наверное вот есть такой пример - абсолютизированный разработчиков корпорации - да, разработчик одной кнопки - иногда так говорят, например.
30:43 То есть, вот у тебя есть какая-то условно говоря, кнопка за которой ты следишь, и больше ты ничего не делаешь.
30:49 Не всегда имеется в виду буквально одна кнопка, но доля, правда, в этом есть.
30:54 То есть, вот есть какая-то зона ответственности, у человека, вот он ей только занимается.
30:58 В маленьких компаниях такого не бывает.
30:59 В маленьких компаниях обычно люди делают все и сразу.
31:02 Поэтому вот отличие может быть в том, что кто-то делает что-то очень узкое, и только это в больших компаниях.
31:09 И еще на уме крутится такая вещь, как ощущение в участии развития продукта.
31:17 Когда люди в маленькой компании работают, они чувствуют свой вклад непосредственно.
31:23 Вот я сделал эту штуку, вот она через 2 дня оказалась на продакшене, вот люди ей пользуются.
31:29 Я вижу, как это происходит.
31:32 Я понимаю, что я это сделал.
31:33 Если там пользуются десятки сотни людей, прям приятно.
31:37 Конечно, в крупных проектах твоей фичи могут пользоваться тысячи и миллионы людей даже, но не всегда может быть такое яркое ощущение влияния на развитие продукта.
31:49 То есть, ты можешь что-то делать, такой пример крайний.
31:53 Когда что-то делают в стол, то есть, есть у большой корпорации какой-то проект, который, ну, может быть, делается не для того, чтобы сейчас начать продаваться, а вот на какую-то перспективу разработчики его пилит-пилит, и понимают, что в продакшене этого нет.
32:09 Что это там какой-то ресерч, например, какое-то исследование для будущих поколений, он там что-то делает.
32:15 Ну, то есть, вот в таких вот вещах очень разница.
32:18 Разработка в больших компаний и малых, но надо тут оговорку сделать, что в крупных корпорациях я не работал, все эти измышления они такие известны и понятны всем в разработке.
32:29 Но это не всегда так.
32:30 То есть не всегда человек, работающий в крупном проекте, не чувствует своего вклада.
32:35 Ну, наверное, есть люди, которые хорошо это чувствуют, особенно если это какие-то очень квалифицированные специалисты, например.
32:42 Ну, и там уже если касаться просто условий труда, они тоже конечно разные.
32:47 Обычно, и как правило, компания поменьше не может предложить таких заманчивых условий, и по зарплате, и вообще по всему остальному, что может предложить большая.
32:57 Но плюсы работы маленьких проектах тоже есть.
33:00 Для кого-то это важно.
33:01 Спасибо, да, ты хорошо сказал про влияние разработчика на продукт ты чувствуешь процесс более живым, потому что продукт небольшой, возникает эмпатия к пользователю.
33:14 После релиза ты можешь задумываться о том, как человеку будет.
33:19 У нас даже основатель поддерживает то, что разработчики могут делиться мнением своим и предложениями по тем или иным улучшениям интерфейса.
33:30 Это все приветствуется.
33:31 А еще ты сказал про разделение заказной разработки и продуктовой.
33:36 Да, это важный момент.
33:38 При заказной разработке тебе важно выдать качественный код по техническому заданию, а при разработке в продукте при взаимодействии с разными ролями, ты чувствуешь лучший вообще весь этот процесс, и лучше чувствуешь пользователя бизнес, я думаю.
33:58 Плюс небольшая компания - это еще и разнообразие задач, это к вопросу о разработчике одной кнопки.
34:07 Иван, я хочу с тобой сейчас поговорить о насущной теме об ИИ инструментах.
34:14 Создается впечатление, что они позволяют экспериментировать сразу в коде, минуя стадию дизайна.
34:21 И у нас такой пример был, когда несколько небольших фич были реализованы основателем при помощи АИ, минуя все этапы скрана и дизайн процесса.
34:33 Как ты к этому относишься?
34:36 Ну да, это и разработка от основателя продукта.
34:42 Надеюсь, что это у нас был такой эксперимент.
34:45 Пожалуй, больше, чем правило.
34:51 помощников никуда не деться, ими нужно учиться пользоваться.
34:55 Я ими пользуюсь, может быть, чуть меньше, чем надо бы и хотелось бы, много очень ажиотажа вокруг этих инструментов.
35:03 Хочется, чтобы этот ажиотаж начал спадать и превратился в какой-то продукт, который все знают, как использовать, сейчас бывают перегибы в этом разработке, когда люди не могут что-то написать сами, просят об этом ИИ, например, и потом не до конца понимают предложенного решения.
35:29 Я сейчас не говорю о нашей команде, я говорю в целом, читая тоже разные блоги по этому поводу.
35:36 Главное, разработчику не переставать понимать код самостоятельно, использовать вот эти и помощники - действительно как помощники, а не как что-то, что делает всю работу за тебя, а ты потом не понимаешь, что же там произошло.
35:52 Если ИИ научится делать все хорошо и без багов, может быть, и действительно скажут: ну все, товарищи разработчики, вы больше не нужны.
36:00 Вот у нас и есть ИИ, которая нам все сделает.
36:02 Сложно тут гадать, и действительно развивается быстро.
36:05 Каждый квартал там появляются какие-то новые модели, которые кого-то чем-то удивляют.
36:10 Но пока разработка командная производится людьми и для людей - код люди в команде пишут таким образом, чтобы другой член команды, который доступ к этому коду имеет, мог понять все, что там написано.
36:26 Поэтому нужно его писать и понятно, и достаточно неизбыточно и иногда грешит тем, что занимается, ну, так сказать, овер-инжинирингом-то слишком сложно что-то реализует, когда можно сделать это чуть попроще, например, или когда он справляет какой-то баг и рождает новый, может быть, даже не всегда очевидный, особенно если тот, кто использует и не очень понимает, что он там ему выдал.
36:55 То есть, проконтролировать то, что там какой-то бак появился, это тоже бывает сложно.
37:00 Поэтому нужно этим пользоваться грамотно, как еще одним инструментом, помогающим в разработке.
37:08 Да, вот этот ажиотаж, о котором ты говорил, я думаю, вызван в том числе тем, что появляются специалисты, которые пишут код, но не умеют его читать.
37:19 Эта история может развиваться и в обратном направлении, когда разработчик начинает проектировать интерфейс сразу в коде без дизайна макетов, как ты считаешь, возможно ли в будущем размытие границ между ролями дизайнера и разработчика.
37:36 Гадать, прям сложно, конечно, точно.
37:38 Неблагодарный занятия, но все-таки, мне кажется, разделение труда, так сказать, дошло до того, что вот у нас есть разработчик и дизайнер - это очень разные вещи.
37:47 Разработчик решает за то, как что-то будет реализовано, каким образом, а дизайнер решает вопросы удобства пользователей и того, чтобы это было понятно пользователю.
38:01 Может быть, конечно, если кто-то обучит когда-нибудь искусственный интеллект правилам дизайна, подаст ему на вход какое-то там техническое задание и скажет: вот у нас есть сервис, который должен делать то-то и то-то, сделай так, чтобы это было удобно людям.
38:16 Тогда, может быть, разработчик будет что-то делать, а ИИ, скажем, будет как-то автоматически это дизайнить уже правильным образом.
38:24 Но я думаю, что такого не произойдет, все же, потому что ИИ не схватывает очень многих вещей, которые люди схватывают при общении друг с другом.
38:36 Например, мимик, какие-то шутки, какие-то образы, не проговоренные, так сказать, в тексте или в каких-то инструкциях, или еще в чем-то, и же учатся на каком-то массиве данных, которые уже мы ему можем подать, там которые уже как-то
38:54 оцифрован, где-то хранится, каким-то образом сагрегирован, проклассифицирован, а насмотренности у людей все-таки больше.
39:04 Насмотренности реального мира, я имею в виду, то есть, поехал дизайнер в какую-нибудь страну для него новую, что-нибудь увидел там на улице просто какой-нибудь, не знаю, дорожный знак, скамеечку красивую, или еще что-то.
39:17 Ему что-то в голову пришло, какие-то образы, и пока так не умеет.
39:22 С другой стороны, можно сказать, что ну вот есть все в мире фотографии, хранящиеся в интернете, мы же можем сказать, и вот, посмотри, пожалуйста.
39:30 Но тогда надо будет его научить и сказать ему, что есть там хороший вкус или еще что-то.
39:37 Ну, в общем, все, что касается такой какой-то художественной составляющей, мне кажется, этому сложно.
39:42 Обучать компьютер, возвращаясь к вопросу, что дизайнер с разработчиком вряд ли сольются во что-то одно, наверное, нет.
39:50 Но то, что у дизайнера появится, в том числе, как и у разработчиков, какие-то более эффективные инструменты для того, чтобы какие-то дизайны, прототипы делать быстрее.
40:02 Это я надеюсь, что так и будет.
40:04 Да, спасибо за ответ.
40:05 Мне очень понравилось, как ты сказал, про коммуникацию и про фоновую подпитку, про какую-то подсознательную работу человека, когда он воспринимает вообще весь мир и он фоном подпитывается этим, и это может сказываться дальше на его решениях, и приносить пользу его работе.
40:27 Иван, наш подкаст близится к завершению, и по традиции я хочу тебя попросить дать несколько советов начинающим разработчикам.
40:36 Чему стоит учиться, на что обратить внимание, чтобы быть востребованным сейчас и в ближайшем обозримом будущем.
40:43 Да, может быть, немножко каким-то будут, грубо говоря, старперскимими каки-то моими советами, но хочется пожелать сначала обратить внимание на базу какую-то свою подготовку.
40:55 Поначалу не гнаться за какими-то конкретными технологиями, какими-то конкретными фреймворками, языками программирования и так далее.
41:05 Хочется, чтобы те, кто входит в профессию, для начала понимали, что такое программирование вообще, что такое алгоритм, из чем его едят, какие бывают структуры данных, например, как они хранятся в памяти компьютера.
41:20 В общем, вот такие базовые вещи,
41:24 молодежь их называют базой.
41:29 Вот это самое важное, потому что пока люди все-таки программу пишут, и нас всех не заменил, и нужно понимать целом суть работы, как делать хорошо, как делать не очень хорошо.
41:40 Вот это все базовая подготовка.
41:42 Про в целом, программирование, про в целом алгоритмизацию.
41:46 Важно с этого начать и это не упустить, потому что это просто я говорю по типичным ошибкам начинающих, которые я вижу сам: что люди хватаются за какую-то модную технологию, которая модно сегодня, например, но не обязательно, что будет модно и завтра и востребованный, и не всегда уделяет достаточное время для какой-то подготовки по базовым вопросам.
42:10 Если это кто-то веб-программист, то это будет работа с сетью, например, в том числе.
42:16 Надо понимать, как она работает, какие бывают протоколы.
42:19 Не говорю, что нужно быть ходячей энциклопедией и знать все про все, про все там условно говоря, коды ошибок, сервера, какие они бывают, все стандарты, которые описаны в интернете, на зубок знать.
42:31 Этого не требуется, но какие-то базовые вещи знать требуются, и нужно понимать, где искать ту или иную информацию.
42:40 Когда сталкиваешься с какой-то проблемой, понимать, какого рода это проблема, где я должен найти на нее ответ, как-то так.
42:46 Иван, спасибо тебе огромное за классный подкаст.
42:49 Я считаю, мы с тобой здорово поговорили и о взаимодействии разработчиков с разными ролями, о процессах, о скраме, затронули тему ИИ.
42:59 Отдельное спасибо за мудрые советы начинающим разработчикам.
43:03 Я рад, что ты пришел и поучаствовал в подкасте.
43:07 Увидимся с тобой в понедельник на Дэри стендапе.
43:10 Спасибо слушателям, что были с нами.
43:16 Это был подкаст Дизайн Практика.
43:18 Если материал оказался полезным, расскажите о нем коллегам.
Комментарии
Войдите, чтобы оставить комментарий.