Comments 29
Огромнвй плюс ТЗ в том, что оно позволяет избежать инсинуаций со стороны заказчика на тему «а давайте попробуем еще вот так» или «мы (всегда умеляет в такой постановке вопроса вовлечение исполниьеля, не Я, но МЫ), итак, мы забыли с вами об одной важной вещи, давайте доделаем и сразу рассчитаемся».
Это похоже на моральное давление. Что-то вроде попытки навязать чувство вины…
В договор нужно включать что-то вроде «Заказчик вправе изменить объём работ в рамках 10% как в большую, так и в меньшую сторону. В данном случае оценку объёма работ осуществляет Исполнитель. Оплата производится пропорционально выполненному объёму работ, в пересчёте от изначально согласованного. Исполнитель вправе назначить новый срок исполнения работ».
Как говорилось в одной хорошей книге, в таком случае хорошим ответом будет: «Ок, давайте тогда мы посчитаем смету для таких изменений». Это отлично остужает порывы внесения изменений после согласования ТЗ.
Наличие ТЗ практически не снимает рисков, связанных с отступлением от него и бесконечным произволом заказчика в виде постоянных изменений требований на определенных проектах. Кто работал на гос сектор — поймет меня.
Предполагаю, проблема государственного сектора в том, что в договоре трудно установить нормальные условия (изменение требований, в частности) для исполнителя — из-за фиксированных форм и отчетности.

Ну и БЮРОКРАТИЯ, конечно же, куда без неё.

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

Главная проблема — ТЗ не документ для «заказчика». Те, кто просит проверить ТЗ заказчику и согласиться с ним, напоминают врача, который предлагает схему лечения (с рискованными инвазивными операциями) и просит подписать согласие, предполагая в случае чего «но вы же сами прочитали».

Умение читать ТЗ (в смысле, анализировать его на выполнимость и разумность того, что получится) — искусство, сравнимое с его написанием.

amarao, спасибо за комментарий, действительно, ТЗ — не воспринимается как документ, которому желательно следовать.

Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).

Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».

Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.

И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.

+1 — по поводу «проверить ТЗ» — это попахивает садизмом: "ПрокомментируйРаскритикуй же меня, разработка!".
>ТЗ — не воспринимается как документ, которому желательно следовать.

Не всё так однозначно. Мне приходилось делать такой жуткий интерфейс. С нелепыми действиями, с лишними кликами. Даже ведущий был согласен со мной, что реализовывать интерфейс по такому ТЗ не следует. Но ТЗ такое ТЗ. Всё было задокументировано и принято. Спасали некоторые пробелы, которые не были оговорены в ТЗ и которые я сделал по-своему.
Не стала писать «надо следовать», написала «желательно».

К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.

Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
А можно где нибудь посмотреть действительно клёвое и правильное ТЗ/Спецификацию на разработку интерфейса?
UFO landed and left these words here
Мне кажется, что идеального ТЗ на интерфейс «под всех» — не может существовать.
Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
UFO landed and left these words here
UFO landed and left these words here
Чем больше детализация — тем больше шанс того, что ему будут бездумно следовать, исполняя каждую деталь.
Это риск для конечного пользователя (вдруг что-то можно сделать лучше, чем было на момент написания такого детального ТЗ).
UFO landed and left these words here
Прав, очень прав.
Хочется, чтобы разработка принимала участие, от которого получится тот самый профит, на этапе создания ТЗ.
Мне снять розовые очки?)
UFO landed and left these words here
Поясните, пожалуйста, о какой методологии разработки Вы пишете?
Мне кажется Вы иногда смешиваете стадию постановки задачи, стадию проектирования и стадию внедрения. Если говорить обо всём этом, то полезно было бы упомянуть Технический проект и Программу и методику испытаний. Последний документ как раз и следует применять при проверке системы перед/при внедрении.
Я не пишу о методологии, как таковой.
Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.

Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.

И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
Мы работаем много лет с крупной государственной компанией, и наше «бумажное» внешнее взаимодействие определяется древним 34-м ГОСТ-ом. Преимущества и недостатки такого подхода давайте оставим за скобками, но в ГОСТе определён такой документ: Программа и методика испытаний (ПМИ). Фактически, это сценарии испытаний продукта. Наверняка, вы пользуетесь одной из Agile-методологий, но в них тоже практикуются проектные документы и сценарии тестирования.

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

