Технічне завдання - це документ і текст, який пише менеджер проекту, пише його для себе, свого замовника, своєї проектної команди. І способів вживання у красивого технічного завдання багато.
Красива звичка - перед написанням будь-якого документа або тексту хоча б раз задуматися, задати собі питання: "А для чого ми його пишемо?". А також, для кого - хто його читатиме і що нам хочеться йому сказати своїми словами (так як в той прекрасний момент нікого більше поруч з читачем може і не виявитися).
Записування думок є кращий спосіб їх продумування
В першу чергу менеджер пише технічне завдання для себе. Найважливішим призначенням технічного завдання є сам процес його написання. Добре відома істина про те, що викладання думки словами сприяє більше чіткому усвідомлення Самоа думки, лежить в основі цього призначення
Менеджер проекту повинен добре, дуже добре і дуже чітко уявляти собі майбутній проект - чим повинен стати сайт. Що таке "сайт з точки зору менеджера проекту" - взагалі тема окремої розмови, тут же скажу про те, що для повного уявлення про сайт, що повинен мати менеджер, йому прийде глянути на проект по декількох сторін
Написання технічного завдання повинне допомогти менеджеру вирішити всі дрібні нестиковки між ідеями, які хоче закласти в сайт він, його замовник, геніальний дизайнер його проектної команди, парадигма реалізації, якою користується студія
Як висновок, формат технічного завдання повинен добре підходити для укладення та взаємної стикування всіх цих ідей і, в чому, формат технічного завдання буде завищить від "парадигми реалізації" (того, як розробники уявляють собі "правильну" функціонально-технічну реалізацію всієї закладеної в задачі функціональності же).
Опис сайту для нашого замовника
Друге сильне важливе призначення технічного завдання - бути описом сайту для нашого замовника. Замовник бачить сайт як щось, в більшості випадків дуже плоске і становить з "карти сайту" і "заголовної сторінки". Сайт ж, до його превеликий подиву, виявляється чимось великим і складним, - технічне завдання повинне допомогти замовникові вижити в цьому раптовому дисонансі
Опис сайту напевно, в кінцевому рахунку, зрозуміло для замовника. Крім того, всі "нижні" рівні цього опису повинні бути обумовлені верхніми - це допоможе замовнику рухатися "вниз" в процесі розуміння завдання. Красива, прозора структура також покращує понимаемость технічного завдання
Чекліст для прийому сайта
До речі, говорячи про розуміння, слід говорити відразу і про взаєморозуміння. Найнебезпечніша для розробників місце - прийом готового продукту. Якщо замовник і команда розробників добре один одного розуміють, то розбіжностей у прийомі не виникне. Технічне завдання служить для того, щоб менеджер міг показати "щось" замовнику і заявити "це відповідає таке- то частини ТЗ", а замовник радісно покивав головою або ж, навпаки, заглянув в ТЗ і вказав на щось, що завданню не відповідає
Сприймаючи технічне завдання як своєрідний "чекліст" для прийому сайта, легко опинитися в омані і почати доводити детальність завдання до запаморочливого рівня. Працюючи над технічним завданням, менеджер повинен деталізувати кожен його блок до того рівня, коли такі деталі стануть уже непринципові для замовника. Гарний же замовник повинен вважати принциповими ті деталі, які необхідні для його розуміння задуму розробника - але це зараз приватна відволікання про ролі "замовника" і "проектувальника".
Як висновок, технічне завдання як чекліст повинно містити деякий опис структури, оформлення, функціональності сайту, розбите на якісь блоки, які можна погоджувати і приймати по окремості; рівень детальності опису кожного блоку буде залежати від того, наскільки цей блок сам по собіебе принциповий для замовника (який у більшості випадків бачить "карту сайту" і "заголовну сторінку", на жаль).
"Тверда пам'ять" менеджера
Добре, що я спочатку зробив заголовки, а потім почав наповнювати статтю вмістом. Інакше я обов'язково б забув про цей пункт, тому що по ходу написання вже три рази відволікався. Тим часом, пункт якраз і стосується "безпам'ятному".
Я вже говорив, що будь-який проект виявляється тим успішніше, чим краще його ведучий (у нашому випадку - менеджер) уявляє собі цей проект - чим більше він сфальцованій на втіленні якогось певного уявлення (я навмисне опускаю питання про те, хто саме генерує це подання). Практично у будь-якої студії кожен менеджер одночасно "веде" кілька проектів, перекидаючись з одного на інший. Ця необхідність перемикання надзвичайно утрудняють "фокусування" - часто проекти починають змішуватися в голові у менеджера - і, якщо для реалізатора це все-таки припустимо, то для проектувальника може означати повний провал
Технічне завдання в нашому випадку виконує роль "твердій пам'яті", постійного сховища, яке включає в себе основні ідеї та концепції, а також намічений шлях їх реалізації. Менеджер може, перегорнувши технічне завдання, відновити цілісну картину проекту, як він його бачив - нехай і після двомісячної перерви. "Я, очевидець", але не "я, робот".
Творчість і самореалізація менеджера
І в останню чергу менеджер пише технічне завдання для себе ж. Одна, не єдина, але все-таки цінна радість менеджера проекту - красивий, наочний і добре состроенній текст технічного завдання.
"Я, очевидець", але не "я, робот". Менеджер проекту не може собі дозволити стати роботом, бездушним компонувальником блоків своїх же власних технічних завдань, будь вони сто разів як успішні і перевірені. Чому? Залишаю це на самостійне пророблення, якщо відповідь вам не очевидний
Разом з тим, окремі блоки технічного завдання обов'язки, і формат, і вміст їх у більшості випадків однаково. Це, наприклад, опис технічних вимог системи і підтримуваних стандартів. Менеджеру не слід витрачати свій час на багаторазове художнє виписування цих розділів, коли він пояснює собі і замовнику, який буде сайт
Замість висновку
Я спробував розповісти, навіщо і кому потрібно технічне завдання, і отримав, що потрібно воно головним чином менеджеру, вірніше, всім тим навколишнього його умовами, від яких він не може відмахнутися: замовник, проектна команда, інші проекти, які очікують своєї години. Наступного разу я буду намагатися встигнути розповісти і про те, яка структура ТЗ, і на якому обсязі документа слід зупинитися
Інший менеджер відмахнеться від моїх околофілософскіх міркувань, сказавши, що і без того добре уявляє собі сайт. Що сказати мені у відповідь? Напевно, нічого крім того, що я, починаючи писати цю статтю, "добре уявляв собі", що я там напишу. Однак, в процесі написання я таки пари раз міцно задумався і перекреслив кілька абзаців
Красива звичка - перед написанням будь-якого документа або тексту хоча б раз задуматися, задати собі питання: "А для чого ми його пишемо?". А також, для кого - хто його читатиме і що нам хочеться йому сказати своїми словами (так як в той прекрасний момент нікого більше поруч з читачем може і не виявитися).
Записування думок є кращий спосіб їх продумування
В першу чергу менеджер пише технічне завдання для себе. Найважливішим призначенням технічного завдання є сам процес його написання. Добре відома істина про те, що викладання думки словами сприяє більше чіткому усвідомлення Самоа думки, лежить в основі цього призначення
Менеджер проекту повинен добре, дуже добре і дуже чітко уявляти собі майбутній проект - чим повинен стати сайт. Що таке "сайт з точки зору менеджера проекту" - взагалі тема окремої розмови, тут же скажу про те, що для повного уявлення про сайт, що повинен мати менеджер, йому прийде глянути на проект по декількох сторін
Написання технічного завдання повинне допомогти менеджеру вирішити всі дрібні нестиковки між ідеями, які хоче закласти в сайт він, його замовник, геніальний дизайнер його проектної команди, парадигма реалізації, якою користується студія
Як висновок, формат технічного завдання повинен добре підходити для укладення та взаємної стикування всіх цих ідей і, в чому, формат технічного завдання буде завищить від "парадигми реалізації" (того, як розробники уявляють собі "правильну" функціонально-технічну реалізацію всієї закладеної в задачі функціональності же).
Опис сайту для нашого замовника
Друге сильне важливе призначення технічного завдання - бути описом сайту для нашого замовника. Замовник бачить сайт як щось, в більшості випадків дуже плоске і становить з "карти сайту" і "заголовної сторінки". Сайт ж, до його превеликий подиву, виявляється чимось великим і складним, - технічне завдання повинне допомогти замовникові вижити в цьому раптовому дисонансі
Опис сайту напевно, в кінцевому рахунку, зрозуміло для замовника. Крім того, всі "нижні" рівні цього опису повинні бути обумовлені верхніми - це допоможе замовнику рухатися "вниз" в процесі розуміння завдання. Красива, прозора структура також покращує понимаемость технічного завдання
Чекліст для прийому сайта
До речі, говорячи про розуміння, слід говорити відразу і про взаєморозуміння. Найнебезпечніша для розробників місце - прийом готового продукту. Якщо замовник і команда розробників добре один одного розуміють, то розбіжностей у прийомі не виникне. Технічне завдання служить для того, щоб менеджер міг показати "щось" замовнику і заявити "це відповідає таке- то частини ТЗ", а замовник радісно покивав головою або ж, навпаки, заглянув в ТЗ і вказав на щось, що завданню не відповідає
Сприймаючи технічне завдання як своєрідний "чекліст" для прийому сайта, легко опинитися в омані і почати доводити детальність завдання до запаморочливого рівня. Працюючи над технічним завданням, менеджер повинен деталізувати кожен його блок до того рівня, коли такі деталі стануть уже непринципові для замовника. Гарний же замовник повинен вважати принциповими ті деталі, які необхідні для його розуміння задуму розробника - але це зараз приватна відволікання про ролі "замовника" і "проектувальника".
Як висновок, технічне завдання як чекліст повинно містити деякий опис структури, оформлення, функціональності сайту, розбите на якісь блоки, які можна погоджувати і приймати по окремості; рівень детальності опису кожного блоку буде залежати від того, наскільки цей блок сам по собіебе принциповий для замовника (який у більшості випадків бачить "карту сайту" і "заголовну сторінку", на жаль).
"Тверда пам'ять" менеджера
Добре, що я спочатку зробив заголовки, а потім почав наповнювати статтю вмістом. Інакше я обов'язково б забув про цей пункт, тому що по ходу написання вже три рази відволікався. Тим часом, пункт якраз і стосується "безпам'ятному".
Я вже говорив, що будь-який проект виявляється тим успішніше, чим краще його ведучий (у нашому випадку - менеджер) уявляє собі цей проект - чим більше він сфальцованій на втіленні якогось певного уявлення (я навмисне опускаю питання про те, хто саме генерує це подання). Практично у будь-якої студії кожен менеджер одночасно "веде" кілька проектів, перекидаючись з одного на інший. Ця необхідність перемикання надзвичайно утрудняють "фокусування" - часто проекти починають змішуватися в голові у менеджера - і, якщо для реалізатора це все-таки припустимо, то для проектувальника може означати повний провал
Технічне завдання в нашому випадку виконує роль "твердій пам'яті", постійного сховища, яке включає в себе основні ідеї та концепції, а також намічений шлях їх реалізації. Менеджер може, перегорнувши технічне завдання, відновити цілісну картину проекту, як він його бачив - нехай і після двомісячної перерви. "Я, очевидець", але не "я, робот".
Творчість і самореалізація менеджера
І в останню чергу менеджер пише технічне завдання для себе ж. Одна, не єдина, але все-таки цінна радість менеджера проекту - красивий, наочний і добре состроенній текст технічного завдання.
"Я, очевидець", але не "я, робот". Менеджер проекту не може собі дозволити стати роботом, бездушним компонувальником блоків своїх же власних технічних завдань, будь вони сто разів як успішні і перевірені. Чому? Залишаю це на самостійне пророблення, якщо відповідь вам не очевидний
Разом з тим, окремі блоки технічного завдання обов'язки, і формат, і вміст їх у більшості випадків однаково. Це, наприклад, опис технічних вимог системи і підтримуваних стандартів. Менеджеру не слід витрачати свій час на багаторазове художнє виписування цих розділів, коли він пояснює собі і замовнику, який буде сайт
Замість висновку
Я спробував розповісти, навіщо і кому потрібно технічне завдання, і отримав, що потрібно воно головним чином менеджеру, вірніше, всім тим навколишнього його умовами, від яких він не може відмахнутися: замовник, проектна команда, інші проекти, які очікують своєї години. Наступного разу я буду намагатися встигнути розповісти і про те, яка структура ТЗ, і на якому обсязі документа слід зупинитися
Інший менеджер відмахнеться від моїх околофілософскіх міркувань, сказавши, що і без того добре уявляє собі сайт. Що сказати мені у відповідь? Напевно, нічого крім того, що я, починаючи писати цю статтю, "добре уявляв собі", що я там напишу. Однак, в процесі написання я таки пари раз міцно задумався і перекреслив кілька абзаців
No comments:
Post a Comment