Тз это точка зрения и у нас их несколько

Материал из CustisWiki

Наш генеральный директор Владимир Рахтеенко рассказал журналу «Секрет фирмы» о причинах непонимания между заказчиками и исполнителями и способах его эффективного устранения. В чем заключаются причины неудач и конфликтов между клиентом и поставщиком? Что представляет собой истинная коммуникация, как ее правильно выстроить? Какие принципы могут помочь в переговорах с контрагентом? Об этом — в материале «Почему исполнители и заказчики не слышат друг друга» на сайте издания.

— Но вы же утвердили техническое задание?! — Техническое задание? Мы думали, ТЗ — это «точка зрения», и у нас их несколько.

Всю свою сознательную жизнь я работаю в сфере информационных технологий, а последние 20 лет возглавляю собственный бизнес по ИТ-консалтингу и разработке ПО. Я сделал сам и повидал немало проектов автоматизации в крупнейших компаниях страны, поэтому могу с уверенностью сказать, что причина большей части неудач и конфликтов между ИТ-специалистами и бизнес-заказчиками — неумение сторон слушать, слышать, понимать, «влезать в шкуру» партнера или клиента, искать решения, а не доказывать свою правоту. В общем, неумение выстраивать коммуникацию.

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

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

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

Сначала о том, что такое коммуникация в ее истинном смысле и в каких ситуациях она действительно важна. Это, конечно, бесконечно сложный философский, социальный и психологический вопрос, но если коротко, то истинная коммуникация в моем понимании — это процесс совместного порождения нового содержания равноправными партнерами. Через выстраивание общего смыслового поля и постепенное взаимное обогащение картин мира друг друга партнеры движутся к совместной цели, создавая что-то новое.

• Коммуникация — это не бытовой разговор, не дружеская беседа. В таких форматах общения вам вполне достаточно выговориться и не обязательно до конца понимать друг друга, а уж тем более порождать новые смыслы. Коммуникация же нужна там, где есть совместная деятельность, порождение чего-то нового, где взаимопонимание необходимо для достижения результата.
• Не генерация идей. Коммуникации всегда подразумевают ответственность сторон, причем четко определенную. Многие совещания и групповые обсуждения проходили бы в компаниях совсем иначе, если бы коллегам пришлось потом совместно реализовать, а не просто «нагенерить» эти идеи.
• Не манипулирование. «Продавливание» своей позиции, победа в дискуссии не входит в текущую тему. Когда мы говорим об истинной коммуникации, мы подразумеваем только открытые и уважительные отношения равноправных партнеров с общими целями.
• Не формальные рабочие обсуждения. Постановка задач руководством, отчеты о проделанных работах — любые монологовые, односторонние форматы не имеют к коммуникации никакого отношения. В коммуникации нет иерархических отношений: все участники выступают как партнеры и имеют равные возможности влиять на ход и результат коммуникативного процесса.

Ниже я попытаюсь дать несколько обобщенных рекомендаций по коммуникации с заказчиком и разъяснить их.

«А кто ты в проекте?»

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

Коммуникации направлены на совместное целевое движение, проведение изменений в общей для сторон деятельности. Поэтому нужно понимать основные обязательства между сторонами, а при необходимости — принципиальную возможность и способы пересмотра этих обязательств.

Концепция Другого и мультикультурализм

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

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

Для выстраивания истинной коммуникации вам придется принять философскую категорию инаковости и осознать, что другой абсолютно прав в своей картине мира и общение с ним обогатит вас и придаст определенной «добавочной стоимости» обеим сторонам.

Что из этого следует на практике? Работайте в презумпции адекватности и разумности противоположной стороны: искренне пытайтесь понять, чего хочет клиент, умейте слушать, поощряйте многокультурность внутри своего коллектива, не старайтесь навязать стандартное решение или отмахнуться в стиле «Я самый умный» («Да я сразу понял, что им нужно! Сейчас быстренько сделаем!»).

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

«Я думал, что играю с ним в шахматы, а он играл со мной в городки»

Чтобы вам что-то ответили, нужно что-то сказать. Клиенту действительно часто сложно описать, чего он хочет, пока ему не покажут или хотя бы не помогут сформулировать это. Осторожно «вбрасывайте» в ходе переговоров свои идеи, тезисы, предположения, внимательно изучайте реакцию на них. Проявляйте эмпатию, умейте занимать позицию другой стороны, смотрите на проект глазами заказчика.

