Реферат: Принципы составления технического задания

Описание результатов работ и методов их приемки (методика и сроки проверки и тестирования клиентом соответствия выполненных работ написанному техническому заданию, протоколирование приемки).

Пример:

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

1.3 Механизм контроля за ходом проекта и квалификация консультантов

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

1.4 Согласование результата

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

Пример:

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

1.5 Гибкость

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

Пример:

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

2 «Подводные камни»

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

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

2.1 Причины разногласий

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

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

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

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

2.2 Нечеткие требования к проекту

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

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

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

3 Принципы составления ТЗ(ТЕХНИЧЕСКИЙ РЕГЛАМЕНТ «Процессы жизненного цикла программного обеспечения» RT 38370656 - 002:2006)

Жизненный цикл программной системы состоит из ряда этапов, на которых программная система планируется, создается, внедряется, эксплуатируется, сопровождается и списывается.

Типичная модель жизненного цикла программной системы состоит из шести этапов:

a) предпроектные работы;