RU   UA   EN   DE
ГлавнаяНовостиУслугиПроектыКаталог продукцииЛицензииПолезная информацияКонтакты
Услуги
Новости
Статьи → Ваш выбор?

Ваш выбор?

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

Время от времени у любого руководителя предприятия возникает непреодолимое желание автоматизировать ряд деловых процессов. Желание руководителя понятно и объяснимо — автоматизация отдельных видов деятельности позволяет решить множество организационных проблем, приводящих к торможению деловых процессов и, как следствие, снижающих эффективность деятельности предприятия в целом.
Желание руководства, выраженное решением, свидетельствует о том, что проблемы осознаны на самом высоком уровне, необходимость автоматизации обоснована, первичные требования сформированы — остается лишь поставить задачу Исполнителю.

Постановка задачи

Решение даже простенькой школьной задачки не обходится без ее постановки — нелегко отыскать того, кто не выводил неровным детским почерком слова «дано», «найти» и «доказать». При решении задачи автоматизации налицо полная аналогия:

  • «дано»— текущее состояние объекта автоматизации, а также более или менее четкое понимание того, что должно получиться — технический облик будущей системы;
  • «найти» — процесс поиска путей перехода от текущего состояния к ожидаемому (проектные решения);
  • «доказать» — подтверждение соот¬ветствия созданной автоматизиро¬ванной системы ожидаемому ре¬зультату (испытания).

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

  • силами самого Заказчика;
  • непосредственным Исполнителем, в чьи обязанности в дальнейшем войдут проектирование и проведе¬ние испытаний;
  • конкурсным Исполнителем, чьи взаимоотношения с Заказчиком завершатся разработкой технического задания;
  • сторонним Исполнителем.


О чем свидетельствует ГОСТ?

Из раздела 2 ГОСТ 15.001-88:
«2.1. ...Конкретное содержание технического задания определя¬ют заказчик и разработчик, а при инициативной разработке — разработчик...
2.2. Техническое задание разрабатывают и утверждают в порядке, установленном заказчиком и разработчиком... При инициативной разработке необходимость, порядок разработки и утверждения технического задания определяет разработчик продукции... К разработке технического задания могут привлекаться другие заинтересованные организации(предприятия): изготовитель, головная организация по виду продукции, внешнеторговая организация, организация-проектировщик, монтажная организация и др.».
Из п. 1 Приложения 1 ГОСТ 34.602-89: «Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.)... При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на АС».
Из п. 3.1 ГОСТ 2.114-95: «ТУ является техническим документом, который разрабатывается по решению разработчика (изготовителя) или по требованию заказчика (потребителя) продукции» (прим. — технические условия (ТУ) по своей структуре и содержанию мало чем отличаются от технического задания).
Следует отметить, что ряд иных ГОСТ предусматривают разработку технического задания силами Заказчика.


Трудозатраты на ТЗ


Отмененным ОСТ 4.071.030 «Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости» на разработку ТЗ степени новизны 1 отводилось 10772 нормо-часа. В неделе — 40 часов, следовательно, разработка ТЗ займет ~ 270 недель в расчете на одного исполнителя. Если допустить, что с 1984 года исполнитель научился работать хотя бы в 20 раз эффективнее (что сомнительно), разработка ТЗ займет 13,5 недель или более трех месяцев.

Разработка ТЗ силами заказчика


Наименее распространенный вариант. Попытка автоматизировать процесс раздачи грубых кормов крупному рогатому скоту силами сельских механизаторов заранее обречена на провал. Примеров тому немало: в очередной раз находит свое подтверждение правило, что одного знания предметной области явно недостаточно. Но разумно ли назначать на должность механизатора дипломированного специалиста-системотехника?
Исключением из правил в недалеком прошлом являлась оборонка, но и она, в силу объективных причин, стала испытывать дефицит высококвалифицированных кадров. Даже могучие нефтегазодобывающие предприятия, располагающие штатом ИТ-специалистов, предпочитают отдавать разработки на сторону, на откуп профильным компаниям. Причин тому может быть много, одной из них является пресловутый человеческий фактор.

