• Нужно ли разрабатывать техническое задание или проектную документацию для автоматизации на базе платформы 1С?

    Читать полностью
23/12/2015

Введение

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

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

     Применительно к платформе 1С ситуация не радует: лишь в редких случаях происходит документирование требований заказчика и прорисовка проектных решений. Чаще всего заказчик полагается на опыт нанимаемого специалиста или привлекаемой на аутсорсинг компании. При этом клиент забывает, что при почасовой системе оплаты труда исполнитель не заинтересован в документировании или фиксации каких либо технических решений. Если же работа построена как проект на сдельной системе оплаты, то исполнитель первый обратится к заказчику, чтобы тот подписал функциональные требования, но неправильно составленная документация не сильно прояснит заказчику основной вопрос — за что именно он платит.

     Цель данной статьи — дать конкретные рекомендации по составлению документации при реализации проектов 1С. Причем речь пойдет именно о низкобюджетных небольших проектах, которыми на 90% заполнен рынок. Прежде чем углубиться в подробности анализа вопроса, добьемся четкого понимания, что такое техническое задание и что такое проект.



Что такое техническое задание и технический проект

     Действительно, существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать деятельность по разработке программного обеспечения. Существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно правда где-то посередине, но на самом деле ГОСТы не раскрывают практических проблем современной разработки программного обеспечния, в том числе и на платформе 1С, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

     Если говорить более предметно о документе «техническое задание», то он регламентируется в следующих ГОСТах:

• ГОСТ 2.114-95 «Единая система конструкторской документации. Технические условия»;

• ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению»;

• ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

НАДОЕЛО ЧИТАТЬ?

Оставь запрос, мы объясним суть статьи по телефону

     Основное назначение техзадания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе. Для разделения требований по видам нам поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования к функциональности;

• Требования к безопасности и правам доступа;

• Требования к квалификации персонала

• и т.д.

     Ключевым фактором успешного технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик. Требования к функциональности – это 90% сложности работ по разработке технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. При этом формально все требования будут соблюдены (по ГОСТу), ТЗ разработано, утверждено и подписано, деньги за него получены.

     Как должны формулироваться требования? Если виды требований могут быть различными в зависимости от целей проекта, то качество или свойства требований должны удовлетворять следующим определениям:

• Требование должно быть понятным;

• Требование должно быть конкретным;

• Требование должно быть тестируемым;

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

     В общих чертах суть документа «техническое задание» пояснена, теперь уточним еще несколько важных моментов:

• На каком языке (в смысле сложности понимания) должно быть написано техническое задание?

• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические подробности?

• Что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с техническим заданием?

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

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

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



Граница между техническим заданием и техническим проектом

     Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ – много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. После этого неизбежно начинается сериал про сдачу работ. «А вот тут не так, как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!

     Обычно мы имеем размытую границу между техническим заданием и техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. С точки зрения разработки это плохо, а получается так, потому что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени – это факт). Есть и еще один важный фактор, влияющий на использование технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, ниже мы рассмотрим ее немного подробней.

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



Можно ли обойтись вообще без технического задания

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

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

1. Полное отсутствие документации. О всех последствиях сказано выше. Разработчик не всегда делает так, как хочет клиент. Иногда он просто не понимает или забывает требования.

2. Уровень технической поддержки. Регистрация заявок в системе helpdesk. Небольшие задачи и доработки, свой штатный программист 1С.

3. Частично разрабатывается техническое задание. Проект либо не разрабатывается вовсе, либо представлен в виде несложных концептуальных зарисовок. Именно к этой категории относятся наиболее часто встречающиеся проекты в сфере 1С с объемом работы от 40 до 200 часов.

4. Полностью разрабатывается и ТЗ и проект. Эта ситуация крайне редко встречается в 1С и всегда встречается в госзаказах (требование законодательства).

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

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



Разработка или доработка

     Хотелось бы отдельно остановиться на интересной детали технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется в виду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например, создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов.

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

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

     В принципе можно смело утверждать, что такая практика в 1С и привела к абсолютному бардаку в вопросах документирования 1С проектов. С другой стороны, приходилось сталкиваться и с другой крайностью, когда под госзаказ на автоматизацию подрядчик написал ТЗ и проект к уже готовым функциям 1С. Выглядело это так, как будто 1С разрабатывали заново. На вопрос, зачем все это надо, ответ был фантастическим: «Надо же что-то писать». При этом в проекте выполнялась большая доработка стандартного функционала, и в принципе, именно это нужно было задокументировать и в ТЗ и ТП. Однако исполнитель испугался, что документация будет «тонковата» или просто не знал, как процесс доработки вписать в архитектуру 39 ГОСТа.

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

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

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

     Однако описывать новое видение заказчиком уже готовой системы по объему работы не меньше чем исходная документация на саму систему 1С. Например, для «1С Управление производственным предприятием» ТЗ будет порядка 10000 страниц. Получается, что каждое изменение требует не меньшего объема – это очевидная глупость. Но не меньшая глупость писать требования, вырванные из контекста уже существующего решения. Нужно подробно описывать, почему решили добавить новую кнопку, чем старая кнопка не устраивала и каковы последствия вплоть до изменения бизнес-процесса и регламента. Тогда техническое задание по доработке будет иметь смысл. Конечно, это все равно будут фрагменты исходной системы, но уже полезные и понятные, на основе которых можно программировать конечную систему. Такое задание будет полезно коммерческому заказчику, деньги потраченные на него принесут отдачу.

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



