1. Крок 1: Вибір одиниці виміру проекту
2. Крок 2: Посилання на проведені дослідження
3. Крок 3: Заплановані витрати і виручка
4. Крок 4: Наявність можливостей на ходу змінити курс
5. висновок

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

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

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

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

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

Сумне ж завжди починалося через пару місяців після введення подібної системи в робочу експлуатацію:

• раптово виявлялося, що 90% всіх функцій ніхто не користується (не навчилися, немає бажання або просто незручні - не важливо),

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

• і все це домагається однозначними висновками, що з введенням нової системи на виконання тих же самих операцій стало витрачатися БІЛЬШЕ людино-годин, ніж раніше (з урахуванням найму адміністраторів, модераторів, операторів та іншого персоналу системи - які безпосередньо ніяк не впливають на зростання продажів лише за умови дотримання життєдіяльність бездушної машини).

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

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

Але які тут технічні вимоги до обладнання користувачів? Обмеження до пропускного каналу? До кваліфікації обслуговуючого персоналу? До прийняття відеоблогу в тестову, а потім в робочу експлуатацію?

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

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

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

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

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

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

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

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

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

Визначившись з початковими і необхідними ресурсами, а також їх форматом, приступаємо:

Крок 1: Вибір одиниці виміру проекту

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

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

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

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

Крок 2: Посилання на проведені дослідження

Кому і навіщо потрібна інформація про авторські права? Хто ці люди, як вони діють зараз, скільки будуть готові платити, скільки запитів в місяць варто очікувати?

Але досліджувати потрібно не тільки платоспроможність і потреби аудиторії, а й рівень додаткового навантаження, який ви їй пропонуєте. Так, раніше я вже неодноразово писав ( rb.ru/opinion/demotivation/ ), Що будь-які спроби автоматизації праці покоївок в номерах або монтерів колії на перегоні завжди гарантовано знижували якість головною роботи.

Це відбувалося і відбуватиметься завжди, оскільки, відволікаючись на екрани і кнопки інтерфейсу, - виконавець на 20-30% усього робочого часу - в результаті випадав з процесу роботи.

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

Крок 3: Заплановані витрати і виручка

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

• Витрати на розробку

• Витрати на персонал

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

• Поріг окупності

• Очікуваний прибуток

Отримані тут цифри найчастіше змушують замислитися над первісною концепцією.

Крок 4: Наявність можливостей на ходу змінити курс

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

висновок

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

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

ВІД редакції: розкажіть які найдивніші технічні завдання отримували ви? А поки Двайте згадаємо які статті Сергій Немеров писав для нашого блогу - це " словник юзабіліті "і про вимоги до юзабіліті мобільного сайту

Якщо Ви знайшли помилку, будь ласка, виділіть фрагмент тексту і натисніть Ctrl + Enter