Фото: не помню откуда
Техническое задание (ТЗ) - это юридически значимый документ, основная цель которого состоит в устранении конфликтов между исходными данными, между имеющимся бюджетом и требуемым функционалом, а также между ожиданиями Заказчика и Исполнителя. Чем подробнее в ТЗ описана конечная цель и условия её достижения, тем меньше будет нежелательных событий в процессе разработки и при сдаче результатов работ.
Постановка задачи
В идеальном варианте техническое задание разрабатывается и оформляется по ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению», ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», ГОСТ Р 7.0.97-2016 «Требования к оформлению документов» и ещё много чего другого - при наличии у Заказчика такого документа слова неуместны: работаем. К сожалению, количество подобных событий оставляет желать лучшего и, в основном, неладно «... что-то в Датском государстве ...» (С): Заказчик «чувствует» ЧТО ему нужно, но с формулировками беда. Такие задачи неопределённости прогрессивное человечество решает через аппроксимацию и экстраполяцию.
Для начала очередного этапа Заказчик формулирует в любом виде критичные, т.е. самые главные с его точки зрения, характеристики предмета разработки и отправляет их Исполнителю. Последний, в свою очередь, создаёт из полученной информации текстовый вариант ТЗ в профессиональных формулировках, а недостающую с его точки зрения информацию добавляет по своему усмотрению и отправляет результат обратно. Заказчик получает, читает это самое «по своему усмотрению», добавляет нужное, удаляет ненужное и опять к Исполнителю, ... - Заказчик - Исполнитель - Заказчик - Исполнитель - ... В результате нескольких подобных итераций получаем искомое техническое задание.
Субъект действия
Заинтересованного в результате человека, который хотя бы на обывательском уровне понимает внутренние механизмы и структуру целевого технологического процесса, видно - даже невооружённым глазом видно: по ответам, по задаваемым вопросам, по поведению. Такие субъекты ценят своё время и максимально концентрируются на решении задачи, поэтому за одну вышеописанную итерацию «..-Заказчик-Исполнитель-..» формируется 15-20 процентов смыслового наполнения технического задания, а примерно через неделю появляется конечный вариант документа.
Основная же масса соискателей ищет причины, чтобы максимально дистанцироваться от процесса формирования требований к предмету разработки - не хочет тратить время, не способна формулировать мысли, боится ответственности за принятие решений. Здесь следует уточнить: потенциальный заказчик может целенаправленно придерживаться не конструктивной позиции или же искренне заблуждаться - с точки зрения потери моего времени это равнозначные события. Поэтому с целью минимизации иррациональных действий при составлении технического задания использую представленные ниже критерии.
Принуждение к диалогу
[1] Каждый новый соискатель воспринимается как дееспособный и заинтересованный в результате субъект принятия решений, у которого есть право убедить меня в обратном.
[2] Техническое задание является завершённым, если Заказчик готов письменно согласиться с утверждением: «Технические, метрологические, а также любые другие характеристики предмета разработки, не регламентированные в настоящем техническом задании, Исполнитель устанавливает и/или выбирает самостоятельно без согласования с Заказчиком».
[3] В течение итераций «..-Заказчик-Исполнитель-..» время нахождения документа у каждой из сторон устанавливает Заказчик. Объясняю. Исполнитель первый раз направил Заказчику проект документа, Заказчик внёс корректировки и вернул документ обратно спустя время T1. Я (Исполнитель) обязуюсь внести свои дополнения и вернуть документ Заказчику в течение времени не более T1. Допустим, после очередного цикла модификаций Заказчик отправляет черновик технического задания через время TX. Так вот: я оставляю за собой право выбрать максимальную из длительностей TX и T1 для своих последующих этапов корректировки. Хотите ехать быстро - не «тормозите».
[4] Длительность интервалов, в течение которых я корректирую проект ТЗ, фиксируется нарастающим итогом в астрономических часах по каждому проекту, например: час работы в прошлом месяце, 2 часа вчера, 3 часа сегодня и т.д. Если конечный вариант ТЗ появляется менее, чем за 40 (сорок) трудовых часов - плата не взимается. В противном случае за каждые полные 40 указанных часов Заказчик оплачивает минимальный тариф и подписывает акт сдачи-приемки части выполненных работ.
[5] Ответственный со стороны Заказчика - чья подпись стоит на договоре - может в течение вышеуказанных итераций изменять условия, требования, параметры к предмету разработки любое количество раз, в любой последовательности, под любым предлогом или без такового - любой каприз за Ваши деньги. Но при возникновении противоречий вследствие делегирования полномочий (например: человек, подписавший договор, назначил ответственным за электрическую часть одного сотрудника, за механическую другого и они формулируют противоположные требования) - прекращение работ. Возобновление только после оплаты минимального тарифа и подписанного акта об отсутствии взаимных претензий с фиксацией произошедшего на бумажном носителе за подписями уполномоченных лиц.
[6] Угрозы, хамство, сарказм - прекращение работ. Возобновление только после оплаты минимального тарифа и подписанного акта об отсутствии взаимных претензий с фиксацией произошедшего на бумажном носителе за подписями уполномоченных лиц.
[7] Каждые полные или не полные 10 (десять) минут разговора по телефону добавляют астрономический час в «копилку» затраченного на проект времени. Почему? - Потому что письменная форма общения (e-mail, форум) наглядно демонстрирует способность собеседника излагать мысли, только она фиксирует доказательства намерений сторон и, главное: у меня нет ни времени, ни желания слушать паузы, «мычание», «э-канье», слова-«паразиты», а также иной лингвистический мусор.
