Менеджмент

Секции направления:

Секции
Сложность
Залы

Евгений Казначеев
VP of Product @ Ecwid
Ульяновск
Тема доклада уточняется

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


из Голосование

Тезисы доклада уточняются


Александр Горник
CEO @ Mindbox
Москва

Расскажу про роли и процессы в разработке mindbox. Результат 13ти лет эволюции Agile в бизнесе, где разработчик стал совладельцем и CEO.

  • Архитектор, скрам-мастер, продукт, стейкхолдер — кто это?
  • За что отвечает команда разработки
  • Как создать гильдии вокруг демо
  • Что измеряем вместо скорости
  • Какие инструменты используем
  • Как применяем социократию и самоуправления: роль открытого P&L и самоназначения ЗП

В нашей разработке 60 человек, 7 команд, 500 млн в год выручка продукта и быстро растем.


Георгий Могелашвили
Lead Developer @ Booking.com
Амстердам

Я - разработчик со стажем более 15 лет. И я также был тимлидом более трех лет. И знаете что? За время управления командами я узнал вещи, про которые мне никто не рассказывал, пока я был разработчиком. И очень зря...

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

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


Александр Орлов
Со-основатель и управляющий партнер @ Стратоплан
Санкт-Петербург
Выгорание тимлида

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


