23 и 24 сентября,
Санкт-Петербург

Заявки на доклады

Поиск по тегам:

Выстраивание технологического процесса

Как эффективно выстроить процессы разработки и перестать издеваться над командой

Артур Дементьев

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Управление / другое
Доклад принят в программу конференции

Инженерные инициативы: как организовать работу с общим техническим долгом в не самой маленькой компании. От раздачи задач “из-под полы” до системного процесса и геймификации.

Алексей Картавенко

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

Когда же у тебя двадцать продуктовых full stack команд, больше сотни одних только разработчиков, число репозиториев кода, стремительно приближающееся к трём сотням, а бизнес вынуждает тебя стремительно итерироваться в борьбе за мировое господство единственного продукта, который вы все делаете и который вас кормит (и в котором, между прочим, миллионы строк кода)… дела могут принять совсем скверный оборот…

… особенно для тебя, лида продуктовой команды и заложника, которому и сделать всё хочется получше, без скошенных углов, и легаси бы почистить, и торопливый бизнес порадовать - но при этом у PM-а не выпросишь и 10% спринта, пока всё не взорвётся, перерабатывать всё время невозможно - что делать, как не опустить руки?

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

Большие проекты/команды
,
Корпоративная культура и мотивация
Доклад принят в программу конференции

Планирование проекта от демонстраций для разворачивания партнерства с заказчиком

Максим Цепков

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Работа со внешним заказчиком/исполнителем
,
Проектирование информационных систем
,
Внедрение и поддержка
Доклад принят в программу конференции

Я стал тимлидом, и что?

Как угробить командную работу: руководство для менеджера

Александра Баптизманская

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

Самое время всё запороть!

В своем докладе я расскажу о 7 примерах дисфункций в отношениях между командой и менеджером и о том, как их не допустить или исправить.

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Про инженерный шовинизм: отвратительно быть менеджером

Евгений Кот

<blockquote>
Редко где найдется столько мрачных, резких и странных влияний на душу человека, как в Петербурге
</blockquote>


TLDR;
Поговорим о том, как жить в мире петпроджектов, звёздочек на гитхабе, и не писать код

-----------

Рано или поздно, и вовсе даже независимо от времени года и места проживания, нашему инженерному брату в голову лезут всякие мысли. От банальных: “а что сейчас надо изучать?” до “я и в сорок лет буду код писать?”. Классики называли это экзистенциализмом, а если по-простому, без зауми, то каждый рано или поздно спрашивает себя: “А что делать дальше?”. И вот тут и наступает порою самый переломный момент: как расти над собой, и при этом заниматься тем, что нравится.

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

Одна из самых распространённых ошибок: берём хорошего инженера и делаем из него плохого менеджера. И вот уже код уходит из рук, подчинённые - "бездари, сам бы всё написал, да времени нет, эх как раньше всё просто было".
Или вот положим удалось отвертеться, и стать таки "архитектором". Работа почётная, что и говорить. А что если продукт не из первой страницы гугла и про него никто не слышал? А хочется-то большего, и вот уже по ночам пилится свой "петпроджект", забирая время и нервы. В наше время, когда звёздочки на гитхабе превращаются в погоны, а фоловеры - в армии, становится не очень понятно - "тварь ли я дрожащая?". Что если ничего такого, за что можно поставить звёздочку ты не сделал, значит ли это, что ты хуже остальных? Учитывая, что написанный код устаревает раньше, чем он пойдёт в бой, останется ли после тебя в мире хоть что-то, если ты просто хорошо делаешь свою работу?
Как угнаться за трендами, хайпами, блокчейнами,нейроннымисетями биткоинкупитьбезкомиссии когда так хочется спать?
В какой-то мере отвечая Вадиму Макиашвили и его нетленке "36" попробуем ответить на классический вопрос "Что делать".

Доклад принят в программу конференции

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

Как работать с джуниорами?

Сергей Попов

* Что такое начинающий разработчик и что он скрывает?
* Какие тайны он приносит с собой после того, как заканчивает обучение?
* Что он придумывает на собеседовании и почему он так их боится?
* К чему нужно быть готовым при работе с джуниорами, какие задачи нужно ему давать и как погружать в работу?

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

Code Review
,
Большие проекты/команды
,
Поиск и развитие команды
Доклад принят в программу конференции

Собеседования как конструктор

Станислав Цыганов

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

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

Планирую рассказать и о реальных кейсах, причем не только наших, и дать некоторый фреймворк и инструкцию, как им пользоваться.

Доклад принят в программу конференции

Работа с командой: делегирование и мотивация

Вы уверены, что вы не микроменеджер?

Егор Бугаенко

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

Модели руководства
Доклад принят в программу конференции

Канбан Метод для команд

Алексей Пименов

Канбан Метод представляет собой достаточно структурированный свод знаний по управлению изменениями в компании (а не про доски и стикеры, как многие привыкли думать). В данном докладе я хотел бы раскрыть определенные механики и паттерны из Канбан Метода, которые можно использовать на командном уровне, разобрать так-называемые Прото-Канбан Системы, которые позволяют получать профит от их применения не проводя разрушительных изменений в команде (т.е. изменений, которые могут вызывать сопротивление). Поделюсь своим опытом и примерами из реального бизнеса

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Модели руководства
,
Корпоративная культура и мотивация
,
Антикризисный менеджмент
,
Управление / другое
Доклад принят в программу конференции

