Комментарии 7
Вы слишком много внимание уделяете наивности и неумению заказчика составлять ТЗ.
Если заказчик не умеет писать ТЗ — это не значит, что заказчик плохой. Это значит, что его придется писать вам.
Да, составление ТЗ — это тоже работа, и многие заказчики этого не понимают/не хотят понимать (читай — оплачивать).
Но тут уж вы сами решаете, каким путем идти: убедить заказчика включить составление ТЗ как отдельный оплачиваемый пункт договора, заранее закладывать стоимость ТЗ в стоимость разработки или какой-либо другой вариант.
Если заказчик не умеет писать ТЗ — это не значит, что заказчик плохой. Это значит, что его придется писать вам.
Да, составление ТЗ — это тоже работа, и многие заказчики этого не понимают/не хотят понимать (читай — оплачивать).
Но тут уж вы сами решаете, каким путем идти: убедить заказчика включить составление ТЗ как отдельный оплачиваемый пункт договора, заранее закладывать стоимость ТЗ в стоимость разработки или какой-либо другой вариант.
Заказчик уверен что уже имеет ТЗ (он уже оплатил его). Заказчик сейчас хороший. Потом будет недовольным.
Как следует из опроса, бОльшая часть читателей готова с работать с таким ТЗ. Тут уж каждый выбирает для себя…
Как следует из опроса, бОльшая часть читателей готова с работать с таким ТЗ. Тут уж каждый выбирает для себя…
Скажите, вы примеры ТЗ выдумали, или это реальные документы?
Мне еще ни разу не приходилось сталкиваться, чтобы в ТЗ были пункты «создать поле в базе», обычно ТЗ содержит бизнес-требования, а в каких полях все там будет храниться — остается «под капотом».
Ну да ладно, предположим, заказчик действительно хочет получить поле «возраст ребенка» и ничего не хочет слушать. Не вопрос, добавляю поле «дата рождения», делаю ему вычисляемое поле «возраст», и все счастливы.
Понятно, что наличие такого ТЗ — это «тревожный звоночек», но никак не критерий того, чтобы сходу отказываться.
Мне еще ни разу не приходилось сталкиваться, чтобы в ТЗ были пункты «создать поле в базе», обычно ТЗ содержит бизнес-требования, а в каких полях все там будет храниться — остается «под капотом».
Ну да ладно, предположим, заказчик действительно хочет получить поле «возраст ребенка» и ничего не хочет слушать. Не вопрос, добавляю поле «дата рождения», делаю ему вычисляемое поле «возраст», и все счастливы.
Понятно, что наличие такого ТЗ — это «тревожный звоночек», но никак не критерий того, чтобы сходу отказываться.
К сожалению, это реальные документы, за которые заказчик заплатил деньги, и на основании которых формирует бюджет и сроки исполнения. И было бы там написано «Обеспечить ввод и хранение контактных данных клиента с приоритетами устанавливаемыми клиентом» — я бы слова не сказал. Собрал бы требования, согласовал, реализовал.
Возраст ребенка — это цветочки. Имя кошки — одно поле. Имя собаки — другое. Вопросы, что делать если у клиента заказчика несколько кошек или, например, крокодил, я уже не задавал. Хотя наличие опасного животного — существенно и влияет на бизнес заказчика.
Согласен, это не единственный критерий. Но я посмотрел не только ТЗ. Мой диагноз — в рамках бюджета и сроков не взлетит. Ожидать начало разбора полетов чтобы испортить отношения с заказчиком я не вижу смысла. Пока мы расстались, как уважающие друг друга люди. И этот отказ никак не повлияет на возможные заказы с его стороны в будущем.
Возраст ребенка — это цветочки. Имя кошки — одно поле. Имя собаки — другое. Вопросы, что делать если у клиента заказчика несколько кошек или, например, крокодил, я уже не задавал. Хотя наличие опасного животного — существенно и влияет на бизнес заказчика.
Согласен, это не единственный критерий. Но я посмотрел не только ТЗ. Мой диагноз — в рамках бюджета и сроков не взлетит. Ожидать начало разбора полетов чтобы испортить отношения с заказчиком я не вижу смысла. Пока мы расстались, как уважающие друг друга люди. И этот отказ никак не повлияет на возможные заказы с его стороны в будущем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фрилансеру на заметку: правила работы с заказчиками