Технічне завдання тз на модернізацію вентиляції. Технічне завдання тз на модернізацію вентиляції Техзавдання на доопрацювання сервера для зберігання

Навіщо необхідне техзавдання?

Приклад ТЗ для програміста

Якщо пройтися зарубіжними сайтами із запитом «product requirements document», то можна знайти креативні та переконливі статті про те, що технічне завдання (ТЗ, PRD) померло. Частково з цим потрібно погодитися - при розробці продукту з нуля прототипування виглядає набагато цікавіше та ефективніше, ніж томи записів замовника, часом дуже непрофесійні. Однак, якщо йдеться про доопрацювання базової системи, то справа набуває зовсім іншого обороту. Ми стикаємося і з доопрацюванням, і з розробкою на замовлення, тому на ТЗ собаку з'їли, якщо кухар нам не бреше. Загалом, сьогодні - про ті найкласичніші технічні завдання, які пишуться на доопрацювання купленого та встановленого програмного забезпечення. Коротше, про наболіле.

Грані взаємодії

Ресурси- люди, машини, інвентар, середовище розробки, час та гроші, які мають використовуватись у процесі реалізації вимог. Ресурси вимагають чіткого планування та оцінки на етапі узгодження технічного завдання. Грамотне розміщення пріоритетів з боку замовника та розподіл трудових ресурсів з боку вендора дозволяють уникнути зриву термінів та мінімізувати інші ризики.

Можливості- якщо коротко, це те, що реально може зробити вендор (виконавець). Розглянемо на прикладі нашої RegionSoft CRM. Клієнт купує систему та складає технічне завдання на доопрацювання: потрібно створити інтеграцію з сайтом та прив'язку подій у CRM до номера замовлення інтернет-магазину. Це реально можлива вимога, у нас є ресурс і можливість зробити це. А ще потрібно розробити та прикрутити до CRM CMS, систему керування контентом сайту. Теоретично ми це можемо, але у нас немає можливості це зробити дешево, а клієнт не має можливості заплатити нам стільки, щоб ми перекинули на завдання людські та тимчасові ресурси. В результаті від цієї вимоги замовник відмовляється - та й CMS йому не надто потрібна, все і так добре. Але про «жадібність» ТЗ- пізніше.

Обмеження- набір перешкод, які роблять виконання завдань із ТЗ скрутним чи неможливим: бюджет, стек технологій, ліцензійні проблеми, законодавчі заборони, апаратні конфігурації та ін.

Таким чином, усі чотири сутності тісно переплітаються між собою та визначають успіх проекту загалом. Розглянемо кожен елемент і спробуємо виділити критичні моменти, які потрібно мати на увазі, працюючи над технічним завданням.

Збір та аналіз вимог

Краще, ніж ви та ваші співробітники, вашу компанію не знає ніхто. А значить, збір та аналіз вимог - виключно ваше завдання, в якому вендор може допомогти і направити, але в жодному разі не втрутитися у процес. Розпитайте розробника про подібні впровадження, уточніть, на що звернути увагу та приступайте. До речі, непоганим помічником може бути ваш співробітник, який добре знається на профільній темі і приблизно представляє архітектуру ПЗ і знайомий з процесом розробки - він може виступити в ролі аналітика та внутрішнього експерта, замкнути на собі процес створення ТЗ та спілкування з вендором.

Є дуже проста схемазбирання вимог.

1. Створіть робочу групу з керівників та досвідчених фахівців підрозділів, які користуватимуться CRM. Розкажіть про рішення, яке передбачається вибрати, надайте доступ до демо-версії.
2. Члени робочої групи повинні передати інформацію співробітникам та запросити у них побажання до новій програміу абсолютно вільній формі. Якщо хтось із співробітників ніколи не стикався із подібним софтом і не готовий говорити в аспекті майбутнього використання, потрібно попросити його описати свої періодичні завдання, це універсальний підхід.
3. Потім кожен підрозділ встановлює, чого немає у CRM або чому вона не відповідає, та агрегує інформацію.
4. Робоча група аналізує зібрані вимоги, перевіряє та виключає перетину. Наприклад, нерідко відділ продажів і відділ маркетингу замовляють той самий звіт, але у вимогах можуть по-різному називатися поля та сутності, хоча дані за ними стоять однакові. Відповідно, потрібно дійти єдиної форми.
5. Робоча група формує список вимог та розставляє пріоритети. На цьому етапі можна підключити вендора, оскільки він відповідає за ресурси. Наприклад, можна попросити створити звіт користувача для RegionSoft CRM, а можна замовити інтеграцію з сайтом. Це різні за термінами завдання, тут дуже важливий пріоритет.

Анатомія технічного завдання

• Виявлення – визначення вимог, пошук проблем, які необхідно вирішити.
• Аналіз – розбір вимог, виділення ключових потреб, узагальнення.
• Адаптація – оцінка вимог у контексті можливостей CRM та існуючих бізнес-процесів.
• Документування - формальне та докладний описвимог, узгодження ТЗ.
• Спілкування з вендором (розробником) - ітеративна взаємодія з вендором щодо доробок згідно з складеним ТЗ.
• Реалізація – робота вендора над створенням необхідної функціональності. Краще, якщо вендор буде постійно на зв'язку із замовником - так продукт на виході буде найточніше відповідати баченню клієнта.
• Тестування - перевірка функціональності співробітниками вендора, внутрішніми експертами клієнта та кінцевими користувачами з метою встановлення відповідності доопрацювання та ТЗ, працездатності системи із змінами.

Рівень бізнесу- найбільший глобальний рівень, на якому вирішуються складні та пріоритетні завдання. До цього рівня можна віднести інтеграцію, доопрацювання та моделювання бізнес-процесів, розробку нових функціональних модулів. Як правило, це ресурсомістка розробка, з серйозними консультаціями та тісною спільною роботоюіз замовником. Наприклад, свого часу в RegionSoft CRM такою рекомендованою доробкою були складський облік, каса та виробництво. Поступово зміни увійшли до релізу, а пізніше дозволили створити новий продукт для оптових, роздрібних магазинів та гіпермаркетів – RegionSoft Retail.

Рівень користувача чи групи користувачів.На цьому рівні реалізуються завдання щодо доопрацювання існуючого інтерфейсу. Наприклад, користувач може захотіти, щоб при наведенні курсору на клієнта з'являлося віконце з номером і статусом останнього замовлення або існував кастомний звіт з особливим угрупуванням даних. Доопрацювання на цьому рівні займають менше часу, але їх може бути багато – наприклад, кілька вимог від відділу маркетингу, логістики та технічної підтримки.

Рівень функціональності.Найчастіше його важко відокремити від попереднього, тут працює формальний критерій - доопрацювання не на рівні відображення чогось в інтерфейсі, а на рівні доопрацювання логіки системи. Сюди можна віднести вимоги до різноманітних сортувань, інтеграцій з чатом, можливостей телефонії.

