Підготовка тз. Технічне завдання: законодавчі вимоги та практика, що склалася

Визначення змісту проекту, розробка ТЗ

У цьому розділі коротко розглянуто питання розробки технічного завдання(Далі ТЗ) . Спочатку дано визначення ТЗ, описані переваги ТЗ як замовника, так виконавця, перераховані основні функції ТЗ. Далі розглянуто, в чому ж сутність ТЗ, розкрито структуру та зміст ТЗ, а також наведено приклади структури ТЗ. На закінчення відзначено особливості ТЗ інноваційних проектів.

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

Визначення

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

ГОСТ 19.201–78. єдина системаПрограмної документації. Технічне завдання. Вимоги до змісту та оформлення.

ГОСТ 25123-82. Машини обчислювальні та системи обробки даних. Технічне завдання. Порядок побудови, викладу та оформлення.

ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи.

Наприклад у «ГОСТ 19.201-78. Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення» дано таке визначення ТЗ: «Технічне завдання на автоматизовану систему - затверджений в установленому порядку документ, що визначає цілі, вимоги та основні вихідні дані, необхідні для розробки автоматизованої системи та містить попередню оцінку економічної ефективності».

Вказано, що ТЗ дозволяє:

    виконавцю - зрозуміти суть завдання, показати замовнику «технічний вигляд» майбутнього виробу, програмного виробу чи автоматизованої системи;

    замовнику – усвідомити, що саме йому потрібно;

    обом сторонам - уявити готовий продукт;

    виконавцю - спланувати виконання проекту та працювати за наміченим планом;

    замовнику - вимагати від виконавця відповідності продукту всім умовам, обумовленим ТЗ;

    виконавцю - відмовитися від виконання робіт, які не вказані у ТЗ;

    замовнику та виконавцю - виконати попунктну перевірку готового продукту (приймальне тестування - проведення випробувань);

    уникнути помилок, пов'язаних із зміною вимог (на всіх стадіях та етапах створення, за винятком випробувань).

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

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

ТЗ виконує чотири основні функції:

    Юридична. ТЗ є юридичним документом, і як додаток входить у договір між замовником і виконавцем.

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

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

    Комунікативна. Докладно складене ТЗ допомагає виконавцю краще дізнатися про потреби замовника та виконати роботу, що відповідає всім його смакам. Що також сприяє процесу затвердження проекту.

Сутність ТЗ

p align="justify"> Робота над ТЗ означає, що передбачається вирішення якогось завдання і воно покроково описується в цьому документі. ТЗ може бути розроблено на будь-що: на створення технології, нового матеріалу, пристрою, сайту, програми, стандарту, виконання заходу тощо.

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

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

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

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

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

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

Незважаючи на свою важливість, зміст та структура ТЗ практично не регламентовані нормативними документами.

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

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

p align="justify"> При формуванні системи вимог необхідний аналіз доступності ресурсів, що знаходяться в розпорядженні замовника і розробника: фінансові, виробничі, людські, тимчасові, а також облік вимог наглядових та ліцензійних органів, наприклад, при проектуванні технологічних комплексів (виробництв). Найчастіше контролюючими є регіональні органи Ростехнагляду, Росстандарту, Росспоживнагляду, Росприроднагляду, та ін.

Нижче наведено приклади структури ТЗ із різних джерел.

Наприклад, ТЗ може містити розділи:

    предмет ТЗ;

    цілі роботи, що проводиться;

    вимоги до звіту;

    порядок організації роботи;

Приклад із вищезазначеного ГОСТ 19.201-78.

    Вступ;

    основи розробки;

    призначення розробки;

    вимоги до програми чи програмного виробу;

    вимоги до програмної документації;

    техніко-економічні показники;

    стадії та етапи розробки;

    порядок контролю та приймання;

    до технічного завдання допускається включати додатки.

Наступний приклад ТЗ надання консультаційних послуг

    загальні положення;

    мета роботи;

    кваліфікаційні вимоги до кандидатів.

Приклад ТЗ на виконання науково-дослідної роботи «Розробка концепції, стратегії розвитку та техніко-економічного обґрунтування створення техніко-впроваджувального парку в м. Пермі» (далі – НДР)

    основа для виконання НДР

    виконавець та співвиконавці

  1. завдання НДР

    початкові дані

    основні вимоги до проведення НДР

    календарний план виконання НДР

    передбачуване використання результатів виконання НДР

    порядок здачі-приймання результатів НДР

Приклад структури шаблону ТЗ на виконання НДДКР

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

    Виконавець

    Термін проведення робіт

    Ціль виконання робіт

    Результати НДДКР

    Продукція, що розробляється

    Технічні вимоги

    Основні параметри, які мають бути досягнуті внаслідок виконання роботи:

    Основні конструктивні вимоги (якщо можна застосувати)

    Вимоги щодо видів забезпечення (якщо застосовно)

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

    Вимоги щодо забезпечення безпеки для життя та здоров'я людей та охорони навколишнього середовища

    Вимоги надійності (якщо застосовується)

    Вимоги щодо безвідмовності та довговічності.

    Вимоги щодо ергономіки та технічної естетики (якщо застосовується)

    Вимоги до експлуатації, зручності технічного обслуговування та ремонтопридатності (якщо застосовується)

    Вимоги до стійкості до зовнішніх впливів (якщо можна застосувати)

    Вимоги до експлуатаційних показників (якщо застосовно)

    Вимоги щодо сертифікації

    Інші вимоги та спеціальні вимоги щодо галузей

    Вимоги до патентної чистоти та патентоспроможності

    Вимоги до документації

    Порядок прийняття робіт.

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

Особливості розробки ТЗ інноваційного проекту

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

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

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

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

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

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

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

До складу розширеного ТЗ можуть включатися:

1. Опис проекту

2. Ринкові та економічні цілі проекту

3. Тимчасові параметри

4. Технічні параметри

5. Виробничі параметри

8. Вимоги до дизайну та ергономіки

9. Норми та розпорядження

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

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

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

Розглянемо місце ТЗ у структурі інноваційного процесу в організації(Впровадження інновацій в організації) згідно .

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

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

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

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

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

Отже, ТЗ

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

Давайте проаналізуємо такий приклад:

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

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

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

Що ми маємо. Виконавець пункт ТЗ виконав, а ви хотіли зовсім інший календар. Начебто все відповідно до ТЗ, ніхто не винен, до конфлікту не дійшло, але найголовніше втрачено час та гроші.

Це приклад усього банального календаря.

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

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


З яких пунктів зазвичай складається ТЗ?

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

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

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

Поїхали пунктами.


Опис сайту

Тут можна в пару пропозицій написати про підприємство, чим займається. Щось типу вступ зробити.

для кого – цільову аудиторію сайту:

  • потенційні покупці
  • продавці продукції (магазини, інтернет-магазини)
  • сервісні центри
  • партнери (фірми)
  • споживачі продукції (той, хто вже купив)

Навіщо потрібен сайт:

  • Для підвищення іміджу компанії
  • Для збільшення продажів
  • Для зручності клієнтів

Тип сайту:

  • Корпоративний
  • Сайт візитка
  • Інтернет магазин

Мовні версії:

  • Англійська
  • Українська


Сайт має вирішувати якісь завдання. Відповідно далі рухаємося за цілями та завданнями сайту.

Цілі та завдання сайту

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

Потенційні покупці продукції.

Ціль: залучити більше покупців і переконати зробити першу покупку, допомогти зробити вибір

