Ну ладно, пусть человек порадуется, это иногда полезно - поверить в себя. Мне тоже казалось, что безумно круто быть тим-лидом в 21 и я искренне не понимал, почему тот великовозрастный разработчик с улыбкой отказывается, когда ему предлагают менеджерскую роль. Зрелось - очень важный показатель, зрелый разработчик может не знать каких-то новомодных фреймворков или глубоких нюансов, но он может принять правильное, неочевидное решение и это очень ценно.
За весь огромный Тинькофф не берусь говорить, и не знаю правда ли это, что кто-то «сбежал» из Тинькофф :)
Но могу сказать точно, что за последние 2 года менеджерский состав сильно окреп, как и HR отдел.
Пришли клевые специалисты из других компаний и также выросло много руководителей из «старичков».
Я также как Юля Царева работаю в Тинькофф Бизнес и мой опыт очень похож на то, что она рассказала в статье выше. Оглядываясь назад я вижу огромные достижения и рост — 4 года назад нас было 20-30 человек в ТБ, сейчас 200+.
Сам я пришел зеленым фронтендером из степей Казахстана, сейчас руковожу отделом разработки кредитных продуктов. Не знаю, удалось бы мне вырасти так быстро в другом месте :)
Приведенные вами цитаты достаточно старые, это личное мнение Олега, каждый имеет право на высказывание своих мыслей :)
Да и действительно, за последнее время в Тинькофф очень многое поменялось. Компания выросла в разы и по результатам и по сотрудникам, да и Олега последние 2 года почти не видно в офисе, хотя иногда хотелось бы видеть.
Этого не сливают в интернет, но Олег не только ругает, но и хвалит. Например года 2 назад он нам пообещал море шампанского, если запустим проект валютных платежей вовремя и обещание свое сдержал :)
Спасибо, хорошее разъяснение. Основная задача тимлида — сделать так, чтобы команда работала эффективно и ее члены были счастливы. Для решения этих задач более важны навыки работы с людьми и понимание процессов разработки.
Занятно, что некоторые комментаторы напрочь забыли про суть статьи и бросились обсуждать совершенно другую тему :)
У нас есть разные подходы к орг. структуре.
По-большей части да, тимлиды имеют бэкграунд разработки.
Но мы также практикует структуру — тимлид не разработчик + техлид(ы).
Все зависит от задач и размера команды.
Не берусь судить, я не юрист.
Обычно это соглашения на уровне корпоративной культуры и не фиксируются в трудовом договоре.
Для меня это правильно с точки зрения этики. Как-то странно ходить и мериться уровнем дохода. Естественно, если эта информация необходима, например, для принятия решений, то нет проблем ей поделиться.
Боюсь вы делаете неправильные выводы. Про то, что ФОТ фиксированный я не говорил. «Подгонять» под ФОТ означает немного другое.
У меня недостаточно информации, чтобы говорить наверняка как все работает целиком, вся изложенная информация — это лишь мои наблюдения.
В любом случае, я не думаю, что это работает так просто как выговорите, с учетом того, что штат насчитывает тысячи сотрудников. В таких условиях хочешь-не-хочешь, нужно придумывать общие правила.
Судя по резкому негативному тону у вас был плохой опыт по работе с ФОТ? Если так, то поделитесь пожалуйста, как это работало у вас?
Новшества никакого нет на самом деле :)
Важно заметить, что у нас есть команды которые замечательно живут со сторипоинтами (чтобы не думали, что мы повсеместно мигрируем с них на due date).
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы.
На самом деле нет, нагрузка не увеличилась. У разработчиков и до этого были мнения и оценки по трудозатратности задач, но их просто не учитывали. Теперь флоу идет централизованно в следующем виде:
1. Заказчик приходит с задачей к лиду
2. Лид просит кого-нибудь из разработчиков провести архитектуру задачи. Если нужно, то собирает брейншторминг с командой.
3. На основе оценок от разработчиков лид прикидывает сроки, учитывая при этом рабочие дни, отпуска, техдолг и т.д.
Ну и самое важное, что нужно было сказать в начале: due date — это не не твердое обещание, это дедлайн в который мы стремимся уложиться. За исключением дедлайнов по задачам где сроки обусловлены законами и т.д.
Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
Джун у нас в команде всего один, так что тут нет проблем :) Разработкой я вполне успевал заниматься, не было с этим проблем.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Переработок наоборот стало меньше (на мой взгляд), за счет того, что мнение разработчиков стали учитывать при оценке сроков. Сроки были раньше и есть сейчас, они никуда не исчезли. Появилось только сопротивление от команды разработки, которое двигает оценку к более приближенному к реальности значению.
Итого: более точные сроки появились из-за бОльшей вовлеченности команды в эту задачу и из-за бОльшей ответственности со стороны команды.
Я вроде и не утверждал, что это Oauth единственный протокол авторизации.
По X-MSISDN ничего толкового не нагуглил (выдает, что в этом хидере пердается номер телефона), может подскажете документацию? Стало интересно.
Посмотрите пожалуйста любую реализацию авторизации в веб-сервисах, например OAuth 2.0.
Почему нет смысла отправлять хэш на сервер вам сразу же объяснили и минусы по делу влепили :)
Ну ладно, пусть человек порадуется, это иногда полезно - поверить в себя.
Мне тоже казалось, что безумно круто быть тим-лидом в 21 и я искренне не понимал, почему тот великовозрастный разработчик с улыбкой отказывается, когда ему предлагают менеджерскую роль.
Зрелось - очень важный показатель, зрелый разработчик может не знать каких-то новомодных фреймворков или глубоких нюансов, но он может принять правильное, неочевидное решение и это очень ценно.
Статья очень даже кстати.
Многие до сих пор не знают.
Конкретного, но не каждого.
Не могут все быть успешными, а хотелось бы.
Тинькофф Бизнес я имел ввиду, но да ладно :)
Но могу сказать точно, что за последние 2 года менеджерский состав сильно окреп, как и HR отдел.
Пришли клевые специалисты из других компаний и также выросло много руководителей из «старичков».
Я также как Юля Царева работаю в Тинькофф Бизнес и мой опыт очень похож на то, что она рассказала в статье выше. Оглядываясь назад я вижу огромные достижения и рост — 4 года назад нас было 20-30 человек в ТБ, сейчас 200+.
Сам я пришел зеленым фронтендером из степей Казахстана, сейчас руковожу отделом разработки кредитных продуктов. Не знаю, удалось бы мне вырасти так быстро в другом месте :)
Да и действительно, за последнее время в Тинькофф очень многое поменялось. Компания выросла в разы и по результатам и по сотрудникам, да и Олега последние 2 года почти не видно в офисе, хотя иногда хотелось бы видеть.
Этого не сливают в интернет, но Олег не только ругает, но и хвалит. Например года 2 назад он нам пообещал море шампанского, если запустим проект валютных платежей вовремя и обещание свое сдержал :)
Занятно, что некоторые комментаторы напрочь забыли про суть статьи и бросились обсуждать совершенно другую тему :)
Кому должен? Как я писал выше — да, зачастую, но не всегда. Тимлид (пиплменеджер) + техлид тоже хорошо работает.
По-большей части да, тимлиды имеют бэкграунд разработки.
Но мы также практикует структуру — тимлид не разработчик + техлид(ы).
Все зависит от задач и размера команды.
Обычно это соглашения на уровне корпоративной культуры и не фиксируются в трудовом договоре.
Для меня это правильно с точки зрения этики. Как-то странно ходить и мериться уровнем дохода. Естественно, если эта информация необходима, например, для принятия решений, то нет проблем ей поделиться.
У меня недостаточно информации, чтобы говорить наверняка как все работает целиком, вся изложенная информация — это лишь мои наблюдения.
В любом случае, я не думаю, что это работает так просто как выговорите, с учетом того, что штат насчитывает тысячи сотрудников. В таких условиях хочешь-не-хочешь, нужно придумывать общие правила.
Судя по резкому негативному тону у вас был плохой опыт по работе с ФОТ? Если так, то поделитесь пожалуйста, как это работало у вас?
Изначально она была такой:
Важно заметить, что у нас есть команды которые замечательно живут со сторипоинтами (чтобы не думали, что мы повсеместно мигрируем с них на due date).
На самом деле нет, нагрузка не увеличилась. У разработчиков и до этого были мнения и оценки по трудозатратности задач, но их просто не учитывали. Теперь флоу идет централизованно в следующем виде:
1. Заказчик приходит с задачей к лиду
2. Лид просит кого-нибудь из разработчиков провести архитектуру задачи. Если нужно, то собирает брейншторминг с командой.
3. На основе оценок от разработчиков лид прикидывает сроки, учитывая при этом рабочие дни, отпуска, техдолг и т.д.
Ну и самое важное, что нужно было сказать в начале: due date — это не не твердое обещание, это дедлайн в который мы стремимся уложиться. За исключением дедлайнов по задачам где сроки обусловлены законами и т.д.
Джун у нас в команде всего один, так что тут нет проблем :) Разработкой я вполне успевал заниматься, не было с этим проблем.
Переработок наоборот стало меньше (на мой взгляд), за счет того, что мнение разработчиков стали учитывать при оценке сроков. Сроки были раньше и есть сейчас, они никуда не исчезли. Появилось только сопротивление от команды разработки, которое двигает оценку к более приближенному к реальности значению.
Итого: более точные сроки появились из-за бОльшей вовлеченности команды в эту задачу и из-за бОльшей ответственности со стороны команды.
Я что-то не понял, так это авторизация или смена пароля?
По X-MSISDN ничего толкового не нагуглил (выдает, что в этом хидере пердается номер телефона), может подскажете документацию? Стало интересно.
Почему нет смысла отправлять хэш на сервер вам сразу же объяснили и минусы по делу влепили :)