Comments 33
Почему под ТЗ вы подразумеваете только функциональные требования? А не функциональные?
В сферическом российском энтерпрайзе в вакууме подавляющее количество заказчиков и исполнителей не отличает бизнес-требования от функциональных и нефункциональных. Часто используется зонтичный псевдо-термин "функционал", который означает всё что угодно в зависимости от настроения участников проекта и ретроградности Меркурия заказчика.
Могу по опыту сказать, что зависит от компании, в которой ты работаешь. Сейчас я работаю в небольшой компании, где функциональные требования предел моих ТЗ. Есть ГОСТы и прочее, но все же ТЗ - это документ внутреннего пользования. Какой он по структуре и содержанию не особо важно, если он понятен разработчикам в таком виде, с каким они привыкли работать. Но, для новых сотрудников, привыкших к другим видам ТЗ, он может вызвать вопросы. В другой компании я писал бизнес-функциональные требования и технические задания, все было с четкой структурой, приложениями и прочим, так как проекты могли быть проданы и доки должны быть понятны одинаково для всех.
По поводу статьи, что-то звучит максимально странно, как по мне. Я лучше потрачу время на проектирование и ведение документации. Качественное ТЗ даст наиболее точное представление о сроках и бюджете.
Документацию можно утвердить заказчиком, чтобы потом не было такого - "А я такого не говорил", "требования были другими", "а я этого не утверждал".
Лучше уметь работать с заказчиком, чем «Без ТЗ нужно уметь управлять функциональностью».
но это лишь стандартные документы по ГОСТу
Да сейчас встретить ТЗ у которого хотя бы заголовок будет по госту (точнее все разделы, предусмотренные гостом) - это большая удача ))
Вы обсуждаете каждую деталь, спрашиваете, какую гайку предпочитает заказчик, где он хочет видеть определенные элементы в машине.
Автомобиль вы так никогда не сделаете
ТЗ нужно. Но вопрос в каком виде/насколько подробно.. и это повод для холивара. Наверно, написать "сделайте нам систему документооборота" - это как-то очень общо... А прописать все "экранные формы" - это нереально (если только вы не пишите ТЗ на уже существующий продукт)...
Моя компания использует документацию по ГОСТ, иногда бывают легкие отклонения в связи пожеланиями заказчика, который в принципе не понимает зачем ГОСТы нужны, но в целом соответствие 95%, есть желание в 2024 перевести всю документацию в соответствии с ГОСТ на 100%. А так в целом основная масса документации соответствует требования ГОСТ P 59795-2021.
Многие могут возразить: "Как можно начать работу, не имея четкого понимания требований?" Но вот тут и кроется наша инновация.
Не думаю, что это инновация, может не общая практика, но не инновация. )
Тезисы по ТЗ:
ТЗ нужно, в том числе потому, что на его основе строятся Методика испытаний и Технические условия (ТУ, кстати ТУ делают и на ПО).
ТЗ обычный заказчик не понимает и это нормально. Для сложных систем делают ТЗ на одно и то изделие, но на каждый этап (эскизный проект, техпроект, рабочий) – эти ТЗ отличаются детализацией. Бизнес-требования (функциональные требования) это по сути ТЗ на эскизный проект.
Иметь хорошее (конкретное) ТЗ – это на 30 процентов уже построить систему (взаимоувязанные требования задают «красную нить» разработки). Однако в ТЗ заказчики часто задают размытые формулировки, чтобы «подстраховаться». Потому что: ТЗ исполнитель обычно делает так (пользуясь, что заказчик в деталях не понимает), чтобы как можно было легко закрыть договор (ТЗ приложение к договору на работу) и возложить вину на заказчика если что-то не хватает и тут же предложить новый допник на доработки (заказчик уже «на крючке» и его можно «щипать»). Исполнитель обычно говорит: заказчик сам не знает, чего хочет. Иногда говорят так: «заказчик знает, что хочет, а исполнитель знает, что действительно нужно заказчику» (но это не так). Типовой результат проекта: работы выполнены в точности по ТЗ, но заказчик хотел другого.
Ранее на большие АСУ было так: после выполнения работ САМ исполнитель (и до испытаний) давал отдельный лист (не дословно) «Перечень отклонений от ТЗ». В нем было показано, что не соответствует ТЗ и почему. Т.е. разработчик брался за работу осознавая, что может сделать не все (представительные комиссии решали допустимость приемки таких работ) ввиду сложности системы.
Кстати ранее при разработке больших систем (АСУ) по «водопаду» – для элементов часто использовался agile, еще до появления этого термина. Это к теме «За кулисами Scrum-мастерства: о навыках, заблуждениях и реалиях профессии».
Вообще, применительно к Comindware было бы интереснее не подобные рассуждения ТЗ\ Scrum\ Apache Ignite, а примеры использования в Comindware техник "linked data".
Вот например https://kb.comindware.ru/article/Расширения-comindware-Примеры-использования-1481.html но вообще там собственно вся база на тройках и сделана (по крайней мере до внедрения апач игнайт). Все что вы вносите в базу, в виде этих троек (фактов) там и хранится.
Моя ссылка примерно туда же. Я про комплексные примеры использования. Хотелось бы и примеры визуализации.
На мой взгляд, чтобы это использовать нужна интеграция с редактором онтологий или прямо встроенный, например, как protege в essential
https://ingenia.wordpress.com/2009/03/02/essential/
https://github.com/freddy-realirm/BPMNEditor-For-Protege-Essential
со стороны исполнителя войти в проект без ТЗ возможно в том случае, если есть возможность соскочить с проекта. В противном случае можно войти в проект условно за 100 рублей и работать там годами, из-за того, что Заказчик будет уточнять и уточнять свое единственно требование «хочу, чтобы это работало так, как мне нужно».
В случае "почасовой" или "поэтапной/помодульной" оплаты можно годами без т.з. удовлетворять хотелки клиента за вполне хорошие деньги, и такое тоже имеет место быть.
А кто сказал, что Заказчику нужна такая модель оплаты? В мире много чего придумано. Но нужно определиться от чего пляшем. Заказчику нужен результат, или исполнителю нужно работать?
Заказчик и получает результат просто не через ТЗ, а по принципу предоставления вариантов решения с последующей доделкой, переделкой на базе устного общения в доверительном тоне. В итоге все довольны годами.
Какой результат можно получить, не обладая изначально определенной постановкой? Лично мне/моей Компании документация необходима. ФТТ/ТЗ. Пол них - проектная документация. И только так можно в дальнейшем поддерживать тысячи систем, созданные сотнями исполнителей.
Документация - это дополнительное время и деньги. В каких-о случаях она строго обязательна, в каких-то полезна, а иногда, внезапно вредна. Вредна не сама по себе, а накладными расходами. Очень часто заказчику нужен не просто результат, а результат еще вчера, и времени (да и желания) на создание, согласование и подписания качественного т.з. у него нет. При этом есть сроки, деньги и доверие к исполнителю, который из опыта понимает, что подойдет заказчику лучше, чем сам заказчик. Исполнять пункты подробного т.з. можно тоже формально, так что продукт будет хуже, чем при большой свободе творчества и принятия решений. Люди, которые исповедуют принцип "без т.з. ни строчки кода", будут терять часть потенциальных клиентов, если это не проблема, то можно и так работать.
Еще раз повторю - да, бывает ситуация, когда можно делать работу и без ТЗ. Но это, как правило, небольшой объем работ и небольшие Заказчики. Конечно, всё относительно.
При этом я рассуждаю на тему, вынесенную в заголовок. И говорю, что ТЗ порой необходимо для проекта. И против безапеляционности рассматриваемого посыла.
Для этого придумана повременная оплата. Вот отчеты о проделанной работе за месяц, вот столько нам отсыпьте за это денег. И мы с радостью продолжим делать любые ваши хочу.
Да на здоровье. Но крупный Заказчик не будет платить так. Ему нужен результат работы. Один-два проекта по такой схеме получится пихнуть. Дальше - всё. Оплата за результат. И тут же переход к этапности. А это - деление потребности на части. И снова - ТЗ.
Вот и получается - ориентир нужен. Это проблема из серии «какая методология проекта единственно верная - pmbook или agile” (прошу прощения, если не совсем корректно использовал данные термины, но смысл, думаю, понятен).
Дальше — всё. Оплата за результат. И тут же переход к этапности.
Мне NDA не позволяет указать заказчика, но мелким его не назовешь. И 70% проектов идет именно как я описал. И надо заметить заказчик сам настаивает на таком принципе оплаты. Там конечно не так что мы пилим сколько хотим, есть момент оценки задачи с нашей стороны и согласования.
Хотя бывает и без согласования, вот надо такая фича работайте.
Один-два проекта по такой схеме получится пихнуть.
Некоторые проекты длятся уже больше 7 лет, тут куча компания рядом успели закрыться, снова открыться, и снова закрыться...
Не понятно, зачем dp1976 вести корпоративный блог с отключенными личными сообщениями. Обычно наоборот, ждут обратную связь.
В моём представлении только более менее чёткое ТЗ может позволить оценить применимость lowcode платформы. Если какая-то часть постановки не реализуема в lowcode, то и выбор этого инструмента нецелесообразен.
Как гибкая разработка сочетается с негибкостью lowcode решений? Если agile команда в целом не привязана к инструменту реализации и в самом крайнем случае может его сменить, то с lowcode это будет означать уход от lowcode совсем.
Или есть какая-то инновация? Тогда в чём она заключается?
Представьте, что перед вами стоит задача построить мост через железную дорогу. Традиционный подход предполагает долгие исследования и планирование. Но что, если у нас есть новый материал, который позволяет быстро создавать и корректировать конструкции? Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать. Зато все будет предельно практично, наглядно и соответствовать ожиданиям и реальным возможностям.
Да, недавно была новость про руководителя такой разработки: https://habr.com/ru/news/743448/
Куча вопросов:
Почему заказчик пишет ТЗ (ТЕХНИЧЕСКОЕ задание)?? Я даже перенесу две цитаты, чтобы быть уверенным что мне это не привиделось "На старте заказчик решил работать с внешним интегратором для составления технического задания." и "заказчик предоставил нам верхнеуровневые функциональные требования и стал разрабатывать ТЗ ". Заказчик ОЧЕНЬ редко может писать именно ТЗ, он не имеет команды сильных аналитиков, он не знает решения. Что он может написать? Да, исключения бывают, но очень редко. Может в этом дело? Ну реально странно, ожидать успеха и быстрого внедрения, где заказчик уединившись сам с собой или с приглашенными "интеграторами" пишет ТЗ. В этом месте уже можно хоронить, причем без покойника :)
Очень удивило вообще сочетание 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. Попытка выглядеть как "иноваторы" - камон :)
так в статье вроде как раз и речь про то, что ТЗ мешает в случае low-code.. не? :) Но заказчики по старинке не могут без него работать - вот и получаются или грабли или тормоза вместо полёта творчества талантливых аналитиков..
Дело в том, что в статье чуток перепутаны местами телега и лошадь
Начнем с начала. Контора Х продает платформу Y + услуги по внедерению на ее базе кастомизированного продукта заказчику. Заказчик это покупает.
Если платформа Y реально хорошая и мачурная, то у нее под капотом (но всем доступно и модно долго не искать) есть методология внедрения решений на базе этой платформы. Примеры я давал, это PEGA и IBM. И эти методологии (я просто буду писать о том, что чуток знаю) довольно таки детализированы с ролями, этапами, инструментами для каждого этапа и много-много чего еще. Т.е. разработчик платформы, консолидировав опыт внедрения, да и просто будут кучу лет на рынке уже пришел к тому, как УСПЕШНО внедрять. Что интересно, на примерах этих двух платформ, а они взяты не с потолка, а как более продвинутые аналоги того, что использует автор (comindware), в методологии нет никакого ТЗ, а очень грубо есть итеративный подход.
Итеративный подход во внедрении BPM взят не просто так, а потому что именно он по сути и раскрывает преимущества такого класса решений. Прозрачность логики для бизнеса (где даже можно ему выделить место и пусть сам настраивает), возможность померять результат, прокрутить симуляции, идентифицировать узкие места ... в общем я тут это не продаю :), но надеюсь мысл понятна. Правильно внедрение BPM по мнению тех, кто на этом упрядку собак съел - итеративный подход и без написания ТЗ. Уже тут как бы понятно, что статья начинает выглядеть по сюжету как сказка про кашу из топора, где в роли топора выступает ТЗ. Т.е. как бы да, но мы ж не дети. Зачем нам топор в каше? А уже долгое описание, почему кашу варить без топора удобнее ... ну такое.
К этому моменту мы получаем прямую логику:
платформа BPM
методология внедрения
успех (не всегда конечно, но в целом шансы есть)
Почему бы не написать так, неясно.
Теперь о ТЗ и вредном заказчике. В целом, я думаю, проблема на моменте продажи. Основное преимущество такого класса решений - это перестать "круглое носить, а квадратное катать". Заказчик уже довольно таки поднаторел в этом подходе, оброл полезными навыками катания и, возможно даже может написать дисертацию, что катать квадратное через ребро лучше чем через вершину и он даже может поделиться богаты м опытом. На этапе продажи, заказчика надо обратить в новую веру "квадратное носить, а круглое катать". Иначе все - реально "хоронить без покойника". Всю пользу от платформы почти сразу можно выбросить. А минусов очень много. Это в принципе порочная практика, брать техническое решение, почти код можно сказать, но выкинуть инструкцию и начать "забивать микроскопом гвозди"
У меня есть реальная история внедрения решений на базе EMC Documentum. Поставщик выиграл тендер и начали писать ТЗ. Это была титаническая работа, куча ревизий, правок, техника одновременной работы над Word документом 10+ человек достигла невиданных ранее высот. Финальный этап согласования вообще выглядел так:
сели в переговорке
положили телефоны в шкаф
решили, что пока не согласуем - не выйдем, иначе "спонсор" всем сделает "секир башка"
На 6й час у одной из барышень реально случился какой-то припадок, она стала натурально кататься по полу и просить ее выпустить, иначе ее клаустрофобия (или что-то ее, было не очень понятно) ее тут прям прикончит, но ей не помогло. Добивать ногами не стали, но подождали пока само пройдет и продолжили.
Итог закономерен, куча денег, ресурсов, даже что-то там работало через пару лет. Но пока все это делалось, бойцы из локальной конторы за еду на Lotus (просто был) сделали 50 процессов как временное решение, которое, как и любое временное решение жило очень долго.
Вывод: если плафторма и МЕТОДОЛОГИЯ внедрения решений на ее базе не предполагают написания ТЗ - не надо это делать. И сразу это честно сказать заказчику, так как именно новый подход даст все те плюшки, которые написаны в буклете платформы.
Но можно гордо есть кактус, плакать и делаться опытом, как это получалось
Ну если бы все всегда делали максимально детальное ТЗ, то наверное мы все до сих пор работали по водопаду, но внезапно большинство из нам используют гибкие методологии)
По факту каноническое ТЗ действительно избыточно зачастую, но вот полное его отсутствие и оперирование одними бизнес-требованиями как другая крайность - тоже не очень, так что по ситуации надо смотреть насколько для данного кейса важна глубина или не важна, если не очень важна, то требования могут быть довольно верхнеуровневыми и их может хватить, а в ином случае наоборот нужна детализация, единого ответа тут не существует
"Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать." - сколько раз и за чей счет?
Всегда делаем ТЗ, и это спасает. Делаем за деньги. Сроки по графику и наши и заказчика. Большое декомпозируем. А на большой проект делаем только концепцию большими мазками. Рекомендую делать ТЗ всегда. У вас не ТЗ потопило, а организация проектного процесса. Это и чините.
Почему ТЗ — лучший способ провалить ваш проект?