Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.
Всё что нам казалось не очень важным тогда, со временем и в масштабе приобрело вид серьезной проблемы.
- Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
- Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
- Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?
Часть №1 “Разработка ТЗ”
«Заказчик: Ребята, это фигня какая-то, ничего не работает.
Разработчики: У нас всё сделано согласно ТЗ.»
Технические задания к КИС выглядели как систематизированные перечни требований. Разработать формы, создать поля такого-то типа, такой-то размерностью и логикой формирования… Отличный документ для разработчика, который быстро превращается в чек-лист того, что нужно сделать и проверки что сделано.
Была у этого одна проблема, если сравнить разработку КИС с постройкой ракеты, то это выглядело так, нужные детали создали, а в отдельных местах собирать и присоединять их не стали, так как не было сказано: а) что это нужно сделать, б) как нужно собрать.
При попытке запустить такую ракету в космос она взрывается, с КИС же:
«Заказчик: Ребята, это фигня какая-то, ничего не работает. Разработчики: У нас всё согласно ТЗ».
Чем больше был размах функционала КИС, тем больше аналитики залипали в детали, и тем чаще теряли виденье задачи целиком.
Итог: Заказчик недоволен и считает, что мы плохие Аналитики… и он прав.
Документ составлен для Разработчиков, а подписывается под ним Заказчик. Всё что в нём изложено «какие поля добавить и т.д.» его не интересует, он в этом не понимает и не должен разбираться, ему интересно получить работающее ИТ-решение его бизнес-задачи. Когда Заказчик ставит подпись на ТЗ он верит, что получит именно последнее.
Я прихожу к директору, я говорю:Аркадий Райкин
— Кто сшил костюм? Кто это сделал? Я ничего не буду делать, не буду кричать, я только хочу в глаза ему посмотреть.
Выходит сто человек. Я говорю:
— Ребята, кто сшил костюм?
Они говорят:
— Мы!
Я говорю:
— Кто это «мы»?
Они говорят:
— У нас узкая специализация. Один пришивает карман, один — проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
— Нет! Пришиты насмерть, не оторвёшь! Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?
Они говорят:
— Скажите спасибо, что мы к гульфику рукав не пришили.
Представляете? Их – сто, а я – один. И все стоят, как пуговицы: насмерть. И я сказал:
— Привет, ребята! Вы хорошо устроились!
Новый шаблон ТЗ мы разбили на две части: первая для Заказчика, вторая для Разработчиков.
Первую часть ТЗ разрабатывал Бизнес-аналитик с Заказчиком с установкой ни в чем себе не отказывать. На выходе этого полета фантазии идеальный описанный и иллюстрированный вариант выполнения бизнес-операции Заказчика с использованием КИС.
Дальше мечта бизнеса спускалась на бренную землю возможностей КИС, где Системный аналитик, Архитектор и Главный разработчик думали над тем как сказку сделать былью. Из горнила рождалась вторая часть ТЗ, которая трассировала бизнес-логику в требования к системе.
После появления второй части и подтверждения «Разработкой», что всё будет работать как описано в первой, Заказчик подписывал первую часть ТЗ и только её.
Так был дан ответ на вопрос «Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?».
Часть №2 “Обновление ТЗ”
«Собери общую картину работы функционала из 20 документов (Пазл 18+)»
Документ №1 (основное ТЗ): Сделать поле 1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
Документ №3 (Дополнение №2 к ТЗ): Внести изменения в поле №1, сделать поле №3.
Документ №4 (Сменился РП по направлению, поэтому создано новое ТЗ): Внести изменения в поле №2 и поле №3.
Документ №5 (Дополнение №1 к новому ТЗ): Внести изменение в поле №3 и №1, сделать поле №4.
Документ №6 (Новый РП нашел основное ТЗ, Дополнение №3 к основному ТЗ): Внести изменение в поле №2 и поле №4.
…
Вот что собой представлял набор документации по функционалу. Новый шаблон ТЗ имел все шансы повторить участь предшественника, в качестве решения выбрали «переписывать слова в песне».
С каждым новым изменением основное ТЗ переписывалось.
Мотив: у нас всегда один актуальный документ.
Нарисовалась проблема. Заказчик начал грустить, что из-за одного нового поля, он должен перечитывать весь документ, чтобы поставить на нем свою подпись. Представим, что одно ТЗ в среднем это 40 страниц, а в месяц Заказчик получает около 10 таких документов (фабрика же / быстрая разработка …).
Вернули дополнения к ТЗ и в них стали указывать, что на что меняем в основном ТЗ или какой новый раздел в него добавляем. Заказчик согласовывает дополнение к ТЗ на 2-3 страницы, а на его основании вносятся изменения в основное ТЗ. На выходе всё тот же один единственный документ, который описывает актуальное состояние ИТ-решения.
Так мы ответили на второй вопрос «Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?».
Часть №3 “Навигация по Техническим Заданиям”
Для навигации по ТЗ-ям мы использовали реестр ТЗ, изначально предназначенный для резервирования номеров под ТЗ и указание к нему такой исторической информации как:
- Подразделение заказавшее разработку
- Заказчик в подразделении, который формулировал и ставил задачу
- Руководитель проекта нашего отдела, который отвечал за его реализацию
- Системный аналитик подрядчика, писавший ТЗ для разработчиков
Описали базовый бизнес-процесс компании (без фанатизма, крупными мазками) и внутри по мере необходимости детализировали/дробили процессы на процедуры. Каждому ТЗ указывали в рамках какого бизнес-процесса выполняются работы и какую процедуру он реализует. По запросу бизнес-подразделения, определив какой бизнес-процесс будем автоматизировать или дорабатывать, сортировали общий пул и определяли будет ли это новое ТЗ или дополнение к существующему, что там уже есть и как работает.
Вот такое решение для последнего вопроса «Как в этом объеме документов найти те, что описывают работу определенного функционала системы?».
Каким должно быть ТЗ?
Моё мнение – оно должно быть постоянно эволюционирующим, решающим насущные задачи команды. Цель не впихнуть в него побольше, а фокусироваться на том с чем чаще всего команда сталкивается в виде проблемы, то с чем работать умеем плохо. Ровно тоже самое, что мы делает с ИТ-продуктом: начинаем с минимально необходимого, затем добавляем красоту и удобство, и в конце оптимизируем.
Поделитесь какое ТЗ у вас, под какие задачи оно у вас настроено и как с ними справляется.
Что хорошего почитать на Хабре по этой теме
- Применение Сценариев использования (use case) при разработке ТЗ
- Техническое задание на сайт
- Техническое задание на сайт. Практика
- Про процесс разработки ПО в компании Nevlabs с примером ТЗ (размещен на сайте компании)
Будет дальше регулярно пополняться.
» Пример первой части нашего ТЗ (в виде pdf на яндекс.диске)
Комментарии (22)
LanSaid
13.10.2016 13:51+2Если в ТЗ есть текст типа
Документ №1 (основное ТЗ): Сделать поле 1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
то:
1. удивительно, что оно на 40 страниц
2. это плохое ТЗ
Правильнее писать в ТЗ верхнеуровневый список функциональности, которая будет сделана, например:
шаг 1 Ввод клиентских данных
шаг 2 Сохранение клиентских данных.
mickvav
13.10.2016 14:28Ага, то есть написать Т.З. в текстовом файле, положить его в git и иметь всё, что вы описали (изменения, навигацию, подпись только под diff-ом) и много чего еще (pull — request-ы, например) — не вариант?
Locolind
13.10.2016 15:24Вариант и даже очень.
Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.remzalp
13.10.2016 23:44GIT + LaTeX
остаётесь в относительно текстовом файле, так что правки вполне читаемы в истории версий.
Богатство оформления и возможность вывести на выходе нормальный PDF
cognolio
13.10.2016 14:35Заказчик подписывал первую часть ТЗ и только её
А потом начнется: "А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.
И все переделки/доделки, конечно же, за счёт исполнителя.Locolind
13.10.2016 15:08А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.
Мы лечили это следующим образом:
- Описание выполнения бизнес-операций сопровождалось картинками, где уже на старте было видно как будут выглядеть кнопочки, где круглые, а где красненькие. Что в ответ на их нажатие появится.
- Мы настраивали Заказчиков минимум на три итерации. Первая — минимально работающее ИТ-решение решающее бизнес-задачу. Вторая — удобно и красиво. Третья — чтобы быстро работало.
- Заказчик подписывал первую часть ТЗ и проверял в соответствии с ней, всё что не вошло в ТЗ, это дополнительное требование. Дополнительные требования оплачиваются за счёт Заказчика. При этом главный критерий приемки — то, что созданный ИТ-продукт решает бизнес-задачу ради которой задумывался. Система выдаёт целевой бизнес-результат, указанный в ТЗ.
Знаю, что некоторые ребята не просто картинки рисуют, а создают буквально работающее решение, которое можно «покликать». Делают с помощью Axure. Почитать и посмотреть можно здесь.
vadimr
13.10.2016 15:26Если у вас объём выполняемой работы находится в значительном дисбалансе с выделяемыми на неё средствами, то это говорит о неправильно построенном организационном и финансовом взаимодействии заказчика и исполнителя. И никакими формальными шагами технарей по уточнению ТЗ это исправить не удастся.
vadimr
13.10.2016 15:01+1ТЗ выдаёт заказчик, детали работы исполнителя его не должны интересовать. В описанном случае исполнитель нагрузил заказчика несвойственной ему работой по согласованию требований к действиям разработчиков. По ГОСТу, если так уж хочется согласовать конкретный способ реализации, то разрабатывается и защищается технический проект.
На месте заказчика, я бы послал исполнителя с таким подробным ТЗ.throttle
13.10.2016 15:26Цитата из 34.602:
2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС,
Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).
6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.
7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.
Это рекомендованное дополнение, и тем не менее.
Руководитель предприятия заказчика и не должен изучать ТЗ — ему достаточно листа согласования. Все дело уже в том, как он составлен.vadimr
13.10.2016 15:32+1Я говорю о том, что ТЗ не должно (или почти не должно) содержать требований по способу реализации функций системы. Это внутренний вопрос исполнителя, часть его работы. Заказчика не должно волновать, каким именно образом исполнитель сделает ему красиво.
throttle
13.10.2016 15:46Это да, там это практически прямо написано:
Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.
Т.е. нельзя писать «язык программирования — Java», например. Это можно писать уже в проектной документации.
Другими словами, заказчик не может требовать сортировку пузырьком, но он может требовать определенной скорости сортировки на неком типовом наборе данных, например. Или ограничить занимаемый при этом объем памяти. Но не конкретный алгоритм и не конкретный язык.
MosDev
13.10.2016 17:13Мы работаем по методологии Agile, но с использованием стиля Waterfall, а именно отталкиваемся от небольших спринтов, которые основаны на требованиях заказчика, далее делаем макет приложения и потом пишем ТЗ на приложение/АС, документ подписывает заказчик и он передаётся всем участникам разработки, в итоге за короткий период мы получаем работающий скелет ПО, на который навешиваем игрушки выпуская новые версии моб. приложения :-) Главная ценность такого подхода — экономия бюджета заказчика, нашего времени для написания ТЗ и разработку ПО!
zenkz
13.10.2016 22:05Вот поэтому и все движутся в направлении DevOps. Документация — это тоже продукт и она должна разрабатываться по аналогии с исходными кодами. Т.е. должа быть система контроля версий (не важно SharePoint или что-то более удобное), все изменения должны быть легко отслеживаемыми (в Word-е есть отслеживание изменений и комментарии для этих целей).
На мой взгляд лучше иметь один актуальный документ, чем кучу приложений. Приложения могут показываться заказчику и подписываться им, но в этих приложениях — просто список изменений по отношению к предыдущей версии ТЗ.
DROS
01.02.2017 17:44+2Я конечно в танке катаюсь, но неужели они сделали нормальные выключатели? А не эти сенсорные не пойми что? Я уж и не надеялся. Благодарю за наводку.
Locolind
14.10.2016 00:04Никогда вообще не встречал тех проблем, что вы описали, хотя постоянно о них слышу… исключительно от тех, кто работает с заказчиками из рф.
Возможно это особенность нашей страны, когда крупная компания покупает платформу от западного вендора и ваяет на её основе систему под собственные нужды, изменив её так, что ты уже не можешь обновится до следующей выпущенной версии от вендора.
В нашем случае это была Pivotal CRM и покупалась в том момент, когда система входила в лидеры квадранта Gartner. Нас оправдывает только то, что лучших практик тогда не было.
Система создавалась для развития ипотечного рынка.
Ребята ездили в Америку изучать ИТ-системы и опыт Freddie Mac и Fannie Mae.
После этого было принято решение делать своё.
Система ежегодно переваривает ипотечных закладных на 60 млрд. рублей.
Выглядит с одной стороны много, но уже с масштабами Сбербанка не сравнить.
Его ИС переваривают ипотечных закладных на 661 млрд. рублей.yarric
15.10.2016 10:03И какой объём занимало ТЗ на ИТ-системы Freddie Mac и Fannie Mae?
Locolind
15.10.2016 13:05Не смогу ответить на ваш вопрос. Был не с самого начала появления нашей системы.
Пришел работать в компанию уже после того, как ребята съездили в командировку, 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 шкафа.
AmdY
Вы же в курсе, что ракеты, как практически и любой сложный современный продук так и создаются — детали делаются в разных местах, а затем собираются в единый продукт. В поисках идеального тз, вы не получите не продукта, ни тз. А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще. А для простого продукта тз можно писать прямо на ходу, а то и постфактум.
Locolind
Мы так и поступили, вместо того, чтобы пытаться остаться в одном, Первом ТЗ, мы создали 300.
Не за один день, но подход был выбран именно такой.
Не факт, что их нужно было 300, но это материал для «рефакторинга» ТЗ.
Если 40 ТЗ описывают одну функциональную область и каждое из них про свою процедуру, есть повод задуматься про структурирование информации.
Сейчас это проблема решена на уровне меток / тегов с названиями бизнес-процессов и бизнес-процедур, указываемых к каждому ТЗ.
Вторая статья в списке для чтения на Хабре по теме как раз про это.
Полное отсутствие ТЗ порождает Diff(-erence) между тем что сделано и ожиданиями Заказчика.
ТЗ эту разницу позволяет сократить. Что включать в ТЗ это уже предмет изучения шишек на лбу команды.
Если Заказчик не зрелый в области проектирования своих собственных бизнес-процессов, то с ним точно надо описывать Бизнес-процесс с применением ИС. Это точно лучше, чем множество итераций/спринтов, и через них приходить с ним к тому процессу который будет ему удобен и более эффективен в сравнении с тем, что у него был до этого. Будет и быстрее по времени и ресурсов «сожжено» меньше.
Мой опыт говорит о том, что когда Заказчик не знает чего хочет, быстрой итерационной разработкой это не лечится.
Дальше бизнес-процесса и сценариев использования системы можно не углубляться, если у вас чистое поле или «свежий» функционал.
Но если у вас одно цепляет за другое, то это опять повод писать ТЗ и уже начинать продумывать техническое решение, что мы сможем реализовать в рамках того что сами уже сделали, а что нет и нужно предлагать Заказчику альтернативные варианты решения его бизнес-задачи.
Момент определяется достаточно просто, когда используя старую парадигму написания легкого ТЗ или без него, вы начинаете делать что-то, выпускаете обновление и что-то в другом месте отваливается.
Чем чаще и в больших местах отваливается, тем больше это становится актуальным.