Не понимаю почему разработчик обязательно должен быть интровертом, кажется это устаревшее заблуждение. Ведь если ты интроверт, то дальше мидла тебе будет тяжело подняться, ведь там надо отстаивать точку зрения, аргументировать выбранное решение, больше общаться с коллегами из других команд и т.д.
Ммммм, футбольчик, обожаю футбольчик. Но тут скажу я вам, вы абсолютно не правы - 99% тренеров бывшие футболисты. Молодыми тренерами становятся - когда на раннем этапе карьеры получают тяжелую травму... Но все известные тренеры - они все бывшие футболисты. Отдельные курсы - заканчивают, да, нужна лицензия и чтоб подсказали и показали жизнь с другой стороны экрана.
Это само собой разумеющееся, когда ты переходишь в новую роль (руководитель, тренер), то необходим качественный онбординг и опытный наставник. И тогда больше шанс что ты начнешь правильно действовать в новой роли. Теже футболисты ездят на стажировку в разные клубы, чтоб увидеть и понять - каково это работать с командой, как работает конкретный тренер с командой. Они, будучи футболистами, видели это, но не всегда осознавали почему принималось то или иное решение. А теперь им самим придется принимать эти решения, и нужно научиться анализировать все происходящее со всей командой.
Кстати, я как раз читаю книги по работе с командами - биографии тренеров (Фергюсон, Моуриньо, Клопп). Безумно интересно читать и потом анализировать и попробовать наложить на свою команду... И знаете - кое-что совпадает и можно применять! ⚽️
Позволю себе не согласиться, что ПМ (проджект менеджер) - это симптом плохих процессов. Работал в командах, где ПМ полностью выполнял роль тимлида - к нему ходили на 1-1, он принимал задачи от бизнеса, планировал спринты, увольнял, нанимал и тд.
И если взглянуть ретроспективно на эти команды - не скажешь, что там все плохо. Где-то даже успешно спарвляется с нагрузкой, дает развиваться и т.д.
Опять же все зависит от этапа развития ИТ в целом в компании, ведь в стартапах можно встретить и СТО - который кодит, а в более крупных - там уже и (загадочная для меня) роль скрам-мастера появляется. А почему загадочная - потому что не работал с таким типом должности еще 😊
Где-то в компании есть деврелы, а где-то нету... Аналогично и с тимлидами - где то они есть, а где-то их может и не быть. Где-то техлид - это тот кто отвечает только за свой сервис и его сбои, а где-то именно лидирует команду по тех вопросам и отвечает за стабильность всех сервисов команды.
А можете привести пример как должна выглядеть команда по вашему мнению, прям интересно узнать ваш опыт и видение.
И еще такое ощущение складывается, что на 1-1 просят только повышение ЗП... Хотя 1-1 процеес регулярный и должен проходить с какой-то периодичностью (ежемесячно - ежеквартально). Я был бы в шоке от коллег, если бы на каждом 1-1 у меня (или у тимлида) просили повышение ЗП.
И.... я кажется понял, что вас тригернуло... что я говорю про техлида, затем пишу что "всегда хотел стать тимлидом", но при этом меня позвали стать техлидом. И дальше собственно вроде везде стараюсь использовать слово техлид.
Если кратко, то пригласили специалистов, совместно провели тесты, выяснили что были ограничения по сети и по железу. Еще они подсказали нам какие варианты архитектуры можно сдлеать на видеозвонках. Эти знания мы и применили в итоге.
Но если подробнее - то это отдельная большая история 🤓
Тут больше не про постановку задачи, а про опыт работы с той или иной технологией или знание самого сервиса. Что-т оя знал лучше и поэтому мог решить вопрос за 2 дня, а кто не знает что это - он и гвоорил что 5 дней... и очевидно, чт оесли заадча упадет не мне , то и решение будет больше чем у меня.
По постановке задачи - мы предварительно задачи смотрим до оценки и накидываем вопросы, что нам непонятно и на планирвоание уже приходим более подготовленные. Но от покера в итоге все равно отказались.
Я согласен, что тимлид - больше отвечает за процессы, а техлид за техническую часть, но ничего не мешает немного мешать эти роли и каждой роли что-то заимствовать от другой роли.
Теперь встречные вопросы к вышеуказанным аргументам:
Почему техлид не может решать межличностный конфликт, если он непосредственный участник его? Кажется если это лид, он должен обладать достаточными софтовыми навыками чтоб разруливать такие вопросы, как холивар про табы и пробелы :) Это должно быть одной из его обязанностей в принципе, раз он уже лид.
Почему техлид не может проводить 1-1? На мой взгляд это одна из форм передачи своих навыков коллегам. Например на 1-1 подсветил зоны роста для следующего грейда, выявил потребность коллег, затем собрал всю команду и сделал презентацию, рассказал про технологию/паттерны и тд. Почему нет?
Как тимлид будет развивать команду, если он "психолог", а не технарь? В таком случае он сможет только софты прокачивать, а не харды подтягивать, а это уже однобокое развитие (если так можно выразиться)
Ну не может тимлид забивать на техническую часть, ведь к нему в любом случае будут приходить с вопросами - "не работает сервис", "а тут бага" и т.п. И соответвенно, если таких вопросов много, значит с технической частью что-то не так и надо ее подтягивать, а у него нет компетенций - и что делать? Если честно, я бы такого тимлида, который забивает на техническую часть, уволил бы 😅
Правильно написали, что в разных компаниях все по разному, у каждой компании свои этапы развития и свои процессы, поэтому это и нормально 😎
Пока такой человек проводит собесы или решает конфликты как тим-лид, в то же самое время он теряет техническую экспертизу и наоборот.
Вот тут не понял, разве можно потерять навык, если ты проводишь собесы? Тем более на собесах и софтовые вопросы задаются и технические. И кажется техническую экспертизу сложно потерять, если только не кодить полгода и т.п. Да и чем выше грейд, тем менее кодинга получается (лид, архитектор, лид юнита и тп) - это же очевидно, и при этом их не называют же тимлидами...
Как будто в СССР попал, что это и о чем вообще речь? В начале статьи нет вводной части и не понимаешь про что она и хочется закрыть. Но я осилил :)
Петров испытывает дефицит внимания команды и руководителя, потому что ему не объяснили подробно с какой проблемой он столкнулся
А разве не Петров должен объяснить с какой проблемой он столкнулся? Он ведь меньше выкопал. Представляю "разработчик не выполнил задачу в срок, а руководитель ему рассказывает почему" - фантастика.
Руководитель испытывает дефицит внимания своих руководителей
А это вообще из пальца высосана проблема, у которой нет никаких вводных. Так можно на весь мир быть обиженным что с тобой мало общаются.
Профессионалы не задают много вопросов. Они предлагают решения.
Они предлагают решения, когда знают какую проблему решают. Как видим из рассказа, проблема не описана и чтоб её решить - надо задать вопросы.
Не понимаю почему разработчик обязательно должен быть интровертом, кажется это устаревшее заблуждение. Ведь если ты интроверт, то дальше мидла тебе будет тяжело подняться, ведь там надо отстаивать точку зрения, аргументировать выбранное решение, больше общаться с коллегами из других команд и т.д.
Ммммм, футбольчик, обожаю футбольчик. Но тут скажу я вам, вы абсолютно не правы - 99% тренеров бывшие футболисты. Молодыми тренерами становятся - когда на раннем этапе карьеры получают тяжелую травму... Но все известные тренеры - они все бывшие футболисты. Отдельные курсы - заканчивают, да, нужна лицензия и чтоб подсказали и показали жизнь с другой стороны экрана.
Это само собой разумеющееся, когда ты переходишь в новую роль (руководитель, тренер), то необходим качественный онбординг и опытный наставник. И тогда больше шанс что ты начнешь правильно действовать в новой роли. Теже футболисты ездят на стажировку в разные клубы, чтоб увидеть и понять - каково это работать с командой, как работает конкретный тренер с командой. Они, будучи футболистами, видели это, но не всегда осознавали почему принималось то или иное решение. А теперь им самим придется принимать эти решения, и нужно научиться анализировать все происходящее со всей командой.
Кстати, я как раз читаю книги по работе с командами - биографии тренеров (Фергюсон, Моуриньо, Клопп). Безумно интересно читать и потом анализировать и попробовать наложить на свою команду... И знаете - кое-что совпадает и можно применять! ⚽️
Позволю себе не согласиться, что ПМ (проджект менеджер) - это симптом плохих процессов. Работал в командах, где ПМ полностью выполнял роль тимлида - к нему ходили на 1-1, он принимал задачи от бизнеса, планировал спринты, увольнял, нанимал и тд.
И если взглянуть ретроспективно на эти команды - не скажешь, что там все плохо. Где-то даже успешно спарвляется с нагрузкой, дает развиваться и т.д.
Опять же все зависит от этапа развития ИТ в целом в компании, ведь в стартапах можно встретить и СТО - который кодит, а в более крупных - там уже и (загадочная для меня) роль скрам-мастера появляется. А почему загадочная - потому что не работал с таким типом должности еще 😊
Где-то в компании есть деврелы, а где-то нету... Аналогично и с тимлидами - где то они есть, а где-то их может и не быть. Где-то техлид - это тот кто отвечает только за свой сервис и его сбои, а где-то именно лидирует команду по тех вопросам и отвечает за стабильность всех сервисов команды.
Прям заинтриговали своими рассуждениями... 🤔
А можете привести пример как должна выглядеть команда по вашему мнению, прям интересно узнать ваш опыт и видение.
И еще такое ощущение складывается, что на 1-1 просят только повышение ЗП... Хотя 1-1 процеес регулярный и должен проходить с какой-то периодичностью (ежемесячно - ежеквартально). Я был бы в шоке от коллег, если бы на каждом 1-1 у меня (или у тимлида) просили повышение ЗП.
И.... я кажется понял, что вас тригернуло... что я говорю про техлида, затем пишу что "всегда хотел стать тимлидом", но при этом меня позвали стать техлидом. И дальше собственно вроде везде стараюсь использовать слово техлид.
Если кратко, то пригласили специалистов, совместно провели тесты, выяснили что были ограничения по сети и по железу. Еще они подсказали нам какие варианты архитектуры можно сдлеать на видеозвонках. Эти знания мы и применили в итоге.
Но если подробнее - то это отдельная большая история 🤓
да, с фича лидами работать стало гораздо комфортнее и быстрее, да и меня немного разгружают ⚡
Тут больше не про постановку задачи, а про опыт работы с той или иной технологией или знание самого сервиса. Что-т оя знал лучше и поэтому мог решить вопрос за 2 дня, а кто не знает что это - он и гвоорил что 5 дней... и очевидно, чт оесли заадча упадет не мне , то и решение будет больше чем у меня.
По постановке задачи - мы предварительно задачи смотрим до оценки и накидываем вопросы, что нам непонятно и на планирвоание уже приходим более подготовленные. Но от покера в итоге все равно отказались.
Оу, холивар напрашивается 🤩
Я согласен, что тимлид - больше отвечает за процессы, а техлид за техническую часть, но ничего не мешает немного мешать эти роли и каждой роли что-то заимствовать от другой роли.
Теперь встречные вопросы к вышеуказанным аргументам:
Почему техлид не может решать межличностный конфликт, если он непосредственный участник его? Кажется если это лид, он должен обладать достаточными софтовыми навыками чтоб разруливать такие вопросы, как холивар про табы и пробелы :) Это должно быть одной из его обязанностей в принципе, раз он уже лид.
Почему техлид не может проводить 1-1? На мой взгляд это одна из форм передачи своих навыков коллегам. Например на 1-1 подсветил зоны роста для следующего грейда, выявил потребность коллег, затем собрал всю команду и сделал презентацию, рассказал про технологию/паттерны и тд. Почему нет?
Как тимлид будет развивать команду, если он "психолог", а не технарь? В таком случае он сможет только софты прокачивать, а не харды подтягивать, а это уже однобокое развитие (если так можно выразиться)
Ну не может тимлид забивать на техническую часть, ведь к нему в любом случае будут приходить с вопросами - "не работает сервис", "а тут бага" и т.п. И соответвенно, если таких вопросов много, значит с технической частью что-то не так и надо ее подтягивать, а у него нет компетенций - и что делать? Если честно, я бы такого тимлида, который забивает на техническую часть, уволил бы 😅
Правильно написали, что в разных компаниях все по разному, у каждой компании свои этапы развития и свои процессы, поэтому это и нормально 😎
Вот тут не понял, разве можно потерять навык, если ты проводишь собесы? Тем более на собесах и софтовые вопросы задаются и технические. И кажется техническую экспертизу сложно потерять, если только не кодить полгода и т.п. Да и чем выше грейд, тем менее кодинга получается (лид, архитектор, лид юнита и тп) - это же очевидно, и при этом их не называют же тимлидами...
О, крутой вопрос, прям заставила задуматься! 🤔
🔥🔥🔥 Принимать решения в режиме пожара
Часто они не обдуманы и могут пораждать техдолг, но при этом тушат только текущий пожар.
Юля, спасибо за отзыв! 💚
Как будто в СССР попал, что это и о чем вообще речь? В начале статьи нет вводной части и не понимаешь про что она и хочется закрыть. Но я осилил :)
А разве не Петров должен объяснить с какой проблемой он столкнулся? Он ведь меньше выкопал. Представляю "разработчик не выполнил задачу в срок, а руководитель ему рассказывает почему" - фантастика.
А это вообще из пальца высосана проблема, у которой нет никаких вводных. Так можно на весь мир быть обиженным что с тобой мало общаются.
Они предлагают решения, когда знают какую проблему решают. Как видим из рассказа, проблема не описана и чтоб её решить - надо задать вопросы.