Привет всем!
Столкнулся вот с такой проблемой, есть у меня заказчики по разработке софта, разработали им что-то давно четко по ТЗ, продуктом они не пользуются особо, а через год вдруг оказывается они хотели другое, а мы как дураки не то делали... долго объясняю, показываю ТЗ и все становится на свои места, просят доработать за маленькие суммы, торгуются хитрят, через год ситуация повторяется. Вторая проблемная ситуация - тоже делаем продукт на заказ, все строго по ТЗ, сдаем, а оказывается что мы не доработали так как заказчик думал что будет дополнительный функционал, которого не было в ТЗ, но он как бы само собой разумеющееся) работы не много, договариваемся доделать, ждем правок неделю, в итоге проходит уже два с половиной месяца, от заказчика только обещания.
Вопрос заключается в том, как не конфликтно расстаться с такими заказчиками? Отношения с ними хороше, дружеское... Но ведь такие этим и пользуются и только отнимают самый ценный ресурс - время, тратят нервы, не приносят прибыли, не дают развиваться и вырасти в компанию.

Garya,

ТЗ пишем совместно или мы

К себе всегда требовательно относимся - наша работа это наше лицо! наверно из-за этого некоторые заказчики стараются и сесть на шею

_nautilus_,

1- как понять ТЗ постфактум? заказчик приходит и говорит "хочу вот это сколько будет стоить, хочу знать точную и конечную цену"
для этого и пишется ТЗ, полностью согласовывается с заказчиком и считается цена.

2- как быть если в ТЗ не были предусмотрены некоторые вещи которые существенно влияют на время разработки, виноваты собственно оба и мы и заказчик, мы считали время и стоимость из ТЗ, а тут придется еще поработать. В большинстве случаях договариваемся и нам оплачивают, в некоторых заказчик упирается рогами, что этот функционал должен быть по умолчанию, как быть во втором случае и как себя вести с ним, кто тут виноват получается и нужно ли такие случаи оплачивать нам?

_nautilus_
Вы в первом посте описываете споры не по цене, а по функционалу. Если у заказчика нет опыта работы по ТЗ, ему это ТЗ ничего не скажет, он и смотреть туда в большинстве случаев не станет. Плясать четко от ТЗ имеет смысл, когда заказчик уже в теме если не всего процесса разработки, то хотя бы сбора требований и внедрения. Когда у него перед глазами уже работающая система и он сам может формализовать требования по доработкам, которые будут реализованы в рамках нового договора.

Стараемся сделать максимально четкое ТЗ, на понятном "русском языке" для заказчика. Описывает как будет работать система, какие функции выполнять и тд. Проговариваем с заказчиком все. Он должен понимать за что платить и что в итоге получает. После таких обсуждений заказчик четко понимает что такое ТЗ, объем работы и как рождается цена)))

_nautilus_Что конкретно вы имеете в виду? Например посчитали, что на какую-то функцию нужно две недели, а оказалось, что три месяца? Тогда при чем здесь заказчик?
К примеру вещи которые были очевидны для заказчика, но про них вообще ни где и ни когда не упоминалось, а по завершению работы и сдачи проекта, выяснилось что мы их не сделали. А сделать их не пять минут, а как раз таки с недельку бесплатного труда. Собственно это не обсуждалось и на эти функции время в работу не закладывалось

Garyayardie_nautilus_,

1- как понять ТЗ постфактум? заказчик приходит и говорит "хочу вот это сколько будет стоить, хочу знать точную и конечную цену"
для этого и пишется ТЗ, полностью согласовывается с заказчиком и считается цена.

2- как быть если в ТЗ не были предусмотрены некоторые вещи которые существенно влияют на время разработки, виноваты собственно оба и мы и заказчик, мы считали время и стоимость из ТЗ, а тут придется еще поработать. В большинстве случаях договариваемся и нам оплачивают, в некоторых заказчик упирается рогами, что этот функционал должен быть по умолчанию, как быть во втором случае и как себя вести с ним, кто тут виноват получается и нужно ли такие случаи оплачивать нам?Уж сколько я этих ТЗ за свою жизнь наваял... Перед написанием ТЗ обычно проводится обследование. И вот на этом этапе важно не только вопросы задавать, но побеседовать с заказчиком по душам. Заказчики обычно догадываются о том, что и как в принципе можно сделать лишь на треть. Не имея опыта в автоматизации, обычные заказчики не представляют, с какими проблемами они могут столкнуться. А также о том, какие возможности перед ними могут открыться в том или ином случае.
Когда я работал со своими заказчиками, я старался выяснить не только то, что хочет заказчик, но и то, что он, в принципе, может захотеть в будущем. А для этого нужно обсуждать и видеть не только функционал приложения, но и достоинства и недостатки используемых методов управления, специфики бизнес-процессов. Самому заранее озвучивать заказчику те вопросы, которыми он не догадался озадачиться. И решать вопросы не только в ракурсе "какой функционал ПО вам нужен?", но и в ракурсе "что в принципе можно изменить и улучшить в методах управления и взаимодействия?", чтобы заказчик получил не только то, что он хочет, но и гораздо больше - то, что он еще не успел захотеть, но бизнес-аналитик уже угадал, что он захочет потом.

Когда выяснялось, что заказчик всё-таки что-то захотел такое, о чем я не смог заранее догадаться, я корил обычно не заказчика, а себя. Пытался понять, что такое я не смог предвидеть, где не доработал, и что нужно учесть на будущее. Однако, это происходило очень и очень редко.

Мои заказчики обычно были очень довольны сотрудничеством со мной именно потому, что я им озвучивал то, что они в принципе могут захотеть, задолго до того, как они сами успели это сделать. Я полагаю, хороший бизнес-аналитик должен уметь это делать и хотеть это делать - вот именно так.

Как правильно делать - тут трудно с вами поспорить.
Но все же и как вы писали и вообще в жижни особенно в сложных проектах, бывают ситуации в которых все не учтешь. Это может быть очень узкая и сложная специфика, все знать и учесть невозможно. То как быть в таких ситуациях? как объяснять заказчику что не учли потому что не учли, не згали, не подрасчитали? Брать все насебя и тащить как лошадь - тоже не вариант...