Разработайте и согласуйте с клиентом коммуникационный протокол — те правила, форматы и процедуры, по которым вы будете обмениваться информацией и подтверждать согласованность действий. При обсуждении концептуальных вопросов максимально полно и объективно объясняйте заказчику альтернативы, чтобы он мог принять взвешенное решение. Выслушав, попытайтесь переформулировать каждый тезис клиента своими словами и получите от него подтверждение корректности своего понимания.

Со временем вы сформируете общее смысловое поле и наравне с пониманием задач и устремлений бизнеса это станет вашим конкурентным преимуществом при выборе подрядчика на следующий проект.

«И жили они долго и счастливо»

На практике создание коммуникационного пространства и выработка совместного языка занимает годы и происходит в процессе переживания заказчиком и подрядчиком множества рабочих ситуаций.

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

2 какие бывают риски в SEO?

Первый тип рисков “Явные”

• Коммуникационные риски — не так друг друга поняли. Например? Исполнитель говорит заказчику — ну вы же подписали ТЗ. Заказчик — и что? Исполнитель — ну ТЗ — Техническое задание! Нее мы думали ТЗ — это точка зрения и у нас их несколько!
• Риски планирования — не так спланировали процесс. Например? Не верно выбрали направления для продвижения.
• Организационные риски — изменились приоритеты в управлении проектом или финансовые затруднения привели к уменьшению бюджета проекта
• Технологические риски — использование ранее не оттестированных решений.

Второй тип рисков “Типичные риски”

• Не верно подобранные поисковые запросы.
• Проблемы с контент-маркетингом, а в результате безграмотный и не интересный контент.
• Другие типичные проблемы сайта. Например? Не работающие формы или не верно указанные телефоны на сайте.
• Проблемы с индексацией сайта. В результате он просто не поднимается в поиске.

Не типичные риски

• Медленный сервер или периодические DDOS атаки на сайт. В результате сайт плохо индексируется и начинаются позиции с поиском
• Не корректная работа CMS. В результате ошибок в работе сайта, поисковые системы не присваивают ему те позиции, которые он заслуживает.
• Физические ограничения на внедрение доработок или внесение изминений в код сайта. Например? Нужно сделать умный фильтр товаров в категориях. Но для этого нужно менять вёрстку и покупать другую редакцию Битрикс.
• Другие не типичные проблемы.

Только опытный SEO-специалист видит риски в SEO и может вовремя выявить ту или иную проблему и подсказать заказчику способы её решения.

Техническое задание на сайт: кто готовит?

— Но вы же утвердили техническое задание?!

Мы думали, ТЗ — это «точка зрения», и у нас их несколько.

Старая бородатая шутка

В одной веб-студии техническое задание ждут от заказчика. В другой делают сами. В третьей предлагают скачать из интернета. Истина где-то рядом: лучшее ТЗ получается у тех, кто собаку съел на развитии и поддержке сайтов. Расскажем почему.

Вариант №1: техническое задание на сайт готовит заказчик

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

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

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

Ситуация может развиваться в двух направлениях:

1. Неучтенные моменты обнаружили при разработке. Печально, но не смертельно. Меняется техзадание и смета, отодвигается срок сдачи. Стоимость проекта в 99% случаях оказывается больше запланированной.

2. Недоработки ТЗ повлияли на работоспособность ресурса после сдачи проекта (сайт «ложится» на 10 тыс. посетителях, дублирующиеся в 2-4 категориях товары с разными URLами ухудшают ранжирование в поисковиках и пр.). Все плохо. Нужны не косметические правки, а полномасштабный ремонт.

В обоих случаях результатом совместной работы становится негатив. Заказчик считает, что, увеличивая время работы за «такие мелочи», разработчики пытаются его «кинуть». Исполнитель, работая строго по ТЗ, воспринимает корректировки как «хотелки» и отказывается работать бесплатно. Компромисс возможен, но при любом исходе будут пострадавшие. Либо исполнитель доработает сайт в ущерб себе, либо заказчику придется увеличивать бюджет разработки.

Вариант №2: техническое задание на сайт делает исполнитель

Стандартная схема разработки ТЗ на сайт в исполнении разработчика выглядит следующим образом:

1. Заказчик обрисовывает, как он видит сайт, описывает задачи.
2. Исполнитель уточняет данные, возможно, дает заполнить бриф.
3. Разработчик составляет ТЗ, согласовывает с заказчиком.
4. В соответствии с ТЗ разрабатывает сайт.

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

Вариант №3: создание техзадания третьей стороной

Третья сторона — независимый эксперт. Его задача — понять идею клиента и переложить ее на технически грамотный язык разработчика.

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

Ему не приходится выбирать между дешевым и хорошим. Он делает то, что отвечает задаче клиента.

Еще одно достоинство этого варианта — возможность сравнить стоимость услуг нескольких агентств и сменить команду разработки, если что-то не срослось. Проверено: когда новому подрядчику передают четко формализованное техзадание, он быстрее втягивается в рабочий процесс и сроки сдачи проекта не страдают.

И да, мы составляем технические задания на сайт для сторонних разработчиков. Знаем, где соломку подстелить и на чем заострить внимание, чтобы клиент получил не просто красивую страничку в интернете, а рабочий бизнес-инструмент.

Владимир Рахтеенко. Почему исполнители и заказчики не слышат друг друга

И как им договориться

— Но вы же утвердили техническое задание?! — Техническое задание? Мы думали, ТЗ — это «точка зрения», и у нас их несколько.

Да, это очень старая шутка. Но я люблю её за точность.

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

То же самое можно наблюдать не только в IT. Так происходит более или менее в любых сложных проектах, которые требуют взаимодействия с подрядчиками, оказывающими профессиональные услуги.

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

О построении правильной коммуникации можно не думать, если вы делаете что-то очень простое. Когда речь идёт о сложной проектной деятельности (конечный результат которой не определён заранее, а должен быть выработан партнёрами по проекту), правильно выстроенная коммуникация — единственный способ обеспечить результативное взаимодействие.

Постановка проблемы

В моём понимании, истинная коммуникация — это объединение усилий равноправных партнёров, нацеленное на порождение принципиально нового содержания. Прежде чем поделиться практическими советами, разберу несколько распространённых заблуждений.

Коммуникация — это не бытовой разговор и не дружеская беседа. В таких форматах общения вам вполне достаточно просто выговориться — не обязательно до конца понимать друг друга, а уж тем более порождать новые смыслы. Коммуникация нужна там, где есть совместная деятельность, порождение чего-то нового, где взаимопонимание необходимо для достижения результата.

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

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

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

А теперь — о том, как построить правильную коммуникацию.

Распределение ролей

Поскольку ответственность и так называемый деятельностный подход являются ключевыми принципами коммуникации, в самом начале процесса важно определить позиции всех участников и сферу их полномочий.

Какой будет ваша реальная, а не формальная позиция в проекте? Руководитель, организатор, конечный пользователь, инвестор? Часто в обсуждениях участвуют люди, смотрящие на проект как бы со стороны. Пока не определится их место в системе организации труда, они не смогут взять на себя свою долю ответственности, и обсуждение, таким образом, не будет конструктивным.

Концепция «другого человека»

Человек, сидящий напротив вас за столом переговоров, воспринимает, мыслит, рассуждает и запоминает не так, как вы. Не обязательно неправильно — просто по-другому.

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

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

У каждого из нас в каждый конкретный момент преобладает какой-то один тип мышления, но мы редко задумываемся, что собеседник может мыслить в абсолютно других категориях. Работая над общим предметом и даже называя его одними и теми же словами, скорее всего, вы с заказчиком понимаете под ними разное, каждый — что-то своё.

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

«Я думал, что играю с ним в шахматы, а он играл со мной в городки»

Чтобы вам что-то ответили, нужно о чём-то спросить. Клиенту действительно бывает сложно описать, чего он хочет, пока ему не покажут (или хотя бы не помогут сформулировать это).

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

Разработайте и согласуйте с клиентом коммуникационный протокол — правила, форматы и процедуры, согласно которым вы будете обмениваться информацией и подтверждать согласованность действий.

При обсуждении концептуальных вопросов максимально полно и объективно объясняйте заказчику альтернативы — чтобы он мог принять взвешенное решение. Выслушав, попытайтесь переформулировать каждый тезис клиента своими словами и получите от него подтверждение корректности своего понимания.