Рівень сервісу- насправді, вимоги цього рівня мають першими потрапляти до нових збірок із фіксами. Це завдання щодо швидкості відгуку системи, роботи під високим навантаженням, безпеки. У ідеальному варіантіу вендора не повинно бути таких доопрацювань - корпоративний софт не повинен гальмувати, втрачати дані, плескати форми та роздавати права доступу одного рівня. Але якщо вимога з'явилася, і вона не пов'язана з персональною параною замовника або проблемами на стороні апаратного забезпеченняварто приділити йому підвищену увагу.

Рівень технології- останній у списку, але за важливістю та складністю випереджає інші. Це можуть бути вимоги клієнта, пов'язані з платформою, операційною системоюабо пристроями. Наприклад, запит збирання під MacOS. Дуже добре, якщо такі вимоги поступово переростуть у релізи, але їх фікси обов'язково. Саме із запитів клієнтів на цьому рівні ми зробили складання RegionSoft CRM під MacOS і додали віддалений доступ за технологією TRM як тимчасове рішення рідкісного, але існуючого запиту мобільної версії.

Анатомія технічного завдання проста, у разі у вигляді скелета. Обов'язкові частини технічного завдання допомагають замовнику зосередитись на проблемі та сформулювати завдання правильно, а виконавцю – зрозуміти, що ж від нього хочуть. До речі, про розуміння. Звичайно, на початку посту ми трохи злукавили, заперечуючи бізнес-консультантів як клас. Справа ось у чому: кожен вендор працює на ринку по кілька років (ми зараз не про CRM-одноденки), а то й десятки років, а значить має набір кейсів практично по кожній галузі. Відповідно і інженери, і програмісти, і продажники знайомі зі специфікою впровадження в кожному типі компанії. Але знов-таки, важливо орієнтуватися саме на свій бізнес.

Для кого?У цьому розділі потрібно описати, хто буде кінцевим користувачем доопрацювання, які завдання та з якою періодичністю планується вирішувати.

Наведу приклад. В одній компанії впроваджували CRM, передбачалася робота на досить великому масиві даних (кілька десятків мільйонів записів на місяць, кілька сотень тисяч записів на день). Начальник відділу продажів запросив звіт з розвантаження цих записів із періодичністю «щодня». Природно, що такий звіт за одночасної роботи сотні користувачів навантажував систему - було знайдено рішення щодо оптимізації процесу. Вже в ході роботи з'ясувалося, що продажник перестрахувався і звіт потрібен йому лише за підсумками місяця, і його можна запускати за розкладом вночі. Чи варто говорити, що час та гроші були витрачені дарма.

Навіщо?Обґрунтування необхідності доопрацювання та його місце у бізнес-процесі. Цей пункт більше потрібен самому замовнику, але й вендору не зайве знати, які процеси будуть торкнутися. Іноді це допомагає знайти альтернативне рішення.

Що має робити?Найінформативніший блок - у ньому описуються вимоги, очікування від системи. І ось тут трапляються ті самі перли, чудеса і колізії, які можна відправляти на башорг, і які ну дуже ускладнюють життя. Причина одна – користувач не знає, чого він хоче, що потрібно зробити. Є ще маленька підпричина – користувач не може сформулювати вимоги. І тут завдання розробника (робочої групи, аналітика, якщо він є) допомогти сформулювати потребу правильно, вибрати доцільну вимогу, вписати завдання у контекст роботи системи. У цьому блоці слід згадати очікуваний результат.

Параметри технічного завдання- терміни, етапи реалізації, відповідальні від усіх сторін, необхідні контакти та ін. Фактично це сукупність важливих формальних речей, які роблять документ технічним завданням. Технічне завдання обов'язково має бути узгоджене та підписане сторонами, щоб уникнути численних змін у ході розробки (вони все одно будуть, але в меншому обсязі).

В ідеальному варіанті технічне завдання складається за активної участі вендора, і його підсумок є приблизно такою структурою:

1. Опис вимоги кожного механізму та кожної функціональності
2. Опис реалізації цієї функціональності
3. Вартість робіт по кожному з етапів окремо
4. Загальна вартість робіт з даного технічного завдання
5. Терміни виконання робіт з розбивкою за етапами та зазначенням черговості
6. Опис умов встановлення та тестування доопрацювання
7. Застереження про вичерпний характер технічного завдання та інші умови

10 правил, написаних сльозами розробника

Технічне завдання має бути жадібним.Нерідко бізнес переоцінює свої можливості чи бажає отримати «все і відразу». Такий підхід не виправданий ні з погляду грошей, ні з погляду бізнесу. Вендор, як правило, існує не кілька тижнів (у випадку RegionSoft - 15 років), і до нього можна звернутися і через деякий час, коли ви реально зрозумієте, чого в CRM не вистачає.

Яскравий приклад надмірності буквально зі вчорашнього дня: клієнт купив ERP однією відомою російської компаніїДумаючи, що якщо працює бухгалтерський облік, то і ERP цього вендора буде хороша. ERP виявилася не те щоб не дуже сама по собі, але дуже не підходяща бізнесу. А ось RegionSoft CRM зі складським облікомта виробництвом підходить. Є рішення: забути про ERP, поплакати, інтегрувати облік 1С з новою CRM та радіти зручній реалізації. Але вбуханих грошей шкода! І клієнт вимагає інтегрувати CRM із ERP. Ми й не таке робили, але навіщо таке витрачання, навіщо дві щодо схожих системи?

Технічне завдання має бути реалістичним та здійсненним- як за вимогами, і за термінами. Тут важливо дослухатися думки вендора, оскільки він точно знає, який час піде на те чи інше завдання. Повірте, розробнику не вигідно тягнути час і накручувати термін - йому вигідно завершити якнайбільше проектів і зробити це добре, щоб не отримати удару по репутації. Що стосується реалістичності, то уникнути прохань допиляти CRM до рівня системи управління колайдером просто: слід включати до вимог те, що дійсно потрібно на Наразіі в найближчому майбутньому.

Наприклад, RegionSoft CRM – десктопна програма, у нас немає клієнта для браузера. Просити нас створити web-додаток для однієї компанії безглуздо, це велика розробка, вона зараз ведеться і не є можливим доопрацюванням для однієї компанії. Ні, звичайно, все має свою ціну, але знову ж таки - у загальному випадку вимога нездійсненна.

Не потрібно плутати з ситуацією, коли йдеться про розробку на замовлення і докорінно змінюється ідея і логіка роботи програми, фактично спонсорується створення нового програмного забезпечення «під себе». Але то інша історія.

Технічне завдання має бути докладним.Потрібно вказати усі значущі деталі майбутнього проекту: від періодичності використання програми до побажань щодо інтерфейсу. Чим докладніше будуть викладені вимоги, тим простіше та швидше пройдуть реалізація та тестування. Особливо варто приділити увагу деталям, якщо ви працюєте у специфічній галузі (медицина, страхування, банки) – докладний виклад нюансів взаємодії бізнесу та програми забезпечить розуміння завдання вендором та швидку адаптацію системи до вашої компанії.

