Оправдание технического задания

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


Рис. 1. Из карикатуры Скотта Адамса. (Тот же сюжет, но в переводе на русский язык).

<--03.10.2013 12:32-->

Нам, с нашей бескрайностью чувств, неприятно думать, что есть нечто, принуждающее мыслить и действовать в определенных рамках. Другое дело сесть и в кругу таких же как мы творческих людей обсудить задачу, поспорить, наметить основные направления работ. Разбежаться по свои местам, напряженно поработать. Еще раз собраться, показать друг-другу свои достижения, обменяться новыми мыслями, что-то уточнить. И так до тех пор пока заветная цель не будет достигнута.
Предполагается, что все члены нашего творческого коллектива беззаветно преданы достижению одной главной цели, до такой степени, что решение всех остальных житейских проблем считают второстепенными. Как писал Булат Окуджава, «…нам нужна одна победа, Одна на всех мы за ценой не постоим».
При всей привлекательности этой формы коллективной работы, она имеет два недостатка:

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

К тому же, как говорится, «все дело в том, что к сожаленью, войны для вас пока что нет»! А раз так, то вполне уместен вопрос: сколько времени может просуществовать группа людей, которая принесла в жертву свои интересы и интересы своих родных, друзей? Пусть ответит читатель по своему усмотрению, а мы продолжим.

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

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

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

Где нет законов, не бывает и преступлений

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

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

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

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

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

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

«Кто был охотник? — Кто — добыча?»

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

Экскурс в Арбатов

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

Ситуация с информационными системами на рынке очень напоминает ситуацию с бизнесом Адама Козлевича. Разработчики информационных систем верят, что результаты их труда позволят повысить степень управляемости организацией или органом управления, за счет точного учета и анализа большого объема данных, который невозможно за разумное время обработать в ручном режиме. Но редко кто из современных руководителей считает эту цель чем то важным, а, тем более, понимает, какую роль в ее достижении играют информационные технологии.
Управляемость тормозится стремительно возрастающим объемом данных, который нужно учитывать как в повседневной организационный деятельности, так и выборе правильной стратегии развития. Необходимость обработки постоянно растущего объема разнообразия данных провоцирует расширение управленческого персонала. Рост числа управленцев в свою очередь отрицательно влияет на управляемость.
Замкнутый круг?!

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

«И как смешна нелепая игра…»

Итак, стремление не включать в техническое задание точных требований – это результат либо незнания, либо желания применить один из множества «сравнительно честных способов отъема денег» у партнера.
Для анализа того, как взаимодействуют заказчик и исполнитель при отсутствии точных требований к заказанной информационной системе, введем двух условных действующих лиц нашего исследования: Бармалея и Незнайку.
Бармалей – это человек, которого совсем не интересуют функции проектируемой информационной системы. Информационная система ему нужна как формальный продукт, наличие которого позволяет ему заслужить расположение начальства и(или) получить хорошее материальное вознаграждение. Подтверждать свой статус и укреплять материальное положение необходимо постоянно. Поэтому единственным важным для Бармалея условием является скорость получения информационной системы, как результата деятельности, которую он представит как свою.

«Незнайка» это человек, которому важны функции проектируемой информационной системы, но он считает, что эти функции он сможет домыслить за своего партнера, или, что партнер домыслит функции Незнайки за него самого.
Для наших целей достаточно посмотреть на четыре пары:

1. заказчик и подрядчик из Бармалеев;
2. заказчик – Бармалей, а подрядчик – Незнайка;
3. заказчик – Незнайка, а подрядчик – Бармалей;
4. заказчик и подрядчик из Незнаек.

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

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