Со временем вы сформируете общее смысловое поле. Нередко на создание цельного коммуникационного пространства уходят годы. Почти всегда клиенту и подрядчику приходится пройти через множество неприятных конфликтов. Но разрешая их, вы обретаете общий контекст и укрепляете доверие.

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

ТЗ – Теперь Зае.ись? Или нет?

Изначально вступление было таким, однако я был вынужден его сократить, потому что оно не вписывалось в оптимальную длину:

Если после получения письма с текстом «Отправьте, пожалуйста, ТЗ» вы впадаете в ступор, у Вас изо рта течет пена, и вы судорожно дергаетесь в конвульсиях, потому что, даже если и знаете что это, но совсем не понимаете, как составляется Техническое Задание – эта статья для Вас.

Но сейчас не об этом. В статье я расскажу о понятии «Техническое Задание» и объясню, что же оно значит для дизайнера. Поехали.

Давайте посмотрим, что думает Википедия по этому поводу:

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

Еще там написано следующее:

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

Не спешите нанимать юриста или говорить дизайнеру, что отказываетесь от его услуг. Все намного проще, чем Вы думаете. На самом деле, сейчас практически все упускают этот аспект из виду, а дизайнер – тем более (в случае, если он не требует юридического сопровождении заказа).

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

• 1.Технические требования (User Story)
• 2.Техническое задание

Сначала Вам нужно понять то, что Вы хотите. Поняли? Если нет – читаем мою предыдущую статью https://spark.ru/startup/53-studio/blog/14953/kak-. , в которой я рассказываю о том, как это сделать. Если после прочтения этой статьи Вы все равно ничего не поняли – можете обратиться за бесплатной консультацией к нашей команде 53studio.

После того, как в Вашей голове сформировалась четкая картина желаемого результата, пишем технические требования по схеме «User Story». Вернемся к Википедии:

Пользовательские истории(англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя.

User Story составляется по такому принципу:

Пишется «Как пользователь я хочу», и составляются пункты. Например:

Как пользователь я хочу:

• 1.Видеть 2 пункта меню;
• 2.При наведении мышки на ссылку «о нас» она должна увеличиться на 120%.

Как пользователь я хочу:

• 1.Видеть красный круг;
• 2.В красном круге видеть букву «Т»;
• 3.Из-под «Т» хочу видеть выглядывающего смурфика. (О том, кто такие смурфики, и будет моя следующая статья, на самом деле нет).

Далее из этого текста формируется Техническое Задание.

Рассмотрим первый пример:

• 1.На сайте должны быть два пункта меню. Первый пункт – «о нас», второй – «где купить». Прикрепляю эскиз проектировщика, где четко указано расстояние и замеры нужных мне элементов. Цвет элементов должен гармонично вписываться в стилистику, но предпочитаемые цвета такие: #ff0ff0, #ababab, #111012;
• 2.Скорость анимации не должна превышать 0,5s. Во время анимации должно быть контрастирование цвета всего интерфейса.

Рассмотрим второй пример:

• 1.Должен быть нарисован круг. Цвет круга должен быть таким: #dc5959, или таким: #ff3636. Его размер: 200×200 пикселей;
• 2.В круге должна быть буква. Цвет буквы: # ffffff. Шрифт: Times New Roman. Размер буквы: 200 пикселей;
• 3.Из-под буквы должен выглядывать смурфик. В письме прикрепляю набросок того, где должен быть этот смурфик и рисунок художника.

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

Рекомендую подписаться на мой канал в телеграме, где я публикую интересные дизайнерские решения и качественные материалы — Designer’s Masterpieces

По традиции 53 studio осталось пожелать Вам удачных заказов и сбереженных нервов, спасибо за чтение.

Тз это точка зрения и у нас их несколько

— Всё сделано в полном соответствии с Вашим ТЗ.

— Но мы думали, что ТЗ — это точка зрения. И их у нас уже несколько.

Начнём с главного. Что же такое техническое задание и зачем и когда оно нам нужно. Техническое задание – это документ, который берётся за основу при разработке любого проекта. Мы бы даже сказали, что это документ, который должен возникнуть первым при начале любого дела и любого сотрудничества. И совершенно не важно, какой сложности и величины задание, что конкретно вы заказываете исполнителю: сайт или внедрение программного продукта, первое, что должен спросить у вас исполнитель – это чёткое и понятное ТЗ. Если перед заключением договора в разговоре с вами даже слова такого не возникает, то даже продолжать разговор не стоит (подробнее о том, как выбрать компанию для внедрения программы мы поговорим в одном из следующих номеров). И это надо не исполнителю! Нет! Совсем наоборот! Чем более расплывчатое ТЗ будет подготовлено, тем больше у исполнителя шансов «впарить» вам лишние работы, дополнительные услуги. Больше вероятность возникновение тех самых пунктов, которые в договоре обычно формулируют «Дополнительные работы оплачиваются отдельно». Техническое задание в первую очередь нужно заказчику, чтобы потом исполнитель работал не на честном слове. Чем чётче будет сформировано ТЗ, тем ближе финальный результат будет к тому, что вы рисовали себе в ваших самых радужных мечтах. Именно поэтому и нежелательно отдавать составление ТЗ на откуп исполнителю. Ведь это ваша мечта! Кто, кроме вас сможет её лучше описать? Кроме того, техническое задание – это документ, по которому вы впоследствии будете принимать сделанную работу. И если что-то не будет выполнено, то при обосновании претензии достаточно указать на соответствующий пункт. Да и вам самим будет проще, подписывая акт, сравнить всё с тем перечнем работ и задач, которые были указаны в первоначальном ТЗ, чтобы вспомнить всё.

Итак, на что же обратить внимание при составлении технического задания. Даже если у вас не очень сложный и не очень специфичный проект, всё равно в вашем техническом задании обязательно должен быть словарь терминов и определений. Почему это важно. Да просто потому, что даже когда вам кажется, что вы с исполнителем понимаете друг друга с полуслова, всё равно, при ближайшем рассмотрении, окажется, что обязательно найдутся слова, фразы или обороты речи, которые вы понимаете по разному. И не надо этого стесняться. Проигрывает обычно не тот, кто проговаривает и формулирует даже самые обычные с его точки зрения слова, а тот, кто этого не делает. Кстати, этот пункт обязателен для обеих сторон. Поэтому не надо стараться казаться умным. Лучше попросите вашего исполнителя включить в этот словарь все его определения. А ещё лучше – составьте его вместе. Лишний повод обсудить будущий проект. Это далеко не лишняя трата времени, потому что известны случаи, когда отсутствие понимания в терминах привело к срыву сроков более чем на месяц. Что на ваш взгляд дороже: 2-3 часа работы двух человек или целый месяц работы команды?

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

Если у вас есть примеры каких-то технических элементов, решений, функций, которые вам очень нравятся, и которые вы хотите иметь у себя, не забудьте описать их в техническом задании. Это и есть функциональные требования. Что же касается условий, как и с помощью чего должно быть это решено, т. е. специальных требований. Если у вас нет никаких жёстких ограничений по этому поводу (совместимость с определённой программой или оборудованием, например), то лучше этот вопрос оставить на усмотрение исполнителя. И не забивать себе голову этими проблемами!

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

Ну и конечно не забудьте прописать всё, что касается отчётности и ответственности.

В заключение хотим привести 3 правила, которые позволят составить действительно работающее техническое задание.

1. ТЗ должно быть детальное, но без воды. Описывайте максимально подробно каждый элемент, пункт, кнопку, но не надо писать пространных эссе на тему «Как вы пришли к такой мысли». Всё чётко и по делу.

2. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Если в процессе выполнения проекта вы поняли, что время требует других решений, не бойтесь подписывать дополнительные соглашения с уточнениями к первоначальному ТЗ. Но не увлекайтесь этим процессом. Всегда взвешивайте своё решение на весах целесообразности и полезности.

3. Чтобы было проще выполнить два предыдущих пункта, возьмите за основу третье правило. Окончательное техническое задание (вопреки тому, что мы написали в начале этой статьи) – это плод коллективного творчества вас и ваших исполнителей. Не стесняйтесь советоваться с профессионалами и что-то оставлять на их усмотрение.

Самое точное определение, которое я когда-либо встречал

Дубликаты не найдены

ТЗ — это Точка Зрения заказчика =))

ТЗ? Сто лет не видел.
— Да вы сделайте как вот в этом нашем проекте и всё.
.
— ЁБ ТВОЮ МАТЬ ЧТО ЗА ХУЙНЮ ВЫ СДЕЛАЛИ?!

