Categorized | Мнение

Технические задания, какие они бывают?!

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

Итак, Технические задания на разработку….
Какие ж они бывают? Очень разные.


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

2. Разработчик профессионал в функциональном направлении.
В этом случае ТЗ может быть сформировано в одно-два предложения, далее РЕАЛЬНЫЕ примеры:
А) Текущая сводная задолженность по дебиторам/кредиторам общей суммой (раздельно по Дт., Кт.) и разложенная по срокам возникновения (сроки — до 30 дней, от 31 до 60, от 61 до 90, от 91 до 180, свыше 180). Сводную задолженность формировать по связанным в учетных записях дебиторам/кредиторам. Любая указанная сумма по требованию представляется в развернутом до документа виде, позволять проваливаться в документ. Проверка полномочий — просмотр документов дебиторов и кредиторов.
Б) Предыдущий отчет сделать не по текущей задолженности, а с возможностью задавать отчетную дату.

3. Нормальный разработчик.
Самый стандартный случай — формализации подлежит полный перечень всех параметров запуска разработки с конкретным указанием parameters or select-option. Обязательно указываются все предполагаемые к использованию таблицы. Если связь между таблицами идет по совпадающим полям (типа knb1-kunnr = kna1-kunnr) то такие связи не указываются. Если связь требует более сложных условий, стоит их прописать:

Через таблицу CSSL связываемся с таблицей COST, где определяем тариф операции. В таблицу CSSL заходим полным ключом: KOKRS = VBRP-KOKRS; KOSTL = определяем из рабочего места, LSTAR = AFRU-LEARR; GJAHR = Год с поля AFRU-BUDAT.

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

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

Стоимость Основного средства на первое января отчетного года формируется по данным таблицы ANLC – Поля значений Основного средства. Первоначальная стоимость = ANLC-KANSW — Первоначальная стоимость нарастающим итогом + ANLC-KAUFW — Повышение восстановительной стоимости нарастающим итогом; Начисленная амортизация = ANLC-KNAFA — Типовая амортизация нарастающим итогом + ANLC-KSAFA — Особая амортизация нарастающим итогом + ANLC-KAAFA — Внеплановая амортизация нарастающим итогом + ANLC-KAUFN — Корректировка типовой амортизации с повыш. коэффициентом НИт.

Искренне надеюсь, что примеры различных вариантов ТЗ полностью продемонстрировали все их разновидности.

Теперь о реальных проблемах, которые могут возникнуть (и возникают) из-за поверхностного знакомства разработчиков с системой, из-за их доверия постановщику. В первую очередь все проблемы возникают из-за того, что системы разработки слишком далеки от продуктивных систем по наполнению информацией и если в системе разработки находится порядка 50 учетных записей дебиторов/кредиторов — то разработчику совершенно все равно с какой стороны начинать поиск дебиторов/кредиторов для их последующей связи по налоговым реквизитам. Вот только, когда в Продуктивной системе оказывается 1 000 кредиторов и 100 000 дебиторов — тут уж разница огромная в направлении подхода. Но такие случаи крайне редки.

Намного больше проблем возникает при отладке в реальных условиях связок select/loop — увы, даже на ОЧЕНЬ похожих системах это работает крайне по-разному. Даже продуктивная система и восстановленная из резервной копии на аналогичном железе продуктивная система дают разные результаты — ведь на копии невозможно повторить нагрузку от пары сотен активных пользователей. Вот и получается, что описанный в ТЗ последовательный сбор данных, их доукомплектация могут быть реализованы разными методами — от тупого следования по ТЗ, до реальных попыток постараться максимально комбинировать опробованные на Продуктивной системе методы. Причем, чаще лучший результат дает именно их комбинация.
Тут выход один — реальный опыт разработчика! Именно реальный и именно на конкретной системе, где впоследствии и будет постоянно использоваться разработка!

Комментарии

  1. Как по мне очень узкие определения.

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

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

    1. Речь о SAP
      В этом случае, техническое задание — документ-заказ на конкретную программу — отчет, интерфейс, но не на весь проект.

      А документ, которые определяет что и как будет работать в Проекте внедрения SAP, обычно называется «Концептуальный проект».
      Часто не один, а несколько — по направлениям: Финансы, Управленческий учет, Закупка, Сбыт….
      Допускается, что вместо большого документа «Концептуальный проект» можно использовать набор отдельных «Проектных решений».