Артем, спасибо за взвешенный комментарий. Вы правы: IT - это не монолит и подходы зависят от специализации. Хороший COO как раз и должен это понимать🙂, чтобы не лезть со своим "универсальным рецептом" туда, где он не работает.

Мой вопрос как раз про это: я не прошу "возьмите меня без знаний", я спрашиваю - готовы ли IT компании рассмотреть управленца с опытом работы и масштабирования в других отраслях, если он готов глубоко погрузиться в вашу специфику?

Специфику - можно выучить. Вопросы - задам точные. Результат - однозначно принесу. Вопрос только в том, готов ли бизнес к такому формату диалога.🙂

Потому что исходя из того, что я наблюдаю в IT компаниях, что слышу от тех же сотрудников работающих там и видя качество различных продуктов, которое неумолимо падает быстрее, чем должно. Я вижу что в IT уж очень не хватает более жесткого контроля и взгляда человека со стороны.

Вы видите это со своей стороны как человека вне ИТ. Собственно это и останавливает рассмотрение вас как кандидатуры. Вы банально не в теме, как любит говорить наш коммерческий.

К примеру - жесткий контроль. Жесткий контроль по отношению к чему? К команде разработки? Так при закрутке гаек сеньоры и мидлы вас на три буквы пошлют и уйдут к конкуренту. Спрос на таких спецов колоссальный. А джуны и даром не нужны, с ними только геморроя много. Это касается и сроков и результата. Многие сейчас вымотаны, потому что пашут без отпуска нормального годами, особенно в заказной разработке. В продуктовой чуть полегче, но тоже давление немалое, в основном из за вайбкодеров с их недофичами за чашку кофе. Все это можно понять только находясь в этой сфере, понимая тенденции и суть современных изменений. Здесь не контроль нужен, здесь оптимизация и балансировка нужна. Причем для каждой специализации и каждой ниши своя.

Даже я, варясь в ИТ сфере больше 10 лет и имея собственную ИТ компанию, понимаю, что некоторые вещи у соседей по цеху, например госконтрактников, даже для меня темный лес. Хотя я занимаюсь автоматизацией разных бизнесов и успел насмотреться на разные компании, разные подходы к организации работы.

Артем, спасибо за честность. Вы правы в одном: сеньорам и мидлам нельзя "закручивать гайки" - они могут уйти. Я это прекрасно понимаю.

Только вы путаете почему то контроль с микроменеджментом.

Контроль - это когда есть прозрачные метрики, понятные критерии качества и сроков. Когда команда сама видит, где проседает, и сама исправляет. Это не давление, это система.

А "оптимизация и балансировка" без системы - это просто анархия, прикрытая красивыми словами.

И да, я не в IT. Но я умею довольно хорошо строить системы, где сеньоры не убегают, а так называемые джуны могут расти. А вы?

Ну раз умеете - сделайте свою) и мучиться не придется с поиском работы у других. Это кстати будет лучшим вашим показателем в резюме.

Давайте Артем тогда по порядку.

Вы сами только что подтвердили мой тезис. 10 лет в IT, своя компания и даже вы не понимаете, как работают соседи по цеху. Значит, "быть в теме" - может все таки это иллюзия? Даже у "своих" она не гарантирует понимания всей отрасли.

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

Я к этому и веду. 😊

Теперь по поводу своего.

Артем, обычно когда аргументы заканчиваются, начинаются советы "сделайте свою". Это понятно. 😊

Но дело то в том, что у меня был свой бизнес. Сделал, масштабировал, продал. Теперь я выбираю, где применить опыт дальше. И да, к счастью, теперь я могу позволить себе выбирать компании, а не они меня.

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

Так потому и говорю - весь ваш опыт слабо поможет в специфике конкретного бизнеса без погружения. А без погружения в тему вам никто компанию не доверит. Здесь это ключевой фактор - вам не доверяют. Пообщавшись с вами сейчас, я также для себя убедился, что я свою компанию вам не доверю.

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

Артем, вы имеете полное право не доверять. Это ваш выбор. 😊 Но давайте честно: вы почему то сделали вывод о моей способности управлять компанией на основе всего лишь нескольких сообщений в соцсети. Это говорит больше о вас, чем обо мне.

Тут уже после таких заявлений, скорее я бы не пошел к вам в компанию, так как вижу в вас неспособность видеть элементарные вещи и делать слишком поспешные выводы... 😊 А насчёт "сделайте свою" - как сказал ранее я уже сделал. Масштабировал. Продал. Сейчас я выбираю, на что потратить следующую главу моей жизни. Если это будет не IT - значит, не IT. Всё просто.

Удачи в ваших проектах. Настоящих управленцев, которые умеют видеть систему за терминами, вы, возможно, ещё встретите. 😉

Вот буквально лучший коммент и формулировка, которую я увидел под моим постом. Спасибо!

