В новом эпизоде курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым продолжаем тему Поведенческих паттернов. На рассмотрении следующие два подхода: Команда и Посредник — разберёмся, какие задачи они решают, как выглядят соответствующие UML-диаграммы, а также какие особенности следует учитывать при реализации в коде.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Выложили в открытый доступ Kodify Nano – модель для кодинга
Это уже вторая опенсорс-модель от MWS AI (ранее MTS AI) – первую, Cotype Nano для работы с текстами, выпустили в конце прошлого года.
Ключевые характеристики:
1,5 млрд параметров;
контекст 32 768 токенов;
ключевые языки: Python, Java, JavaScript, C# и Go
Функции:
генерация и автодополнение кода;
документирование разработки;
генерация юнит-тестов;
объяснение чужого кода.
Встраивается в среды разработки, работает в формате чат-ассистента. Поставляется в трех версиях, все можно скачать на Hagging Face:
Kodify‑Nano – рекомендуется на видеокартах Nvidia c не менее, чем 10 Гб памяти.
Kodify‑Nano-GPTQ (4bit) – квантизированная версия Kodify Nano, которая в три раза меньше оригинальной модели. Рекомендуется на видеокартах Nvidia c не менее 6 Гб памяти.
Kodify‑Nano-GGUF – сконвертирована для работы с Ollama/llama.cpp. , на случай, если нет мощной видеокарты. Есть варианты 16 бит, 8 бит и 4 бита.
Мы рекомендуем использовать модели с нашим собственным плагином (скачать тут), он уже настроен для работы с Kodify Nano. Есть версии для VS Code и IntelliJ IDEA (и других IDE Jet Brains).
Знаем, 1,5B параметров – это совсем немного. Основная корпоративная модель – Kodify 2, вышедшая ранее, – тоже не гигант, 7B. Вот тут в статье рассказываем, почему пошли по пути создания легковесных моделей, и что делаем, чтобы они справлялись со своими задачами достойно.
Разработка или Vibe Coding продолжается 3 день. Я все ещё использую Bolt и смог сделать вполне рабочий сервис. Вручную программисту потребовалось бы около 1-2 недель на такой функционал.
Авторизация
Редактор форм
Просмотр ответов форм с фильтрами
Выгрузка ответов в csv
Шаблоны форм
Загрузка файлов в хранилище
Публикация формы для клиента
Все уже работает и связано с БД
Остальные скрины и ДЕМО версию пришлось опубликовать в телеге т.к. тут лимит на 1 картинку.
В моем канале IT Talks можно скачать бесплатный методический материал, где ты найдешь шаблоны пяти основных диаграмм на PlantUML в практических кейсах с описанием.
Для каждого шаблона подробно описан процесс, для которого построена диаграмма, а также есть сама диаграмма и исходный код на PlantUML. В гайде можно найти диаграмму активности, последовательности, прецедентов, состояний и компонентов.
Это восьмая серия курса «Паттерны и практики написания кода», где вместе с бэкенд-инженером Юрой Афанасьевым открываем новую тему — Поведенческие паттерны. Данная группа самая обширная из всех изученных, поэтому в новом эпизоде постепенно разберём первые два подхода: Стратегия и Состояние.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Правда ли, что пользователи фанатеют по темному режиму? Проверяем в своем приложении
Много слышал о том, что темная тема ― это тренд и чуть ли не 100% пользователей на нее переедет.
Мы решили проверить, как обстоят дела с темной темой в нашем мобильном приложении системы управления проектами YouGile. Dark mode у нас просили еще с момента запуска мобильного приложения, темная тема входила в топ-10 запросов. Проверили ― оказалось, 40% регулярно использует dark mode.
Так выглядит наше приложение YouGile в темной и светлой темах
Похоже ли это на то, что светлая тема вообще не нужна? Видимо, нет. Пользователи из России предпочитают и то, и другое ― темную тему ставит 34% пользователей (данные 2023). Опрос Android Authority показывает, что dark mode предпочитает 81% респондентов, но опросу уже пять лет и выборка там менее 3 000 человек.
А вообще темный режим ― это правда полезно, особенно для зрения. А вот то, что темная тема экономит заряд батареи ― видимо, неправда. В этом году выяснилось, что скорее наоборот. Все из-за того что пользователи включают яркость экрана на максимум.
Я сам использую темную тему, причем везде, где это возможно. Даже в документах Word у меня черный лист и белый текст. Мне нравится, что так экран более контрастный и глаза устают меньше.
Микрокоманды захватывают Кремниевую долину в США. Компании доходят до миллиардных капитализацией с 10 сотрудниками. Среди таких стартапов — Safe Superintelligence от Ильи Суцкевера, Midjourney и Adept — в каждой большую часть работы выполняет ИИ. По словам экспертов, это «смерть» для карьерного роста многих менеджеров.
Бизнес-категории Авито Услуг разительно отличаются и каждую из них развивает отдельная команда. Запросы на аналитику от заказчиков к таким командам часто похожи — преобразуясь в ad-hoc задачи, они несут в себе одну неочевидную угрозу статичной работы.
Как поступить, чтобы такого не допускать?
Привет, я Алексей Авраменко, тимлид команды аналитики в Авито Услугах, и ниже мои 10 способов решения этой проблемы:
Решайте проблемы заказчиков. Когда коллеги приходят с задачей «Выгрузите ушедших пользователей», важно понять, что они хотят оценить. Например, если это эффект от новой инициативы, то его лучше покажет динамика активных клиентов, которая уже есть в дашборде. Естественный отток происходит всё время и список ушедших пользователей ничего не даст без анализа динамики. Задавайте вопросы, чтобы решать проблемы стейкхолдеров, а не выгружать чиселки.
Делайте автоматическую базовую отчетность. Этот процесс должен стать постоянным. Сегодня достаточно одного отчёта, завтра будет фокус на новой стороне продукта — и придётся добавить новый.
Минимизируйте хаос. Избегайте вмешательства заказчиков в середине спринта. Мотивируйте их следовать процессам: приходить на брейншторм и планирование, создавать задачу, описывать проблему и ожидания. Не все заказчики дойдут даже до планирования — срочность и важность задачи могут быть преувеличены.
Унифицируйте решения для похожих задач. Группируйте запросы коллег по общим признакам и метрикам и решайте одну задачу, которая покроет сразу все потребности.
Предвосхищайте вопросы. Иногда вы лучше заказчика знаете, что ему надо, и можете предугадывать проблемы. Думайте наперёд, чтобы сэкономить время на добавлении нового поля/ разреза/ функциональности или вообще на изменении решения.
Отказывайте. Даже если вы любите ваших заказчиков, иногда надо говорить «нет», но обязательно с объяснением причины: «нет, потому что…».
Планируйте задачи хотя бы на квартал вперёд. Так вы получите фокус и синхронизируетесь по ожиданиям с заказчиками. Планирование даст вам дополнительный аргумент для приоритизации задач.
Уточняйте причину срочности. Когда заказчик врывается с запросом «Срочно! Посчитайте мне длину удава в попугаях!», обязательно выясните, какие запланированные события зависят от этих данных. Иногда оказывается, что встреча по физиологии удава стоит через 3 недели. И даже для перестраховки длину удава достаточно получить в течение следующего спринта.
Создавайте инструменты для самообслуживания. Для простых однотипных задач можно сделать удобный инструмент и инструкцию к нему. Так заказчики часть проблем смогут устранить сами при косвенной поддержке с вашей стороны.
Будьте эмпатичным. Не оставляйте заказчиков один на один с их проблемой. Дайте им хотя бы минуту внимания и несколько идей, что им может помочь.
Делитесь в комментариях, какие способы уже были в вашей работе.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В cедьмой серии курса «Паттерны и практики написания кода» разберем три последних подхода в теме Структурных Паттернов: Мост, Заместитель и Приспособленец. Вместе с бэкенд-инженером Юрой Афанасьевым посмотрим, как паттерны реализуются в коде и в чём состоит их ключевое назначение.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков
Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.
Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.
Инструменты безопасности
На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.
По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.
Чат‑режим в SourceCraft Code Assistant
ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.
Зеркалирование и бесшовная миграция
Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.
Также появился федеративный доступ к платформе для компаний — авторизация через SSO.
Публичный API
Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.
Правила работы с ИТ‑проектами
В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.
Опенсорс
Появился анонимный доступ к публичным репозиториям платформы.Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.
Удобство работы с кодом
Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.
Автоматизация CI/CD‑процессов
Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.
Packages
Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.
Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.
Что обсудили: — рабочий день техлида, — горизонтальное vs вертикальное развитие: что выбрать, — сложности руководства командой, — опыт работы в Германии и возвращения, — почему Юрий выбрал МойОфис, и как у нас устроена инженерная культура, — как развиваться самому и развивать продукт.
Хотите стать техлидом или просто узнать, что значит вести команду? В этом выпуске — кейсы и честные истории про задачи и людей.
В новом эпизоде отрытого курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Авито Юрой Афанасьевым продолжаем тему Структурных Паттернов. Разберём два новых подхода — Декоратор и Фасад, поговорим про UML-диаграммы паттернов и их реализацию в коде, а также рассмотрим основные преимущества подходов.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект! Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?
Agile обещал гибкость и гуманистический фокус. Однако новые роли, жесткий спуск сверху, трансформации и бесконечный встречи превратили его в бюрократию новой волны Теперь же “искусственный интеллект” врывается в менеджмент и ставит жирную точку: куда интереснее цифровые следы людей и возможности автоматизации и прогнозирования, а не работа в ценностной модели и адаптивности. Аджайл перестал справляться с изменениями и запросами на больший контроль поставляемого результата
У меня есть коллега, который активно включает LLM как в пайплайны разработки, так и в общие операционные процессы - и вот уже два месяца его студия живет без единого дейлика, встречи крайне редко, но повысилась асинхронная работа, коллаборация через код и документы, а также возможности глубокого погружения задачи без постоянного переключения контекста. Иногда ему кажется, что он здесь лишний
Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile
Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?
Data-класс вашей ошибки: как относиться к ошибкам как программист
Ошибки можно рассматривать как задачи, которые возникли в ходе решения другой таски. Только, как правило, с экстремально короткими сроками выполнения и большим потоком информации. И входишь ты в этот поток не с самым высоким уровнем мотивации и возможным давлением.
Чтобы убрать эмоции из анализа ошибки и подойти к ней с «трезвой» головой, можно разложить ее как код. Вот, например, какой data-класс можно выделить у ошибки:
class Error {
// что нужно было сделать
var task
// что пошло не так
var errorDetails
//какие возможные последствия уже есть или последуют и кто может пострадать
var effect
//причины ошибки
var reasons
//плюшки от решения сложившейся ситуации
var benefits
//выводы
var experience
//список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
var actionItems
}
А теперь — реализация.
Пример: Вы неверно оценили сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблись на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная.
Как бы выглядела реализация интерфейса для данного случая:
class BadEstimationForMVPMessaging {
var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
var effects = listOf(
- релиз переносился два раза
- демотивация команды
- вопросы с продуктовой стороны
)
var reasons = listOf(
- часть задач были сильно недооценены
- не учтены зависимости, которые, конечно, вылезли только в конце
- не заложен запас по времени
)
var benefits = listOf(
- хороший пример, который можно разобрать
- прокачан навык работы с ожиданиями
- ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
)
var experience = listOf(
- детальнее искать зависимости на этапе подготовки к эстимации
- закладывать запас по времени в 2-3 релиза
- на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
)
var actionItems = listOf(
- составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
- обсудить с командой процесс выявления зависимостей
)
}
Смотреть на ошибки так гораздо эффективнее. Вы выносите из них уроки, а не просто посыпаете голову пеплом. Попробуйте!
А больше лайфхаков по построению здоровой культуры ошибок в жизни и на работе читайте в подробной статье от Марии Киселевой, тимлида команды разработки мобильных приложений для KvadraOS в YADRO →
Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?
В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Порождающие паттерны Prototype и Singleton: а минусы будут?
В новой серии открытого курса «Паттерны и практики написания кода» мы завершим изучение порождающих паттернов знакомством с двумя шаблонами — паттерном Прототип и паттерном Синглтон. Вместе с бэкенд-инженером Юрой Афанасьевым разберемся, почему паттерн Prototype — простой в реализации — используется редко, а паттерн Singleton — самый критикуемый.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В новом выпуске подкаста «Свободный слот» обсуждаем сложные решения тимлида — те, что бьют не по метрикам, а по нервам. Чтобы разобрать эту непростую тему, ведущие Саша Прокшина и Паша Федотов встретились с Олегом Федоткиным, CTO в «Циан». Как принимать решения, когда нет правильного ответа? Уволить или дать шанс? Сохранить команду или пойти на реорганизацию? Согласиться на даунгрейд ради себя или тянуть дальше? Выделите свободный слот в своем расписании, чтобы вместе с ребятами найти ответы на все вопросы.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐
Олег и Денис, наши фронтенд-разработчики, рассказали, почему отказались от этого фреймворка, несмотря на то что потратили на погружение в него немало времени. Это был хороший эксперимент, который дал нам много полезных инсайтов. ✍️
Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.
В React Native просто начать делать компоненты, но, погрузившись в нативную часть, мы почувствовали себя джунами — запилить поле ввода с нативной валидацией было непросто.
Вот что мы поняли при разработке:
● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.
● React Native может подойти для проектов, которые начинаешь с нуля и нужно охватить мобильные платформы и веб сразу.
Результаты нашего эксперимента
Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:
✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.
✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.
Будет ли применимо для нас в будущем — время покажет. Возможно, для новых продуктов это рабочая схема, сейчас — экономически неоправданно.
В малом и микро бизнесе встречаются два вида контроля. Они в каком-то смысле противоположны друг другу по цели и методам осуществления.
В первом случае предприниматель чувствует облегчение, что кто-то занимается отделом продаж и старается не вдаваться в подробности. Во втором контроль — это способ справиться с тревожностью. Спросил, и вроде отлегло.
Есть еще третий способ, когда предприниматель формализует и контролирует все, что хоть как-то похоже на процесс. Он верит, что бизнес должен быть оцифрован; что получаешь ровно то, что контролируешь; и прочие законы успешного бизнеса, с которыми трудно не согласиться.
Однако, нужно еще ответить на вопрос: каким должен быть следующий шаг. Контроль в общем смысле — это не только получение информации о деятельности подразделений, но и управленческое воздействие на основе этой информации.
Управленческое воздействие сильно зависит от того как интерпретировать данные. А те, в свою очередь, зависят от того куда мы смотрели.
Модерация объявлений, коммуникация внутри сервиса, меры безопасности — рассказываем о SafeCom в новом выпуске «AviTalk». На этот раз экспертизой делится Антон Тупиков, технический лидер дирекции SafeСom Авито. Вместе с ведущей Стасей Кошман говорим о найме в SafeCom, интересных кейсах из работы сервиса и способах стать детективом внутри Авито. Антон также поделится историей собственной карьеры: от первых проектов до перехода в Авито.
Чтобы ничего не пропустить, включайте видео и делитесь мнением в комментариях.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).
BI-проекты: 5 причин, почему они выходят за рамки бюджета (и как этого избежать)
Если вы хоть раз участвовали во внедрении BI-системы — знаете, как легко проект может уйти не туда: – бюджет трещит по швам, – сроки съедены интеграцией и доработками, – пользователи по-прежнему делают аналитику в Excel.
Мы в GlowByte собрали в статье практический разбор типичных ошибок, которые чаще всего приводят к перерасходу бюджета и снижению отдачи от BI-проектов.
Плюс: даём самодиагностический чек-лист и PDF-гайд, где перечислены все организационные, финансовые и технические риски BI-проектов.
Открытый проект редактора Neovim имеет уже более 100 ИИ-плагинов сейчас. Их список привёл разработчик решение Colin Kennedy. Некоторые из плагинов в списке находятся в разработке или могут быть не полностью ориентированы на редактор Neovim.
В прошлом году усиленно начал пользоваться AI (LLM) тулами и словил жуткую волну грусти-печали после 5-6 месяцев использования. Для меня самым сложным стало не то, что код в целом может писать LLM, а осознание того, то в общем-то это и не так важно. Гораздо важнее появился абстрактный вопрос зачем его вообще писать если завтра всё может поменяться настолько быстро что глазом не моргнешь.
Погрустив и поболев буквально и походив по книжным магазинам наткнулся на интересную книгу - The Art of Excellent Products: Enchanting Customers with Premium Brand Experiences by Riccardo Illy. И эта книга попала настолько, что понял как разрешить (на текущий момент), моральную дилемму с AI кодом, когда ты сам не пишешь код, а его пишет AI - через этические принципы.
На мой взгляд этические принципы дают три возможности:
Ограничения или фокус - зафиксировав принципы, можно фокусироваться только на том, что действительно важно и отбрасывать / deprioritize то, что не согласуется с этими принципами.
Гибкость при принятии решений - зная ограничения и имея этический фокус, можно при необходимости быстрее принимать ответственные решения, но при этом не жертвовать тем, что этически важно для компании / продукта.
Доверие - имея ограничения в виде выбранных этических принципов, ценности продукта / компании могут стать более устойчивыми к кризисам - что в итоге может дать больше доверия продукту для конечного пользователя. В теории:)
Поэтому с начала года я начал думать над принципами / ценностями / values и пытаться понять, какие подходят - и почему.
вышел из digital чтобы написать ручками в блокнотике:)
Для себя выделил три группы (пока что): - Приложения, игры и персональные принципы.
Например для приложений пока пришел к такому списку:
Удобство
Простота
Безопасность
Долговечность
Полезность
Для игр (так как это хобби, немного другие принципы):
Полезность
Творчество
Развлечение
Вызов
На текущий момент (май), 5 месяц тестирования - и могу честно сказать что стало гораздо проще фокусироваться на проблеме и решении чем раньше. Уверен что с развитием AI многое ещё изменится - но как будто это может стать мостиком для работы с ним с морально - этической стороны (особенно когда нужно торговаться / выбирать между быстрее - качественнее).
Ещё завел телеграм канал - https://t.me/devethics, в который стал собирать ценности / принципы которые внезапно стал открывать у других людей и компаний (продуктовых, электронных) и т.д.. Пока назвал этика разработчика:)
Надеюсь что пост чем нибудь вдохновит и окажется полезным :-)
Пожалуйста делитесь своими мыслями в комментариях:-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией:-)
Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).
Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.
ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)
20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.
Несколько информационных моментов.
1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО
Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.
2. Вебинары РБПО-направленности
Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:
Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.
3. Сертификация ФСТЭК
В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?
Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).
PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.
PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):
PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);
PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);
продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.
Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.
Работа каждого руководителя начинается с PDCA (Plan–Do–Check–Act)
Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!
Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.
В целом по способности выстроить всю цепочку от планирования до развития можно оценить любого руководителя. Каждый этап имеет свой вес в зависимости от специфики работы. Руководитель, исходя из своих личных особенностей и контекста бизнеса, может активнее участвовать в одних звеньях цепочки и делегировать другие. Полностью вложиться конечно можно, но гораздо спокойнее, если часть элементов делегировать, оставив себе наиболее критичные.
Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.
Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.
Руководителю лучше заранее решить, за что браться самому, а что делегировать для обеспечения полноты управленческой цепочки. Ну или надеется на "авось", а потом расхлебывать. В нашем случае девочка планировала, её отец брался за работу и развитие. Но цепочка была неполной как раз из-за отсутствия контроля — никто по-настоящему не отвечал за результат. Вот и получили то, что получили.
Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.
Есть 1000 и 1 способ организовать продуктовую команду, и каждый со своими преимуществами и недостатками. Как тут выбрать и не ошибиться? (*ﾉωﾉ)
Наш CPO Саша Бондаренко собрал и описал более 12 моделей команд. У каждой указал, какому типу компаний она подойдет, а также дал инструкцию по подбору «той самой». Получился большой материал, который мы разбили на несколько частей.
Спрос на IT-специалистов в 2025 году близок историческому минимуму и продолжает падать — по многим направлениям количество IT‑вакансий стало меньше, чем в самые тяжёлые времена ковида.
С конца 2022 года многие IT-компании во всём миру уволили примерно 635 тысяч сотрудников.
Эксперты винят в этой ситуации спад выручки, закрытие проектов, а также автоматизацию и внедрение нейросетей, которые снимают ощутимую часть работы. Специалисты говорят, что такие события будут прогрессировать по мере совершенствования ИИ. Под угрозой оказались даже сеньоры с 15-летним опытом и специалисты Microsoft, Google, Tesla, eBay и PayPal.
Что такое чистая архитектура: основные особенности
Чистая архитектура — это подход к проектированию систем, который предполагает независимость от фреймворка и вообще от внешних компонентов. Выделяем слой use-кейсов, слой сущностей, UI и презентер — и теперь эти слои и есть наши фреймворки. Поэтому реальный фреймворк в чистой архитектуре можно использовать как инструмент, а не перестраивать весь проект под его ограничения.
Как, по сути, работает чистая архитектура
Какие еще свойства чистой архитектуры важны:
Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.
Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.
Большой материал о том, на каком проекте была внедрен этот подход и почему выбрали именно его, читайте в блоге.
❓Разработчик и стартап: работать | основать | избегать?
В новом выпуске Sravni Tech Podcast обсуждаем, куда податься разработчику: пойти работать в стартап, рискнуть и запустить свой или держаться подальше от “стартапной суеты”? Наш гость — Илья Хрусталёв, основатель Foodfox (тот самый, что стал «Яндекс.Едой»).
В выпуске: 📌Работа в ИТ-стартапе: ожидание vs реальность 📌Жизненный цикл стартапа (и когда это уже не стартап?) 📌Запускаем свой бизнес в ИТ. Что важно учесть? 📌Различия стартапов в России и США. Где проще получить инвестиции?
Если в компании несколько команд, хорошая идея — время от времени переводить спецов с проекта на проект. Особенно это полезно для тех разработчиков, темп работы которых чуть ниже, чем в среднем по больнице. Новый проект поможет им увеличить производительность, а тимлиду — найти уязвимости в обеих командах.
Разберем, как это работает:
Новая среда и культура могут вдохновить разработчика на новые идеи и подходы, которые он не рассматривал ранее. Иногда смена обстановки может повысить мотивацию специалиста и помочь ему переосмыслить методы работы.
Обратная связь от новой команды поможет найти точки роста или новые, более эффективные инструменты. А всё вместе это может благотворно влиять на продуктивность разработчика.
Разнообразие задач помогает нащупать как пробелы, так и темы, в которых разработчик чувствует себя как рыба в воде. Кроме того, если внимание иногда переключается с задачи на задачу, улучшаются навыки и растет уверенность.
Обмен опытом позволит специалисту перенять лучшие практики и подходы у новых коллег, а это никогда не бывает лишним. Плюсом опять же потенциальный рост продуктивности — новые подходы и процессы могут помочь.
Идентификация проблем. Если разработчик работал медленно в одной команде, но быстро в другой — возможно, в первой проблемы. Они могут быть связаны с коммуникацией или с постановкой задач, но проверить точно стоит.
Главное при ротации — приставить к разработчику более опытного ментора. Так человеку будет легче адаптироваться в новой среде и получить необходимые знания для повышения продуктивности.
Больше советов по этой теме читайте в нашей статье. Она поможет выстроить работу команды разработки таким образом, чтобы дедлайны не срывались.
Президент РФ Владимир Путин в рамках «перечня поручений по итогам пленарного заседания и посещения выставки Форума будущих технологий, включая встречи с учёными», поручил Правительству РФ рассмотреть вопрос о создании национального суперкомпьютерного центра.
«С учётом ранее данных поручений рассмотреть вопрос о создании национального суперкомпьютерного центра, предусмотрев возможность предоставления российским исследователям доступа к его вычислительным мощностям и обратив внимание на необходимость подготовки кадров для данного центра».
Раньше (до того как машины стали стоить как квартира) замечал несколько раз - вот выберешь себе новую машину и вдруг в городе их оказывается уже очень много. Вот едет и вот еще. И потом начинаешь замечать, что их реально много стало вокруг.
На самом деле, их конечно же не стало больше, просто мы их стали замечать.
Такое наше поведение является проявлением эффекта Пигмалиона (Розенталя) и является одним из когнитивных искажений (ошибок мышления - обожаю эту тему, вот и сюда ввернул).
Эффект Пигмалиона - ожидания человека определяют его действия.
Психологи Роберт Розенталь и Ленора Якобсон провели эксперимент: в начале учебного года они выделили учеников из разных классов начальной школы, которые по результатам теста оказались более талантливыми и обладали более высоким IQ, чем их одноклассники. На самом деле никаких выдающихся способностей у них обнаружено не было и ученики были выбраны случайно, однако учителям сообщили обратное. Повторное тестирование в конце года показало, что результаты «одарённых» учеников в среднем улучшились, а показатель IQ увеличился.
Дело в том, что наш мозг с трудом отличает восприятие и ожидание. Социолог Роберт Мёртон описал самосбывающиеся пророчества, к которым относится эффект Пигмалиона, как самогипноз. Имея изначально убеждение о себе или других, мы влияем на действительность и делаем так, что оно становится правдой. Этот психологический феномен позволяет целенаправленно или случайно влиять на реальность.
А что автомобиль?
Решив купить новый автомобиль мы перестроили внутренние фильтры восприятия информации и начали по другому видеть ситуацию - буквально выхватывать из автомобильного потока ту самую марку.
Отсюда есть 2 интересных следствия:
1. Просто формулируя цели — вы уже настраиваете себя.
Сформулировав цель вы получите результат больше, чем если не сформулируете и будете просто «копать-бежать».
Это лучше чем ничего, но точно недостаточно чтобы сделать прорыв.
OKR служит хорошей формулой для формулирования целей.
2. От ожиданий руководителя зависит результат сотрудников.
Руководитель, который думает что его окружают «дэбилы», получит результат сильно хуже, чем тот кто будет верить в своих сотрудников и доверять им. Мои ребята точно способны на большее!
А знаете чей слоган «для способных на большее»? Пишите в комментариях
Неудивительно, что эти ребята сейчас активно внедряют OKR. Это уже становится частью их культуры.
⛵️Без кого не выплывем: 4 ключевые роли в OKR-проекте
Одна из базовых причин, почему так много неудачных внедрений OKR - OKR не рассматривается в компании как проект трансформации.
И если уж компания решает, что помимо красиво сформулированных амбициозных целей им еще нужен результат, мы запускаем настоящий проект и собираем под него команду.
Представьте, что для выполнения сложной миссии нам нужна команда, почти, как на пиратском корабле🏴☠️.
Наш опыт показывает, что есть 4 ключевые роли, без который наш корабль никуда не поплывет.
Итак.
Для успешного внедрения OKR как проекта нам понадобятся следующие роли.
🔶 Лидер проекта внедрения OKR — главный в проекте, это по сути капитан корабля. Обычно эту роль на себя берет кто-то из ТОП-менеджеров. Он напрямую заинтересован в успехе проекта и обладает управленческими компетенциями. Как и любой бывалый капитан, он понимает важность человеческой составляющей в проекте изменений.
Ключевые его задачи:
✅ вовлекать ТОП-менеджеров и других участников проекта;
✅ управлять изменениями;
✅ обеспечивать ресурсами участников проекта.
🔶 OKR-коуч — главный эксперт по OKR. Это тот самый мудрец, обладающий секретными знаниями о сокровищах, без которых команда не реализует проект. Работает на уровне организации и ТОП-менеджеров, а не команды. Обладает обширной практикой и набором инструментов, которые подбирает под конкретную ситуацию, в том числе управления изменениями. Чаще это приглашенный эксперт.
🔶 OKR-мастер работает на уровне команды, а не компании. Он задает ритм, помогает грести в верном направлении через декомпозицию целей и выстраивание регулярного процесса изменений. С его участием команда системно добивается бОльших результатов. И точно доплывет быстрее, чем без него.
🔶 OKR-Strategist отвечает за сборку общего дерева целей по компании. Является экспертом в декомпозиции целей и работе с метриками. Его ценность в том, чтобы помочь компании правильно распределить ресурсы между различными целями и выстроить регулярный процесс мониторинга.
Стали выделять эту роль, когда выяснили, что в компании никто не отвечает за сборку общего дерева целей, каждый за свой кусочек.
У нас уже есть курс для OKR-мастеров. И мы планируем запустить обучение и по другим ролям, чтобы у компаний была возможность собрать полноценную команду и запускать изменения.
Поэтому сейчас я провожу бесплатные интенсивы в закрытом телеграм-чате. Подробности обучения и ссылка на чат в моем телеграм-канале.
Вы показывали хорошие результаты на своей текущей позиции, были активны и хотели роста. Вы были хорошим экспертом и профессионалом.
Поэтому начальство и сделала вас руководителем, чтобы вы могли передать свою экспертизу и опыт новым сотрудникам.
Уже в роли руководителя вы брали самые сложные задачи на себя, как самый большой эксперт в команде.
Ваша экспертная мышца вновь прокачивалась значительное сильнее управленческой, еще очень слабой и не такой развитой.
В период кризисов вы также подключали свою экспертизу и опыт. Решения надо принимать быстро и максимально эффективно. Не до тренировок, дела делать надо.
В итоге в большинстве кризисных ситуациях (а последние лет 5 только такие и есть) вы добивались результата использую сильные экспертные мышцы. У управленческой мышцы даже не было шанса стать настолько же развитой, как экспертная.
Как это изменить?
В организме у нас тоже есть сильные мышцы - агонисты/антагонисты (двигатели), стабилизаторы (фиксируют сустав и корпус) и синергисты (усиливают движение).
Чтобы прокачать стабилизаторы, например, надо выключить основные мышцы с использованием тренажера, чтобы основная нагрузка была именно на те мышцы, которые нам необходимо.
По аналогии для прокачки управленческой мышцы нам необходимо отключить нашу экспертизу.
Как это сделать?
Начать управлять командой, где у вас нет предметной экспертизы.
Так вы автоматически подключите управленческую мышцу, потому что по другому просто не получится достичь результата.
А возвращаясь уже на привычку позицию, ты вдруг понимаешь, что у тебя кроме сильной экспертизы теперь честь и другая действительно сильная экспертиза - управление.
Поэтому в Японии управленцы периодически меняли свои позиции - руководил маркетингом, стал управлять складом или производством.
Это тоже про концентрированно прокачать управленческие компетенции.
Я не предлагаю менять ТОПов местами, есть вариант лучше.
Можно стать OKR-мастером для команды, где у тебя нет экспертизы и помочь ей достичь крутых результатов.
А я пока предлагаю вам перейти в мой телеграм-канал и больше узнать об OKR и лидерстве.
Более 2000 лет назад Сократ придумал концепцию - быть -> делать ->иметь
Суть ее в том, чтобы что-то «иметь», нам необходимо в начале «быть» этим человеком или компанией, потом «делать» (совершать поступки из этого нового состояния) и в результате поступков мы будем иметь то, что хотели.
Прочитайте еще раз. Вызывает ли у вас это сопротивление?
Почему?
Мы же часто хотим в начале что-то иметь, а уже после думаем про все остальное.
Но как можно «быть» в самом начале — спросите вы?
«Я же сначала хочу иметь млн долларов, а уже после этого я могу стать богатым. Наоборот не получится».
Но на самом деле всё не совсем так. Люди, которые выиграли лотерею или в казино, не остаются богатыми надолго.
Как думаете, почему?
Чтобы чего-то достичь, важно внутренне стать/быть таким. Именно этот новый подход изменит ваш способ мышления. Оно изменит действия, и уже это с более высокой вероятностью обеспечит «иметь».
Давайте посмотрим на такую ситуацию:
Есть ли для вас разница между - быть «отцом» и иметь детей?
Для одних разницы не будет. Это нормально 🙂
Но другие скажут что разница огромна — можно иметь детей и не быть отцом, а можно быть отцом, не имея детей.
Быть отцом — это цель, сформированная формате бытия (состояния).
Иметь детей — цель в виде действия (изменения).
А при чем тут OKR?
Когда мы только формировали с Татьяна Винтерголлер первый курс по OKR 3 года назад, то отметили , что есть цели-состояния, а есть цели-изменения. И долго обсуждали, стоит ли так усложнять на курсе. В результате первого прогона отказались.
И только в этом году я понял, в чем их отличия.
Формируя цель в формате состояния (каким я/компания хочу быть?), вы создаете целый набор вариантов, какие для этого необходимы изменения (цели-изменения) и, таким образом, создаете для себя целое пространство вариантов.
Если же вы фокусируетесь на целях-изменениях, то часть вариантов можно упустить.
Что важно — выбирайте тот вариант, который для вас комфортен на данном этапе. Если вы формируете цели от изменений, вы уже получаете преимущество перед 95% других, в следующем году сможете сделать следующих шаг 🙂
А как вы формируете цели и какой подход ближе? Поделитесь в комментариях.
P.S. Это пост-пояснение к публикации “В поисках идеальной формулы OKR”.
В интернете можно найти чек-листы для проверки качества OKR — вдохновляющие, конкретные, измеримые.
Мне не нравится, что в этом случае форме уделяется больше внимания, чем содержанию. На практике все несколько по-другому: мало ценности бывает в переформировании цели из обычной в амбициозную, если это не продвигает команду.
Но вопрос остается: как выглядит идеальная формула OKR?
В определении Цели важно:
1. глагол;
2. объект изменений;
3. качество, которое приобретает объект в процессе изменений.
И что-то это мне все время напоминало, аж до зуда. 🤔
А ведь есть формула составления работ в JTBD - «глагол + существительное + контекст». Можно ли ее применить и тут?
Стал изучать, и оказалось еще интереснее:
Теорию JTBD активно разрабатывали 2 человека - Энтони Ульвик и Алан Клемент.
Ульвик говорил, что работа это « job-activities» - «do goals» - работы - действия (пример: построить дом).
А в это же время Клемент доказывал: работа — это что-то ценностное - «be goals» - работа как состояние или бытие (пример: быть хорошим отцом).
Много копий было в свое время сломано при обсуждении, какой подход лучше, а на самом деле они отлично дополняют друг друга по аналогии с целями-состояний и целями изменений.
Таким образом, для формулирования Objective можно использовать формулу «глагол + существительное + контекст качество» (прилагательное или изменение).
Ключевые результаты должны в полной мере описывать качество. Если качеств несколько, то для каждого должна быть своя метрика.
Например, вы сформулировали цель - «Стать умным, красивым и сильным», то для каждого качества нужная своя метрика :)
Вспомнилась фраза по итогу всей этой темы - бог один, провайдеры разные.
Попробуйте формулировать OKR в таком варианте и поделитесь результатам, плз :)
Чтобы достигать ДРУГИХ результатов нужно действовать по-другому, а в начале думать по-другому.
Новый результат ⬅️ новый способ действия ⬅️ новый способ мышления.
А для этого очень много нужно вкладываться в развитие команды и конкретных людей.
И вот тут есть проблема - 90% предпринимателей не хотят заниматься развитием команды.
Люди это сложно, долго и еще ненадежно. Только научишь, а они и уйти могут.
Вот бы как-то решить эту задачу, но чужими руками.
И мы научились это делать!
Когда мы запускаем OKR в компании, то обязательно вводим своих OKR-мастеров.
Их задача - научить команду действовать по-другому, максимально эффективно выстроив процесс достижения целей. А уже через достижение целей трансформировать мышление.
❗ В результате команда начинает кратно быстрее бежать (есть кейсы когда за 3 месяца получили результат больше, чем за предыдущие 9 месяцев). Также она забирает ответственность за достижение цели и изменения, которые для этого необходимо реализовать.
По итогу мы и получаем тех самых лидеров, которым нужна поддержка, а все остальное они могут и сами.
Лайфхаком является то, что при запуске OKR мы готовим в компании внутренних OKR-мастеров, которые начинают уже сами вести команды изменений дальше.
В рамках этой роли он работает с командой - 1-2 часа в неделю, что позволяет ему эффективно выполнять и свои основные функции.
При этом он помогает команде достигать целей, и прокачивает свою модель горизонтального лидерства. Это когда у тебя нет прямой власти над командой, но ее все равно нужно научиться направлять и даже управлять.
Вот и получается что мы получаем в 2 раза больше лидеров:
1. Те кто умеют достигать целей с командой.
2. Те кто умеют выстраивать процесс команды так, чтобы она достигала целей.
«Дай человеку рыбу, и он будет сыт один день. Научи человека ловить рыбу, и ты накормишь его на всю жизнь».
