#тз — Public Fediverse posts

Вот вам техническое задание — сделайте правильно.
Если будет неправильно — у меня для вас будут плохие новости.
Только вы не поймёте.

#тз #юмор #TwoZeroTwoFour

Почему агентный SDD ломается между микросервисами?

Каждая команда описала свой сервис, каждый агент точно выполнил локальную спецификацию, все контракты прошли проверку — а сквозной процесс всё равно развалился. Проблема не обязательно в коде: часто у системы нет общего контекста, владельца инвариантов и правил частичного отказа.

https://habr.com/ru/articles/1066242/

#SDD #микросервис #агент #AI #AIагент #API #Документация #Требования #ТЗ

Когда исчезает ROI из коммерческих проектов автоматизации

За последний год на пресейлах я всё чаще слышу одни и те же фразы: «Дорого!», «За что такие деньги?», «С такой автоматизацией мы без штанов останемся». И это не торг за бюджет. За этими фразами стоит жесткий вопрос: какой экономический эффект покупает заказчик? Найти, куда исчез ROI

https://habr.com/ru/articles/1049494/

#автоматизация #управление_проектами #ROI #бизнесэффект #ТЗ #скоуп #управление_требованиями #бизнеспроцессы #цифровая_трансформация #окупаемость

Как я Zabbix с LLM дружил в свободное время. Архитектурный обзор взаимодействия с нейросетью. Часть 1 «При чем тут ТЗ»

Это первая статья из цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна. В теории хотелось простого: система принимает события мониторинга, понимает их контекст, не дергает лишний раз по пустякам и подсказывает, куда смотреть в первую очередь. Но на практике необходимо начинать не с модели, не с кода и даже не с Docker Compose, а с нормального ТЗ. В процессе написания материал разросся до неимоверных размеров, поэтому пришлось поделить его аж на четыре части. Ссылки буду добавлять по мере выпуска (примерно раз в одну-две недели). Часть 1: Вводная и формирование ТЗ -> вы здесь Часть 2: Выбор локальной LLM Часть 3: Формирование HLD и немного LLD Часть 4: Что из этого вышло

https://habr.com/ru/articles/1031140/

#zabbix #llm #aiops #мониторинг #алерты #тз #itинфраструктура #rca

ТЗ за 30 минут: как быстро погружаться в новый проект без потери качества

Обычно аналитик долго пишет ТЗ, когда пытается делать три вещи одновременно: понять задачу, спроектировать решение и оформить это всё в документ. Это как сервировать праздничный стол, не решив, что будете готовить, и параллельно искать рецепт в интернете. В голове разные интеллектуальные процессы смешиваются в одну кучу и возникает ступор. На связи Ольга, бизнес-аналитик в Outlines Tech. Расскажу, как я погружаюсь в новую задачу, чтобы составить техническое задание за 30 минут. По моей методике 80% работы над ТЗ — понять и договориться, 20% — зафиксировать всё в документ. Так не придётся торопиться и придумывать текст с нуля или вносить правки на ходу.

https://habr.com/ru/companies/outlines_tech/articles/1029748/

#техническое_задание #тз #аналитик #оформление_документов #бизнесаналитик #общение_с_клиентом #согласование_требований #как_аналитику_писать_тз #как_аналитику_быстро_написать_тз #outlines_tech

Как проектировать интеграции с Kafka

Привет, Хабр! Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах» Этой статьёй я бы хотела начать серию материалов для аналитиков и разработчиков, которые только начинают свой путь в ИТ. Когда-то я сама жестко плавала в бульоне ИТ-терминов, а также тыкалась по разным сайтам в поисках подходящей информации, как слепой котенок, без возможности соединить воедино полученные данные таким образом, чтобы моих интеллектуальных ресурсов хватило для написания ТЗ. Толковых гайдов и памяток я не находила, в основном попадалась или сухая теория, или жидкая вода. Поднабравшись немного опыта, я решила составить серию памяток, где буду расписывать ключевые вопросы, которые помогут начинающим специалистам разобраться, как писать ТЗ по интеграциям. Если вам прилетала задачка, в рамках которой необходимо продумать, как Kafka будет взаимодействовать с вашей системой, но вы не особо знакомы с этой платформой, то моя памятка — как раз для такого случая.

https://habr.com/ru/companies/ingos_it/articles/1015314/

#кафка #apache_kafka #kafka #тз #тз_разработчикам #интеграция #интеграции #интеграции_сервисов #интеграции_с_it_системами #системный_анализ

А что на входе? Разбираем структуру данных для AI-агента

После прошлой статьи мне в личку прилетел вопрос: «А что на входе? Как именно ты подаёшь данные агенту? Просто кидаешь текст ТЗ — и всё?» Отвечаю сразу — вот он, паспорт требования, с которым работает мой агент:

https://habr.com/ru/articles/1007056/

#1с #ТЗ #aiагенты #llmмодели #rag

Как я создавала AI-агента для проверки ТЗ: история одного эксперимента

