Техническое задание - страшный, коварный и очень подлый документ. При грамотно проведенной разработке ТЗ становится мощнейшим инструментом манипуляций как заказчиком, так и исполнителем. Вопрос лишь в том, кто из них окажется умнее. Такова c est la vie - либо се ля вы, либо се ля вас... Впервые опубликована в журнале «Мир Автоматизации» № 4 за 2006 год под названием «Ваш выбор? Часть II». Редакция от 11.01.2022.
Создан 04.07.2006 20:31:06
Время от времени у любого руководителя предприятия возникает непреодолимое желание автоматизировать ряд деловых процессов. Желание руководителя понятно и объяснимо - автоматизация отдельных видов деятельности позволяет решить множество организационных проблем, тормозящих деловые процессы и, как следствие, снижающих эффективность деятельности предприятия в целом.
Желание руководства, выраженное решением, свидетельствует о том, что проблемы осознаны на самом высоком уровне, необходимость автоматизации обоснована, первичные требования сформированы - остается лишь поставить задачу исполнителю в http://uyutniugolok.ru/.
Постановка задачи
Решение даже простенькой школьной задачки не обходится без ее постановки - нелегко отыскать того, кто ни разу, роняя в тетрадку слезы, не выводил неровным детским почерком слова «дано», «найти» и «доказать». Решение задачи автоматизации - отнюдь не исключение. Напротив, налицо полная аналогия:
- «дано» - исходными данными служат текущее состояние объекта автоматизации, а также более или менее четкое понимание того, что должно получиться в итоге - технический облик будущей автоматизированной системы;
- «найти» - процесс поиска путей перехода от текущего состояния к ожидаемому (проектные решения);
- «доказать» - подтверждение соответствия созданной автоматизированной системы ожидаемому результату или назначению (через испытания).
Ничего принципиально нового: решение задачи автоматизации не выходит за рамки школьной программы.
Пункт первый - постановка задачи. Чтобы результат из ожидаемого превратился в запланированный, постановка задачи должна быть переведена с языка «хотелок» заказчика на язык технический, а затем найти свое отражение в техническом задании.
Кому же отдать роль «переводчика»? Обратимся к стандартам.
О чем свидетельствуют ГОСТы?
О чем же свидетельствуют ГОСТы? О разном.
Из раздела 2 ГОСТ 15.001: «2.1 ... Конкретное содержание технического задания определяют заказчик и разработчик, а при инициативной разработке - разработчик... 2.2 Техническое задание разрабатывают и утверждают в порядке, установленном заказчиком и разработчиком... При инициативной разработке необходимость, порядок разработки и утверждения технического задания определяет разработчик продукции... К разработке технического задания могут привлекаться другие заинтересованные организации (предприятия): изготовитель, головная организация по виду продукции, внешнеторговая организация, организация-проектировщик, монтажная организация и др.»
Из п. 1 Приложения 1 ГОСТ 34.602-89: «Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.)... При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на AC».
Из п. 3.1 ГОСТ 2.114-95 «ТУ является техническим документом, который разрабатывается по решению разработчика (изготовителя) или по требованию заказчика (потребителя) продукции» (примечание - технические условия (ТУ) по своей структуре и содержанию мало чем отличаются от технического задания - Авт.).
Следует отметить, что ряд иных ГОСТов предусматривают разработку технического задания силами заказчика.
Итак, стандарты предоставляют руководителю определенную степень свободы в выборе разработчика технического задания. Техническое задание может быть разработано:
- силами самого заказчика;
- непосредственным исполнителем, в чьи обязанности в дальнейшем войдут проектирование и проведение испытаний;
- «конкурсным» исполнителем, чьи взаимоотношения с заказчиком завершатся разработкой технического задания;
- сторонним исполнителем.
Разработка ТЗ силами заказчика
Разработка ТЗ силами заказчика - наименее распространенный вариант. Попытка автоматизировать процесс раздачи грубых кормов крупному рогатому скоту силами сельских механизаторов заранее обречена на провал. Примеров тому немало - в очередной раз находит свое подтверждение правило, что одного знания предметной области явно недостаточно. Но разумно ли назначать на должность механизатора дипломированного специалиста-системотехника?
Исключением из правил в недалеком прошлом являлась оборонка, но и она, в силу объективных причин, стала испытывать дефицит высококвалифицированных кадров. Даже могучие нефтегазодобывающие предприятия, располагающие штатом IT-специалистов, предпочитают отдавать разработки «на сторону», «на откуп» профильным аутсорсным компаниям. Причин тому может быть много, одной из них является пресловутый человеческий фактор.
Далее: |
Человеческий фактор
Где-то в сети был обнаружен сайт некой IT-компании, «до зубов» сертифицированной по ISO 9000. В разделе «Наша миссия» было продекларировано (почти дословно): «Мы - молодая, дружная, единая команда профессионалов, компенсирующая недостаток знаний и опыта энергией и энтузиазмом, целью которой является достижение удовлетворенности заказчика».
Умудренный опытом руководитель, поневоле (не «сертифицируешься» - не продашь) внедривший на своем предприятии систему управления качеством, никогда не забудет об основополагающей роли человеческого фактора. Человеческий фактор, как минимум, проявляется в трех ипостасях:
- в том, что люди - не роботы;
- в отсутствии заинтересованности «внутреннего» исполнителя;
- в косности персонала, чью деятельность предполагается автоматизировать.
Люди - не роботы
Люди - не роботы. Каждый - индивидуален. Опыт, уровень компетенции, собственные интересы и оценка происходящего, личные амбиции, настроение, симпатии и антипатии - все перечисленное оказывает серьезное влияние на ход деловых процессов предприятия. И, поверьте, - отношение руководителя к подчиненному как к «человеческому ресурсу» вряд ли вызовет у подчиненного позитив по отношению к руководителю.
Примечание от 10.06.2014 г. - Президент Лукашенко очень грамотно вывел из свого традиционного ежегодного послания к народу и парламенту оскорбительное для многих понятие «человеческий ресурс» и заменил его на откровенно ласкающее слух «человеческий капитал».
Незаинтересованность внутреннего исполнителя
Интересы, несмотря на самые смелые декларации, у каждого свои. У руководителя - свои, у подчиненных - свои. Руководителю не хватает денег на достройку дачи на Рублевке, подчиненному - на замену масла в «Жигулях». И «нацеленность» на общую задачу - обеспечить компании прибыль, не срабатывает. Поскольку слишком уж неравны «доли прибыли» участников делового процесса.
Всем известно, что у победы - много отцов. В случае победы мы - «единая команда победителей»: генеральному - орден, заму - медаль, клеркам - благодарность, а не хватит бланков - благодарность устная. В случае поражения срабатывает схема «каждый умирает в одиночку» и начинается поиск «крайнего», - «дружная, единая команда профессионалов» разваливается на глазах.
Таким образом, «командный» подход на «одной шестой части суши» попросту не срабатывает. Понимая это, подчиненный, внутрений исполнитель, стремится свести к минимуму сферу своей деятельности, взять на себя как можно меньше ответственности. И мудрый руководитель также отдает себе в этом отчет.
Косность персонала
Косность персонала, чью деятельность предполагается автоматизировать, чаще всего обусловлена страхом перед увольнением. Вспомните реакцию бухгалтеров на первые попытки компьютеризации их деятельности, на появление первых компьютерных программ по расчету заработной платы. Прошло много лет, пока бухгалтеры не пообвыкли и не притерпелись к компьютерам, но и по сей день любой бухгалтер трижды проверит результаты работы компьютерной программы на калькуляторе, а то и гремя костяшками счетов.
Проблема состоит в непонимании факта, что автоматизация деятельности приводит, как правило, не к сокращению, а к раздуванию штатов. Помимо бухгалтеров-счетоводов в штате финансового отдела образуются должности системного администратора, программиста и иже с ними. И никого не сокращают, поскольку объемы работ в результате автоматизации только увеличиваются - ведь производительность и эффективность труда возрастают.
Выводы
Стоит ли руководителю пытаться преодолеть человеческий фактор? Трудно сказать. Но очевидно одно - коль скоро в производственных отношениях установился некоторый баланс, вряд ли разумно чрезмерно «раскачивать лодку» - не стало бы хуже. Быть может, поэтому разработка ТЗ силами заказчика не пользуется особой популярностью.
Разработка ТЗ непосредственным исполнителем
Разработка ТЗ непосредственным исполнителем - самый распространенный вариант. Но, прежде чем продолжить, необходимо согласиться с тем, что изложение материала будет строиться в рамках идеализированной модели взаимоотношений хозяйствующих субъектов.
Указанная модель необходима для сведения к «минус бесконечности» возможности давления на исполнителя со стороны заказчика, за исключением честного поединка в арбитражном суде. Идеализированная модель предполагает, как минимум, взаимодействие заказчика и исполнителя по «безоткатной» технологии, а также в условиях отсутствия «телефонного права». По-возможности, следует на некоторое время пренебречь таким понятием, как деловая репутация, и сосредоточиться на том, в чьих интересах разрабатывается ТЗ.
«Безоткатная» технология
«Безоткатная» технология - антипод технологии «откатной». «Откатная» модель взаимодействия между хозяйствующими субъектами общеизвестна, нет смысла подробно на ней останавливаться. В ходе изложения материала предполагается исходить из реальных производственных потребностей заказчика, а не из реальных финансовых потребностей отдельных его представителей, «сидящих на договорах».
«Телефонное право»
«Телефонное право», применительно к нынешним реалиям, реализуется классическим способом: отставной генерал (в прошлом - заказчик) становится членом Совета директоров компании-исполнителя. Исполнителю, в результате такой «сделки», гарантирован солидный пакет заказов, заказчик, в свою очередь, обретает мощные «рычаги» давления на исполнителя, генерал - солидную прибавку к пенсии, при размерах которой о самой пенсии можно даже и не вспоминать.
Умный заказчик, умный исполнитель...
Теперь немного терминологии. В среде разработчиков популярен проверенный жизнью постулат, приведенный в более «мягкой», по сравнению с оригиналом, формулировке:
- Умный заказчик, умный исполнитель - продление сроков договора;
- Умный заказчик, наивный Исполнитель - бесконечные переделки (за счет исполнителя);
- Наивный заказчик, умный исполнитель - высочайшая норма прибыли (исполнителя);
- Наивный заказчик, наивный исполнитель - бой быков (...и винный погреб... Чем не рай?!).
В чьих интересах разрабатывается ТЗ
«Закон - что дышло, куда повернул - туда и вышло». То же можно сказать и о техническом задании.
Техническое задание - один из самых страшных, коварных и подлых документов, и понимание этого факта дается немалой кровью. Изобилующие юридической казуистикой разного рода «рамочные» договоры - «младенцы» в части коварства и «тайной подлости» по сравнению с техническим заданием. Штрафные санкции, предусмотренные при невыполнении договорных обязательств, могут оказаться копеечными по сравнению с убытками, причиненными «с помощью» технического задания. В то же время техническими заданиями иногда удается компенсировать непродуманные упоминания в договорах таких понятий, как «дефект» и «качество».
Таким образом, техническое задание - серьезный инструмент манипулирования, который непременно окажется в руках менее «наивной» стороны. И заказчик должен полностью отдавать себе отчет в том, кто в чьих интересах будет разрабатывать техническое задание. Рассмотрим варианты.
Наивный заказчик, умный исполнитель
Умный исполнитель, в силу знаний и опыта, всегда относится к заказчику с некоторой настороженностью, понимая, что музыку заказывает тот, кто платит. Чтобы обезопасить себя от непредвиденного поведения заказчика в случае возниковения конфликта, исполнитель предусмотрительно расставит в техническом задании ряд «капканов», оставив себе возможность развернуть любую конфликтную ситуацию в свою пользу. Иными словами, умный исполнитель разработает техническое задание в собственных интересах.
«Капканы» представляют собой вполне невинные, достаточно прозрачные формулировки, «разбросанные» по разным подразделам технического задания и логически будто бы не связанные. Например, в подразделе «Требования к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы» приводится требование - «Конструктивно технические средства системы должны быть выполнены из стандартных, унифицированных модулей промышленного исполнения», а в подразделе «Требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения)», - «Технические средства по степени защиты должны иметь исполнение класса не хуже IP61 по ГОСТ 14254-96».
В случае конфликта заказчик, наивно полагающий, что технические средства должны быть выпущены промышленностью, будет неприятно удивлен, когда выяснится, что ему следовало приобретать технические средства, предназначенные для эксплуатации в промышленных условиях. Возразить нечего, поскольку с учетом требований по стойкости, устойчивости и т.д. технические средства должны быть защищены настолько, чтобы обеспечивать возможность своего штатного функционирования чуть ли не в условиях нанесения вероятным противником ядерного удара. Мат в два хода - белые (исполнитель) начинают и выигрывают. У заказчика, правда, остается выбор:
- отказаться от претензий к исполнителю и пойти на разного рода уступки в его пользу;
- потерять изрядные деньги на возврате технических средств, «не вписавшихся» в требования технического задания;
- истратить уйму денег на закупку технических средств, предназначенных к эксплуатации в промышленных условиях;
- расторгнуть договор и выплатить исполнителю неустойку.
Стоимость материнской платы промышленного исполнения (типа micro-PC) значительно превосходит стоимость своего полного «бытового» аналога. Указанный факт хорошо известен читателям журнала «Мир Автоматизации».
Но это еще не все. Умный исполнитель приложит все усилия к тому, чтобы свести к минимуму число требований технического задания. Ведь чем больше требований будет в ТЗ, тем больше проблем ожидает исполнителя при проведении испытаний, что выходит за рамки интересов исполнителя.
И снова человеческий фактор...
И снова человеческий фактор. Очевидно, что непосредственно разработкой ТЗ занимается не кровно заинтересованный в заказе директор компании-исполнителя, а подчиненный ему системотехник или аналитик - наемный работник, получающий при дележке «пирога» лишь «маковую росинку». Неосторожное слово, косой взгляд директора может привести к тому, что «штык» системотехника окажется направлен против собственной компании.
В этом случае приведенный выше сценарий начнет раскручиваться с точностью «до наоборот». «Капканы» будут расставлены не «на заказчика», а «на исполнителя», и заказчик об этом будет предупрежден - системотехник всегда имеет прямой контакт с заказчиком. А предупрежден - значит вооружен.
Умный заказчик, наивный исполнитель
Умный заказчик, как правило, в «прошлой жизни» - умный исполнитель. Такой заказчик не станет ни в чем препятствовать исполнителю, напротив - обеспечит ему полную свободу «словоизвержения». В результате исполнитель устроит «засаду» себе сам.
Широко распространенная фраза, фигурирующая в большинстве технических заданий, разрабатываемых в «софтверных» компаниях, «программа должна обладать интуитивно-понятным пользовательским интерфейсом», - классический образец наивности (если не сказать - глупости) исполнителя. Заказчик при приемке работы заявит, что его персонал не обладает достаточными для работы с подобным интерфейсом понятливостью и интуицией. Исполнитель будет вынужден переделывать интерфейс до тех пор (за собственный счет, разумеется), пока заказчику не надоест «игра в кошки-мышки».
Хорошо известен трюк, построенный на невнимательности исполнителя, когда последний попросту забывает расписать пределы ответственности каждой из сторон. Испытания, к примеру, согласно ГОСТ 34.603-92, принято проводить на объекте заказчика, но в стандарте не указано явно, на чьих технических средствах. И тут-то у исполнителя появляется отличная возможность предоставить заказчику собственные технические средства или приобрести их за свой счет. А если в техническом задании указаны условия эксплуатации технических средств, выходящие за рамки нормальных климатических условий, то заказчик получит все основания заставить исполнителя провести климатические испытания. Тот, кому довелось проводить «климатику», да еще и с интервалом в полградуса, наверное, вздрогнул, читая эти строки.
«Капканов» и «засад» в техническом задании может оказаться бесконечное множество. Автор не склонен далее развивать тему далее, поскольку (рассказав все) рискует попросту остаться без работы.
Выводы
Как указывалось выше, разработка ТЗ непосредственным исполнителем - вариант наиболее распространенный. Но в данном случае и заказчику, и исполнителю следует быть бдительными, держать «нос по ветру».
При отходе от идеализированной модели - возврату к жизненным реалиям, положение исполнителя становится несоизмеримо более тяжелым. Ответственный за проект, будь то директор лично, руководитель проекта и т.п., оказывается «между молотом и наковальней». Сверху «давит» заказчик, снизу упорно «отбрыкивается» «человеческий фактор». В результате, в подавляющем большинстве случаев, заказчик попросту «садится на шею» исполнителя.
Каждый сам кузнец своего счастья. Руководитель-исполнитель, склонный придерживаться точки зрения «незаменимых нет», будет по-жизни возить заказчика «на своем горбу». Мудрый руководитель создаст своим «ключевым» специалистам максимально благоприятные условия и станет чувствовать себя не «вожаком волчьей стаи», а основателем собственной школы.
Разработка ТЗ на тендерной основе
Тендер (конкурс), по своему замыслу, вещь правильная, ведь конкурентная основа предполагает возможность выбора, приобретения чего-то лучшего с меньшими расходами. Но почему же на любой тендер выставляются не технические задания, а технико-коммерческие предложения? Все объяснимо: ТКП содержат большей частью единожды «сработанную» рекламу, а разработка технического задания требует серьезных трудозатрат.
О трудозатратах. Отмененным, к великому сожалению разработчиков, ОСТ 4.071.030 «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости», на разработку технического задания степени новизны 1 отводилось 10772 нормо-часа. В неделе - 40 часов, следовательно, разработка ТЗ займет ~ 270 недель в расчете на одного исполнителя. Если допустить, что с 1984 года исполнитель научился работать хотя бы в двадцать раз эффективнее (что сомнительно), разработка ТЗ займет 13,5 недель или более трех месяцев.
Далее: |
Дорогое удовольствие
Разработка технического задания - удовольствие не только трудозатратное, но и не из дешевых. Краткая справка - стоимость разработки технического задания солидным (из первой двадцатки «профильного» рейтинга) исполнителем обходится заказчику примерно в десять-пятнадцать тыс. долларов, и это далеко не предел. За меньшую сумму солидный исполнитель работать вряд ли станет - слишком уж велики собственные издержки (аренда офиса, зарплата персонала, налоги и прочее).
Проверим алгеброй гармонию. Умножая оклад разработчика «средней руки» ($1500) на трехмесячный срок, получим стоимость ТЗ в размере $4500. С учетом собственных издержек стоимость разработки ТЗ неизбежно преодолеет планку в 10 - 15 тыс. тонн грязно-зеленой мериканской резаной бумаги.
Примечание от 25.11.2011 г. - Примеры расчета стоимости разработки технической документации, основанные на действующих (и не очень) нормативах, приведены в статьях В. А. Глаголева «Стоимость разработки технической документации. Часть I» и «Стоимость разработки технической документации. Часть II».
Разработка ТЗ сторонним исполнителем
Разработка ТЗ сторонним исполнителем - явление, встречающееся все чаще и чаще. Институт фрилансерства (free lance), как весенняя травка сквозь асфальт, медленно, но верно пробивает себе путь к Солнцу. Фрилансеры охотно берутся и за «мелочевку», и за крупномасштабные проекты вроде «Электронной России» или очередного клона webmoney, заказчик, как правило, остается доволен. Некоторое взаимное недоверие, поначалу, присуще обеим высоким договаривающимся сторонам, но риск сводится к минимуму оплатой услуг теми же webmoney.
Фрилансеров можно условно поделить на две категории:
- на категорию «вольных стрелков»;
- на категорию «методистов».
«Вольные стрелки»
«Вольные стрелки», рыскающие в поисках заработка в сети, образуют сетевые профессиональные сообщества, отслеживают рейтинги исполнителей, публикуют сведения о недобросовестных работодателях и исполнителях - ведут активную сетевую «жизнь». В среде «вольных стрелков» часто встречаются настоящие профессионалы - писатели, журналисты, преподаватели, научные работники. Кстати, большинство авторов находят издательства, заинтересованные в их публикациях, в сети Интернет.
Примечание от 10.06.2014 г. - Несколько лет тому назад именно фрилансерша здорово помогла нам эмулировать очень сложную физическую модель. Достаточно сказать, что вычислительный кластер непрерывно трудился в поте лица в течение почти трех суток.
«Методисты»
«Методисты» - менее подвижная категория фрилансеров. «Методисты», как правило, неплохо устроены, работают в солидных компаниях и, в силу своих профессиональных навыков, частенько выполняют «месячную норму» в весьма сжатые сроки. Избыток свободного времени требует заполнения - природа не терпит пустоты. Поэтому специалист, скорее ради живого интереса, чем ради денег, возьмется за «сторонний» проект. Действительно, любопытно: сколько времени может потребоваться, чтобы «перекроить» ТЗ на информационно-измерительную систему в полноценное ТЗ на систему электронного документооборота?
При взаимодействии с таким исполнителем заказчик может быть полностью уверен в том, что разработка ТЗ будет выполнена в его интересах, в интересах заказчика. А если исполнитель узнает, что разработку проекта по ТЗ предполагается передать в компанию, на которую исполнитель, в силу ряда причин, «имеет зуб»...
Вместо заключения
В конечном счете, решение, кому поручить разработку технического задания, остается за заинтересованным в автоматизации руководителем - в статье более или менее детально рассмотрены наиболее типичные варианты. Остается добавить, что не в самом далеком будущем многие «офисные сидельцы», специалисты, чье присутствие на рабочем месте и ныне не обусловлено разумной необходимостью, продолжат работу в уютных домашних или дачных условиях. И предпосылки тому имеются - немыслимый рост арендной платы и бурное развитие коммуникаций. Побольше бы мудрых руководителей...
Примечание от 10.06.2014 г. - Последние пару лет в стране активно заговорили об этом, даже закон соответствующий приняли. Оказываем услуги по предсказанию будущего #128526;
