Управление разработкой *

Мой код, мой кофе, мой хаос

Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными

Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.

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

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

Разрешение конфликта

Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.

В итоге мы остановились на одной из либ, но не это важно. Главное, что разрешился конфликт между двумя сотрудниками на почве выбора технологий. А часто бывает и по-другому, что никто не хочет уступать и каждый топит за свой алгоритм/либу в проекте.

В таких случаях я обычно:

• Развожу спорщиков по разным проектам

• Или принимаю сам решение какую технологию использовать далее

В обоих случаях после конфликта может упасть мотивация, могут затаиться обиды и т.д.

Мотивация-шмотивация

Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:

1. Деньги-деньги, решают многое. Сюда же незапланированные премии.

2. Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.

3. Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).

4. Про лишние дни отдыха тоже понятно.

5. Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.

6. Признание заслуг в разработке проекта перед вышестоящим начальством и текущей командой. Хотя это должно быть по умолчанию в команде.

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

Конфликты между коллегами в команде – это не трагедия, а возможность для экспериментов и роста. Выслушать каждого, дать шанс доказать свою точку зрения на практике и подкрепить это мотивацией – именно так конфликт становится точкой роста.

Если есть чем поделиться, как вас мотивировали - прошу в комментарии.

Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО

Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.

Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:

1.      Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года

2.      Содержание ГОСТ Р 56939-2024 и его структура

3.      Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024

4.      Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024

5.      ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки

Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.

Приглашаю смотреть уже записанные встречи и участвовать в новых: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.

SLI, SLO, SLA — как разобраться в метриках?

В новом выпуске AviСast обсуждаем:

• чем отличаются SLI, SLO и SLA и как их правильно применять?

• когда компании осознают необходимость этих метрик и как их встраивать в процессы?

• как оценить критичность сервисов и доказать бизнесу ценность SLO/SLA?

В теме помогут разобраться Паша Лакосников, руководитель юнита ArchGovernance в Авито, Дима Синявский, SRE-инженер в Ви.Tech, и Кирилл Юрков, Observability and Reliability Engineering Manager в ecom.tech.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Интеграция PVS-Studio c AppSecHub

Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.

Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.

Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.

Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.

Как мы в Страховом Доме ВСК внедряем ИИ: спецпроект System Analysis & AI Talks
AI-запросы, Kafka, автоматизация и даже вайб-кодинг — всё это не сюжет киберпанк-романа, а реальный спецпроект IT VSK — System Analysis & AI Talks, который мы недавно провели в Страховом Доме ВСК.

Этот проект родился из простой, но важной идеи: системный анализ — это не скучно, особенно когда в дело вступает нейросеть. И когда в одной комнате собираются системные аналитики, разработчики и эксперты по ИИ, разговор получается горячим. А мы не просто поговорили, мы показали, как всё это работает на практике в рамках корпоративных ИТ-систем.

System Analysis & AI Talks: немного про магию
В рамках AI Talks мы разобрали реальное применение LLM в деятельности системного аналитика — не на уровне «что может ИИ», а с погружением:

• Что такое LLM в контексте продуктовой разработки;

• Как выполнять базовые операции и избегать ошибок в промт-дизайне;

• Как тюнинговать промты под конкретные бизнес-задачи;

• Как встраивать нейросети в ежедневную практику.

Особый интерес вызвал наш блок «Открытый микрофон», где участники делились собственным опытом: от подсказок к составлению бизнес-требований до генерации тест-кейсов в один клик.

TechDay: ИИ-киборги, вайб-кодинг и Kafka на грани
Вторая часть ИИ-марафона прошла под флагом нашего флагманского проекта TechDay по искусственному интеллекту. Делимся тремя самыми горячими темами:

AI-киборги: минус разработчик или плюс вайб?

Где грань между помощником и угрозой?
На этой сессии мы:

• Подключали ИИ к IDE прямо на глазах у публики