Необхідно вирішити задачі:

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

  • Дати інформацію про салони-магазини
  • Дати інформацію про роздрібну торгову мережу

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

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


Тепер перераховуємо модулі сайту.

Функціонал сайту

Для того щоб перерахувати функціонал сайту, потрібно вирішити, що йому необхідно:

  • Чи потрібні новини на сайті
  • Чи потрібний рекламний блок
  • Чи потрібна реєстрація
  • Чи потрібний закритий розділ сайту (тільки для зареєстрованих користувачів)
  • Чи потрібна форма зворотного зв'язку
  • Чи потрібний скрипт розсилки
  • І т.д. і т.п.


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

Опис функціоналу сайту

На даний момент ми знаємо для кого сайт, які цілі та завдання він має виконувати, його додаткові функціональні можливості.

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

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

Для початку потрібно розповісти про компанію. Тут можуть бути сторінки про компанію, історія компанії, контакти, відгуки.

Звичайно має бути пункт меню «продукція», з підпунктами « каталог продукції», «Релізи», «обговрення продукції».

Загалом, як розписувати сподіваюся зрозуміло. Представлю кінцевий варіант можливого меню для нашого сайту:

Про компанію

  • Історія компанії
  • контакти
  • відгуки

Новини

  • події
  • акції
  • нове на сайті

Продукція

  • каталог продукції
  • релізи
  • відгуки про продукцію

Сервіс

  • служба сервісу
  • гарантійне обслуговування
  • післягарантійне обслуговування

Споживачу

  • купівля та доставка
  • користування
  • про сервіс

Магазинам та інтернет магазинам

  • фотографії продукції
  • Часто задавані питання

Сервісним центрам

  • Як стати сервісним центром
  • Часто задавані питання

Партнерам

  • запрошення до співпраці
  • часто задавані питання


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


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


Головне тепер описати логіку роботи.

Логіка роботи

Я описувати буду, виходячи з малюнка вище.

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

Приблизно так описується загальна логіка роботи.

Тепер детально описуємо кожний блок. Наприклад «Новинна стрічка».

«Новинна стрічка» з 10-ти останніх новин. Кожна новина має складатися із заголовка новини, дати публікації, короткого початку новини (4-5 рядків) та посилання «читати повністю». При натисканні на посилання читати повністю потрапляємо на сторінку новин. Новина, на яку потрапили, відображається на місці основного вмісту. Включає заголовок новини, дату публікації. Зліва так само відображається стрічка новин. Новини за минулі місяці та роки потрапляють до архіву. Тобто під новинами за поточний місяць відображаємо «архів за (якийсь місяць чи рік)». При натисканні на посилання «архів за (такий-то місяць чи рік)» вниз випадає список новин за відповідний місяць/рік.

Приблизно так описуємо роботу кожного блоку. Не забуваймо про випадок із календарем. І найголовніше потрібно розписати роботу каталогу товару. Тут я даю вам завдання: спробуйте продумати і описати, як працюватиме каталог Свої варіанти надсилайте на e-mail. Найкращий ми опублікуємо.


Що ще має бути? Непогано було б вказати сумісність.

Сумісність

У цьому пункті вказуємо, на яких операційні системиі в яких браузерах сайт повинен однаково добре виглядати. На якій версії, якої мови має бути написано. Який CMS використовується. Це варто вказати, якщо Ви дійсно розумієте, про що кажете.

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


Висновок

У цій статті я не прагнув показати, що саме так складається ТЗ і ніяк не інакше. Робіть так і проблем не буде. Скласти якісне ТЗ – це скоріше питання досвіду. На перших парах скласти грамотне ТЗ вийде далеко не у всіх.

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

І не забувайте про завдання!

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

  • У першій частині « Розробка технічного завдання. Що це таке, навіщо воно потрібно, з чого почати і як має виглядати?» я докладно спробую відповісти на питання теми, розгляну структуру та призначення Технічного завдання, дам деякі рекомендації щодо формулювання вимог.
  • Друга частина " Розробка технічного завдання. Як формулювати вимоги?» буде повністю присвячена виявленню та формулюванню вимог до інформаційної системи.

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

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

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

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

Думаю, зараз у читача мають виникнути питання:

  • А чому не можна розробляти Технічне завдання завжди однаково?
  • Чи є якісь стандарти, методики, рекомендації? Де їх взяти?
  • Хто має розробляти технічне завдання? Чи має ця людина мати якісь спеціальні знання?
  • Як зрозуміти, чи добре складено Технічне завдання чи ні?
  • За чий рахунок має воно розроблятися, та й чи потрібне воно взагалі?

Цей список може бути нескінченним. Говорю так упевнено від того, що вже 15 років у професійній розробці програмного забезпечення, а питання про Технічні завдання спливає у будь-якому колективі розробників, з ким доводиться працювати. Причини цього різні. Порушуючи тему розробки Технічного завдання, я чудово усвідомлюю те, що не зможу викласти її на 100% для всіх, хто цікавиться темою. Але, спробую, як то кажуть, «розкласти все по поличках». Ті, хто вже знайомий з моїми статтями знають, що я не користуюся копі-пастом праці інших людей, не передруковую чужі книги, не цитую багатосторінкові стандарти та інші документи, які Ви і самі зможете знайти в інтернеті, видаючи їх за свої геніальні думки. Достатньо набрати в пошуковій системі «Як розробити Технічне завдання» і Ви зможете прочитати багато цікавого, але, на жаль, багаторазово повторюваного. Як правило, ті, хто любить розумнічати на форумах (спробуйте все-таки пошукати!), самі ніколи не робили тлумачного Технічного завдання, і безперервно цитують рекомендації ГОСТів з цього питання. А тим, хто справді серйозно займається питанням, зазвичай ніколи сидіти на форумах. Про ГОСТИ, до речі, ми теж поговоримо. У різні роки своєї роботи мені доводилося бачити безліч варіантів технічної документації, складеної як окремими фахівцями, так і відомими командами та консалтинговими компаніями. Іноді ще я займаюся такою діяльністю: виділяю собі час і займаюся пошуком інформації на тему, що цікавить, за незвичайними джерелами (такою невеликою розвідкою). В результаті доводилося бачити документацію і за такими монстрами, як ГазПром, РЗ та багато інших цікавих компаній. Звичайно ж, я дотримуюсь політики конфіденційності, незважаючи на те, що ці документи потрапляють до мене з загальнодоступних джерел або безвідповідальності консультантів (розкидають інформацію по інтернету). Тому відразу кажу: конфіденційною інформацією, яка належить іншим компаніям не поділяюся, незалежно від джерел виникнення (професійна етика).

Що таке технічне завдання?

Перше, що ми зараз зробимо, то це розберемося з тим, що за звір такий, «Технічне завдання».

Так, дійсно існують ГОСТи та стандарти, в яких зроблено спроби регламентувати цю частину діяльності (розробки програмного забезпечення). Колись усі ці ГОСТи були актуальними та активно застосовувалися. Наразі існують різні думки щодо актуальності даних документів. Одні стверджують, що ГОСТи були розроблені дуже далекоглядними людьми і досі актуальні. Інші кажуть, що вони безнадійно застаріли. Можливо, хтось зараз подумав, що правда десь посередині. Я б відповів словами Гете: «Кажуть, що між двома протилежними думками є істина. Ні в якому разі! Між ними лежить проблема». Так от, між цими думками істини немає. Тому що ГОСТи не розкривають практичних проблем сучасної розробки, а ті, хто їх критикує, альтернативи (конкретної та системної) не пропонують.