Это не туториал и не истина в последней инстанции. Я просто делюсь своим опытом — как у меня родилась идея и как я её воплощала. Возможно, кому-то это поможет не наступать на те же грабли или подтолкнёт к собственным экспериментам.

https://habr.com/ru/articles/1006372/

#1С #ТЗ #AIагенты #LLM #RAG

Техническое задание – что это и для кого

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием. Необходимость разработки формального документа со спецификацией требований, когда продукт делается не собственными силами для собственного потребления, а выделяются заказчик и исполнитель, очевидна. Особенно, если речь идёт о достаточно сложном продукте, не являющимся типовым решением. Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ. Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»). Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

https://habr.com/ru/articles/1004302/

#ТЗ #техническое_задание #управление_проектами #управление_разработкой_продукта #управление_разработкой_ис #управление_разработкой_по #управление_разработкой

Почему безупречный код — это ноль, если бухгалтер не нашел кнопку «сохранить»

Вам наверняка попадался тот самый мем: «Как видит проект заказчик / как видит разработчик / как видит пользователь». Так вот, я — тот парень, который рисует четвертую картинку: «Как это должно работать на самом деле» и «как сделать продукт, который устроит всех». Меня зовут Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила: — Не бойся ошибаться, бойся ошибаться медленно. Чем раньше ты получишь фидбэк от реального пользователя, тем дешевле и быстрее все исправишь. — Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. Сегодня я расскажу, как, принимая ошибки и выстраивая коммуникацию, можно создать продукт, который будут реально использовать и рекомендовать другим.

https://habr.com/ru/companies/ru_mts/articles/972764/

#Data_Presales #Управление_проектами #Прототипирование #Коммуникация #ТЗ #Оценка_рисков #Бюджет #Пользовательский_фидбэк #B2B

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

Рассмотрим практический разбор слабых мест в технических заданиях на разработку систем, сервисов и т.д. Идеальное ТЗ — утопия, но многие болезненные моменты и конфликты на стадии приемки можно предсказать и минимизировать. Часто они возникают не из-за злого умысла, а из-за слепых зон в документе.

https://habr.com/ru/articles/972992/

#техническое_задание #требования_к_системе #риски_бизнеса #риски_в_проектах #тз #тз_разработка_системы #функциональные_требования

Генерация схем бизнес-процессов с помощью ИИ на основе текстового ТЗ

Современные инструменты успешно превращают текстовое описание в наглядные диаграммы, включая профессиональные нотации, например, BPMN. Такие инструменты, как Miro AI, Whimsical и Eraser.io, превращают текстовое ТЗ в аккуратные и настраиваемые схемы за считанные секунды. ChatGPT выступает в роли универсального аналитика, который может и написать код для диаграммы, и детально её описать. А для задач профессионального моделирования уже существуют специализированные решения вроде Bonita AI BPMN Generator. В этой статье мы разберем, как ИИ-помощники справляются с генерацией диаграмм, в чем их сильные стороны и как с их помощью за минуты превратить текстовое описание в готовую схему. Также рассмотрим ИИ, как практический инструмент для структурирования, декомпозиции и визуализации размытых требований.

https://habr.com/ru/articles/968300/

#bpmn #схемы #тз #функциональные_требования #анализ_рисков #искусственный_интеллект #ии_помощник

Заметка про собеседования #2

На прошлой неделе S0ER опубликовал пост о том, что в собеседованиях укоренилась практика проверять знание каких-то фактов, а не умение мыслить. Будто ищется условный чат-гпт с большой базой знаний, а не специалист, способный анализировать и решать задачи. Хотя ИИ как раз тестируют так, как надо наоборот бы тестировать человека. Этот материал побудил меня порефлексировать над своим опытом в найме, вспомнить недавние кейсы и подумать о формирующихся тенденциях. Конечно, в этих рассуждениях не обошлось без AI.

https://habr.com/ru/articles/926730/

#собеседования #найм #кандидаты #тз #тестовые_задания #ии #ai

Шаблон ТЗ для AI

Привет! Я Ярослав Шмулев, датасаентист, выпускник МФТИ и технический директор топ-10 интегратора ИИ R77 AI. Сделал для нас AI ТЗ потому что обычно заказчики приходят и не знают чего хотят, как это описать и какие эффекты ждут.

https://habr.com/ru/articles/926254/

#тз #AI #ML #project_management #технические_задания

Зачем и как писать ТЗ

Эта статья написана для заказчиков разработки, в основном касается IT-продуктов на ранних стадиях. Цель статьи — дать понимание, что писать в ТЗ, как и главное, зачем. ТЗ — это вообще интересный феномен, все знают о том, что писать надо, но никто не делает. Либо делает халтуру с GPT, то же самое, даже хуже.

https://habr.com/ru/articles/924750/

#стартап #тз #продукт #разработка

Как подружить заказчика и исполнителя с помощью двух правильных букв?

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

https://habr.com/ru/articles/895350/

#прототипирование #тз #техническое_задание #управление_проектами #maker #gpt #заказчик #исполнитель #заказчик_исполнитель #bpmn