• Показывали, как правильно и этично использовать помощников, не превращая их в «копипасту из ада»

• Про наш эксперимент с N8N + ИИ: рассказали коллегам про новые возможности в Страховом Доме ВСК.

Вайб-кодинг: как писать сервисы, не трогая клавиатуру?

Здесь мы раскрыли необычную тему: разработка типового сервиса без ручного программирования. Сравнили: кодить по классике, с low-code, с помощью ИИ — где удобнее, где быстрее, а где надёжнее. В финале показали, как собрать прототип за полчаса, даже если вы не fullstack-разработчик.

Kafka без боли: как не утопить прод
Завершили встречу рассказом о самых критичных ошибках при работе с Kafka, которые мы реально встречали в проектах:

• Как не перегрузить сеть и диск, когда вы рассылаете сотни тысяч сообщений;

• Почему архитектура решает (и как её не сломать с первого коммита);

• И где границы между гибкостью и хаосом в распределённых системах;

• Что за этим всем стоит?

Спецпроект System Analysis & AI Talks стал частью нашей инициативы по созданию открытого инженерного сообщества внутри Страхового Дома ВСК.

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

P.S. Если вы в своей компании делаете что-то похожее — поделитесь, нам правда интересно! Следите за публикациями в блоге — будет много нового: и про Kafka, и про промты, и про реальные грабли с ИИ в проде.

Про сотрудника Игоря, или про того, кто ни в чем никогда не виноват

Работал у меня в компании лет 5 сотрудник, назовем его Игорь. И странное дело, он всегда был ни в чем не виноват. Что бы ни происходило, но он не виноват по определению.

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

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

Причём если ошибка была в коде, который он написал. Игорь каким-то волшебным образом умудрялся всегда находить слова типа: «А вот помнишь, ты мне говорил вот это сделать, я так и сделал, и вот в результате появилась ошибка». Иногда доходило до смешного: на форме при разработке были какие-то орфографические ошибки, и он начинал юлить. )) Мне в какой-то момент даже стало интересно, а в принципе он может сказать: «Я сделал здесь ошибку». И знаете что? За 5 лет работы с ним я так и не добился такого признания.

Что еще было: был сон на рабочем месте в рабочее время, несколько жестких будунищ после выходных, и в таких случаях я всегда его отправлял домой, потому что толку от такого сотрудника нет никакого (это другая история). Но нет. Он никогда не виноват. )))

Минутка рефлексии и мои рассуждения по поводу таких сотрудников:

1. Сотрудник, не берущий на себя ответственность, обходится компании дороже, чем кажется. Его реальная стоимость — это не только его зарплата, но и десятки часов моего времени как руководителя, потраченные на микроменеджмент и исправление последствий и принятие решений там, где это должен был сделать он. Я, как руководитель, хочу платить деньги профессионалу, а не маленькому ребенку.

2. На собеседовании нужно всегда задавать вопрос об ошибках. Простой вопрос «Расскажите о своей самой серьезной ошибке и что вы сделали, чтобы ее исправить?» мгновенно выявляет «Игорей». Они либо не могут вспомнить ни одной ошибки, либо рассказывают историю, где виноваты были обстоятельства или коллеги. Так не бывает в реальной жизни. Мы все ошибаемся и это нужно уметь признавать.

3. Нужно вовремя принимать решение об увольнении. Моя ошибка была в том, что я держал Игоря 5 лет в надежде, что он изменится. Люди меняются крайне редко. Моя задача как руководителя — не быть психотерапевтом, а собирать эффективную команду. Я затянул с этим решением, и это стоило компании и денег, и нервов.

Такие дела…

А у вас в практике был такой коллега — Игорь, который никогда не берет на себя ответственность и пытается ее спихнуть на другого человека?