Зауважимо, що у ГОСТі явно не дано навіть визначення, сказано лише: «ТЗ на АС є основним документом, що визначає вимоги та порядок створення (розвитку чи модернізації - далі створення) автоматизованої системи, відповідно до якого проводиться розробка АС та її приймання під час введення у дію».

Якщо комусь цікаво, про які ГОСТи я говорю, то ось вони:

  • ГОСТ 2.114-95 Єдина система конструкторської документації. Технічні умови;
  • ГОСТ 19.201-78 Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення;
  • ГОСТ 34.602–89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи.

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

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

Саме головне, але єдине. Настав час взятися за головне: розкласти все «по поличках», як і обіцяв.

Що потрібно знати про вимоги? Необхідно чітко розуміти, що всі вимоги потрібно розділяти за видами та властивостями. Нині ми навчимося це робити. Для поділу вимог за видами нам допоможе ГОСТ. Той перелік видів вимог, який там представлений, є добрим зразком того, вимоги яких видів слід розглядати. Наприклад:

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

Думаю, для Вас очевидно, що ключовим фактором успішного Технічного завдання є добре сформульовані вимоги до функціональності. Саме цим вимогам присвячено більшість робіт та методик, про які я говорив. Вимоги до функціональності – це 90% складності робіт із розробки Технічного завдання. Решта найчастіше є «камуфляжем», який одягнений на ці вимоги. Якщо вимоги сформульовані погано, який красивий камуфляж на них не натягуй, успішного проекту не вийде. Так, формально всі вимоги будуть дотримані (за ГОСТом J), ТЗ розроблено, затверджено та підписано, гроші за нього отримано. І що? А далі почнеться найцікавіше: що робити? Якщо це проект на ДержЗамовленні, то проблем немає – там бюджет такий, що в жодну кишеню не влізе, у процесі реалізації (якщо вона буде) все і з'ясовуватиметься. Саме таким чином і пиляється більшість бюджетів проектів на ДержЗамовленнях (накалякали «ТЗ», злили десяток мільйонів, а проект робити не стали. Усіх формальностей дотримано, винних немає, нове авто біля будинку. Краса!). Але ж ми говоримо про комерційні організації, де гроші рахують, та й результат потрібен інший. Тому давайте розбиратися з головним, як розробляти корисні та працюючі Технічні завдання.

Про види вимог я сказав, а що ж із властивостями? Якщо види вимог можуть бути різними (залежить від цілей проекту), то з властивостями все простіше, 3:

  1. Вимога має бути зрозумілим;
  2. Вимога має бути конкретним;
  3. Вимога має бути тестованим;

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

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

  • якою мовою (у сенсі складності розуміння) має бути написане технічне завдання?
  • Чи мають бути описані у ньому специфікації різних функцій, алгоритми, типи даних та інші технічні штуки?
  • А що таке технічне проектування, про яке, до речі, сказано і в ГОСТах, і як воно пов'язане з технічним завданням?

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

Технічне завдання– це документ, в основі якого лежать вимоги, сформульовані зрозумілою (звичайною, звичною) для Замовника мовою. При цьому може і повинна використовуватися галузева термінологія, зрозуміла Замовнику. Жодних прив'язок до особливостей технічної реалізації не повинно бути. Тобто. на етапі ТЗ у принципі не важливо, на якій платформі реалізовуватимуться ці вимоги. Хоча є винятки. Якщо йдеться про впровадження системи на основі вже існуючого програмного продукту, то така прив'язка може мати місце, але тільки на рівні екранних форм, форм звітів та ін. бізнес аналітик.І аж ніяк не програміст (якщо він не поєднує в собі ці ролі, таке трапляється). Тобто. ця людина має говорити із Замовником мовою його бізнесу.

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

Що ми маємо на практиці? Забавно спостерігати, коли директору приносять на узгодження Технічне завдання, яке рясніє технічною термінологією, описом типів даних та їх значень, структури бази даних та ін. бізнес-вимог. Що, знайома ситуація? І що це закінчується? Зазвичай, таке ТЗ стверджується, потім реалізується, а 80% випадків потім зовсім відповідає факту виконаних робіт, т.к. багато чого вирішили змінити, переробити, неправильно зрозуміли, не так думали тощо. і т.п. А потім починається серіал про здачу робіт. "А ось тут не так як нам треба", а "це в нас працювати не буде", "це занадто складно", "це незручно" і т.д. Знайомо?!! Ось і мені знайомо, довелося набити шишок свого часу.

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

Ще невеликий, але важливий момент. Іноді Технічним завданням називають невеликий шматочок вимог, простий та зрозумілий. Наприклад, доопрацювати пошук об'єкта за будь-якими умовами, додати колонку у звіт тощо. Такий підхід цілком виправданий, навіщо ускладнювати життя. Але застосовується не так на великих проектах, але в дрібних доопрацюваннях. Я сказав би це ближче до супроводу програмного продукту. У цьому випадку в Технічному завданні може бути описано конкретне технічне рішення реалізації вимоги. Наприклад, «В алгоритм такий-то внести таку зміну», із зазначенням конкретної процедури та конкретної зміни для програміста. Це випадок, коли кордон між Технічним завданням і Технічним проектам повністю стирається, т.к. немає жодної економічної доцільності роздмухувати паперотворчість там, де це не потрібно, а корисний документ створюється. І це правильно.

А чи потрібне взагалі технічне завдання? А Технічний проект?

Чи не перегрівся я? Хіба таке можливо, взагалі без Технічного завдання? Уявіть собі можливо (точніше, зустрічається), і такий підхід має багато послідовників, і їх кількість збільшується. Як правило, після того, як молоді фахівці начитаються книг про Scrum, Agile та інші технології швидкої розробки. Насправді це чудові технології, і вони працюють, тільки в них не йдеться дослівно «не треба виконувати технічні завдання». У них говориться «мінімум паперів», особливо непотрібних, ближче до Замовника, більше за конкретику і швидше до результату. Але фіксування вимог ніхто не скасовував, і там це сказано. Саме там вимоги і фіксуються, виходячи з трьох чудових властивостей, про які я говорив вище. Просто у деяких людей так влаштована свідомість, що якщо можна щось спростити, то давайте це спростимо до повної відсутності. Як сказав Ейнштейн « Зроби так просто, як можливо, але не простіше за це» . Адже золоті слова, до всього підходять. Так що Технічне завданняПотрібно, інакше успішного проекту Вам не бачити. Інше питання, як складати і що туди вмикати. У світлі методологій швидкої розробки треба зосередитись лише на вимогах, а весь «камуфляж» можна відкинути. В принципі я з цим згоден.

А що ж із Технічним проектом? Цей документ дуже корисний і не втратив своєї актуальності. Більше того, часто без нього просто не обійтись. Особливо, якщо йдеться про передачу робіт із розробки набік, тобто. за принципом аутсорсингу. Якщо цього не зробити, є ризик дізнатися багато нового про те, як має виглядати система, яку Ви задумали. Чи повинен з ним знайомитись Замовник? Якщо хоче, чому ні, але наполягати і затверджувати цей документ немає жодної необхідності, він лише стримуватиме і заважатиме працювати. Спроектувати систему до дрібниць практично неможливо. В цьому випадку доведеться безперервно вносити зміни до Технічного проекту, що займає чимало часу. А якщо організація сильно забюрократизована, то загалом усі нерви там залишите. Якраз про скорочення такого роду проектування і йдеться у сучасних методологіях швидкої розробки, про які я згадував вище. До речі, всі вони базуються на класичному XP (екстремальному програмуванні) - підході, якому вже близько 20 років. Тож зробіть якісне Технічне завдання, зрозуміло Замовнику, а Технічний проект використовуйте як внутрішній документ для взаємовідносин між архітектором системи та програмістами.

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

