Як скласці тэхнічнае заданне на распрацоўку

Добрае тэхнічнае заданне эканоміць не старонкі, а грошы: па ім падрадчык называе цану, якая не «сплыве» праз месяц, а вы прымаеце работу па зразумелых крытэрыях. Дрэннае ТЗ — гэта або тры радкі «патрэбны сайт як у канкурэнтаў», або 80 старонак патрабаванняў, якія ніхто не дачытаў да канца.

Ніжэй — практычнае кіраўніцтва, як скласці тэхнічнае заданне на бота, сайт, дадатак або платформу, нават калі вы не тэхнічны спецыяліст. Разбяром структуру, пакажам фрагмент ТЗ у рэальным фармаце, пералічым памылкі, якія часцей за ўсё прыводзяць да перарабленняў, і раскажам, як атрымаць папярэднюю ацэнку без доўгай перапіскі.

Навошта патрэбна ТЗ і чым яно адрозніваецца ад брыфа

Брыф адказвае на пытанне «што за бізнес і якая задача». ТЗ адказвае на пытанне «што менавіта павінна атрымацца і як мы зразумеем, што гэта гатова». Брыф запаўняюць за паўгадзіны, ТЗ збіраюць ад некалькіх дзён да пары тыдняў — у залежнасці ад маштабу прадукту.

У тэхзадання тры практычныя функцыі:

• Ацэнка. Без пераліку роляў, сцэнарыяў і інтэграцый любая цана — гэта варажба. Разрыў ацэнак аднаго і таго ж «сайта» ў розных падрадчыкаў у 3–5 разоў звычайна тлумачыцца тым, што кожны ўявіў сабе свой сайт.
• Дамоўленасць. ТЗ фіксуе аб'ём работ. Усё, што ў яго не ўвайшло, — змяненне аб'ёму, якое абмяркоўваецца асобна, а не «ну гэта ж відавочна».
• Прыёмка. Кожнае патрабаванне павінна правярацца: «форма заяўкі адпраўляе даныя ў CRM за 5 секунд» праверыць можна, «зручная форма» — нельга.

Для невялікіх задач — простага бота або лендынга — дастаткова кароткага ТЗ на 2–4 старонкі. Для платформы або мабільнага дадатку дакумент вырастае да 15–40 старонак, і яго звычайна дапрацоўваюць разам з падрадчыкам на этапе прататыпа.

Шаблон ТЗ на распрацоўку: 9 абавязковых раздзелаў

Гэты шаблон ТЗ на распрацоўку падыходзіць для любога лічбавага прадукту: Telegram-бота, сайта, Mini App, мабільнага дадатку або маркетплэйса. Раздзелы можна скарачаць, але не выкідаць — пусты раздзел лепшы, чым забыты.

Калі прадукт складаны, дадайце глосарый (што вы называеце «замовай», «здзелкай», «кліентам») і дадаткі да дакумента: прыклады дакументаў, выгрузкі з бягучых сістэм, скрыншоты канкурэнтаў з пазнакамі «падабаецца» і «не падабаецца».

Як напісаць ТЗ на распрацоўку: сцэнарыі замест спіса функцый

Галоўная памылка — апісваць прадукт як набор экранаў і кнопак. Распрацоўшчыку важней зразумець, хто, навошта і ў якой паслядоўнасці выконвае дзеянні. Таму, калі вы разбіраецеся, як напісаць ТЗ на распрацоўку так, каб яго зразумелі аднолькава, пачынайце са сцэнарыяў.

Формула карыстальніцкай гісторыі

Выкарыстоўвайце просты шаблон: «Як [роля], я хачу [дзеянне], каб [вынік]». Напрыклад: «Як менеджар, я хачу атрымліваць апавяшчэнне ў Telegram пра новую заяўку, каб звязацца з кліентам на працягу 15 хвілін».

Крытэрыі прыёмкі да кожнай гісторыі

Да кожнай гісторыі дадайце 2–5 умоў, якія можна праверыць. Для прыкладу вышэй:

• апавяшчэнне прыходзіць не пазней за 10 секунд пасля адпраўкі формы;
• у апавяшчэнні ёсць імя, тэлефон, выбраная паслуга і крыніца заяўкі (UTM-пазнака);
• кнопка «Узяць у работу» змяняе статус заяўкі і хавае яе ад іншых менеджараў;
• калі менеджар не адказаў за 15 хвілін, апавяшчэнне атрымлівае кіраўнік.

Так пішуцца патрабаванні, па якіх можна і ацаніць работу, і прыняць яе. Для ботаў і Mini App гэта асабліва важна: логіка там жыве ў дыялогу, і без сцэнарыяў падрадчык вымушаны дадумваць. Падрабязней пра тое, як мы праектуем карты станаў, — на старонцы распрацоўкі Telegram-ботаў.

Прыярытэты: MoSCoW

Размецьце кожную функцыю: Must (без яе прадукт не запускаецца), Should (патрэбна, але можна праз месяц), Could (прыемна мець), Won't (дакладна не ў гэтай версіі). Гэтая разметка — аснова першай версіі прадукту; як адабраць функцыі для запуску, мы падрабязна разбіралі ў артыкуле пра распрацоўку MVP.

Нефункцыянальныя патрабаванні, пра якія забываюць

Функцыі апісваюць, што прадукт робіць. Нефункцыянальныя патрабаванні — як ён гэта робіць. Менавіта яны часцей за ўсё ўсплываюць пасля запуску і каштуюць даражэй за ўсё, калі пра іх не дамовіліся загадзя.

