Подтемы
Транскрипт
Загрузка транскрипта…
Ничего не найдено.
Разговор начали с открытого вопроса про работу на западных рынках. Вывод Андрея: чтобы работать на локальном рынке страны (Франция), недостаточно английского – нужен язык делового общения той страны, где живёшь; английского хватает только на международном рынке. При этом локальные рынки структурно напоминают СНГ: те же жалобы на «дураков-коллег и начальников-чайников». Разработку почти никто не отдаёт на аутсорс внутри страны – все хотят штат; подрядные модели держатся в основном вокруг администрирования и системной интеграции.
Центральная ось спора. Уалихан: обучение и развитие – инициатива и ответственность самого сотрудника, а не обязанность компании; «спасение утопающих – дело рук самих утопающих», компания должна лишь соблюдать социальный контракт. Михаил и Андрей: для узкого прикладного IT это рабочая бизнес-модель, но если хочешь большего – без вложений в обучение не обойтись. Отдельный аргумент от инфляции: чтобы удерживать людей и не терять их к конкурентам, нужно повышать выработку, а значит – квалификацию; «чтобы стоять на месте, надо быстро бежать».
Провокация Уалихана: там, где нет жёстких технических критериев (проектный/продуктовый менеджер, скрам-мастер), можно брать любого «адекватного» человека, потому что специализацию всё равно не свалидируешь. Контртезис: если разработчику достаточно «дать инструмент» (LLM), почему тогда и разработчика нельзя взять «с улицы»? Михаил защитил роль PM через PMI/PMBOK: расписание, риски и закупки можно делегировать, но интеграция всех видов деятельности в результат остаётся за руководителем проекта; PM – это «трикстер» и агент изменений. Проблема в том, что грейдирования и внятного описания роли PM почти нигде нет – «учат плавать, выбросив на середину озера».
Скепсис к индустрии, которая «ведётся на моду» и переназывает старые роли (DevOps, SRE, PaaS – это переименованные роли в команде). «Красную книгу» Сазерленда про Scrum назвали вредной: она создаёт «атмосферу успешного успеха», хотя Scrum нужен далеко не везде. Из-за этого роль скрам-мастера часто вырождается в администратора команды, тогда как настоящему мастеру нужен матёрый человек, решающий «экзистенциальные вопросы существования команды», а не двигающий стикеры. Плохие «скрамы» – это просто плохие планёрки по часу.
Проблема грейдирования в компании с разнородными продуктами: единая линейка может публично понизить человека (был сеньором – стал «слабым мидлом»), и он уходит. Рабочий приём – числовые грейды (L1/L2/L3), развязанные с ярлыками «сеньор/мидл» и привязанные к потолку ценности проекта; для уникальных талантов создают отдельные позиции. Грейдирование – это в первую очередь страховка взаимозаменяемости (проверка на бас-фактор): «любая бизнес-трансформация – это кровь», часть людей неизбежно уходит, и это ожидаемо.
Ответ на давний вопрос из бэклога. Корреляция между Story Points и реальным временем выполнения – минимальная: проверяли и в игровой ситуации, и на реальных данных из Jira. Технически посчитать легко (выгрузка из Jira → корреляция → график), но главный вопрос – зачем: людям просто «хочется чувствовать власть над временем».
Живой кейс: твой тимлид/руководитель менее компетентен в софт-скиллах – что делать. Артур предложил путь «серого кардинала»: стать для него авторитетом и мягко манипулировать, продавливая удобные тебе решения (открыто назвав это «тёмной триадой»). Андрей возразил, что предпочитает прямое, прозрачное влияние без манипуляций и построения политических клик – иначе сам будешь параноить, что тебя хотят подсидеть. Отдельный красный флаг: когда при найме тебя даже не знакомят с прямым руководителем.
Самая долгая дискуссия. Молодой стартап (запуск в январе 2026, команда из шести человек) бежит закрывать каждую клиентскую интеграцию (LDAPS, Teams, YouTrack, кастомные трекеры), потому что «мы на ранней стадии и цепляемся за каждого клиента». Андрей раскритиковал это как «беличье колесо»: продажи перегружают производство, компания субсидирует интеграции из своего кармана, и вместо найма джунов «для снятия рисков» стоило бы поднимать цены, лучше продавать и приоритизировать по 20/80. Контекст к джунам: на зрелом проекте (2,5–3 года) джун «не вывозит» из-за доменной сложности, а на greenfield – вполне. Отдельно разобрали «клиентократию» (пример JetBrains) – когда «нет запроса – не делаем», и продукт зарастает шероховатостями.
| Вопрос | Андрей | Уалихан | Михаил | Артур |
|---|---|---|---|---|
| Чья ответственность – развитие и обучение джунов? | Для узкого прикладного IT ок, но для роста надо вкладываться в обучение | Инициатива и ответственность самого сотрудника – компания ничего не должна | Инфляция давит на выработку – без роста квалификации не выжить | – |
| Можно ли брать «адекватных с улицы» на нетехнические роли? | – | Да, где нет жёстких техкритериев (PM, PdM, скрам-мастер) | У роли PM есть системные требования (PMI/PMBOK), но грейдов почти нет | – |
| Как влиять на менее компетентного руководителя? | Прямое, прозрачное влияние без манипуляций | – | – | Стать «серым кардиналом» и мягко манипулировать под свои условия |
| Клиенто-ориентированная гонка за фичами – это норма? | «Беличье колесо» – надо поднимать цены и приоритизировать 20/80 | На ранней стадии цепляешься за каждого клиента, фичи переиспользуются | – | – |
Модель «сотрудник учится сам» работает для узкого прикладного IT, но инфляция и потребность в росте выработки рано или поздно заставляют вкладываться в квалификацию. Вопрос не «должна ли компания», а «какой у неё горизонт».
Там, где нельзя строго свалидировать навык (PM, скрам-мастер), легко скатиться к найму «адекватных с улицы» и получить администратора вместо агента изменений. Ценность PM/скрам-мастера – в интеграции и решении экзистенциальных вопросов команды, а не в ведении тикетов.
Числовые грейды (L1/L2/L3), развязанные с ярлыками и привязанные к ценности проекта, повышают взаимозаменяемость; уход людей – в том числе проверка систем на взаимозаменяемость. Но для уникальных талантов нужны отдельные позиции, иначе нормализация их выталкивает.
Проверено и в игре, и на реальных данных Jira: корреляция минимальная. Стремление привязать SP к часам – это желание «власти над временем», а не рабочий инструмент оценки.
На ранней стадии цепляться за клиентов нормально, но когда продажи систематически перегружают производство и компания субсидирует интеграции из своего кармана, лечится это не наймом джунов «для снятия рисков», а ценой, приоритизацией 20/80 и продажей «на равных».
Хотите обсудить эти темы с практикующими тимлидами?
Обсудить в Telegram