Поэтому, в таблице решений Бармалей-заказчик и Бармалей-подрядчик получили по 100 баллов выигрыша.
Когда Бармалей заказывает Незнайке разработать информационную систему, он рассчитывает на то, что Незнайка сделает все сам, и не будет надоедать с многочисленными вопросами. Таким образом, Бармалей-заказчик рассчитывает на «клинического» Незнайку, который уверен, что знает о потребности заказчика много лучше, чем сам заказчик.
И все же Бармалей рискует. Во-первых, Незнайка увлекшись реализацией собственных представлений о нуждах заказчика может сорвать срок сдачи. Во-вторых, Незнайка может вдохновиться своей работой настолько, что начнет внедрять свой продукт в руководимой Бармалеем организации. Попытка внедрения вызовет скрытую панику среди сотрудников, на которых могут «повесить» дополнительную работу. Бармалею-руководителю придется выдержать волну недовольства в различных формах от служебных записок до истерик.
Но все эти проблемы несложно преодолеваются, поэтому в таблице решений Бармалей получил 90 баллов, а 10 баллов снято за необходимость терпеть избыточное рвение Незнайки.
Генри Форд говорил[5]: «противоестественно, когда человек, который хочет работать, не может получить ни работы, ни вознаграждения за нее». Наш Незнайка получил вознаграждение, но выполнил никому не нужную работу. Поэтому в таблице решений получил 50 баллов.
Незнайка, заказавший Бармалею разработать информационную систему, не получит ничего. Кроме того, он потратит массу незапланированных усилий на попытки наказать Бармалея, и не заплатить ему по контракту. Но эмоции, как и несбывшиеся ожидания, Незнайки арбитражный суд в расчет не примет. Поэтому в таблице решений Незнайка получил минус 100 баллов. Бармалей получил свои 80 баллов, затратив лишь 20 баллов на то, чтобы отбить не слишком опасные атаки Незнайки.
Незнайка-заказчик до последнего момента будет ждать наступления счастья от информационной системы, которую создаст подрядчик. Незнайка-подрядчик будет уверен, что созданная им информационная система осчастливит заказчика. Но, еще Аркадий Гайдар писал в повести «Чук и Гек», что такое счастье — это каждый понимал по-своему. Различие в понимании счастья от информационной системы приведет к конфликту Незнаек. Неразрешимому конфликту, потому что в споре эмоций истина не рождается. Оба Незнайки останутся в проигрыше. Заказчик не получил информационную систему. Подрядчик не получил контракта на продолжение работ или на техническую поддержку, за счет которого собирался покрыть затраты на реализацию собственных фантазий. В таблице решений оба получили по минус 50 баллов. Почему не минус 100? Потому что приобрели опыт, пусть и отрицательный.
Посмотрите на нашу таблицу решений. В выигрыше Бармалеи, т.к. их стратегия самая выигрышная. А это значит, что пустые технические задания плодят Бармалеев.
Рост популяции Бармалеев приводит к падению спроса на информационные системы.
Популяция разработчиков информационных систем стремительно сокращается, а Незнайки, не превратившиеся в Бармалеев, испытывают чувство глубокого разочарования в информационных системах.

Незнайка, учи матчасть!

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

1. Указ Президента РФ от 7 мая 2012 года N 601 «Об основных направлениях совершенствования системы государственного управления»: доля граждан, использующих механизм получения государственных и муниципальных услуг в электронной форме, к 2018 году — не менее 70 процентов
2. Паспорт «Программы инновационного развития ОАО «АВТОВАЗ»(www.avtovaz.ru/files/passport-pir.pdf ) содержит требование: сократить срок разработки автомобиля с 64мес. до 39мес. к 2016 году.
3. Руководитель ОАО Сбербанка России ставит цель: к концу 2012 года 90% клиентов «Сбербанка» должны быть обслужены в срок не более чем за 10 минут, в то время как в на начало 2011 года 80% клиентов Сбербанка обслуживались в среднем за 41 минуту.

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

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

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

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

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

Поэтому, техническое задание хорошего качества на разработку информационной системы может быть создано в результате совместной работы заказчика и исполнителя. При этом заказчик и только он несет полную ответственность за содержание Технического задания, как это и предусмотрено ГОСТами серии 19 и 34.
Создание технического задания заказчиком совместно со специалистами в области разработки информационных систем – это сложный процесс, требующий от заказчика дополнительных организационных усилий (см. Рис. 2, Рис. 3, Рис. 4).

