Каким должно быть ТЗ на Корпоративную ИС?

А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще.

Мы так и поступили, вместо того, чтобы пытаться остаться в одном, Первом ТЗ, мы создали 300.
Не за один день, но подход был выбран именно такой.

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

В поисках идеального тз, вы не получите не продукта, ни тз.

Вторая статья в списке для чтения на Хабре по теме как раз про это.
Полное отсутствие ТЗ порождает Diff(-erence) между тем что сделано и ожиданиями Заказчика.
ТЗ эту разницу позволяет сократить. Что включать в ТЗ это уже предмет изучения шишек на лбу команды.

Если Заказчик не зрелый в области проектирования своих собственных бизнес-процессов, то с ним точно надо описывать Бизнес-процесс с применением ИС. Это точно лучше, чем множество итераций/спринтов, и через них приходить с ним к тому процессу который будет ему удобен и более эффективен в сравнении с тем, что у него был до этого. Будет и быстрее по времени и ресурсов «сожжено» меньше.

Мой опыт говорит о том, что когда Заказчик не знает чего хочет, быстрой итерационной разработкой это не лечится.

Дальше бизнес-процесса и сценариев использования системы можно не углубляться, если у вас чистое поле или «свежий» функционал.

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

Момент определяется достаточно просто, когда используя старую парадигму написания легкого ТЗ или без него, вы начинаете делать что-то, выпускаете обновление и что-то в другом месте отваливается.
Чем чаще и в больших местах отваливается, тем больше это становится актуальным.

Вариант и даже очень.

Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.

А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.

Мы лечили это следующим образом:

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

Знаю, что некоторые ребята не просто картинки рисуют, а создают буквально работающее решение, которое можно «покликать». Делают с помощью Axure. Почитать и посмотреть можно здесь.

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

Цитата из 34.602:

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС,
Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).
6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.
7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

Это рекомендованное дополнение, и тем не менее.
Руководитель предприятия заказчика и не должен изучать ТЗ — ему достаточно листа согласования. Все дело уже в том, как он составлен.

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

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

В нашем случае это была Pivotal CRM и покупалась в том момент, когда система входила в лидеры квадранта Gartner. Нас оправдывает только то, что лучших практик тогда не было.
Система создавалась для развития ипотечного рынка.
Ребята ездили в Америку изучать ИТ-системы и опыт Freddie Mac и Fannie Mae.
После этого было принято решение делать своё.

Система ежегодно переваривает ипотечных закладных на 60 млрд. рублей.
Выглядит с одной стороны много, но уже с масштабами Сбербанка не сравнить.
Его ИС переваривают ипотечных закладных на 661 млрд. рублей.

Комментарий Кирилла навел меня на ряд размышлений, что вылилось в не короткий ответ (читать ниже), который лучше раскрывает поднятую тему.

Locolind, 7 ноября в 22:31
Добрый вечер, Кирилл.

Благодарю за комментарий к статье «Каким должно быть ТЗ?» у меня займёт некоторое время подготовить для вас ответ.
Хочу уточнить у вас, какие разделы показались вам лишними / не нужными в нашем шаблоне ТЗ?
И если есть возможность, то дайте комментарий почему считаете его лишним.

Askofen, 9 ноября в 01:13
Добрый вечер, Максим!

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

Когда документ согласован, то, в зависимости от объема, в системе контроля задач создается новый проект либо создается новая задача. А на ее основе создаются задачи для разработчиков.

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

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

На мой взгляд, в статье перепутаны 2 разных документа: техническое задание и руководство пользователя.

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

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

• на 80% готовое руководство пользователя, его остается сгруппировать и структурировать по ролям/группам пользователей.
• готовые сценарии для функционального тестирования.

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

У нас техническое задание пишется на текущее изменение системы, т.е. на то, что нужно добавить, удалить или изменить.

В документации на КИС нужно отражать изменение бизнес-процесса и ИТ-решения чтобы обеспечить целостность первого.

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

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

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

Вторая причина – ему не дадут это сделать после, а не до. Система находится под большой нагрузкой, переваривает 60 миллиардов рублей в год, в день это 170 мил. рублей в день. В ней работает более 2000 пользователей. Простой системы – это финансовые потери и последующие «перегрузки» в работе компании, так как выпавший в работе день нужно будет нагонять. Есть понимание что “time to market” должен быть минимален на столько на сколько это возможно, но при условии, что риск будет сопоставим с получаемой выгодой. Если риск убытков высок, а выгода не покрывает их, то мы склоны сперва спроектировать новый бизнес процесс, посмотреть как мы будем работать на тестовой среде и только после этого ставить обновление на промышленную систему и проводить изменение в бизнес-процессах компании.

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

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

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

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

Информационная карточка (за исключением истории изменений и, возможно, этапов внедрения)

Мне кажется, вы смотрите на неё только с точки зрения Разработчика.
Основание для разработки – это для Аудита, чтобы связать то что сделано (на что были потрачены ресурсы) с бизнес-запросами (обоснованием этих затрат).
Тема разработки и бизнес-процесс предназначены для Бизнес-аналитика по направлению, чтобы внести данные в реестр ТЗ и в последующем осуществлять навигацию и поиск нужных ТЗ.
Постановка задачи, задачи и цель также предназначены для Бизнес-аналитика, чтобы быстро «считать» о чем ТЗ, что им реализовано.
Охваченные компоненты – это для Архитектора и Системного Аналитика, чтобы быстро «считать» есть ли интеграция с чем-то ещё или всё в рамках одной ИС.
Этапы внедрения – это для Заказчика и Руководителя ДИТ фиксирующие факт окончания работ и подтверждения, что решение принято Заказчиком.

Думаю, что документ можно разделить на 2 документа или на 2 части.

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

Бизнесовая часть также состоит из двух частей «Тела» и «Приложений».
В Приложения выносятся формы Отчетов, описание Алгоритмов и всё подобное.

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

За излишней детализацией незримо присутствует нотация IDEF0 (SADT), которая говорит, что у действия есть вход, выход, кто это действие выполняет, инструменты и управление. Мы дополняем вход указанием от кого кому, откуда куда, так как описание текстовое.

В таком виде документ поступает на вход бизнес-аналитику, и он готовит второй документ (или вторую часть документа), в которой рисует screen-flow и мокапы экранов.

1. А почему вы этого сотрудника называете бизнес-аналитиком, а не системым аналитиком?
2. И кто тогда готовит тот документ, который поступает на вход «бизнес-аналитику»?

Сложилось впечатление, что вы так разводите два этапа работ, описание бизнес-процесса и проектирование программы.

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

Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.

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