Все инсайты

Метрики, R&D, прибыль и управление ритуалами

Период: 19–24 мая · 1106 сообщений · 10 тем

Ключевые темы

1. Метрики врут – или вы неправильно смотрите?

Стас из Microsoft показал сообществу три графика стабильности билдов – одни и те же данные, но сгруппированные по неделям, месяцам и кварталам. Результат оказался неожиданным: на еженедельном графике участники видели хаос и шум, на квартальном – явный тренд к улучшению. При этом данные были абсолютно одинаковыми.

Дискуссия быстро разделила участников. Артур настаивал на декомпозиции по командам и людям – «найти тех, кто генерирует 80% фейлов». Денис, напротив, критиковал саму визуализацию: «столбцы несопоставимы, легенда однородна, чтобы разобраться – нужна бутылка». Андрей заметил, что управленец должен принимать решения даже при неполной информации.

Интересно, что за масштабами (2 000 тестов, 300 разработчиков, 1 000–1 500 билд-машин, 60–70 релизов в сутки) скрывается более глубокий вопрос: не что метрики показывают, а как мы их интерпретируем. Когда каждый тест в отдельности имеет 99% надёжности, а система из 10 000 тестов – всего 36%, одна только перспектива определяет, видите вы проблему или прогресс.

«График – гавно. Чтобы разобраться, нужна бутылка» – Денис, о качестве визуализации метрик
«Для метрик важна перспектива. На квартальном графике явно видны улучшения, на еженедельном – шум» – Стас
Читать в чате →

2. IT – кост-центр или двигатель прибыли?

Артур категорично заявил: «Прибыль генерят не инженеры. Прибыль генерят продажники и маркетологи». Утверждение вызвало бурную реакцию. Андрей назвал это «копиумом продажников», Уалихан привёл контрпример из аутстаффа, где разработчик – буквально продукт для лизинга. Стас спросил: а как тогда понять, сколько денег приносит конкретная фича в продукте уровня MS Teams?

Спор выявил фундаментальное различие в мышлении. Артур мыслил в категориях бухгалтерского баланса – расходы и доходы. Андрей и Стас – в категориях цепочки создания ценности (value chain), где каждое звено участвует в создании прибыли. Уалихан точно подметил: «Хер с ним, никто кроме продажников не приносит прибыль. Но разве это делает их самым значимым фактором?»

Казалось бы, академический спор. Но от ответа на этот вопрос зависит, как компания бюджетирует IT, как оценивает инженеров и какие решения принимает о найме. Если IT – это «просто расход», зачем инвестировать в качество кода?

«Даже если вы шахту золотую нашли и начали её разрабатывать, это расходная часть, пока ресурсы с шахты не будут продавать» – Артур
«В борделе прибыль генерирует не проститутка, а сутенер? Спорно» – Уалихан
Читать в чате →

3. Где начинается R&D и заканчивается «просто работа»?

Василий предложил шкалу от 0 (путешествие во времени) до 10 (колесо) и спросил: с какого уровня деятельность можно считать исследованием? Андрей провёл жёсткую границу: настоящий R – это работа за мировым фронтиром, а покупка и пуско-наладка готовой технологии – это D, development, и не надо путать.

Дискуссия обнажила проблему казахстанского IT-рынка. Андрей утверждал, что за 10 лет инноваций исследований почти нет. Василий возражал: Kaspi – уникальный продукт, а ЦАРКА делает настоящую исследовательскую работу в ИБ. Уалихан привёл собственный пример – два года исследований перед созданием облачной платформы, что составило «больше 10% всей жизни».

Практический вывод для тимлидов: называя рутинную интеграцию исследованием, мы девальвируем понятие и теряем способность отличать настоящее R от D. Но и обесценивать локальные достижения – значит отбивать желание двигаться дальше. Баланс между честностью и поддержкой – вечная дилемма лидера.

«Я не верю, что называя исследованием покупку и пуско-наладку технологии с рынка, чего-то можно добиться» – Андрей
«Я потратил на исследования перед созданием облака больше 10% всей своей жизни» – Уалихан
Читать в чате →

