Менеджмент

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

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

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

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


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

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


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

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


из Доклады

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

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

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

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


    Евгений Кот
    Director of Development @ Wrike
    Прага
    Про Лидерство, или как я съел интроверта

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


    из Доклады

      Все книги, наставления и методички пишут, что без лидерства менеджеров не бывает. Вбейте в поисковике “Leadership principles”, и на вас тут же прыгнут “Amazon, 7 ways to success”, “Apple story” и прочие красивые истории. И они работают! Ну, в теории. Непонятно правда, что делать, если в книге написано, что “Insist on the highest standards”, а у тебя кругом пожар, команда - не команда, а сроки - вчера.

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


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

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

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

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


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

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

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

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


      Артем Каличкин
      Технический директор Faktura.ru @ ЗАО "Центр Финансовых Технологий"
      Новосибирск

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

      Коллективная ответственность это хороший, но трудно достижимый ориентир. Поэтому в командах нужны лидеры мнений, наделенные как полномочиями, так и ответственностью. Новые должности очередных «менеджеров» создают напряжение в коллективе и запутанные схемы взаимодействия. Вместо этого можно пойти по пути расстановки критичных необходимых ролей в командах из числа действующих играющих членов команд. Для разработки программного продукта такими критичными ролями являются: - тимлид, -техлид, -тестлид. Расскажите им правила игры, обозначьте зону ответственности, дайте полномочия, и дело пойдет. Если вы выбрали правильных людей.


      Дмитрий Калаев
      Директор Акселератора @ Фонд развития интернет-инициатив
      Москва
      Отличия продуктов-лидеров от компаний, не оправдавших надежд

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


      из Доклады

        – Как найти окно возможностей для нового продукта

        – Как стать лучше конкурентов?

        – Как захватить рынок конкурентов быстрее?

        – Основные факторы успеха

        – Инструменты успешного предпринимателя: lean startup, customer development


        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 - он существует?