Pull to refresh

Comments 8

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

А визуализация требований — прототип — позволяют клиенту включиться в постановку задачи, и начать понимать (заранее), что именно он получит.
Подождите, во-первых, прототип — это уже существенные затраты с точки зрения подрядчика.
Во-вторых, если ПО по тендеру, то там вы вообще не можете сделать и показать прототип.

P.S. понимает/не понимает — это отдельная тема. Заказчик может понимать/не понимать как с ТЗ, так и без него.
Если прототип пользовательских интерфейсов требует значительных затрат, значит это не прототип, а нечто существенно большее.

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

Что такое «ПО по тендеру»?

Мы выиграли несколько тендеров тем, что визуально показали наши идеи, помимо основной заявки на участие в конкурсе.

Если Заказчик не понимает — жди беды!
Я сейчас не про пользовательские интерфейсы. По большей части заказчикам пофиг как будет выглядеть приложение (это конечно тема для отдельного разговора), им важно чтобы была реализована бизнес-логика.

Именно реализацию бизнес-логики (и вообще логики) и надо защищать ТЗ.

>Мы выиграли несколько тендеров тем, что визуально показали наши идеи, помимо основной заявки на участие в конкурсе.

Видимо это были не гос тендеры :) Там до тендера нельзя пообщаться с заказчиком. А на самом представлении оцениваются обычно всего 4 параметра, никак не относящиеся к продукту.
Я понял. Да, бывает и такое. Но в этом случае логику лучше тоже визуализировать — показывать диаграммы, а не писать текст. Или если текст так уж нужен, пусть он будет дополнительным, а не основным каналом коммуникации.

Защищайте диаграммы, а не текст! :)

Да, мы пока не работали на государство напрямую. Но в описанном случае мы партизанскими методами получили доступ к системе (никто его нам специально не предоставлял).

Поняли, что в ней не так, и сослались на это в своем предложении. Наша прыть произвела неимоверный эффект :) Мы, кажется, были не самыми дешевыми подрядчиками, но клиент поверил, что мы сделаем все правильно. И кажется, он не ошибся. По крайней мере, он уже пару раз рекомендовал нас другим.
Ну да. Я со всем согласен. Просто опыт подсказывает что понимает клиента — это одно, а ТЗ — это совсем другое. Обязанность подрядчика синхронизировать эти две вещи на этапе инициации проекта.

Просто это следуюет даже из методологии ведения проектов: чтобы в конце проекта понять достигли мы успеха или нет, надо знать о поставленных целях. Поствавленные цели описаны в ТЗ.

p.s. спасибо за вебинар.
Sign up to leave a comment.