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

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

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

Оценка задач

Дмитрий Симонов

- Макро-планирование разработки на длительные сроки.
- Учимся читать нечёткие формулировки от бизнеса с постоянно меняющимися требованиями, их уточнение и проработка: постановка цели, измерение результата, оценка необходимых ресурсов, критерий достижения цели, оценка времени.
- Разбиваем постановку задачи от бизнеса на составляющие, их приоритезация, группировка для технической реализации.
- Участие тестировщиков в постановке задач и дальнейшее их участие в самой разработке.
- "Дизайнерская" работа продуктологов в прототипировании разрабатываемого функционала как способ уточнения постановки задач.
- Техническая декомпозиция задач. Работа по задачам, которые непонятно, как делать.
- Ход реализации задач и типичные проблемы при реализации, оценка сроков, определение, что задачи затягиваются, и действия в случае затягивания сроков.
- План выката в продашкн.
- Работа команды по обработка багов, которые приходят после выката новых фич.
- Комплексная оценка всего затраченного времени.

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

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

Кто такие тимлиды, и какова их реальная задача?

Никита Быков

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

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

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

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

Из закрытой касты в Servant Leader - эволюция тимлида в Booking.com

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

Компания Booking.com существует уже больше 20 лет. За это время она выросла от небольшого голландского стартапа до крупной международной корпорации - лидера на рынке онлайн-бронирования путешествий с офисами по всему миру.

За последние несколько лет Booking.com увеличил количество сотрудников в IT-департаменте. И это повлекло за собой изменения в роли тимлида. Мы прошли путь от причастности тимлида к ограниченному кругу людей ("касте"), частичного отказа от лидов на какое-то время в пользу автономных команд, и до их возвращения под новой концепцией "Servant Leader". В ходе этой трансформации у нас накопилось много полезного опыта, которым я с удовольствием с вами поделюсь.

В своём докладе я расскажу, как мы адаптировались к взрывному росту числа сотрудников в IT и с какими проблемами столкнулись, о роли тимлида в этом процессе, об эволюции этой роли за последнее время, что она значит сейчас, а также как устроен IT-менеджмент в Booking.com в целом.

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

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

Как не сойти с ума. Инструменты TeamLead. Must have

Андрей Гапанюк

1. Сфера ответственности TeamLead.
2. Redmine, JIRA, TFS.
3. Agile, SCRUM, Kanban.
4. Планирование ресурсов, диаграмма Гантта, Microsoft Project.
5. Разработка продукта (.Net). Visual Studio (Microsoft), dotTrace (JetBrains), ReSharper (JetBrains), SQL Assistant.
6. Тестирование, доставка продукта. TFS CI, TeamCity.
7. Поддержка продукта. ELK, Zabix, Microsoft Bot Framework, Dashboard, Skype, Outlook/Nine.
8. Планировщик задач. Хаос-контроль. EverNote. Outlook.

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

Оцениваем разработчика на основе объективных данных

Александр Киселев
Сергей Семенов

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

Но когда разговор заходит о разработчиках, никто не знает, на какие характеристики смотреть, чтобы измерить их эффективность.

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

Обсудим следующие вещи:
- Где брать данные для метрик? github/gitlab/bitbucket, таск трекеры, мессенджеры.
- В поисках универсальной метрики. *Спойлер*: Ее нет.
- Новый подход - идем от проблем. Хороший разработчик - это разработчик, у которого мало проблем.

Разберем конкретные проблемы и найдем под них метрики.
* Индивидуальные:
1. Разработчик часто застревает на задаче.
2. Разработчик плохо прорабатывает задачи до начала разработки.
3. Разработчик-перфекционист.
4. Разработчика постоянно отвлекают.
5. Разработчик демотивирован.
6. Разработчик перегружен.
7. У разработчика нет фокуса на своевременный выпуск задач.
8. Неточные оценки задач.

* Командные:
1. Неравномерное распределение знания кодовой базы.
2. Катимся в пучину технического долга.
3. Текучка разработчиков.
4. Неточные продуктовые требования.
5. Плохой онбординг.
6. Конфликты на код-ревью.

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

Накапливание знаний в команде

Управление знаниями: какие документы нужны и что в них фиксировать

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

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

