Что актуально для руководителей в IT в 2026?

@sokolviktory, так не глубоко шарить, а представление иметь. Понимать, о чем говорит бизнес, иметь общий контекст, знать блин цели компании. Там не рокет саенс же. И, кстати, кажется, что в век ИИ и ценности контекста это даже ещё важнее.

Это в обе стороны работает. Тот же менеджер, говорящий фразу «ой, ну это техническое, я даже думать об этом не буду, код какой-то, пффф, сделайте хорошо, вы тут разработчики» — ну, как бы сказать, удивит окружающих. :)

Чтобы коммуникации шли быстро, и все работало хорошо, на стыке людей должны быть чуть перекрывающиеся компетенции, как кружочки наложить чуть-чуть друг на друга. А если кружочки компетенций не накладываются, а даже не соприкасаются, по моему опыту, всё грустнеет.

@sokolviktory, добавлю свои наблюдения из работы

• в стартапах без такого разделения на технических и функциональных спецов
• в корпорациях с бизнес аналитиками не шарящими в технической части и командами разработки не понимающими чем вообще бизнес занимается.

Во втором случае принятые решения очень часто крайне слабые и непродуктивные из-за потерь в коммуникации. У меня прям очень много примеров взрыва скоупа из-за этого. Например,
аналитик пишет в требованиях какую нибудь маленькую и не существенную с его точки зрения деталь, допустим риалтайм апдейт данных на фронте. разработка не челленджит и с радостью тащит SignalR в проект, где просто можно обновлять фронт по таймеру. на выходе задача занимает три недели вместо 3 дней.

@auvoronov, не очень хочу рассматривать стартапы, потому что они обычно маленькие — там легко понять, почему ты и чтец и жнец, и на дуде игрец. Но и продукты у них, обычно, поменьше, чем у корпорации.

А вот как так получилось, что у вас были не компетентные бизнес-аналитики в корпорации — загадка. Вообще, свою карьеру я начинала с бизнес/системной аналитики, и там сильный технический бекграунд считался вполне себе must have. 🤷‍♀️

Так если проблема в некомпетентных людях на конкретной должности, почему их работу нужно переложить на других, а не решить саму проблему?

@Sveta, к сожалению, я не могу согласиться, что знать цели компании — это не рокет саенс.
Хм… заработать как можно больше денег? Занять самый большой кусок рынка?
Это, наверняка, правдивые цели и для вашей и для моей компании; но не уверена, что это как-то продвигает нас в дискуссии.

Да и что касается технической подготовки менеджеров. Да, я с вами согласна, хотелось бы, чтобы разбирались.
На практике, не разбираются и не признаются в этом. 🤦🏼‍♀️

@sokolviktory, ну так в ситуации, где техническая команда не знает цели бизнеса, а менеджеры совсем не шарят — ровно та ситуация, о которой я пишу. Обеим сторонам не хватает компетенций, кружочки не соприкасаются даже. :) На стыке возникают зоны, где все некомпетентны, вуаля, всё плохо.

И нет, я не соглашусь, что у наших компаний одинаковые цели. :) Какие-то могут совпадать, но большая часть точно будут различаться. Конечно, можно забить, и не разбираться в том, что напрямую не касается, и вроде и не обязан, но тогда мы возвращаемся в мир кружочков, каждый из которых сам по себе.

@urtow, в хороших компаниях я такого не видела, а в плохих не надо работать. :)
Ну серьезно, зачем работать там, где тебя считают слишком умным? :)

@Sveta, Ну вот туда и не берут работать, это вторая проблема 😅

@urtow, ахахаха) Пущай возьмут в самую замечательную компанию на много денег и интересные задачи в этом году!

@Snk, долго, сложно, страшно. :)
В общем, мне кажется, единицы на такое решаются.

@Sveta, Я когда-то с этого начинал, по-другому уже не представляю.

А так да, даже самые умные технически товарищи нужды бизнеса представляют в очень извращенном виде.
Самое обидное что они почему-то считают, что представляют. :)

Я лет десять назад ходил по воркшопам техлидов и ПМ-ов и рассказывал им базовые финансы компании.
Народ на этом потом здорово взлетел, кто хоть чуть-чуть слушал.

@Snk, ага, от привычки считать себя самым умным тяжко отказываться. :)
Ну и да, вот таких воркшопов бы, про финансы, про клиентов, эх!

@Sveta, я уже давно не веду вне джунов на своих проектах.
Коммерческий смысл рассказывать наружу имеет только если совсем сидишь на мели.
Все считают что они умные, просто клиенты их ума не понимают, и это клиентов нужно учить. :)

@NotYetBenGan, попробую ответить.

Prework: разобраться в базе (мне лучше всего помогает чтение, поэтому AI Engineering by by Chip Huyen) и попрактиковаться в AI-assisted engineering, workflow automation, agents, etc. Это занимает буквально несколько часов на каждое из упражнений.

Ну а дальше стандартный management playbook - написать AI adoption strategy: выбрать 1-2 цели и провалидировать их с бизнесом, задать стартовый темп и выбрать несколько экспериментов. Через 3-6 месяцев измерить результаты (на этом этапе достаточно очень базовой метрики вроде tooling adoption) и, если все приемлемо, запускать вторую волну экспериментов с уже более четкими outcomes.

Главное не бездумно пытаться строить из себя 0,1% бигтех и помнить по productivity J-curve.

Отдельно можно поговорить про то, как это все оформить в красивый кейс для финансов (весь этот тулинг стоит деняг), но мой комментарий итак уже получается сильно длиннм.

@yeharetski, спасибо за ответ и рекомендацию книжки :)

@oayunin, так вышло что тимлиды любят брать таски себе, где надо быстро покодить что то, но иногда из за нехватки времени или просто усталости в казалось бы простой задаче можно сделать баги
И хуже всего когда баги вызывают инцидент, а ужасно когда на инцидент вызывают другие команды

Ну коротко
Просто объяснять, что если таска не влияет на ключевые результаты, то нельзя делать самому

@p4nuta, а, теперь понял, полностью согласен. меня запутала фраза "сделать техдолг" - я прочел как "исправить", а у тебя употреблено в значении "создать"