Comments 30
Такая система называется RMS (Requirements Management System) и ее реализаций великое множество: DOORS Next, Jama, Polarion ALM, Helix и тд.
Наиболее близкой системой к тому что вы описали является Doorstop.
Спасибо, про RMS и Doorstop не знал, посмотрю. Формально это тот же класс, и Doorstop ближе всего по духу, потому что требования в нем живут рядом с работой, а не в отдельном хранилище.
Но RMS, включая Doorstop, управляют требованиями, которые уже сформулированы и помещены в систему. Моя идея в другом. Я предлагаю не создавать еще одно дублирующее хранилище документации, а собирать ТЗ из того, что и так происходит в задачах, переписке и согласованиях. Не нужно писать требование в RMS, оно уже есть в процессе, нужно только связать и показать.
Doorstop хранит требования в репозитории, а значит предполагает, что аналитик работает с гитом. Аналитики, в отличие от разработчиков, с гитом, как правило, не работают, и это не их зона ответственности. Иначе им пришлось бы освоить ветки, конфликты, merge, pull request, а это серьезные навыки, которые от аналитиков не требуются. Кроме того, в документации много нетекстовой информации (таблицы, диаграммы). Аналитик – не разработчик, и это нормально. Поэтому идея “документация как код (в git)” и не получила широкого распространения.
Моя идея несколько отличается от RMS. Плоская модель вместо дерева, а также извлечение из каналов вместо ручного ввода. Но главное даже не это. Не нужно дублировать задачи Jira в Confluence или Word. Требование живет в задаче, со связями, историей и согласованием. ТЗ становится выборкой таких задач, а не отдельным документом, который надо писать и поддерживать.
Я вам перечислил аналоги только чтобы вы могли посмотреть и позаимствовать подходящие идеи чтобы улучшить ваше решение.
Освоить гит - дело пары недель.
Не стоит так строго разделять "зоны ответственности" (это, кстати, не совсем они. Это скилл в чистом виде) - чем ближе аналитик к разработке тем лучше для всех в конечном итоге. Так думаю.
Наши аналитики вполне справляются, кстати, и новые проекты ведут в гите.
как уже ранее писал - с т.з. создания именно модели требований - попробуйте Archimate / Archi.
В т.ч. вот неплохой в принципе пример использования в статье с Хабра:
https://habr.com/ru/companies/axenix/articles/1038916/
А почему вы пишете, что в Jira нет версионности задач ?
Да, и важный момент, который является плюсом классического ТЗ - его можно закрепить при обсуждении с заказчиком - его можно версионировать как описание системы на конкретный момент времени.
А вообще в свое время поиск подходящей RMS меня привел к Archimate / Archi - как к более комплексному подходу с возможностью поддержания сложной системы связей между разными уровнями требований и в связи между техническими и функциональными требованиями, целями/задачами бизнеса, инфраструктурными ограничениями и возможностями и др ;-)
Версионироваь можно не только "классическое ТЗ", но и каждую задачу или их набор.
Это понятно.
Только в том-то и смысл ТЗ, что версионируется набор - в рамках которого есть тоже итерации по каждому требованию.
Просто реализовывать можно в конкретный момент времени только конкретную версию ТЗ.
Иначе это не ТЗ, а реально просто гибкая разработка с беклогом...
И ТЗ тогда сжимается до ЧТЗ под каждую конкретную задачу.
А разработка в целом происходит эволюционным путем - методом проб и ошибок и др - без попыток охватить картину в целом.
В общем ведение пунктов ТЗ в виде задач - идея не новая, но достаточно костыльная - особенно в случаях, когда есть нефункциональные требования и, фактически, во всех задачах они будут превращаться в чек-лист того, что нужно проверить / учесть разработчику при реализации конкретной фичи.
Ну и ТЗ - это в т.ч. первичное описание целевой архитектуры - хотя бы требований к ней...
ЗЫ: и если уж совсем быть строгими - после ТЗ идет техпроект, техпаспорт и т.п.
Но это для систем, которые внедряются в критичный прод - например, связанный с производством, ТЭК и т.п., где цена ошибки/просчета слишком высока, чтобы работать без предварительного ТЗ и понимания критериев приемки работы.
Хорошо вам живется - вам требования поступают от заказчика так, что их можно извлечь из каких-то документов... завидую. Подозреваю, что делаете вы стотысяченадцатую вариацию а-ля кастомизация 1С. Тоже нужная вещь, не спорю. Но подозреваю, что жить таким проектам осталось не слишком долго. Если ИИ может правильно изалечь требования, то и сделать сам проект он, вероятно, тоже сможет без помощи кожаной прокладки... могу, впрочем, ошибаться в сроках - возможно, остались не месяцы, а еще годы.
Но как быть с теми проектами, в которых заказчик сам толком не понимает, что именно ему нужно? Вы можете ьесклнечно созваниваться и переписываться или встречаться лично, но в итоге формулируете ТЗ - вы сами, и придумываете его - по сути тоже сами, вытаскивая из заказчика не тоебования, а "хотелки". Их реализация - быть может, и возможна, за триллиард или чуть меньше, но заказчик этим доволен не будет. Ваша работа - понять, чего заказчику реально не хватает такого, что ваша команда способна для него сделать. Думабю, подобные заказы еще кпкое-то время поживут, прежде чем ИИ научится их делать. Возможно, это время и немаленькое, типа лет ста... могу, опять же, ошибаться в сроках.
С такими заказами как быть?
э... я нигде не писал, что требования поступают от заказчика в готовом виде..
Обычно заказчик приходит с проблемой, а не с требованиями - и даже не с пониманием, что ему нужно - новая система, или и.б. просто нужно людей обучить работать с текущими инструментами, или вообще просто это проблема процесса, а не ИТ.
Но закреплять требования по итогам обследования и работы аналитиков нужно с заказчиком - потому что иначе в какой-то момент возникнет вопрос, что работа должна быть оплачена, результаты приняты, бюджеты потрачены... и у заказчика должно быть понимание - на что и с каким выхлопом
Меня еще в институте учили, что ТЗ ВСЕГДА пишет исполнитель :)
Но заказчик формулирует заказ
Вы пока слишком оптимистичны в отношении ИИ.
Да, сейчас можно, теоретически, написать даже достаточно сложную систему, особенно используя SDD-подход.
Но, надо понимать, что это просто очередной шаг эволюции.
Когда-то программы писали на машинном языке или Асме - и представители бизнеса/ученые/инженеры отдавали свои алгоритмы/модели на бумаге бородатым дядькам или тетям, которые их забивали в перфокарты и запускали в мейнфреймы, а потом делали длинные распечатки с результатами.
Потом появились специалисты на стыке бизнеса/науки/аналитики и программирования - потому что в итоге появились языки верхнего уровня. Но все равно приходилось осваивать уже работу с этими инструментами.
А сейчас ИИ пишет код. При этом, все прекрасно понимаю, что как на языке верхнего уровня уже не написать так элегантно, как на асме, так и на ИИ вы получите код не просто не оптимальный - а заполненный определенным процентом нейрослопа.
Но, в любом случае, как только система становится проще обычной утилитки - встает необходимость управления ТЗ и применения SDD.
Ну и эффект "самоопыления" никто не отменял - ИИ вам не предложит нового решения - он просто "выровняет" вас с рынком.
Условно - ну, вот подскажет, что есть класс систем RMS, расскажет про мировой опыт и сделает проект "на уровне" который уже достигнут - но ничего нового он не предложит - потому что этого нигде еще нет.
Человеческое творчество - это не подбрасывание игральных костей - это сложный процесс, в котором есть даже детерменизм - только просчитать его также бесполезно пока что, как смоделировать поведение атомов в кусочке сахара, растворяемом в чае
Спасибо, что откликнулись.
Про творчество - в смысле, недоступное ИИ, который просто подровняет и всё, - имхо, один из мифов, которому жить осталось совсем недолго. ИИ уже способен находить новые решения, кои мы с вами далеко не всегда видим в силу нашей, человеческой, инерции мышления. К примеру, полноценное научное открытие - которое в т.ч. противоречит общепринятым концепциям и трактовкам и дает новое понимание физики явлений - отнюдь не дело следующего века. Причем для этого даже не нужна супер-интеллектуальная модель. Не лумаю, что разработка бизнес-софта концептуально сложнее.
Качество нейрокода - тоже вещь не то чтобы постоянная. Сравните сегодня и год назад... просто сравните. Шахматисты десяток лет назад тоже считали столетия, пока компьютер научится их обыгрывать, а фотографы - пока цифровая матрица сравняется с пленочной по пикселям. Качественный скачок, хотим мы того или нет, уже произошел.
Еще один распространенный миф - про ограничения платформ. Типа, на экселе невозможно написать нормальную программу, там лаже классов нормальных нет (кстати, про "ненормальные", которые там таки есть, многие суперспецы и не слыхали, как и про много чего еще). Дело часто бывает не в платформе, а в зарплате, которую шотовы платить разработчику.
Я про другое хотел сказать - про то, что уже сейчас неплохо бы подумать о том, какие проблемы нам придется решать лет через несколько, когда ИИ "скушает" очередной пласт человеческих работ, на этот раз в области программирования, - и как улучшить то, что еще после этого останется нашим белковым собратьям.
Кино не уничтожило театр и книги, а смартфон не уничтожил зеркалки - но театральному артисту и профессиональному фотографу сегодня надо делать не то же самое, что полста лет назад.
Какие именно задачи придется решать завтра тем, кто сегодня делает бизнес-софт? Где главное "узкое место" в таких задачах? Как его "расшить"? Сегодня это может казаться чем-то не слишком важным, а завтра - может оказаться единственным, что спасет профессию от вымирания...
С технологиями уходит рутина и остается творчество.
Это показывают и примеры новостей с так называемыми "открытиями ИИ". По факту там речь идет о том, что ИИ перебирал все возможные варианты, что ест-но человек сделать не может с такой же скоростью (пример - Мендеелеев перепробовал кучу вариантов в течении длительного времени, пока ему не "приснилась" итоговая таблица элементов).
Узким местом становится уже человек, который должен успевать обрабатывать те результаты, которые выдает ему ИИ и принимать решение - классический пример - кодревью кода ИИ. Иначе у нас все превратится в ваб-ливинг - когда все делает ИИ - и работает, и принимает работы... и живет :).
и тогда "скрипач не нужен".
И возникает вопрос - а нужен ли тогда ИИ?
Тут еще вторая западня - прогресс ИИ будет влечь за собой регресс людей. И в итоге остается опасность самоопыления ИИ с постепенной деградацией - уже и ИИ и людей... как говорится "будешь как Великий Нехочуха".
Но, думаю появятся люди, которые уйдут в Зеон и будут делать все "руками", думать сами, читать книги и др.
Как не убил ширпотреб штучного производства в XIX веке. Да, луддиты побастовали - но мир не остановился. Просто оставшиеся мастера стали цениться выше и доступны узкому кругу.
Только если бы все было так просто - при чтении аналитических отчетов от ИИ не возникало бы каждый раз ощущение общения со смоляным чучелком.
Ключевое, что отличает человека - это не только явные знания, но и опыт, воспоминания, ощущения - все, что связано с физическим миром.
Не даром "мысль изреченная - есть ложь" - внутренний мир (неявные знания) человека намного богаче и сложнее, чем он может это описать.
И пока все неявные знания не будут переведены в явные - ИИ будет уступать.
Это как с "отвернувшимися" у Лю Цисиня в "Темном лесе".
ИИ сможет приблизиться к человеку, когда он получить возможность полноценной физической жизни, с полным спектром переживаний...
Вопрос только - нужен ли нам такой гомункул ?
А с т.з. экспериментов - да, если дать ИИ самому проводить физические эксперименты - он сможет методом подбора найти новые составы веществ, технологии производства и др... правда есть при этом вероятность, что он "сожрет" кучу материи на неудачные опыты... как сейчас сжигает кучу энергии на неудачные генерации и нейрослопы.
И, к слову, пока что даже в программировании, ИИ не может полностью самостоятельно дать себе обратную связь и сыграть за всю команду разработки, сам провести нужные эксперименты и др - все равно пока требуется наличие того, кто первично отстраивает систему.
Я бы воспринимал ИИ как очень активного студента, который прочитал кучу книг и впитал в себя все теоретические знания.
Чем он отличается от студента - студент такой объем забудет сразу после сессии - потому что нет подкрепления. А ИИ запомнит все - и полезное, и бесполезное - но без эмоционально, механистически.
А человек запоминает только через практику, через применение знаний в своих действиях - причем. желательно. в ближайшие несколько суток.
ЗЫ: вот про 1С обидно было... :-)
пусть в меня кинут камень, но уровень большинства программистов 1С мне с трудом позволяет назвать их ИТ-специалистами/программистами/проектировщиками...
Очень редко на рынке 1С-разработчиков встречаются грамотные команды - и причиной тому сама платформа, которая загоняет в некие рамки и сажает в свою песочницу.
Примерно как программирование на учебных языках типа "Кумир".
Поэтому сравнивать мою работу с примерами на 1С я бы не стал :-)
А вообще то, что вы описываете под ТЗ в Jira - это по сути бэклог.
Просто по правилам большинства гибких методологий:
1) задача не берется в текущую работу, пока ее не уточнили (это как раз этап формализации требований аналитиками)
2) допустима иерархия задач (те же "эпики" в скраме)
да, еще немного "не раскрыта тема сисек" с т.з. того, что вы понимаете под требованиями.
На вскидку есть как минимум такие варианты:
1) что должно быть
2) как должно быть учтено
И вот требования вида "что" хорошо укладываются в задач...
А вот требования "как" - должны соблюдаться при выполнении всего проекта и с т.з. использования трекера - это будут постоянно активные задачи, которые будут просто висеть в общей помойке задач и никак не "жить", не влиять на другие задачи и др.
Пример задачи "как" - "интерфейс должен соответствовать требованиям стайл-гайда...", "все модули должны работать на Java не ниже версии..." и т.п. - причем это могут быть и функциональные и нефункциональные требования
Можете разделить Что делать (продукт заказчика), Как делать (технология исполнителя), и заменить Порядок (таск трекер) на Ожидание (релизы)
Это очень удобно, когда ТЗ не документ, а компиляция из живых ссылок!!!
Заходите в п. 1 и читаете: "кнопка должна быть синяя по центру".
Сделали и идёте сдавать. А вам говорят: "Ты — плохой ушлеёпок! Что написано в ТЗ?"
Открываете все вместе, а там: "Кнопка должна быть красной слева".
Просто, пока вы писали синюю кнопку требования уже раза три переделали. ТЗ же
должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.
Очень удобно иметь динамичное ТЗ. Так можно получить квалификационное звание RTD (Real Time Developer, Программист реального масштаба времени).
Это особое искусство!
Такой не станет переделывать кнопку на красную. Он знает систему глубже!..
Он ждет. И... когда в требовании п. 1 снова появляется СИНЯЯ кнопка, он бежит сдавать работу. То, что она должна быть справа — не беда.По пути в лифте поправит.
Заехала на др. элементы интерфейса?
Это ушлёпки из др. команд не прочитали прекрасное динамичное ТЗ из ссылок!
Справа по п. 1 должна быть именно эта синяя кнопка.
В др. пунктах тоже все должно быть справа?
Это потому, что каждое требование пишут разные люди в своем собственном отделе. А в ТЗ они собираются по ссылкам. Нам не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость.
Я сдаю работу по п. 1 только! Вот, её и принимайте!!!
А разве монолитное ТЗ избавлено от внезапных правок? Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем. А форма ТЗ не имеет к этому отношения. В статье нет ничего про то, что "не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость". Это Вы от себя добавили.
Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем.
Хм-м-м... Сергей, а как же тогда автособирающееся ТЗ из требований, которые куча разных людей пишут себе по своим делам, не держа в голове, что это одновременно будет и пункт ТЗ?
Эта фраза в вашем ответе, на мой скромный взгляд, прямо противоречит тому, что вы написали в вашем длинном запросе о помощи, изначально:
… нужна… система, в которой ТЗ собирается из требований, а не пишется как структурированный документ.
Документы разных типов в ней должны связываться между собой, иметь ссылку на источник, историю обсуждения и согласования.
ТЗ должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.
… аналитик перестанет делать работу технического писателя, потому что ему не нужно будет переносить требования из переписки в ТЗ, ведь система забирает их из каналов и связывает.
Или я неправильно понял?!
Должна искомая гипотетическая система сама генерировать ТЗ или не должна, и у ТЗ тогда будет конкретный автор (коллектив авторов с ответственным руководителем), который его создает на основе каких-то других документов и отвечает за его содержимое?
Эта статья не является полным и окончательным описанием нужной системы формирования ТЗ. Чтобы такая система хорошо работала, многое нужно додумать. Написание ТЗ - это всегда итерационный процесс, и это не меняется от того, что у нас теперь набор связанных документов, а не единое монолитное ТЗ. Да, можно привлечь ИИ к формированию нужного набора связанных документов, но потом придется посмотреть на результат и внести правки. Про "автособирание" ТЗ в статье не говорится. Один человек, исходя из своих обстоятельств соберет так, другой - иначе.
Но вся прелесть этого подхода в том, что сборное ТЗ легко актуализируется и поэтому отражает актуальное состояние системы. А внесение правок в монолитное 200-страничное ТЗ требует огромных редакторских усилий, и поэтому откладывается на потом (навсегда). Нужно сделать какую-то задачу проекта - написали одностраничный документ - связали ссылками с другими. Всё. Нужно внести правки в определенный документ - внесли правки только в этот документ, не думая об оглавлении, нумерации страниц и рисунков и т.п. Всегда понятно, когда именно внесена правка в одностраничный документ, чего не скажешь о 200-страничном ТЗ, где по 10 правок в день в разных местах. Если нужно получить общее представление о проектируемой системе, прошли по ссылкам, сделали обзор, оглавление, индекс. Если нужно поручить разработку исполнителю, сформировали перечень связанных документов, отослали исполнителю.
А как же единство и целостность разрабатываемой системы? А для этого есть архитектурные документы (разнообразные диаграммы и т.п.), и не нужно смешивать это с техническим заданием.
Про “автособирание” ТЗ в статье не говорится. Один человек, исходя из своих обстоятельств соберет так, другой - иначе.
Тогда, что должна делать предполагаемая ИС — не понятно, если всё равно человек формирует ТЗ.
Но, у человека же и так есть ссылки на все источники, по которым он формирует его. Пусть открывает эти источники да собирает своё ТЗ.
Есть куча сервисов, вкл. бесплатные, позволяющих строить диаграммы связей одной сущности с другими. Есть более формальные и строгие, вкл. стандартизированные языки описания связей, есть более красивые, но неформальные.
Пусть авторы ТЗ ведут такие диаграммы себе со ссылками на живые документы и создают свои ТЗ, наблюдая связи визуально.
Личный опыт: В конце 90-х годов мы делали большие корпоративные документы (отчёты, ТЗ, документацию…) на Microsoft Word 6.0 (под Windows NT) и более поздних версиях Word. В этом текстовом процессоре (MS Word) есть такая функция — Master Document. Документы, представляющие отдельные части большого, лежали у нас на серерах конкретных отделов и рабочих групп. Каждую главу или раздел редактировал, вёл и отвечал конкретный человек, управлявший своими авторами. Версию файла обновлял только он один. (Иерархическая система была: редактор главы также собирал содержание по своим авторам.) Мастер-документ вордовский содержал только титульную страницу, объекты типа [Содержание] и пр. технические вещи и… объекты-вставки др. офисных файлов. Т. е. мастер-документ не содержал текст глав, графики, рисунки, иллюстрации и пр., а только сетевую ссылку к др. файлу. Когда его открываешь на любой рабочей станции в корп. сети, то можно было читать или печатать огромный 600+ страничный документ. Он собирался автоматически из отдельных файлов документов разных групп авторов.
Вот, так когда-то делали мы. ;-)
Самый неудобный формат ТЗ с которым я работал, это как раз RMS. Куча утверждений "Система ДОЛЖНА...", из которых каждый человек по разному синтезирует что же именно надо сделать. Не считая описания требований в задачах, что на мой взгляд вообще неприемлемо.
Наиболее удобно для меня иметь описание системы ДО, описание система ПОСЛЕ и дельту между ними.
Описание системы ДО в моей картине мира это обязательный артефакт. Руками надо либо внести правки и превратить ДО в ПОСЛЕ (и силами ИИ описать дельту), либо описать дельту и силами ИИ получить ПОСЛЕ.
Плюс минус это можно делать в Конфлюенсе или другой вики через версии страниц (понятно что не идеально), можно в гите.
Видимо, Вы работали без системного аналитика, который должен отвечать за целостность и непротиворечивость ТЗ. Безусловно, версионность ТЗ - это обязательное требованние. Ну и согласование изменений, а также уведомления об изменениях.
ну, в случае новой системы не будет "ДО" - и ТЗ в итоге будет содержать полный набор требований вида "должен/должна" и т.п.
Это редкий вырожденный случай
Система создаётся один раз, и дорабатывается потом 10 лет.
В любой итеративной модели прямо "с нуля" только первая итерация. Потом уже появляется ДО.
Это кстати одна из проблем теории - хорошее ТЗ на новую систему и хорошее ТЗ на доработку системы несколько разные. Про это почему то редко пишут, и постоянно ориентируются на новую систему.
Нужна система, в которой ТЗ собирается из требований, а не пишется как структурированный документ