Войти через соцсеть:
Войти через email:
Секции направления:
По этим критериям поиска ничего не найдено
Программный комитет не принял решения по этому докладу
Тезисы доклада уточняются
Доклад принят в программу конференции
Расскажу про роли и процессы в разработке mindbox. Результат 13ти лет эволюции Agile в бизнесе, где разработчик стал совладельцем и CEO.
В нашей разработке 60 человек, 7 команд, 500 млн в год выручка продукта и быстро растем.
Я - разработчик со стажем более 15 лет. И я также был тимлидом более трех лет. И знаете что? За время управления командами я узнал вещи, про которые мне никто не рассказывал, пока я был разработчиком. И очень зря...
Когда ты разрабатываешь софт, то может казаться, что единственное, что тебе надо делать, чтобы быть успешным, это писать хороший код. Однако, когда дело доходит до повышения, новым тимлидом или синьором становится тот, чей код может быть хуже твоего. И оказывается, что этот человек хорош в чём то ещё. Но в чём? Понять это можно, если посмотреть на разработчика с точки зрения менеджера.
Мне повезло, я был менеджером какое-то время. И вернувшись в разработку, я могу с точностью сказать, что именно так не хватает некоторым толковым парням и девчонкам, чтобы стать новыми тимлидами или синьорами у нас в компании. Я выделил шесть основных вещей, про которые и расскажу в своем докладе.
Профессиональное выгорание: кто виноват и что делать. Рассказ от первого лица.
Что объединяет врачей, психологов, педагогов, менеджеров, инженеров, тимлидов? Нет, зарплата у них всех разная, а вот с людьми им приходится работать одинаково много. Что создает благодатную почву для эмоционального выгорания, которое:
Проявляется нарастающим безразличием к своим обязанностям и происходящему на работе, дегуманизацией в форме негативизма по отношению как к клиентам (пациентам), так и к коллегам (сотрудникам), ощущением собственной профессиональной несостоятельности, неудовлетворенности работой, в явлениях деперсонализации, а в конечном итоге в резком ухудшении качества жизни. В дальнейшем могут развиваться невротические расстройства и психосоматические заболевания.
На докладе мы как раз поговорим о том, как понять, на какой стадии к профессиональному выгоранию находитесь вы и ваши сотрудники, чего ожидать дальше и какие пути решения есть.
Сотрудники хотят расти в компании и за её пределами,
руководители - простых инструментов и переговоров,
компания - роста компетенций и автономии сотрудников.
Примерно два года мы в Wargaming, Platform работаем над внедрением карьерных уровней и наконец вышли на финишную прямую. Я поделюсь тем, что у нас получилось, и вы даже сможете покритиковать - потому что мы за открытость и объективность. А ещё поделюсь найденными нами ответами на наиболее сложные по нашему опыту вопросы:
* Как связаны карьерные уровни и зарплата?
* Зачем вообще нужны карьерные уровни?
* Как продать карьерные уровни руководству?
* Как внедрить карьерные уровни?
* Чем отличаются грейды и карьерные уровни?
* Как привнести пользу и не нанести вред открытостью?
* Как лавировать между уровнями рынка, Гугла и внутри компании?
* Как договориться до минимальных, но достаточных определений уровней?
Часто получается так, что тимлидом в команде становится самый прокачанный разработчик. Зачастую этот разработчик хорош в hard skill’ах, но менеджментом до этого не занимался. В своем докладе я попробую рассказать о том, как принципы SOLID могут помочь технарю понять базовые правила менеджмента. Мы поговорим про людей и их роли, а также поймем все ли из этих принципов применимы к управлению командой.
Кроме этого мы поразмышляем над организацией процессов разработки и проведем параллели между ними и подходами оркестровки и хореографии в распределенных системах.
На примере кейса разберем:
- Как можно остаться в любимой команде и повысить свой доход
- Как можно помочь компании и получить удовольствие
- Как, используя performance review, можно демотивировать сотрудника
- Как, используя performance review, можно замотивировать сотрудника на развитие и достижения
Найм в IT — задача не самая тривиальная, и этим часто приходится заниматься тимлидам и инженерам. Я расскажу про то, как собрать крутую команду из ничего без помощи HR’ов и бюджета на высокие зарплаты. С чего начать? Как понять, сколько и на какие позиции сотрудников нанимать? Как правильно делать отбор? В докладе будет всё про найм айтишников: от поиска кандидатов и проведения собеседований до оценок инженеров и психологических аспектов ввода новых людей в команду.
Найм людей — это ответственное и сложное дело, но я расскажу о методиках, которые многократно облегчают этот процесс. Постараюсь показать всё на примерах из моей практики. А также укажу на важные моменты, которые иногда упускают из вида. Особую роль в подборе новых сотрудников играют особенности конкретных команд и проектов, я расскажу, на что стоит обращать внимание, чтобы новый инженер идеально дополнял существующий коллектив. Нет ничего невозможного, даже при скромных возможностях компании можно собрать успешную команду.
Успешная деятельность в IT невозможна без развития. Но развиваться можно по-разному. Один из вариантов — переход на новые технологии.
В своём докладе поделюсь опытом и расскажу:
1. Зачем переходить на новые технологии
2. Какие могут быть риски
3. К каким затратам нужно быть готовыми
4. Пошаговый процесс внедрения
5. Как оценивать результаты перехода
Мечта любого продакт менеджера — придумывать фичи и выводить новые продукты. Но что делать если фич или продуктов в линейке компании слишком много? Как не потерять фокус и мужественно отсечь ненужные детали. Расскажу на примере ManyChat и X-cart почему стоит переделывать популярные фичи и как отказаться от продукта даже если он приносит деньги.
Перечисления вариантов разработки SCRUM, KANBAN и т.д.
Ньюансы которые возникают при использование
Выводы из личного опыта использования всех известных подходов
Как набирать людей к себе в команду
Какие качества должны быть у кандидата
Как надо производить обучение и при этом не перегибать
что мотивирует сотрудников работать лучше
как добиться от сотрудников автономности.
Часто говорят о том, что скрам-мастер это лидер-слуга, но мало кто понимает, что это означает. Мы с вами попробуем разобраться, что за явление servant leadership и каким он должен быть, пресловутый лидер-слуга.
KPI- наш помощник в оценке эффективности работы сотрудников. Он позволяет правильно выстроить взаимоотношение с командой, мотивировав ее на результат. Принято делить KPIкатегорийной: менее 90% плана - плохой результат, 100% - норма , более 100% отлично. И как правило все основные бонусы к заработной плате находятся в интервале от 100%)) но KPI, как средство, довольно безликое. Это голая статистика, которая не всегда может отражать все аспекты работы. К примеру, она может защитить интересы 1 человека, но навредить команде. Каким образом? Допустим у нас в команде есть человек, который отлично выполняет свои функции, по его KPI к нему нельзя придраться, но его нахождение в коллективе угнетает команду, делает ее менее эффективной. Человек заострен только на своих интересах и его коммуникация с командой, негативно сказывается на личных результатах членов команды и всей команды в целом. К примеру, человек просто ходит и бесит всех) неуместно шутит, дезорганизует, мешает. Если вы формируете команду акул, то тогда вопросы непосредственно к карпам! Если же все обстоит иначе, то смена одного такого сотрудника может дать +100% к эффективности команды в денежном эквиваленте.
Как разрабатывать продукт, опираясь на продуктовые метрики? Что именно нужно измерять? И как быть, если измерять это больше нет смысла?
Когда мы создавали чат-бот Aimee в блоке R&D, то и представить не могли, какое количество банковских процессов этот продукт будет обеспечивать сегодня. Всё благодаря тому, что у нас не было "плана-графика" на несколько лет вперёд, а решения о развитии принимались исходя из актуальных потребностей бизнеса. А как понять, соответствует ли продукт потребностям? Нужно измерить это!
О том, как мы подбирали метрики, как измеряли их, проверяли гипотезы, как всё это отражалось на бэклоге и к чему привело, я расскажу в своём докладе, с примерами и картинками.
Зачем нужны гуманитарные науки обычному инженеру.
Вы настроили всякие эджайлы, объяснили людям как оно работает, поставили события для ретроспективы и внезапно обнаруживаете, что люди сами по себе не умеют разговаривать. Что с этим делать и куда смотреть.
Почему этап планирования так важен и зачем на него тратить ежемесячно 20 часов своего времени?
Все дело в том, что планирование уменьшает неопределенность, в частности, избавляет нас от мук выбора - какой проект или идею нужно реализовать первым. Неутешительная статистика такова, что из 10 идей выстреливает только 1. В глубине души каждый из нас, скорее всего, надеется, что той самой идей, которая выстрелит, станет первый проект. Надежда - дело хорошее, но нам нужно что-то понадежнее, поэтому я расскажу про алгоритм действий, позволяющий уже на этапе проектирования отсеять невыгодные идеи.
Второе преимущество: с хорошим планом реже возникают моменты «простоя», мы быстрее принимаем решения и не забываем важное.
Кроме того, этим документом можно отмахиваться от всех, кто что-то от вас необоснованно хочет. Сплошная польза!
В своем докладе я расскажу:
- Что нужно делать, чтобы сделать хорошее планирование.
- Из каких источников можно взять идеи и как быстро отсеять невыгодные, сэкономив время.
- Какие проекты нужно реализовывать в первую очередь, чтобы увеличить вероятность успеха.
- В каком формате представить результаты планирования для руководства, чтобы одобрили бюджеты.
По мере роста компании сталкиваются с разными проблемами и трудностями, старые подходы управления разработкой перестают работать. И моя компания не стала исключением, мы наделали кучу ошибок, пришлось выходить из сложных ситуаций. Решили использовать Канбан-метод. Я расскажу, как с его помощью мы подружили разработку и бизнес и избежали жертв с обеих сторон. Мы освободили инженеров от бесполезных задач, научились вычислять эффективность задач, наконец, изменили отношение людей к разработке.
Покажу, во что можно превратить статистику в умелых руках. Я расскажу, как мы с её помощью научились планировать процесс так, чтобы у инженеров хватало времени не только на текущие и срочные задачи, но ещё и на улучшение системы в целом. Наглядно покажу, как мы добились увеличения скорости разработки и экономии времени за счёт отказа от лишних митингов и обсуждений. Также расскажу, как мы с бизнесом договорились о соглашении о качестве сервиса (SLA) и как научились планировать с бизнесом без помощи и отрыва от работы программистов. А со стороны разработчиков покажу, какие статистические показатели снимали и показывали бизнесу.
Три директора одновременно. Инициатива наказуема. Детализированные задачи. Вокруг враждебная среда. Вся ответственность на руководстве
Фэйл при самостоятельном внедрении
Ретроспектива, как много мы узнали. Лечение болезней
Пришло время договариваться
Зачем и что мы делаем? Фокус, цели и декомпозиция
Скрам-мастер или совместитель?
Голос из прошлого. Нам нужен психолог
Безопасная среда из кремниевой долины
Миссия и ценности
Agile. ONE TO ONE и Performance review
Мы готовы к масштабированию
Найдите разработчика у кого больше всех задач – так вы найдете самого главного бездельника. Много задач в работе это очень удобно - много чего делается, но мало чего доделывается и главное всегда есть чем оправдать время, проведенное на работе.
Приличную долю бюджета в компаниях кушают “задачи пустышки” – эдакоя раковая опухоль. За ними можно охотиться и пытаться их вовремя ликвидировать, но лучше ликвидировать среду, в которой они размножаются.
Недостаток разработчиков в монолитном ИТ отделе это не только повод для головной боли менеджерского состава – это еще и повод для ссор между главами департаментов. Монолит это не всегда плохо, но в большой, а уж тем более, быстрорастущей компании это скорее зло.
Совместимы ли Agile и техническое задание? По мне так нет. Ведь рынок технологий и маневры компаний так изменчивы на сегодняшний день, что ТЗ лишь в редких случаях доводит дело до конца – говоря о быстрорастущей компании. Так, что не стоит тратить на него время.
- Как быть, если договор фиксированный, а заказчик хочет Scrum?
- Буря в стакане: скоуп, цена или срок?
- Scrum в Enterprise - он существует?
Однажды я столкнулся с вопросом, как разложить знания в команде по полочкам? Как выяснить, кто в каких областях эксперт, а где у нас узкое место? Как грамотно показать точки роста или объяснить принимаемые решения по распределению работ и задач?
Я расскажу про подход, который мы используем у себя в компании, ставший простым инструментом. В нём видны узкие места в документировании продуктов и в областях знаний членов команды, и теперь мы можем принимать правильные решения в наполнении пустот и развитии недостающих компетенций. Расскажу, как к этому пришли, и покажу, как пользоваться.
В продуктовой разработке важно соблюсти баланс между своими вложениями и выпуском востребованного продукта. На помощь приходят предварительные исследования.
Эффективный Time2Market подразумевает поставку на рынок востребованных продуктов. Как оценить востребованность продукта, если у нас в голове только идея. Как понять, не потратим ли мы время зря, проверяя идею. Как определить качество полученного результата: убираем на полку или работаем дальше. Какие есть критерии перпективности. Рассмотрим эти вопросы на примере нескольких исследований.
Зачем мы лезем в гибкие методологии.
История своего "почти успеха".
Мелочи, которые которые остаются мелочами или как прекратить из мухи делать слона.
Отказ от ежедневных привычек.
Чек-лист успешного проекта и ещё пара секретов.