Функциональная спецификация на разработку ERP-системы на примере ABAP-отчета

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1]. Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2]. Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

https://habr.com/ru/articles/854228/

#техническое_задание #тз #задание_на_разработку #erpсистемы #спецификация_на_разработку

Как подружить разработчиков и SEO-специалистов, чтобы компания достигала целей

Привет! Я Илья Русаков — CEO impulse.guru. За годы практики заметил, что взаимодействие с ребятами-seoшниками не всегда проходит гладко. Сегодня разберёмся в нуждах и потребностях команд, посмотрим на примеры их «противостояния», и попутно я буду рассказывать, как облегчить взаимодействие между разработкой и SEO. Что за противостояния, о чём вообще речь? Когда SEO-специалист приносит стопку правок, разработчик почему-то не торопится их брать в работу. И это не из вредности — часто бывает, что seошник не доносит ценность правок, поэтому те и не попадают в список первоочередных задач разработчика. SEO-специалист продолжает настаивать, и вот уже работа двух команд напоминает батл — кто кого переиграет.

https://habr.com/ru/articles/846986/

#seo #взаимодействие_команд #команда_разработки #тз #правки

Принципы проектирования программ и их отражение в спецификации на доработку ERP-системы

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы. Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2]. К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.

https://habr.com/ru/articles/832594/

#спецификация_на_разработку #тз #техническое_задание #техническое_задание_для_разработки #техническое_задание_образец #fs #functional_specification #srs #функциональная_спецификация

Как двум командам сработаться и не сойти с ума

В сфере заказной разработки мобильных и веб-приложений встречаются разные способы организации работ и комбинации команд подрядчиков. Есть множество факторов, от которых это зависит: специфика проекта, области компетенций и квалификация подрядчиков, бюджет, сроки и еще куча подобных моментов. Единого стандарта нет и быть не может. Но есть часто встречающиеся комбинации, и одна из них: бэк на одном подрядчике, фронт – на другом. Как раз об этой комбинации мы и хотим рассказать. Так что в этой статье поделимся собственным опытом и порефлексируем. А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (SA) компании Интаро , взглядом фронтенда поделится Лиза, аналитик (BA) компании Surf . Читать дальше

https://habr.com/ru/companies/surfstudio/articles/817723/

#бизнесаналитика #аналитика #тз #surf #управление_продуктом #бизнесанализ

Был программистом, а стал системным аналитиком: что хорошего в смене специализации и каких ошибок лучше не совершать

Если вы задаётесь такими вопросами, как «точно ли я занимаюсь тем, что нравится?» или «как сменить сферу деятельности?», тогда эта статья однозначно для вас. В ней я поделюсь: • тем, как я выбрал свою первую профессию программиста; • почему решил сменить её и ушёл в системный анализ; • насколько мой опыт разработки помог мне в новой сфере; • сложно ли менять профессию и проходить собеседования; • какие выводы я сделал из пройденных трудностей и совершённых ошибок. Я, Игорь Олянич, системный аналитик компании Intaro, сейчас проведу вас по своему пути из разработки в аналитику и поделюсь опытом, который мне удалось получить. Присаживайтесь поудобнее.

https://habr.com/ru/companies/netologyru/articles/796729/

#системный_анализ #системный_аналитик #сменить_профессию #перейти_в_аналитику #тз #разработка_проектов #реализация_идей #спецификация #техническая_документация #общение_с_разработчиком

Большая подборка тестовых заданий для тестировщиков. Гайд и рекомендации

Привет! Меня зовут Артем. Я тестировщик и занимаюсь обучением будущих специалистов в этом направлении. Обучение – это первый шаг, гораздо важнее – поиск первой работы. Достаточно часто соискателям на позицию QA Engineer компании высылают тестовые задания (ТЗ). Их решение дает первичное понимание об уровне специалиста и является дополнительным фильтром для нанимающего менеджера. Я собрал всю информацию про тестовые задания и рекомендации в одном гайде. В конце статьи вы найдете ссылку на репозиторий с большой подборкой тестовых заданий.

https://habr.com/ru/articles/790438/

#тестовые_задания #тз #тестовые_задания_для_тестировщиков #тестировщик_тз #тестировщик_с_нуля #тестировщик_по #тестовые_задания_тестировщик

Перенос телефонии с западного вендора на российский САТЕЛ. Или ТЗ, с которым все непросто

Привет, Хабр! Сегодня мы расскажем про замену телефонии для одного крупного корпоративного клиента. Это проект из тех, что начинаются как локальная стройка, а заканчиваются возведением вавилонской башни. Простое внедрение дополнительного функционала системы обернулось переходом на новое ПО с разработкой, тестированием и исправлением «на лету». Под катом – специфические подробности про работу корпоративных «связистов», длинный список требований от заказчика, активное допиливание решения и, несмотря ни на что, позитивный финал.

https://habr.com/ru/companies/k2tech/articles/781628/

#телефония_для_бизнеса #миграция #UC #PBX #тз #Сател #рту

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

#video #fun #ТЗ #communication #log #прекрасное #soft_skills