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

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

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

Работа над собой, собственное развитие

Защита докторской

Игорь Цупко

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

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

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

Why we should care about diversity and inclusion in tech?

Yuliya Kurapatsenkava

I would like to cover examples of how diversity changed the way Spotify is driving its product. I will show how by changing the approach to diversity and inclusion teams can change the way they work. I will cover some practical steps of what has been done in Spotify to address diversity and inclusion issues and what benefits it gave the company, local committees and countries where the company is represented.

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

Как мы нанимаем людей и помогаем им адаптироваться

Игорь Цупко

На то, чтобы ввести нового сотрудника в курс происходящего может уходить несколько месяцев, а поиск новых кадров - это отдельная боль всего IT.
Я расскажу о том, как устроено трудоустройство и дальнейшая адаптация сотрудников во Флант, и, самое главное - почему именно так. Как мы тестируем и каким составом собеседуем инженеров, как помогаем новичку “догнать” постоянно рвущиеся вперёд разработки и довести его до состояния полноценной боевой единицы.

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

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

Теперь я - тимлид, но почему мне так плохо? Практические советы экзистенциального толка

Евгений Кот

Для экзистенциалиста человек потому не поддается определению, что первоначально ничего собой не представляет. Человеком он становится лишь впоследствии, причем таким человеком, каким он сделает себя сам.
(с) Жан-Поль Сартр. Экзистенциализм - это гуманизм

Умная цитата тут конечно вставлена только для того, чтобы пустить пыль в глаза, а сам доклад не об этом.
Вот как бывает - сидишь себе, пишешь код, растёшь, можно сказать даже эволюционируешь от знаний и опыта. И как на той картинке, где за голым мужиком идёт толпа непонятных субъектов, постепенно превращаешься из джуниора в мидла, потом в сеньора с дубиной, а потом наступает черёд становиться тимлидом и вести за собой эту толпу к неотвратимому свету прогресса.
И вроде всё хорошо, но вместе с прямохождением в голову начинает лезть всякое.
Вот была у тебя одна система ценностей: хороший код = хорошая работа. Написал сервис = пошёл домой. Сделал фичу = получил премию. А тут целый день на митингах, разговоры, разговоры, разговоры, а потом начинаешь думать: что же полезного-то я сделал. И с ужасом понимаешь, что ничего. “Тварь ли я дрожащая…”, и всякое такое. Но на самом деле…
Для кого этот доклад: для таких, каким я был (и есть) сам. Для тех, кто писал код, а потом вдруг понял, что времени на это всё меньше и меньше. Для тех, кто понял, что работать с людьми - это вообще-то не просто. Ну и для тех, кто пока ничего ещё не понял, но уже что-то такое начал подозревать. А менеджеров от природы я почти и не видел.

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

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

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

Александра Балод

1. Зачем их мотивировать, если и так работают
2. Виды кнутов и пряников
3. Не в деньгах счастье, но и без них нельзя

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

О вреде ярлыков с компетенциями

Владимир Романько

Синдром мёртвой команды, или как категоризация людей по их компетенциям и развешивание ярлыков убивает команду.
Отсутствие ярлыков с компетенциями не означает отсутствие специализации.
Как создать среду для естественной или "органической" специализации и развития команды.
Чем сильна команда с органической специализацией.

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

Брошенные на произвол судьбы

Игорь Цупко

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

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

Бизнес-процессы

Школа программистов как решение проблемы найма

Лев Екасов

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

Мы обсудим особенности набора, какие проблемы возникают, как мы их решаем, какими инструментами пользуемся

Рассмотрим, как и чему мы учим в школе, кто ведёт занятия, что вообще делают в школе и после её окончания

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

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

Как собирать метрики и стоит ли на них полагаться

Макс Богуславский

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

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

Умение давать обратную связь, как основная компетенция тим.лида.

Александра Балод

1. Что такое обратная связь и для чего она сотруднику
2. Позитивная и негативная обратная связь - особенности предоставления.
3. Получение обратной как механизм саморазвития тим.лида

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

Мотивация команды через майнинг игровой валюты

Ртищев Евгений

Друзья, привет!

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

Тимлиду бывает очень сложно – он тоже человек и не редко бывает субъективен и предвзят. Случайная ошибка (повышение не того человека, публичный эмоциональный срыв, нелогичность действий) имеет сильный и сложно обратимый эффект. Команду легко расстроить и вывести из состояния производственной эффективности.

Часто перед нами встают вопрос и проблемы:
1) Кого повышать? Заслуживает ли человек повышения?
2) Какой вклад этот человек делает в развитие продукта?
3) Каков вклад этого человека по отношению к другим членам команды?
4) Как правильно контролировать и учитывать экстренные задачи в общей эффективности?
5) Как контролировать и поддерживать своё внимание к каждому члену команды?
6) Как не забыть чьих-то заслуг или проколов?
7) Как ввести что-то новое, чтобы усилить интерес и вовлеченность коллег?
8) Как настроить команду на соревновательный дух, который идёт на благо продукта?
9) Как мотивировать команду через систему понятных наград и возможностей?

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

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