А зачем мы вам деньги платим?!

Без ТЗ получают ХЗ

я говнотер, про тз не слышал.

ты тоже пикабу на роботе листаешь?

и никто меня не зачморил за «рОбота», удивительно

Вот как постоянный заказчик у дизайнеров, верстальщиков и программистов могу сказать, что 95% ТЗ читают абы как.

Показывают результат — а там четверть пунктов просто пропущена, а ещё четверть сделана неправильно. Просто потому что исполнителю было лень внимательно читать ТЗ.

И даже свериться по ТЗ перед показом мне было западло.

Особенно это свойственно дизайнерам, во вторую очередь — верстальщикам, и замыкают рейтинг прогеры.

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

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

ТЗ – Теперь Зае.ись? Или нет?

Изначально вступление было таким, однако я был вынужден его сократить, потому что оно не вписывалось в оптимальную длину:

Если после получения письма с текстом «Отправьте, пожалуйста, ТЗ» вы впадаете в ступор, у Вас изо рта течет пена, и вы судорожно дергаетесь в конвульсиях, потому что, даже если и знаете что это, но совсем не понимаете, как составляется Техническое Задание – эта статья для Вас.

Но сейчас не об этом. В статье я расскажу о понятии «Техническое Задание» и объясню, что же оно значит для дизайнера. Поехали.

Давайте посмотрим, что думает Википедия по этому поводу:

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

Еще там написано следующее:

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

Не спешите нанимать юриста или говорить дизайнеру, что отказываетесь от его услуг. Все намного проще, чем Вы думаете. На самом деле, сейчас практически все упускают этот аспект из виду, а дизайнер – тем более (в случае, если он не требует юридического сопровождении заказа).

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

• 1.Технические требования (User Story)
• 2.Техническое задание

Сначала Вам нужно понять то, что Вы хотите. Поняли? Если нет – читаем мою предыдущую статью https://spark.ru/startup/53-studio/blog/14953/kak-. , в которой я рассказываю о том, как это сделать. Если после прочтения этой статьи Вы все равно ничего не поняли – можете обратиться за бесплатной консультацией к нашей команде 53studio.

После того, как в Вашей голове сформировалась четкая картина желаемого результата, пишем технические требования по схеме «User Story». Вернемся к Википедии:

Пользовательские истории(англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя.

User Story составляется по такому принципу:

Пишется «Как пользователь я хочу», и составляются пункты. Например:

Как пользователь я хочу:

• 1.Видеть 2 пункта меню;
• 2.При наведении мышки на ссылку «о нас» она должна увеличиться на 120%.

Как пользователь я хочу:

• 1.Видеть красный круг;
• 2.В красном круге видеть букву «Т»;
• 3.Из-под «Т» хочу видеть выглядывающего смурфика. (О том, кто такие смурфики, и будет моя следующая статья, на самом деле нет).

Далее из этого текста формируется Техническое Задание.

Рассмотрим первый пример:

• 1.На сайте должны быть два пункта меню. Первый пункт – «о нас», второй – «где купить». Прикрепляю эскиз проектировщика, где четко указано расстояние и замеры нужных мне элементов. Цвет элементов должен гармонично вписываться в стилистику, но предпочитаемые цвета такие: #ff0ff0, #ababab, #111012;
• 2.Скорость анимации не должна превышать 0,5s. Во время анимации должно быть контрастирование цвета всего интерфейса.

Рассмотрим второй пример:

• 1.Должен быть нарисован круг. Цвет круга должен быть таким: #dc5959, или таким: #ff3636. Его размер: 200×200 пикселей;
• 2.В круге должна быть буква. Цвет буквы: # ffffff. Шрифт: Times New Roman. Размер буквы: 200 пикселей;
• 3.Из-под буквы должен выглядывать смурфик. В письме прикрепляю набросок того, где должен быть этот смурфик и рисунок художника.

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

Рекомендую подписаться на мой канал в телеграме, где я публикую интересные дизайнерские решения и качественные материалы — Designer’s Masterpieces

По традиции 53 studio осталось пожелать Вам удачных заказов и сбереженных нервов, спасибо за чтение.

Тз это точка зрения и у нас их несколько

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы

К сожалению, очень часто, «проповедуя» Agile, разработчики пытаются замаскировать свое неумение разработать проект системы (либо даже не знают, что это возможно). Они действуют самым удобным для них образом: будем допиливать и допиливать за деньги заказчика.

Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес.
И это не отменяет того факта, что без умения проектировать, ничего хорошего не получится. С или без agile.

ps
и да, agile не универсальное решение. строить (здания) по agile не очень.

Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес.

Я могу попробовать.
Главная выгода Agile для бизнеса:

• быстрый выход на рынок
• короткие фидбек циклы, что позволяет проводить быстрые эксперименты

• цена ошибки минимизирована, т.к. не тратится большое количество времени и денег на разработку минимального продукта, отзыв на который можно получить непосредственно от пользователя моментально
• допускается, что пользователь не знает на 100%, что он хочет, но пользователь точно знает, что он не хочет, посему работающий продукт идеален для получения отзыва, хотя прототипы и другие «оффлайн» методы могут очень помочь и сократить сроки экспериментов

В конкурентной среде (особенно такой динамичной, как в наши дни) у вотерфола почти нет шансов. Он непременно приведет к проваливанию сроков и разработке продукта, который, скорее всего, никому не нужен. Или, в лучшем случае, с огромным количеством фичей, которыми никто не пользуется.
Главная задача ИТ в динамичном бизнесе — не разработка софта, как бы странно это не звучало. Главная задача — решение бизнес проблем более эффективно. Оптимизация текущих процессов, изобретение новых. Если вы поговорите с вашим заказчиком и выясните, что он проводит огромное количество ручных вычислений, и вы дадите ему формулку для Excel, на написание которой и обучение нужных людей вам понадобится 2 дня, но это увеличит продуктивность заказчика на 90%, то вам цены не будет!

Тут собственно говоря уже развернуто обсудили, почему agile — это про бизнес, а не про ИТ.

Бизнесу грубо говоря, глубоко до лампочки — scrum, waterfall, devops, etc.
У бизнеса основная проблема — что делать в условиях неопределенности: конкуренты, законы, потребители, глобализация, и т.д. В итоге, сказать, каков будет твой бизнес через год, два, три — вряд ли кто может. Если в этих условиях кто-то предложит бизнесу, а давай ты вложись в XXX, и через годик, другой, получишь вот такой профит. То любой зрелый бизнес понимает, что через годик, другой все переиграется, и XXX может станет не нужным.
Ответ, что делать в условиях неопределенности — уменьшить горизонт детального планирования, наладить сбор и анализ обратной связи, и короткими итерациями двигаться с счастью. Понятно, что и этот подход не панацея. В итоге приходится импровизировать, что собственно и есть «agile», т.е. проявлять ловкость (многие забывают, что agile это не только гибкий, но и ловкий, а применительно к бизнесу, ловкий как-то ближе). Т.е. agile — это не просто короткие итерации и прочие атрибуты, которые обычно связывают с термином «agile», а чуть шире, в целом ловкость и быстрая адаптируемость к внешним условиям.

А правильно проектировать нужно всегда. При любом подходе.
Просто сейчас акцент проектирования смещается в более концептуальную сторону.
А где у нас узкие места по производительности? А что мы будем делать с этим когда нужно будет избавиться от этого узкого места? А что у нас с безопасностью? А что у нас простотой обслуживания? А что у нас с простотой развития? А что у нас с масштабированием? и т.д.

Насколько детально проектировать?
Настолько насколько нужно. Ответ вроде простой, но тем не менее неочевидный.
Чем больше проект и чем динамичнее, тем больше документация разъезжается с реальностью. В итоге документацией перестают пользоваться, и возникает отрицательная обратная связь. Документацией никто не пользуется, потому что она неактуальная. Документацию никто не актуализирует, потому что ей никто не пользуется.

Из этого ошибочно делают выводы, документация для проектирования не нужна вообще. (Документация нужна, необходимо только правильно выбрать уровень детализации) И документация никогда не нужна. (В других проектах, менее динамичных, документация запросто может быть детальной и актуальной).

Целиком поддерживаю! Вы читаете мои мысли, которые мне не удалось выразить в этой статье. Главное правило: не пользоваться тупо методиками, какими бы совершенными они ни были, а голову включать всегда и везде! И Один метод не исключает другого. Базовую функциональность спроектировали по вотерфолу, а замет поюзали, попробовали, поняли, что и где неудобно и чего не хватает: пошла гибкая разработка. А вот выбор, что есть базовое, с чем мы можем выйти на рынок, надо определять в каждом конкретном случае отдельно.

Тз это точка зрения и у нас их несколько

Довольно часто клиенты приходят без технического задания, просто с некоторыми материалами, в лучшем случае это будет предполагаемая структура сайта. И когда я им объясняю, что ТЗ необходимо, объясняю почему, называю цену, они зачастую не возвращаются. Возможно, их пугает дополнительный этап работы, может, они думают, что это просто займёт больше времени. Можно было бы включать разработку ТЗ в цену проекта, но тогда возникают трудности с подписанием договора, так как к нему нельзя будет приложить ТЗ.

Какие есть варианты?

В бюро техническое задание ( или более упрощённое задание на работу) является первым коммерческим этапом любого проекта. Нет никакой необходимости объяснять клиенту, зачем нужно задание — это просто часть методологии нашей работы. Без него мы просто не смогли бы решить задачу. Крайне важно, чтобы мы сами его написали, иначе нет никакого способа нам и клиенту убедиться, что мы правильно поняли задачу.

Это как тесто замесить перед выпечкой. Я не рекомендую вам убеждать клиента в необходимости замеса, просто сообщите, что это первый этап вашей работы; не пытайтесь продавать замес отдельно.

Этот совет устарел. Сейчас бюро придерживается итеративного подхода с несдвигаемыми дедлайнами, а технические спецификации составляются между этапами дизайна и разработки. См. советы об управлении проектами.

Комментарии

Ярослав Маркин
5 ноября 2010

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

На самом деле, «замес» вполне можно продавать отдельно — мы в Evil Martians очень часто предлагаем написать спецификацию для проекта отдельным этапом, за отдельную сумму: так заказчик имеет возможность посмотреть на качество нашей работы (проработка требований и вообще организация работы), при том что он не подписывает контракта на работу, и, вообще говоря, после разработанной спецификации может уйти к другому разработчику (это мы тоже объясняем каждый раз). Мы, с другой стороны, видим, насколько проработана идея проекта, выясняем все тонкости (что на самом деле является целью проекта, кто имеет последнее слово в принятии решений), смотрим, как у заказчика с исполнением обязательств (платежи), и вообще определяемся, насколько проект адекватен.

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

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

Илья Земсков
5 ноября 2010

Артём, правильно ли я понял, что вы фактически предлагаете не цепляться за клиентов, которые не хотят работать по нашим правилам?

Александр Кравчук
6 ноября 2010

Сделайте ТЗ бесплатно, в качестве бонуса.

Заодно сможете проверить степень адекватности клиента А он уже на этом этапе убедится в вашей исключительной компетентности и успокоится.

После этого заключить договор будет намного проще.

Алексей Мельников
6 ноября 2010

Для клиента выглядит как большая кнопка «Сделать красиво». И как любой нормальный человек, он хочет засунуть деньги в автомат, нажать на кнопку и получить своё «красиво», по возможности, не отвечая ни на какие вопросы и не проходя никакие «шаг 1 из 10».

Старайтесь не надоедать ему техническими подробностями и помнить, что на этой есть и другие кнопки

Иван Демидов
9 ноября 2010

Не всё можно хорошо сделать без участия клиента и одним нажатием кнопки. Например, костюм без активной помощи клиента хорошо не пошьёшь 🙂

Даниил Фойгель
17 ноября 2010

А почему нельзя объяснить клиенту, что сначала вы подписываете договор, потом начинаете сами формулировать ТЗ, которое клиент (не) утверждает, а потом на его основе начинаете работать? В конце концов, если ТЗ херовое, то трудности наживёте вы, а не клиент, следовательно, дышится лучше, когда ТЗ составили сами. Да и потом, если что, им можно поразмахивать (как гостом

Алексей Кварц
9 апреля 2014

Даниил, возможно, я неправ, но чтобы подписать договор, нужно наверняка знать стоимость проекта, а также его объём работы и сроки. Это всё как раз в договоре и прописывается.

Любой адекватный человек не стал бы подписываться под тем, к чему он не готов.