• Нагрузка: колькі карыстальнікаў чакаецца ў першы месяц і праз год, ці ёсць пікі (распродажы, рассылкі).
• Хуткасць: мэтавы час загрузкі старонак і адказу бота; для сайтаў — арыенцір па Core Web Vitals.
• Даступнасць: дапушчальны час прастою, ці патрэбны маніторынг і дзяжурства.
• Бяспека: якія даныя захоўваем, хто мае да іх доступ, ці патрэбна двухфактарная аўтарызацыя, журнал дзеянняў.
• Персанальныя даныя: апрацоўка па 152-ФЗ (расійскі закон аб персанальных даных), лакалізацыя захоўвання ў РФ, згоды і палітыка канфідэнцыяльнасці.
• Размяшчэнне: ваша воблака, уласныя серверы або закрыты контур без доступу ў інтэрнэт.
• Падтрымка: браўзеры, версіі iOS і Android, мовы інтэрфейсу, даступнасць для людзей з парушэннямі зроку.
• Перадача: дакументацыя, доступы, рэпазітарый на вашым акаўнце, інструкцыя па разгортванні.

Прыклад тэхнічнага задання на сайт

Ніжэй — скарочаны прыклад тэхнічнага задання на сайт вытворчай кампаніі. Ён змяшчаецца на дзвюх старонках і ўжо дазваляе атрымаць дакладную ацэнку.

1. Мэта: атрымліваць заяўкі на разлік абсталявання ад B2B-кліентаў; арыенцір — 40 кваліфікаваных заявак у месяц праз 3 месяцы пасля запуску.
2. Аўдыторыя: інжынеры і забеспячэнцы прадпрыемстваў, 70% заходзяць з дэсктопа.
3. Ролі: наведвальнік; кантэнт-менеджар (правіць каталог і навіны); адміністратар (доступы, налады).
4. Структура: галоўная, каталог з 6 катэгорый і ~120 пазіцый, картка тавару з PDF-спецыфікацыяй, кейсы, пра кампанію, кантакты, блог.
5. Ключавы сцэнарый: наведвальнік знаходзіць пазіцыю праз фільтр → адкрывае картку → націскае «Запытаць КП» → запаўняе форму з 4 палёў → заяўка ідзе ў Bitrix24 і ў Telegram аддзела продажаў.
6. Інтэграцыі: Bitrix24 (стварэнне ліда), Яндэкс Метрыка з мэтамі, выгрузка каталога з 1С раз на суткі.
7. Дызайн: брэндбук ёсць, патрэбны UX-прататып і адаптыў для мабільных.
8. Нефункцыянальныя патрабаванні: загрузка старонкі да 2 секунд на 4G, тэхнічнае SEO і мікраразметка, хостынг у РФ.
9. Прыёмка: усе сцэнарыі з п. 5 праходзяць на тэставым стэндзе, формы даходзяць у CRM, Lighthouse Performance — ад 90.

Звярніце ўвагу: тут няма слоў «сучасны», «зручны» і «прадаючы». Затое ёсць лічбы, ролі, сцэнарый і крытэрыі. Па такім дакуменце падрадчыкі называюць супастаўныя цэны, а вы параўноўваеце прапановы, а не фантазіі. Паглядзець, якія сайты і вэб-дадаткі мы робім і з чаго складаецца работа, можна ў раздзеле распрацоўкі сайтаў.

Частыя памылкі ў ТЗ і як іх пазбегнуць

Яшчэ адна пастка — спрабаваць апісаць усё да апошняй кнопкі яшчэ да прататыпа. Дэталі інтэрфейсу хутчэй і танней вырашаюцца на клікабельным прататыпе: вы бачыце экраны, націскаеце, змяняеце. ТЗ задае рамку, прататып яе напаўняе.

Анлайн-апытальнік: ТЗ без чыстага аркуша

Самае складанае — пачаць. Таму на сайце ёсць анлайн-апытальнік для складання ТЗ: ён ператварае структуру вышэй у паслядоўнасць пытанняў з падказкамі і варыянтамі адказаў. Пісаць з нуля не трэба — большасць пунктаў выбіраюцца кнопкамі. Апытальнік складаецца з 7 раздзелаў:

1. Пра вас — кантакты, кампанія, ваша роля ў праекце.
2. Пра прадукт — тып прадукту, мэта, стадыя, бягучы стэк, рэферэнсы і спасылкі на дакументы.
3. Карыстальнікі і ролі — аўдыторыя, ролі, маштаб, геаграфія, праблема карыстальніка.
4. Функцыянальнасць — функцыі, абавязковы мінімум, аплаты, інтэграцыі.
5. Платформы і дызайн — дзе працуе прадукт, дызайн, брэндынг, кантэнт.
6. Даныя, AI і бяспека — ці патрэбны AI, міграцыя даных, патрабаванні да бяспекі і размяшчэння.
7. Бюджэт, тэрміны і працэс — бюджэт, дэдлайн і яго прычына, падтрымка, ваш удзел.

Адразу пасля адпраўкі вы атрымліваеце папярэднюю ацэнку. Яна даведачная: дакладны кошт называем пасля прапрацоўкі ТЗ разам з вамі. Арыенціры па цэнах на ўсе напрамкі сабраны на старонцы цэн на распрацоўку.