Маленький пример: в формате user story "как <роль> я хочу <сделать что-то> для того чтобы <достичь целей>" часть с целью появилась не сразу. Она нужна, чтобы разработчик мог поставить себя на место пользователя, если в процессе реализации надо выбрать между несколькими альтернативами. Казалось бы, можно спросить, однако прерывание разработки – дорого, и разработчики часто додумывают за пользователя, и часто ошибались. Указание цели пользователя позволяет уменьшить число неверных решений. Кстати, сам формат появился при переходе к итеративной разработке как средство обеспечить инкрементальную поставку ценного продукта.

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

Подход к проектированию документации аналогичен проектированию интерфейсов: описываешь кейсы коммуникаций, определяешь, какими документами и артефактами это обеспечивается. понимая, что каждый документ имеет свою цену, и потому часть можно оставить в головах людей. И только после определения документов стоит выбирать, какими инструментами пользоваться: Wiki, Google Docs, что оставить в Task tracker и так далее.

Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).

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

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

Как строить свой профессиональный путь - схемы самоопределения

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

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

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

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

Разрешение противоречий в командах и на уровне руководства

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

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

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

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

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

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

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

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

Масштабируем разработку: от стартапа до сотни инженеров. Опыт Badoo

Николай Крапивный

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

В докладе поговорим об эволюции нашего процесса за последние 7 лет. За это время инженерная команда Badoo выросла с 30 до 200 человек и мы собрали много боли и граблей, возникших вместе с ростом компании и увеличением количества задач.

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

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

Раскрытие талантов, психология достижений, OKR

Методы мотивации сотрудников. Способы выращивания сотрудников с нуля

Андрей Минкин

Я стал тимлидом 3 года назад. Я совершенно не понимал, что мне нужно делать, и каков теперь мой круг обязанностей. Мне стало понятно, что мне нужно развивать свою команду и расширять ее. Пришлось работать с наймом сотрудников. В процессе найма я столкнулся с тем, что люди в нашей стране ленивые и не все готовы работать и соблюдать процессы хорошей разработки ПО. Писать тесты, настраивать CI, планировать спринты и укладываться в срок, доводя дела до конца. Пришлось исправлять эти проблемы. Также, ввиду большой конкуренции с рынками РФ и Беларуси, и в связи с большим оттоком кадров, я решил открыть стажировку, на которой люди бы обучались базовым вещам совершенно с нуля.

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

1. Виды позитивной и отрицательной мотивации. На ком что лучше работает.
2. Что было испробовано за 3 года и что зарекомендовало себя с хорошей стороны в нашем случае.
3. Какие личные качества человека мне важны.
4. Что важнее? Софт-скиллы или хард-скиллы?
5. Статистика по итогам трех лет.

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

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

Как мы начали меньше кодить и полюбили общаться с заказчиками

Надежда Дебогори

Гибкая разработка на то и гибкая, что она меняется, подстраиваясь под новые условия и требования. Но нельзя налаживать процесс исключительно со стороны команды. Для ускорения выпуска задач заказчик также должен принимать принципы agile и стараться им следовать.

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

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

Почему с позиции патопсихологии редкий разработчик способен стать управленцем

Юрий Сорокин

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

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

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

В докладе я постараюсь не только поделиться рядом теорий из области патопсихологии, опираясь на которые, мы смогли составить свое подобие алгоритмов по выбору менеджеров и разработчиков в свои проекты. Также поделюсь своими наработками в методах оценки и развития менеджеров и разработчиков внутри команды. Эти методы позволили нам увеличить вдвое «срок жизни» сотрудников на проектах.

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

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

Как научить тимлидов давать фидбэк

Евгения Голева

Рабочее название доклада: "Как внедрить практику позитивного и конструктивного фидбэка в высококритичную среду разработчиков".

Зачем нужен этот навык? Что ломается в компании, когда навыка нет, и сколько это стоит? Почему эффект от тренингов стремится к нулю?

Эти вопросы затронем, но нет, я не буду продавать саму идею фидбэка. Если пришли, значит, уже наболело, для вас очевидна ценность и важность этого скила у тимлидов. Доклад точно не тренинг по тому, как давать фидбэк. Хотя, основные принципы буду напоминать.

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

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

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

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

В поисках динамического равновесия команды

Константин Андрюнин

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

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

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

Будут затронуты вопросы:
- командной организации (естественные и искусственные формы);
- командной самомотивации (как конструктивной, так и токсичной по отношению к команде);
- наращивания команды (когда, кем, как);
- стратегии подбора / замены людей в уже сложившиеся коллективы.

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