По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя.
Это разные документы и служат разным целям и они взаимо дополняющие.
TЗ — это что надо сделать
Функциональная спецификация — как сделать то, что указано в ТЗ
Пользователь скажет: Хочу отчет по продажам.
ТЗ будет включать:
ТЗ-1.1 Система должна предоставлять Отчет по продажам «в штуках». Форма отчета см…
ТЗ-1.2 Система должна предоставлять Отчет по продажам «в деньгах». форма отчета см…
ТЗ-1.3 Система должна предоставлять возможность экспорта отчетов в формат PDF
ТЗ-1.4 Система должна предоставлять возможность экспорта отчетов в формат Excel xlsx
Функциональная спецификация будет включать:
Пункт ТЗ-1.1 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
Пункт ТЗ-1.2 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
Нюанс в том, что в Scrum(Agile) все равно есть этап анализа и рассмотрения Story и критериев приемки, юнит-тесты и QA, которые все равно должны базироваться на чем-то конкретном и доказать что «Оно делает что надо». В противном случае на этапе «покера» просто не смогут договориться «что делать», не говоря уже «как делать».
Хорошим тоном считается не брать в BackLog спринта User Story, которая не сопровождается критериями приемки.
Так что миниТЗ все равно есть.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ,
Ключевой вопрос: откуда вы взяли ПЛАН?
Как следствие: вам сделали по ВАШЕМУ плану — постройка утонула или не выполнила ожидаемое. К кому претензии? К Вам или к строителям?
Если вы «купили» план — вы за него заплатили «тому парню», если вы сделали его сами — вы заплатили своим временем как минимум.
Заказчик платит в любом случае :)
Если Вы еще «не вынесли» мозг строителям, вам покажут пальчиком на сомнительные моменты и уточнят пару деталей — это будет бесплатно.
Но если вы «вынесли» мозг строителям — они вам сделают как «заказано», и ни одна зараза не намекнет, что марка труб у вас «тонкая и ржавеют с нашей водой» или штукатурка фиг подходит под климат или еще что…
Так и с ТЗ для клиента — адекватный, можно и соломку ему «подстелить».
Можно сказать что согласно ЗАКОНУ а можно и не говорить
Если иное не предусмотрено договором подряда, заказчик, принявший результаты работы без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)
Это, к сожалению заблуждение. Перепутана причина и следствие. Просто тех работники редко задумываются и читают юридические «бумажки», как и юристы технические.
У меня Закон звучит так:
1. Качество выполненной подрядчиком работы должно соответствовать условиям договора подряда, а при их отсутствии или неполноте – требованиям, обычно предъявляемым к работам соответствующего рода. Если иное не предусмотрено законодательством или договором, результат выполненной работы должен в момент передачи заказчику обладать свойствами, указанными в договоре или определенными обычно предъявляемыми требованиями, и в пределах разумного срока быть пригодным для установленного договором использования, а если такое использование договором не предусмотрено, – для обычного использования результата работы такого рода.
2. Если законодательством или в установленном им порядке предусмотрены обязательные требования к работе, выполняемой по договору подряда, подрядчик, действующий в качестве предпринимателя, обязан выполнять работу, соблюдая эти обязательные требования.
Как бы я не изворачивался, но должен следовать, иначе Клиент меня просто «на органы продаст» что бы «компенсировать убытки» или буду «пожизни баги фиксить». :)
Полагаю в РФ есть что-то весьма похожее, тем более что есть ГОСТ ИСО/МЭК 25041-2014. Не думаю что просто так его сделали
А вот для этого и используется «бумажка» :)
Проектная документация и инструментальная поддержка. Система отлично собирается и поддерживается годами.
Для проекта бюджетом в пару миллионов долларов, система на пару десятков тысяч долларов — фигня.
А вот косяки предовращает — на ура.
Работа со стейкхолдерами, выявление от лиц «принимаюх решение», до просто «быть информированными»
На это все есть уже отработанные «рекомендации лучших собаководов» :).
В принципе, это не часть ТЗ. Хотя может быть пункт в критериях приемки, например: функционал Fx проверяется согласно следущих тестов.
Это часть методологии приемки, которая оговаривается юридически в контракте (лучше уточнить у юристов для соответсвующей юрисдикции).
Если договора нет, то о какой оплате речь идти может?
Это и становится предметом договора.
— Клиент, Вы согласны выделить бюджет и оплатить работу Подрядчика, со следующим результатом ...? Да / Нет.
— Клиент, Вы можете использовать результат работы или с нашими разработчиками, или с устроить тендер для любых иных подрядчиков. Вам понятны Ваши возможности? Да / Нет
Присоединюсь к этому мнению.
Кто платит, тот и музыку заказывает :)
Если Клиент оплачивает риски подхода ХЗ без ТЗ — без проблем
А если перекладывает риски на Подрядчика, то это уже дело Подрядчика как делать и делать ли вообще.
Обычно предлают «MVP» — нарезать «на кусочки», которые достижимы и валидируемы, и понижают риски «просадить бабло».
А если Компания пытается сделать, проект по которому нету компетенций — то сами себе злые буратины.
Обещали построить термоядерный реактор из палок и платилина, но не смогли? Добро пожаловать «на костер» :)
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
На просьбу формализировать требования сопротивляются.
Используются технические средства типа Change Management System: Jira / TFS / EA и т.д.
Без инструментов приносящих пользу всем сторонам — так и будет развиваться :)
А если прикруть к этому систему «считать деньги и таски» — то вообще будет счастье. Можно будет получить ответ на вопрос: а зачем сделали, сколько это стоило и почему
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)
Если учесть, что результат работы БА — прояснения и непротиворечивость результат, то ребята не выполняютс свою работу :) Уволить нафиг
В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами.
Это называется НЕ техническое задание, а «техническое решение»
Фактические это архитектура системы и является результатом работы системного аналитика/архитектора.
Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это. Но поскольку это работа, и результат «осязаем» и валидируем (серия стандартов ISO 250xx) то нужно дововариваться о оплате.
Бесплатно делать такое — это безумие
Это уже проблема PreSale :)
С точки зрения финансов — составление ТЗ можно провести как отдельную услугу с оплатой.
У буржуинов это нормальная практика. Часто попадались проекты, в которых нужно было только «написать код» по «бумажкам». Да и мои SRS (технические задания) часто делали пару циклов согласования, после рецензирования, у аудиторов, которых оплачивал Клиент.
А в моем текущем проекте, пришлось уделить неделю изучению юридических нюансов, и отправлять Клиенту табличку, как пункты договора и технического задания связаны с конкретными Законами.
Почему должен платить заказчик? очень просто. Он Заинтересован.
Его интерес в следующих пунктах:
1. Клиент заинтересован в четком бюджете на проект? заинтересован.
2. Клиент заинтереован в четком понимании результат? заинтересован.
Техническое задание помогает ему достичь этих целей.
Клиент может с ТЗ пойти другому исполнителю, но у него уже будут собраны и описаны не противоречивые:
1. цели проекта
2. доменная область
3. бизнес логика
4. технические нюансы (если интеграции с другими системами)
5. критерии проверки результата.
Фактически нормально ТЗ — доказательство достижимости поставленных целей в рамках бюджета.
А есть еще и юридическая точка зрения: у Клиента есть доказательсто того, что Подрядчик его не обманет при приемке:)
Это разные документы и служат разным целям и они взаимо дополняющие.
TЗ — это что надо сделать
Функциональная спецификация — как сделать то, что указано в ТЗ
Пользователь скажет: Хочу отчет по продажам.
ТЗ будет включать:
Функциональная спецификация будет включать:
Хорошим тоном считается не брать в BackLog спринта User Story, которая не сопровождается критериями приемки.
Так что миниТЗ все равно есть.
Ключевой вопрос: откуда вы взяли ПЛАН?
Как следствие: вам сделали по ВАШЕМУ плану — постройка утонула или не выполнила ожидаемое. К кому претензии? К Вам или к строителям?
Если вы «купили» план — вы за него заплатили «тому парню», если вы сделали его сами — вы заплатили своим временем как минимум.
Заказчик платит в любом случае :)
Если Вы еще «не вынесли» мозг строителям, вам покажут пальчиком на сомнительные моменты и уточнят пару деталей — это будет бесплатно.
Но если вы «вынесли» мозг строителям — они вам сделают как «заказано», и ни одна зараза не намекнет, что марка труб у вас «тонкая и ржавеют с нашей водой» или штукатурка фиг подходит под климат или еще что…
Так и с ТЗ для клиента — адекватный, можно и соломку ему «подстелить».
Можно сказать что согласно ЗАКОНУ а можно и не говорить
У меня Закон звучит так:
Как бы я не изворачивался, но должен следовать, иначе Клиент меня просто «на органы продаст» что бы «компенсировать убытки» или буду «пожизни баги фиксить». :)
Полагаю в РФ есть что-то весьма похожее, тем более что есть ГОСТ ИСО/МЭК 25041-2014. Не думаю что просто так его сделали
Проектная документация и инструментальная поддержка. Система отлично собирается и поддерживается годами.
Для проекта бюджетом в пару миллионов долларов, система на пару десятков тысяч долларов — фигня.
А вот косяки предовращает — на ура.
На это все есть уже отработанные «рекомендации лучших собаководов» :).
Это часть методологии приемки, которая оговаривается юридически в контракте (лучше уточнить у юристов для соответсвующей юрисдикции).
Это и становится предметом договора.
— Клиент, Вы согласны выделить бюджет и оплатить работу Подрядчика, со следующим результатом ...? Да / Нет.
— Клиент, Вы можете использовать результат работы или с нашими разработчиками, или с устроить тендер для любых иных подрядчиков. Вам понятны Ваши возможности? Да / Нет
Кто платит, тот и музыку заказывает :)
Если Клиент оплачивает риски подхода ХЗ без ТЗ — без проблем
А если перекладывает риски на Подрядчика, то это уже дело Подрядчика как делать и делать ли вообще.
А если Компания пытается сделать, проект по которому нету компетенций — то сами себе злые буратины.
Обещали построить термоядерный реактор из палок и платилина, но не смогли? Добро пожаловать «на костер» :)
Используются технические средства типа Change Management System: Jira / TFS / EA и т.д.
Без инструментов приносящих пользу всем сторонам — так и будет развиваться :)
А если прикруть к этому систему «считать деньги и таски» — то вообще будет счастье. Можно будет получить ответ на вопрос: а зачем сделали, сколько это стоило и почему
Если учесть, что результат работы БА — прояснения и непротиворечивость результат, то ребята не выполняютс свою работу :) Уволить нафиг
Это называется НЕ техническое задание, а «техническое решение»
Фактические это архитектура системы и является результатом работы системного аналитика/архитектора.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это. Но поскольку это работа, и результат «осязаем» и валидируем (серия стандартов ISO 250xx) то нужно дововариваться о оплате.
Бесплатно делать такое — это безумие
Поздравляю, вы ознакомились со стадией «идентификация рисков» в управлении рисками. (ISO 31010)
Очень полезная стадия
С точки зрения финансов — составление ТЗ можно провести как отдельную услугу с оплатой.
У буржуинов это нормальная практика. Часто попадались проекты, в которых нужно было только «написать код» по «бумажкам». Да и мои SRS (технические задания) часто делали пару циклов согласования, после рецензирования, у аудиторов, которых оплачивал Клиент.
А в моем текущем проекте, пришлось уделить неделю изучению юридических нюансов, и отправлять Клиенту табличку, как пункты договора и технического задания связаны с конкретными Законами.
Его интерес в следующих пунктах:
1. Клиент заинтересован в четком бюджете на проект? заинтересован.
2. Клиент заинтереован в четком понимании результат? заинтересован.
Техническое задание помогает ему достичь этих целей.
Клиент может с ТЗ пойти другому исполнителю, но у него уже будут собраны и описаны не противоречивые:
1. цели проекта
2. доменная область
3. бизнес логика
4. технические нюансы (если интеграции с другими системами)
5. критерии проверки результата.
Фактически нормально ТЗ — доказательство достижимости поставленных целей в рамках бюджета.
А есть еще и юридическая точка зрения: у Клиента есть доказательсто того, что Подрядчик его не обманет при приемке:)