Обов'язково зверніть увагу на формати чисел, назви полів, наявність або відсутність списків, поведінка кнопок і хінтів, типи даних. Якщо замовник використовує власні формули, які необхідно закласти у логіку роботи CRM ( наприклад, розрахунок дилерських бонусів), ці формули повинні бути прописані з повним розшифруванням їх позначень та логіки розрахунку.

Технічне завдання має бути однозначним та точним.Розпливчасті формулювання, варіанти реалізації, нечіткі вимоги - все це шлях у безвихідь. Буває, що покупець із добрих намірів пише у ТЗ кілька варіантів поведінки системи, близьких, але з рівнозначних. У цьому випадку він впевнений, що допомагає, підказує програмісту, але насправді добрими намірами встелена дорога в пекло розробник повинен розуміти, що саме потрібно, а як це зробити він вибере сам, виходячи з особливостей системи та стеку технологій, що використовуються.

Технічне завдання має бути написане людською мовою.І це важливо, ні, ВАЖЛИВО. Виокремлю дві ситуації, коли проблеми з мовою призводять до затягування реалізації проекту.

1. Клієнт намагається продемонструвати свою технічну грамотність та городить конструкції типу: «імплементувати вікно з хінтом у тіло календаря з можливістю реакції на кол події…» замість «у календарі має спливати вікно, в якому можна відзначити завдання як виконане». Якщо у вас чи вашого внутрішнього експерта немає навичок написання технічних текстів, не гуглить – пишіть звичайними словами, ми їх розуміємо.

   Технічне завдання має бути скаргою.Потрібно вирішувати проблему, а не описувати її, приділяючи увагу шрифтам та забуваючи про опис вимог. ТЗ має містити як саму проблему, а й її рішення лише на рівні осмислення - далі розробник вже вирішить її лише на рівні коду. Порівняйте «відділ продажу погано планує, втрачає цифри, вже рік боремося»і «необхідно створити звіт, який зберігатиме значення плану та факту продажів щомісяця, у розрізі груп номенклатури».

   Технічне завдання має вміти дивитися у майбутнє.Ну не зовсім воно, а люди, які стоять за ним. Якщо відомо, що незабаром відбуватимуться зміни у бізнес-процесах, це потрібно обов'язково враховувати, щоб не платити за доопрацювання двічі.

   Технічне завдання має бути бюрократичним.Якщо ви хоч раз складали цей документ, то, напевно, відчували, як важко уникнути спокуси скотитися в бюрократію, навернути вступних слів, суворих оборотів та описати кожен пункт як статтю Кримінального кодексу (бажано з покаранням усім за порушення). Бюрократичні формулювання маскують неповне розуміння цілей створення ТЗ. Відповідальність вендора прописана у договорі, там же написано бюджет. Не варто переносити ці моменти на технічне завдання.

   Технічне завдання має бути технічним завданням.Звучить парадоксально, але часто замість ТЗ читаємо листи, скарги, договори, заново написану інструкцію до CRM або протокол наради. Звісно, ​​працювати за таким документом неможливо. Для того, щоб не уникнути форми і змісту, скористайтеся старим шкільним вивертом: розгляньте термін за словами. Технічне - отже, диктує доопрацювання, техніку, спрямоване вирішення завдання у вигляді зміни ПЗ. Ось про завдання у контексті ПЗ і треба говорити. Завдання - означає постановка питання, проблеми, без порад, підказок та попередніх оцінок. Просто формулювання завдання.

   Заповіді закінчилися, тепер відповідь

   Крім перерахованих правил, є ще кілька речей, про які варто розповісти. Йдеться про цілі, плани та очікування - всіх тих, хто залишає, які роблять проект успішним, а відносини вендора та клієнта майже дружніми.

   Технічне завдання потрібно писати швидконавіть якщо перед вами стоїть завдання автоматизації процесів стільникового операторачи великого гіпермаркету. Це пов'язано з тим, що технології розвиваються з величезною швидкістю і навіть система, яку ви впроваджуєте, за півроку-рік може пережити мажорний реліз (а іноді й два), отримати нову функціональність. Можливо, доведеться переглянути необхідність доробок та розпочати процес заново.

   

   
   Нарешті знайшов час закінчити ТЗ. Але, на жаль, довкола не залишилося розробників, щоб його реалізувати.

   Клієнт не знає про стек та технічні обмеження.І знати не повинен – це завдання вендора, саме він оцінює роботи після складання технічного завдання. Замовнику не варто заглиблюватися в технології та на кожній комі запитувати, чи зможе вендор зробити ту чи іншу річ. Складіть комплексне ТЗ і розробник вибере потрібну архітектуру - часто навіть кращу, ніж ви могли подумати.

   Оцінити бюджет та уникнути неприємних сюрпризів- чи не спільне завдання номер один. Не варто смикати вендора і вимагати від нього зразкової оцінки робіт (ну хоч приблизно, навскидку, на око, а як в інших, ну в проектах такого типу, а з досвіду, ну так, в межах похибки). Повна оцінка бюджету можлива лише після прочитання, аналізу та остаточного затвердження технічного завдання. Якщо ваш розробник чинить інакше - готуйтеся до того, що доробка обійдеться щонайменше вдвічі дорожче.

   Виходьте з об'єктивної необхідності змін та розширень- я писав, що розробник не зникає і готовий внести зміни і доповнення за вашими вимогами в будь-який момент. Тому не намагайтеся створити CRM/ERP мрії одразу, не вимагайте від вендора кнопку «Все працює, поки я п'ю каву» - попрацюйте в системі, визначте критичні для вас зауваження та приступайте до збору вимог та складання ТЗ.

   Про технічні завдання можна писати нескінченно, це справжній генератор не тільки мемів і байок, а й головного болю. Можна розповісти про пріоритети та правила оформлення, про ГОСТ 1989 року, який робить ТЗ нелюдським, про стандарти IEEE, які трохи кращі, про прототипи та ТЗ, що їх доповнюють. Але в кінці хотілося б обмежитися одним, найголовнішим правилом: технічне завдання – не норма права, не ГОСТ і не догма, тому, якщо можна покращити – покращуйте, можна спростити – спрощуйте, можна зробити витончено і щоб усім подобалося – робіть. Упевнений, ніхто після такого не тицьне носом у ТЗ і не скаже, що там такого не написано. Або майже ніхто.

   Весь грудень ми даємо знижки на RegionSoft CRM та весь софт власної розробки. З 1 по 15 грудня – 15% та круті умови розстрочення та оренди. У нас не буває -70% і -90%, тому що ми тримаємо економічно обґрунтовану ціну на ліцензії, а не беремо її зі стелі.

   Ну а якщо вам потрібна CRM-система (з доопрацюванням або без), то заходьте на наш сайт, там багато про CRM, її переваги та інше корпоративний софт.

   І так, ми завжди шукаємо партнерів, які готові продавати CRM та інші продукти, доопрацьовувати та продавати CRM, продавати софт та навчати користувачів. Поділ доходів чесний та вигідний партнеру. Покажемо, розкажемо, навчимо. Пишіть на [email protected]

   Слайди, слайди. Комікси взяті з http://www.modernanalyst.com/ та з Pinterest. Якщо є найкращий переклад – будемо раді його внести до посту.