Продовжимо дослідження питання: «Які вимоги включати до Технічного завдання?»

Формулювання вимог щодо інформаційної системи. Структура Технічного завдання

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

Як і будь-яку діяльність, формулювання вимог можна (і потрібно) поділити на етапи. Всьому свій час. Це важка інтелектуальна праця. І якщо ставиться до нього з недостатньою увагою, то результат буде відповідний. За експертними оцінками вартість витрат на розробку Технічного завдання може становити 30-50%. Я дотримуюсь такої самої думки. Хоча 50 – мабуть, перебір. Адже Технічне завдання – це ще останній документ, який має бути розроблений. Адже ще має бути технічне проектування. Такий розкид обумовлений різними платформами автоматизації, підходами та технологіями, які застосовуються проектними командами при розробці. Наприклад, якщо йдеться про розробку класичною мовою типу С++, то без детального технічного проектуваннятут не обійтися. Якщо йдеться про впровадження системи на платформі 1С, то тут із проектуванням ситуація дещо інша, як ми бачили вище (хоча, при розробці системи «з нуля», вона проектується за класичною схемою).

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

  1. загальні відомості;
  2. призначення та цілі створення (розвитку) системи;
  3. характеристика об'єктів автоматизації;
  4. вимоги до системи;
  5. склад та зміст робіт зі створення системи;
  6. порядок контролю та приймання системи;
  7. вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи у дію;
  8. вимоги до документування;
  9. Джерела розробки.

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

Розділ 1. Загальні відомості.

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

Розділ 2. призначення та цілі створення (розвитку) системи.

Рекомендації щодо ГОСТ Що з цим робити на практиці
Призначення системи З одного боку, з призначенням все просто. Але бажано формулювати конкретно. Якщо написати щось на кшталт «якісно автоматизувати складський облік у компанії Х», то потім можна довго обговорювати результат при його завершенні навіть незалежно від хорошого формулювання вимог. Т.к. Замовник завжди може говорити, що під якістю він мав на увазі щось інше. Загалом нервів можна зіпсувати один одному багато, а навіщо? Краще відразу написати приблизно так: «Система призначена для ведення складського обліку в компанії Х відповідно до вимог, зафіксованих у даному Технічному завданні».
Цілі створення системи Цілі – це безумовно важливий розділ. Якщо його вмикати, то треба вміти ці цілі формулювати. Якщо у Вас проблеми з формулюванням цілей, то краще взагалі виключити цей розділ. Приклад невдалої мети: "Забезпечити швидке оформлення документів менеджером". Що таке швидке? Це можна потім доводити нескінченно. Якщо це важливо, краще переформулювати цю мету так: «Менеджер з продажу повинен мати можливість оформити документ «Реалізація товарів» зі 100 рядків за 10 хвилин». Подібна мета може з'явитися, якщо, наприклад, в даний час менеджер витрачає на це близько години, що дуже багато для цієї компанії і для них це важливо. У такому формулюванні мета вже перетинається з вимогами, що природно, т.к. при розгортанні дерева цілей (тобто дроблячи їх на дрібніші пов'язані цілі), ми і так будемо наближатися до вимог. Тому захоплюватися не варто.

Взагалі, вміння виділяти цілі, формулювати їх, будувати дерево цілей – це тема абсолютно окрема. Запам'ятайте головне: вмієте – пишіть, не впевнені – взагалі не пишіть. А що буде, якщо не сформулювати цілі? Працюватимете за вимогами, таке часто практикується.

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

Розділ 4. Вимоги до системи

ГОСТ розшифровує перелік таких вимог:

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

Незважаючи на те, що основним, безумовно, буде розділ із конкретними вимогами (функціональними), даний розділтеж може мати велике значення (і здебільшого має). Що може виявитися важливим та корисним:

  • Вимоги до кваліфікації. Можливо, система, що розробляється, вимагатиме перепідготовки фахівців. Це можуть бути як користувачі майбутньої системи, так і IT-фахівці, які будуть потрібні для її підтримки. Недостатня увага до цього питання нерідко переростає у проблеми. Якщо кваліфікація наявного персоналу є явно недостатньою, краще прописати вимоги до організації навчання, програмі навчання, термінів тощо.
  • Вимоги щодо захисту інформації від несанкціонованого доступу.Тут коментарі зайві. Це і є вимоги до розмежування доступу до даних. Якщо такі вимоги плануються, їх потрібно розписати окремо, як можна детальніше за тими самими правилами, як і функціональні вимоги (зрозумілість, конкретність, тестируемость). Тому можна ці вимоги включити і в розділ з функціональними вимогами
  • Вимоги до стандартизації.Якщо існують будь-які стандарти розробки, які застосовуються до проекту, вони можуть бути включені до вимог. Як правило, такі вимоги ініціює ІТ-служба Замовника. Наприклад, у компанії 1С є вимоги до оформлення програмного коду, проектування інтерфейсу та ін;
  • Вимоги до структури та функціонування системи.Тут можуть бути описані вимоги до інтеграції систем, представлений опис загальної архітектури. Найчастіше вимоги до інтеграції виділяють взагалі окремий розділ і навіть окреме Технічне завдання, т.к. ці вимоги можуть бути досить складними.

Всі інші вимоги менш важливі і їх можна не описувати. На мій погляд, вони лише ускладнюють документацію і практичної користі несуть небагато. А Вимоги до ергономіки описувати як загальних вимог дуже складно, краще їх перенести до функціональним. Наприклад, може бути сформульована вимога «Отримати інформацію про ціну товару, натиснувши лише одну кнопку». На мій погляд, це все-таки ближче до конкретних функціональних вимог, хоч і відноситься до ергономіки. Вимоги до функцій (завдань), що виконуються системою. Навіть якщо все інше зробити на відмінно, а цей розділ на «3», то результат по проекту буде в кращому випадку на «3», а то й взагалі проект провалиться. Саме ці ми і займемося детальніше у другій статті, яка увійде до 5-го випуску розсилки. Саме до цього пункту належить «правило трьох властивостей вимог», про які я говорив. Вимоги до видів забезпечення

ГОСТ виділяє такі види:

  • Математичне
  • Інформаційне
  • Лінгвістичне
  • Програмне
  • Технічне
  • Метрологічне
  • Організаційне
  • Методичний
  • та інші…

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

  • Рішення про те, якою мовою (або якою платформою) буде вестися розробка не прийнято;
  • До системи пред'являються вимоги мультимовного інтерфейсу (наприклад, російська/англійська)
  • Для функціонування системи має бути створений окремий підрозділ або прийняті на роботу нові працівники;
  • Для функціонування системи у Замовника мають відбутися зміни у методиках роботи та ці зміни мають бути конкретизовані та заплановані;
  • Передбачається інтеграція з будь-яким обладнанням і до нього висуваються вимоги (наприклад, сертифікації, сумісності та ін.)
  • Можливі інші ситуації, все залежить від конкретних цілей проекту.

Розділ 5. Склад та зміст робіт зі створення системи

Розділ 6. Порядок контролю та приймання системи

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

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

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

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

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

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

Цей перелік може бути довгим, дивіться на конкретний випадок свого проекту. Створення необхідних функціонування системи підрозділів і служб;

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

