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

Павло Молянов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Техзадание становить виконавець

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ми вказуємо:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

Від того, наскільки точно складено технічне завдання на доопрацювання 1С, безпосередньо залежить, чи будуть вирішені поставлені перед розробниками завдання. Разом з тим при роботі з таким документом існують деякі складності. В широкому розумінні в ТЗ прописані норми при створенні і модернізації автоматизованої системи (АС), а також порядок робіт. Сюди ж входить і звід стандартів запуску проекту. Це розуміння ролі технічного завдання продиктовано вимогами ГОСТ 19.201-78 і 34.602-89, згідно з якими ведеться розробка ТЗ для 1С. Є й інше тлумачення значення цього документа, більш наближене до практики.

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

Яким має бути ТЗ?

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

Основні помилки в технічному завданні на розробку 1С

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

1. Повторення деяких розділів у різних інтерпретаціях.
2. Інформація дається безладно. В ідеалі вона повинна ставитися до певної структури, наприклад бізнес-процесів або модулів системи.
3. Інформація в різних розділах подається з різним ступенем деталізації.

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

Після перегляду замовником зразок ТЗ на доопрацювання 1С може змінитися і не завжди в кращу сторону. Це в свою чергу зазвичай заважає програмістам правильно сприймати інформацію. Особливо це стосується фахівців з невеликим досвідом. На цьому етапі часто виникають такі помилки:

1. Вимоги різних розділів суперечать один одному.
2. Формулювання виявляються неточними.
3. Місцями інформація надмірно деталізована.

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

Як уникнути помилок при розробці ТЗ?

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

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

Основні правила при складанні технічного завдання на розробку звіту та інших елементів 1С:

1. ТЗ створюється спільно виконавцем і замовником.
2. До роботи програмістів повинні пред'являтися тільки об'єктивні вимоги. Для успішної розробки проекту суб'єктивне бачення замовника повинно бути зведене до мінімуму.
3. Потрібно детально описувати результат, який потрібен замовнику. При цьому в прикладі технічного завдання на розробку конфігурації 1С необхідно прописувати всі параметри, за якими повинен працювати елемент. Інакше результат може сильно відрізнятися від бажаного.
4. Ризики виконавця і замовника повинні бути приблизно рівні і зведені до мінімуму.
5. Не можна застосовувати терміни, які використовуються в діловому спілкуванні і не застосовуються в конкретній галузі.

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

Небезпека неправильного складання ТЗ

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