Больше полезной информации про ИТ-управление, спорные вопросы в найме, менеджменте и планировании — в блоге Код ИТ-директора в Telegram, VK, Дзен, Instagram*, FB*. Подпишитесь, чтобы не пропустить новые тексты!

_{*Признаны экстремистскими организациями и запрещены на территории РФ.}

— Слушай, я посмотрел у Тинькоффа — у них такие крутые анимации. Давайте и нам такие сделаем!

— Ну, у нас не финтех, мобильного приложения нет, и вообще — у нас CRM для логистов…

— Ну и что? Люди любят, когда красиво! Сделаем плавные графики, чтобы всё оживало. UX, UI, ты же понимаешь!

— У нас при этом не работают фильтры, отчёты формируются вручную, и у клиента падает система при импорте Excel. Может, сначала это починим?

— Ладно… Только кнопки тогда сделай с закруглениями, как в Тинькоффе. Хоть что-то красивое будет.

Выглядит лучше. Работает — так же плохо.

Потому что копировать обёртку, когда продукт внутри разваливается — это мёртворождение дизайна.

Вдохновение — не преступление.

Но копирование без понимания контекста — худший выбор.

У Тинькоффа и команда дизайнеров, и исследования юзабилити, и огромный бюджет, и полгода на rollout.

Сначала надо решить боль клиента, а не украсить страдание. Сделай стабильный функционал, и только потом — красивый. Иначе копирование по цене тех долга выйдет.

Оффтоп
Читайте больше у меня в профиле и в Telegram канале

Flipper Devices показала видео с примерами использования Busy Bar — продвинутого таймера фокусировки для гиков.

«Большой роскошный обзор тестового образца BUSY Bar. В середине есть примеры работы с API и виртуальной сетью», — пояснили разработчики проекта.

Представлен открытый репозиторий с коллекцией гайдов по почти всем стекам технологий — от операционных систем и языков программирования до паттернов проектирования и принципов дизайна. Все гайды сжаты и структурированы, включая популярные языки программирования — Python, Java, Go, JS, Rust, всё об инструментах, редакторах кода и IDE, а также шпаргалки по горячим клавишам, библиотеки и фреймворки для работы.

1000 человек уже тестируют новую бесплатную CRM

Простой и бесплатной CRM не существует? Похоже, теперь такая уже есть!

Мы запустили в открытое тестирование первую версию CRM внутри YouGile. Она доступна всем без исключения пользователям бесплатно. Смотрите подробнее о ее возможностях:

А для команд до 10 человек вся система управления проектами YouGile бесплатна навсегда без каких-либо ограничений.

Автоматическое добавление номера задачи в коммит

Привет, Хабр! 👋
Хочу поделиться небольшой, но полезной фичей, которая упростила мне жизнь при оформлении коммитов.

В своей работе я придерживаюсь структурированного подхода к именованию веток и сообщений коммитов. Подробнее об этом можно почитать здесь:
📎 https://habr.com/ru/articles/820547/

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

Почему это удобно?

Указание номера задачи позволяет быстро понять, какие именно тикеты попадают в релиз. Особенно это помогает при ревью и при деплое.

Пример структуры ветки:

feat/dev-123_filter или fix/dev-432_filter

Сообщения коммитов я пишу в следующем формате:

dev-123 | настроил сортировку в фильтре

Чтобы не вставлять руками номер задачи каждый раз, я написал небольшой shell-скрипт, который делает это автоматически.

Скрипт prepare-commit-msg

#!/bin/sh

COMMIT_MSG_FILE=".git/COMMIT_EDITMSG"
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)

if echo "$BRANCH_NAME" | grep -qE 'dev-[0-9]+'; then
  TASK_ID=$(echo "$BRANCH_NAME" | grep -oE 'dev-[0-9]+')

  if ! grep -q "$TASK_ID" "$COMMIT_MSG_FILE"; then
    sed -i.bak "1s/^/$TASK_ID | /" "$COMMIT_MSG_FILE"
    rm -f "$COMMIT_MSG_FILE.bak"
  fi