Часто прикладаю прототипи сторінок, щоб клієнт зрозумів, як виглядатиме його сайт. Потім складаю окреме завдання для верстальника – з технічними деталями та поясненнями, які допоможуть у його роботі.

Чим складніше завдання, тим докладніше має бути ТЗ. Коли я брала участь у великих проектах, я бачила техзавдання на 30 сторінок.

Гурам Сіпки, засновник діджитал-студії Udix Media

Насамперед ТЗ потрібно клієнту - щоб він зрозумів, яким буде його сайт, і на що йдуть гроші. Якщо щось зроблено не так – він може послатися на ТЗ та попросити переробити.

ТЗ складає менеджер проекту після спілкування з клієнтом та обговорення завдання з дизайнером.

Великі замовники часто просять докладні ТЗ, в яких описана кожна кнопка. Невеликі компанії, навпаки, не люблять скрупульозні документи на 100 сторінок.

Приклад технічного завдання на доопрацювання сайту

Загальні відомості

Найменування автоматизованої системи

«АС ЗБУТ»

Замовник

Виконавець

Підстава для виконання робіт

Планові терміни початку та закінчення робіт зі створення системи

Початок робіт: 01.09.2010

Закінчення робіт: 31.12.2010

Призначення та цілі створення системи

Призначення системи

Розроблювана автоматизована системапризначена для автоматизації процесів збуту підприємства.

Цілі створення системи

Цілі створення автоматизованої системи

Цілями розробки «АС ЗБУТ» є:

1. 3. Характеристика об'єкта автоматизації

3.1 Бізнес процеси підприємства

3.1. 1 Бізнес процес «Укладання договору»

Воно стане Вашим щитом, у цей документ Ви, у разі чого, зможете тицьнути пальцем недобросовісному розробнику та вимагати привести Ваш сайт у відповідність до нього.

Технічне завдання(коротко “ТЗ”) – це документ, який максимально докладно та однозначно відображає вимоги до Вашого майбутнього сайту.

Сайт створюють саме на основі ТЗ. Чим докладнішим і однозначнішим воно буде, тим більше Ваш новий сайт буде відповідати Вашим очікуванням.

ТЗ на створення сайту – як закон, не повинно допускати трактувань та різночитань.

Все, що не прописано в ТЗ, розробник робить на свій розсуд.

· Керівництво адміністратора;

· Керівництво контент-менеджера;

· Посібник з інсталяції;

· Керівництво програміста.

2.20. Організація та проведення навчання фахівців Слідчого комітету при прокуратурі Російської Федерації

Пред'являються такі вимоги до навчання:

· Виконавець має провести навчання співробітників Слідчого комітету при прокуратурі Російської Федераціїу складі трохи більше 10 чол.

· Навчання має проводитися російською мовою.

· Приміщення для навчання надається Замовником.

· Місце та час навчання має бути погоджено із Замовником.

Навчання повинно проводитись по всій функціональності системи.

У рамках навчання необхідно здійснити інформаційне наповнення одного пілотного сайту Кільця сайтів Слідчого комітету при прокуратурі Російської Федерації.

3.

Зразок технічного завдання на доопрацювання сайту

Важливо

У процесі застосування Виконавець повинен надавати допомогу Замовнику в рамках Графіка застосування.

6.1.11. У разі слабкої підготовки персоналу Замовника до впровадження та необхідності надання додаткової допомоги Виконавцем для успішного впровадження ПЗ повинен бути складений додатковий протокол узгодження договірних цін на надання інформаційно-консультаційних робіт.

6.2.Порядок подальшого супроводу завдань АС «Збут».

У ТЗ має бути зазначена трудомісткість та вартість робіт з реалізації додаткових вимог.

6.2.2. Виконавець зобов'язується підтримувати телефонну гарячу лінію з супроводу програмного забезпечення.

Грані взаємодії Перш ніж розпочати препарацію процесу створення технічного завдання, поговоримо про чотирикутник, до якого потрапляють виконавець і замовник, приступаючи до проекту. Вимоги- бажана поведінка системи, описана замовником або холдером процесу, що підлягає реалізації. Як правило, вимоги формуються на підставі досвіду роботи, подання правильної поведінки програми.

Це ключова інформація для розробника (вендора), проте саме на етапі збору вимог виникає найбільша кількість колізій, помилок, зайвих запитів та ін.

Ресурси- люди, машини, інвентар, середовище розробки, час та гроші, які мають використовуватись у процесі реалізації вимог. Ресурси вимагають чіткого планування та оцінки на етапі узгодження технічного завдання.

Сюди можна віднести вимоги до різноманітних сортувань, інтеграцій з чатом, можливостей телефонії.

Рівень сервісу- насправді, вимоги цього рівня мають першими потрапляти до нових збірок із фіксами. Це завдання щодо швидкості відгуку системи, роботи під високим навантаженням, безпеки.

Увага

В ідеальному варіанті у вендора не повинно бути таких доробок - корпоративний софт не повинен гальмувати, втрачати дані, плескати форми та роздавати права доступу одного рівня. Але якщо вимога з'явилася, і вона не пов'язана з персональною параною замовника або проблемами на стороні апаратного забезпечення, варто приділити йому підвищену увагу.

Рівень технології- останній у списку, але за важливістю та складністю випереджає інші.

Microsoft World чи Microsoft Excel.

Особисто ми під час розробки landing page використовуємо спеціальні програмні продукти.

За допомогою їх можна швидко і легко складати проекти навіть складних сайтів – це, наприклад, Balsamiq. Втім, як ми робимо весь прототип, уже розповідали в статті.

По темі: Прототипування сайту: створення, інструменти та програми.

Передпроектним проектуванням можна зайнятися спільно з розробником або повністю перекласти це на його плечі.
Головне, не забудьте, потім його узгодити та підписати двома сторонами.

ЛАЙФХАКИ З СКЛАДАННЯ ТЗ

Ці пункти однаково ставляться як заповнення брифа, і до складання технічного завдання.

І в них я відкрию Вам невеликі хитрощі, як скласти тз для сайту та полегшити, і без того складне життя підприємця:

1.

Переконатися, що клієнт та виконавець правильно зрозуміли один одного».

У технічному завданні не повинно бути якісних прикметників: гарний, надійний, сучасний. Їх не можна однозначно зрозуміти. У кожного свої поняття краси та сучасності.

Подивіться. Адже хтось вважав цей дизайн красивим і дозволив використовувати на своєму сайті:

