Расскажем, как на наш взгляд не стоит писать функциональные требования для Технического Задания.
Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.
Итак, что точно не нужно делать.
Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.
Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".
В российских проектах НСИ часто выходит далеко за рамки справочников и включает задачи MDM и Data Quality. Разбираемся, чем это отличается от классического RDM и к чему это приводит.
Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.
Индустрия разработки ПО прошла долгий путь, ее бросало из крайности в крайность. Мы отказались от многостраничных технических заданий, перейдя к устным обсуждениям. Потом обсуждений стало слишком много, а системы слишком сложными, чтобы можно было описать их с помощью стикеров на доске. И мы перешли на гибридные процессы: с зоопарком инструментов и форматов описания требований, размытыми ролями и архитектурой, где паттерны перемешаны в произвольных пропорциях.
Неизменно было только одно – основную ценность представляет код. Код – это истина в последней инстанции. Требования, архитектура, тест-кейсы — не более чем черновики, наброски, которые могут быть уничтожены сразу после начала «настоящей работы» – написания кода.
Но что, если я скажу, что сейчас происходит тихая контрреволюция? Индустрия устала от неопределенности. Когда код — единственная истина, система превращается в «черный ящик». Понять, как она работает фактически, можно только прочитав тысячи строк кода.
Код идеально отвечает на вопрос «как?», но в нем нет ответа на вопросы «зачем?», «для кого?», «почему?». Без знания ответов на эти вопросы, любая доработка — это гадание на кофейной гуще.
В этой статье проследим эволюцию: от Водопада к Agile, от Agile к Гибридам и Everything as Code.
Привет, Хабр!
В прошлой статье мы заглянули под капот ClickHouse и разобрались, как работает движок MergeTree. Мы узнали, как хранятся данные и что такое парт, зачем нужен разреженный индекс и как работает фоновое слияние.
В этой статье мы рассмотрим один из мощнейших инструментов ClickHouse — Materialized View.
Все новости, особенно те, которые основаны на данных нужно обязательно критически переосмыслять, часто данные правдивые, но показаны так, что скрывают проблему или недоговаривают о негативных динамиках.
Хочу рассказать как самому не попасться в эту ловушку и как неосознанно не создавать подобные датавизуализации, которые могут вводить читателей в заблуждение. Все антипримеры я брала из личного рабочего опыта или из реальных примеров, которые каждый день вижу в различных статьях и примерах.
Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». В 2025 году мы столкнулись с частым запросом: бизнес хочет внедрить отечественную BI‑систему, при этом бюджет плюс‑минус 1,5 млн рублей. Мы решили изучить рынок и найти подходящее ПО, а заодно рассказать тем, кто тоже подбирает продукт, о результатах нашего исследования. В первом обзоре — PolyAnalyst. Подробно разбираю архитектуру, компоненты, источники данных, ETL‑пайплайны, визуализацию и так далее
Массовое внедрение AI в работу менеджмента и экспертов формирует пузырь, который удивительно точно повторяет механику ипотечного кризиса 2008 года. Парадокс в том, что формируется он на самом видном месте. Эксперты, инвесторы, акционеры — все пристально смотрят в документацию компании (или института). Но качество документа не гарантируют качества экспертной информации, которая должна была отражаться конечным артефактом. Документ может быть "токсичным": логично выглядеть, но содержать ошибки, противоречия и «галлюцинации» AI.
“Документы не должны противоречить друг другу” как отдельного требования нет, но оно кажется очевидным из ISO 9001, ITIL и BPM.
Небольшие заметки о разработке CRM‑системы по продаже объектов недвижимости.
По причине того что после 8-летнего хардкодинга рандомными людьми, код предыдущей CRM пришел в состояние квантовой запутанности, потребовалось срочно разработать новую CRM.
Собственно, по ходу составления технического задания, становилось понятно, почему все предприятия со сколько‑нибудь сложным продуктом или бизнес‑процессами, идут в свою разработку.
И первое (Продукт), и второе (Процессы) накладывает фундаментальные требования к модели данных, формируя каркас бизнес‑логики.
Какие вопросы должен задать себе CEO, СД, руководитель C-уровня перед тем, как внедрить в своем бизнесе AI-агентов?
Нередко к внедрению AI-агентов подходят как к покупке очередного софта. Или даже как к модному хайпу («все внедряют, значит и нам нужно»). В итоге можно получить «дорогую игрушку», которая вместо прибыли и оптимизации принесет разочарование и лишние затраты. А в качестве «бонуса» - конфликты между ключевыми департаментами, например коммерческим и техническим, по поводу бюджетов или ответственности за успех / неудачу внедрения. При этом если уже сейчас не начать усиление бизнеса AI – агентами, то есть риск потери конкурентоспособности. Иными словами, грамотная AI стратегия нужна уже вчера
Вместе с Алексеем Федоровым, - экспертом по стратегиям роста и развитию продаж в IT" и автором ТГ канала @growthinIT, мы обсудили 10 честных и жестких вопросов, на которые нужно ответить перед тем, как взяться за внедрения AI-агентов.
История разработки ИИ-агента для автоматизации проектирования в low-code. О том, как мы споткнулись о контекст, поругались с Qwen, победили "зависающий" Mermaid и поняли, что без проверки агенты врут.
У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:
• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя
В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.
В 1957 году писатель-фантаст Роберт Хайнлайн так представлял себе людей XXI века: «Делала перерасчет прочности гидропонических оранжерей, но выходило с ошибками. Дважды забывала логарифмы, так что пришлось лезть в таблицу».
Однако наша цивилизация выбрала другую ветку развития — и в нашей версии XXI века все за человека делают машины: от сложения двузначных чисел до написания статей на Хабре. Считать в уме, а уж тем более помнить наизусть логарифмы — звучит, как не самая востребованная сверхспособность.
Зато, чтобы обрести эту сверхспособность, не требуются укусы радиоактивных пауков — достаточно просто прочитать эту статью, а уж пригодится ли в жизни — решайте сами. Может быть в нужный момент калькулятора под рукой не окажется, а может быть просто захочется произвести впечатление на коллег небрежно брошенной фразой: «Корень седьмой степени из пяти это примерно 1,25». Хотите научится быстро считать? Тогда добро пожаловать под кат!
Самые интересные новости финансов и технологий в России и мире за неделю: Palantir представил концепцию Warfare as a Service, москвичам отрубили мобильный интернет, Сбер и Яндекс просят о господдержке для ИИ, Дуров обеднел в несколько раз, релиз GPT-5.4, а также окончательный деанон Бэнкси.
Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора».
На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.
В этом цикле будут разобраны три фатальные ловушки, в которые попадают компании, и главное — предложены пошаговые рецепты спасения, основанные на реальной практике и современных методологиях.
Всем привет! Меня зовут Наташа, и я системный аналитик. Сейчас я в поиске работы, сходила на пару собеседований, и хочу описать ответы на некоторые вопросы, которые там встречались - некая рефлексия для меня, и надеюсь, эти короткие статьи будут полезны и еще кому-то.
Многие думают, что достаточно пройти курс по Pandas и ты готов к работе, а потом сталкиваются с реальными задачами и не знают что им делать.
В статье разобрала по полочкам:
• Что реально нужно знать про Python до того, как лезть в датафреймы
• 20+ методов Pandas, которые покроют 80% задач
• Какие графики и чем рисовать
• Библиотеки для статистики и SQL – минимум, но необходимый
Без воды, списками и примерами.
Всем привет. Меня зовут Никита, я руковожу командой Цикл‑ОН. Мы уже более 5 лет ведем проекты по заказной разработке ПО и, как и многие, сталкиваемся с необходимостью разработки не только качественного кода, но и документацию на продукты. В нашей нише особенность, что заказчики живут в парадигме ГОСТа. Я бы здесь хотел оставить небольшую заметку о нашем опыте — как то, что для начаиналось как откровенное мучение превратилось сначала в умную идеологию, а по итогу в самостоятельное решение для подготовки документации.
В данной статье-тренажёре мы подготовили 25 заданий на составление BPMN-модели процесса кредитования в ДБО. К каждому заданию мы подготовили рекомендации по его выполнению, а также под спойлерами спрятали наше решение и его объяснение. Возможно, наше понимание и исполнение может отличаться от того, к которому придёте вы — мы будем рады подискутировать в комментариях.
В конце статьи мы приложили файл цельной диаграммы всех процессов и полный текст в формате .pdf для скачивания, чтобы можно было потренироваться, поискать собственное решение и подробнее ознакомиться с нашим в любое удобное время.