fi

Скрипт нужно сохранить как .git/hooks/prepare-commit-msg и сделать исполняемым:

chmod +x .git/hooks/prepare-commit-msg

Как это работает?

• COMMIT_MSG_FILE — путь до файла, в который Git записывает текст коммита.

• BRANCH_NAME — название текущей ветки.

• Сначала проверяется, есть ли в названии ветки номер задачи (dev-123).

• Если он найден и ещё не указан в коммите — скрипт добавляет его в начало первой строки сообщения.

Таким образом, ваш коммит автоматически будет выглядеть так:

dev-123 | добавил пагинацию в список товаров

Вроде мелочь, а приятно — экономит время и упрощает навигацию по истории коммитов.

Если будет интересно — это и другие полезные скрипты, на моём GitHub

https://github.com/prog-time

Спасибо за внимание! ✌️

Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.

К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".

Накидали, и что дальше?

За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.

Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".

Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.

На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.

В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.

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

Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"

Чек-лист: твой проект скоро развалится, если…

Небольшой технический чек, который стоит пройти каждому, кто ведёт продукт или отвечает за разработку.
Если узнаете себя — возможно, пора не спешить с новой фичей, а разложить фундамент.

• Весь проект держится на одном человеке
  И он — не документация. Ушёл в отпуск — проект замер.

• Задачи ставятся в личке, на встрече или в голове
  "Я же в телеге писал задачу". Без трекинга всё разваливается.

• Никто не может объяснить, что по приоритету
  Всё срочно, всё горит, всё одновременно. Ну вы поняли.

• Прод выкатывается вручную, или в пятницу вечером
  Даже не баг, а фича. Проблемы по подписке.

• Тестов нет, баги ловим по фидбеку
  Багрепорт от клиента — это не QA.

• Архитектура — это слово из чужого лексикона
  Потому что “нам и так норм”. До первой перегрузки.

• Вопросы “а как это работает?” решаются методом тыка
  Потому что комментировать код — западло.

• Бэкапы где-то есть… но никто не проверял
  Олег говорил, что сохранял себе дамп локально

• Ушёл один человек — и половина знаний ушла с ним
  Значит, их не было в проекте — только в его голове.

Если вы загнули 3–4 пальца — значит пора встать и осмотреться.
Пока “всё работает” — это ещё не стабильность, это просто везение.

Некоторые проблемы уже рассмотрел подробнее в своих статьях

Фича ради фичи

Как легко потерять смысл разработки, добавляя “полезности”

• Сделаем ещё кнопку, она “точно нужна”

• Добавим фильтр, и сортировку, и модалку, ну мало ли

• Вот бы выгрузку в Excel, и график, и пуши!

…Проект набирает скорость. Только куда?

В чём проблема?
Когда цель — просто сделать больше фичей, а не решить конкретную задачу, продукт начинает разваливаться: интерфейс пухнет, команда тонет в «хотелках», релизы идут в спешке, а люди - даже не замечают большинство этих «удобств»

Парадокс: чем больше фич, тем хуже продукт

Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.

У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»

Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.

Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги.
Людям не нужно «все и сразу», им нужна качественная точечная фича

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.

Человек-комбайн

Почему зависимость от одного специалиста может утопить всю команду. Выглядит как супергерой. На деле — одиночка, от которого зависит всё.

Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.

Первый этап

Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.

Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».

Второй этап

Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.

Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.

Третий этап

Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…

Судный день

Без него — никто не знает, как деплоить, где что лежит, как починить баг.

Документации нет, у разработчиков паника.

Прод падает. Клиенты жалуются. Команда — в ступоре.

Восстановление занимает недели. А иногда — проект просто не поднимается.

Как не угодить в ловушку?

Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.

Коромысло с одним ведром — всегда перевесит в одну сторону.

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.