Те саме - з невиразними формулюваннями, які нічого самі по собі не означають:

• Сайт має сподобатися замовнику.А якщо він матиме поганий настрій?
• Сайт має бути зручним.Що це означає? Зручним для чого?
• Сайт має витримувати великі навантаження. 10 тисяч відвідувачів? Чи 10 мільйонів?
• Якісний експертний контент.Ну ви зрозуміли.

Перевірте, чи немає тексту неоднозначностей. Якщо є – перепишіть.

Вирішили замовити сайт (він же лендінг)? Як свідчить практика, це не так просто. Сотні замовників, побачивши свій готовий сайт, виявляють, що він їм не підходить: дизайн не той, розташування кульгає, тексти повз, прикрутили купу непотрібних функцій.

Щоб уникнути таких наслідків, Вам необхідне технічне завдання на розробку сайту.

ВОНЕ МЕНІ ТРЕБА?!

Не має значення, хто буде виконавцем сайту – Ви самі, Ваш родич, фрілансери за скромну оплату, спеціалізована компанія за величезну суму грошей…

Технічне завдання на сайт має бути.

Наприклад, можна попросити створити звіт користувача для RegionSoft CRM, а можна замовити інтеграцію з сайтом. Це зовсім різні за термінами завдання, тут дуже важливий пріоритет. Після того, як вимоги зібрані, проаналізовані та узгоджені зі співробітниками та керівництвом, можна приступати до створення технічного завдання.
Ви можете попросити форму у вендора або скласти його самостійно - у будь-якому випадку є кілька залізних правил, дотримання яких позбавить головного болю і вас, і вашого постачальника CRM.

Анатомія технічного завдання

Якщо говорити про процес створення технічного завдання, існує кілька етапів. Їхнє послідовне проходження і призводить замовника до бажаного доопрацювання.
Ось вони.

Тут важливо дослухатися думки вендора, оскільки він точно знає, який час піде на те чи інше завдання. Повірте, розробнику не вигідно тягнути час і накручувати термін - йому вигідно завершити якнайбільше проектів і зробити це добре, щоб не отримати удару по репутації.

Що стосується реалістичності, то уникнути прохань допиляти CRM до рівня системи управління колайдером просто: слід включати до вимог те, що дійсно потрібно на даний момент та в найближчому майбутньому.

Наприклад, RegionSoft CRM – десктопна програма, у нас немає клієнта для браузера. Просити нас створити web-додаток для однієї компанії безглуздо, це велика розробка, вона зараз ведеться і не є можливим доопрацюванням для однієї компанії.

Повне та коротке найменування інформаційної системи

Повне найменування системи - офіційний сайт Слідчого комітету при прокуратурі Російської Федерації.

Коротка назва системи - "Сайт СКП", "Система", "Сайт".

1.2. Найменування замовника системи та його реквізити

Найменування: Слідчий комітет при прокуратурі Російської Федерації

Місце знаходження: р.

Інфо

Москва, Технічний провулок, будинок 2

Фактична адреса: А

Контактна особа Замовника:

Телефон: (4, (4);

Адреса електронної пошти

1.3. Перелік документів, на основі яких створюється Система

Державний контракт №________________ від ___ ___________ 2010 р.

1.4.

Визначаються відповідно до Договору.

2. Вимоги до системи

2.1.

дата платежу

НомерПлатежа

Номер платежу у платіжній системі

Сума платежу

1. Вибрати рядки файлу передачі даних
2. Почати цикл за рядками файлу передачі
3. Прочитати рядок файлу передачі даних
4. Отримати з рядка файлу передачі даних код договору
5. Знайти за кодом відповідний елемент у довіднику «Договори контрагентів», якщо елемент не знайдено, то видати повідомлення «Не знайдено договору з кодом...»
6. Якщо елемент знайдено, то додати рядок до таблиці значень, де: «Договір» - знайдений елемент, «Дата» - «Data_plat», «НомерПлатежа» - «Nomer_plat», «Сума» - «Summa_plat»
7. Після отримання останнього рядка файлу передачі даних закінчити цикл
8. Для кожного рядка таблиці значення створити документ «Платіжне ордер надходження коштів».

Заповнюючи бриф або складаючи тз на дизайн сайту, не залишайте пробілів.

Ви повинні розуміти, що "На розсуд розробника" означає "що хочу, те і ворочу" або "Все, що не обумовлено, виконується на розсуд виконавця". І повірте, це не просто лазівка, а ціле вікно для розробника до Європи.

І, звичайно, так відбувається не завжди.

Якщо Вам попався грамотний спеціаліст, то можна не хвилюватись за результат.

Але тут виникає інша проблема, він може зробити реально як треба, а Вам не сподобається суто суб'єктивно. І все буде як у відомому для багатьох розробників анекдоті:

КОРОТКО ПРО ГОЛОВНЕ

Ви точно не пошкодуєте про час, витрачений на складання та узгодження технічного завдання для створення сайту чи лендінгу.

Адже це Ваш найкращий інструмент контролю та вирішення розбіжностей, які виникають у процесі.

При натисканні на той чи інший округ слід переходити на сторінку з текстовим описом даного округу.

· Блок «Блог Голови»— повинен являти собою список із трьох останніх тем, створених у блозі у вигляді назви теми та дати її публікації. Назва теми буде посиланням, при натисканні якого має бути переведено на сторінку блогу з описом даної теми. Також у даному блоці має розміщуватись відео, яке можна відтворити, не залишаючи головну сторінку. У відео має бути посилання «Коментарі», що є кількістю коментарів до цього відеозображення. Посилання "Коментарі" має вести на сторінку блогу з коментарями до представленого відео.

Нижній колонтитул повинен містити поле для пошуку, інформацію про авторські права тощо.

2.3.

Бріф– це анкета з питаннями про зміст, дизайн, технічні можливостіВашого майбутнього сайту

Звичайно, докладно заповнений бриф підписаний двома сторонами може замінити технічне завдання.

Адже це практично те саме, різниця лише в тому, що бриф це Ваше бачення, а технічне завдання це фінальний документ на основі Вашого брифу та коментарів розробника.

Якщо окремі пункти викликають труднощі, то не соромтеся ставити розробнику запитання на кшталт "Що це означає?", "Як це вплине на роботу мого сайту?"

Або у графі “ додаткова інформація” обов'язково вкажіть усі Ваші побажання, які не увійшли у відповіді на запитання.

Якщо ця графа відсутня, просто допишіть в кінці брифа.

VK, Google, Facebook.

3.2.2 У особистому кабінетіу розділі замовлення додати поле для додавання промо-коду.

3.2.3 Замість сторінки, яка надходить користувачеві після запиту на відновлення пароля (виду name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=) зробити сторінку (виду name.com/login/forgot/сhange_password=yes =ru&USER_CHECKWORD=), яка відображатиме контент сайту, матиме поле «Email при реєстрації», контрольний рядок, новий пароль, підтвердження пароля, кнопка надіслати дані.

3.2.4 При додаванні товарів до кошика має виводитись повідомлення про те, що товар доданий до кошика.

3.2.5 Додати висновок повідомлення про те, що пароль не відповідає параметрам безпеки під час реєстрації нового користувача.

» _» ______________ 2010 р.

Поступово зміни увійшли до релізу, а пізніше дозволили створити новий продукт для оптових, роздрібних магазинів та гіпермаркетів – RegionSoft Retail.

Рівень користувача чи групи користувачів.На цьому рівні реалізуються завдання щодо доопрацювання існуючого інтерфейсу. Наприклад, користувач може захотіти, щоб при наведенні курсору на клієнта з'являлося віконце з номером і статусом останнього замовлення або існував кастомний звіт з особливим угрупуванням даних.

Доопрацювання на цьому рівні займають менше часу, але їх може бути багато – наприклад, кілька вимог від відділу маркетингу, логістики та технічної підтримки.

Рівень функціональності.Найчастіше його важко відокремити від попереднього, тут працює формальний критерій - доопрацювання не на рівні відображення чогось в інтерфейсі, а на рівні доопрацювання логіки системи.

Якщо там написана каша – можливо, варто бігти і не озиратися.

• Застрахуватися від несумлінності виконавця.Коли сайт готовий, його можна перевірити на технічне завдання. Чи є невідповідності? Розробник зобов'язаний їх виправити. Якщо ви співпрацюєте офіційно і укладали договір, можна навіть примусити через суд.
• Спростити заміну виконавців.Якщо клієнт і розробник посварилися та розбіглися, створення сайту може сильно затягнутися. Коли є докладне техзавдання, його можна передати новій команді – вона втягнеться у роботу в рази швидше.
• Дізнатись вартість розробки складного продукту.Оцінити точні терміни та вартість розробки складного веб-сервісу відразу не можна. Спочатку потрібно зрозуміти, як працюватиме сервіс, і які у ньому будуть функції.

Є root-доступ, власні IP-адреси, порти, правила фільтрування та таблиці маршрутизації.

Google PageSpeed ​​Insights - це безкоштовний сервісрекомендацій для веб-сайтів щодо прискорення відображення сторінки у браузері користувача (https://developers.google.com/speed/pagespeed/insights/).

Пошукова оптимізація (або SEO) - комплекс заходів із внутрішньої та зовнішньої оптимізації для підняття позицій сайту в результатах видачі пошукових систем за певними запитами користувачів.

Зовнішня оптимізація сайту – це реєстрація сайту пошукових системах, розкручування в соціальних мережах, нарощування посилальної маси шляхом залучення посилань з інших ресурсів на сайт, що просувається, банерна реклама, контекстна реклама.

Внутрішня оптимізація сайту – це оптимізація тексту, URL-адрес, редагування структури сайту, перелінкування, перевірка відповідей сервера.

Наявні матеріали Посилання на сайти, що сподобалися, а також буклети, журнали, фотографії – що завгодно, а може бути у Вас є готовий бренд-бук. Додається окремим архівом. Мінімальна роздільна здатність та пристрої відображення У цьому пункті вкажіть, з яких пристроїв передбачається переглядати сайт – ПК, ноутбуків, смартфонів… Монітори ПК від 19 до 27 дюймів; Ноутбуки від 15,6 до 17,3 дюйми; Смартфони від 3,5 до 6 дюймів; Планшети від 7 до 12 дюймів Мобільна версія? Так ФУНКЦІОНАЛЬНІ ВИМОГИ Зразковий набір модулів (для користувачів) У цьому розділі потрібно перерахувати все функціональні можливості, які Ви бажаєте бачити на сайті.

Це може бути кошик, фільтри каталогу за різними параметрами, можливість зробити онлайн замовлення, залишити заявку на зворотний дзвінок, підписатися на розсилку та будь-які інші опції Фільтри каталогу за ціною, за алфавітом, за виробником.
CRUпtCj9B:s»XVжб╟▌╤└u╟J_■Е╘Dj»J■╛EХHJя(гTT┬Пб╟▌╤└u╟╛#╜┘al+Ка Кqяk3┴i≈²& ц╜IWA▓BOЬ└vOЗб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╔╛ ┘al+КаXG[ б:ьVжб╟▌╤└u╟╛#╜│ц&V█7┬м3aqNYJy╕°Vжб╟▌╤└u╟╛#╜┘al+КaXG[ б: #╜┘al+КаXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╒ ≈≈K&ОQТі╦▒'%[н╓≥Lк"[Ц(б╖~и╚б╖~и╚б╚~и╚б╖~и╚б╖~и╚б╖~у╚б╖~у ╚б╖~и╚б╖~и╚б╖~и╚б╖~и╚б╖~ы╚б╚~и╚б╖~ы╚б╚~и╚бD'═\┘*NлkZ ⌡ ┐©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈Д7і$╔≥ Ы∙?ЬjЛ?Ч╜∙╤SQ≥╒°еHФх═с┬├6иCИіЪ╖Bl╢╡ Lе ┬7┴+iSo(╦°rБ╒┴■Е4СЦг┬╨ з╖ ┘╤m°с÷Уm╦Wімdр'%R^&╔gt╖yхDА]zт╪L╝i▌▀s_2 ©OлM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡і<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Пам'ятаєте закон Мерфі? Якщо вас можуть зрозуміти неправильно, вас неодмінно зрозуміють неправильно. Це справедливо не лише у спілкуванні між людьми, а й у створенні сайтів. Клієнт хотів другий "Фейсбук", а отримав форум юних собаківників. Розробник не вгадав хотівку замовника - змарнував час.

У цьому гайді я розповім, що й навіщо треба писати у техзавданні. Заодно покажу, як писати не треба, щоб створення ТЗ не обернулося змарнованим часом.

Стаття буде корисною:

• Усім, хто має відношення до створення сайтів: розробникам, дизайнерам, верстальникам.
• Менеджерам проектiв.
• Керівникам діджітал-студій.
• Підприємцям, які планують замовити розробку сайту.

Щоб матеріал вийшов слушний, я зібрав коментарі кількох розробників, дизайнерів, проект-менеджерів та власників діджитал-студій. Найцінніші додав до кінця статті. Поїхали розбиратися.

Що таке техзавдання і навіщо воно потрібне

Технічне завдання – це документ, у якому зафіксовано вимоги до сайту. Чим чіткіше і докладніше розписані ці вимоги, то краще всі учасники процесу розуміють, яким він має бути. Отже, зростає шанс того, що всі залишаться задоволені результатом.

Головна мета технічного завдання: переконатися, що клієнт та виконавець правильно зрозуміли один одного.

Користь від технічного завдання багато. Для кожної сторони вона своя.

Користь для клієнта:

• Зрозуміти, за що він платить гроші і яким буде сайт.Можна одразу побачити структуру, зрозуміти, що і як працюватиме. Прикинути, чи все влаштовує. Якщо ні – без проблем змінити ще до початку розробки.
• Побачити компетентність виконавця.Якщо техзавдання зрозуміле та чітке – довіра до розробника підвищується. Якщо там написана каша – можливо, варто бігти і не озиратися.
• Застрахуватися від несумлінності виконавця.Коли сайт готовий, його можна перевірити на технічне завдання. Чи є невідповідності? Розробник зобов'язаний їх виправити. Якщо ви співпрацюєте офіційно і укладали договір, можна навіть примусити через суд.
• Спростити заміну виконавців.Якщо клієнт і розробник посварилися та розбіглися, створення сайту може сильно затягнутися. Коли є докладне техзавдання, його можна передати новій команді – вона втягнеться у роботу в рази швидше.
• Дізнатись вартість розробки складного продукту.Оцінити точні терміни та вартість розробки складного веб-сервісу відразу не можна. Спочатку потрібно зрозуміти, як працюватиме сервіс, і які у ньому будуть функції. Для цього і потрібно підготувати техзавдання.

Користь для виконавця:

• Зрозуміти, що хоче замовник.Клієнту ставлять десятки запитань, показують приклади, пропонують рішення. Потім записують у єдиний документ і узгоджують. Якщо все окей – ура, ви зрозуміли правильно.
• Застрахуватися від раптових бажань клієнта.Іноді трапляються замовники, які хочуть поміняти завдання на півдорозі. Якщо ви погодили та підписали ТЗ, вам не страшно подібне. У разі чого навіть суд буде на вашому боці.
• Показати свою компетентність.Класно підготовлене техзавдання покаже клієнту експертність розробників. Якщо компанія сумнівалася, чи довіряти вам розробку сайту, сумніви з великою ймовірністю розвіються.
• Заробити гроші.Деякі студії та розробники пропонують складання ТЗ як окрему послугу.

• Полегшити та прискорити процес розробки. У хорошому ТЗ вказано структуру сайту, необхідні функції та елементи на кожній сторінці. Коли всі вимоги вже перед очима – залишається тільки задизайнить та написати код.

Тепер давайте розберемося, як скласти хороше техзавдання, яке виконує всі ці функції.

Техзавдання складає виконавець

Взагалі техзавдання може скласти будь-хто. "Потрібен сайт-візитка для стоматологічної клініки" - це вже техзавдання. Але чи виконуватиме він свої функції? Навряд чи.

Хороше ТЗ завжди складає виконавець: проект-менеджер чи розробник. Очевидно, що веб-розробник розуміє створення сайтів більше, ніж власник кафе або стоматологічної клініки. Тому описувати проект доведеться йому.

Це не означає, що клієнт зникає і з'являється наприкінці, щоб написати: «Збс, схвалюю». Він також має брати участь у процесі:

Звісно, ​​замовник може накидати свій варіант ТЗ. Можливо, це прискорить процес створення кінцевого техзавдання. А можливо, вийде сміття, яке нишком викинуть на смітник.

Пишіть однозначно та точно

Ця порада випливає з головної мети техзавдання - «Переконатися, що клієнт і виконавець правильно зрозуміли одне одного».

У технічному завданні не повинно бути якісних прикметників: гарний, надійний, сучасний. Їх не можна однозначно зрозуміти. У кожного свої поняття краси та сучасності.

Подивіться. Адже хтось вважав цей дизайн красивим і дозволив використовувати на своєму сайті:

Те саме - з невиразними формулюваннями, які нічого самі по собі не означають:

• Сайт має сподобатися замовнику.А якщо він матиме поганий настрій?
• Сайт має бути зручним.Що це означає? Зручним для чого?
• Сайт має витримувати великі навантаження. 10 тисяч відвідувачів? Чи 10 мільйонів?
• Якісний експертний контент.Ну ви зрозуміли.

Перевірте, чи немає тексту неоднозначностей. Якщо є – перепишіть. Ваші формулювання мають бути чіткими та точними:

• Сайт повинен завантажуватись швидко → Будь-яка сторінка сайту повинна мати більше 80 балів у Google PageSpeed ​​Insights.
• Великі навантаження → 50 тисяч відвідувачів одночасно.
• На головній сторінці відображається список статей → На головній сторінці відображається список останніх 6 опублікованих статей.
• Мінімалістичний зручний інтерфейс передплати → Поле «Залишіть e-mail» та кнопка «Підписатися» → * намальований ескіз *.

З формулюваннями розібралися, давайте пробіжимося структурою.

Вкажіть загальну інформацію

Усі члени команди повинні правильно розуміти, чим займається компанія та хто її цільова аудиторія. Щоб ніхто не заплутався, це краще прописати на початку техзавдання.

А ще варто вказати мету сайту та описати його функціонал у двох словах – щоб не отримати інтернет-магазин замість блогу.

Поясніть складні терміни

Перше правило техзавдання - воно має бути зрозумілим для всіх, для кого призначено. Якщо ви збираєтеся використати терміни, які може не зрозуміти ваша клієнтка – власниця магазину дитячих іграшок – обов'язково поясніть їх. Зрозумілою мовою, а не копіпастою з «Вікіпедії».

Опишіть інструменти та вимоги до хостингу

Уявіть, що ви 2 місяці робили крутий сайт. Кожен етап узгоджували з клієнтом – він у захваті. І ось настав час здавати роботу. Ви показуєте адмінку, а клієнт кричить: Це що таке? Модекс? Я думав, ви зробите на "Вордпресі"!"

Щоб таких проблем не було, опишіть інструменти, движки та бібліотеки. Заодно вкажіть вимоги до хостингу. Мало, ви зробите на PHP – а у клієнта сервер на .NET.

Перерахуйте вимоги до роботи сайту

Сайт повинен працювати у всіх браузерах актуальних версій та на всіх типах пристроїв. Так, це очевидно для будь-якого розробника та будь-якого замовника. Але краще написати, щоб захистити клієнта від несумлінно виконаної роботи.

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

Вкажіть структуру сайту

До початку малювання дизайну та верстки вам потрібно узгодити з клієнтом структуру сайту.

Поспілкуйтеся із замовником, з'ясуйте, що йому треба. Зберіть розробників, сеошників, маркетологів, головного редактора - і вирішіть, які сторінки потрібні на сайті. Подумайте, як вони пов'язані між собою, з якою на яку можна перейти.

Можна показати структуру списком, можна намалювати блок-схему. Як вам зручніше.

Це один із найважливіших етапів роботи на сайті. Структура – ​​це фундамент. Якщо вона невдала – сайт вийде кривою.

Поясніть, що буде на кожній сторінці

Клієнт повинен зрозуміти, навіщо потрібна кожна сторінка та які елементи на ній будуть. Є два способи це показати.

Прототип- Наочніший і однозначний спосіб. Виконавець малює ескізи кожної сторінки та додає їх до техзавдання. Клієнт бачить, як виглядатиме інтерфейс його майбутнього сайту та каже, що йому подобається, а що варто змінити.

Перелік елементів- лінива альтернатива прототипу. Просто напишіть, які блоки мають бути на сторінці і що вони роблять.

Розпишіть сценарії використання сайту

Якщо ви робите якийсь нестандартний інтерфейс, просто показати структуру та ескізи сторінок недостатньо. Важливо, щоб вся команда виконавців та клієнт зрозуміли, як відвідувачі користуватимуться сайтом. Для цього чудово підходять сценарії. Схема сценарію дуже проста:

• Дія користувача.
• Дія сайту у відповідь.
• Результат.

Звісно, ​​якщо ви робите стандартну візитку чи лендинг, писати сценарії не потрібно. Але якщо на сайті будуть якісь інтерактивні сервіси дуже бажано.

Докладніше про сценарії використання читайте у «Вікіпедії».

Визначте, хто відповідає за контент

Одні розробники роблять сайт одразу з контентом. Інші ставлять рибу. Треті можуть написати тексти, але за додаткову оплату. Договоріться про це на березі та зафіксуйте у техзавданні, який контент ви повинні підготувати.

Вигадати об'єктивні критерії оцінки якості текстів досить складно. Краще не пишіть нічого, ніж «Якісний, цікавий контент, що продає, корисний для цільової аудиторії». Це сміття, воно нікому не потрібне.

Вказати, що весь контент має бути унікальним – це корисно. Ще один захист клієнта від несумлінних виконавців.

Опишіть дизайн (якщо зможете)

Як і у випадку з текстом, об'єктивні критерії оцінки дизайну сайту придумати складно. Якщо ви з клієнтом домовилися про колірну гамму – напишіть її. Якщо у нього є брендбук, у якому прописані шрифти, - вкажіть їх.

Писати про гарний та сучасний дизайн не треба. Це нічого не означає, не має сили і взагалі фу.

Замість висновку: структура техзавдання

Для різних завдань структура ТЗ буде своєю. Безглуздо робити однакові технічні завдання для нової соціальної мережі та лендингу з оптового продажу моркви. Але загалом вам потрібні такі розділи:

• Інформація про компанію та цільову аудиторію, цілі та завдання сайту.
• Глосарій термінів, які можуть бути незрозумілими для клієнта.
• Технічні вимоги до верстки та роботи сайту.
• Опис використовуваних технологій та список вимог до хостингу.
• Детальна структура сайту
• Прототипи сторінок чи описи елементів, які мають бути.
• Сценарії використання нестандартного інтерфейсу (опційно).
• Список контенту, який розробник.
• Вимоги до дизайну (опціонально).

• Правила упорядкування Software Requirements Specification. SRS – наступний ступінь еволюції техзавдання. Потрібна для великих та складних проектів.
• Стандарти та шаблони ТЗ на розробку ПЗ. Опис різних ГОСТів та методологій створення технічних завдань.

Це кінець тієї частини, що писав я. Але є й інша – коментарі спеціалістів, які допомагали робити гайд. Почитайте це теж цікаво.

Коментарі розробників

Я поспілкувався з кількома розробниками, щоб дізнатися, як вони складають техзавдання. Передаю мікрофон ім.

Насамперед ТЗ потрібно клієнту - щоб він зрозумів, яким буде його сайт, і на що йдуть гроші. Якщо щось зроблено не так – він може послатися на ТЗ та попросити переробити.

ТЗ складає менеджер проекту після спілкування з клієнтом та обговорення завдання з дизайнером.

Великі замовники часто просять докладні ТЗ, в яких описана кожна кнопка. Невеликі компанії, навпаки, не люблять скрупульозні документи на 100 сторінок. Довго читати і легко упустити щось важливе. Найчастіше ми робимо лаконічні ТЗ на 10–15 сторінок.

Ми вказуємо:

• Інформацію про компанію та мету сайту.
• Вимоги до дизайну, кольорова гама.
• Використовувані технології та CMS.
• Хто займається контентом – ми чи клієнт.
• Структуру сайту до кожної сторінки.
• Описи кожної сторінки. Ми не робимо прототипи, але вказуємо, які елементи мають бути на сторінці та як вони повинні працювати.

Останні 2 розділи – найважливіші. Саме вони забезпечують розуміння, якими буде сайт і як він працюватиме.

Дуже важливий момент – не можна просто віддати техзавдання розробникам та сподіватися, що вони все зроблять добре. ТЗ – це список вимог до сайту, він не може замінити спілкування. Важливо переконатись, що кожен член команди розуміє загальну мету, а не просто виконує завдання на потоці. Якщо щось незрозуміло – треба пояснити, обговорити, дати докладні коментарі.

У житті часто буває так, що людина не може пояснити, що хоче, навіть у побутових речах. Коли справа доходить до пояснення програмісту своїх «хотілок», людина просто впадає у ступор.

В ідеалі ТЗ має складати замовник — тільки він знає, що йому потрібне. Але на практиці через низьку компетенцію замовника у сфері 1С часто це доводиться робити виконавцю. Замовник усно озвучує свої потреби, а програміст (консультант) оформлює це у письмовій формі.

Навіщо потрібне технічне завдання?

Будь-які, в ідеалі, повинні супроводжуватися технічним завданням. Це, по-перше, чітке визначення завдання, термінів та методу виконання. По-друге, це документ, за допомогою якого вирішуються усі спірні моменти у майбутньому. Писати ТЗ чи ні — справа, звісно, ​​Ваша, особисто мені ТЗ полегшує роботу та спілкування з клієнтом.

Отримайте 267 відеоуроків з 1С безкоштовно:

Що має містити технічне завдання?

тех. завдання обов'язково має містити у собі:

• мета- Завдання, яку ми вирішимо, реалізуючи дане ТЗ;
• опис- Короткий виклад майбутніх доопрацювань;
• спосіб реалізації- Докладний опис методів вирішення мети. У цьому пункті необхідно описати всі нюанси завдання мовою програміста: які , створюємо/редагуємо, як має виглядати інтерфейс і т.д. Якщо Ви не володієте "мовою програміста", але "щось чули", краще не намагатися писати технічною мовою - виходить досить весело. Опис має бути однозначним та не викликати питань. Також може містити у собі приклад реалізації такого рішення в іншій сфері;
• оцінка роботидуже важливий пункт, опис трудовитрат.

Також існують державні стандарти до написання ТЗ – ГОСТи. Насправді мало де застосовуються, але буває, замовник наполягає у цьому.

За досвідом, при здачі робіт дуже часто виникають ситуації на кшталт «а ми Вам тоді говорили…», що не дуже приємно, і часто доводиться переробляти роботу цілком. Тому добре написане ТЗ полегшує життя обох сторін.

Приклади та зразки ТЗ для 1С

Невелика добірка, яку я знайшов у вільному доступі до мережі. Починаючи від найпростіших і найдоступніших, закінчуючи досить складними документами.