Розділ 8. Вимоги до документування

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

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

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

Розділ 9. Джерела розробки

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

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

Але без головного: функціональних вимог жодне грамотно Технічне завдання не обходиться. Хочу зауважити, що на практиці такі Технічні завдання зустрічаються, та ще й як! Є діячі, які зможуть розвести води з усіх розділів, опишуть Загальні вимогизагалом, і документ виходить дуже важкий, і слів у ньому розумних багато, і навіть Замовнику може сподобається (тобто він його затвердить). Але працювати по ньому може не вийти, тобто. практичної користі від нього мало. У більшості випадків такі документи народжуються, коли треба отримати багато грошей саме під технічне завдання, а зробити його треба швидко і не занурюючись у деталі. А особливо якщо відомо, що далі справа не піде, або її робитимуть зовсім інші люди. Загалом просто для освоєння бюджету, особливо державного.

У другій статті говоритимемо лише про розділ 4 «Вимоги до системи», саме ми будемо формулювати вимоги з міркувань зрозумілості, конкретності і тестируемости.

Чому вимоги мають бути зрозумілими, конкретними та тестованими.

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

Чи тестована ця вимога? Начебто проста річ, але як її перевіряти, якщо немає конкретики?

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

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

  • Рядки в документ повинні додаватися як натисканням на кнопку «Додати», так і при натисканні на клавіші «insert», а також вводі користувачем частини найменування;
  • При перегляді списку товарів має бути можливість пошуку за найменуванням, штрихкодом та артикулом;
  • та ін.

Розмежування прав доступуДоступ до даних із прибутку має бути доступний лише фінансовому директоруЗрозуміло? Майже. Правда, прибуток буває різний, треба уточнити. Конкретно? Звичайно, ні. Як це бачиться у реалізації? Якщо мова йде про валовий прибуток, то необхідно обмежувати доступ до даних про вартість закупівлі, т.к. в іншому випадку валовий прибуток обчислити не складе труднощів, оскільки дані про вартість реалізації відомі широкому колу осіб. До того, що стосується прав доступу, треба ставитися дуже акуратно. А якщо у менеджерів з продажу мотивація побудована на валовий прибуток, то ці вимоги ще й суперечать одна одній, т.к. менеджери ніколи не зможуть перевірити це. Якщо вже включати таку вимогу, потрібно вказувати конкретні звіти та об'єкти системи, в яких вказувати, яка частина даних повинна бути доступна окремим категоріям осіб. І розглядати кожен такий випадок індивідуально. Продуктивність Звіт з продажу повинен формуватися за 1 хвилину. І навіть є конкретне обмеження часу: 1 хвилина. Але не відомо, яка деталізація при цьому передбачається: по кожному товару, групам товарів, клієнтам чи якось ще? Можна сформулювати приблизно так: «Звіт з продажу в розрізі клієнтів з деталізацією до кожної товарної позиції повинен виводитися не більш ніж за 1 хвилину за умови, що кількість товарів у вибірці не перевищує 5000 рядків».

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

Щоб у Технічне завданнябуло більше конкретики, є чимало рекомендацій. Навіть є список слів, які вживати в Технічному завданні не рекомендується. Цікаво про це пише К.Вігерс у своїй книзі «Розробка вимог до програмного забезпечення». Наведу найцікавіші та найпростіші, на мій погляд, рекомендації:

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

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

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

Види робіт під час збору вимог до системи обліку та інформації для опису бізнес-процесів. Частина 2

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

Як зазвичай відбувається у житті:

Як це відбувається у більшості проектів

Як це відбувається
Зрозуміло, що є привід для радості, особливо, якщо проект великий, нічого поганого в цьому немає! Головне, не радіти надто довго, відтягуючи початок фактичних робіт, з цієї хвилини час йтиме інакше.
Зазвичай цей процес обмежується кількома зустрічами з керівництвом, потім із керівниками підрозділів. Зафіксувавши деякі «позиви» із боку Замовника, вони фіксуються як загальних формулювань. Іноді до цього додають наявну документацію (хтось колись намагався вже поводити обстеження, документи з існуючих регламентів, форми звітів, що використовуються). Ну, трохи налаштувати і все буде працювати». На питання, чи треба обговорювати, як усе має працювати (або як виконується конкретний процес) з кінцевими користувачами, відповідь зазвичай негативна. Висловлюється думка, що керівник усе знає про своїх підлеглих. А дарма ... За цим ховається безліч пасток і перешкод, і здавання робіт може перетворитися на марафон смужкою з перешкодами. Як відомо, марафон прийнято бігати рівною дорогою, а біг з перешкодами можливий лише на коротких дистанціях (можна і не добігти).
Документування результатів роботи Після цього починається документування результатів залежно від цілей робіт: Якщо потрібно розробити Технічне завдання, консультант починає розсовувати отриману інформацію за заготовленим шаблоном документа, щоб і виглядало красиво, і основні вимоги були зафіксовані (ті, що озвучені від керівництва, а то можуть не затвердити). Розуміючи, що на практиці таке Технічне завдання особливо не використовується і доводиться все з'ясовувати "по ходу справи", головною метою Технічного завдання він ставить мінімальний час узгодження та затвердження. І, якщо вийде, інформація для зразкової оцінки вартості майбутніх робіт (до речі, теж важливо). Якщо потрібно описати бізнес-процеси. Як не дивно, але часто всі попередні дії виглядають аналогічно, як і у випадку розробки Технічного завдання. Різниця лише в оформленні документації. Тут можливі варіанти: консультанти описують процес довільними словами або використовують будь-які правила опису бізнес-процесів (нотації). У першому випадку такий документ виходить дивовижно схожим на Технічне завдання. Буває навіть таке, що якщо замінити титульний лист, жодної різниці не побачиш. В останньому випадку часто наголошують не на відповідності дійсності, а на «правильності опису», тобто. формальне дотримання правил опису. На жаль, обидва варіанти є не самою найкращою практикою, т.к. є скоріше формальністю, а користі приносять небагато.

Чому склалася така практика, як описано вище? Зізнаюся, я не знаю. У кого не спитай, ніхто не знає. При цьому ситуація змінюється не дуже швидко, хоча на цю тему постійно дискутують, обмінюються досвідом, пишуть книги… Мені здається, що одна з причин – низька якість відповідної освіти. Може ще позначається і те що, що багато фахівців приходить взагалі їх іншого бізнесу, і осягають все практично, тобто. їх досвід формується у тому середовищі, куди вони потрапили. Про ставлення ВНЗ та відсутність їхнього прагнення бути ближчим до реальності, теж факт відомий, але мене іноді дивує їхня позиція. Наприклад, у мене був випадок, коли дипломниця, талановитий фахівець, хотіла писати дипломну роботу на платформі 1С (хорошу галузеву розробку), але на кафедрі їй сказали, що незалежно від теми, на оцінку «відмінно» розраховувати не можна буде, т.к. 1С несерйозна система. Тут справа не в серйозності та об'єктивності такої думки, а в тому, що примітивне завдання класичною мовою програмування відразу вважалося гідним оцінки «відмінно».

Спробуємо надати розглянутому вище процесу більш системний підхід. Як він може виглядати тоді?


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

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

Погляньмо, як можна реорганізувати підхід до збору інформації про діяльність компанії.

Як це може відбуватися за більш грамотної організації робіт

