Я как CTO, читаю эту статью как короткое объяснение для фаундеров и рекрутеров: автор нормально показывает, что CTO — стратегическая роль, которая не лезет в операционку и не превращается в «сеньора, который всё тянет сам».
В целом, я согласен со всеми пунктами, если не учитывать контекст.
В реальности, эта роль и ее фокусы меняются в зависимости от стадии компании и ситуации на рынке. Мне самому ближе роль CTO как бизнес-партнера. Работа над бизнес-стратегией тоже часть его работы: https://habr.com/ru/articles/907800/
Часть сам, часть с АИ. Уж очень много там связей. Больше 200. И надо бы еще добавить. Если кто-то найдет полезным, то покручу побольше. Там можно еще добавить описание того, как именно влияет пункт чек-листа на проблему.
Хороший разбор плохих кейсов. Я попробовал взять свою статью с чек-листом CTO и наложить на 36 проблем из статьи. Подумал, что может получиться что-то интересное.
29 пунктов чек-листа CTO vx 36 проблем в организации
С первой попытки, получилось не очень информативно. Потом добавил клик по пунктам и вроде можно посмотреть какие проблемы могут быть.
Влияние "структуры команд" на проблемы
Но, самым наглядным получился вариант с двудольным графом.
Лично меня бесит, что все заявления компаний про высокие SLA / UPTIME это всегда маркетинг. Это значит, что если тебе нужно что-то сравнить, то ты будешь опираться на свой опыт, либо на опыт знакомых. Реально измерять никто не будет.
Крупные продукты всегда говорят о высоких SLA, но в реальности, такие сервисы состоят из большого числа компонентов/сервисов и когда один из них не работает, это не считается простоем. А когда таких компонентов десятки или сотни, то ты как пользователь постоянно ощущаешь как у тебя что-то вечно отваливается, но SLA будет 5 девяток. И вот с этой проблемой вообще ничего не сделать ...
Поэтому, вывод один: не читайте советских газет заявления сервисов касательно их SLA, это маркетинг.
Open source для автора это всегда маленький продукт. Если это библиотека, то это оценка других разработчиков (комьюнити), кто готов ее использовать. Это прежде всего бесценный опыт.
Как CTO, могу сказать, что текст хороший. Подписываюсь под приоритетом управленческих навыков. Закрывать команду от хаоса — нормальный тактический прием, но на долгой дистанции я бы попробовал научить команду работать с этим хаосом самостоятельно.
Я бы хотел увидеть в статье немного про CTO и рынок. Важно не упускать из вида исследование внешней среды. Если начать не с потребностей клиентов и позиции компании относительно конкурентов, то найм, бюджеты и процессы могут быть реакцией на шум или галлюцинации менеджмента.
Я бы начал с позиции на рынке и развития навыков «понимания ситуации на рынке», потом уже всё остальное. Дашборды и JIRA — не стратегия, это ритуалы в заданных ограничениях.
Я за то, чтобы CTO смотрел на эти тренды, как на точку опоры для достижения целей. Сначала — рынок и стратегия, а тренды приходят и уходят. Важно уметь их использовать, вписывая в общую рамку, хотя, иногда нужно быть гибки и менять рамку под давление трендов.
Напишу с позиции своего СТО опыта. Я согласен с ключевым: CTO — не роль пошаблону, а функция, которая живёт в контексте компании. Тип или типаж действительно важно подбирать под стадию продукта, культуру и задачи. Иначе вместо технического лидера получаем красивую визитку и хаос завернутый в воздушные замки.
Но вот что зацепило. Делить CTO только по «типажам» — опасно. Можно заиграться в ярлыки и забыть про базовую работу: рынок, стратегия, инженерная культура. Можно хоть сто раз попасть в «правильный» типаж, но если CTO не понимает, куда движется бизнес и как на это ложится технология, — ничего не взлетит.
На Хабре почему-то не принято писать или комментить статьи про роль CTO. Буду первым. В целом, я согласен с автором. Особенно про то, что роль CTO меняется на каждом этапе жизни компании. От «сам пишу MVP» до «убеждаю совет директоров в выделении AI-направлении и формировании новой команды под это».
Согласен с делением на стадии и с тем, что CTO в стартапе и CTO в корпорации очень различаются, писал об этом в своей статье про задачи СТО. Да, сначала ты бегаешь с гаечным ключом, а потом учишь остальных бегать с этим ключом. И да, без навыков работы с людьми в компании 50+ человек, ты потопишь команду.
Но вот с чем не согласен. техническая экспертиза — не только «для стартапа». Даже на уровне 1000+ человек CTO обязан понимать, что у него под капотом, чтобы не продавать команде воздушные замки. Стратегия без базы в технологиях превращается в красивую, но бесполезную презентацию.
Спасибо, что вы оставили сравнение с Qwen2.5 на синтетике, где видно, что модель проигрывает. Все чаще, сейчас, такое предпочитают скрывать или умалчивать.
Я как CTO, читаю эту статью как короткое объяснение для фаундеров и рекрутеров: автор нормально показывает, что CTO — стратегическая роль, которая не лезет в операционку и не превращается в «сеньора, который всё тянет сам».
В целом, я согласен со всеми пунктами, если не учитывать контекст.
В реальности, эта роль и ее фокусы меняются в зависимости от стадии компании и ситуации на рынке. Мне самому ближе роль CTO как бизнес-партнера. Работа над бизнес-стратегией тоже часть его работы: https://habr.com/ru/articles/907800/
Часть сам, часть с АИ. Уж очень много там связей. Больше 200. И надо бы еще добавить. Если кто-то найдет полезным, то покручу побольше. Там можно еще добавить описание того, как именно влияет пункт чек-листа на проблему.
Можно тут посмотреть связи и код: https://github.com/pahaz/pahaz.8iq.dev/blob/main/public/cto-checklist-vs-problem-ru.html#L469
Хороший разбор плохих кейсов. Я попробовал взять свою статью с чек-листом CTO и наложить на 36 проблем из статьи. Подумал, что может получиться что-то интересное.
С первой попытки, получилось не очень информативно. Потом добавил клик по пунктам и вроде можно посмотреть какие проблемы могут быть.
Но, самым наглядным получился вариант с двудольным графом.
Залил сюда: https://pahaz.8iq.dev/cto-checklist-vs-problem-ru.html если кому-то интересно пощелкать на связь задача CTO - проблемаы.
Может быть полезно, чтобы учесть возможные проблемы до момента их наступления.
Ссылки
Чеклист: https://habr.com/ru/articles/907800/
Проблемы: https://habr.com/ru/articles/965750/
Итог: https://pahaz.8iq.dev/cto-checklist-vs-problem-ru.html
Лично меня бесит, что все заявления компаний про высокие SLA / UPTIME это всегда маркетинг. Это значит, что если тебе нужно что-то сравнить, то ты будешь опираться на свой опыт, либо на опыт знакомых. Реально измерять никто не будет.
Крупные продукты всегда говорят о высоких SLA, но в реальности, такие сервисы состоят из большого числа компонентов/сервисов и когда один из них не работает, это не считается простоем. А когда таких компонентов десятки или сотни, то ты как пользователь постоянно ощущаешь как у тебя что-то вечно отваливается, но SLA будет 5 девяток. И вот с этой проблемой вообще ничего не сделать ...
Поэтому, вывод один: не читайте
советских газетзаявления сервисов касательно их SLA, это маркетинг.Мы разрабатываем open source продукт с MIT лицензией. У нас есть блок для работы с клиентами, если будет желание, то можем сделать коллаб. Код на гитхабе: https://github.com/open-condo-software/condo
Расскажу историю своей опенсорс платформы. Может кому-то будет полезно.
Я ожидал где-то тут увидеть ссылку на GitHub. С примером или чем-то подробным.
Open source для автора это всегда маленький продукт. Если это библиотека, то это оценка других разработчиков (комьюнити), кто готов ее использовать. Это прежде всего бесценный опыт.
Мало компаний готовы поддерживать open source разработку. Поделюсь своим опытом разработки open source продукта.
Оставлю тут ссылку на наш опыт открытой разработки SRM-системы. Если кто-то ищет открытый проект, мы будем рады помочь :)
Поделюсь своим опытом, как мы разрабатываем open source SaaS и что это дает.
Все так, основа — хороший продукт. Если продукт не очень, то хоть open source, хот close. Никакой разницы.
Как CTO, могу сказать, что текст хороший. Подписываюсь под приоритетом управленческих навыков. Закрывать команду от хаоса — нормальный тактический прием, но на долгой дистанции я бы попробовал научить команду работать с этим хаосом самостоятельно.
Я бы хотел увидеть в статье немного про CTO и рынок. Важно не упускать из вида исследование внешней среды. Если начать не с потребностей клиентов и позиции компании относительно конкурентов, то найм, бюджеты и процессы могут быть реакцией на шум или галлюцинации менеджмента.
Я бы начал с позиции на рынке и развития навыков «понимания ситуации на рынке», потом уже всё остальное. Дашборды и JIRA — не стратегия, это ритуалы в заданных ограничениях.
Я за то, чтобы CTO смотрел на эти тренды, как на точку опоры для достижения целей. Сначала — рынок и стратегия, а тренды приходят и уходят. Важно уметь их использовать, вписывая в общую рамку, хотя, иногда нужно быть гибки и менять рамку под давление трендов.
Напишу с позиции своего СТО опыта. Я согласен с ключевым: CTO — не роль по шаблону, а функция, которая живёт в контексте компании. Тип или типаж действительно важно подбирать под стадию продукта, культуру и задачи. Иначе вместо технического лидера получаем красивую визитку и хаос завернутый в воздушные замки.
Но вот что зацепило. Делить CTO только по «типажам» — опасно. Можно заиграться в ярлыки и забыть про базовую работу: рынок, стратегия, инженерная культура. Можно хоть сто раз попасть в «правильный» типаж, но если CTO не понимает, куда движется бизнес и как на это ложится технология, — ничего не взлетит.
На Хабре почему-то не принято писать или комментить статьи про роль CTO. Буду первым. В целом, я согласен с автором. Особенно про то, что роль CTO меняется на каждом этапе жизни компании. От «сам пишу MVP» до «убеждаю совет директоров в выделении AI-направлении и формировании новой команды под это».
Согласен с делением на стадии и с тем, что CTO в стартапе и CTO в корпорации очень различаются, писал об этом в своей статье про задачи СТО. Да, сначала ты бегаешь с гаечным ключом, а потом учишь остальных бегать с этим ключом. И да, без навыков работы с людьми в компании 50+ человек, ты потопишь команду.
Но вот с чем не согласен. техническая экспертиза — не только «для стартапа». Даже на уровне 1000+ человек CTO обязан понимать, что у него под капотом, чтобы не продавать команде воздушные замки. Стратегия без базы в технологиях превращается в красивую, но бесполезную презентацию.
Спасибо за интересную статью.
Дефицит IT-кадров никуда не делся — просто «шум» от волны увольнений и сокращений его маскирует.
Рост стоимости капитала и падение рынка рушит финмодели, убивает «компании на грани» и вынуждает резать эксперименты для снижения риска.
Поправил и добавил расшифровку. Не хотел загромождать определениями текст. Пока писал, половину сократил. Спасибо.
Удивительно, что даже Gemma 3 27b выше гигачата. Интересно посмотреть на YandexGPT.
Спасибо, что вы оставили сравнение с Qwen2.5 на синтетике, где видно, что модель проигрывает. Все чаще, сейчас, такое предпочитают скрывать или умалчивать.
Снимаю шляпу 🎩