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