Что мешает команде развиваться
1. Нечёткие цели. Не стоит надеяться, что "все люди взрослые, достаточно указать направление, а дальше они сами разберутся" - не разберутся
2. Явно не распределена зона ответственности. Каждый будет сваливать на другого если не понимает за что отвечает.
3. Толерантность к лентяям и мудакам. Незаменимых нет, если человек мудак и лентяй, но является бас фактором, проще заменить и починить за ним.
#команда #развитие

Что помогает команде развиваться
1. Открытость. Налаживать простую и понятную коммуникацию с командой на разных уровнях. Объяснять цели и стратегию.
2. Доверие. Строить не только на работе, но и в совместных ритуалах. Необходимо постоянно поддерживать.
3. Требовательность. Когда есть открытость и доверие, то можно требовать друг от друга высокий результат. Подключаем OKR, ретро и т.д.
#команда #развитие

Советы Капитана Очевидность
1. Уважайте себя и окружающих.
2. Задавайте вопросы и просите помочь.
3. Будьте самостоятельными
4. Разберитесь в разнице между «делать и сделать».
5. Планируйте.
6. Не давайте обещаний, которые не сможете выполнить.
7. Не бойтесь ошибок.
8. Результат важнее затраченного времени.
#ко

Как убеждать людей когда у вас нет административных ресурсов
1. Повышайте уровень своей репутации в компании. На него влияют две вещи: насколько хорошие решения вы принимаете, и насколько вы проявляете здравый смысл.
2. До того, как предлагать изменения, разберитесь, почему вещи работают именно так, как работают сейчас. А еще, поработайте с ними самостоятельно, чтобы не опираться только на чужие суждения.
3. Когда вы только начинаете изменения, беритесь за самые низковисящие фрукты. Быстрые победы помогут заслужить доверия для более серьезных изменений.
4. Продавайте любое изменение, как эксперимент: заранее определите критерии успешности и ограничьте время его проведения.
5. Перед тем, как презентовать идею группе людей, продайте ее каждому из группы лично, и отработайте все возможные возражения.
#коммуникация

Как подойти к исполнению задачи когда не хочется
1. Мотивация. Найдите чем себя мотивировать.
2. Минимальный шаг. Начните с реализации самого простого шага.
3. Социальное давление. Пообещайте кому-нибудь, что сделаете это.
4. Найти аналоги в чём-то новом. Решите задачу новым для себя способом, используя новую технологию или поход.
5. Разрешить себе ничего не делать. Иногда нужно просто отдохнуть.
#мотивация

Как развивать сотрудников
1. Составить матрицу компетенций отвечающую интересам компании
2. Провести скрининг разработчика и заполнить матрицу
3. Провести One-2-One с разработчиком выяснив желание развиваться
4. Выбрать направления развития отвечающие интересам разработчика и компании
5. Определить критерии прогресса и контрольные точки
6. Документировать все результаты
7. Договориться как компания будет учитывать время потраченное разработчиком на развитие. Должно ли оно компенсироваться или компания рассчитывает на саморазвитие в свободное от работы время. Условия должны быть прозрачны для разработчика
#ипр #развитие

Причины ухода сотрудников
1. Слабая группа - коллектив, на который нельзя положиться
2. Безразличный лидер - не отвечает на запросы группы
3. Бессильный покровитель - нет перспектив в развитии, продукт не развивается
4. Группа меня не приняла - никто не коммуницирует, не даёт задачи, создаётся ощущение ненужности сотрудника
#мотивация #команда

Вопросы для one-to-one
1. Тебе нравится здесь работать, от 1 до 10 - где 10 лучшее место на земле, 1 хуже не придумаешь. Если сотрудник называет например 7, то уточняем, почему не 8, чего не хватает чтобы стать на 1 балл лучше. Фиксируем информацию для дальнейшего развития
2. Что стало лучше за последние пол года? Что стало хуже? Оцениваем, туда ли мы движемся. Если стало хуже, зафиксировать для дальнейшего обсуждения.
3. Насколько тебе нравятся задачи? Чем хочешь заниматься в будущем? Тебя устраивает роль в команде? Выясняем, чувствует ли человек себя на своём месте.
#one2one

Отчет по результатам one-to-one
1. Что спрашивали
2. Какие мероприятия по итогу запланированы
3. Summary на команду - противоречия, запросы
4. Summary на каждого сотрудника - что беспокоит, что хочет изменить
5. Выявленные конфликты
#one2one

Подготовка к one-to-one
1. Нужно подходить подготовленным, должен быть список вопросов. Нужно поднять информацию о сотруднике, какие проблемы у него были в прошлом, какие действия для их решения были предприняты
2. Перед встречей должны быть обозначены договорённости о неразглашении, что данная информация остаётся только между вами и не разглашается между сотрудниками. Или если информация пойдёт далее, то кому, руководителю верхнего уровня или в HR отдел.
#one2one