Человеческий фактор

Умудренный опытом руководитель, поневоле внедривший на своем предприятии систему управления качеством (не «сертифицируешься» — не продашь), никогда не забудет об основополагающей роли человеческого фактора, проявляющегося, как минимум, в трех ипостасях: в том, что люди — не роботы, в отсутствии заинтересованности внутреннего исполнителя и в косности персонала, чью деятельность предполагается автоматизировать.

  • Люди — не роботы. Каждый из нас — индивидуален. Опыт, уровень компетенции, собственные интересы и оценка происходящего, личные амбиции, настроение, симпатии и антипатии — все это оказывает серьезное влияние на ход деловых процессов предприятия. И поверьте, отношение руководителя к подчиненному как к человеческому ресурсу вряд ли вызовет у подчиненного позитив по отношению к руководству.
  • Интересы у каждого свои. Руководителю не хватает денег на достройку дачи, подчиненному на замену масла в «жигулях». И нацеленность на общую задачу — обеспечить компании прибыль не срабатывает, слишком уж неравны доли прибыли участников делового процесса. Всем известно, что у победы много отцов. В случае победы мы — единая команда победителей. Но в случае поражения срабатывает схема «каждый умирает в одиночку» и начинается поиск крайнего — дружная единая команда профессионалов разваливается на глазах. Таким образом, командный подход попросту не срабатывает. Понимая это, подчиненный, внутренний исполнитель, стремится свести к минимуму сферу своей деятельности, взять на себя как можно меньше ответственности. И мудрый руководитель также отдает себе в этом отчет.
  • Косность персонала, чью деятельность предполагается автоматизировать, чаще всего обусловлена страхом перед увольнением. Проблема состоит в непонимании того факта, что автоматизация деятельности приводит, как правило, не к сокращению, а к раздуванию штатов, ведь объемы работ в результате автоматизации только увеличиваются — возрастают производительность и эффективность труда.

Стоит ли руководителю пытаться преодолеть человеческий фактор? Трудно сказать. Но очевидно одно — коль скоро в производственных отношениях установился некоторый баланс, вряд ли разумно раскачивать лодку. Быть может, именно поэтому разработка ТЗ силами Заказчика не пользуется особой популярностью.

Разработка ТЗ непосредственным Исполнителем

Данный вариант — наиболее распространенный. Но, прежде чем продолжить, необходимо отметить, что изложение материала будет строиться в рамках идеализированной модели взаимоотношений хозяйствующих субъектов. Указанная модель необходима для сведения к минус бесконечности возможности давления на Исполнителя со стороны Заказчика, за исключением честного поединка в арбитражном суде.
Идеализированная модель предполагает, как минимум, взаимодействие Заказчика и Исполнителя по безоткатной технологии, а также в условиях отсутствия телефонного права. По возможности следует на некоторое время пренебречь таким понятием, как деловая репутация, и сосредоточиться на том, в чьих интересах разрабатывается ТЗ.
В ходе изложения материала предполагается исходить из реальных производственных потребностей Заказчика, а не из реальных финансовых потребностей отдельных его представителей, сидящих на договорах.
Телефонное право применительно к нынешним реалиям реализуется классическим способом: отставной генерал (в прошлом — Заказчик) становится членом Совета директоров компании-исполнителя. Исполнителю в результате такой сделки гарантирован солидный пакет заказов. Заказчик, в свою очередь, обретает мощные рычаги давления на Исполнителя, генерал — прибавку к пенсии, при размерах которой о самой пенсии можно даже и не вспоминать.
«Закон — что дышло, куда повернул — туда и вышло». То же можно сказать и о ТЗ, одном из самых коварных документов. Изобилующие юридической казуистикой разного рода «рамочные» договоры — младенцы в части коварства и «тайной подлости» по сравнению с ТЗ. Штрафные санкции, предусмотренные при невыполнении договорных обязательств, могут оказаться копеечными по сравнению с убытками, причиненными с помощью ТЗ. В то же время ТЗ иногда удается компенсировать непродуманные упоминания в договорах таких понятий, как «дефект» и «качество».
В среде разработчиков популярен проверенный жизнью постулат, приводимый здесь в более мягкой, по сравнению с оригиналом, формулировке:

  • Умный Заказчик, умный Исполнитель — продление сроков Договора.
  • Умный Заказчик, наивный Исполнитель — бесконечные переделки (за счет Исполнителя).
  • Наивный Заказчик, умный Исполнитель — высочайшая норма прибыли (Исполнителя).
  • Наивный Заказчик, наивный Исполнитель — бой быков.

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