🛠 День 10: Разработка полным ходом.

Хочу поделиться прогрессом по нашему новому продукту, постарался тезисно собрать все что есть на данный момент:

📱 Мобильная версия

• Полнофункциональный интерфейс на телефоне- Можно создавать формы и просматривать ответы прямо с телефона

🔧 Конструктор форм

• Drag & Drop

• Автосохранение

• Заголовки (title, description)

• Брендинг: обложка, логотип (картинка, текст или эмодзи)

• 20+ типов полей: текст, email, телефон, рейтинги, файлы, дата, время

• Бизнес-поля: ИНН, ОГРН, КПП, БИК, СНИЛС, паспорт - с валидацией и проверкой хеша

• Рейтинги: 1-5 звёзд, 1-10

🌐 Переводы

• Уже есть RU / EN- Скоро сделаем ещё 48 языков

🗂 Папки и доступы

Папки с правами доступа - удобно делиться с командой

Уровни доступа:

• Владелец - полный контроль

• Администратор - всё, кроме удаления папки

• Редактор - формы и ответы

• Редактор форм - только формы

• Оператор - только просмотр/обновление ответов

• Платежи - доступ только к платежам

📋 Управление формами

• Поиск, фильтрация, сортировка

• Дублирование и удаление

• Шаблоны

🔗 Публикация

• Короткие ссылки (/f/abc1234)

• QR-коды

• Виджет для встраивания в сайт (iframe)

• SEO-метатеги

• Превью формы в соцсетях (OG, Twitter) с картинкой

• SSR-рендеринг форм

📊 Ответы и аналитика

• Фильтрация по дате, форме, IP

• Экспорт ответов в CSV

📎 Файлы

• Поддержка 20+ форматов

• Превью: изображения, PDF, CSV, текст и др.

Карма vs Инженерная честность: Почему рейтинги убивают экспертизу

Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.

Социальная инженерия вместо экспертной оценки

Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:

Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").

Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.

Карма как инструмент подавления инакомыслия

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

Итог:
Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят.
Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли.
Платформа медленно превращается в клуб взаимного одобрения.

Что делать?

1. Игнорировать карму как погрешность системы (но тогда зачем она?).

2. Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".

3. Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.

Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.

P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.

Как QA и DEV могут эффективно работать вместе, а не играть в бесконечный пинг-понг с передачей фичи на тестирование и багов туда-обратно?

Об этом Лена Федорова, QA Garage Eight, рассказала на своей лекции «Мир, дружба, тестирование» на QA митапе в офисе Garage Eight. Она поделилась кейсом своей команды по внедрению совместного тестирования и тем, какие результаты оно дало.

Смотри лекцию и узнаешь:
> что такое «совместное тестирование»?
> какие у него преимущества и недостатки;
> каким командам подойдет этот подход;
> как измерить успех.

YouTube | VK Видео

Как развернуть среду разработки и сервис управления проектами в облаке?

Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.

• В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.

• Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini^®.

• За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.

Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.

Что ждет участников Ural Digital Weekend 2025?

1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.

В 2025 году на конференции выступят спикеры из Альфа-Банк, Т-Банк, Яндекс, Avito.Tech, Ozon.tech, Битрикс24, SM Lab, Cloud.ru, Островок!, Столото, Scrum.ru, +7 pay, «Девелоника» (ГК Softline), Kokoc.tech, .redev, arcsinus, ARTW, ITECH, Terabit, Лидеры Изменений, Викенд в IT, CreativePeople, Luntry, Юникорн (Ujin), Деврел-бюро, MediaSoft, Product Vision, Partner’s Club, Тэглайн / agency2agency, Spectr и множества других известных компаний.

Программа конференции будет разделена на 3 секции: «Разработка», «Управление разработкой» и «Управление бизнесом». 

Полная программа и детали в нашем материале на Habr: https://habr.com/ru/articles/919802/