В таком коллективном творчестве есть важные положительные стороны.
Совместно созданное техническое задание с большей вероятностью содержит цель разработки информационной системы, одинаково понимаемую заказчиком и подрядчиком. Как говорил Богданов [6], для того чтобы успешно выполнять совместную работу заказчику и подрядчику необходимо «столковаться». После того как стороны столковались, техническое задание может использоваться в качестве своеобразного переводчика с профессионального языка заказчика на профессиональный язык исполнителя, и позволяет контролировать ход разработки информационной системы как исполнителем, так и заказчиком. Как принято сейчас говорить, процесс разработки информационной системы станет открытым для заказчика. В результате такого контроля можно снижать риск срыва сроков разработки информационной системы.

Рис. 2,3,4. Шаги разработки и утверждения технического задания

Начало – половина дела

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

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

Стивен Макконнелл в своей книге «Сколько стоит программный проект» [7] использует очень наглядную метафору – «конус неопределенности».

Конус неопределенности, представляя собой плоскую фигуру похожую на конус, иллюстрирует изменения степени неопределённости в толковании требований к информационной системе по мере ее разработки.

За кажущейся абстрактностью значения степени неопределенности скрываются вполне земные проблемы. Наличие неопределенности – это возможные дополнительные затраты и увеличение сроков разработки информационной системы.

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

Рис. 5. Конус неопределенности

Элияху Голдратт в книге «Критическая цепь»[8] очень наглядно показал, как увеличение степени неопределенности в один и шесть десятых раза может увеличить затраты более чем в два раза. Поэтому, верхняя граница конуса указывает на изменение трудозатрат на разработку при расширенном толковании требований.

Нижняя граница конуса показывает изменение трудозатрат на разработку при упрощенном толковании требований. Ось конуса соответствует некому «нормальному» взгляду на требования.

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

Более того, если снижением степени неопределенности будет заниматься только исполнитель, то требования начнут упрощаться, если заказчик, то требования начнут усложняться. Поэтому на выше приведенных схемах (см. Рис. 2, Рис. 3, Рис. 4) предлагается применять механизм постоянного взаимодействия заказчика и исполнителя. Именно такой подход и предлагается в популярных agile-подходах — Scrum, ХР (экстремальное программирование), Lean (бережливое программирование) и Канбан. Но почему то концепция «пользовательские истории» воспринимается как отрицание технического задания.

Ну что ж, как говорится, было бы желание, а повод найдется.

После небольшого отступления вернемся опять к основной теме нашей статьи – необходимости тщательной разработки технического задания. Для этого стоит еще раз обратить внимание на конкретные значения неопределенности на рисунке. Так за период подготовки требований(читай технического задания), значение неопределенности уменьшается с 4 до 1.67, т.е. почти в половину.

 

Не зря говорят, что начало – половина дела.

Закон должен быть кратким

Древние римляне говорили, закон должен быть кратким. Техническое задание, в этом смысле –не исключение, т.е. техническое задание должно быть настолько кратким, насколько это возможно. Но как это сделать? Для ответа на этот вопрос, надо посмотреть на то, из чего состоит технического задание, т.е. на структуру документа.
Прежде всего, анализируя состав разделов технического задания, не грех следовать заповеди Иисуса, кесарю кесарево, а Божье Богу. Иными словами, следует разделять формальную и смысловую части технического задания.
Объем и содержание формальной части регламентирует правила взаимодействия заказчика и исполнителя (состав работ, порядок контроля, порядок приемки, и т.д.), и зависит от:

• действующего законодательства
• характера договоренности сторон договора;
• особенности разрабатываемой информационной системы.

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

Смысловая часть технического задания должна отвечать на вопросы, удивительно напоминающие гадание, «Что было? Что будет? Чем сердце успокоится?».

«Что было» и «что будет» должно быть описано в разделе «характеристика объектов автоматизации». А чем сердце успокоится должно описываться в разделах «назначение и цели создания системы» и «требования к системе».