Разделение ответственности в IT-командах - практики бирюзовых организаций на каждый день

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

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

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

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

Рассказ будет о том, как это воплотить в жизнь, при этом сохранив целостность решения.

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

Карта компетенций как инструмент для тимлида

Константин Кафтан

Ключевая фраза - “для тимлида”. Это не официальный кадровый документ, написанный канцелярским языком, а рабочий инструмент, помогающий избежать ошибок при назначении задач, оценить насколько хорош каждый из коллег и помочь обозначить план обучения.
Когда у команды широкий и разношерстный спектр задач, требуется четкое понимание того, кто из коллег чем занят, на что он способен. В докладе я расскажу о том когда требуется озаботиться картой компетенций, как сделать ее простой, понятной и наглядной.
Если вбить в поиске "Карта компетенций" выдача заполнится кучей канцелярских документов, составленных "В целях повышения удоев чугуна на душу населения".
Мы же поговорим о практической пользе этого инструмента. Для нас это именно инструмент, а не отчетная бумага.

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

Модели softskill для тимлида

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

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

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

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

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

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

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

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

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

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

Тимлид в организации

Organisational Structure in Spotify

Yuliya Kurapatsenkava

In this talk, I would like to cover the organisational structure of Spotify. What is the line between giving more autonomy to the squads while expecting accountability from them? I will cover how the organisational model of Spotify transformed over time experiencing a hyper-growth phase in terms of hiring and scaling of the product and maintaining the company culture. I will describe the leadership model of teams and how we transformed from the approach of Chapter Leads to Engineering managers.

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

Орлята учатся летать

Андрей Тимонич

Воспитание джуниоров является неотъемлемой частью работы тимлида. А в условиях быстрого роста бизнеса эта задача становится одной из важнейших для тимлида и компании в целом. В докладе рассмотрены 3 фазы становления новичков: адаптация (бытовая, эмоциональная, социальная), набор уровня профессиональной компетенции и мотивация. Также станет понятно, как и почему должен измениться сам тимлид, чтобы его орлята быстро, красиво, и пышно оперились и начали летать.
В Tinkoff.ru мы умеем и любим централизованно находить молодые таланты, обучать их и брать в штат. Но задача адаптации их к реальной работе ложится на плечи непосредственных руководителей и тилидов. Доклад основан на 2-летнем опыте руководства одним из IT-отделов Tinkoff.ru, выросшим за это время в 4 раза за счет прихода молодых и талантливых, но неопытных людей.

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

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

Фабриченко Виктор

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

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

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

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

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

Как мотивировать команду работать и получать от этого удовольствие

Надежда Шевелева

Надежда Шевелева – эксперт в ИТ с опытом более 10 лет. Владелец софтверной компании Радолёт и сервиса Deploy4Me. Несколько лет вела бизнес в Австралии.

Мотивация команды – это мотивация людей. Люди разные, поэтому нужен особый подход по группам мотивации. Хорошо зарекомендовал себя подход на основе «Водопадной теории мотивации и интеллекта».

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

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

Доклад подробно останавливается на приемах системного и личностного воздействия по всем основным параметром мотивации: физический компонент, финансы и доход, общественное мнение, интерес, затраты.

Подход дает ответы на вопросы:
• как уменьшить фонд оплаты труда без потери мотивации?
• почему геймификация не у всех работает?
• почему гуманитарии быстрее растут по карьерной лестнице?
• как не допустить over-engineered решений?
• что делать с overqualified сотрудниками?
• Как заставить работников работать за копейки, за еду или за идею?

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Антикризисный менеджмент
,
Управление / другое
,
Вечеринки, развлечение
,
Деловая встреча
Программный комитет ещё не принял решения по этому докладу

Не сбавляя темпов роста. Как мы переходили от функциональных команд к продуктовым

Виталий Леонов

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

Расскажу, как мы переходили от функциональной структуры к кросс-функциональной (aka продуктовой), как повышали автономность команд, как снижали Time To Market, с какими проблемами столкнулись, и что из всего этого получилось.

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

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

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

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

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

Как мы выбираем себе команду

Александра Балод

1. Субъективные предпочтения и чем это грозит
2. Профиль должности и портрет кандидата
3. Разные роли = разные люди

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как мы внедряли систему грейдов. Или зачем нужна оценка команды.

Роман Мочалов

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

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

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

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

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

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

Иван Михеев

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

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

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

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

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

Максим Дзюба

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

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

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

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

Тимур Павлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тимур Павлов

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

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

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

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

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

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

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

Антон Бевзюк

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

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

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

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