«Управление абстракциями над исполнителями - и неважно, мебель это или ПО» - именно это я пытался донести. Жаль, не все готовы услышать и еще меньше это понимают.

Рад, что среди тех, кто реально пилит код, есть такое понимание. Это даёт надежду на адекватный диалог между бизнесом и разработкой.🙂

Прямо вот порадовали на ночь глядя, уже и не ожидал что то подобное увидеть.

Дмитрий, отличный вопрос. Риск есть всегда, даже когда нанимаешь «своего». Главное - что на другой чаше весов.

Мой опыт - это не знание кода, а понимание законов роста: как из хаоса сделать систему, как выстроить процессы так, чтобы команда не выгорала и компания не теряла сильнейших специалистов, а бизнес мог масштабироваться. В IT те же проблемы, что и в e-com или производстве: войны отделов, раздутые сроки, отсутствие прозрачности и понимания, что и для чего делается.

Я прихожу не учить разработчиков писать код, а строить операционную модель, в которой они смогут работать максимально эффективно. Это снижает риски гораздо больше, чем создаёт отсутствие отраслевого опыта.

А погрузиться в новую отрасль - это всего лишь вопрос времени. IT тем и хорош, что здесь можно быстро въехать, если есть голова на плечах.

А. Всё понятно. Разработчики по умолчанию умеют в конфлюенс, джира, ci/cd.Вы какую то свою операционню модель видите?

Дмитрий, вы сейчас описали наличие инструментов. А я говорю про операционную модель.

Конфлюенс, джира, CI/CD - это круто. Но это просто софт. Как токарный станок. Сам по себе станок детали не точит, даже если он будет с ЧПУ.

Вопросы, на которые у вас, судя по всему, нет ответов:

· Почему задачи, оценённые в 2 часа, делаются 2 недели? · Почему бизнес и разработка ненавидят друг друга? · Почему приоритеты меняются быстрее, чем версии в CI/CD? · Почему команда выгорает, а сроки горят?

Вот это - операционные проблемы. И джира их не решает. CI/CD их не видит. Конфлюенс в них не поможет.

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

А инструменты… Инструментам я тоже могу научить, если надо. Но сначала надо разбираться с хаосом, который кто то наворотил.

Простой вопрос, как к специалисту: что должен сделать техлид/тимлид/команда разработки, если product owner недоступен, а его мнение нужно для принятия решения?

Конечно же, ответ на этот вопрос, возможно, покажет компетенцию.

Дмитрий, вопрос действительно хороший. Только вот он не про разработку, а про системный сбой.

Если product owner регулярно недоступен, когда нужно решение, - это значит, процессы в компании выстроены буквально через жопу. У здоровой команды есть:

1. Чёткие критерии, какие решения может принимать техлид самостоятельно 2. Имеется заместитель или ответственный на случай отсутствия PO 3. Понятная эскалация, если вопрос критический

Если всего этого нет, то вопрос не «что делать команде», а «почему руководители допустили такую ситуацию».

Лично я как COO выстроил бы систему, в которой PO всегда доступен, когда нужен, а если недоступен, то есть понятный алгоритм действий без авралов и шаманства.

А команда в это время просто делает свою работу.

Вы не сможете построить операционку если не умеете оценивать задачи самостоятельно. Ну скажет вам разраб что задача на неделю - вы как это проверите?

Чтобы подружить стейкхолдеров (бизнес) и разработку опять же надо уметь задачи и приоритеты по ним переводить в цифры для бизнеса и в понятные оцениваемые требования для команды.

Что касается 2х часов и 2х недель - тут тоже варианты не попали в оценку потому что бизнес напихал уточнения требований или разраб переоценил себя (ну тут только джун так может).

В общем чтобы зайти эффективно, а не «эффективно» как чаще всего бывает, надо пару тройку лет самому покодить, познать всю боль войн бизнеса и разработки и потом заходить на операционку.

На истину в последней инстанции не претендую, но опыт и разработки и управления командами есть 🙂

Наталья, спасибо за развёрнутое мнение. Ценю ваш опыт и разработки, и управления.

Но позволю не согласиться с главным тезисом. Вы говорите: чтобы управлять разработкой, надо уметь оценивать задачи. А я говорю: руководитель оценивает не задачи, а тех, кто их оценивает. Если я не умею жарить яичницу, это не мешает мне понять, что повар пережарил её за 40 минут там, где нужно 5. Потому что у меня есть часы, здравый смысл и понимание, что такое «вкусно» от заказчика. В разработке то же самое. Мне не нужно знать, как писать код, чтобы видеть: - Почему задача на 2 часа делается 2 недели - Почему бизнес и разработка ненавидят друг друга - Почему приоритеты меняются быстрее, чем спринты

