Первая страница » Статьи » О пользе бумаги » Часть I

О пользе бумаги

Влад Князев

Часть I. Бумаги, которые мы пишем

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

Не могу сказать, что это доставляло мне какое-то удовольствие, тем более, что в те времена и компьютеров то не было. Пишешь, зачеркиваешь то, что написал, опять пишешь, опять зачеркиваешь и т.д., пока не получится что-то более или менее связное. Потом переписываешь начисто и несешь машинистке для печати. И печатались все эти «бумаги» не в одном, а в трех и более экземплярах.

Утешало меня только то, что все эти отчеты надо было писать только по завершении очередного этапа темы, а это бывало примерно раз в год. Но бумаги при этом расходовалось столько, сколько за весь предыдущий отрезок времени, если не больше. И наличие «слоновьей» бумаги в такие моменты было бы весьма кстати. Правда, со временем я нашел для себя выход, о котором я расскажу чуть позже.

Конечно, все эти «бумаги», о которых сказано выше, по-своему необходимы. Я не знаю, читал ли наши отчеты наш Заказчик, или просто складывал на полку, но для нас написание отчетов было делом, само собой разумеющимся. Если даже отбросить научную или техническую ценность информации, содержащейся в нем, то отчет являлся тем самым документом, который свидетельствовал о завершении этапа и давал основания для перечисления нам очередной суммы денег.

Сейчас же мне хотелось бы поразмышлять о «бумагах», которые требуется написать еще до того, как какая-либо другая работа начнется вообще. Без создания подобных бумаг все остальное теряет всяческий смысл.

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

Возможно, кому-то такой документ может показаться пустой формальностью, и он предпочитает не тратить время на такие формальности и обходиться без такой «бумаги». Зачем же тратить свое время на сочинение какого-то ТЗ? Все и так ясно и надо сразу «брать быка за рога». Я допускаю и такой подход, и у кого-то он срабатывает. Но, я думаю, все это только до поры, до времени. И в этом я убедился не так давно на своем опыте.

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

Но работа, как я уже сказал, оказалось простой и вопросов, а тем более, проблем не было. Так, что я все быстро сделал. Все работало хорошо, но... не так, как требовалось. Оказалось, что требовалось включение/выключение микрофонов в произвольной комбинации, а я сделал по принципу «один из...», т.е. в любой момент времени может включаться только один микрофон, остальные выключались.

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

Конечно, мне пришлось все переделать, и это не заняло много времени. А если бы задача была более сложная, и на ее решение ушло бы больше времени? Во что вылилась бы последующая переделка?

И я могу привести еще один пример формального подхода к требуемым формальностям. Нам потребовалось разработать пульт для «бюджетного» лингафонного кабинета. Разработка показалась достаточно простой и ресурсов контроллера, предполагаемого к использованию, должно хватить с избытком.

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

Когда впоследствии мне пришлось писать программу для контроллера в соответствии с этой «бумагой», то выяснилось, что сделать прибор в полном соответствии с ТЗ было невозможно. Все упиралось в малый объем памяти программ «на борту». Я старался, как мог, но сделать полностью все не сумел. Видимо, в трехлитровую посуду невозможно налить пять литров воды. Программа заняла все «три литра», места в памяти осталось на 2-3 команды, не более.

И что интересно, работа с пультом даже при наличии «упрощенного» алгоритма показалась пользователям (преподавателям иностранных языков) настолько сложной, что когда им требовалась смена режима, они просто кратковременно выключали питание для установки пульта в исходное состояние (поскольку кнопки сброса не было). А уж затем переходили в нужный режим.

О том, что никакого ТЗ, согласованного с потенциальными пользователями, не было я уже и не говорю.

Теперь возникает другой вопрос: кто должен составлять ТЗ? Мне приходилось слышать мнения, что ТЗ должен составлять Заказчик, поскольку он лучше знает, что ему реально нужно. У других мнение противоположное: ТЗ должен составлять Исполнитель, потому что он знает как сделать то, что нужно Заказчику. Я же думаю, что истина как раз посередине.

Но сначала мне бы хотелось привести случай из практики моего однокашника по институту, который произошел с ним не так давно. Заказчик попросил его разработать некое устройство в соответствии с предложенным ТЗ. Он не стал вдаваться особенно в предложенное задание и сделал все, как требовал Заказчик. Заказчик был доволен: все сделано, как просили. Но когда стали это устройство испытывать на месте, оказалось, что все работает не так, как было нужно в действительности.

Тогда мой товарищ стал выяснять, что же нужно было Заказчику на самом деле. В конце концов, выяснилось, что в действительности требовалось совсем не то, что было указано в ТЗ. А так, как было сделано в соответствии с предложенным ТЗ, работать не должно, что и произошло в реальности.

Естественно, что Заказчика это не устроило, и мой товарищ сделал новое устройство, и, конечно, за дополнительную оплату. Но на этот раз ТЗ на разработку составлял он сам, и при этом участвовал представитель Заказчика.

Так вот, на мой взгляд, ТЗ должно являться плодом совместной работы Заказчика и Исполнителя, результатом их совместных усилий. В ходе работы (хочу подчеркнуть это слово) над ТЗ обе договаривающиеся стороны могут лучше понять друг друга. Исполнитель будет лучше представлять, что именно нужно Заказчику. Кстати, у нас в лаборатории в свое время был лозунг: «Дать Заказчику не то, что он хочет, а то, что ему нужно!».

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

Писать саму «бумагу» проще всего, на мой взгляд, Разработчику. Он лучше знает техническую сторону дела и проблемы, требующие решений. Но исходные данные должен предоставлять Заказчик, и он же будет утверждать это ТЗ.

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

Наличие подписей говорит, прежде всего, о взаимной ответственности договаривающихся сторон. Если ты ставишь подпись, то это значит, что ты берешь на себя определенную ответственность за все дальнейшие последствия. И в этом случае ТЗ перестает быть просто «бумагой», оно становится Документом.

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

Конечно, бывает и так, что работа как начинается с составления ТЗ, так им же и заканчивается. Может случиться так, что Ваш заказчик по ряду причин после составления ТЗ отказывается от продолжения работы. Печально? Несомненно. Работа проделана зазря? А вот с этой точкой зрения я готов поспорить.

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

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

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

Зато правильно составленное ТЗ подобно правильно сформулированному вопросу, во многом является уже решенной задачей. И наоборот, дни «сэкономленные» на составлении ТЗ, могут обернуться дополнительными неделями, а то и месяцами, потраченными на поиски нужных решений во время выполнения работы над проектом. А эти недели (или месяцы) будут смотреться со стороны Заказчика совсем иначе после того, как Вы уже поставили на ТЗ свою подпись.

Но вот ТЗ составлено и, казалось бы, можно приступать к работе. Ан нет, этого оказывается еще недостаточно. В дополнение к ТЗ необходимо (или желательно) иметь план-график выполнения работ. И опять нужно писать очередную «бумагу».

«Я планов наших люблю громадье...», — писал В.В. Маяковский. Я думаю, планы действительно стоят того, чтобы о них поразмышлять отдельно.

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

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

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

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

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

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

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

Конечно, сами по себе планы на бумаге не являются достаточным условием выполнения Дела. Но то, что они необходимы для Дела, в этом я нисколько не сомневаюсь.

Конечно, и ТЗ и План необходимы, и мы их пишем. Но есть еще и другие бумаги, которые могли бы способствовать Делу. А вот их мы часто не только не пишем, но и не задумываемся о них вообще.

Введение. О пользе слонов < • > Часть II. Бумаги, которых мы не пишем