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

Поиск по тегам:
Показать только принятые доклады

Работа с командой

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

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

Ценный сотрудник покинул вашу команду — и увёл за собой ещё пару человек?
Я же открыт для диалога — почему он не подошёл ко мне раньше?
Почему отправил counter-offer в корзину даже не прочитав?
Знакомая ситуация, правда?

Я расскажу о двух мощных инструмента удержания — культуре доверия и one-to-one встречах.
Рассмотрю 10 вопросов — они помогут вам оценить состояние команды и ее участников.

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

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

Карьера, рост и развитие

Я расскажу, как мы собрали команду в ~200 разработчиков за 2 с небольшим года, как мы помогли HR выстроить процесс найма, с какими проблемами столкнулись из-за безумно интенсивного найма, и как мы с этим справились.

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

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

Коммуникация

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

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

Ключевые вопросы:
* Как руководителю адаптироваться к управлению командой в 5 человек, 15 и 40.
* Почему власть не дают, а берут. Как люди повышают сами себя.
* Зачем нужна стратегия подразделения, как она помогает принимать решения.
* Как перерабатывать протухший беклог. Как быть, когда задач прибывает больше, чем закрывается.
* Почему общение с заказчиками очень важно. Как выстраивается репутация команды.
* Чем опасен роста команды на 5 человек в месяц. Как в таких условиях удержать культуру разработки.
* Что такое когнитивная перегрузка, и как руководителю с ней справиться.

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

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

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

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

Меня зовут Александр, я руководитель одного из направлений разработки в Lamoda, и четыре года я работал над большим старым монолитом и его последствиями. Название доклада связано именно с возрастом проекта и архаичностью лежащих в его основе технологий, и тем фактом, что мы не бросаем его в таком состоянии, продолжая привносить в него всё новое, в чём ощущаем потребность: docker, k8s, kafka etc.

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


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

У нас 8 платформенных и 3 продуктовых команды разработки, это 60+ человек и 30+ digital продуктов. Летом 2020 года мы решили перейти на гибкие методологии разработки, сохранив нашу "неклассическую" структуру с существенной взаимосвязанностью команд. Это позволило нам не расширять штат разработки и получить "плюшки" Agile в виде улучшения T2M и быстрого развития всех наших продуктов. Я расскажу, как мы это делали и с какими сложностями столкнулись.

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