Когда-то давно была статься Что должен делать тимлид: роли, обязанности и навыки. Уж очень мне там схема понравилась по компетенциям. И уж очень разные вещи в компаниях являются основными для team lead-а. Было бы интересно прочитать о том, что наиболее востребовано на вашем месте работы, какие обязянности в приоретете.
Как я понимаю, золотая корона — это как раз и есть велосипед с непонятно какими стандартами, а про100 — проприетарная платформа сбербанка, использует лицензии MasterCard (что тоже не гуд).
ребята занимались процессингом МПС в РФ с середины 80х годов и написали самостоятельно свой процессинг фактически с нуля в 90е годы
А где-то можно посмотреть информацию на этот счет, очень интересно?
При том, что если бы не сделали, то имелся не нулевой шанс, что сейчас ни Visa, ни MasterCard сейчас бы в России не работали.
Да и чего все на ребят накинулись?! Кто-нибуть хотя бы EMVCo спецификации посмотрел, там даже с пол-литрой не разберешься за вменяемое время. Зайдите посмотреть ради интереса, гугл Вам в помощь. А это только малая часть всей системы.
Если уж библиотеку для POS терминала (kernel) писать нужно несколько месяцев, да еще потом сертифицировать неопределенное время, то сколько у них сил ушло, что бы это всё почти с нуля поднять. Причем это реально сейчас работает, многие производители терминалов поддерживают MIR, сертифицируются.
Не знаю как с политической точки зрения, но с человеческой реально круто!
У меня такое чувство, что я потратил своё время читая какую-то хрень. А если конструктивно, то это задача вышестоящего звена (от мидла до гендиректора), определять границы ответственности и отсекать лишние поползновения. Например, сказал мидл джуну так писать, пусть он пишет и не выкабенивается. Поспорили два мидла — пошли к сеньёру или тимлиду. И т.д.
А всякие «обидки» — это из-за плохой огранизации рабочего процесса.
Компании получают концепт, участники получают опыт работы с реальными задачами и возможность зарекомендовать себя — всё честно.
А концепт — это еще не готовое решение, на согласование, доработки, тестирование, интеграцию, сертификацию, внедрение, бумажную волокиту еще куча времени уйдет. Нам как-то дали концепт, который парень запилил за 6 дней, у нас ушло несколько месяцев работы команды на несколько человек, что бы из него сделать приложение для бизнеса. От концепта ничего не осталось, даже название поменялось.
В разных компаниях у тимлидов список задач может сильно варьироваться. Но эту статью, я считаю, можно назвать классическим описанием тимлида.
По поводу контроля. Качество сотрудников сильно разнится (и не всегда у тимлида есть возможность выбирать) поэтому и степень контроля разная. Например, есть джуны, которые и вопрос-то иногда не могут задать. Их нужно контролировать постоянно, вплоть до парного программирования. Но это, по моему мнению, не должна быть работа тимлида напрямую, это должно быть поручено старшим разрабам (обычно мидлам, т.к. сеньёры стоят сильно дорого). Задачи для джунов стоит подбирать более простые и понятные, требующие решения именно «в лоб». Проверить такую задачу легче. Опять же, не все мидлы или сеньеры имеют склонности к преподаванию, и поставить такого человека на контроль, будет фатально для джуна. Мой посыл в том, что если правильно распределять задачи в команде, то затратность на контроль можно снизить.
А где-то можно посмотреть информацию на этот счет, очень интересно?
Да и чего все на ребят накинулись?! Кто-нибуть хотя бы EMVCo спецификации посмотрел, там даже с пол-литрой не разберешься за вменяемое время. Зайдите посмотреть ради интереса, гугл Вам в помощь. А это только малая часть всей системы.
Если уж библиотеку для POS терминала (kernel) писать нужно несколько месяцев, да еще потом сертифицировать неопределенное время, то сколько у них сил ушло, что бы это всё почти с нуля поднять. Причем это реально сейчас работает, многие производители терминалов поддерживают MIR, сертифицируются.
Не знаю как с политической точки зрения, но с человеческой реально круто!
А всякие «обидки» — это из-за плохой огранизации рабочего процесса.
А концепт — это еще не готовое решение, на согласование, доработки, тестирование, интеграцию, сертификацию, внедрение, бумажную волокиту еще куча времени уйдет. Нам как-то дали концепт, который парень запилил за 6 дней, у нас ушло несколько месяцев работы команды на несколько человек, что бы из него сделать приложение для бизнеса. От концепта ничего не осталось, даже название поменялось.
По поводу контроля. Качество сотрудников сильно разнится (и не всегда у тимлида есть возможность выбирать) поэтому и степень контроля разная. Например, есть джуны, которые и вопрос-то иногда не могут задать. Их нужно контролировать постоянно, вплоть до парного программирования. Но это, по моему мнению, не должна быть работа тимлида напрямую, это должно быть поручено старшим разрабам (обычно мидлам, т.к. сеньёры стоят сильно дорого). Задачи для джунов стоит подбирать более простые и понятные, требующие решения именно «в лоб». Проверить такую задачу легче. Опять же, не все мидлы или сеньеры имеют склонности к преподаванию, и поставить такого человека на контроль, будет фатально для джуна. Мой посыл в том, что если правильно распределять задачи в команде, то затратность на контроль можно снизить.