Знакомьтесь: успешная компания, которая решила двигаться в ногу со временем и автоматизировать свои процессы с помощью low-code платформы. После тендера и заключения договора с исполнителем, она нашла опытного интегратора и ушла создавать идеальное ТЗ. После года напряжённой работы, когда множество деталей было учтено и всё казалось готовым к запуску, вступила в игру реальность: приоритеты компании изменились, бюджет был пересмотрен, а идеальное ТЗ уже не отвечало актуальным потребностям. И таких примеров — множество. Как оказалось техническое задание сегодня способно пустить на дно даже небольшой проект, не говоря уже про амбициозные решения. Давайте вместе с ведущим аналитиком Comindware Игорем Простоквашиным разберём этот кейс в деталях и поймем, как избежать подобных ловушек при планировании IT-проектов.
Рояль в кустах
Мы в Comindware, как исполнители, работаем с заказчиками, которые обычно инициируют проекты через получение оценок на их реализацию. Обычно, прежде чем начать работу клиенты создают техническое задание (ТЗ) и только после этого начинается работа над проектом. Но тот документ, который мы получаем на старте проекта, я бы не назвал техническим заданием в его каноническом виде. Это скорее функциональные требования. На основе этих требований заказчик формирует свои требования к функционалу, а исполнители предоставляют сроки и стоимость. Однако, очень часто эти функциональные требования описывают лишь общие возможности системы, например, удобство, задачи, уведомления, печатные формы, интеграции и так далее. Отсутствует детализация, ответы на вопросы о том, как именно система должна функционировать или интегрироваться. За этой поверхностностью часто скрываются сложности, которые можно сравнить с "роялем в кустах" или неожиданными препятствиями.
Заказчик, из-за неопределенности с интеграторами, партнерами и платформами, не может составить конкретное техническое задание. Например, он не может детально описать, как пользователь с определенной ролью взаимодействует с системой. Без видения будущей системы, заказчики часто не могут детализировать свои требования. К тому моменту, когда они выбирают исполнителей через тендеры или конкурсы, требования могут измениться или что-то уже может быть упущено.
На основе функциональных требований от заказчика мы делаем оценки сроков и стоимости, после чего начинаем работу над проектом. Однако, заказчики часто хотят уже на старте увидеть детальное описание того, что мы, бизнес-аналитики, будем делать, вплоть до конкретных полей и интеграционных схем. Такая детализация требует времени, сопоставимого с реализацией самого решения.
Приведу два примера. Первый касается крупного производителя тяговых составов. Они нуждались в CRM-системе для управления продажами. Платформа Comindware была выбрана для реализации проекта. На старте заказчик решил работать с внешним интегратором для составления технического задания. Этот процесс занял почти год, после чего работы на проекте начались.
Второй кейс — заказчик предоставил нам верхнеуровневые функциональные требования и стал разрабатывать ТЗ. Еще весной прошлого года мы рассчитывали что к достаточно быстро закончим проект и передадим его результаты. Но техническое задание от заказчика пришло лишь через год. Процесс затянулся, у заказчика изменились условия, в результате чего проект был приостановлен. Несмотря на то, что мы были готовы к работе, реализация так и не началась из-за долгой подготовки документации.
Работать без ТЗ?
Многие могут возразить: "Как можно начать работу, не имея четкого понимания требований?" Но вот тут и кроется наша инновация. Вместо того чтобы следовать традиционной модели разработки, мы предлагаем экспериментальный подход. С помощью современных инструментов, таких как наши, можно сразу приступать к проектированию. Да, мы можем столкнуться с ошибками, но благодаря гибкости Comindware Business Application Platform, их можно быстро исправить.
Представьте, что перед вами стоит задача построить мост через железную дорогу. Традиционный подход предполагает долгие исследования и планирование. Но что, если у нас есть новый материал, который позволяет быстро создавать и корректировать конструкции? Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать. Зато все будет предельно практично, наглядно и соответствовать ожиданиям и реальным возможностям.
Тем не менее, для многих заказчиков, особенно в государственном секторе, техническое задание остается критически важным документом — с точки зрения внутренней отчетности или по другим бюрократическим причинам — “у нас так принято”. И здесь мы иногда идем на хитрость. Вместо того чтобы писать ТЗ на начальном этапе, мы предлагаем разработать его ближе к завершению проекта. Таким образом, оно будет отражать реальное решение, которое было создано.
Конечно, в начале проекта отсутствие четкого технического задания может вызвать ряд вопросов. Например, что именно будет утверждать руководство со своей стороны. И тут, повторюсь, что заказчики часто предоставляют лишь функциональные требования. Например, они могут указать на необходимость создания системы управления продажами, которая будет обладать определенными функциями, такими как ввод карточки контрагента или интеграция с телефонией. Однако дьявол кроется в деталях. Что именно подразумевается под "карточкой контрагента"? Сколько полей она будет содержать? Какова ее структура?
Такая неопределенность может привести к недопониманию и дополнительным затратам в будущем. Например, упоминание "калькулятора коммерческого предложения" может оказаться гораздо более сложной задачей, чем предполагалось изначально.
Главное в процессе разработки — гибкость
Бизнес-аналитики должны быть готовы быстро адаптироваться и корректировать свои действия на основе полученной информации. Если определенная функция оказывается слишком сложной или затратной, возможно, стоит пересмотреть приоритеты.
И в этом случае техническое задание становится живым документом, который формируется на протяжении всего проекта, уточняясь и дополняясь. Такой подход помогает определить, что именно будет включено в конечную систему, и служит основой для дальнейшей работы. И, да, часто четкое ТЗ формируется на более поздних этапах разработки, когда становится предельно понятно, что именно должна представлять собой законченная система.
И тут многие могут сказать, мол отсутствие долгой и четкой проработки проекта на старте играет на руку тем, кто продает платформу. Но в нашем случае продажа уже произошла. Предлагая подход, при котором техническое задание уходит на второй план, я не стремлюсь ускорить продажу. В любом случае, клиент приходит с небольшим документом, ожидая оценки стоимости. И часто все это напоминает ситуацию, когда человек обращается к строителю с вопросом о стоимости дома, не уточняя сколько у него будет этажей. Мол, вы просто скажите сколько будет стоить построить дом, а число этажей и другие детали я вам скажу уже во время строительства. Часто очень похожие запросы мы видим в сфере ИТ и автоматизации процессов в бизнесе. Клиенты часто предоставляют лишь поверхностные требования, не углубляясь в детали. Например, они могут запросить "калькулятор", не уточняя его сложность и функционал.
Да, наша задача — выяснить, что именно они имеют в виду, и оценить объем работы.
Мы работаем с этими требованиями, уточняя их и пытаясь понять глубину задачи. Если клиент хочет сложный калькулятор, это может занять гораздо больше времени и ресурсов. Наша цель — помочь управлять этой функциональностью, показать клиенту как можно определять приоритеты и планировать возможные изменения. Техническое задание, в классическом понимании, формируется ближе к концу проекта. Оно становится результатом нашего детального анализа и обсуждения с заказчиком. Этот документ описывает функционал системы, а также служит основой для тестирования и инструкций для пользователей.
«Представьте, что вы купили «Феррари», а водите ее так, будто у вас «Фиат»
Современные подходы к разработке, такие как Low-code, позволяют нам быстро приступить к настройке системы, не тратя время на подготовку обширной документации. Но это не означает, что мы игнорируем важность планирования и анализа. Наша цель — эффективно сочетать быстродействие и качество. Вспомните футболиста Златана Ибрагимовича, который был приобретен Барселоной, но «использовался» не по назначению. Говоря о стратегии своего тренера Хосепа Гвардьолы он сказал: «Представьте, что вы купили «Феррари», а водите ее так, будто у вас «Фиат». Это похоже на ситуацию, когда вам предоставляют современный инструмент в виде low-code платформы, но вы используете устаревший подход Waterfall. Вы тратите много времени на написание технического задания, а потом осознаете, что возникают различные несоответствия.
Разве не легче начать кодирование и уже увидеть результат работы сайта или системы, чем тратить два месяца на описание, где требуется фантазия? Ведь в таком случае вы ничего конкретного не видите. Простой пример — заказчик предлагает, создать кнопку зеленого цвета. Но как она будет выглядеть на практике? Возможно, было бы проще сразу что-то визуализировать. Однако, когда вы начинаете это делать, вам говорят подождать, составить техническое задание. В итоге, когда дело доходит до реализации и вы добавите фон, поля и др элементы формы, то увидите, что все это перекрывает кнопку. Без визуализации это было сложно понять.
Low-code — это Феррари, это действительно гибкий инструмент. Он позволяет быстро получать визуализацию решений и разрабатывать проект в условиях, когда результат можно получить быстрее ТЗ, и даже если этот результат заказчика не устроит — быстро внести нужные исправления.
И тут возникает резонный вопрос о том, насколько часто техническое задание соответствует реальной разработке? Можно сказать, что в большинстве случаев (около 95%) это так. Однако иногда заказчики могут предоставить нечеткие требования, которые сложно интерпретировать. Например, требование о реализации календарного представления может оказаться желанием создать что-то похожее на Outlook, что является огромной задачей. Иногда заказчики не понимают последствий своих требований, и это может привести к дополнительным сложностям в разработке.
Например, сейчас мы работаем с крупной промышленной компанией России. Она очень тщательно подошла к описанию требований и детализировала их включая описание экранных форм и полей. Мы начали реализацию, исходя из предоставленных данных. Однако в дальнейшем обсуждении задачи с заказчиком выяснилось, что требования стали более сложными. Например, изначальная форма из трех полей превратилась в форму с 30 полями, так как клиент хотел включить больше опций выбора материала. Этот пример показывает, насколько важно глубоко понимать потребности клиента и быть готовым к изменениям в ходе проекта.
«Без ТЗ нужно уметь управлять функциональностью»
Мы сталкиваемся с ситуацией, когда заказчик не готов вкладывать ресурсы в разработку ТЗ до заключения контракта. Клиенты часто хотят понимать сроки и стоимость заранее. Оптимальный вариант – когда заказчик предоставляет функциональные требования, на основе которых производится оценка проекта. Но даже при этом может возникнуть проблема "раздувания" проекта и превышения бюджета. Для контроля бюджета без конкретного ТЗ нужно уметь управлять функциональностью: детализировать и оценивать её.
Пример: можно начать с грубой оценки — калькулятор стоит, условно, 500 тысяч, интеграция — условный миллион, и так далее. Но когда начинаются уточнения, стоимость может меняться. Если заказчик решает усовершенствовать калькулятор, его стоимость может возрасти в 3 раза. Тогда приходится искать компромиссы в других частях проекта.
Этот подход может казаться неидеальным. Ведь, представьте, что вы решаете купить автомобиль, нацелившись на определенные функциональные характеристики, но в итоге получаете не то, что ожидали. Это как выбирать автомобиль, ориентируясь на функции и комплектацию через онлайн-конфигураторы, а в итоге получать что-то другое. Но вы понимаете, что при одном бюджете и заданных сроках нужно управлять функциональностью автомобиля. Это похоже на выбор определенных характеристик или наличие или отсутствия адаптивного круиз-контроля. Вы замечаете, что какие-то функции, например, регулировка сиденья или механизм открывания крыши, могут быть иными, чем вы думали. Тест-драйв может помочь разобраться, но ведь невозможно опробовать все модели.
Основные параметры проекта включают в себя сроки, бюджет и требования к функциональности. Если заказчик понимает, что определенная функция, к которой у него изменились требования, потребует дополнительных вложений или времени, он может принять решение о корректировке бюджета и сроков.
Существует несколько терминов, используемых для описания технической документации. Техническое задание (ТЗ) — это один из них, но иногда оно может быть неполным или недостаточно детализированным. В таких случаях используются другие документы, например, частное техническое задание (ЧТЗ) или пользовательские сценарии. Они описывают, как система должна функционировать в конкретных условиях. Важно понимать, что начальные требования и конечные технические документы могут различаться.
Если на начальном этапе предоставлены лишь общие требования, то нашим ответом будет детальное техническое задание. В случае, когда заказчик предоставляет документ, который он называет ТЗ, но это лишь стандартные документы по ГОСТу, мы отмечаем, что такой документ слишком обобщен. Применительно к автомобилю, представьте, что требованиями были: 4 колеса, кузов, багажник, подсветка и дизельный двигатель. По таким требованиям можно получить дизельный трактор с подсветкой. Поэтому требования всегда требуют уточнения.
При использовании гибкого инструмента low-code, можно визуализировать процесс создания продукта. Представьте, что вы приходите на завод, где множество деталей, и начинаете создавать автомобиль в непосредственном сотрудничестве с заказчиком. Вы обсуждаете каждую деталь, спрашиваете, какую гайку предпочитает заказчик, где он хочет видеть определенные элементы в машине. Заказчик, таким образом, участвует в процессе создания своего автомобиля, будь то BMW или Bentley, и каждая мелочь настраивается согласно его пожеланиям. Именно благодаря гибкости нашего инструмента мы можем быстро адаптировать требования и вносить изменения на лету, учитывая пожелания заказчика. И это, позволяет отказаться от ТЗ на старте и сделать реализацию проектов значительно быстрее.
Комментарии (33)
sergeyns
05.09.2023 06:18+2но это лишь стандартные документы по ГОСТу
Да сейчас встретить ТЗ у которого хотя бы заголовок будет по госту (точнее все разделы, предусмотренные гостом) - это большая удача ))
Вы обсуждаете каждую деталь, спрашиваете, какую гайку предпочитает заказчик, где он хочет видеть определенные элементы в машине.
Автомобиль вы так никогда не сделаете
ТЗ нужно. Но вопрос в каком виде/насколько подробно.. и это повод для холивара. Наверно, написать "сделайте нам систему документооборота" - это как-то очень общо... А прописать все "экранные формы" - это нереально (если только вы не пишите ТЗ на уже существующий продукт)...
BeLord
05.09.2023 06:18Моя компания использует документацию по ГОСТ, иногда бывают легкие отклонения в связи пожеланиями заказчика, который в принципе не понимает зачем ГОСТы нужны, но в целом соответствие 95%, есть желание в 2024 перевести всю документацию в соответствии с ГОСТ на 100%. А так в целом основная масса документации соответствует требования ГОСТ P 59795-2021.
Emulyator
05.09.2023 06:18+2Многие могут возразить: "Как можно начать работу, не имея четкого понимания требований?" Но вот тут и кроется наша инновация.
Не думаю, что это инновация, может не общая практика, но не инновация. )
itGuevara
05.09.2023 06:18+2Тезисы по ТЗ:
ТЗ нужно, в том числе потому, что на его основе строятся Методика испытаний и Технические условия (ТУ, кстати ТУ делают и на ПО).
ТЗ обычный заказчик не понимает и это нормально. Для сложных систем делают ТЗ на одно и то изделие, но на каждый этап (эскизный проект, техпроект, рабочий) – эти ТЗ отличаются детализацией. Бизнес-требования (функциональные требования) это по сути ТЗ на эскизный проект.
Иметь хорошее (конкретное) ТЗ – это на 30 процентов уже построить систему (взаимоувязанные требования задают «красную нить» разработки). Однако в ТЗ заказчики часто задают размытые формулировки, чтобы «подстраховаться». Потому что: ТЗ исполнитель обычно делает так (пользуясь, что заказчик в деталях не понимает), чтобы как можно было легко закрыть договор (ТЗ приложение к договору на работу) и возложить вину на заказчика если что-то не хватает и тут же предложить новый допник на доработки (заказчик уже «на крючке» и его можно «щипать»). Исполнитель обычно говорит: заказчик сам не знает, чего хочет. Иногда говорят так: «заказчик знает, что хочет, а исполнитель знает, что действительно нужно заказчику» (но это не так). Типовой результат проекта: работы выполнены в точности по ТЗ, но заказчик хотел другого.
Ранее на большие АСУ было так: после выполнения работ САМ исполнитель (и до испытаний) давал отдельный лист (не дословно) «Перечень отклонений от ТЗ». В нем было показано, что не соответствует ТЗ и почему. Т.е. разработчик брался за работу осознавая, что может сделать не все (представительные комиссии решали допустимость приемки таких работ) ввиду сложности системы.
Кстати ранее при разработке больших систем (АСУ) по «водопаду» – для элементов часто использовался agile, еще до появления этого термина. Это к теме «За кулисами Scrum-мастерства: о навыках, заблуждениях и реалиях профессии».
Вообще, применительно к Comindware было бы интереснее не подобные рассуждения ТЗ\ Scrum\ Apache Ignite, а примеры использования в Comindware техник "linked data".
aegoroff
05.09.2023 06:18Вот например https://kb.comindware.ru/article/Расширения-comindware-Примеры-использования-1481.html но вообще там собственно вся база на тройках и сделана (по крайней мере до внедрения апач игнайт). Все что вы вносите в базу, в виде этих троек (фактов) там и хранится.
itGuevara
05.09.2023 06:18Моя ссылка примерно туда же. Я про комплексные примеры использования. Хотелось бы и примеры визуализации.
На мой взгляд, чтобы это использовать нужна интеграция с редактором онтологий или прямо встроенный, например, как protege в essential
https://ingenia.wordpress.com/2009/03/02/essential/
https://github.com/freddy-realirm/BPMNEditor-For-Protege-Essential
Alex_Chicot
05.09.2023 06:18+2со стороны исполнителя войти в проект без ТЗ возможно в том случае, если есть возможность соскочить с проекта. В противном случае можно войти в проект условно за 100 рублей и работать там годами, из-за того, что Заказчик будет уточнять и уточнять свое единственно требование «хочу, чтобы это работало так, как мне нужно».
Emulyator
05.09.2023 06:18+2В случае "почасовой" или "поэтапной/помодульной" оплаты можно годами без т.з. удовлетворять хотелки клиента за вполне хорошие деньги, и такое тоже имеет место быть.
Alex_Chicot
05.09.2023 06:18А кто сказал, что Заказчику нужна такая модель оплаты? В мире много чего придумано. Но нужно определиться от чего пляшем. Заказчику нужен результат, или исполнителю нужно работать?
Emulyator
05.09.2023 06:18Заказчик и получает результат просто не через ТЗ, а по принципу предоставления вариантов решения с последующей доделкой, переделкой на базе устного общения в доверительном тоне. В итоге все довольны годами.
Alex_Chicot
05.09.2023 06:18Какой результат можно получить, не обладая изначально определенной постановкой? Лично мне/моей Компании документация необходима. ФТТ/ТЗ. Пол них - проектная документация. И только так можно в дальнейшем поддерживать тысячи систем, созданные сотнями исполнителей.
Emulyator
05.09.2023 06:18Документация - это дополнительное время и деньги. В каких-о случаях она строго обязательна, в каких-то полезна, а иногда, внезапно вредна. Вредна не сама по себе, а накладными расходами. Очень часто заказчику нужен не просто результат, а результат еще вчера, и времени (да и желания) на создание, согласование и подписания качественного т.з. у него нет. При этом есть сроки, деньги и доверие к исполнителю, который из опыта понимает, что подойдет заказчику лучше, чем сам заказчик. Исполнять пункты подробного т.з. можно тоже формально, так что продукт будет хуже, чем при большой свободе творчества и принятия решений. Люди, которые исповедуют принцип "без т.з. ни строчки кода", будут терять часть потенциальных клиентов, если это не проблема, то можно и так работать.
Alex_Chicot
05.09.2023 06:18Еще раз повторю - да, бывает ситуация, когда можно делать работу и без ТЗ. Но это, как правило, небольшой объем работ и небольшие Заказчики. Конечно, всё относительно.
При этом я рассуждаю на тему, вынесенную в заголовок. И говорю, что ТЗ порой необходимо для проекта. И против безапеляционности рассматриваемого посыла.
VBKesha
05.09.2023 06:18+1Для этого придумана повременная оплата. Вот отчеты о проделанной работе за месяц, вот столько нам отсыпьте за это денег. И мы с радостью продолжим делать любые ваши хочу.
Alex_Chicot
05.09.2023 06:18Да на здоровье. Но крупный Заказчик не будет платить так. Ему нужен результат работы. Один-два проекта по такой схеме получится пихнуть. Дальше - всё. Оплата за результат. И тут же переход к этапности. А это - деление потребности на части. И снова - ТЗ.
Вот и получается - ориентир нужен. Это проблема из серии «какая методология проекта единственно верная - pmbook или agile” (прошу прощения, если не совсем корректно использовал данные термины, но смысл, думаю, понятен).
VBKesha
05.09.2023 06:18+1Дальше — всё. Оплата за результат. И тут же переход к этапности.
Мне NDA не позволяет указать заказчика, но мелким его не назовешь. И 70% проектов идет именно как я описал. И надо заметить заказчик сам настаивает на таком принципе оплаты. Там конечно не так что мы пилим сколько хотим, есть момент оценки задачи с нашей стороны и согласования.
Хотя бывает и без согласования, вот надо такая фича работайте.Один-два проекта по такой схеме получится пихнуть.
Некоторые проекты длятся уже больше 7 лет, тут куча компания рядом успели закрыться, снова открыться, и снова закрыться...
Alex_Chicot
05.09.2023 06:18Повторюсь - бывает всяко. Я в первую очередь против однозначного декларирования «ТЗ не нужно». Всё определяется размером и целями проекта и Заказчика.
Я «играю» сейчас со стороны Заказчика, ооочень крупного. Был и исполнителем. И всё испытывал на себе.
VBKesha
05.09.2023 06:18Я в первую очередь против однозначного декларирования «ТЗ не нужно».
Я тут вас поддержу на 100% когда ТЗ есть, это в 90% хорошо, как минимум в плане понятности когда проект закончится. В противном случае он может закончится внезапно и это очень неудобно.
Glays
05.09.2023 06:18В моём представлении только более менее чёткое ТЗ может позволить оценить применимость lowcode платформы. Если какая-то часть постановки не реализуема в lowcode, то и выбор этого инструмента нецелесообразен.
Как гибкая разработка сочетается с негибкостью lowcode решений? Если agile команда в целом не привязана к инструменту реализации и в самом крайнем случае может его сменить, то с lowcode это будет означать уход от lowcode совсем.
Или есть какая-то инновация? Тогда в чём она заключается?
tmxx
05.09.2023 06:18Представьте, что перед вами стоит задача построить мост через железную дорогу. Традиционный подход предполагает долгие исследования и планирование. Но что, если у нас есть новый материал, который позволяет быстро создавать и корректировать конструкции? Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать. Зато все будет предельно практично, наглядно и соответствовать ожиданиям и реальным возможностям.
Да, недавно была новость про руководителя такой разработки: https://habr.com/ru/news/743448/
Batalmv
05.09.2023 06:18+1Куча вопросов:
Почему заказчик пишет ТЗ (ТЕХНИЧЕСКОЕ задание)?? Я даже перенесу две цитаты, чтобы быть уверенным что мне это не привиделось "На старте заказчик решил работать с внешним интегратором для составления технического задания." и "заказчик предоставил нам верхнеуровневые функциональные требования и стал разрабатывать ТЗ ". Заказчик ОЧЕНЬ редко может писать именно ТЗ, он не имеет команды сильных аналитиков, он не знает решения. Что он может написать? Да, исключения бывают, но очень редко. Может в этом дело? Ну реально странно, ожидать успеха и быстрого внедрения, где заказчик уединившись сам с собой или с приглашенными "интеграторами" пишет ТЗ. В этом месте уже можно хоронить, причем без покойника :)
Очень удивило вообще сочетание low-code платформы и ТЗ. Объясню на примере платформы PEGA (либо IBM BPM). Хорошая low-code платформа обычно внутри содержит МЕТОДОЛОГИЮ своего внедрения, детальные роли, этапы и т.д. И к примеру, эти две системы не говорят о ТЗ вообще. Ну странно. Low-code - это участия заказчика чуть ли не в самой разработке, идеологически Agile под капотом, и вообще - сама идея платформ, это быстрое изменение логики и возможность бизнеса в САМОЙ платформе видеть свои требования в понятном виде. Т.е. либо low-code не такого класса (допускаю), либо внедрятели решили не читать доку, как внедрять
В 2023 году вообще поднимать вопросы такого уровня? Уже вроде все давно пройдено, начиная с контрактинга, как делать fixed bid/fixed scope, time&material и dedicated контракты. Все идет от контракта, так как на первом типе можно применять Agile, но если вы уже договорились за скоуп и деньги - ну такое. Будет либо ритуальные танцы, либо любую хотелку надо проводить через ChR процедуру, либо у вас странный fixed/fixed.
Ну и ... зачем вам вообще ТЗ? Ритуально станцевать перед заказчиком? Назвать ТЗ пост документацию решения? Я не понял. ТЗ в конце - это не ТЗ. Просто из названия и сути документа. Какое может быть задание, если работа сделана.
Единственное - просто длинная реклама платформы, которая концептуально "опередила время", если ее вернуть в прошлое лет 20 назад :) Есть класс систем и, в общем-то, давно сформированные подходы к внедрению. Класс довольно таки древний, но по прежнему успешный в большом enterprise. Попытка выглядеть как "иноваторы" - камон :)
UserName1212
05.09.2023 06:18так в статье вроде как раз и речь про то, что ТЗ мешает в случае low-code.. не? :) Но заказчики по старинке не могут без него работать - вот и получаются или грабли или тормоза вместо полёта творчества талантливых аналитиков..
Batalmv
05.09.2023 06:18+1Дело в том, что в статье чуток перепутаны местами телега и лошадь
Начнем с начала. Контора Х продает платформу Y + услуги по внедерению на ее базе кастомизированного продукта заказчику. Заказчик это покупает.
Если платформа Y реально хорошая и мачурная, то у нее под капотом (но всем доступно и модно долго не искать) есть методология внедрения решений на базе этой платформы. Примеры я давал, это PEGA и IBM. И эти методологии (я просто буду писать о том, что чуток знаю) довольно таки детализированы с ролями, этапами, инструментами для каждого этапа и много-много чего еще. Т.е. разработчик платформы, консолидировав опыт внедрения, да и просто будут кучу лет на рынке уже пришел к тому, как УСПЕШНО внедрять. Что интересно, на примерах этих двух платформ, а они взяты не с потолка, а как более продвинутые аналоги того, что использует автор (comindware), в методологии нет никакого ТЗ, а очень грубо есть итеративный подход.
Итеративный подход во внедрении BPM взят не просто так, а потому что именно он по сути и раскрывает преимущества такого класса решений. Прозрачность логики для бизнеса (где даже можно ему выделить место и пусть сам настраивает), возможность померять результат, прокрутить симуляции, идентифицировать узкие места ... в общем я тут это не продаю :), но надеюсь мысл понятна. Правильно внедрение BPM по мнению тех, кто на этом упрядку собак съел - итеративный подход и без написания ТЗ. Уже тут как бы понятно, что статья начинает выглядеть по сюжету как сказка про кашу из топора, где в роли топора выступает ТЗ. Т.е. как бы да, но мы ж не дети. Зачем нам топор в каше? А уже долгое описание, почему кашу варить без топора удобнее ... ну такое.
К этому моменту мы получаем прямую логику:
платформа BPM
методология внедрения
успех (не всегда конечно, но в целом шансы есть)
Почему бы не написать так, неясно.
Теперь о ТЗ и вредном заказчике. В целом, я думаю, проблема на моменте продажи. Основное преимущество такого класса решений - это перестать "круглое носить, а квадратное катать". Заказчик уже довольно таки поднаторел в этом подходе, оброл полезными навыками катания и, возможно даже может написать дисертацию, что катать квадратное через ребро лучше чем через вершину и он даже может поделиться богаты м опытом. На этапе продажи, заказчика надо обратить в новую веру "квадратное носить, а круглое катать". Иначе все - реально "хоронить без покойника". Всю пользу от платформы почти сразу можно выбросить. А минусов очень много. Это в принципе порочная практика, брать техническое решение, почти код можно сказать, но выкинуть инструкцию и начать "забивать микроскопом гвозди"
У меня есть реальная история внедрения решений на базе EMC Documentum. Поставщик выиграл тендер и начали писать ТЗ. Это была титаническая работа, куча ревизий, правок, техника одновременной работы над Word документом 10+ человек достигла невиданных ранее высот. Финальный этап согласования вообще выглядел так:
сели в переговорке
положили телефоны в шкаф
решили, что пока не согласуем - не выйдем, иначе "спонсор" всем сделает "секир башка"
На 6й час у одной из барышень реально случился какой-то припадок, она стала натурально кататься по полу и просить ее выпустить, иначе ее клаустрофобия (или что-то ее, было не очень понятно) ее тут прям прикончит, но ей не помогло. Добивать ногами не стали, но подождали пока само пройдет и продолжили.
Итог закономерен, куча денег, ресурсов, даже что-то там работало через пару лет. Но пока все это делалось, бойцы из локальной конторы за еду на Lotus (просто был) сделали 50 процессов как временное решение, которое, как и любое временное решение жило очень долго.
Вывод: если плафторма и МЕТОДОЛОГИЯ внедрения решений на ее базе не предполагают написания ТЗ - не надо это делать. И сразу это честно сказать заказчику, так как именно новый подход даст все те плюшки, которые написаны в буклете платформы.
Но можно гордо есть кактус, плакать и делаться опытом, как это получалось
NIKEtoS1989
05.09.2023 06:18Ну если бы все всегда делали максимально детальное ТЗ, то наверное мы все до сих пор работали по водопаду, но внезапно большинство из нам используют гибкие методологии)
По факту каноническое ТЗ действительно избыточно зачастую, но вот полное его отсутствие и оперирование одними бизнес-требованиями как другая крайность - тоже не очень, так что по ситуации надо смотреть насколько для данного кейса важна глубина или не важна, если не очень важна, то требования могут быть довольно верхнеуровневыми и их может хватить, а в ином случае наоборот нужна детализация, единого ответа тут не существует
dimas062
05.09.2023 06:18"Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать." - сколько раз и за чей счет?
Emulyator
05.09.2023 06:18За счет тех же, кто оплачивает длительное проектирование и внесение изменений в проект и переделки уже сделанного в случае возникновения каких-то неучтенных моментов на более поздних этапах.
papilaz
05.09.2023 06:18Всегда делаем ТЗ, и это спасает. Делаем за деньги. Сроки по графику и наши и заказчика. Большое декомпозируем. А на большой проект делаем только концепцию большими мазками. Рекомендую делать ТЗ всегда. У вас не ТЗ потопило, а организация проектного процесса. Это и чините.
Yuri_nedre
Почему под ТЗ вы подразумеваете только функциональные требования? А не функциональные?
uuger
В сферическом российском энтерпрайзе в вакууме подавляющее количество заказчиков и исполнителей не отличает бизнес-требования от функциональных и нефункциональных. Часто используется зонтичный псевдо-термин "функционал", который означает всё что угодно в зависимости от настроения участников проекта и ретроградности
Меркуриязаказчика.Yuri_nedre
Вот тут плюсану вас.
Но где-то это решается просто обучением команды (или даже заказчика), а где-то просто экономят деньги на нормальных аналитиках (
uuger
Когда заказчик очень большой, любой подрядчик для него - проходящее явление. И никто не будет перестраивать свой "богатый внутренний мир". Особенно это заметно, когда происходят встречи по обмену опытом между двумя сравнимыми по масштабу мастодонтами.
Master_of_Slaves
Могу по опыту сказать, что зависит от компании, в которой ты работаешь. Сейчас я работаю в небольшой компании, где функциональные требования предел моих ТЗ. Есть ГОСТы и прочее, но все же ТЗ - это документ внутреннего пользования. Какой он по структуре и содержанию не особо важно, если он понятен разработчикам в таком виде, с каким они привыкли работать. Но, для новых сотрудников, привыкших к другим видам ТЗ, он может вызвать вопросы. В другой компании я писал бизнес-функциональные требования и технические задания, все было с четкой структурой, приложениями и прочим, так как проекты могли быть проданы и доки должны быть понятны одинаково для всех.
По поводу статьи, что-то звучит максимально странно, как по мне. Я лучше потрачу время на проектирование и ведение документации. Качественное ТЗ даст наиболее точное представление о сроках и бюджете.
Документацию можно утвердить заказчиком, чтобы потом не было такого - "А я такого не говорил", "требования были другими", "а я этого не утверждал".
Лучше уметь работать с заказчиком, чем «Без ТЗ нужно уметь управлять функциональностью».