Наивный Заказчик, умный Исполнитель

Умный Исполнитель, в силу знаний и опыта, всегда относится к Заказчику с некоторой настороженностью, понимая, что музыку заказывает тот, кто платит. Чтобы обезопасить себя от непредвиденного поведения Заказчика в случае возниковения конфликта, Исполнитель предусмотрительно расставит в ТЗ ряд капканов, оставив себе возможность развернуть любую конфликтную ситуацию в свою пользу, — умный Исполнитель разработает ТЗ в собственных интересах.
Капканы представляют собой вполне невинные, достаточно прозрачные формулировки, разбросанные по разным подразделам ТЗ и логически будто бы не связанные. Например, в подразделе «Требования к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы» приводится требование — «Конструктивно технические средства Системы должны быть выполнены из стандартных, унифицированных модулей промышленного исполнения», а в подразделе «Требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения)» — «Технические средства по степени защиты должны иметь исполнение класса не хуже IP61 по ГОСТ 14254-96».
В случае конфликта Заказчик, наивно полагающий, что технические средства (далее ТС) должны быть выпущены промышленностью, будет неприятно удивлен, когда выяснится, что ему следовало приобретать ТС, предназначенные к эксплуатации в промышленных условиях. Возразить нечего, поскольку с учетом требований по стойкости, устойчивости и т. д. ТС должны быть защищены настолько, чтобы обеспечивать возможность своего штатного функционирования чуть ли не в условиях нанесения вероятным противником ядерного удара. Мат в два хода — белые (Исполнитель) начинают и выигрывают.
У Заказчика, правда, остается выбор:

  • отказаться от претензий к Исполнителю и пойти на разного рода уступки в его пользу;
  • потерять изрядные деньги на воз¬врате ТС, не вписавшихся в требо¬вания ТЗ;
  • истратить уйму денег на закупку ТС, предназначенных к эксплуатации в промышленных условиях;
  • расторгнуть Договор и выплатить Исполнителю неустойку.

Стоимость материнской платы промышленного исполнения (типа micro-PC) значительно превосходит стоимость своего полного бытового аналога. Но это еще не все. Умный Исполнитель приложит все усилия для того, чтобы свести к минимуму число требований ТЗ — чем больше требований будет в ТЗ, тем больше проблем ожидает Исполнителя при проведении испытаний.
И снова человеческий фактор... Очевидно, что разработкой ТЗ занимается не директор компании-исполнителя, а подчиненный ему системотехник или аналитик, получающий при дележке пирога лишь маковую росинку. Неосторожное слово, косой взгляд директора могут привести к тому, что штык системотехника окажется направленным против собственной компании.
В этом случае приведенный выше сценарий начнет раскручиваться с точностью до наоборот. Капканы будут расставлены не на Заказчика, а на Исполнителя, и Заказчик об этом будет предупрежден — системотехник всегда имеет с ним прямой контакт. А предупрежден — значит вооружен.

Умный Заказчик, наивный Исполнитель