из Доклады

    Профессиональное выгорание: кто виноват и что делать. Рассказ от первого лица.

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

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

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


    Ilya Roslyakov
    Engineering Manager @ Wargaming, Platform
    -
    Карьерные уровни в Wargaming, Platform Управление командой

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


    из Доклады

      Сотрудники хотят расти в компании и за её пределами,

      руководители - простых инструментов и переговоров,

      компания - роста компетенций и автономии сотрудников.

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

      * Как связаны карьерные уровни и зарплата?

      * Зачем вообще нужны карьерные уровни?

      * Как продать карьерные уровни руководству?

      * Как внедрить карьерные уровни?

      * Чем отличаются грейды и карьерные уровни?

      * Как привнести пользу и не нанести вред открытостью?

      * Как лавировать между уровнями рынка, Гугла и внутри компании?

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


      Александр Поломодов
      Руководитель разработки в управлении Привлечением @ Тинькофф
      Москва
      SOLID'ный тимлид или основы менеджмента для технарей

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


      из Доклады

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

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


        Андрей Гирин
        Scrum Master, Release Train Engineer @ Ak Bars Digital Technologies
        Казань
        Как готовить performance review, чтобы все были счастливы и никто не уволился

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


        из Доклады

          На примере кейса разберем:

          - Как можно остаться в любимой команде и повысить свой доход

          - Как можно помочь компании и получить удовольствие

          - Как, используя performance review, можно демотивировать сотрудника

          - Как, используя performance review, можно замотивировать сотрудника на развитие и достижения


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

          Санкт-Петербург
          Сам себе HR

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


          из Голосование

          Найм в IT — задача не самая тривиальная, и этим часто приходится заниматься тимлидам и инженерам. Я расскажу про то, как собрать крутую команду из ничего без помощи HR’ов и бюджета на высокие зарплаты. С чего начать? Как понять, сколько и на какие позиции сотрудников нанимать? Как правильно делать отбор? В докладе будет всё про найм айтишников: от поиска кандидатов и проведения собеседований до оценок инженеров и психологических аспектов ввода новых людей в команду.

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


          Григорий Бычек
          Руководитель отдела разработки @ Ratio
          Ростов-на-Дону
          Как перевести команду разработки на новые технологии

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


          из Доклады

            Успешная деятельность в IT невозможна без развития. Но развиваться можно по-разному. Один из вариантов — переход на новые технологии.

            В своём докладе поделюсь опытом и расскажу:

            1. Зачем переходить на новые технологии

            2. Какие могут быть риски

            3. К каким затратам нужно быть готовыми

            4. Пошаговый процесс внедрения

            5. Как оценивать результаты перехода


            Олег Силаков
            Head of X-Cart App Development @ SellerLabs
            Ульяновск
            Строить - не ломать! Почему продакт менеджеру нужно уметь не только создавать фичи, но и вовремя их удалять.

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


            из Голосование

            Мечта любого продакт менеджера — придумывать фичи и выводить новые продукты. Но что делать если фич или продуктов в линейке компании слишком много? Как не потерять фокус и мужественно отсечь ненужные детали. Расскажу на примере ManyChat и X-cart почему стоит переделывать популярные фичи и как отказаться от продукта даже если он приносит деньги.


            Дмитрий Ивко
            Lead Front-end @ altarix
            Самара
            Выбор методики разработки или как реализовать план Барбаросса

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


            из Голосование

            Перечисления вариантов разработки SCRUM, KANBAN и т.д.

            Ньюансы которые возникают при использование

            Выводы из личного опыта использования всех известных подходов


            Дмитрий Ивко
            Lead Front-end @ altarix
            Самара
            Как создать dream team

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


            из Голосование

            Как набирать людей к себе в команду

            Какие качества должны быть у кандидата

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

            что мотивирует сотрудников работать лучше

            как добиться от сотрудников автономности.


            Андрей Гирин
            Scrum Master, Release Train Engineer @ Ak Bars Digital Technologies
            Казань
            Скрам-Мастер как Лидер-Слуга

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


            из Доклады

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


              Максим Валовой
              Руководитель отдела внедрения IT проектов @ Apriorum Group
              Волгоград
              Отрицательный KPI как инструмент повышения эффективности работы команды

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


              из Голосование

              KPI- наш помощник в оценке эффективности работы сотрудников. Он позволяет правильно выстроить взаимоотношение с командой, мотивировав ее на результат. Принято делить KPIкатегорийной: менее 90% плана - плохой результат, 100% - норма , более 100% отлично. И как правило все основные бонусы к заработной плате находятся в интервале от 100%)) но KPI, как средство, довольно безликое. Это голая статистика, которая не всегда может отражать все аспекты работы. К примеру, она может защитить интересы 1 человека, но навредить команде. Каким образом? Допустим у нас в команде есть человек, который отлично выполняет свои функции, по его KPI к нему нельзя придраться, но его нахождение в коллективе угнетает команду, делает ее менее эффективной. Человек заострен только на своих интересах и его коммуникация с командой, негативно сказывается на личных результатах членов команды и всей команды в целом. К примеру, человек просто ходит и бесит всех) неуместно шутит, дезорганизует, мешает. Если вы формируете команду акул, то тогда вопросы непосредственно к карпам! Если же все обстоит иначе, то смена одного такого сотрудника может дать +100% к эффективности команды в денежном эквиваленте.


              Михаил Вдовин
              Владелец продукта @ Profee.Lab
              Казань
              Metrics Driven Development

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


              из Доклады

                Как разрабатывать продукт, опираясь на продуктовые метрики? Что именно нужно измерять? И как быть, если измерять это больше нет смысла?

                Когда мы создавали чат-бот Aimee в блоке R&D, то и представить не могли, какое количество банковских процессов этот продукт будет обеспечивать сегодня. Всё благодаря тому, что у нас не было "плана-графика" на несколько лет вперёд, а решения о развитии принимались исходя из актуальных потребностей бизнеса. А как понять, соответствует ли продукт потребностям? Нужно измерить это!

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


                Илья Якямсев
                Scrum Master, Release Train engineer @ Wiley
                Королев
                Говорите пожалуйста

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


                из Доклады

                  Зачем нужны гуманитарные науки обычному инженеру.

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


                  Денис Соболев
                  Content Product manager @ Skyeng
                  Москва

                  Почему этап планирования так важен и зачем на него тратить ежемесячно 20 часов своего времени?

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

                  Второе преимущество: с хорошим планом реже возникают моменты «простоя», мы быстрее принимаем решения и не забываем важное.

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

                  В своем докладе я расскажу:

                  - Что нужно делать, чтобы сделать хорошее планирование.

                  - Из каких источников можно взять идеи и как быстро отсеять невыгодные, сэкономив время.

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

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


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

                  Санкт-Петербург

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

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


                  Валентин Севастьянов
                  Генеральный директор @ ГОРОДРАБОТ.РУ
                  Йошкар-Ола

                  Три директора одновременно. Инициатива наказуема. Детализированные задачи. Вокруг враждебная среда. Вся ответственность на руководстве

                  Фэйл при самостоятельном внедрении

                  Ретроспектива, как много мы узнали. Лечение болезней

                  Пришло время договариваться

                  Зачем и что мы делаем? Фокус, цели и декомпозиция

                  Скрам-мастер или совместитель?

                  Голос из прошлого. Нам нужен психолог

                  Безопасная среда из кремниевой долины

                  Миссия и ценности

                  Agile. ONE TO ONE и Performance review

                  Мы готовы к масштабированию


                  Андрей Ревяшко
                  CIO @ WILDBERRIES
                  Москва
                  Ставим разработку на новые рельсы

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


                  из Голосование

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

                  Приличную долю бюджета в компаниях кушают “задачи пустышки” – эдакоя раковая опухоль. За ними можно охотиться и пытаться их вовремя ликвидировать, но лучше ликвидировать среду, в которой они размножаются.

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

                  Совместимы ли Agile и техническое задание? По мне так нет. Ведь рынок технологий и маневры компаний так изменчивы на сегодняшний день, что ТЗ лишь в редких случаях доводит дело до конца – говоря о быстрорастущей компании. Так, что не стоит тратить на него время.


                  Виталий Чесноков
                  Генеральный директор @ QSOFT
                  Москва
                  SCRUM в водопаде

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


                  из Голосование

                  - Как быть, если договор фиксированный, а заказчик хочет Scrum?

                  - Буря в стакане: скоуп, цена или срок?

                  - Scrum в Enterprise - он существует?


                  Алексей Трошин
                  Руководитель департамента IT-разработки @ ФИНАМ
                  Москва
                  Знания и компетенции в команде: найти, увидеть, прокачать

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


                  из Голосование

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

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


                  Гузель Рахимова
                  Руководитель проектов развития бизнеса @ Directum
                  Ижевск
                  Инструменты R&D исследований для эффективного Time2Market

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


                  из Голосование

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

                  Эффективный Time2Market подразумевает поставку на рынок востребованных продуктов. Как оценить востребованность продукта, если у нас в голове только идея. Как понять, не потратим ли мы время зря, проверяя идею. Как определить качество полученного результата: убираем на полку или работаем дальше. Какие есть критерии перпективности. Рассмотрим эти вопросы на примере нескольких исследований.


                  Карим Аминов
                  QA Head @ Eqvanta
                  Казань
                  Свой путь в Agile или как научить команду работать и отдыхать.

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


                  из Голосование

                  Зачем мы лезем в гибкие методологии.

                  История своего "почти успеха".

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

                  Отказ от ежедневных привычек.

                  Чек-лист успешного проекта и ещё пара секретов.