Признаки пахнущих процессов
1. Вам кажется, что с вами работают нерадивые сотрудники - не хотят работать, не вовлечённые. Проблема может быть как в сотруднике, так и в процессах, когда сотрудник недостаточно осведомлён, выставлены некомфортные условия работы, плохо работает онбординг
2. Формальные отношения - не хотят взаимодействовать пока не будут соблюдены все формальные процедуры. Проблема может быть в том, что на сотрудника падает много ответственности или задач и он таким образом себя ограждает от лишней работы
3. Лишний труд - совещания, планирование спринта, ревю, и т.д занимают довольно много ресурсов
4. Сплошная дребедень - множество разных задач на сотруднике, частые переключения контекста и смена приоритетов, сложно сосредоточиться на одной задаче
5. Я в домике - разработчики не хотят взаимодействовать с другими командами, нарушена коммуникация, желание спихнуть часть работы на кого-нибудь другого
6. Идеальный мир - когда думают, что никаких проблем вообще нет и всё идеально
#процессы

Причины пахнущих процессов
1. Ритуалы - когда процесс есть, а смысл, зачем этот процесс выполняется уже утерян или его не было изначально
2. Ложь - когда команде не говорят истинную цель процесса, например говорить, что KPI не влияют на бонусы, но на самом деле влияют
3. Коммуникации - проблема отсутствия единого языка, непонимание между отделами или между менеджментом и разработкой
4. Неудобство - процесс есть, но он неудобен для использования, тогда его будут саботировать
5. Карго-культ - кто-то так делал и у него всё получилось, давайте делать также без понимания сути процесса
6. Культура - "Культура ест стратегию на завтрак"
#процесы

Как определить пахнущий процесс на этапе внедрения
1. Очевидность - "любая задача имеет простое, легкое для понимания неправильное решение"
2. Безальтернативность - например внедряем Scrum без вариантов альтернативного выбора
3. Так делает Google - внедряем практику, потому что ей пользуется крупная компания типа FAANG, а они ребята не глупые, значит надо делать так-же
4. Так сказал Kent Beck - когда решение выбирают опираясь на авторитет источника, скрам гайда, доклада с конференции и т.д.
5. Я так сказал - внедрение практик по команде сверху
#процесы

Как построить вовлеченную команду
1. Втягивайте команду в совместное принятие решений - Эффективное решение = Правильное решение х Уровень приверженности
2. Вовлекайте в принятие решений постепенно: - Давать указание, - Продать решение, - Советоваться с командой, - Договориться, - Советовать команде, - Спрашивать у команды
3. В разные решения можно вовлекать на разных уровнях, например в процессе Оценки задач - Советовать команде, а в процессе Собеседований - Советоваться с командой
4. Помогайте людям договариваться и принимать решения - фасилитация
#команда #мотивация

Теория принятия решений
Принятие решений - процесс, предпринимаемый для того, чтобы улучшить состояние принимающего решение в будущем

Три главные компоненты процесса принятия решений
1. выбор одной альтернативы
2. распределение ограниченных ресурсов
3. выработка соглашения с оппонентами

Этапы процесса принятия решений
1. Осознание задачи
2. Определение цели
3. Сбор и анализ информации
4. Определение множества альтернатив
5. Разработка системы критериев для оценки альтернатив
6, Определение шкалы для каждого критерия
7. Переход от субъективных оценок к числовым
8. Установление порогов отсечения
9. Анализ множества вариантов, построение нового множества вариантов
10. Оценка сравнительной важности критериев и построение иерархий (если необходимо)
11. Выбор вариантов агрегирования оценок
12. Агрегирование
13. Анализ и интерпретация результатов
14. Реализация выбранного варианта

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

Принятие решений в условиях высокой неопределённости
1. Не существует ситуации когда нам неизвестно вообще ничего. Что-то мы уже знаем. Нужно понять, что у нас есть какое-то базовое знание, которое может служить отправной точкой
2. Что мы ещё знаем про эту ситуацию? Анализируем, что нам известно из данной предметной области, аналогичные случаи, предыдущий опыт
3. Откуда я это знаю? Нужно отсеять ценные знания от надуманных. Исключить ту информацию, которая строятся на домыслах
4. Где ещё я могу взять то, чего мне не хватает? Анализируем какие источники информации по данной проблеме нам доступны
5. Как я сейчас могу это узнать? Если нам важно принять решение сейчас, планируем следующие шаги по получению информации из доступных в данный момент источников

Итого: Утверждение, что у нас нет достаточной информации верно только в контексте - Сейчас
Утверждение, что нам негде взять информацию - Иллюзия
(кроме случаев конфиденциальной или секретной информации, но это относится к исключениям)
#решения

Peer review
Какие техники, помимо классического Code Review можно внедрить в команду?

1. Code Review - Несёт в себе проблемы:
*Занимает много времени от разработки
*Не находит сложных проблем
*Приводит к потере мотивации
*Сложно сделать хорошо
2. Ideal Review - ревю которого нет, но чьи функции выполняются:
*Code auto format
*Strong type system
*Static code analysis
*Automatic testing
3. Design Review - Перед началом работы над задачей описываем Как мы её будем делать, составляя Tech Design. Tech Lead проводит ревю дизайна, советует как сделать лучше. Разработчик корректирует Tech Design и пишет по нему код
4. Expert Review - ревю проводит специалист по заданному направлению для оценки критически важных секций
5. Review on-demand - Если сомневаемся в решении, обращаемся к коллеге проверить конкретную часть кода.
6. Seagull-style Review - Когда задача уже закрыта, один разработчик проверяет "отлежавшийся" код другого разработчика, на устаревание, анализа мест для оптимизации, изучения чужого опыта. Основной посыл - изучение, а не критика
#review