Умный Заказчик, как правило, в прошлой жизни — умный Исполнитель. Такой Заказчик не станет ни в чем препятствовать Исполнителю и обеспечит ему полную свободу словоизвержения. В результате Исполнитель устроит засаду себе сам.
Широко распространенная фраза, фигурирующая в большинстве ТЗ, разрабатываемых в софтверных компаниях, «программа должна обладать интуитивно понятным пользовательским интерфейсом», — классический образец наивности (если не сказать — глупости) Исполнителя. Заказчик при приемке работы заявит, что не обладает достаточными для работы с таким интерфейсом понятливостью и интуицией. Исполнитель будет вынужден переделывать интерфейс до тех пор (за собственный счет, разумеется), пока Заказчику не надоест игра в кошки-мышки.
Хорошо известен трюк, построенный на невнимательности Исполнителя, когда последний попросту забывает расписать пределы ответственности каждой из сторон. Испытания, к примеру, согласно ГОСТ 34.603-92, принято проводить на объекте Заказчика, но в стандарте не указано явно, на чьих ТС. И тут-то у Исполнителя появляется отличная возможность предоставить Заказчику собственные ТС или приобрести их за свой счет.
А если в ТЗ указаны условия эксплуатации технических средств, выходящие за рамки нормальных климатических условий, то Заказчик получит все основания заставить Исполнителя провести климатические испытания. Кому довелось проводить «климатику», да еще и с интервалом в полградуса, наверное, вздрогнул, читая эти строки.
И подобных капканов и засад в ТЗ может быть множество.
Как указывалось выше, разработка ТЗ непосредственным Исполнителем — вариант наиболее распространенный. Но в данном случае и Заказчику, и Исполнителю следует быть бдительными, держать нос по ветру.
При отходе от идеализированной модели — возврату к жизненным реалиям, положение Исполнителя становится несоизмеримо более тяжелым. Ответственный за проект, будь то директор лично, руководитель проекта и т. п., оказывается между молотом и наковальней. Сверху давит Заказчик, снизу отбрыкивается человеческий фактор. В результате в подавляющем большинстве случаев Заказчик попросту садится на шею Исполнителя. Каждый сам кузнец своего счастья. Руководитель-исполнитель, склонный придерживаться точки зрения «незаменимых нет», будет по жизни возить Заказчика на своем горбу. Мудрый руководитель создаст своим ключевым специалистам максимально благоприятные условия и станет чувствовать себя не вожаком волчьей стаи, а основателем собственной школы.

Разработка ТЗ на тендерной основе

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

Разработка ТЗ сторонним Исполнителем

Разработка ТЗ сторонним исполнителем — явление, встречающееся все чаще. Институт фрилансерства медленно, но уверенно пробивает себе путь к Солнцу. Фрилансеры охотно берутся и за мелочевку, и за крупномасштабные проекты вроде «Электронной России». Заказчик, как правило, остается доволен.
Фрилансеров можно условно поделить на две категории: вольные стрелки и методисты.
Вольные стрелки, рыскающие в поисках заработка в Интернете, образуют сетевые профессиональные сообщества, отслеживают рейтинги исполнителей, публикуют сведения о недобросовестных работодателях и исполнителях. В среде вольных стрелков часто встречаются настоящие профессионалы - писатели, журналисты, преподаватели, научные работники и т. п.
Методисты — менее подвижная категория фрилансеров. Они, как правило, неплохо устроены, работают в солидных компаниях и, в силу своих профессиональных навыков, частенько выполняют месячную норму в весьма сжатые сроки. Избыток свободного времени требует заполнения. И специалист, скорее ради живого интереса, чем ради денег, возьмется за сторонний проект. Действительно, любопытно: сколько времени может потребоваться, чтобы перекроить ТЗ на информационно-измерительную систему в полноценное ТЗ на систему электронного документооборота?
При взаимодействии с таким Исполнителем Заказчик может быть полностью уверен в том, что разработка ТЗ будет выполнена в его интересах. А если Исполнитель узнает, что разработку проекта по ТЗ предполагается передать в компанию, на которую Исполнитель имеет зуб...

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

Алексей Колесников
"Мир Автоматизации", август 2006

автор: Алексей Колесников , источник: http://authorit.ru  

← Вернуться к списку статей