Водопадный процесс или циклический

     Процесс разработки — это еще один важный вопрос, очень актуальный в целом в софтверной отрасли, но практически никогда не рассматривающийся в практике управления проектами на 1С. Фактически ГОСТом установлен последовательный, водопадный или каскадный процесс разработки ПО. Согласно Wikipedia:

     Каскадная модель (англ. waterfall model, иногда переводят как модель "Водопад") — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

Водопадный процесс разработки

Итеративный процесс разработки



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

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

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

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

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



Компонентная архитектура

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

     Дело в том, что мало предприятий готовы сразу перейти на монолитное решение класса ERP (1С ERP или 1С Управление производственным предприятием, сокращенно 1С УПП), поэтому многие выращивают свою автоматизацию постепенно из различных конфигураций. Например, для задач управленческого учета подойдет конфигурация «1С Комплексная автоматизация», для бухгалтерии «1С Бухгалтерия», для зарплаты и кадров - «1С Зарплата и управление персоналом». Есть много других готовых решений 1С, закрывающих складскую, проектную деятельность и многое другое. Данные решения могут работать отдельно или быть интегрированы в основные решения 1С, но на практике многие предпочитают работать с ними по отдельности.

     Почему? Ответ на этот вопрос не лежит на поверхности, в печатном виде редко где можно встретить его обсуждение. Дело в том, что потребность в единой высокоинтегрированной монолитной системе ERP обосновывается чисто ИТ-шными соображениями, выгода от этого не существенна. Зато вред от внедрения такой системы может быть весьма значительным, особенно он заметен на примере малых предприятий. Проще говоря, интегрированные решения не востребованы на ранних стадиях развития бизнеса, а именно такого бизнеса в России большинство.

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



Что писать в документации для проекта 1С

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

     За основу можно взять все тот же ГОСТ 39*, адаптировав его под специфику 1С. Во первых нужно прописать бизнес-процессы TO BE, то есть как они будут происходить после автоматизации или доработки. Важно отметить, что одно и тоже имеет смысл написать с применением функционального, процессного моделирования и смоделировать потоки данных в понятиях 1С. Разные диаграммы нужны для разных целей, одни пойдут программистам, а другие будут использоваться на стадии внедрения для обучения пользователей.

     Далее нужно описать конкретные доработки, изменения, создания новых объектов платформы 1С:

• Справочников, регистров

• Документов

• Отчетов

• Обработок

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

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

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

      Интересным в 1С является связь «на основании». Фактически можно связать между собой какие угодно между собой документы и получить сеть. В практике связи документов являются мощным инструментом навигации пользователей, поэтому настоятельно рекомендуется проектировать его и активно использовать в разработке.

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

     Что же тогда включается в техническое задание? Все просто: требования пользователя, которые привели к проектированию системы. То есть мыслим обратно, если мы спроектировали документ, то зачем? Должно быть предложение, картинка или что-то другое, что объясняло бы, почему вы решили начать проектировать этот элемент системы.

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

ОСТАЛИСЬ ВОПРОСЫ?

Мы ответим на любой интересующий вас вопрос по интеграции

     Теперь более конкретно, что желательно видеть в ТЗ:

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

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

3. Описание ожидаемых результатов от реализации проекта. В этом же разделе описвается, какие действия по проекту уже были сделаны.

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

5. Более детальное описание требований заказчика. Оно должно быть подробней, чем в пункте 1, можно воспользоваться структурой ГОСТа на ТЗ. Особо ценной является следующая информация:

a. Детализированное словесное описание задачи с применением графики, таблиц, примеров

b. Уже спроектированные решения документов, отчетов, как их видит заказчик

c. Вопросы интеграции и взаимодействия с другими информационными системами

d. Технические, организационные, кадровые и прочие требования

6. Описание бизнес–процессов как они должны быть (TO BE). Этот пункт желательный, но не принципиальный. Если проект сложный то нужно зафиксировать о чем думает заказчик и как он себе это представляет

7. Организация проекта. Реализация, внедрение, тестовая, опытная эксплуатация, границы ответственности исполнителя, организация работы команды исполнителей, роль заказчика — все что важно знать для успешной организации и окончания проекта.



Заключение

     В статье рассмотрены многие вопросы и ситуации, которые могут возникнуть при реализации и документировании проекта 1С ERP. В принципе, наиболее оправданным представляется минималистический подход: чем тоньше, тем лучше и дешевле. Однако явно показано, когда и где возникнут проблемы, если делать документацию слишком «худой». Самое главная и сложная часть работы, на которую уйдет как минимум 90% времени и усилий при разработке технического задания — это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать.

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

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



ключевые слова: техническое задание Владивосток, ТЗ, технический проект Владивосток, водопадный, каскадный, ГОСТ, разработка 1С erp Владивосток