Самым перспективным для сокращения разделом технического задания выглядит раздел «Характеристики объекта автоматизации». Потому что этот содержит сведения, необходимые для понимания и правильного истолкования главной части технического задания требований. Т.е. этот раздел восполняет пробел в знаниях исполнителя (а иногда и заказчика) о среде, в которой будет использоваться создаваемая информационная система.

Помните Тетя Полли в романе Марка Твена «Приключения Тома Сойера» дала Тому Сойеру ведро с известкой и велела покрасить забор. В этом случае техническое задание может содержать два требования:

• выбелить забор известкой;
• заказчик не против, если забор будет покрыт известкой в два или даже три слоя;
• особо поощряется, если в добавок к побелке на земле будет проведена белая полоса.

А теперь представим, что вместо Тома Сойера, нанимается мальчик, который не знает ни что такое забор, ни как выглядит известка. В этом случае, не обойтись без раздела «Характеристики окрашиваемого забора» со сведениями о заборе и известке.
Тогда пояснения тети Полли к характеристикам забора могут быть такими:

• сведения о том, как найти дом тети Полли смотрите в путеводителе по городку Питтсбург, что на берегу реки Миссисипи;
• сведения о том, как выглядит забор находятся в документе «Технический паспорт», который тетя Полли заблаговременно заказала в БТИ;
• сведения о том, что такое известка (гашеная известь) легко найти в справочниках по строительным материалам.

Когда заказывается информационная система, заказчик и исполнитель, чаще всего, люди с разных планет. В этих условиях без раздела «Характеристики объекта автоматизации» никак не обойтись. А так как нельзя положиться на знания исполнителя, то можно попробовать сослаться на эти знания изложенные в других документах.

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

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

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

Более подробно о качестве управления бизнес-процессами, а также той роли которую в этом играет описание процессов можно прочитать в очень увлекательной книге Влада Долгова «Страсти по ISO 9000» [9].

Итак, общий подход к сокращению затрат труда на разработку технического задания можно свести к следованию следующим правилам:

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

И рад бы в Рай, да грехи не пускают

И вот что странно – бизнес-процессы точно есть. Мы говорим прозой, а на работе включены в один или несколько бизнес-процессов. Но, как только мы делаем попытку рассмотреть один из таких бизнес-процессов, как он исчезает из поля зрения подобно зебре в глазах мухи цеце[10].

Объяснение этой форме своеобразной «слепоты» нашел 1925 году Алексей Капитонович Гастев, основоположник советской школы научной организации труда (НОТ). В своем анализе он противопоставлял два метода – ремесленный метод и метод массового производства[9].

Вот что пишет Алексей Капитонович, «для ремесленника характерен «секрет». Вся его жизнь есть сплошной заговор против других ремесленников, это сплошной заговор против всех непосвященных вообще, которые не знают, как выйти из положения в данном случае. Ремесленник не любит ничего, что бы выражалось в строго определенном расписании, в строго определенном регламентировании его работы. Он совершенно не терпит видимую для всех установку своей работы. По существу он – конспиратор и всегда гордится тем, что именно он, исключительно он, это знает. В скоро-массовом производстве всему этому противопоставляется все разоблачающая документация, выражающаяся в чертежах, диаграммах, инструкциях, в точных записях и эскизах того оборудования, которое необходимо для работы. Собственно говоря, весь смысл современного скоро-массового производства, в его противопоставлении ремеслу, заключается в этом сплошном разоблачении ремесленников, дни которых становятся все меньше и меньше, дни которых сочтены».

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

Два очень распространенных заблуждения мешают нам видеть и составлять описания бизнес-процессов?:

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

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

Когда управленческий процесс не организован, бездельников невольно плодят работающие сотрудники. Чем успешнее трудится сотрудник, тем больше ему поручают. А это рано или поздно приводит к излишнему перенапряжению этого сотрудника. Ценный сотрудник настаивает на том, чтобы ему в подчинение были выделены помощники. Но, в условиях не организованного бизнес-процесса, работающий сотрудник вынужден на лету создавать порядок выполнения каждого «горящего» поручения. Объяснение этого порядка, а тем более обучение помощников этому порядку, требует от работающего сотрудника дополнительных затрат времени и сил, что может отрицательно сказаться на оценке его труда начальником. Поэтому помощники часто оказываются незагруженными, а наш труженик по прежнему перегружен.

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

