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

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

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

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

Это страшное слово Deadline

Василика Климова

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

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

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

Совместная работа дизайнеров и верстальщиков
,
Фронтенд / другое
,
Code Review
,
Совместная работа, система контроля версий, организация веток
,
Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Антикризисный менеджмент
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

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

Техническая ипотека: что и кому должен тимлид

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

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

Программный комитет ещё не принял решения по этому докладу

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

Олег Плотников

Прошлой весной мы запустили проект по обновлению интерфейса с примерно такой постановкой задачи:
- запустить маркетплейс с плагинами;
- обновить и систематизировать UI продукта;
- прокачать текущую функциональность.

Легко было растянуть проект на годы, залочить другие команды, в конце зарелизить продукт низкого качества и после осознать, что сделали совсем не то, что нужно пользователям. Вместо этого мы справились командой из пяти человек (дизайнер, фронтендер, бэкендер, тестировщик, продакт) за полгода, и нам нравится результат. 

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

Single page application, толстый клиент
,
Фронтенд / другое
,
Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу

Круглый стол: Как измерить программиста?

Георгий Могелашвили

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

Программный комитет ещё не принял решения по этому докладу

Как создать эффективную команду проектных менеджеров

Константин Шубин

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

2. Проведение встреч 1:1 с подчиненными.
Найти нужного человека - только полдела. Далее, самое важное - суметь раскрыть его потенциал в работе.
- Расскажу о построении доверительных отношений с подчиненным и его мотивацию через встречи один на один.

3. Фидбэк подчиненным каждый день!
Встречи 1:1 дали крепкий фундамент для улучшений, пора давать регулярную обратную связь.
- Покажу на примерах, как давать фидбэк, в каких случаях и как часто (спойлер: подход "раз в полгода" не работает).
- Отмечу, что любой фидбэк (положительный или запрос на изменения) направлен на позитивные изменения в будущем.
- Расскажу, что делать, если фидбэк не работает и изменений нет.

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

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

Модели руководства
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

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

Сложные интеграционные проекты. Главные составляющие успеха

Иван Михеев

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

В докладе осветим:

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

Программный комитет ещё не принял решения по этому докладу

Планирование и организация исправления продакшен багов вместе с разработкой нового функционала

Тимур Павлов

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

Мы проанализировали проблемы которые возникают при работе с продашен багами. Учитывая эти проблемы стали планировать и управлять трудозатратами на исправление дефектов. Изменили workflow работы и ввели новые роли в командах. В результате создали систему, которая навела порядок в работе с багами. Теперь, если мы срываем релизы, то баги продакшна тут не причем :)

В своем докладе я расскажу:
- что представляет собой разработанная система работы с релизными багами и как она помогает в планировании;
- какие правила мы ввели для работы с багами;
- как внедряли и с какими сложностями столкнулись.

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу

Как вырастить фичакоманду за 3 месяца

Антон Бевзюк

3 месяца назад моя команда CodeMonkeys работала только над одним компонентом DodoIS - кассой ресторана, в основном на C#.

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

Какие преимущества дает фичакоманда по сравнению с компонентной командой, и какие практики eXP помогают её вырастить - вот про это и поговорим.

Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу

Переписываем 8-летний проект или рефакторинг в условиях работающего бизнеса

Максим Дзюба

Рефакторинг для бизнеса - это решение проблемы, на которую никогда нет времени.

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

Миграции данных
,
API
,
PHP
,
Рефакторинг
Программный комитет ещё не принял решения по этому докладу

Понимание системы разделения труда как ключ к успеху внутреннего предпринимательства

Александр Павлють

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

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

Надеюсь что прочитав (чтения на 5 минут) вы меня направите с точки зрения конференции с какой лучше позиции будет лучше раскрыть и какую именно, между строк там речь идет про мой продукт, он не публичный, и это не реклама его и не планируется. Отсылаться к нему я могу лишь в доказательной форме если потребуется что все что я излагаю "измерено рублем из кармана" и прошло проф пригодность. Это все большой набор кейсов.

Спасибо за внимание, надеюсь на участие в конференции.

http://telegra.ph/Ne-abassador-no-evangelist-10-25

UPD: Основная мысль которую хотелось довести - "Тим лид должен быть в первую очередь предпринимателем внутри любой структуры, при любых обстоятельствах". Где-то есть термин для компаний с большими структурами "Внутреннее предпринимательство".

Программный комитет ещё не принял решения по этому докладу

Использование багов для совершенствования процессов разработки и тестирования

Тимур Павлов

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

Мы изменили процесс работы с дефектами в нашем продукте. И это стало основой системы самосовершенствования процесса разработки и тестирования.

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

Сейчас наш продукт успешно продается и конкурирует с зарубежными аналогами. Проблемы с падающими серверами отошли в прошлое.

В своем докладе я расскажу:
- Как мы работаем с багами.
- Какие индикаторы мы используем.
- Как баги помогают нам совершенствовать процессы разработки.

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу