[Разработка веб-сайтов, Управление разработкой, Управление проектами, Управление персоналом] Записки юного TeamLead: Ошибки, о которых не стыдно говорить
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Честно сделанные ошибки следует считать не неудачами, а семенами для основной деятельности по их исправлению
ПредисловиеБуквально несколько дней назад был "субботник" у одной компании с красно-белым лого. В первом докладе спикер рассказывал про оси развития разработчика. Всего он выделил три оси:
- Технологии
- Продукт
- Люди
В целом, он не ошибся. Любой разработчик может уйти в сторону оси "Технологии" и делать свой стек технологий сильнее - становиться ведущим или старшим разработчиком. Можно попробовать прокачать себя в оси "Продукт" - уйти в PM и потом пойти дальше по матрице компетенций и расти по вертикали. Но есть еще одна ось, о которой можно много говорить, о которой много пишут, писали, и будут писать - "Люди". Управление людьми, работа с командой напрямую, выстраивание своих локальных процессов разработки - участь TeamLead (далее TL). Я осмелился написать этот пост на основе своих же ошибок. Мне не стыдно их признать, не стыдно рассказать о них, показать, что некоторые тактики не всегда помогают. ОшибкиВсе их допускают, без них никуда. На основе ошибок можно понять слабые места, понять, что и где нужно исправить или убрать. Ошибки толкают нас к движению, к прогрессу. Вот и я будучи TL в компании в первые месяцы допустил несколько больших ошибок. ДовериеОшибка, которую допускают, я думаю, многие TL, в том числе и я - отсутствие доверия к своей команде или к людям из команды.
Мысли аля "Я могу сделать это лучше" первое время постоянно рядом, из-за этого получается, что вы перегружаете себя и, конечно же, не успеваете. Ведь помимо разработки у вас есть другие не менее важные задачи. Решение данного вопроса очень простое: нужно учиться доверять, оценивать людей не только по их личным, но и по их техническим характеристикам. Тогда будет намного легче. Возможно, вы перестанете быть звездой-гением-мысли-лучшим разработчиком среди всех разработчиков в компании, но вы будете хорошим TL, который умеет самое главное - доверять. От этого вам плюсик в карму от команды. Оценка сроковДругая не менее распространенная ошибка - Ошибка в оценке сроковИногда, на глобальном планировании на несколько спринтов вперед бизнес может сказать "Нам нужно это, это, и вот это - сможешь?".
Тут начинается игра "Кто хочет стать Багоделом", потому что чем больше вы возьмете на себя и свою команду, тем больше будет проблем потом. Проблемы будут появляться из-за:
1. Непредвиденных обстоятельств, блокирующих задач других людей или команд
2. Сложности. То, что по заявлением должно делаться N часов - делается 2N часов - отсюда смещение по времени и нарушение дедлайнов
3. Перегруженности команды: в высоком темпе разработчик работать может, но недолго - дальше выгорание и потеря сотрудника.
В итоге, получается ситуация, где все можно успеть, но или очень с очень плохим качеством (т.е. техническим долгом), или с убитой командой, или (самый благоприятный исход) - просто не успеть. ПриоритетыЭто особенно важная история в рамках команд, которые работают над несколькими большими задачами в спринте.
Принцип прост: сильному разработчику -- более сложная и приоритетная задача. Разработчику послабее -- задача его уровня. Но тут нужно понимать одну вещь, связанную с развитием каждого разработчика отдельно - нельзя вечно держать разработчика на задачах его уровня. Нужно вкидывать хотя бы иногда что-то сложнее и интереснее, ведь разработчик заинтересован в своем развитии. Отсюда появляется следующая ошибкаОтсутствие развития сотрудников в профессиональном плане Вы как TL должны думать не только о том, какие фичи поставляет ваша команда, но и том, как развивать каждого члена команды в отдельности. Ведь все абсолютно разные, у всех свой опыт и свой бэкграунд, а значит каждому нужна своя траектория развития.
Вряд ли разработчик будет сидеть на одних и тех же задачах - он потребует больше, интереснее, сложнее. Учитывая это, TL может построить правильную траекторию развития каждого разработчика. Общение с разработчиками Или One-to-One. Лучший способ узнать что происходит у разработчика - прямо спросить. И не обязательно спрашивать "ну что, как там с задачами?". Нужно быть человеком и искренне проявлять интерес к жизни сотрудника. Спросить что-то отвлеченное от работы или обсудить, к примеру, вчерашний футбольный матч - прекрасное начало диалога, который поможет больше понять что беспокоит сотрудника. Если необходимо спросить про трудности с задачами - это стоит делать без претензией, а с искренним желанием помочь. Ошибок, которых я допустил - тысяча. Но скажу одно - даже у ошибок есть польза. Нужно просто уметь получать эту пользу.Конфликты Самое страшное, что может случиться в команде - это конфликт между разработчиками. Что самое забавное, его причины достаточно прозаичны, например - pull request был предвзято оценен или чрезмерно раскритикован. И самое неприятное в конфликте то, что он может быть продолжительным и он может съесть день вашего времени. Решение конфликта кроется в общении:
1. С каждым по-отдельности - разговор one-to-one для поиска причины и оценки ситуации
2. Совместно с конфликтующими - разговор, который направит на нахождение компромисса Это поможет быть:
1. Ближе к команде
2. Справедливее. Вы не занимаете стороны - вы стремитесь к общей идее сплоченной команды Не занимайте стороны, не говорите эмоциями - говорите фактами. Заключение статьиСейчас, спустя несколько месяцев работы TL, я могу с уверенностью сказать, что многие вещи в команде стали лучше. И процессы разработки, и качество кода, и взаимоотношения с командой. И стали они лучше благодаря одной простой вещи - признанию своих ошибок.
Проблема производительности команды не кроется в отдельных разработчиках - она кроется в грамотной постановке не только дедлайна и задачи, но и в условиях, в которых разработчики каждый день находятся, в правильной "постановке атмосферы" разработки - надеюсь не перемудрил и вы меня поняли. Если кратко: сделать комфортные условия и увеличить КПД - вот задача тимлида.
В следующей статье я расскажу о других наблюдениях, или "очевидных открытиях". А пока спасибо за внимание и до скорых встреч. Жду ваши отзывы и предложения.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Agile, Управление продуктом, Управление персоналом] SCRUM: Понимание и применение фреймворка
- [Разработка веб-сайтов, CSS, Программирование, Java] От студента до учителя: как разобраться в веб-разработке, если это не твой профиль
- [Управление персоналом] Онбординг как пятизвездочный отель: пять важных мыслей для оптимального трудоустройства новых сотрудников (перевод)
- [Управление проектами, Развитие стартапа, Управление продуктом, Бизнес-модели, IT-компании] Discord закрыла переговоры: вместо вхождения в состав Microsoft компания выйдет на IPO
- [Управление проектами] Как настроить дашборды в Azure DevOps, чтобы они приносили пользу
- [Информационная безопасность, Сетевые технологии] Концепция периметра безопасности устарела. Но как усложнить жизнь хакерам?
- [Разработка веб-сайтов, Управление проектами, Управление медиа] Google и Ростуризм запустили проект «Раскуси Россию» о русской кухне
- [IT-инфраструктура, Управление проектами, Инженерные системы] Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 4
- [Анализ и проектирование систем, Управление персоналом, Карьера в IT-индустрии, Лайфхаки для гиков] Должен ли системный аналитик вторгаться на чужую территорию?
- [Тестирование IT-систем, Тестирование веб-сервисов, Конференции] Приглашаем на DINS QA EVENING: работа с логами и функциональные возможности инструментов на базе CDP
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_upravlenie_personalom (Управление персоналом), #_upravlenie (управление), #_upravlenie_ljudmi (управление людьми), #_teamlead, #_frontend, #_konflikty (конфликты), #_kollektiv (коллектив), #_komanda_razrabotki (команда разработки), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:36
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Честно сделанные ошибки следует считать не неудачами, а семенами для основной деятельности по их исправлению
Мысли аля "Я могу сделать это лучше" первое время постоянно рядом, из-за этого получается, что вы перегружаете себя и, конечно же, не успеваете. Ведь помимо разработки у вас есть другие не менее важные задачи. Решение данного вопроса очень простое: нужно учиться доверять, оценивать людей не только по их личным, но и по их техническим характеристикам. Тогда будет намного легче. Возможно, вы перестанете быть звездой-гением-мысли-лучшим разработчиком среди всех разработчиков в компании, но вы будете хорошим TL, который умеет самое главное - доверять. От этого вам плюсик в карму от команды. Оценка сроковДругая не менее распространенная ошибка - Ошибка в оценке сроковИногда, на глобальном планировании на несколько спринтов вперед бизнес может сказать "Нам нужно это, это, и вот это - сможешь?". Тут начинается игра "Кто хочет стать Багоделом", потому что чем больше вы возьмете на себя и свою команду, тем больше будет проблем потом. Проблемы будут появляться из-за: 1. Непредвиденных обстоятельств, блокирующих задач других людей или команд 2. Сложности. То, что по заявлением должно делаться N часов - делается 2N часов - отсюда смещение по времени и нарушение дедлайнов 3. Перегруженности команды: в высоком темпе разработчик работать может, но недолго - дальше выгорание и потеря сотрудника. В итоге, получается ситуация, где все можно успеть, но или очень с очень плохим качеством (т.е. техническим долгом), или с убитой командой, или (самый благоприятный исход) - просто не успеть. ПриоритетыЭто особенно важная история в рамках команд, которые работают над несколькими большими задачами в спринте. Принцип прост: сильному разработчику -- более сложная и приоритетная задача. Разработчику послабее -- задача его уровня. Но тут нужно понимать одну вещь, связанную с развитием каждого разработчика отдельно - нельзя вечно держать разработчика на задачах его уровня. Нужно вкидывать хотя бы иногда что-то сложнее и интереснее, ведь разработчик заинтересован в своем развитии. Отсюда появляется следующая ошибкаОтсутствие развития сотрудников в профессиональном плане Вы как TL должны думать не только о том, какие фичи поставляет ваша команда, но и том, как развивать каждого члена команды в отдельности. Ведь все абсолютно разные, у всех свой опыт и свой бэкграунд, а значит каждому нужна своя траектория развития. Вряд ли разработчик будет сидеть на одних и тех же задачах - он потребует больше, интереснее, сложнее. Учитывая это, TL может построить правильную траекторию развития каждого разработчика. Общение с разработчиками Или One-to-One. Лучший способ узнать что происходит у разработчика - прямо спросить. И не обязательно спрашивать "ну что, как там с задачами?". Нужно быть человеком и искренне проявлять интерес к жизни сотрудника. Спросить что-то отвлеченное от работы или обсудить, к примеру, вчерашний футбольный матч - прекрасное начало диалога, который поможет больше понять что беспокоит сотрудника. Если необходимо спросить про трудности с задачами - это стоит делать без претензией, а с искренним желанием помочь. Ошибок, которых я допустил - тысяча. Но скажу одно - даже у ошибок есть польза. Нужно просто уметь получать эту пользу.Конфликты Самое страшное, что может случиться в команде - это конфликт между разработчиками. Что самое забавное, его причины достаточно прозаичны, например - pull request был предвзято оценен или чрезмерно раскритикован. И самое неприятное в конфликте то, что он может быть продолжительным и он может съесть день вашего времени. Решение конфликта кроется в общении: 1. С каждым по-отдельности - разговор one-to-one для поиска причины и оценки ситуации 2. Совместно с конфликтующими - разговор, который направит на нахождение компромисса Это поможет быть: 1. Ближе к команде 2. Справедливее. Вы не занимаете стороны - вы стремитесь к общей идее сплоченной команды Не занимайте стороны, не говорите эмоциями - говорите фактами. Заключение статьиСейчас, спустя несколько месяцев работы TL, я могу с уверенностью сказать, что многие вещи в команде стали лучше. И процессы разработки, и качество кода, и взаимоотношения с командой. И стали они лучше благодаря одной простой вещи - признанию своих ошибок. Проблема производительности команды не кроется в отдельных разработчиках - она кроется в грамотной постановке не только дедлайна и задачи, но и в условиях, в которых разработчики каждый день находятся, в правильной "постановке атмосферы" разработки - надеюсь не перемудрил и вы меня поняли. Если кратко: сделать комфортные условия и увеличить КПД - вот задача тимлида. В следующей статье я расскажу о других наблюдениях, или "очевидных открытиях". А пока спасибо за внимание и до скорых встреч. Жду ваши отзывы и предложения. =========== Источник: habr.com =========== Похожие новости:
Разработка веб-сайтов ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:36
Часовой пояс: UTC + 5