Техническое задание

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

Куда пропало понимание

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

Спешка только навредит

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

Техническое задание решит многие проблемы

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

Совместная работа

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

Максимум внимания важно уделить деталям

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

И вот здесь то и возникает естественный вопрос: А насколько детальным должно быть описание? Думаю что ответ уже абсолютно очевиден: он просто обязан быть максимально детализирован, и не допускать нигде двояких толкований! Но… и тут есть грани разумного при составлении технического задания.

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

Гибкость - закон сохранения баланса

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

Уже составленное техническое задание на внедрение «1С» подлежит в очередной раз подробнейшему изучению и прочтению. И только когда не будет возникать ни одного вопроса и схема будет казаться идеальной — есть шанс, что оно действительно так и есть.