Як це відбувається
Рішення прийнято, проекту бути! Тут нічого не змінюється щодо першого варіанта, емоції ніхто не скасовував
Провели нараду з керівниками, зібрали деяку інформацію про їхнє бачення результату. Цей крок також залишається, і він має велике значення. Але основне призначення першої зустрічі (або кількох зустрічей) із керівниками та власниками це знайомство. Знайомство насамперед із людьми та компанією. Сформульовані цілі та побажання на таких спільних зустрічах можуть бути різними, у тому числі фантастичними. Всі вони будуть, звичайно ж, вислухані, але не факт, що їх буде реалізовано. При глибшому зануренні в бізнес компанії будуть з'являтися інші цілі, так і відкидатися попередні. Я це до того, що з попередніх зустрічей не можна сформулювати чіткі цілі, все це потребуватиме ретельного опрацювання. Навіть просте здавалося б вимога може бути нереалізованим чи дуже трудомістким.
Формування робочої групи від Замовника та Виконавця, розподіл ролей Необхідно визначитися, хто працюватиме над проектом як з боку Замовника, так і Виконавця. Незважаючи на простоту даного етапу, він має дуже велику роль. Якщо не зафіксувати чітко, хто за що відповідає, під час реалізації робіт Ви ризикуєте зіткнутися з плутаниною. Якщо зі свого боку Ви завжди можете конкретизувати ролі у своїй команді, то у Замовника з цим можуть виникнути проблеми. На що слід звернути увагу: до складу робочої групи Замовника обов'язково мають увійти ті люди, які надалі хоч якось впливатимуть на прийняття результату. Якщо припустити ситуацію, що під час здачі робіт підключаться співробітники Замовника, які не брали участь у роботах щодо формування цілей та виявлення вимог, то проблеми гарантовані. Можлива навіть така абсурдна ситуація, що все, виявляється, зроблено не так, як вимагалося. У моїй практиці я стикався з такою ситуацією не раз. може брати участь у прийманні-здачі робіт. А найкраще прописати таке в договірних умовах (У договорі або Статуті проекту). Пам'ятаю, був такий випадок: в одному великому проекті засновник вирішив підключитися до процесу (не знаю чому, нудно бачити стало) і відвідав одну з робочих зустрічей, де обговорювалося питання формування рахунків клієнтам. Він із подивом для себе дізнався, що рахунок клієнту виставляє менеджер із продажу. У його поданні рахунок має виставляти бухгалтер і ніяк інакше. Але насправді бухгалтер взагалі не уявляв, про що йдеться, а менеджер не міг уявити, як так працювати, якщо за кожним рахунком бігати до бухгалтера. В результаті втратили купу часу, але нічого не змінилося, рахунок, як і раніше, виставляв менеджер. А засновник залишився на своїй думці, але більше в процес не втручався. На цьому етапі доцільно розробити Статут проекту, у якому зафіксувати ролі учасників, порядок комунікацій, регламент і склад звітності, і навіть решта, що слід прописати у Статуті. Розробка Статуту проекту це тема знову ж таки окрема.
Навчання проектної команди методикам та інструментам роботи, узгодження правил роботи, видів та складу документації По-перше, необхідно роз'яснити проектній команді все, що прописано у Статуті, як це застосовуватиметься на практиці. По-друге, проектну команду Замовника необхідно навчити тим методам роботи, які Ви збираєтеся використати на всіх наступних етапах. Має сенс обговорити формати документів, які будуть використовуватись, розглянути зразки. Якщо будуть застосовуватися будь-які правила опису моделей або бізнес-процесів, то треба обговорити і ці правила, щоб вони були зрозумілими.
Анкетування Етап анкетування дозволяє порівняно швидким способом отримати достовірний зріз інформації про компанію. Якість такої інформації визначатиметься трьома факторами:
  1. Насамперед тим, як Ви навчили проектну групу Замовника. Вони повинні чітко розуміти, як відбувається процес анкетування та вміти донести інформацію до всіх учасників.
  2. Сама форма анкет. Анкети мають бути зрозумілими. Бажано, щоб була інструкція із заповнення анкет. Ще краще, якщо буде приклад наповнення.
  3. Склад учасників. Необхідно правильно вибрати склад учасників. Якщо обмежитись лише керівниками, зібрати достовірну інформацію не вдасться. Я рекомендую включати до складу анкетування всіх, хто буде в майбутньому користувачем кінцевих результатів. Наприклад, якщо йдеться про впровадження автоматизованої системи, то варто включити всіх, хто буде користувачем. Бувають випадки, коли з 10 співробітників однієї посади знайдеться один, який виконує якусь особливу функцію, про яку ніхто з 9-ти більше не знає (наприклад, готує особливий звіт для керівництва). Якщо йдеться про подальший перерозподіл обов'язків або розробку посадових інструкцій, слід зробити аналогічно.

Звертаю увагу, що методика анкетування для подальшого впровадження автоматизованої системи або опис бізнес-процесів у правильному випадку відрізняється. Звичайно, структура анкет може бути і однакова, але це не найкращий варіант. Коли ми описуємо бізнес-процеси, то анкети зазвичай мають загальніший характер, т.к. невідомо точно, із чим доведеться зіткнутися. Якщо ж йдеться про впровадження конкретної автоматизованої системи, то краще мати анкети, що враховують особливості цієї системи. При такому підході можна відразу виявити всі вузькі місця системи, які не підходять для цього підприємства. Як правило, методики впровадження готових систем передбачають наявність таких анкет. Такі анкети можуть розроблятися або за окремими областями обліку (наприклад, облік замовлень, продажу, ціноутворення) або для конкретних посад (фінансового директора, наприклад). Склад питань приблизно однаковий.
Опитування Опитуванням називається проведення усної співбесіди з фахівцями з метою з'ясувати особливості окремих процесів. Необхідно організувати опитування так, щоб воно не виглядало як просто «зустрілися-поговорили», а організовано. Для цього потрібно підготувати так званий план опитування. До нього можна включити ті частини анкети, які викликають питання, суперечать відомостям інших анкет чи інформація представлена ​​поверхнево. Відповіді треба конспектувати в обов'язковому порядку. Ідеально, якщо Ви домовитеся про аудіозапис. На цьому етапі слід простежити за повнотою наданої інформації про документообіг (як форм первинних документів, так і різних звітів)
Виділення ключових бізнес-процесів або областей автоматизації Після анкетування та опитування можна обґрунтовано вважати, що інформації достатньо, щоб робити висновки щодо виділення ключових бізнес-процесів. Насправді, вже можна виділити не лише ключові бізнес-процеси, а й практично всі (якщо склад учасників було обрано правильно). Питання виділення бізнес-процесів це тема дуже окрема і не проста. Навчитися тут складно і виробляється переважно досвідом. З виділених бізнес-процесів слід скласти список (класифікатор). Потім можна буде приймати рішення, які з них слід досліджувати глибше, які ні, а також виділяти пріоритети.
Формулювання ключових вимог до системи, цілей, критеріїв успішності проекту, процесів для детального вивчення До цього етапу має бути зібрана вся первинна інформація про діяльність компанії, складено перелік бізнес-процесів. Тепер саме час повернутися до цілей, конкретизувати їх, за необхідності обговорити з першими особами компанії. При формулюванні цілей слід врахувати конкретні показники, при досягненні яких вважатимемо проект успішним. Якщо йдеться про впровадження автоматизованої системи, окремим переліком можна виділити вимоги до системи від ключових користувачів. Я це роблю у вигляді окремої таблиці, де всі вимоги згруповані за підсистемами, для кожної вимоги вказується автор вимоги, формулювання та пріоритет. Цю інформацію можна буде використовувати для складання плану розгортання системи (послідовності впровадження окремих підсистем), а також для пропозицій щодо подальшого розвитку системи (якщо окремі підсистеми в поточному проекті не планується впроваджувати). Якщо необхідно описати бізнес-процеси, приймаються рішення про процеси, які необхідно досліджувати більш детально.