Планирование и оценка задач, ретроспектива

Сказка про репку, или Как рождаются правильные задачи

Антон Костерин

• Как должны появляться задачи, отвечающие интересам заказчика - цепочка от глобальной цели компании до постановки задачи с разбиением на слои. Зоны ответственности и выделение порождаемых артефактов.
• Проблемы и боли teamlead'а и команды разработки в целом при плохой/ не правильной/ не полной постановке задач.
• Критерии корректно поставленной задачи, состав минимально необходимой постановки для достижения успешного результата.
• Инструментарий по работе с задачами:
- валидация;
- техническая декомпозиция;
- линковка задач;
- оценка трудозатрат / технических рисков;
- приоритизация.

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
,
Управление / другое
,
Управление изменениями, управление требованиями
,
Общение с заказчиком, извлечение требований
Доклад принят в программу конференции

Развитие осознанности

Борьба с перегрузками

Александр Бикманов

Большинство из тех, кто недавно стал teamlead'ом, обычно страдают от перегрузок: сложно справляться одновременно с несколькими потоками задач. Технические задачи, работа с командой, общение с другими руководителями и т.д. Всё кажется важным, а времени на качественное выполнение задач не хватает. Ты начинаешь задерживаться по вечерам, работать больше, но всё равно постоянно что-то упускаешь.

В своем докладе хочу рассмотреть данную проблему c разных точек зрения:
- работа с потоком задач (как уменьшить поток/улучшить качество задач, как делать задачи быстрее, можно ли их совсем не делать);
- отношение к задачам (как повысить психологическую устойчивость, как перестать переживать о невыполненных задачах и не загубить дело);
- управление своей энергией (как не выдыхаться к вечеру);
- управление своим временем (только основные моменты);
- можно ли ничего не делать;
- что совсем не работает.

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

Цель доклада не открыть что-то новое, а, скорее, систематизировать имеющиеся решения/практики. Наиболее полезным доклад будет для начинающих teamlead'ов, поскольку они в состоянии перегрузки находятся относительно недавно и еще, быть может, не успели выработать свой подход к решению этой проблемы.

Управление / другое
Доклад принят в программу конференции

Две крайности руководителя

Александр Орлов

По многолетнему опыту обучения и личной работы с руководителями первого уровня (тимлидами, менеджерами команд и проектов) становится заметно, что их можно поделить на две большие группы (исключения бывают, но редко и точечно):

1. Технические профессионалы — самый сильный программист в проекте становится его тимлидом.

2. Коммуникативные профессионалы — те, кто хорошо умеют находить общий язык со всеми членами команды, «неадекватным» заказчиком, «странным» руководством и т.д.

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

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

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

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

Доклад принят в программу конференции

Трансформационные изменения в людях и командах

Level up для тимлида, или Что делать, когда, казалось бы, уже все процессы настроены?

Стас Щетинников

Ты - тимлид. Ты уже настроил процессы разработки и тестирования: помог команде с автотестами, внедрил CI/CD и гитфлоу, все сервисы мониторятся и алертинги алертят. Ты участвуешь в найме, решаешь конфликты, адаптируешь новых сотрудников. Ты раздаешь и декомпозируешь задачи, помогаешь с оценкой и планированием. И что делать, когда кажется, что все процессы настроены? Куда и как развиваться? Какие еще возможности для увеличения эффективности и продуктивности команды и собственного роста?

Доклад принят в программу конференции

Это выгодно: почему нам нужно больше женщин-программисток?

Андрей Бреслав

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

Рынок IT-специалистов постоянно растет, и всем постоянно не хватает людей. За сильного специалиста обычно борется сразу несколько компаний, растут зарплаты и другие виды компенсации. Вывод: все IT-бизнесы заинтересованы в том, чтобы на рынке стало больше специалистов. Привлекая на этот рынок женщин, можно увеличить его на 10, 20, 30% или даже больше. Это значит, что если вы сейчас не вкладываетесь в привлечение женщин в IT, это делает кто-то другой.

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

Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Доклад принят в программу конференции

Инструментарий тимлида

Знания и компетенции в команде: найти, увидеть, прокачать

Алексей Трошин

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Поиск и развитие команды
Доклад принят в программу конференции

Рецепты классного тимлида: инструменты, подходы, практики

Дмитрий Ли

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

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

Нужна конкретика! В своем докладе я поделюсь детальными, применимыми советами по нескольким аспектам управления: ЧТО и КАК делать тимлиду. Я собрал практики, полученные опытным путем, в единый рецепт, который поможет вам взглянуть на свои привычные процессы и подходы со стороны.

Мы поговорим о:

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

Доклад призван предотвратить неочевидные, но распространенные ошибки тимлидов.
Киллер фича — множество примеров и инструментов, которые можно внедрять сразу после конференции.

Инструментальная поддержка, декомпозиция задач
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Выстраивание стратегии развития

DevRel для тимлида

Алексей Долгушев

С чем у вас ассоциируется DevRel?

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

Своё профессиональное развитие, развитие команды, мотивация, коммуникации. Задачи, где пригодится DevRel — их много и они разные.

В докладе поделюсь наблюдениями, какие способы применения DevRel оказываются самыми полезными для тимлидов.

Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции