регистрация закрыта(

Ага (

Дорогие друзья, Team Leader meetup'а в этом году больше не будет, т.к. мы решили, что вместо него всем будет интересно сходить на московский YaTalks: https://yandex.ru/promo/events/yatalks-moscow

Этот YaTalks пройдёт 30 ноября и будет полон топовых людей. Например, нас с Андреем, там можно будет найти на главной сцене с 17:00 :) Ну и в любое другое время в кулуарах.
Кроме того, нас теперь можно читать тут: https://t.me/insilicio

https://soundcloud.com/podlodka/podlodka-118-inzhenernaya-kultura     интересный выпуск.   Самый интересный вопрос, который у меня возник - трудозатраты. пусть 4 map reduc'a  стоит поддерживать X ресурсов в месяц, а переход на 1 m.r.  стоит Y.     Чему равно отношение Y / X ?     @ashagraev @AndreyPlakhov что-то можете рассказать на эту тему, коллеги?    Интересно, как проект смогли обосновать.

TLDR: Y ~= 10*X. Это следует из такого рассуждения, от специфики нашей индустрии не особенно зависящего: допустим, у компании есть свободные Y, во что их выгоднее вложить, в улучшение инфраструктуры, которое даст нам X в месяц экономии, или в какой-то новый проект? Давайте просто посмотрим, во что и с какой эффективностью мы их вкладывали раньше, какая там была в среднем отдача. Я не финансист и немного плаваю во всех этих RoI, RoA, RoE, но цифра 10% в год для нашей индустрии похожа на правду, не ужасно ошибочная, во всяком случае :)  Особенно учитывая то, что и Х, и особенно Y мы обычно знаем крайне примерно.

На самом деле обычно переходят на единый стандарт не для того, чтобы сэкономить ресурсы на поддержку, а для того, чтобы улучшить обмен опытом внутри компании и унифицировать тулзы. Другими словами, Х состоит не столько из затрат, явно выраженных в каком-нибудь тасктрекере, сколько из не очень измеримой, но вполне реальной "недополученной синергии", так что Х тоже так себе поддаётся оценке.

👍

#вакансия #teamlead #удаленка

Всем привет!
⭐️ Ищем ТИМЛИДА в нашу команду!

Формат работы: Удаленно
Занятость: Полная
Зарплатная вилка: от 70 000 и до !!! на руки!

Требуемый опыт работы: 3–6 лет. Полная занятость, полный день. Возможна удаленная работа.

ОБЯЗАННОСТИ:
- проработка архитектуры проекта
- декомпозиция задач
- постановка задач разработчикам/тестировщикам/инженерам
- контроль исполнения и качества результата
- оценка сроков
- контроль требований

НАШИ ПОЖЕЛАНИЯ К КАНДИДАТАМ:
- высшее техническое образование
- опыт планирования, постановки задач
- успешный опыт реализации проектов в области автоматизации бизнес процессов
- знание различных методологий разработки
- знание полного цикла разработки продукта
- опыт руководства командой разработки
- знание Bitrix, sql, опыт интеграции с 1С

ЧТО МЫ ПРЕДЛАГАЕМ:
- Удаленная работа, либо офис в Москве/Петрозаводске по вашему выбору
- Официальное трудоустройство
- Возможность командировок в экзотические страны
- Интересные внутренние проекты
- Достойный уровень заработной платы - по договоренности

✅ Откликнуться ➡️ https://clck.ru/JqsUh

:D

Считаю, что тимлиды должны на такое реагировать без насмешек! :)

Накидал пост https://bizzapps.ru/b/raznitsa-mezhdu-programmistami-senior-middle-junior/

Мб обсудим? )
Что можно добавить/поправить?

за что вы не любите мидл разработчиков?

пчм? ))
мидл разработчики - это 80% силы в команде )
сеньоры заняты джунами
джуны толком ничего не могут

одна надежда на мидлов )

тональность речи. Сеньоров вы описываете позитивно, джунов нейтрально, мидлов — негативно, как будто объясняете, почему мидл не сеньор: «не хватает», «плохо прогнозируют», «не готов», «залипают в технологии»

Мой фидбек такой: я хочу думать не о свойствах сотрудника, а о том, какие результаты он может обеспечивать. В тексте очень много про свойства: вот даже senior'ы джунов обучают, но не указано, чего эти джуны под их руководством добиваются.

Такой подход может приводить к тому, что народ формально стремится к каким-то процессам и свойствам (типа на конфы ездить и c++ учить), а результаты при этом не растут. И это вредно для бизнеса и команды, а еще это вредно для человека, т.к. он в своем развитии должен прежде всего учиться достигать большего, а уж какими именно инструментами - это вторично.

> я хочу думать не о свойствах сотрудника, а о том, какие результаты он может обеспечивать.

у сеньора первый пункт - уметь достигать результата по крупным задачам (проекты, Epic, OKR).
1. крупные задачи в разных командах зовутся по разному
2. они не только зовутся по разному, но они еще и разные от команды к команде. в микросервисе это шардинг БД на 3 сервера сделать, а в контентном проекте это притащить +200% трафа через смарт фильтр.
3. крупные задачи не только разные по названию и содержанию от команды к команде, но даже внутри 1 команды сегодня они одни, а завтра другие.
4. но общая черта одна - это крупные задачи и сеньор должен уметь решать крупные задачи.

Можно эту же мысль выразить иначе: Описание того, какие результаты он может обеспечивать это тоже свойство 🙂

Птм не получится хотеть не думать о свойствах )

Другой вопрос что есть свойства важные и не важные:
- доводить до результата крупные задачи - это важно
- знать C++ и иметь сертификаты - да пофиг

Плюс-минус нормально описал.  В том, что middle определяется через отрицание, я не вижу ничего негативного. Очень математично :)

единственное что: T-Shape - не догма. Ну что не бывает Синьоров, которые кроме С++ ничего не знают? Да бывают.  Прогнозировать риски, приоритеты - это задача тимлидов больше, а не синьоров. Разве что, если в команде несколько стадий декомпозиции задач, то да.