Опять же, это вопросы не про код. Это вопросы про систему управления. А систему не видят те, кто внутри неё варятся годами. Вы говорите про «пару тройку лет покодить». А я скажу так: лучшие операционщики, которых я знаю, зачастую никогда не работали по своим правилам в которых они реально знали многое. Они просто понимали, что разработка - это такое же, как и любое другое. Там те же законы: ресурсы, сроки, качество, коммуникации. И да, задачи надо уметь оценивать. Но не самому, а через тех, кто это делает профессионально. И если команда говорит «неделя», а ты видишь, что неделю назад такое же делали за 2 дня, то ты задаёшь вопросы. Без погружения в код.

Так что, с вашего позволения, я продолжил бы строить операционку в IT, не написав ни строчки кода. И скажу честно, что буду делать это лучше многих, кто 10 лет просидел в спринтах, но так и не научился видеть систему за тикетами. 😊

Роман, у тебя датасет старый. Учи матчасть, читай скрам, хотя бы основу будешь знать.

Дмитрий, скрам я как-нибудь осилю, при необходимости. Спасибо за заботу. 😊

Только вот в скраме чётко написано: Product Owner должен быть доступен команде. Если он недоступен - это нарушение самого фреймворка.

Так что вопрос не ко мне, а к вашей команде: почему вы допускаете, чтобы PO пропадал, и при этом называете это скрамом?

Учите не меня, учите своих. 😉

Сейчас пока курил, специально тест открыл, сделал скрин-дарю. На вопрос, заданный мной, ты ответил неверно, а сам вопрос взят из официальных сертификационных тестов скрам pspo, поэтому сообщи свое экспертное мнение туда, где ему самое место-на сайт scrum.org и объясни им их ошибку. Они всегда рады учитывать компетентное мнение. Помоги сообществу)

Ок, вы про уровень выше. Тогда у меня есть парочку вопрсов к вам в другом сильно наболевшем ключе) Вы управляете FTE или людьми? как быть с зоопарком технологий? 5 проектов и 2 разраба на них - норм? )

Дмитрий, я рад, что вы знаете ответы на тесты. Только в реальном бизнесе за сертификаты не платят. Платят за результат.

Как я вам уже говорил: если PO регулярно недоступен - это не проблема команды. Это проблема того, кто допустил такую ситуацию.

В тесте правильный ответ - тот, который устроит авторов. Там говорят: «эскалируйте». Только вот бизнес вам скажет: «почините систему, чтобы эскалировать не приходилось!».

Чувствуете разницу? 😊

Вы спросили, что делать команде. Я ответил, как сделать так, чтобы этот вопрос вообще не возникал.

А сертификаты... Знаете, сколько я видел людей с сертификатами при найме? Тысячи. И примерно столько же бизнесов, было утоплено этими «сертифицированными» гениями, которые знали ответы на тесты, но не умели думать головой в реальной ситуации.

Так что извините, доказывать свою компетентность ответами на тесты я не буду. У меня для этого есть десятки клиентов и бизнесов, вытащенных из жопы, моими не сертифицированными советами. А бумажку оставьте себе и на стенку повесьте. Потом детям можно будет показать. 😉

Наталья, хорошие вопросы. Отвечу по порядку.

FTE или люди? И то, и другое. Это считай две стороны одной монеты. Первое - для планирования и бюджета. Второе - для развития и результата. Кто путает одно с другим - просто проигрывает.

Зоопарк технологий? Как правило это следствие отсутствия стратегии. Лечится архитектурным комитетом, стандартами и трезвым, жестким расчётом: что реально нужно бизнесу, а что - хотелки разработчиков, заказчиков и прочих личностей.

5 проектов на 2 разработчиков? Норм, если хотите получить 5 недоделок и 2 выгоревших сотрудника, которые убегут от вас сломя голову и хреновый отзыв о вашей работе. Хотите результат - приоритизируйте. Один проект в работу, остальные - в очередь. Или ищите людей. Всё гениальное просто.

Я ответил на ваши вопросы. Теперь позвольте спросить и мне: у вас в компании эти проблемы как решают через технологии или через систему?

Поразительный случай. А эти клиенты, они щас с вами в одной комнате? Прекращайте доставать что то из жоп, Роман.

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

Удачи вам как PO с вашими скрам-тестами. Сертификат на стеночке протрите и не забудьте поправить потом. Ну и вперёд к новым победам. 😉

Отвечу в личные сообщения)

А чего нам стесняться то, Наталья 😉 Если нет коммерческой тайны или какой то другой. Можете писать здесь. Вон у нас какой диалог то образовался. Мне прямо интересно стало😁, а самое главное, столько информации получаю о том, что в секторе IT происходит.

Ну на 2х fte делать выводы обо всем секторе скорее нельзя, чем можно 😂 а диалог и правда интересный) подняли вам охваты поста заодно))

Если честно, то я задал максимально простой вопрос🙂 и не думал что разразится такая битва в комментах, что сеть ли не консультацию придется оказывать по базе. Но в любом случае, это интересный опыт.