Андрей систематически забывает включать запись встреч. Участники разобрали это как кейс по управлению процессами: были инструкции, было согласие, но привычка не сформировалась. Вася отметил, что изначально не было строгих инструкций с конкретными шагами. Вывод: процесс должен быть максимально простым и привязанным к конкретному действию, а не к абстрактному обязательству.
Обсуждали ландшафт IT-сообществ: САБА (системные и бизнес-аналитики, ~120 человек), PM Club (закрытое сообщество проектных менеджеров с созвонами раз в две недели), DevOps-группы, чаты архитекторов. Все эти сообщества – части одного большого IT-комьюнити Казахстана, связанные через общих людей и пересекающиеся в разных чатах.
Андрей категоричен: до 50 человек в команде микросервисы не нужны без объективных причин. Модульный монолит дает то же логическое разделение (модули общаются через очереди/gRPC/REST), но без операционных издержек. Микросервисы наказывают за слабые компетенции: сетевые ошибки, рассинхронизация контрактов, сквозная отладка. Деление на сервисы должно отражать деление бизнеса (авторизация, логистика), а не техническое желание.
Самая социально острая тема. В IT принято гнобить за слабые компетенции, поэтому никто не признается в незнании. Команды берут задачи вместо спайков (исследовательских задач), потому что «взять спайк = признать, что не знаешь». Миша подтвердил на примере SAFe-команд. Василий резюмировал: стигматизация незнания заставляет людей брать двойную ответственность (спайк + имплементация) вместо честного разделения этапов.
Миша рассказал про типичные проблемы: вендоры разворачивают системы в Docker-контейнерах на 32 ГБ оперативки, не умеют работать с Kubernetes, не делают Helm-чарты, используют Persistent Volumes вместо cloud-native подходов. У маленьких команд нет бюджета на DevOps, а своих компетенций не хватает. Итог: «работает – не трогай».
Компания не умела проектировать API – бизнес-аналитики обещали «два поля добавить», в итоге вывалили внутренние API наружу для клиента. Проблема мировая: мало компаний проектируют API с учетом удобства потребителя. Smart Bridge Казахстана – пример плохо документированной системы, где community-driven вики с примерами подключений могла бы сильно помочь следующему поколению разработчиков.
Кейс с выступления: AI ускорил написание кода, но багов стало больше, тестеры перегружены, итоговый выигрыш – около 5%. Фокус разработчика сместился с написания кода на ревью. Решение: автоматизация тестирования, линтеры, анализаторы. Андрей добавил: LLM может генерировать «зеленые» тесты, которые ничего не проверяют – нужен человек для оценки тестовой модели на адекватность.
Принцип: откладывай решения как можно позже – это сохраняет гибкость. Аналогия с policymaking: законодатели намеренно не доделывают законы, дают рынку устояться, потом «закручивают гайки» на основе данных. Microsoft закрывает методы как internal на 10 лет и открывает только после статистического подтверждения потребности. Математическое обоснование через теорию вероятности помогает понять, какие риски ты принимаешь.
Павел рассказал про подход: маленькие специализированные агенты на слабых моделях, оркестратор координирует. Линейная архитектура не работает – нужна обратная связь, когда саб-агенты сталкиваются с проблемами. Важно разделять планер (составляет план) и оркестратор (координирует исполнение). Anthropic Claude Code Architect Certification – источник паттернов оркестрации.
| Вопрос | Андрей | Василий | Миша |
|---|---|---|---|
| Микросервисы | Не раньше 50 человек, модульный монолит | Модулями можно делить, не обязательно сервисами | Вендоры не тянут даже Docker нормально |
| Культура незнания | Отраслевая проблема, люди боятся признаваться | Следствие стигматизации, надо разделять этапы | Команды поддаются давлению бизнес-оунеров |
| AI в разработке | Статический анализ не спасает от логических ошибок | – | 5% выигрыш, нагрузка на ревью |
| Архитектурные решения | Откладывай как можно позже, policymaking | – | – |
До 50 человек микросервисы не оправданы без объективных причин. Монолит устойчивее к слабым компетенциям. Деление на сервисы должно отражать деление бизнеса, а не техническую моду.
Стигматизация незнания приводит к отказу от спайков, сокрытию проблем и избыточным техническим решениям. Спайк – нормальный инструмент, а не признание слабости.
AI ускоряет написание, но бремя качества переходит на ревью. Нужна инфраструктура: автотесты, линтеры, верификация тестовых моделей. Зеленые тесты ≠ правильные тесты.
Принимай решения как можно позже, решай только известные задачи, оставляй место для неизвестного. Математическое обоснование тестирования помогает принимать осознанные решения о рисках.
Маленькие специализированные агенты на слабых моделях с оркестратором – перспективное направление. Линейная архитектура не работает, нужна обратная связь и разделение планера и оркестратора.
Хотите обсудить эти темы с практикующими тимлидами?
Обсудить в Telegram