середу, 30 жовтня 2013 р.

Як замовити якісний сайт. Частина 4.

Сьогодні хочу поговорити на тему: чи існує ідеальне технічне завдання (ТЗ).

І відразу дам відповідь: не існує.

Так до чого ж тоді взагалі ця тема, запитаєте Ви. А до того, що незважаючи на те, що таки його, ідеального, не існує, без нього неможливе створення жодного продукту, не лише сайту.
Ідеальне ні, але правильне, хороше, відмінне ТЗ — основа порядку. Його буде читати 2 людини (абстрактно, звичайно) — клієнт і розробник, по ньому буде виконуватись робота, по ньому вона і буде здаватись.
Додам, що жоден розробник не почне роботу без технічного завдання, де буде чітко і ясно описано куди, що, навіщо і коли. Тут я мала на кваліфікованого високскілованого розробника, а не "тижпрограміст"/племінник/син/братдружиникума... Проїхали ;)

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

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

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

Наступне питання, яке завжди задають чи то на етапі написання ТЗ чи то вже на етапі розробки:

чи можемо ми випустити швидко неповнофункціональний продукт?

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

Для кого пишемо ТЗ?

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

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

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

Немає коментарів:

Дописати коментар