4. Навыки в эпоху AI – что учить, когда AI уже на уровне PhD?

Неделя началась с поста Стаса о трёх навыках, которые остаются важными: декомпозиция сложных задач для AI, культура коммуникации с AI (исключение двусмысленности) и способность понимать сложные системы для их проверки. При этом «уметь учиться» важнее конкретных знаний – AI может быстро объяснить технологии.

Андрей скептически отнёсся к идее манифестов: «Все манифесты разобрали маркетологи, никто не услышит манифест в текущем гаме». Параллельно Стас из Microsoft признал, что GitHub Copilot – «говно» по сравнению с Claude Code, и разработчики внутри компании используют Claude по максимуму, пока это возможно.

К концу недели Артём поднял вопрос о границе между вайбкодером и инженером. Дмитрий Мельник чётко обозначил разрыв: «Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» Вайбкодинг учит делать, но не учит понимать – а понимание остаётся ключевым навыком инженера.

«GitHub Copilot – говно. Пока доступен Claude Code – его используют по максимуму» – Стас, об инструментах внутри Microsoft
Читать в чате →

5. Первый опенсорс-контрибьют и сила сообщества

Дмитрий, начинающий разработчик, спросил совет о пет-проекте для портфолио. Вместо абстрактных идей сообщество направило его к реальному вкладу: Андрей предложил исправить баг в репозитории сообщества. Через несколько часов Дмитрий отправил свой первый PR – выравнивание кнопки на странице.

«Стыдно признаться, что это мой первый вклад в опенсорс» – написал Дмитрий. Андрей ответил: «Было ли бы тебе стыдно, что ты первый пошёл в приют для животных? Что важнее – что ты не делал когда-то, или то, что ты сделал сейчас?» И тут же – нетипичный для опенсорса подход: PR смерджили без ревью, доверяя автору. «Это не критичный сайт, покажем тебе другой стиль работы».

Стас при этом рекомендовал строить карту контрибуций по разным репозиториям вместо мёртвого пет-проекта: обширный след в опенсорсе выглядит для работодателя сильнее, чем заброшенный todo-лист.

«Стыдно признаться, что это мой первый вклад в опенсорс» – Дмитрий
«Было ли бы тебе стыдно за то, что ты первый пошёл в приют для животных?» – Андрей
Читать в чате →

6. IT-сообщества в Казахстане – есть ли спрос?

Артём анонсировал новое AI-инженерное сообщество. Стас поставил под вопрос саму идею: в 2019 году он вырастил чат с 600 до 1 800 человек, проводил митапы, гостевые лекции в университетах – но сильных проектов это не породило, «потому что они не нужны рынку».

Дмитрий Мельник возразил: проблема не в рынке, а в формате. Он видит результаты от системного обучения (курсы с методикой и обратной связью), тогда как свободное общение в чатах – слишком слабый формат. «Все сообщества мертвые. Но когда конкретно обучаешь конкретных людей, видишь классные результаты».

Андрей нащупал неожиданный компромисс: в Казахстане есть спрос на технические навыки (Артём, Дмитрий), но нет спроса на менеджмент (Стас) и сложные инженерные работы (Андрей). А слабый менеджмент – корневая причина: «Слабый менеджер не в состоянии даже не очень сложные технические решения продвигать».

«Все сообщества мертвые. Но когда конкретно обучаешь конкретных людей – видишь классные результаты. И это один и тот же рынок» – Дмитрий Мельник
Читать в чате →

7. Сотрудник не соблюдает ритуал – что делать, если уволить нельзя?

Василий поставил классическую управленческую задачу: сотрудник систематически не выполняет важный ритуал. 1-1 не помог. Автоматизировать нельзя. Уволить тоже. Что делать? Ответы разделились на два лагеря – силовой и системный.

Артур предложил «социальный конструктор» – публичное давление через дейлики, просьбы к коллегам спрашивать о ритуале, манипулятивные приёмы убеждения. «Много вариантов, могу ещё накидать. Они не все этичные, но работают». Андрей возразил: социальное давление не поможет, если человек просто забывает в нужный момент. Его альтернатива – делегировать процесс более ответственному участнику.

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

