Выпуск # 7 (08.09.2004)

Всплытие.

Ну что ж. Пора начинать всплытие из глубин творческого кризиса, одно из проявлений которого - более чем годовое отсутствие новых выпусков рассылки. Причины кризиса, его необходимость и пользу еще только предстоит осознать.
Безусловно, не может не радовать сам факт возникновения кризиса, который есть неотъемлемая часть творческой личности. Это говорит о том, что не все еще потеряно.

Итак, делаю вид, что ни куда ни пропадал и продолжаю.

ТЕХзадание или мойте руки перед едой.

Когда я был маленький и даже чуть-чуть позже, фраза "мойте руки перед едой" занимала в моей жизни весьма интересное место. В школе этому вопросу уделялось значительное количество внимания со стороны учителей и прочих педработников. Не знаю как сейчас, но и в дошколных учреждениях этот вопрос не был обделен вниманием. Как я ни старался, так и не смог разглядеть тех самых коварных микробов, которые по заверению сердобольных педагогов живут у меня на руках, ожидая что я их съем, и как огня боятся воды с мылом.
Я вполне серьезно думал, что эти коварные организмы живут почти все в школе. Объяснение было у меня очень простое и оно меня устраивало, если весь день гулять во дворе, на близлежащих стройках и прочих объектах народного хозяйства, а после этого не моя рук съесть бутерброд с колбасой по 2 руб. 20 коп. за кило, то ни чего не случалось, а вот если съесть что-нибудь не помыв рук в школьной столовой, то по заверениям педработников обязательно заболит живот, или вообще положат в больницу.

Другими словами, сия церемония обязательно должна предшествовать приему пищи, дабы предотвратить львиную долю нежелательных последствий. Прием пищи, особенно вкусной пищи, доставляет не меньшее удовольствие, чем творческий процесс в присутствии музы (или даже с ее участием). А что же тогда есть мытье рук перед едой? Вот это самое то, что назовем для начала "формирование техзадания".

Принимая во внимание тотальное неприятие творческими людьми подобных терминов и мероприятий регламентно-технического характера, прошу не плевать в мою сторону. Тем более, что техзадание не настолько бесполезная штука, как может показаться на первый взгляд даже в нашем случае.

Зачем это нужно?

Обычно о техзадании речь заходит, когда есть заказчик и есть исполнитель каких-то работ (например техзадание на разработку сайта, которое формирует заказчик и передает студии web-дизайна). В этом случае смысл сего действия довольно очевиден. Заказчик пытается сформулировать чего же он хочет получить в результате, а исполнитель пытается в этом разобраться.
В нашем случае ситуация несколько иная заказчик - сам, исполнитель - сам (ну или почти сам). Однако полезность техзадания от этого меньше не становится. В процессе формирования техзадания, приходится ни раз задуматься чего же нужно получить в результате. При этом, чем более тщательно будет продуман этот момент, тем меньше вероятность того, что придется что-то переделывать потом. А вообще, осовная мысль очень проста. Чем точнее представляешь себе конечный резальтат, тем быстрее его достигнешь.

Еще одним несомненным плюсом подобного мероприятия является следующее. В процессе создания своего проекта ни раз будет возникать соблазн "уйти в сторону", т.е. "начав вязать нужную варежку, в результате связать ненужный костюм". Что бы подстраховать себя от подобного проявления усердия и нужно обозначить желаемый результат.
Ну и еще один момент. Если все-таки придется часть работ поручить кому-то, то тут без техзадания не обойтись вовсе. При этом требования к техзаданию ужесточаются. Оно должно быть понятно исполнителю, а не только вам.

Как?

Готовых планов и примеров техзаданий я конечно приводить не буду. При желании все это запросто можно найти на просторах сети. Однако, на некоторые общие моменты все же стоит обратить внимание. Ну а раз техзадание пишется в нашем случае большей частью для себя, единственным важным требованием к его структуре и оформлению является лишь, что бы самому было возможно потом разобраться в нем. Если все же предполагается, что в создании вашего шедевра будет участвовать еще кто-то, то тут уже надо более ответственно подойти к этому вопросу.

