Как сами да напишете техническа задача
Много компании не са готови да включат изпълнители на етапа на писане на техническото задание, вярвайки, че всеки изпълнител ще напише документ, разбираем само за неговите служители, като на практика си гарантира привилегирована позиция в конкурса/търга.
Това е отчасти вярно, но в много случаи това явление е свързано не толкова с меркантилните интереси на изпълнителите, колкото с различията в подхода към прилагането на този документ.
Дефиницията на техническото задание в Wikipedia по-специално гласи, че това е „документ, съдържащ изискванията на клиента към обекта на поръчката, определящ условията и реда за неговото изпълнение за задоволяване на държавни или общински нужди, в съответствие с които се извършва доставката на стоки, извършването на работа, предоставянето на услуги и тяхното приемане.
Освен това има редица GOST, например 19.201-78, които посочват какво и в каква форма трябва да се съдържа в такъв документ.
Въпреки това, както показва практиката, заветното съкращение "TK" се отнася за документи, които са напълно различни по същество, съдържание, дизайн и детайли. За съжаление много клиенти са сигурни, че след като напишат няколко страници с изисквания за бъдеща система, те ще получат от нас точна оценка (с максимална делта от 10-20%) с работен график. Още веднъж, когато получа по пощата „TK, според който до утре е необходимо да се оцени и изпрати CP“, винаги се подготвям психически да видя следващото творение в стил „системата трябва да обменя цялата необходима информация със сайта“.
Едно време в отдела, в който работех, беше прието следното разделение:Техническо задание, по-подробно, описващо подробно всички функции, но вече на език, разбираем предимно за разработчиците .
Няма да описвам основните изисквания за структурата на документа, като например: целите на проекта трябва да бъдат описани в ТЗ, трябва да се съдържат функционални изисквания, трябва да има списък със съкращения и съдържание, всичко трябва да бъде написано с максимално прости и кратки фрази и т.н. Мисля, че това е известно на всеки, който е прочел техническите характеристики поне няколко пъти.
Документите, с които трябваше да работя и въз основа на които се получиха максимално близки до идеята резултати, имаха следните свойства:
1.TK като инструкция. Документът по своята структура прилича на ръководство за потребителя, където е написано стъпка по стъпка в какъв случай какви действия трябва да извърши потребителят, за да получи желания резултат. Тези. това бяха документи без непрекъснат списък от необходими функции, но с логично разпределение на отделни процеси с описание на техните специфики
2.Повече визуализация. Колкото повече оформления/екранни снимки/макети/блок-схеми съдържа един документ, толкова по-малка е вероятността да получите система, която изглежда изпълнява необходимите функции, но има напълно различна логика/дизайн/интерфейс.
3.Използваемост.От предходните две точки има проста последица - ясната логика на работа и максималната визуализация на бъдещата система в крайна сметка ще помогнат да се постави в ТЗ необходимия брой бележки / точки по отношение на използваемостта на системата. За системи, с които работят нискоквалифицирани служители, това може да бъде решаващ фактор за успеха на проекта (но този параметър е изключително важен и за топ мениджмънта, който не иска да се занимава с "тези счетоводни програми"). Например в ТЗв системата за продажби на дребно не е посочено, че търсенето на артикул не трябва да отнема повече от три секунди. Ако системата беше внедрена чрез типично търсене на конфигурация, това може да доведе до критични ситуации в реална работа, т.к като се има предвид броя на артикулите, това търсене отне до 30 секунди, което е недопустимо при работа с клиенти на дребно, където всяка секунда е от значение.
4.Връзки към популярни решения. Често за всички, например мениджърите по продажбите на компанията, фразата „транзакционна функционалност“ означава приблизително едно и също нещо, но за служителите на изпълнителя тази фраза не означава абсолютно нищо. Но добавете няколко думи към тази фраза и от опцията „карта за сделка, подобна на тази в Bitrix24 (или 1C: CRM)“, вече е ясно какво очаква Клиентът от същата карта.
5.Първична обратна връзка. Повтарям още веднъж - за успешното прилагане на TK не е необходимо да го пишете в съответствие с GOST. Няма нужда да пишете документ, предназначен само за технически специалисти. Техническото задание преди всичко трябва да е ясно на колегите от създателя му, а след това и на тези, които ще го реализират. Изключително важно е да получите положителна обратна връзка от други бизнес потребители, преди да препратите документ на потенциални изпълнители или вътрешно развитие. Документ, който е пределно ясен за един човек, но неразбираем дори за най-близкото обкръжение, няма шанс за успешно изпълнение.
Разбира се, има различни гледни точки относно изискванията за изготвяне на ТЗ. Въпреки това, при липса на необходимото време, ресурси и компетенции, именнотехническите условия, написани на най-разбираемия език за бизнес потребителите, притежават горните свойства, ще имат максимални шансове за успешно изпълнение.