От і дісталися питання «Що далі?». Далі розглядатимемо завдання опису бізнес-процесів та розробки Технічного завдання окремо. Я невипадково розглядаю ці завдання паралельно. Між ними справді багато спільного, що я хочу продемонструвати. Спочатку розглянемо послідовність робіт під час опису бізнес-процесів.


Що і як робити
Виділяємо бізнес-процес Із загального переліку бізнес-процесів, отриманого на попередніх етапах, виділяємо один (за пріоритетом) детального опрацювання. З рештою потім чинимо аналогічно.
Детальне вивчення бізнес-процесу Виділений бізнес-процес піддаємо детальному вивченню: аналізуємо отримані первинні документи, звіти та їх структуру, що використовуються в процесі програми, різні файли (наприклад, Excel), розмовляємо з кінцевими виконавцями. Збираємо різні ідеї про те, як можна покращити процес. Дуже корисно, якщо вдасться поспостерігати за процесом саме в тих умовах, в яких він виконується (не багато хто любить, коли за ними спостерігає, але що робити)
Графічний та/або текстовий опис бізнес-процесу (первинний) Отриману докладну інформацію починаємо описувати. Перш ніж описувати процес, треба визначитися, чи вимагатиме він графічного опису. Якщо процес простий і зрозумілий, функцій у ньому мало, і, графічне уявлення поліпшить його розуміння чи сприйняття, то треба витрачати цей час. І тут досить описати їх у текстовому вигляді у табличній формі. Якщо ж процес складний, з різними логічними умовами, краще навести його графічну схему. Діаграми завжди сприймаються легше. Якщо Ви вирішили описати процес у графічному вигляді, це зовсім не означає, що не треба наводити його текстовий опис. Тобто. текстовий опис процесу має бути у будь-якому випадку, причому виконаний за однаковою схемою. Зручно це робити у вигляді таблиці, де вказати: виконавців кожного кроку, яку інформацію вони отримують на вході, опис кожного кроку, яку інформацію формують на виході. Нижче подивимося на прикладі, як це може виглядати.
Погодження з виконавцями та власником бізнес-процесу Кращий спосіб зрозуміти, наскільки вдало ви вибрали стиль викладу інформації, це показати результат користувачам (виконавцям) процесу. На найголовніше в такій демонстрації це розуміння того, наскільки правильно Ви зрозуміли, як процес виконується. від виконавців цілком адекватного зворотного зв'язку. А якщо їм стане цікаво, то просуватися все почне набагато швидше. Виявлені уточнення та невідповідності необхідно відобразити в описі (актуалізувати), за необхідності операцію повторити.
Виділення показників бізнес-процесу Після того, як вироблено правильне розуміння, як виконується бізнес-процес, треба подумати над показниками, якими можна виміряти якість чи швидкість виконання процесу. Це не просто, але потрібно. Показник може бути вимірюваним, тобто. виражений у числовому вираженні і має існувати простий спосіб цю величину отримати. Якщо показник, що вимірюється, виділити неможливо, є ризик того, що бізнес-процес виділено невдало. Крім того, не буде можливості зрозуміти (адже виміряти не можна), приведуть зміни процесу до його поліпшення чи ні.
Остаточне документування бізнес-процесу Після того, як ми переконалися у правильному розумінні, як процес виконується (або має виконуватися), можна включати його до документації.
Далі можливі варіанти: аналізовані процеси будуть аналізуватися та оптимізуватися, розроблятися посадові інструкції, приймати рішення про необхідність автоматизації окремих процесів і т.д. Це може бути і окремий проект: опис бізнес-процесів.

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


Що і як робити
Виділяємо бізнес-вимогу/область автоматизації Виділення як вимог цілої області автоматизації (наприклад, «Складські запаси») практично використовується, проте, це найефективніший спосіб деталізації вимог. Область автоматизації є групою вимог, і розглядати їх краще за кожне окремо. Наприклад, «Облік надходження матеріалу на склад»
Детальне вивчення бізнес-вимоги Під детальним вивченням бізнес-вимоги розуміється те, як це хоче бачити і використовуватиме кінцевий користувач (зрозуміло, відповідно до цілей проекту). У технологіях розробки програмного забезпечення часто називають «варіант використання». Таким чином, детальне вивчення бізнес-вимоги зводиться до опрацювання варіантів використання. Приклад такого варіанту наведено у додатку 2 до статті. У найпростіших випадках варіанти використання зовсім не обов'язково малювати у вигляді графічних схем, можна обмежитися і текстовим формулюванням. Наприклад, вимога «Під час введення номенклатури ціна має розрахуватися як ціна закупівлі +20%» малювати не має сенсу. У вигляді діаграми є сенс представляти вимоги, об'єднані в область автоматизації, як показано в прикладі в додатку 2.
Моделювання вимог в інформаційній системі Ось воно! Як Ви, напевно, пам'ятаєте, я вже звертав увагу на цей найважливіший елемент у методиці розробки Технічних завдань. «Побудуй модель – отримаєш результат!» А що треба моделювати? Моделювати треба варіанти використання, отримані на попередньому етапі. Що має бути на виході моделювання? Повинна вийти демонстраційна програма, в яку внесені дані користувача, причому бажано звичні його (користувача) слуху, з урахуванням галузевої специфіки, актуальних проблем. І не просто так внесено, а має бути зрозуміло, звідки ці дані взялися, як розрахувалися. У цьому місці у читача мають виникнути питання:
  1. А що, якщо планується розробка нової системи і моделювати просто нема в чому?
  2. Що якщо для демонстрації не вистачає функціональності, і систему треба доопрацьовувати?

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

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

Доцільно супроводити таку модель текстовим описом, нехай навіть стислим, щоб користувач міг самостійно спробувати попрацювати з моделлю у вільний час. У цьому описі можна формулювати вимоги до доработок.
Демонстрація інформаційної моделі робочої групи Отриману модель показуємо Замовнику і розповідаємо, як усе має працювати. Демонстрацію моделі краще проводити підсистемами, тобто. за групами вимог. У випадку, якщо з'ясується, що у клієнта пропонована схема не працюватиме, треба подумати про інші варіанти використання, внести зміни в модель і показати ще раз. Тільки якщо є впевненість, що запланована модель у даного клієнта «житиме», можна вважати модель вдалою.
Розробка тестів Для чого потрібні тести? Те, як ми змогли реалізувати вимоги, потрібно перевіряти. Відповідно, на всі ключові ділянки, складні алгоритми та ін тести бажано зробити. У тому числі, ці тести можуть бути використані при здачі робіт. Зовсім необов'язково робити тести на кожну функцію системи, скрізь має бути здоровий глузд. Якщо йдеться про готову систему, то робити тест на «введення нового елемента до довідника клієнтів» буде виглядати безглуздо і марною тратою сил і часу. А якщо це зовсім нова система, таке цілком можливо. Навіщо робити тести, якщо ще немає системи? По-перше, розробнику буде зрозуміліше, чого від нього хочуть досягти. По-друге, ми полегшуємо життя тестувальнику (адже хтось тестуватиме результат розробки). Взагалі, тестування це окрема дисципліна, вельми не проста з безліччю методик. Насправді, зазвичай, однаково використовуються найпростіші методи тестування.
Документування вимог у вигляді Технічного завдання Зібрана інформація на попередніх етапах буде саме тим, що й має увійти в основу документа «Технічне завдання» у розділі з вимогами. Отже залишається все це грамотно оформити.
Подальші дії (або їх відсутність), залежно від цілей проекту Далі може початися процес розробки, пошук партнерів для проекту, тендер тощо, все залежить від ситуації.

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

