Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Вы же в курсе, что ракеты, как практически и любой сложный современный продук так и создаются — детали делаются в разных местах, а затем собираются в единый продукт. В поисках идеального тз, вы не получите не продукта, ни тз. А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще. А для простого продукта тз можно писать прямо на ходу, а то и постфактум.
А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще.
Мы так и поступили, вместо того, чтобы пытаться остаться в одном, Первом ТЗ, мы создали 300.
Не за один день, но подход был выбран именно такой.
Не факт, что их нужно было 300, но это материал для «рефакторинга» ТЗ.
Если 40 ТЗ описывают одну функциональную область и каждое из них про свою процедуру, есть повод задуматься про структурирование информации.
Сейчас это проблема решена на уровне меток / тегов с названиями бизнес-процессов и бизнес-процедур, указываемых к каждому ТЗ.
В поисках идеального тз, вы не получите не продукта, ни тз.
Вторая статья в списке для чтения на Хабре по теме как раз про это.
Полное отсутствие ТЗ порождает Diff(-erence) между тем что сделано и ожиданиями Заказчика.
ТЗ эту разницу позволяет сократить. Что включать в ТЗ это уже предмет изучения шишек на лбу команды.
Если Заказчик не зрелый в области проектирования своих собственных бизнес-процессов, то с ним точно надо описывать Бизнес-процесс с применением ИС. Это точно лучше, чем множество итераций/спринтов, и через них приходить с ним к тому процессу который будет ему удобен и более эффективен в сравнении с тем, что у него был до этого. Будет и быстрее по времени и ресурсов «сожжено» меньше.
Мой опыт говорит о том, что когда Заказчик не знает чего хочет, быстрой итерационной разработкой это не лечится.
Дальше бизнес-процесса и сценариев использования системы можно не углубляться, если у вас чистое поле или «свежий» функционал.
Но если у вас одно цепляет за другое, то это опять повод писать ТЗ и уже начинать продумывать техническое решение, что мы сможем реализовать в рамках того что сами уже сделали, а что нет и нужно предлагать Заказчику альтернативные варианты решения его бизнес-задачи.
Момент определяется достаточно просто, когда используя старую парадигму написания легкого ТЗ или без него, вы начинаете делать что-то, выпускаете обновление и что-то в другом месте отваливается.
Чем чаще и в больших местах отваливается, тем больше это становится актуальным.
Если в ТЗ есть текст типа
то:
1. удивительно, что оно на 40 страниц
2. это плохое ТЗ
Правильнее писать в ТЗ верхнеуровневый список функциональности, которая будет сделана, например:
шаг 1 Ввод клиентских данных
шаг 2 Сохранение клиентских данных.
Документ №1 (основное ТЗ): Сделать поле 1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
то:
1. удивительно, что оно на 40 страниц
2. это плохое ТЗ
Правильнее писать в ТЗ верхнеуровневый список функциональности, которая будет сделана, например:
шаг 1 Ввод клиентских данных
шаг 2 Сохранение клиентских данных.
Ага, то есть написать Т.З. в текстовом файле, положить его в git и иметь всё, что вы описали (изменения, навигацию, подпись только под diff-ом) и много чего еще (pull — request-ы, например) — не вариант?
Вариант и даже очень.
Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.
Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.
Заказчик подписывал первую часть ТЗ и только её
А потом начнется: "А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.
И все переделки/доделки, конечно же, за счёт исполнителя.
А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.
Мы лечили это следующим образом:
- Описание выполнения бизнес-операций сопровождалось картинками, где уже на старте было видно как будут выглядеть кнопочки, где круглые, а где красненькие. Что в ответ на их нажатие появится.
- Мы настраивали Заказчиков минимум на три итерации. Первая — минимально работающее ИТ-решение решающее бизнес-задачу. Вторая — удобно и красиво. Третья — чтобы быстро работало.
- Заказчик подписывал первую часть ТЗ и проверял в соответствии с ней, всё что не вошло в ТЗ, это дополнительное требование. Дополнительные требования оплачиваются за счёт Заказчика. При этом главный критерий приемки — то, что созданный ИТ-продукт решает бизнес-задачу ради которой задумывался. Система выдаёт целевой бизнес-результат, указанный в ТЗ.
Знаю, что некоторые ребята не просто картинки рисуют, а создают буквально работающее решение, которое можно «покликать». Делают с помощью Axure. Почитать и посмотреть можно здесь.
Если у вас объём выполняемой работы находится в значительном дисбалансе с выделяемыми на неё средствами, то это говорит о неправильно построенном организационном и финансовом взаимодействии заказчика и исполнителя. И никакими формальными шагами технарей по уточнению ТЗ это исправить не удастся.
ТЗ выдаёт заказчик, детали работы исполнителя его не должны интересовать. В описанном случае исполнитель нагрузил заказчика несвойственной ему работой по согласованию требований к действиям разработчиков. По ГОСТу, если так уж хочется согласовать конкретный способ реализации, то разрабатывается и защищается технический проект.
На месте заказчика, я бы послал исполнителя с таким подробным ТЗ.
На месте заказчика, я бы послал исполнителя с таким подробным ТЗ.
Цитата из 34.602:
Это рекомендованное дополнение, и тем не менее.
Руководитель предприятия заказчика и не должен изучать ТЗ — ему достаточно листа согласования. Все дело уже в том, как он составлен.
2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС,
Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).
6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.
7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.
Это рекомендованное дополнение, и тем не менее.
Руководитель предприятия заказчика и не должен изучать ТЗ — ему достаточно листа согласования. Все дело уже в том, как он составлен.
Я говорю о том, что ТЗ не должно (или почти не должно) содержать требований по способу реализации функций системы. Это внутренний вопрос исполнителя, часть его работы. Заказчика не должно волновать, каким именно образом исполнитель сделает ему красиво.
Это да, там это практически прямо написано:
Т.е. нельзя писать «язык программирования — Java», например. Это можно писать уже в проектной документации.
Другими словами, заказчик не может требовать сортировку пузырьком, но он может требовать определенной скорости сортировки на неком типовом наборе данных, например. Или ограничить занимаемый при этом объем памяти. Но не конкретный алгоритм и не конкретный язык.
Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.
Т.е. нельзя писать «язык программирования — Java», например. Это можно писать уже в проектной документации.
Другими словами, заказчик не может требовать сортировку пузырьком, но он может требовать определенной скорости сортировки на неком типовом наборе данных, например. Или ограничить занимаемый при этом объем памяти. Но не конкретный алгоритм и не конкретный язык.
Мы работаем по методологии Agile, но с использованием стиля Waterfall, а именно отталкиваемся от небольших спринтов, которые основаны на требованиях заказчика, далее делаем макет приложения и потом пишем ТЗ на приложение/АС, документ подписывает заказчик и он передаётся всем участникам разработки, в итоге за короткий период мы получаем работающий скелет ПО, на который навешиваем игрушки выпуская новые версии моб. приложения :-) Главная ценность такого подхода — экономия бюджета заказчика, нашего времени для написания ТЗ и разработку ПО!
Первый пункт я так понимаю это классическое прототипирование?
Вот поэтому и все движутся в направлении DevOps. Документация — это тоже продукт и она должна разрабатываться по аналогии с исходными кодами. Т.е. должа быть система контроля версий (не важно SharePoint или что-то более удобное), все изменения должны быть легко отслеживаемыми (в Word-е есть отслеживание изменений и комментарии для этих целей).
На мой взгляд лучше иметь один актуальный документ, чем кучу приложений. Приложения могут показываться заказчику и подписываться им, но в этих приложениях — просто список изменений по отношению к предыдущей версии ТЗ.
На мой взгляд лучше иметь один актуальный документ, чем кучу приложений. Приложения могут показываться заказчику и подписываться им, но в этих приложениях — просто список изменений по отношению к предыдущей версии ТЗ.
Забавно читать подобные статьи, когда ни разу не работал по подобным тз :-)
Я фрилансер, работаю в разных командах исключительно с технически-грамотными заказчиками из «далекого зарубежа».
Мне трудно представить масштаб проекта взятого в пример для этой статьи, так что, если у вас проект размером с авиалайнер, то, мое мнение, вероятно, не релевантно.
Так вот, я работаю в основном по системе scrum или тому подобных решениях. Никогда вообще не встречал тех проблем, что вы описали, хотя постоянно о них слышу… исключительно от тех, кто работает с заказчиками из рф.
Я фрилансер, работаю в разных командах исключительно с технически-грамотными заказчиками из «далекого зарубежа».
Мне трудно представить масштаб проекта взятого в пример для этой статьи, так что, если у вас проект размером с авиалайнер, то, мое мнение, вероятно, не релевантно.
Так вот, я работаю в основном по системе scrum или тому подобных решениях. Никогда вообще не встречал тех проблем, что вы описали, хотя постоянно о них слышу… исключительно от тех, кто работает с заказчиками из рф.
Никогда вообще не встречал тех проблем, что вы описали, хотя постоянно о них слышу… исключительно от тех, кто работает с заказчиками из рф.
Возможно это особенность нашей страны, когда крупная компания покупает платформу от западного вендора и ваяет на её основе систему под собственные нужды, изменив её так, что ты уже не можешь обновится до следующей выпущенной версии от вендора.
В нашем случае это была Pivotal CRM и покупалась в том момент, когда система входила в лидеры квадранта Gartner. Нас оправдывает только то, что лучших практик тогда не было.
Система создавалась для развития ипотечного рынка.
Ребята ездили в Америку изучать ИТ-системы и опыт Freddie Mac и Fannie Mae.
После этого было принято решение делать своё.
Система ежегодно переваривает ипотечных закладных на 60 млрд. рублей.
Выглядит с одной стороны много, но уже с масштабами Сбербанка не сравнить.
Его ИС переваривают ипотечных закладных на 661 млрд. рублей.
И какой объём занимало ТЗ на ИТ-системы Freddie Mac и Fannie Mae?
Не смогу ответить на ваш вопрос. Был не с самого начала появления нашей системы.
Пришел работать в компанию уже после того, как ребята съездили в командировку, CRM-система была закуплена и развернута, начат процесс по её доработке/развитию.
У нас был и электронный и бумажный архив документации на систему. Последний ведется по той причине, что компания каждый год проходит проверку Генеральной Прокуратурой и Счетной Палатой на предмет целевого расходования средств, так как основной акционер компании Государство.
Их интересует:
— кто авторизовал расходование средств на ИТ-систему,
— на что они пошли и зачем это было нужно,
— кто делал / кто получил деньги,
— кто осуществлял приемку.
в 2014 году начали экспериментировать с Электронно-Цифровой Подписью для взаимодействия внутри и с Партнерами, чтобы отказаться от бумажного документооборота в пользу юридически значимого электронного.
Погуглил.
Так как у меня остались смутные воспоминания, со времен изучения SADT, что в Америке в 70-е годы документация на ИТ-системы доходила до нескольких тон, если это касалось систем масштаба страны.
Structured Analysis and Deign Technique появилась в 1969-1973 году.
Упомянутые здесь в комментариях GIT и SVN появились в 2000-е.
CVS первый выпуск 1990.
Freddie Mac появилась в 1970 году.
в 2006 году оборот компании 44 млрд. долларов.
Активы в 2015 году 1,946 трлн. долларов.
Fannie Mae появилась в 1938 году.
Активы в 2014 году 3,2 трлн. долларов.
Даты создания компаний, масштаб бизнеса, дата появления SADT и даты появления систем управления версиями указывают на то, что у каждой ТЗ на ERP-систему могло быть больше чем в 3 шкафа.
Пришел работать в компанию уже после того, как ребята съездили в командировку, CRM-система была закуплена и развернута, начат процесс по её доработке/развитию.
У нас был и электронный и бумажный архив документации на систему. Последний ведется по той причине, что компания каждый год проходит проверку Генеральной Прокуратурой и Счетной Палатой на предмет целевого расходования средств, так как основной акционер компании Государство.
Их интересует:
— кто авторизовал расходование средств на ИТ-систему,
— на что они пошли и зачем это было нужно,
— кто делал / кто получил деньги,
— кто осуществлял приемку.
в 2014 году начали экспериментировать с Электронно-Цифровой Подписью для взаимодействия внутри и с Партнерами, чтобы отказаться от бумажного документооборота в пользу юридически значимого электронного.
Погуглил.
Так как у меня остались смутные воспоминания, со времен изучения SADT, что в Америке в 70-е годы документация на ИТ-системы доходила до нескольких тон, если это касалось систем масштаба страны.
Structured Analysis and Deign Technique появилась в 1969-1973 году.
Упомянутые здесь в комментариях GIT и SVN появились в 2000-е.
CVS первый выпуск 1990.
Freddie Mac появилась в 1970 году.
в 2006 году оборот компании 44 млрд. долларов.
Активы в 2015 году 1,946 трлн. долларов.
Fannie Mae появилась в 1938 году.
Активы в 2014 году 3,2 трлн. долларов.
Даты создания компаний, масштаб бизнеса, дата появления SADT и даты появления систем управления версиями указывают на то, что у каждой ТЗ на ERP-систему могло быть больше чем в 3 шкафа.
На мой взгляд, в статье перепутаны 2 разных документа: техническое задание и руководство пользователя. У нас техническое задание пишется на текущее изменение системы, т.е. на то, что нужно добавить, удалить или изменить. Если же есть необходимость поддерживать в актуальном состоянии руководство пользователя, то изменения в нем должны вноситься техническим писателем параллельно с изменениями в системе (или сразу после них).
Посмотрел на Ваш образец технического задания. Если речь идет о внутренней разработке, то, на мой взгляд, оно чрезвычайно сложное и изобилует ненужными разделами. Мы придерживаемся той точки зрения, что результат нашей работы — это готовая программа, а не техническое задание. Поэтому стараемся делать его максимально кратким и максимально полезным.
Посмотрел на Ваш образец технического задания. Если речь идет о внутренней разработке, то, на мой взгляд, оно чрезвычайно сложное и изобилует ненужными разделами. Мы придерживаемся той точки зрения, что результат нашей работы — это готовая программа, а не техническое задание. Поэтому стараемся делать его максимально кратким и максимально полезным.
Комментарий Кирилла навел меня на ряд размышлений, что вылилось в не короткий ответ (читать ниже), который лучше раскрывает поднятую тему.
Корпоративное ПО создается для решения специфичной для данного бизнеса задачи, часто это решение является неповторимым. Для другой компании оно не подойдет, так как рабочий процесс у неё устроен по другому.
Заложенная в решение бизнес-логика толкает исходную информацию по производственной цепочке. Главная задача обеспечить работоспособность бизнес-процесса, а не Корпоративной ИС.
По этой причине описывать работу Корпоративной ИС лучше с точки зрения бизнес-процесса, а не функциональных возможностей системы.
Когда описываешь КИС с позиции рабочего процесса ТЗ начинает сильно быть похожим на руководство пользователя, охватывая работу разных типов пользователей в ней. Те участки, что не покрывались текущим решением отражались на схеме и в описании как выполняемые без КИС. Это служит целеуказателем куда дальше развивать ИТ-решение.
Полученный документ это:
В этом отличие внутри разработанного ПО от массового, универсальных продуктов, таких как Atlassian JIRA. Последние представляют собой набор кубиков, из которых создаешь нужное решение. Если тебе их не хватает ты можешь поискать другие на маркете или сделать свои. Для таких систем документацию стоит описывать с точки зрения функциональных возможностей кубика, что им можно делать и для чего использовать, и отражать изменения в работе функциональности.
В документации на КИС нужно отражать изменение бизнес-процесса и ИТ-решения чтобы обеспечить целостность первого.
В нашем случае описать изменения в функциональности технический писатель может, а вот отразить изменения в бизнес-процессе и сделать это по факту нет.
Причина первая – технический писатель не бизнес-аналитик и часто не владеет глубокими познаниями как в конкретном бизнес-процессе так и в их цепочке в целом. Скажу что это даже не его работа, не его задача.
Вторая причина – ему не дадут это сделать после, а не до. Система находится под большой нагрузкой, переваривает 60 миллиардов рублей в год, в день это 170 мил. рублей в день. В ней работает более 2000 пользователей. Простой системы – это финансовые потери и последующие «перегрузки» в работе компании, так как выпавший в работе день нужно будет нагонять. Есть понимание что “time to market” должен быть минимален на столько на сколько это возможно, но при условии, что риск будет сопоставим с получаемой выгодой. Если риск убытков высок, а выгода не покрывает их, то мы склоны сперва спроектировать новый бизнес процесс, посмотреть как мы будем работать на тестовой среде и только после этого ставить обновление на промышленную систему и проводить изменение в бизнес-процессах компании.
Взгляните на это с ещё одной точки зрения, что результат нашей работы это не готовая программа, а новое ИТ-решение включающее и программу и бизнес процесс.
Согласен с вами, в общем случае это лишнее. В текущем виде отражена особенность нашей внутренней процедуры работы с документами. У нас тоже был электронный документооборот. Вместо того, чтобы заменить бумажный он стал для него учетной системой, в которой отражается статус прохождения бумажного документа, а в конце прикрепляется скан.копия с «живыми» подписями заинтересованных и ответственных сторон. Поэтому лист согласования присутствует в шаблоне, на нем эти «живые» подписи затем собирались.
Мне кажется, вы смотрите на неё только с точки зрения Разработчика.
Основание для разработки – это для Аудита, чтобы связать то что сделано (на что были потрачены ресурсы) с бизнес-запросами (обоснованием этих затрат).
Тема разработки и бизнес-процесс предназначены для Бизнес-аналитика по направлению, чтобы внести данные в реестр ТЗ и в последующем осуществлять навигацию и поиск нужных ТЗ.
Постановка задачи, задачи и цель также предназначены для Бизнес-аналитика, чтобы быстро «считать» о чем ТЗ, что им реализовано.
Охваченные компоненты – это для Архитектора и Системного Аналитика, чтобы быстро «считать» есть ли интеграция с чем-то ещё или всё в рамках одной ИС.
Этапы внедрения – это для Заказчика и Руководителя ДИТ фиксирующие факт окончания работ и подтверждения, что решение принято Заказчиком.
Документ поделен на две части, то что вы видите это бизнесовая часть, а есть ещё техническая, которую бизнес-пользователи не видят и которую пишет системный аналитик для разработчиков. В ней он каждое «Нажал на кнопку, появилась форма для заполнения Такая-то» переводит в список задач что нужно сделать и что изменить. Бизнесовая часть не указывает есть ли эта кнопка, появляется ли в результате нажатия именно эта форма. Бизнесовая часть — это чистая фантазия Пользователя/Заказчика и Бизнес-аналитика на тему как будет выглядеть выполнение бизнес-операции в системе.
Бизнесовая часть также состоит из двух частей «Тела» и «Приложений».
В Приложения выносятся формы Отчетов, описание Алгоритмов и всё подобное.
За излишней детализацией незримо присутствует нотация IDEF0 (SADT), которая говорит, что у действия есть вход, выход, кто это действие выполняет, инструменты и управление. Мы дополняем вход указанием от кого кому, откуда куда, так как описание текстовое.
Сложилось впечатление, что вы так разводите два этапа работ, описание бизнес-процесса и проектирование программы.
В нашем случае мы сразу проектируем бизнес-процесс визуализируя его на системе. То что нам может не хватить технических возможностей, Бизнес-аналитика и Пользователя этим не заморачиваем, пусть рисуют концепт. Дальше в момент анализа и проектирования технических решений станет ясно, что можем, а что не можем и какую альтернативу будем предлагать Пользователю, чтобы обеспечить тот же результат выполнения бизнес-операции.
Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.
Так решается проблема, что ребята могут придумать новый концепт, который в корне отличается от существующего, разработаны новые регламенты и подготовлено ИТ-решение, но им просто Страшно переходить на новую схему, так как никто в ней не умеет работать, полное виденье есть у Начальника и Проектировщика, но им страшно не меньше чем всем остальным. Страх нагоняет упоминавшийся выше контекст, что подразделение находится под существенной нагрузкой и они не готовы к возможным не предвиденным остановкам. Поэтому здесь работает стратегия эволюционных изменений в сторону нового концепта.
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 и мокапы экранов.
- А почему вы этого сотрудника называете бизнес-аналитиком, а не системым аналитиком?
- И кто тогда готовит тот документ, который поступает на вход «бизнес-аналитику»?
Сложилось впечатление, что вы так разводите два этапа работ, описание бизнес-процесса и проектирование программы.
В нашем случае мы сразу проектируем бизнес-процесс визуализируя его на системе. То что нам может не хватить технических возможностей, Бизнес-аналитика и Пользователя этим не заморачиваем, пусть рисуют концепт. Дальше в момент анализа и проектирования технических решений станет ясно, что можем, а что не можем и какую альтернативу будем предлагать Пользователю, чтобы обеспечить тот же результат выполнения бизнес-операции.
Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.
Так решается проблема, что ребята могут придумать новый концепт, который в корне отличается от существующего, разработаны новые регламенты и подготовлено ИТ-решение, но им просто Страшно переходить на новую схему, так как никто в ней не умеет работать, полное виденье есть у Начальника и Проектировщика, но им страшно не меньше чем всем остальным. Страх нагоняет упоминавшийся выше контекст, что подразделение находится под существенной нагрузкой и они не готовы к возможным не предвиденным остановкам. Поэтому здесь работает стратегия эволюционных изменений в сторону нового концепта.
Максим,
Это нормально. Главное, что бы логически задания (и модифицируемые системы) были выстроены правильно (с точки зрения их иерархии). В Вашем случае, как я понял иерархия (и логическая последовательность) выглядят так:
Бизнес-процесс => Приложение => UI => Подсистемы приложения
В таком случае, сначала пишется ТЗ, в котором излагаются новые требования к бизнес-процессу. Результат выполнения этого ТЗ — это описание нового или измененного бизнес-процесса.
Измененный бизнес-процесс предъявляет новые требования к приложению. Поэтому следующим шагом пишется ТЗ для приложения. В качестве первого шага при подготовке этого ТЗ описываются изменения, которые необходимо внести в существующий интерфейс. Но не в виде конкретных решений, а в виде проблем (что надо добавить? что — изменить? чего не хватает?) Затем вырабатываются решения перечисленных проблем, которые представляются в виде мокапов, screen flows, детальных юз-кейсов и т.д. и т.п.
После этого (или параллельно с этим) начинает готовиться документ, в котором описываются изменения в архитектуре системы, новые компоненты, диаграммы взаимодействия и т.д.
Все это можно оформить как в виде различных документов, так и разделами одного документа. Это непринципиально. Главное — соблюдать последовательность.
Заложенная в решение бизнес-логика толкает исходную информацию по производственной цепочке. Главная задача обеспечить работоспособность бизнес-процесса, а не Корпоративной ИС.
Это нормально. Главное, что бы логически задания (и модифицируемые системы) были выстроены правильно (с точки зрения их иерархии). В Вашем случае, как я понял иерархия (и логическая последовательность) выглядят так:
Бизнес-процесс => Приложение => UI => Подсистемы приложения
В таком случае, сначала пишется ТЗ, в котором излагаются новые требования к бизнес-процессу. Результат выполнения этого ТЗ — это описание нового или измененного бизнес-процесса.
Измененный бизнес-процесс предъявляет новые требования к приложению. Поэтому следующим шагом пишется ТЗ для приложения. В качестве первого шага при подготовке этого ТЗ описываются изменения, которые необходимо внести в существующий интерфейс. Но не в виде конкретных решений, а в виде проблем (что надо добавить? что — изменить? чего не хватает?) Затем вырабатываются решения перечисленных проблем, которые представляются в виде мокапов, screen flows, детальных юз-кейсов и т.д. и т.п.
После этого (или параллельно с этим) начинает готовиться документ, в котором описываются изменения в архитектуре системы, новые компоненты, диаграммы взаимодействия и т.д.
Все это можно оформить как в виде различных документов, так и разделами одного документа. Это непринципиально. Главное — соблюдать последовательность.
Да, вы верно ухватили суть и процесс.
Добавлю ещё пару уточняющих моментов.
Момент №1
Если функционал новый
После того как новый бизнес-процесс спроектирован и наложен на текущий интерфейс Приложения, Заказчик отключается от данного процесса и включается в работу Системный Аналитик.
Системный аналитик формулирует перечень проблем: что надо добавить и изменить. На основе подготовленного документа он общается с Архитектором и Разработчиков как они будут решены и добавляет ответы на вопросы к сформулированным проблемам, переводит их в задачи.
Решения показываются Бизнес-аналитику, он их проверяет на соответствие целям и результатам бизнес-операций. Если технические ограничения не позволяют реализовать бизнес-процесс в заявленном виде, уже отталкиваясь от текущих возможностей Бизнес-аналитик готовит новый вариант выполнения бизнес-операции и согласовывает с Заказчиком.
На этом этапе согласования подключается Тестировщик и вместе с Системным Аналитиком готовит сценарии тестирования.
Документ, разработанный Системным аналитиком, и всё что готовится дальше Заказчику не показывается. Заказчик получает подтверждение Бизнес-аналитика, что Приложение будет обеспечивать новый вариант бизнес-процесса, Заказчик подтверждает, что мы можем начинать реализацию.
Если функционал не новый
Изменения в реализованный бизнес-процесс Бизнес-аналитик вносит через документ «Дополнение к ТЗ», который указывает какой раздел описания бизнес-процесса изменяется и на что.
И далее по цепочке, подключается Системный аналитик и анализирует новые требования к Приложению.
Момент №2
Наличие «картинок и кнопок» в ТЗ делает описание бизнес-процесса для Заказчика похожим на правду. Из абстрактного, описание превращается в конкретное.
Сравните
Создаёт в системе новое поручение через специальную экранную форму.
И
Нажимает на кнопку «Создать новое поручение»
,
на открывшейся форме «Нового поручения»
сотрудник ОККЭ заполняет поля …
Если Пользователь уже знает интерфейс системы, то для него такое описание выглядит ещё более правдивым.
Когда ТЗ содержит много абстракций и они ссылаются друг на друга, Пользователи теряют общее видение решения и отсюда «прилетают» ошибки в логике работы, которые хуже ошибок в коде. Ошибку в коде можно быстро поправить, а ошибку в реализованной логике может и не получится быстро устранить.
Добавлю ещё пару уточняющих моментов.
Момент №1
Если функционал новый
После того как новый бизнес-процесс спроектирован и наложен на текущий интерфейс Приложения, Заказчик отключается от данного процесса и включается в работу Системный Аналитик.
Системный аналитик формулирует перечень проблем: что надо добавить и изменить. На основе подготовленного документа он общается с Архитектором и Разработчиков как они будут решены и добавляет ответы на вопросы к сформулированным проблемам, переводит их в задачи.
Решения показываются Бизнес-аналитику, он их проверяет на соответствие целям и результатам бизнес-операций. Если технические ограничения не позволяют реализовать бизнес-процесс в заявленном виде, уже отталкиваясь от текущих возможностей Бизнес-аналитик готовит новый вариант выполнения бизнес-операции и согласовывает с Заказчиком.
На этом этапе согласования подключается Тестировщик и вместе с Системным Аналитиком готовит сценарии тестирования.
Документ, разработанный Системным аналитиком, и всё что готовится дальше Заказчику не показывается. Заказчик получает подтверждение Бизнес-аналитика, что Приложение будет обеспечивать новый вариант бизнес-процесса, Заказчик подтверждает, что мы можем начинать реализацию.
Если функционал не новый
Изменения в реализованный бизнес-процесс Бизнес-аналитик вносит через документ «Дополнение к ТЗ», который указывает какой раздел описания бизнес-процесса изменяется и на что.
И далее по цепочке, подключается Системный аналитик и анализирует новые требования к Приложению.
Момент №2
Наличие «картинок и кнопок» в ТЗ делает описание бизнес-процесса для Заказчика похожим на правду. Из абстрактного, описание превращается в конкретное.
Сравните
Создаёт в системе новое поручение через специальную экранную форму.
И
Нажимает на кнопку «Создать новое поручение»
,на открывшейся форме «Нового поручения»
сотрудник ОККЭ заполняет поля …
Если Пользователь уже знает интерфейс системы, то для него такое описание выглядит ещё более правдивым.
Когда ТЗ содержит много абстракций и они ссылаются друг на друга, Пользователи теряют общее видение решения и отсюда «прилетают» ошибки в логике работы, которые хуже ошибок в коде. Ошибку в коде можно быстро поправить, а ошибку в реализованной логике может и не получится быстро устранить.
Перенес
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каким должно быть ТЗ на Корпоративную ИС?