Comments 14
Для внутренних проектов — может быть.
Для проектов, где есть внешний заказчик вступает в силу более важная функция ТЗ — определение границ проекта и критериев результата.
И какой бы гуру-программист не выполнял проект он может закончиться эпик фэйлом.
Для проектов, где есть внешний заказчик вступает в силу более важная функция ТЗ — определение границ проекта и критериев результата.
И какой бы гуру-программист не выполнял проект он может закончиться эпик фэйлом.
А есть пример хорошего ТЗ для внутреннего и внешнего заказчика? Вечные споры. Наши топ-интеграторы пишут документы толстые, но слабо осмысленные, слабо связанные. Буквально приходится переписывать за них.
Для внутреннего использования обычно используем нечто похожее на смесь user story & use case, а хотелось бы более формализованный документ иметь.
Для внутреннего использования обычно используем нечто похожее на смесь user story & use case, а хотелось бы более формализованный документ иметь.
Внешние, внутренние, какая разница. Попробуйте не согласиться: есть проекты где можно легко разработать ТЗ, а есть труднее или вообще практически невозможно.
Относительно того, что ТЗ — это «соломки подстелить» для разработчиков, нельзя не согласиться, но это ж из другой оперы.
Относительно того, что ТЗ — это «соломки подстелить» для разработчиков, нельзя не согласиться, но это ж из другой оперы.
ТЗ для внешнего заказчика — это еще и способ обезопасить компанию от ненормированной работы над проектом.
Если бюджет уже определен, а ТЗ очень поверхностное, то заказчик практически до бесконечности может предъявлять «хотелки», а с поверхностным ТЗ вполне может стать, что его хотелки получаться аргументированными. Когда в ТЗ описано по максимуму, то заказчик может в минимальной степени предъявлять «хотелки» и на них можно отвечать что это не по ТЗ и брать дополнительные деньги.
Если бюджет уже определен, а ТЗ очень поверхностное, то заказчик практически до бесконечности может предъявлять «хотелки», а с поверхностным ТЗ вполне может стать, что его хотелки получаться аргументированными. Когда в ТЗ описано по максимуму, то заказчик может в минимальной степени предъявлять «хотелки» и на них можно отвечать что это не по ТЗ и брать дополнительные деньги.
Вы все правильно говорите! Но приводит ли такой подход к полной удовлетворенности заказчика? В чем заключаются отношения между заказчиком и исполнителем? В том ли, чтобы предусмотреть чтобы заказчик не перегрузил работой? Или удовлетворенность заказчика в обмен на вознаграждение исполнителю? Не является заграждение заказчика проработанным ТЗ от дополнительных требований стереотипом? А сколько времени уходит на разработку ТЗ? Кто платит за это время? А может ли заказчик так определить требования в начале проекта, чтобы выработанное на их основе ТЗ привело к удовлетворительному для него результату?
Я могу продолжать список вопросов, но топик не на эту тему. Хотя тема ТЗ очень интересная. Данная визуализация помогла мне лично понять некую взаимосвязь, которая определяет более гибкий подход к организации и управлению каждого отдельного проекта.
Я могу продолжать список вопросов, но топик не на эту тему. Хотя тема ТЗ очень интересная. Данная визуализация помогла мне лично понять некую взаимосвязь, которая определяет более гибкий подход к организации и управлению каждого отдельного проекта.
Ну чем больше времени потрачено на ТЗ, тем меньше времени разработчик тратит на код (это реально так, говорю как разработчик и человек который пишет ТЗ). Например сложная форма — если в ТЗ нет четкого описания полей и их обязательности, а только макет — перед разработчиком встает делема, он сам должен некоторые моменты додумывать. А потом заказчик предъявит претензию: почему у нас ИНН не валидируется, ФИО, не проверяется что русское и прочее и прочее? И придется еще раз вернутся и доделывать и заказчик по своему будет прав, так как явно об этом ни где не сказано. А может быть, что программист сделает все эти валидации, но они будут не нужны или даже вредны — значит разработчик потратил ценное время в пустую
А удовлетворение тоже очень важно. Только либо вы будите брать много денег, значительно выше рынка, либо работать себе в убыток. Заказчик может сколько угодно долго согласовывать дизайн, требовать перересовки, вставки «котиков» и «собачек». Вы десять раз будите перерисовывать макеты, чтобы в итоге, возможно, вернутся к первому или второму. Или вообще клиент не удовлетвориться, так как вы его «творческий» порыв не понимаете. Или все же будет удовлетворен, но вполне возможно, что вы дизайнеру заплатите больше, чем с клиента возьмете.
А удовлетворение тоже очень важно. Только либо вы будите брать много денег, значительно выше рынка, либо работать себе в убыток. Заказчик может сколько угодно долго согласовывать дизайн, требовать перересовки, вставки «котиков» и «собачек». Вы десять раз будите перерисовывать макеты, чтобы в итоге, возможно, вернутся к первому или второму. Или вообще клиент не удовлетвориться, так как вы его «творческий» порыв не понимаете. Или все же будет удовлетворен, но вполне возможно, что вы дизайнеру заплатите больше, чем с клиента возьмете.
Мой мозг, ось абсцисс не подписана, а ординат подписана аж два, намек на скрытое измерение?
Возможно, бессознательный у автора :)
Для меня концепция становится яснее если взять параметры «программист должен думать над реализацией задачи» (много и архитектурно — мало) и «программист должен думать над постановкой задачи» (не должен —должен исследовать задачу, общаться с заказчиком, выявлять требования и т. п.)
Для меня концепция становится яснее если взять параметры «программист должен думать над реализацией задачи» (много и архитектурно — мало) и «программист должен думать над постановкой задачи» (не должен —должен исследовать задачу, общаться с заказчиком, выявлять требования и т. п.)
Приведите пожалуйста пример проекта, для которого невозможно составить техническое задание.
Sign up to leave a comment.
Горизонт программного проекта