Управление

С удаленной работой надо уметь работать так же, как и с обычной "оффлайн". У неё есть свои ловушки, проблемы и последствия. Давайте вместе разберемся, как эти проблемы находить, а главное - что с этим делать!

Расскажу о новом методе стратегического планирования. Много лет я смотрел, как другие делают Impact Map, сам его делал для своих проектов и проектов заказчиков. В итоге, пересобрал этот метод в новый, чтобы можно было точнее определять причинно-следственные связи между бизнес-целями, задачами и гипотезами достижения целей. Назвал этот метод “Карта гипотез”.

Индивидуальный план развития (ИПР) – популярный инструмент в арсенале тимлида.

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

Шарить ИПР на команду, подключить бота с напоминаниями, ввести грейды, проводить ревью для обратной связи – эксперименты с ИПР можно встретить самые различные.

Везде по-разному, но довольно часто можно встретить и кое-что общее: инициатива с ИПР “замерзает”.

Вроде начинали делать и вроде что-то получалось, а потом интерес пропал, причём с обеих сторон. Сотрудник рад, что он него «отцепились», можно сосредоточиться на понятных задачах. Компания расценила, что халявный способ выжать больше пользы из сотрудников не сработал – суеты много, а отдача ниже ожидаемого. Тимлид рад, что можно меньше внимания уделять непонятным гуманитарным делам; глядишь, и попрограммировать останется время.

А потом случается новый проект, в котором нужна новая технология, а её в команде никто не знает – хотя можно было изучить в рамках ИПР. Или люди уходят из команды с обратной связью, что не ощущают развития, только застой – хотя какой-то “не только текучкой” можно было бы позаниматься в рамках ИПР.

Таким образом получается, ИПР нужен, но не работает? Нужен – да, не работает – я видел обратное.

В докладе поделюсь историями из опыта – как отношение к ИПР и результативность процесса получалось изменить в лучшую сторону за счёт более неформального подхода. В чём этот подход состоит и как работает на практике – расскажу в докладе.

Надеюсь, доклад будет интересен тимлидам и инженерам, у кого был неудачный опыт с ИПР по любую сторону процесса, кто испытывает сложности с ИПР прямо сейчас и кто ещё пока не пробовал, но настроен скептически.

На примере истории СимбирСофт поделюсь опытом работы на позиции собственника компании и расскажу про его должностные обязанности. Также немного поговорим про системное лидерство, как один из инструментов управления на уровне владельцев бизнеса.

- Необычные кейсы из практики найма и управления командой разработчиков

- Три лайфхака, как управлять и удерживать сотрудников на высококонкурентном gamedev рынке, особенно когда ты сама играла только в косынку в детстве

- Внутренние сообщества как база для внутреннего взаимодействия

- Вопросы-ответы

- Бюджет маркетинга - «достаточно» это сколько;

- Кроссфункциональная вовлеченность - зачем она нужна;

- Как выглядит план-капкан;

- Убийственные аргументы защиты бюджета

Как рассказывать о своем опыте и шарить экспертизу коллегам?

От скучных daily scrum meeting к интересным стендапам и зажигательным митапам?

Как погружать в контекст, но не перегружать?

Расскажу об опыте моем и компании по подготовке митапов и спикеров.

Остановимся на форматах стендапов, что они дают спикерам и командам. Как это влияет на «пороки команды».

Рассмотрим инструмент обучения спикеров для выступлений внутри команды, донесения информации для топов, работы с внешней аудиторией.

Существует много докладов, статей и подкастов про то, что должны делать тимлиды, и какими качествами обладать.

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

Где-то вам нужно собрать команду с нуля, где-то расширить команду с 5 до 50 человек за 3 месяца, а где-то вывести команду из кризиса за те же 3 месяца, иначе все компании конец. Везде нужен тимлид, но везде нужен разный тимлид, с разными скиллами и разными сферами деятельности.

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

Очень часто тимлиду приходится не только управлять команду, но и участвовать в процессе найма и отбора кандидатов. Поговорим о том, как эффективно настроить этот процесс и сэкономить время при отборе.

- Какая технология в описании вакансии, увеличила количество откликов в 3 раза?

- Как составить сценарий разговора, чтобы рекрутёр мог без вас выявить все красные флаги за первые 15 минут скрининга? Действуем по принципу Fail Fast.

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

Также расскажу о тех лайфхаках, которые нашел для себя за 2 года проведения собеседований.

Бонусом расскажу об особенностях найма в международную команду.

