Меню

Техническое задание. Теория и действительность

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

Теория

Техническое задание на разработку ПО / доработку SAP (далее по тексту - ТЗ) в теории является неотъемлемым элементом процесса разработки ПО (SAP). В общих чертах, полный цикл разработки ПО выглядит следующим образом:

  1. Ключевой пользователь со стороны бизнеса готовит ПЗ (Постановку задачи). В ПЗ он описывает, какой функционал должно обеспечить разрабатываемое ПО, какую бизнес-информацию и в каком формате требуется отображать и/или обрабатывать. Всё это описывается в терминах бизнес-процесса без «технической» информации.
  2. SAP-консультанты по соответствующим модулям на основе ПЗ готовят ТЗ (каждый свою часть). В ТЗ детально описывается алгоритм со всеми техническими деталями: какие поля и каких таблиц участвуют в логике разработки, какие связи и зависимости используются в логике приложения, по каким критериям отбирается информация, каким образом она отображается и/или как она обрабатывается. Если предполагается использовать стандартный функционал (функции, методы классов и т.п.), то указывается, какие параметры надо передавать, какие накладывать ограничения и как использовать полученные результаты.
  3. Программист, на основе ТЗ, осуществляет реализацию разработки (доработку системы).

В такой схеме от программиста не требуется знание бизнес-логики и структуры бизнес-данных того или иного модуля. Его задача сводится к чистому кодированию. Отсюда, кстати, и традиционный коэффициент 0,8 при оплате труда разработчика пришедший к нам с запада, где всё и происходит по вышеописанной схеме.

Практика

А как же всё происходит у нас в действительности? Не претендуя на объективность, буду основываться только на личном опыте, включающем около двух десятков проектов. Картина вырисовывается следующая.

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

В половине случаев имеются утверждённые правила оформления ТЗ, но они не соблюдается. Разработка начинается по неоформленному ТЗ. В начале консультанты пытаются оформлять ТЗ по шаблону, но чем ближе дедлайн, тем реже это происходит и, в конце концов, всё сводится к первому варианту «отсутствия ТЗ». Стандартное оправдание в таких случаях – нехватка времени.

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

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

Как хотелось бы. Пожелания разработчика

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

  • Организационная информация. В ней указывается, к какому модулю относится разработка, её код в общем реестре разработок, автор ТЗ, приоритет разработки и т.п. Информация важная с точки зрения менеджмента проекта, но разработчику малополезная.
  • Описание функционала. В общих чертах. Примерно то, что пишет ключевой пользователь в Постановке задачи. Только не надо утрировать и описывать функционал в мельчайших подробностях, несущественных для разработчика. Разработчику надо «в целом» понимать, что от него хотят и что в итоге должно получиться.
  • Если это ТЗ на создание отчета/формуляра, то обязателен перечень критериев отбора данных. Собственно, содержимое экрана выбора. Обязательно с указанием, можно ли задавать множество/диапазон для критерия выбора, или только единичное значение. (Иными словами, понятными техническим специалистам, это parameters или select-options).
  • Если

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев22

Комментарий от  

Олег Точенюк

  |  20 августа 2013, 00:55

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

Комментарий от  

Николай Кронский

  |  22 августа 2013, 08:57

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

Комментарий от  

Сергей Теплов

  |  28 августа 2013, 11:28

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

Комментарий от  

Олег Точенюк

  |  28 августа 2013, 13:33

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

Я бы добавил к "зеленый" еще такое как "ленивый" :-)

Комментарий от  

Кирилл Яковлев

  |  29 августа 2013, 09:54

Отличная статья! Незаменивый вклад в процессы производства систем на базе ПО SAP в РФ.
 
Пожелания:
- в наименовании статьи следует сразу отразить, что речь идет исключительно о "ТЗ" на ABAP-разработку. Есть еще масса других направлений (SAP BO, BPC, KNOA, ...), где эти правила не применимы за отсутствием состава объектов.
- заменить ТЗ на "Спецификация на разработку". ТЗ как правило преследует значительно более широкий спектр целей - это Вам не просто "спека".
- продолжать выпуск подобного полезного материла

Комментарий от  

Александр Неловкин

  |  29 августа 2013, 10:01

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

Согласен, утопия.
Уж и помечтать нельзя? :)

Комментарий от  

Александр Неловкин

  |  29 августа 2013, 10:06

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

Сергей, полностью согласен с поэтапной разработкой! Как правило, этот метод и оказывается самым эффективным. Эффективней только написание разработки самим постановщиком-консультантом.

Комментарий от  

Павел Мартынов

  |  29 августа 2013, 10:17

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

Комментарий от  

Степан Лаврентьев

  |  29 августа 2013, 10:58

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

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

Комментарий от  