«Много вариантов, могу ещё накидать. Они не все этичные, но работают» – Артур
«Кто пашет, на том и едут?» – Андрей, о распределении ответственности в сообществе
Читать в чате →

8. Локальный PaaS для Казахстана – нужен ли рынку?

Уалихан представил сообществу свой проект – облачную платформу нового типа для казахстанского рынка. Проблема, которую он решает: в Казахстане нет локальных PaaS-решений, и стартапы строят инфраструктуру поверх нестабильных VPS. Preview environments, мультистенды, защита от DDoS – всё это требует отдельного отдела инфраструктуры, который стартапу не по карману.

Андрей задал жёсткие вопросы: «Понижая цену, ты уходишь в нищебродский сегмент – это самые муторные клиенты». И главное – «ты так и не сказал: что это и зачем оно нужно». Уалихан выделил три преимущества: цены ниже (не нужно отбивать инвестиции в полмиллиона долларов), настоящий pay-as-you-go биллинг и стабильность инфраструктуры.

Дискуссия обнажила типичную ловушку технических фаундеров: увлечённость решением мешает объяснить проблему. Андрей дважды просил «просто скажи, что это делает», прежде чем получил ответ. Для тимлидов – полезное напоминание: если не можешь объяснить продукт за 30 секунд, может, ты ещё не понял свою аудиторию?

«Понижая цену, ты уходишь в нищебродский сегмент. Это обычно самые муторные клиенты» – Андрей
«В простом да – много самонадеянности» – Уалихан, о своём подходе к unit-экономике
Читать в чате →

9. BeeTech и формат IT-конференций в Казахстане

BeeTech стала поводом обсудить формат IT-мероприятий в целом. Жибек, удалённый разработчик, поделилась впечатлениями: «Приятное времяпрепровождение для удалённого затворника. Больше для нетворкинга». Она отметила, что Алексей Утепов 6 месяцев осваивал то, чему Дмитрий Мельник учит за 2 – разработку агентов.

Параллельно Василий предложил неожиданный тезис: Astana Expo – отличная площадка для IT-сообществ. Множество организаций в пешей доступности, возможность организовать митапы прямо в рабочее время. Максим скептически спросил: «А делают ли?» В Алматы такого места нет – кроме района Нурлы Тау с банками.

Созвон сообщества в тот же день прервался из-за сбоя Telegram. Стас предложил перейти на Google Meet, Discord или Zoom. Андрей запустил голосование. Практический итог: зависимость от одной платформы – риск не только для продукта, но и для сообщества.

«Приятное времяпрепровождение для удалённого затворника» – Жибек, о BeeTech
«В Астане Экспо – крутая штука для айтишников. Сильное отличие от того, что в Алмате» – Василий
Читать в чате →

10. Мультиагентные системы и границы вайбкодинга

Борис описал архитектурный подход к AI: вместо одного большого промпта – несколько агентов с разными ролями, меньшим контекстом и специализированными системными промптами. На практике он реализовал это для платформы Archivision – системы архитектурного проектирования, где один агент с ограниченным контекстом не справляется.

Идея вызвала скепсис у Артёма: «Бесконечно сложно и ни разу не мидл». Но Борис возразил: «AI очень хорошо помогает. Как пет-проект – можно сделать за недельку-две. Сложнее промпты оттюнить на основе статистики, чем механику разработать с AI». Это подтвердило тезис Жибек с BeeTech – экспериментирование с агентами доступно, но от прототипа до продакшена – дистанция.

Дмитрий Мельник чётко обозначил разрыв между вайбкодером и инженером: «Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» Вайбкодинг учит создавать, но не учит понимать – а без понимания мультиагентная система превращается в мультиагентную проблему.

«Сложнее промпты оттюнить на основе статистики, чем механику разработать с AI» – Борис
«Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» – Дмитрий Мельник
Читать в чате →

Хотите продолжить обсуждение?

Обсудить в Telegram