Административный регламент, по мнению Стаффорда Бира [13], представляет собою искусственный порядок, наложенный на действующую систему управления, порядок в которой создан в результате ее самоорганизации.

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

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

Из всего сказанного выше, можно сделать следующие выводы:

1. Описание текущего состояния системы управления нужно как ступень для ее развития, а не в качестве монумента этой системе на все времена.

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

3. Знание о правилах работы системы управления это основа для принятия решений о путях повышения эффективности выполнения управленческих функций, а также о целях и требованиях к усовершенствованной системе, можно будет обосновать.

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

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

«А напоследок я скажу»…

Подведем краткий итог нашего анализа предназначения технического задания на разработку информационной системы:

1. Техническое задание – это обязательная часть договора на разработку информационной системы. И поэтому требования технического задания регулируют отношения заказчика и исполнителя в процессе разработки информационной системы.

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

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

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

Так что, как писал Михаил Жванецкий, «тщательней надо, ребята». Тщательней нам с вами надо подходить к техническим заданиям на разработку информационных систем, если не хотим совсем уничтожить этот вид деятельности. Тем более, что эффективностью расходования денег на эти нужны уже не первый раз интересуется Счетная палата Российской Федерации.

Литература

1. Михаил Аркадьевич Иванов, Давид Матвеевич Шустерман. Организация как ваш инструмент: Российский менталитет и практика бизнеса. М: «Альпина Бизнес Букс», 2006.
2. У. Росс Эшби. Введение в кибернетику. Пер. с англ. – М.: Издательство: КомКнига, 2006. – 432 с.
3. Игра на третьей волне. Портал «Красноярск.Биз»,11.10.2004
4. СкоттАдамс. Мне нужно знать твои требования, чтобы начать дизайн программы. Сайт DilbertbyScottAdams, 2006.01.29.Русский перевод здесь.
5. Генри Форд. Моя жизнь, мои достижения; пер. с англ. Е. Кочергин, Н. Рудницкая. М: «Манн, Иванов и Фербер», 2013. – 304 с.
6. Александр Александрович Богданов. Тектология: Всеобщая организационная наука. М: «Финансы», 2003. – 496 с – 304 с.
7. Стивен Макконнелл. Сколько стоит программный проект. СПб.: Питер,М.: «Русская редакция», 2007. — 304 с
8. Элия Голдратт. Критическая цепь Минск.: «Попурри», 2013. –240 с.
9. Влад Долгов. Страсти по ISO 9000. Грустно-комическая повесть о получении сертификата на систему качества. Издательский текст: Вершина; Москва; 2006
10. Стивен Джорж, Арнольд Ваймерских. Всеобщее управление качеством: стратегии и технологии, применяемые сегодня в успешных компаниях. (TQM). СПб., «Виктория плюс», 2002 г. – 256 с.
11. Алексей Капитонович Гастев. Как надо работать. Практическое введение в науку организации труда./Под общ. ред. Н. М. Бахраха, Ю. А. Гастева, А.Г. Лосева, Е. А. Петрова. Изд. 3-е. М: Книжный дом «ЛИБРОКОМ», 2011. – 480 с.
12. Алексей Капитонович Гастев. Трудовые установки./Под общ. ред. Ю. А. Гастева, Е. А. Петрова. Изд. 3-е. М: Книжный дом «ЛИБРОКОМ», 2011. – 344 с.
13. Стаффорд Бир. Кибернетика и управление производством. Мифология систем под сводом сумерек. /Под ред. А.Б. Челюсткина. Пер. с англ. Изд. 2-е. М: Издательство «НАУКА», 1965. – 392 с.

Прежнее место размещения: http://www.torins.ru/support/blogs.php?page=post&blog=gladkov&post_id=98