Алексей Шарифуллин

  |  29 августа 2013, 11:21

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

Комментарий от  

Иван Кондаков

  |  29 августа 2013, 12:10

Согласен, утопия.
Уж и помечтать нельзя? :)

Николай, вы предлагаете ликвидировать консультанта(-ов)?:)

Комментарий от  

Иван Кондаков

  |  29 августа 2013, 12:11

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

Николай, вы предлагаете ликвидировать консультанта(-ов)?:)

Комментарий от  

Иван Кондаков

  |  29 августа 2013, 12:12

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

с хорошими бюджетами и штатами можно много чего:)

Комментарий от  

Иван Косенко

  |  29 августа 2013, 13:11

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

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

Комментарий от  

Николай Кронский

  |  09 сентября 2013, 14:51

Николай, вы предлагаете ликвидировать консультанта(-ов)?:)

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

Комментарий от  

Олег Башкатов

  |  13 сентября 2013, 22:49

Это пожелания кодера, а не разработчика.

Комментарий от  

Олег Точенюк

  |  14 сентября 2013, 21:13

Это пожелания кодера, а не разработчика.

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

Комментарий от  

Олег Башкатов

  |  15 сентября 2013, 00:54

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

я оценку знаниям не давал - не знаю, где Вы это усмотрели в комменте; думаю, Вам нужно браузер сменить.
 
я мог бы, конечно, начать оправдываться, мол я имел ввиду, что есть потребность в хорошо_оформленном коде, а есть потребность в быстром решении задачи с помощью программного кода...но это лишнее.
 
скажу тем языком, который Вы понимаете (sapland.ru/articles/spj):
меня не тра@ает ваше мнение, характеристики и оценка.
 
В большинстве случаев, это Вы меня комментируете, а не я Вас. Ваши-то статьи для меня интереса не представляют, ровно, как и комменты.

Комментарий от  

Олег Точенюк

  |  15 сентября 2013, 01:25

я оценку знаниям не давал - не знаю, где Вы это усмотрели в комменте; думаю, Вам нужно браузер сменить.
 
я мог бы, конечно, начать оправдываться, мол я имел ввиду, что есть потребность в хорошо_оформленном коде, а есть потребность в быстром решении задачи с помощью программного кода...но это лишнее.
 
скажу тем языком, который Вы понимаете (sapland.ru/articles/spj):
меня не тра@ает ваше мнение, характеристики и оценка.
 
В большинстве случаев, это Вы меня комментируете, а не я Вас. Ваши-то статьи для меня интереса не представляют, ровно, как и комменты.

"Это пожелания кодера, а не разработчика" - ну что же переведите, как вы же нужно читать ваш коментарий, потому что я прочитал это как, автор кодер, а не разработчик. Статья то авторская. Потому что если он разработчик, то не может писать такие пожелания.
 
А статьи мои не надо читать, вы дальше складики для подотчетников грузите :-)

Комментарий от  

Олег Башкатов

  |  15 сентября 2013, 01:44

"Это пожелания кодера, а не разработчика" - ну что же переведите, как вы же нужно читать ваш коментарий, потому что я прочитал это как, автор кодер, а не разработчик. Статья то авторская. Потому что если он разработчик, то не может писать такие пожелания.
 
А статьи мои не надо читать, вы дальше складики для подотчетников грузите :-)

что Вы там прочитали и подумали пусть останется у Вас.
 
на всякий случай: слово "комментарий" пишется с 2мя буквами "м".
 
Вы мою наизусть выучили?
наверное, не ложитесь спать без неё.
и правильно, ведь проект LSMW-то оказался гораздо менее затратен по времени, чем Ваш код и более универсален.
 
здесь-то ваш подход с оптимизацией не прошел...

Комментарий от  

Олег Точенюк

  |  15 сентября 2013, 02:07

что Вы там прочитали и подумали пусть останется у Вас.
 
на всякий случай: слово "комментарий" пишется с 2мя буквами "м".
 
Вы мою наизусть выучили?
наверное, не ложитесь спать без неё.
и правильно, ведь проект LSMW-то оказался гораздо менее затратен по времени, чем Ваш код и более универсален.
 
здесь-то ваш подход с оптимизацией не прошел...

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

Комментарий от  

Евгений Никонов

  |  06 ноября 2013, 11:01

Читая заголовок подумал про ТЗ на внедрение какой-нибудь системы, а тут просто по сути спецификация/ТЗ на разработку.=)
Если разработчик толковый, можно вообще без спеки обойтись, но потом тяжело будет через полгода вспоминать, а что и как там сделано. Поэтому спека еще упростит поддержку внедренного решения, главное она должна быть актуальна, т.к. в процессе реализации часто изменяется до неузнаваемости.