Якось раз мій добрий товариш Інокентій, на сьогоднішній день вельми успішний PM і чудовий фахівець, запитав: «Як ти думаєш, з якої фрази починається дорога в пекло?». Я здивовано підняв брову. «З фрази: А давайте працювати без ТЗ», — відповів він і розповів мені вельми повчальну історію.
Як Кєша сайт робив
Років п’ять тому він працював маркетинг менеджером в одній середніх розмірів конторі. Займався, як водиться, усім: вигадував зовнішню рекламу і відео-ролики, строчив тексти, відповідав за мерчендайзинг на торгових точках, загалом, був і женцем, і на дуді гравцем. Ніхто вже не пам’ятає, як саме прогрес дістався до цієї компанії, але одного чудового дня керівництво вирішило, що їхній фірмі терміново необхідний веб-сайт. Керувати проектом розробки, призначили якраз мого приятеля.
З компанією підрядником визначалися не довго. З легкої руки директора було обрано студію чоловіка подруги дружини — «світові хлопці, Люся завжди про них добре відгукувалася». Після першої ж зустрічі було вирішено, що завдання стоїть абсолютно просте — запиляти сайт-візитку.
Хлопці вже 1000 разів таке робили і були повністю впевнені, що впораються швидко і без проблем. На спробу Антона щось сказати про планування проекту розробники тільки посміхнулися: «Та чого тут думати? Тут робити потрібно». «І якомога швидше — он у конкурентів уже місяць як сайт є», — підтримав хлопців голова відділу продажів, — «ти думаєш мені просто на зустрічі ходити ганьбитися? Усі й так думають, що ми відсталі». Наприкінці зборів було вирішено, що сайт має бути готовий за півтора місяця і не хвилиною пізніше.
«Коли я помру, і за мною з’являться чорти», — говорив мені Кєша, — «вони теж скажуть, що завдання зовсім просте. З кожним новим кроком вони розповідатимуть мені про те, що згадали про якусь дріб’язкову функцію, яка від самого початку малася на увазі і була всім і так очевидна…»
Проблеми почалися майже одразу: спершу, розробники повернулися через 2 тижні після вищезгаданих зборів і принесли не те. Мій товариш так їм і сказав, після чого хлопці ображено пішли переробляти. Пізніше, коли вони прийшли з більш відповідним варіантом, на Інокентія чекав новий сюрприз. У процесі демонстрації продукту колегам він з’ясував, що ті уявляли корпоративний сайт зовсім інакше. На їхню думку, все потрібно було терміново переробити. Ось із цього моменту почалося Кєшине персональне пекло.
Спершу він з кожним днем лаявся з колегами, пояснюючи, що сайт-візитка не передбачає можливості прямого продажу продуктів через інтернет і вирішує зовсім інші завдання.
Коли стало зрозуміло, що продукт треба здати у вересні, а надворі вже серпень, а рішення все немає, до розглядів долучилися ТОП-менеджери, і розмовляти вони стали виключно на підвищених тонах. Керівництво обмежувалося риками: «Це так не працює, а як потрібно — ми не знаємо, вирішіть проблему!»
У результаті робота, яка мала тривати два місяці, розтягнулася майже на півроку, бюджет проєкту зріс удвічі, а Кєша зрештою звільнився з компанії і почав свою кар’єру в IT.
Банальний, але важливий документ
Робота без ТЗ — це шлях у пекло. Дорогою губляться гроші, час, нерви, терпіння, вмирають проєкти і ламаються життя. Це не тільки Кєшина думка. Усе дуже логічно — ТЗ — це не просто документ — це інструмент, який вирішує низку конкретних завдань. Щоб поміняти колесо в машині, вам потрібен домкрат, щоб розробити ефективний IT-проект, вам потрібно ТЗ. Навіщо? Ось тільки частина причин:
- ТЗ акумулює в собі прийняті ідеї. Саме цей документ фіксує рішення, з якими згодні всі відповідальні особи даного проєкту. Якщо ви не хочете сваритися з колегами як Кєша — ТЗ ваш шлях до успіху.
- ТЗ — це біблія як для розробника, так і для замовника. Воно дає можливість з’ясувати, чи відповідає кінцевий продукт заявленим критеріям, і дізнатися, хто правий, а хто винен у неоднозначних ситуаціях.
- Давайте не забувати про те, що ТЗ — це юридичний документ. Найчастіше воно є додатком до договору на розробку.
Найголовніша функція технічного завдання в тому, що воно описує, який вигляд має мати і працювати якісний продукт. Нескладно здогадатися, що якщо врешті-решт ви хочете отримати саме такий результат — не варто нехтувати ТЗ. З вами можуть сперечатися і говорити, що:
- Ми хочемо копію продукту конкурентів — навіщо нам ТЗ?
- Наш проєкт — це комерційна таємниця і ми нікому про нього не розповімо.
- Ми ще не знаємо, чого хочемо в підсумку і хочемо розглянути різні варіанти.
Ну або вже зовсім перли на кшталт «раптом у нас/вас зміниться концепція?» або «ми спочатку хочемо зрозуміти, скільки наш/ваш проєкт коштуватиме».
На жаль, таку маячню іноді можна почути не тільки від клієнтів, а й від розробників, адже якісна оцінка проєкту — витратна стаття для аутсорсингової компанії, а розробка докладного ТЗ може не окупитися, якщо клієнт скасує замовлення. Замовник може взагалі не заплатити за таку роботу, оскільки в наших реаліях досі заведено вважати кінцевим продуктом винятково готовий сайт або застосунок, а ТЗ — це так, каракулі.
Що таке технічне завдання в IT-розробці
Давайте уявимо, що технічне завдання (ТЗ) в IT — це ваша кулінарна книга для приготування ідеальної програмної «страви». Не просто список інгредієнтів, а повна рецептура успіху. Тільки замість томатів та базиліка тут функціонал та інтерфейси.
Що ми варимо? ТЗ визначає, що саме має робити ваш IT-проект. Це як вказати, чи будемо ми готувати спагеті болоньєзе, чи веганський бургер — деталі мають значення.
Рецепт успіху. У ТЗ описується кожен крок розробки, щоб уникнути «пересолу». Це ваша дорожня карта від задуму до реалізації, де кожен поворот прописаний.
Для кого готуємо? ТЗ допомагає всій команді готувати «на одній кухні». Замовник впевнений, що отримає те, що замовляв, а розробники точно знають, які «страви» потрібно приготувати.
Інструкція із застосування. ТЗ — це не просто план, це інструкція для всіх учасників проєкту. Як у рецепті, де вказано час приготування і температуру, ТЗ регламентує терміни і технічні аспекти.
Шлях до майстерності. Створення ТЗ — це не прогулянка супермаркетом. Це скрупульозний процес, що включає обговорення, аналіз і документування.
Навіщо все це? Без ТЗ легко заблукати в лісі IT-розробки. Воно допомагає уникнути непорозумінь, скорочує ризики, захищає інтереси всіх сторін і забезпечує точне планування.
Ось і все! Тепер, коли ви знаєте, що таке ТЗ, ви готові створювати IT-проєкти, які будуть «смачними» та вдалими. І пам’ятайте, що хороший рецепт — це половина успіху в приготуванні шедевра.
Функції ТЗ в IT-розробці
Технічне завдання в IT-розробці виконує кілька ключових функцій:
- Уточнення та фіксація вимог. ТЗ точно визначає вимоги до проєкту, включно з функціональними і нефункціональними аспектами, забезпечуючи ясність і розуміння цілей проєкту.
- Комунікація між учасниками проєкту. ТЗ слугує основою для спілкування та узгодження між усіма зацікавленими сторонами, включно із замовниками, розробниками та керівниками проєкту.
- Планування та управління проєктом. ТЗ допомагає у створенні плану проєкту, визначенні термінів, ресурсів та етапів розробки.
- Оцінювання та контроль якості. ТЗ надає критерії, за якими можна оцінювати прогрес і якість продукту на різних етапах його розробки.
- Юридичний захист. Як документ, ТЗ може використовуватися в юридичних цілях для захисту прав і зобов’язань усіх сторін, що беруть участь у проєкті.
- Гнучкість і адаптація. ТЗ дає змогу адекватно реагувати на зміни в проєкті, забезпечуючи можливість коригування цілей і вимог у процесі розроблення.
Кожна з цих функцій ТЗ в IT-розробці має ключове значення для успіху проєкту. Воно забезпечує чітку орієнтацію, запобігає непорозумінням і конфліктам, сприяє ефективному плануванню та управлінню, забезпечує високу якість розробки і служить захистом інтересів усіх учасників. У підсумку, добре складене ТЗ значно підвищує ймовірність своєчасного й успішного завершення IT-проєкту, мінімізуючи ризики та потенційні витрати.
ТЗ не просто документ, а критично важливий інструмент в арсеналі кожної команди розробників, що гарантує чіткість, якість і ефективність роботи над проєктом.
Що головне в технічному завданні
«Все важливо, але щось важливіше!» — так можна охарактеризувати головні аспекти в технічному завданні. Ось на що варто звернути особливу увагу:
- Якщо ТЗ написано мовою стародавніх шумерів, ніхто не зрозуміє, що від нього хочуть. Ясність і простота формулювань — ваш найкращий друг.
- Повний опис функціоналу. Це як «повний список інгредієнтів» для вашого проєкту. Не забудьте про «приправи» — дрібні, але важливі деталі.
- Узгодженість із замовником. ТЗ не має бути одностороннім. Це діалог, а не монолог. Переконайтеся, що замовник киває головою, а не дряпає її в подиві.
- Світ не стоїть на місці, і ТЗ теж. Готовність до змін — це не слабкість, а знак уміння адаптуватися.
- Пам’ятайте, ТЗ — це не просто план, а й документ. Добре, якщо він захистить вас, якщо щось піде не так.
- Тестові сценарії та критерії приймання. Це ваш контрольний список перед «здачею страви». Переконайтеся, що все приготовлено правильно.
Тож, коли писатимете ТЗ, пам’ятайте: воно має бути чітким, повним, узгодженим, гнучким, захищеним і перевіреним. Це як рецепт успіху, тільки в IT.
Що має бути в технічному завданні в IT-розробці
Подумаймо про технічне завдання як про рецепт для шеф-кухаря: що має бути в цьому «кулінарному шедеврі»?
- Опис проєкту. Перший шматочок — смачний вступ. Тут ми говоримо про цілі та завдання проєкту.
- Вимоги до функціоналу. Це як список інгредієнтів. Що має вийти в результаті? Електронна комерція? Інтерактивний додаток? Усе вказуємо!
- Інтерфейс і дизайн. Це про те, який вигляд матиме наш «кулінарний шедевр». Прототипи, макети, опис користувацького інтерфейсу.
- Нефункціональні вимоги. «Приправи» типу безпеки, швидкості роботи, сумісності.
- Критерії прийому роботи. Як ми зрозуміємо, що страва готова? Тести, критерії успішності проєкту.
- Бюджет і терміни. «Скільки солі?» — питання не тільки про спеції, а й про ресурси та час.
Підходьте до складання ТЗ творчо, але систематично. І пам’ятайте, хороший рецепт – це півсправи на шляху до смачного IT-проєкту!
Що потрібно менеджеру, щоб правильно працювати з технічним завданням
Ось кілька порад, які допоможуть проєктному менеджеру ефективно працювати з технічним завданням:
- Вивчіть основи. Розуміння базових IT-концепцій і термінології спростить взаємодію з командою розробників.
- Спілкування з розробниками. Навчіться говорити з розробниками їхньою мовою, щоб краще розуміти їхні потреби та очікування.
- Аналіз вимог. Розвивайте навички аналізу та оцінювання вимог проєкту.
- Увага до деталей. Особливу увагу приділяйте деталям ТЗ, щоб уникнути непорозумінь.
- Гнучкість і адаптивність. Будьте готові до змін у ТЗ і вмійте швидко на них реагувати.
- Юридичні аспекти. Розумійте юридичний бік ТЗ, щоб захистити інтереси вашої компанії.
- Управління ресурсами та термінами. Розвивайте навички планування та управління ресурсами.
Курс TechMind від IAMPM може значно допомогти в цьому. Він надасть вам знання про те, як обирати архітектуру, фреймворк і команду для проєкту, аналізувати вимоги, створювати прототипи продукту, працювати з API-документацією та Git, а також розуміти процеси в різних типах розробки. Опанування цих навичок полегшить вам взаємодію з технічними командами та допоможе ефективно керувати проєктами IT-розробки.
Плюси роботи без ТЗ
Чи є якісь плюси від роботи без ТЗ? Тільки в тому разі, якщо у вас збочене почуття прекрасного:
- У вас є свобода прийняття рішень — за яку потім доведеться дорого платити.
- Відсутністю ТЗ можна обґрунтувати підвищену невизначеність і закласти бюджет на всілякі «сюрпризи», якщо, звісно, вам дадуть це зробити, однак після початку роботи думати про це буде вже пізно.
- Формування і перевірка ТЗ вимагають вкладення часу і сил до початку основної роботи. Відсутність ТЗ дає змогу ці зусилля перенести на пізніший термін, щоправда в цьому разі частину вже зробленої роботи доведеться переробляти.
- Ви завжди можете «переграти» на свою користь погано проговорені моменти. Особливо, якщо ви майстер скоріше слова, ніж справи.
Перераховані «плюси» — це жарт, схожий на шкідливі поради Григорія Остера. Я наполегливо рекомендую не перевіряти їх на собі та своїх проєктах. Результат може бути плачевним — доведено Інокентієм. Саме тому я вирішив випустити цілий цикл статей про технічне завдання і те, як правильно його розробляти. Не будь як Кєша — пиши ТЗ!
Висновок
Технічне завдання — це не просто формальність, а ключовий інструмент в управлінні IT-проєктами. Воно допомагає всім учасникам проєкту залишатися на одній хвилі, мінімізує ризики і непорозуміння, і є основою для успішної реалізації проєкту. Вивчення основ IT, взаємодія з розробниками, увага до деталей, гнучкість і правильне управління ресурсами — ось складові успішного управління ТЗ. Курси, такі як TechMind від IAMPM, можуть значно полегшити цей процес, надаючи необхідні знання та навички для ефективного управління IT-проєктами.