⁃ подход к подбору команды, «роли по Сереже» vs «роли по стандартным типологиям»

⁃ Чем топ-команда отличается от команды разработки

⁃ Цикл жизни команды наложенный на цикл развития ее лидера

⁃ Враги и друзья команды

⁃ Мои ошибки при формировании команды

⁃ 5 советов тем, кто завтра окажется в моей роли

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

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

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

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

- чем привлекать первоклассных специалистов в свои команды;

- как выстроить доверительную коммуникацию между отделами;

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

Скажете, что это утопия? А я отвечу, что реальность.

- Цена проблемы. Сколько теряем мы и другие компании на ранних увольнениях;

- Как предсказать текучку и срок жизни сотрудника еще на этапе найма (19 параметров для оценки кандидатов).

- Best practice (не наступайте на наши грабли): как мы адаптировали оценку под себя, внедрили ее в рамках компании и какие получили результаты;

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

— С чего начать коммуникацию с заказчиком

— Определение внутренней стратегии ведения проекта

— Тактика презентации решения в зависимости от типа клиента

— face-to-face с заказчиком (Как не зря сходить в гости к клиенту)

С фразы «Ставьте задачу досконально» часто начинается путь мучений в отношениях между тем, кто ставит задачу — заказчиком, менеджером продукта или аналитиком — и разработчиками. Этот путь обычно заканчивается тупиком. В докладе я расскажу, почему это происходит, и что делать, чтобы выстроить беспроблемный процесс постановки и передачи задач в разработку.

— Подробно и с примерами расскажу про проблемы стыковки постановщика и разработчика.

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

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

— С технической стороны напомню об инструментах для совместного проектирования и постановки задач Impact mapping, сценарии пользователя, User story mapping, 4 context architecture. Расскажу, как наиболее эффективно пользоваться этими инструментами.

⁃ Зачем?

⁃ У нас есть практики менеджмента, значит у нас есть менеджмент?

⁃ Как? Первые шаги!

⁃ Практические кейсы.

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

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

В ходе доклада выясним:

— К какими проблемами может привести неаккуратная работа с требованиями;

— Как выглядит сквозной процесс управления требованиями;

— Контрольные точки в процессе управления;

— Какие инструменты и методы могут применяться на разных этапах процесса;

— На что обратить внимание при работе на разных этапах. Риски и сложные моменты при управлении требованиями.

В конце, конечно же, сделаем выводы и подведем итоги.

Как при внедрении изменений не совершать ошибок, которые разрушат команду и подорвут доверие к вам.

В докладе я разберу 10 ошибок, которые наш Agile-офис совершил при внедрении важных изменений, расскажу про выводы, которые мы сделали, и то, как мы исправили ситуацию.

- отличия проектного ведения бизнеса (professional services) от классического продуктового подхода

- какие боли есть у организаций продающий профессиональные услуги

- на чем зарабатывают такие организации

- что надо контролировать в этом бизнесе и чем это отличается от классической продуктовой деятельности

- за что отвечает проектных менеджер

- что можно позаимствовать из проектной деятельности для продуктовой разработки

- Как говорить “нет” и приносить бизнес результаты?

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

- Как сохранять фокус на целях?

- Как не демотивировать команду?

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

Чтобы придерживаться второй стратегии - быть центром изменений, в докладе рассмотрим:

1. Как понять, что пришло время изменений. Какие есть драйверы изменений

2. Какие есть фреймворки, помогающие реализовать изменения

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

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

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

1. Как принципы и ценности компании помогают повышать удовлетворенность клиентов

2. Как сформулировать ценности компании на основе потребностей клиента

3. Как негативные кейсы повышают лояльность клиентов

4. Как лучшие практики B2C колл-центров и чат-поддержек помогают выстроить коммуникацию в B2B.

5. А существует ли дружба между клиентом и поставщиком?

— Мотивация и эффективность: может ли быть одно без другого?

— Каковы причины неэффективности? С какими из них можно бороться?

— Топ-5 причин неэффективности бизнес-аналитиков по результатам наших исследований

— Методы и инструменты борьбы с неэффективностью: как помочь самому себе и как это сделать совместно с тимлидом?

1. Уникальность или универсальность? Надежность или риск? Простота или красота? На что стоит сделать упор при разработке вашего продукта и причем тут Нориаки Кано

2. Пошаговый алгоритм применения модели Кано: от составления анкеты до обработки результатов

3. Приоритизация бэклога, маркетинг, принятие решений о необходимости доработок: с чем еще может помочь модель Кано?