Додаток 1. Описаний бізнес-процес у нотації EPC.

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

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

Зменшити ризики та підвищити можливість отримати інтернет-ресурс вашої мрії допоможе правильно складене технічне завдання на створення сайту.

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

  • Виконавцюграмотне ТЗ на розробку сайту допоможе заздалегідь оцінити обсяг роботи, її складність та вартість. Зрозуміти, чи впорається він із таким завданням самостійно, чи варто взяти помічників. А потім зробити саме те, чого від нього чекає замовник.
  • Замовникутехзавдання дає впевненість у тому, що він задокументував свої побажання до майбутнього сайту, чітко окреслив терміни, в які має вкластися виконавець, прописав вимоги до роботи сайту. І якщо результат виявиться незадовільним, можна пред'явити обґрунтовану претензію: "Не відповідає ТЗ!"

Як виглядає технічне завдання сайту?

Ваше побажання «блог з безкоштовними матеріалами, сторінкою про мене та контактами»виконавець бачить так:

Ви думаєте, що цього достатньо для створення сайту?

Ви отримуєте готовий сайт, і тут раптом виявляється, що ви мали на увазі ось це:


Нюанси опису дуже важливі

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

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

Про що пишуть у техзавданні?

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

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

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

  • Навіщо і для кого створюється сайт?
  • Чим він буде сповнений?
  • Як це все функціонуватиме?
  • Хто і як працюватиме над проектом, хто за що відповідає?
  • Що прийматиметься на виході?

Основні розділи технічного завдання на розробку сайту

1. Інформація про замовника, тобто про вас

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

2. Інформація про проект

Що це буде: сайт-візитка, інтернет-магазин, корпоративний портал, електронна бібліотека?

3. Цільова аудиторія сайту

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

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

4. Цілі та завдання, які має вирішувати сайт для замовника та для аудиторії

Це, напевно, головний розділ ТЗ на розробку сайту. Ви повинні чітко розуміти, навіщо вам потрібен web-ресурс. Для підвищення іміджу? Для прямого продажу? Ви хочете конвертувати відвідувачів у передплатників за допомогою сайту? Ви хочете створити ресурс для залучення потенційних партнерів?

Вказуйте пряме призначення вашого веб-сайту.

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

5. Рамки проекту (основний функціонал)

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

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

6. Структура (карта) сайту

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

Структуру зручніше малювати, ніж описувати. У графічному вигляді легко продумати взаємозв'язок областей сайту.


Схема взаємозв'язків окремих частин сайту

У нас на цю тему є вебінар «Система контенту сайту, що продає». І ось про структуру сайту, про взаємозв'язок сторінок та посилання між ними ми там докладно розповідаємо. Рекомендую! Картинка вище – із матеріалів цього вебінару.

7. Окремі сторінки

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

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

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

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

8. Вимоги до дизайну сайту

На цьому етапі будьте обережні. Виходьте з того, що дизайнер – професіонал. Не варто прописувати кожен крок. Не розповідайте: «Цю кнопку зроби з переливом з синього в червоний, а цей текст 12-м кеглем і щоб мерехтіло». Визначте основні побажання. Наприклад, покажіть існуючі сайти/банери/поліграфію, дизайн яких видається вам підходящим. Розкажіть про те, які кольори ви надаєте перевагу. Скажімо, ви хочете зробити сайт, присвячений жіночим тренінгам, дизайнер може «побачити» його в рожевих тонах, а вам подобається бузковий та помаранчевий. Загальний описпобажань допоможе знайти компроміс між вашим баченням та професійним поглядом дизайнера.

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

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

9. Робочий функціонал сайту

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

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

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

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

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

10. Опис контенту

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

11. Технічні вимоги

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


Чи не хочете отримати повне розчарування приймаючи сайт від розробника? Тоді уважно прочитайте цю статтю!

Але можливо, все ж таки провини його немає? Адже за результат будь-якого делегування відповідає не лише виконавець, а й замовник.

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

НАВІЩО ПОТРІБНЕ ТЕХ ЗАВДАННЯ?

  • Виконавцюграмотне ТЗ на розробку сайту допоможе заздалегідь оцінити обсяг роботи, її складність та вартість. Зрозуміти, чи впорається він із таким завданням самостійно, чи варто взяти помічників. А потім зробити саме те, чого від нього чекає замовник.
  • Замовникутехзавдання дає впевненість у тому, що він задокументував свої побажання до майбутнього сайту, чітко окреслив терміни, в які має вкластися виконавець, прописав вимоги до роботи сайту. І якщо результат виявиться незадовільним, можна пред'явити обґрунтовану претензію: "Не відповідає ТЗ!"

ПРО ЩО ПИШУТЬ У ТЕХЗАВАННІ?

У цих завданнях розглядаються такі питання:

  • Навіщо і для кого створюється сайт?
  • Чим він буде сповнений?
  • Як це все функціонуватиме?
  • Хто і як працюватиме над проектом, хто за що відповідає?
  • Що прийматиметься на виході?

ОСНОВНІ РОЗДІЛИ ТЕХНІЧНОГО ЗАВДАННЯ НА РОЗРОБКУ САЙТУ

1. Інформація про замовника, тобто про вас

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

2. Інформація про проект

Що це буде: сайт-візитівка, блог, інтернет-магазин, корпоративний портал, електронна бібліотека?

3. Цільова аудиторія сайту

Опишіть вашу цільову аудиторію, розкажіть, що їм потрібно і як їх можна зацікавити.

4. Цілі та завдання, які має вирішувати сайт для замовника та для аудиторії

Ви повинні чітко розуміти, навіщо вам потрібен web сайт. Для підвищення іміджу? Для прямого продажу? Для новин? Ви хочете конвертувати відвідувачів у передплатників за допомогою сайту? Ви хочете створити ресурс для залучення потенційних партнерів?

Вказуйте пряме призначення вашого веб-сайту.

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

5. Рамки проекту (основний функціонал)

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

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

6. Структура (карта) сайту

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

Структуру зручніше малювати, ніж описувати. У графічному вигляді легко продумати взаємозв'язок областей сайту.

7. Окремі сторінки

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

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

8. Вимоги до дизайну сайту

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

9. Робочий функціонал сайту

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

Яка форма? Для чого? Які пункти мають бути? Як вона виглядає? Цих нюансів виконавець може не вгадати, у результаті ви отримаєте зовсім не те, що хотіли. Гроші заплачені, проект відповідає ТЗ (ви ж написали «Календар»- Ось він), а вам доведеться задовольнятися тим, що вийшло, хоча це зовсім не те, чого хотілося, або переплачувати за зміни.

10. Опис контенту

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

11. Технічні вимоги

Складний пункт для тих, хто мало розуміється на сайтобудуванні.

Якщо не розумієтеся, включайте логіку.

Наприклад, ваш сайт повинен:

  • однаково добре виглядатиме моніторах різної ширини (адаптивний дизайн);
  • бути СЕО оптимізовано для просування;
  • вміти протистояти вірусам;
  • мати вбудований seo-функціонал тощо.

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