Comments 29
Огромнвй плюс ТЗ в том, что оно позволяет избежать инсинуаций со стороны заказчика на тему «а давайте попробуем еще вот так» или «мы (всегда умеляет в такой постановке вопроса вовлечение исполниьеля, не Я, но МЫ), итак, мы забыли с вами об одной важной вещи, давайте доделаем и сразу рассчитаемся».
Больше всего мне нравится «мы», ага: )
В договор нужно включать что-то вроде «Заказчик вправе изменить объём работ в рамках 10% как в большую, так и в меньшую сторону. В данном случае оценку объёма работ осуществляет Исполнитель. Оплата производится пропорционально выполненному объёму работ, в пересчёте от изначально согласованного. Исполнитель вправе назначить новый срок исполнения работ».
Как говорилось в одной хорошей книге, в таком случае хорошим ответом будет: «Ок, давайте тогда мы посчитаем смету для таких изменений». Это отлично остужает порывы внесения изменений после согласования ТЗ.
Наличие ТЗ практически не снимает рисков, связанных с отступлением от него и бесконечным произволом заказчика в виде постоянных изменений требований на определенных проектах. Кто работал на гос сектор — поймет меня.
Предполагаю, проблема государственного сектора в том, что в договоре трудно установить нормальные условия (изменение требований, в частности) для исполнителя — из-за фиксированных форм и отчетности.
Ну и БЮРОКРАТИЯ, конечно же, куда без неё.
Кстати, проблема актуальна и для коммерческих фирм, которые отдают работы на сторону по тендерам.
Ну и БЮРОКРАТИЯ, конечно же, куда без неё.
Кстати, проблема актуальна и для коммерческих фирм, которые отдают работы на сторону по тендерам.
Почему «ТЗ интерфейса»? Проблема с следованию ТЗ, так же как его написания — это общая проблема, и не имеет значения, речь идёт о том, как обрабатываются коды ошибок или как выглядит кнопка.
Главная проблема — ТЗ не документ для «заказчика». Те, кто просит проверить ТЗ заказчику и согласиться с ним, напоминают врача, который предлагает схему лечения (с рискованными инвазивными операциями) и просит подписать согласие, предполагая в случае чего «но вы же сами прочитали».
Умение читать ТЗ (в смысле, анализировать его на выполнимость и разумность того, что получится) — искусство, сравнимое с его написанием.
Главная проблема — ТЗ не документ для «заказчика». Те, кто просит проверить ТЗ заказчику и согласиться с ним, напоминают врача, который предлагает схему лечения (с рискованными инвазивными операциями) и просит подписать согласие, предполагая в случае чего «но вы же сами прочитали».
Умение читать ТЗ (в смысле, анализировать его на выполнимость и разумность того, что получится) — искусство, сравнимое с его написанием.
amarao, спасибо за комментарий, действительно, ТЗ — не воспринимается как документ, которому желательно следовать.
Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).
Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».
Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.
И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.
+1 — по поводу «проверить ТЗ» — это попахивает садизмом: "ПрокомментируйРаскритикуй же меня, разработка!".
Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).
Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».
Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.
И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.
+1 — по поводу «проверить ТЗ» — это попахивает садизмом: "
>ТЗ — не воспринимается как документ, которому желательно следовать.
Не всё так однозначно. Мне приходилось делать такой жуткий интерфейс. С нелепыми действиями, с лишними кликами. Даже ведущий был согласен со мной, что реализовывать интерфейс по такому ТЗ не следует. Но ТЗ такое ТЗ. Всё было задокументировано и принято. Спасали некоторые пробелы, которые не были оговорены в ТЗ и которые я сделал по-своему.
Не всё так однозначно. Мне приходилось делать такой жуткий интерфейс. С нелепыми действиями, с лишними кликами. Даже ведущий был согласен со мной, что реализовывать интерфейс по такому ТЗ не следует. Но ТЗ такое ТЗ. Всё было задокументировано и принято. Спасали некоторые пробелы, которые не были оговорены в ТЗ и которые я сделал по-своему.
Не стала писать «надо следовать», написала «желательно».
К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.
Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.
Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
А можно где нибудь посмотреть действительно клёвое и правильное ТЗ/Спецификацию на разработку интерфейса?
Это фантастика
UFO just landed and posted this here
Мне кажется, что идеального ТЗ на интерфейс «под всех» — не может существовать.
Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
UFO just landed and posted this here
Поясните, пожалуйста, о какой методологии разработки Вы пишете?
Мне кажется Вы иногда смешиваете стадию постановки задачи, стадию проектирования и стадию внедрения. Если говорить обо всём этом, то полезно было бы упомянуть Технический проект и Программу и методику испытаний. Последний документ как раз и следует применять при проверке системы перед/при внедрении.
Мне кажется Вы иногда смешиваете стадию постановки задачи, стадию проектирования и стадию внедрения. Если говорить обо всём этом, то полезно было бы упомянуть Технический проект и Программу и методику испытаний. Последний документ как раз и следует применять при проверке системы перед/при внедрении.
Я не пишу о методологии, как таковой.
Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.
Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.
И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.
Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.
И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
Мы работаем много лет с крупной государственной компанией, и наше «бумажное» внешнее взаимодействие определяется древним 34-м ГОСТ-ом. Преимущества и недостатки такого подхода давайте оставим за скобками, но в ГОСТе определён такой документ: Программа и методика испытаний (ПМИ). Фактически, это сценарии испытаний продукта. Наверняка, вы пользуетесь одной из Agile-методологий, но в них тоже практикуются проектные документы и сценарии тестирования.
А о методологии Вы пишете косвенно. И здесь мне не всё ясно. Поэтому и попросил пояснить. Есть ли у вас проектная документация?
Фиксируете ли вы проектные решения на бумаге, в виде макетов, ещё как-то? Согласовываете ли это с заказчиком?
ИМХО неправильно рассматривать «требования» разработчика в ТЗ. ТЗ не проектный документ. Это постановка задачи. Определение набора требуемых к реализации функций, условий. Этот документ порождается в начальной фазе. Конечно, продвинутые разработчики могут принимать участие в формулировании концепции и проектного решения, и для этого должны быть знакомы с ТЗ. Но рядового разработчика интересует другая задача: не поставленная заказчиком (большая и общая), а поставленная начальником (короткая и конкретная в рамках итерации, например).
По прочтении Вашей статьи, у меня сложилось мнение, что Вы, скорее, пишете о Технорабочем проекте — документе (-ах), отражающем и функции и их реализацию.
Хотя, наверное, зря я докапываюсь :). На сколько я понял, Вы несколько упростили процесс и у вас нет фазы ТЗ и фазы ТП (Технический проект). Вы сразу формулируете и согласовываете один документ, отражающий постановку задачи и технические решения. И когда-нибудь «сильно потОм» отдадите это разработчикам. Видимо, меня ввело в заблуждение слово ТЗ. Строго говоря, это не ТЗ, но вариант вполне рабочий. У нас такое не пройдёт из-за требований заказчика, но это сугубо наша проблема.
Пожалуй, в ближайшее время поделюсь своим опытом в блоге. Это тема не комментария, а, наверное, статьи и отдельного обсуждения. Мне будет очень интересно хабрамнение.
А о методологии Вы пишете косвенно. И здесь мне не всё ясно. Поэтому и попросил пояснить. Есть ли у вас проектная документация?
Фиксируете ли вы проектные решения на бумаге, в виде макетов, ещё как-то? Согласовываете ли это с заказчиком?
ИМХО неправильно рассматривать «требования» разработчика в ТЗ. ТЗ не проектный документ. Это постановка задачи. Определение набора требуемых к реализации функций, условий. Этот документ порождается в начальной фазе. Конечно, продвинутые разработчики могут принимать участие в формулировании концепции и проектного решения, и для этого должны быть знакомы с ТЗ. Но рядового разработчика интересует другая задача: не поставленная заказчиком (большая и общая), а поставленная начальником (короткая и конкретная в рамках итерации, например).
По прочтении Вашей статьи, у меня сложилось мнение, что Вы, скорее, пишете о Технорабочем проекте — документе (-ах), отражающем и функции и их реализацию.
Хотя, наверное, зря я докапываюсь :). На сколько я понял, Вы несколько упростили процесс и у вас нет фазы ТЗ и фазы ТП (Технический проект). Вы сразу формулируете и согласовываете один документ, отражающий постановку задачи и технические решения. И когда-нибудь «сильно потОм» отдадите это разработчикам. Видимо, меня ввело в заблуждение слово ТЗ. Строго говоря, это не ТЗ, но вариант вполне рабочий. У нас такое не пройдёт из-за требований заказчика, но это сугубо наша проблема.
Пожалуй, в ближайшее время поделюсь своим опытом в блоге. Это тема не комментария, а, наверное, статьи и отдельного обсуждения. Мне будет очень интересно хабрамнение.
:( а где «боевые» случаи? коварные истории? картинки было-стало?
>Профит: разработчик более вовлечен и мотивирован: ему надо просто предупредить исполнителей о том, что неприменимо в новом (или измененном) интерфейсе, на его взгляд и по его опыту.
По-моему, стоит выделить слово «что», а не «неприменимо».
Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?
С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
По-моему, стоит выделить слово «что», а не «неприменимо».
Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?
С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
Занимаюсь разработкой интерфейсов: те дизайн юзабилити и реализация в реальных проектах (WPF и CSS)
И вот мое мнение — невозможно составить тз на интерфейс так что оно будет учитывать все аспекты и нюансы.
Всегда получившееся приложение(четко по ТЗ) и его вариант «на бумаге» — это две разные вещи.
Причина проста:
Приложение — оно живое, динамическое, масштабируемое…
Бумага — она мертвая, статическая, с физическими размерами…
Сейчас я работаю в основном без ТЗ, делаю немного по другому.
1) составляем бриф на дизайн и юзабилити вместе с заказчиком
2) делаем оценку стоимости дизайна и юзабилити (приблизительно творческую работу никогда нельзя оценить временем), кроме того юзабилити надо заниматься уже на этапе дизайна, иначе потом может быть поздно. В смете так же указываем и некоторые важные детали как что-то сложное будет реализовано и почему.
3) рисуем, согласовываем, снова рисуем, дорисовываем, думаем над юзабилити, снова рисуем… пока не добьемся True интерфейса на бумаге.
4) после согласования интерфейса на бумаге, делаем оценку сроков и стоимости реализации его в реальном приложении, тк мы сами проектировали интерфейс, ТЗ нам не особо нужно, документ составляем только один — смету, по ней же и осуществляем сдачу/приемку работ по пунктам в смете., те если какого-то окна нет в смете — заказчик не вправе требовать его добавить.
этот этап довольно сложный, оценить время тут сложно хоть с тз хоть без него.
5) Реализовываем интерфейс…
И вот тут то начинается самое интересное, не всегда то — что мы придумали на бумаге, в реальности удобно (много факторов на это влияют, например тормоза железа или сервера, анимация режет глаз, невозможность выполнить новые задумки из-за ограничений платформы, и тд и тп)
Кроме того, все это не всегда красиво, бывает очень красивый интерфейс — как картинка — просто супер, но вот как реальное приложение — ляпист, нелеп, мерцает на состояниях мыши или мелок для пальца заказчика на сенсоре (на картинке не каждый заказчик это все поймет)
И поэтому, тут также привлекается дизайнер и юзабилист, чтобы… менять интерфейс прямо на ходу (естественно не целиком и полностью а некоторые мелочи как правило)
Все в разы интереснее, если заказчик приходит со своим ТЗ и дизайном… Тут как правило очень часто идет под нож и дизайн и ТЗ, хорошо если заказчик понимает замечание еще до начала реализации верстки XAML или CSS после моего беглого но зоркого взгляда выявившего массу нюансов и недочетов в дизайне и ТЗ, но если уперт — потом либо получает каку по ТЗ, либо платит дважды за перерисовку и переверстку.
Так что следовать ТЗ на интерфейс целиком и полностью — это глобальная ошибка, всех нюансов не учесть на бумажке. Когда это все заработает и задвигается — всплывает столько неучтенных мелочей, что иногда за голову можно схватиться (собственно поэтому не забывайте накидывать 25% на высчитанное время реализации)
И вот мое мнение — невозможно составить тз на интерфейс так что оно будет учитывать все аспекты и нюансы.
Всегда получившееся приложение(четко по ТЗ) и его вариант «на бумаге» — это две разные вещи.
Причина проста:
Приложение — оно живое, динамическое, масштабируемое…
Бумага — она мертвая, статическая, с физическими размерами…
Сейчас я работаю в основном без ТЗ, делаю немного по другому.
1) составляем бриф на дизайн и юзабилити вместе с заказчиком
2) делаем оценку стоимости дизайна и юзабилити (приблизительно творческую работу никогда нельзя оценить временем), кроме того юзабилити надо заниматься уже на этапе дизайна, иначе потом может быть поздно. В смете так же указываем и некоторые важные детали как что-то сложное будет реализовано и почему.
3) рисуем, согласовываем, снова рисуем, дорисовываем, думаем над юзабилити, снова рисуем… пока не добьемся True интерфейса на бумаге.
4) после согласования интерфейса на бумаге, делаем оценку сроков и стоимости реализации его в реальном приложении, тк мы сами проектировали интерфейс, ТЗ нам не особо нужно, документ составляем только один — смету, по ней же и осуществляем сдачу/приемку работ по пунктам в смете., те если какого-то окна нет в смете — заказчик не вправе требовать его добавить.
этот этап довольно сложный, оценить время тут сложно хоть с тз хоть без него.
5) Реализовываем интерфейс…
И вот тут то начинается самое интересное, не всегда то — что мы придумали на бумаге, в реальности удобно (много факторов на это влияют, например тормоза железа или сервера, анимация режет глаз, невозможность выполнить новые задумки из-за ограничений платформы, и тд и тп)
Кроме того, все это не всегда красиво, бывает очень красивый интерфейс — как картинка — просто супер, но вот как реальное приложение — ляпист, нелеп, мерцает на состояниях мыши или мелок для пальца заказчика на сенсоре (на картинке не каждый заказчик это все поймет)
И поэтому, тут также привлекается дизайнер и юзабилист, чтобы… менять интерфейс прямо на ходу (естественно не целиком и полностью а некоторые мелочи как правило)
Все в разы интереснее, если заказчик приходит со своим ТЗ и дизайном… Тут как правило очень часто идет под нож и дизайн и ТЗ, хорошо если заказчик понимает замечание еще до начала реализации верстки XAML или CSS после моего беглого но зоркого взгляда выявившего массу нюансов и недочетов в дизайне и ТЗ, но если уперт — потом либо получает каку по ТЗ, либо платит дважды за перерисовку и переверстку.
Так что следовать ТЗ на интерфейс целиком и полностью — это глобальная ошибка, всех нюансов не учесть на бумажке. Когда это все заработает и задвигается — всплывает столько неучтенных мелочей, что иногда за голову можно схватиться (собственно поэтому не забывайте накидывать 25% на высчитанное время реализации)
ТЗ передать можно просто на бумажке, а можно с динамическим прототипом.
Умышленно не писала про прототипы, так как проблема единая.
Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)
Умышленно не писала про прототипы, так как проблема единая.
Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)
Sign up to leave a comment.
А зачем мне ТЗ? Я и так знаю!