Хотя, наверное, зря я докапываюсь :). На сколько я понял, Вы несколько упростили процесс и у вас нет фазы ТЗ и фазы ТП (Технический проект). Вы сразу формулируете и согласовываете один документ, отражающий постановку задачи и технические решения. И когда-нибудь «сильно потОм» отдадите это разработчикам. Видимо, меня ввело в заблуждение слово ТЗ. Строго говоря, это не ТЗ, но вариант вполне рабочий. У нас такое не пройдёт из-за требований заказчика, но это сугубо наша проблема.

Пожалуй, в ближайшее время поделюсь своим опытом в блоге. Это тема не комментария, а, наверное, статьи и отдельного обсуждения. Мне будет очень интересно хабрамнение.
>Профит: разработчик более вовлечен и мотивирован: ему надо просто предупредить исполнителей о том, что неприменимо в новом (или измененном) интерфейсе, на его взгляд и по его опыту.

По-моему, стоит выделить слово «что», а не «неприменимо».

Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?

С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
Занимаюсь разработкой интерфейсов: те дизайн юзабилити и реализация в реальных проектах (WPF и CSS)
И вот мое мнение — невозможно составить тз на интерфейс так что оно будет учитывать все аспекты и нюансы.
Всегда получившееся приложение(четко по ТЗ) и его вариант «на бумаге» — это две разные вещи.
Причина проста:
Приложение — оно живое, динамическое, масштабируемое…
Бумага — она мертвая, статическая, с физическими размерами…

Сейчас я работаю в основном без ТЗ, делаю немного по другому.
1) составляем бриф на дизайн и юзабилити вместе с заказчиком
2) делаем оценку стоимости дизайна и юзабилити (приблизительно творческую работу никогда нельзя оценить временем), кроме того юзабилити надо заниматься уже на этапе дизайна, иначе потом может быть поздно. В смете так же указываем и некоторые важные детали как что-то сложное будет реализовано и почему.
3) рисуем, согласовываем, снова рисуем, дорисовываем, думаем над юзабилити, снова рисуем… пока не добьемся True интерфейса на бумаге.
4) после согласования интерфейса на бумаге, делаем оценку сроков и стоимости реализации его в реальном приложении, тк мы сами проектировали интерфейс, ТЗ нам не особо нужно, документ составляем только один — смету, по ней же и осуществляем сдачу/приемку работ по пунктам в смете., те если какого-то окна нет в смете — заказчик не вправе требовать его добавить.
этот этап довольно сложный, оценить время тут сложно хоть с тз хоть без него.
5) Реализовываем интерфейс…
И вот тут то начинается самое интересное, не всегда то — что мы придумали на бумаге, в реальности удобно (много факторов на это влияют, например тормоза железа или сервера, анимация режет глаз, невозможность выполнить новые задумки из-за ограничений платформы, и тд и тп)
Кроме того, все это не всегда красиво, бывает очень красивый интерфейс — как картинка — просто супер, но вот как реальное приложение — ляпист, нелеп, мерцает на состояниях мыши или мелок для пальца заказчика на сенсоре (на картинке не каждый заказчик это все поймет)
И поэтому, тут также привлекается дизайнер и юзабилист, чтобы… менять интерфейс прямо на ходу (естественно не целиком и полностью а некоторые мелочи как правило)

Все в разы интереснее, если заказчик приходит со своим ТЗ и дизайном… Тут как правило очень часто идет под нож и дизайн и ТЗ, хорошо если заказчик понимает замечание еще до начала реализации верстки XAML или CSS после моего беглого но зоркого взгляда выявившего массу нюансов и недочетов в дизайне и ТЗ, но если уперт — потом либо получает каку по ТЗ, либо платит дважды за перерисовку и переверстку.

Так что следовать ТЗ на интерфейс целиком и полностью — это глобальная ошибка, всех нюансов не учесть на бумажке. Когда это все заработает и задвигается — всплывает столько неучтенных мелочей, что иногда за голову можно схватиться (собственно поэтому не забывайте накидывать 25% на высчитанное время реализации)
ТЗ передать можно просто на бумажке, а можно с динамическим прототипом.
Умышленно не писала про прототипы, так как проблема единая.

Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)
Only those users with full accounts are able to leave comments. Log in, please.