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