В первой части техзадания стоит обозначить самое главное, т.е. что вообще ожидается получить в результате, и зачем это. Какими качествами это должно обладать ну и т.д. Т.е. если создается сайт, то в первой части прописывается название сайта, зачем он, для кого он, что он должен делать, каким требованиям специальным отвечать (например: сайт посвящен вопросам исследования колоний северных тушканов, нужно на сайте реализовать возможность рассчета количества тушканов в колонии, необходимого для влияния на процессы роста мухоморов в средней полосе; кроме того, сайт рассчитан на широчайшие слои исследователей этих тушканов, их возраст от 15 до 95 лет, 90% из них выходят в сеть по оптическим линиям связи ну и т.д.)

Во вторую часть стоит включить важные моменты реализации. В случае с сайтом, это структура сайта, цветовая гамма, элементы дизайна, которые необходимо включить и пр.

В третьей части, как это ни печально, пытаемся привязать все работы над шедевром к конкретным временным периодам. Другими словами тут хотелось бы видеть хотя бы какое - то подобие графика работ. Конечно можно и даже нужно выделять время с запасом, но обделять своим драгоценным вниманием эту часть не стоит. Иначе ваш шедевр рискует ни когда не увидеть свет.

По желанию можно добавлять разделы описывающие те или иные важные для шедевра моменты. Например, если речь идет о пластилиновой скульптуре какого-нибудь тотемного (гербового) животного Вашего города на главную площадь этого города, то конечно не помешает посвятить целый раздел техзадания для описания требований к пластилину (его состав, цвет, и пр.)

Если же вы набравшись смелости назвали себя студией (мастерской, цехом, фабрикой, заводом) дизайна (сайтостроительства, вебстроительства, веббилдинга, красивости и т.д.), то вам рано или поздно придется делать "это" для клиента. Вы автоматически оказываетесь по другую сторону баррикад, то есть техзадания. Как это ни печально, но большинство клиентов даже не представляют себе, что им нужно. При этом, далеко не всегда они хотят того, что им действительно нужно. Вот для этого и создаются типовые формы техзаданий. Клиент отвечая на конкретные вопросы такой формы, описывает ожидаемый результат в удобном для разработчика виде.

Тут есть один тонкий момент. К участию исполнителя в формировнии техзадания нужно относится очень осторожно, даже если исполнитель - Вы. В этом случае воплне возможна следующая ситуация. Техзадание будет описывать результат, которого может достичь исполнитель, и не всегда это именно то, что нужно заказчику.
Пример: Допустим исполнитель замечательно пишет скрипты на php, а заказчику нужно нечто, вполне хорошо реализуемое на простом HTML. Но исполнитель предлагает заказчику на одобрение (утверждение) техзадание, в котором прописана реализация проекта на основе написанного специально для этого сайта движка на php. Заказчик не разбирается в технологиях, ему нужно-то сайт из трех страничек. Заказчик, созерцая сумму предъявляемую ему за работу исполнителя, обращается к другому исполнителю. Первый исполнитель просто теряет клиента в лучшем случае, в худшем - его рипутация течет как весенний ручей по мостовой, при том что он лучше всех разбирается в php.

Вполне возможна и обратная ситуация. И что бы избежать подобных казусов, просто необходимо созерцать клиента с его заказом незамутненным, чистым и беспристрастным взором.

Особое внимание нужно уделить вопросам времени. Время, необходимое для работ, нужно обозначать смело в 1,5 - 2 раза больше рассчетного и еще пару дней сверху.
Ни в коем случае не позволяйте себе отклоняться от графика ведения проекта. Следствием подобных отклонений могут быть неприятности, размер которых пропорционален стоимости проекта, ну и величине этих отклонений.

Не помешает обозначить в техзадании количество предлагаемых вариантов будущего шедевра

На сегодня наверно все. Конечно, тема техзадания освещена поверхностно и не полно, да и не было такой цели - погрузиться в теорию написания техзаданий.

Однако, если настоящая тема окажется актуальной, готов вернуться к этому вопросу в дальнейшем. Буду признателен, за отзывы, касающиеся этого вопроса. Возможно, в последующих выпусках имеет смысл сформировать примерную структуру техзадания на разработку сайта.

Конечно же пишите.