Pull to refresh

Comments 152

Не вижу пункта «я разработчик, но ТЗ предоставляет заказчик». Иногда даже с примерами интерфейсов, которые ему нужны. После обсуждения и внесения изменений согласовывается окончательный вариант. Через год-два от того первоначального ТЗ неизменным остается только титульный лист. :)
Точно, но наверное нельзя уже править, иначе сломается?

Но у меня кстати база всегда остается, но обрастает дополнениями.
Полностью поддерживаю. По факту, кстати, это самый вменяемый тип клиентов, который чаще всего понимает что он хочет (конечно если там не полторы строчки, а реально составили хорошо). Был у нас клиент году в 2010-м который составил ТЗ на интернет-площадку продажи и обмена редких монет. Жаль мы к тому времени только дизайн для этого проекта делали, т.к. для не-специалиста он чрезвычайно подробно более чем на сорока страницах описал всю суть и большинство нюансов, при этом добавил как полагается глоссарий, оглавление и приложил скрины с примерами на которых указал отдельные важные элементы. Также отдельно несколько таблиц составил, описывающих логику работы калькуляторов и систем оценки. По сути только благодаря тому ТЗ я до сих пор помню чем отличаются XF от VF.
Формат простой, всего три документа:
1. Сценарии
Цели:
Задачи:
Пользовательский сценарий 1
Шаг 1
Шаг 2

Шаг n
Пользовательский сценарий 2
Пользовательский сценарий N
2. Описание экранов
Экран 1
Экран 2

Экран n
3. План демонстрации промежуточных стадий системы
Демонстрация 1
Демонстрация 2

Демонстрация n

Иногда к этому добавляется API в swagger и математика в XLS, если есть
Добавить «словарь системы» и пусть все говорят на одном языке
Присоединяюсь — очень полезное дополнение!
Очень неприятно месяц обсуждать небольшую деталь проекта, а потом выяснить, что под одним и тем же термином подразумевались совершенно разные вещи.

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


  1. Диаграмма последовательности (как альтернатива пользовательскому сценарию)
  2. Блок-схемы демонстрирующие как должен работать, например, реализуемый API

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


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


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

Спасибо, добавление разумное.

Иногда я использую майн-карты и mindmaster для этого.

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

Вот тоже поддержу схемы и диаграммы. У меня самого лучше получается понять суть процесса, если я смоделировал его в диаграмме, а ещё, бонусом, я могу в два-три раза быстрее объяснить происходящее коллеге.
Напишите, плиз, в чем диаграммы рисуете
Обычно в Dia рисую, программа немного неформальная, больше рисовалка схем, чем инструмент проектирования классов (в отличие от ArgoUML).
А вот ежели надо по всей строгости спроектировать, то, наверное, лучше ArgoUML применять.
Вот хороший вариант www.draw.io Работает прямо в браузере.
А мы рисуем в Visio.
У нас все большие фаната диаграмм (и я тоже, даже на бумажках часто рисую во время обсуждений!), но вот новое руководство их не любит и заставляет переписывать в листы текста и как с этим бороться пока не придумали

А как они обосновывают свой выбор? Что за текст? В каком формате?

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

А в каком виде то? просто для разных задач разные формы хорошо подходят. Например если мы говорим о чем-то что как-то себя по хитрому ведет, то тут как по мне всякие specification by example хорошо себя подают. А есть ситуации когда проще описывать причину и следствие (event storming). Те же текстовые стори тоже удобно группировать в какую-то карту (стори мэппинг). А есть еще всякие impact mapping-и и т.д.


Посему все же поинтересуюсь, какие именно диаграммы вы пробовали делать, и в каком виде пишите текст. Просто полотно из критериев приемки, или что-то поинтереснее...

Приёмочные тесты тоже не помешали бы, пусть только по базовому функционалу и просто написанные без автоматизации…
В принципе, это не часть ТЗ. Хотя может быть пункт в критериях приемки, например: функционал Fx проверяется согласно следущих тестов.
Это часть методологии приемки, которая оговаривается юридически в контракте (лучше уточнить у юристов для соответсвующей юрисдикции).
Да зачем здесь юристы, почти все документы составляют инженеры.
В данном случае составляется документ «Программа и методика испытаний» в котором описано пошаговое выполнение программным обеспечением требований ТЗ, вида:
спойлер
1. В браузере IE 8.0 открыть «Портал автоматизации всего» по адресу http://site.com
2. В окне авторизации ввести данные УЗ пользователя портала.
3. В левой части окна выбрать пункт меню «Настройки».
4. Во вкладке «Настройки интерфейса» в выпадающем списке поля «Язык» выбрать English.
5. Нажать кнопку «Сохранить настройки».
6. Убедиться в наличии англоязычного интерфейса в портале.


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

upd:
Разумеется ПМИ перед испытаниями согласовывается с заказчиком на предмет того что в нём описаны проверки всех необходимых ему функций.
Это, к сожалению заблуждение. Перепутана причина и следствие. Просто тех работники редко задумываются и читают юридические «бумажки», как и юристы технические.

У меня Закон звучит так:
 1. Качество выполненной подрядчиком работы должно соответствовать условиям договора подряда, а при их отсутствии или неполноте – требованиям, обычно предъявляемым к работам соответствующего рода. Если иное не предусмотрено законодательством или договором, результат выполненной работы должен в момент передачи заказчику обладать свойствами, указанными в договоре или определенными обычно предъявляемыми требованиями, и в пределах разумного срока быть пригодным для установленного договором использования, а если такое использование договором не предусмотрено, – для обычного использования результата работы такого рода.
 
2. Если законодательством или в установленном им порядке предусмотрены обязательные требования к работе, выполняемой по договору подряда, подрядчик, действующий в качестве предпринимателя, обязан выполнять работу, соблюдая эти обязательные требования.


Как бы я не изворачивался, но должен следовать, иначе Клиент меня просто «на органы продаст» что бы «компенсировать убытки» или буду «пожизни баги фиксить». :)

Полагаю в РФ есть что-то весьма похожее, тем более что есть ГОСТ ИСО/МЭК 25041-2014. Не думаю что просто так его сделали
Иногда делаем. Особенно когда API на стадии ТЗ проектируется.
Обычно приемка по сценарию пользователя происходит и всем ок: и клиенту и разрабам.

Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.

На практики это, казалось бы очевидное утверждение, встречает массу возражений -)
UFO just landed and posted this here
Был на стороне разработчика и заказчика. С тех пор имею седые волосы в самых неожиданных местах!
Это легко исправить: повнедрять и посопровождать — раз! И вообще волос нет :)
я повнедрял и посопровождал от души и много лет, и продолжаю
волосы норм

кому бы делегировать? -)))
И обратно к любимому занятию? И ж чего хотите, там своих молодых да ранних, вот таких Чапаевцев (КДПВ очень в тему кстати) с шашкой наголо хватает — без ТЗ по ночам… По четко поставленному ХЗ!
По Чапаеву были сомнения будет ли правильно воспринят. Вы их развеяли, спасибо за фитбэк -)
Действительно, мало кто понимает, что программный продукт есть продукт сотрудничества сторон. Денег недостаточно. Обязательно требуется компетенция заказчика, его организационные движения на его стороне.
В такой трактовке верный коммент выше — «Заказчик должен (быть готовым) вложить свои внимание и усилия в достаточно полное описание задачи». Без этих усилий это просто «кнопка „сделайте хорошо“».
Вообще, клиенты, которые не болеют за проект — отдельная болезненная тема.
Действительно мало кто понимает это.
Это свойственно, когда заказчик и эксплуатант системы — разные люди (подразделения). К примеру, заказали новую систему биллинга, а инженерам, сидящим на поддержке старой — это нафиг не надо, хотя операторы системы, наоборот, радостно ждут переписанную ИС (ибо старой уже больше 15 лет, а код состоит в основном из костылей). Понятно, что несмотря на свою экспертизу, инженеры от нового проекта и подрядчика отмахивались почти не глядя. Ведь новую систему нужно будет изучать с 0, учить новый ЯП, изучать новую IDE.
Другой пример. Финансовое руководство предприятия, недовольное вечным бардаком на складах и кипой вечно теряющихся бумаг, заказало написание и внедрение сферической ИС «Склад». Надо ли упоминать, что кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?
И таких примеров уйма. У всех свои интересы, даже внутри одного предприятия.
Понимаю вас, плавали — знаем. Если заказчик не заинтересован в проекте, наверное лучше вообще отказаться. Не понятно как его сдавать в этом случае сдавать проект.
заказчик заинтересован. Просто не надо путать тех кто будет эксплуатировать с заказчиками.
expertise (англ.) = опыт, специальные навыки, мастерство, компетентность.
экспертиза (в устоявшемся в русском языке смысле, например, «проведена криминалистическая экспертиза») = inspection, expert report, evaluation
кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?

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

Вот это, кстати, очень печальный случай — когда описывают желаемый функционал те, кто никогда с системой как пользователь не работал. Потому что потом получается нечто неюзабельное, но формально выполняющее ТЗ, которым никто не хочет пользоваться.
UFO just landed and posted this here
Обычно сценарий у меня занимает 3 странички.
Предлагаю реализовать минимальную версию системы для начала, а дальше апгрейдить -)
Поиск минимально необходимого уровня формализации — отдельная тема. Если в случае с хипстерским стартапом ТЗ на 5 страничек А4 — вполне себе нормально, то для какой-нибудь системы учета для предприятия оборонной промышленности ТЗ должно быть максимально детальным и подробным. Все очень зависит от сферы и конкретного проекта.
Если есть такая возможность — выложите, пожалуйста, один пример вашего ТЗ.
Формат дал, я дал здесь: https://habrahabr.ru/post/315046/#comment_9909048

а пример в паблик вывливать не могу — все примеры только живые -)

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

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

P.S. большие компании вообще делают pre-sales программы, которые стоят до 50К-100К и которые никак не возвращаются напрямую.
Эммм, ну вот я аналитик.
Мне платят либо клиенты, либо разрабы.

Написали, допустим, 10 разным клиентам ТЗ, потратили по 20 рабочих часов на каждое, т.е. 200 рабочих часов в сумме.

Все они сказали спасибо, и пошли думать, а скорее всего устраивать тендер между разными разрабами, кто дешевле даст ценник.

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

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

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

К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.

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

P.S. я чаще выступаю как заказчик.
Сколько людей заказав ТЗ не делают дальше никаких работ в процентах?

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

К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.

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

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

Ну и консультация у юриста тоже не бесплатная, по крайней мере в Праге.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ,

Ключевой вопрос: откуда вы взяли ПЛАН?
Как следствие: вам сделали по ВАШЕМУ плану — постройка утонула или не выполнила ожидаемое. К кому претензии? К Вам или к строителям?
Если вы «купили» план — вы за него заплатили «тому парню», если вы сделали его сами — вы заплатили своим временем как минимум.
Заказчик платит в любом случае :)

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

Стоимость ТЗ порядка 3-5% от оплаченного счета
Где-то 10%-25% тех, кто заплатил за ТЗ не делают ничего вообще. ТЗ они довольны, но бывает планы поменялись, начальство передумало, бюджеты урезали и т.п.
Написание ТЗ нужно заказчику не меньше, чем разработчикам. Как правило, у заказчиков, которые еще не написали ТЗ у самих полностью отсутствует понимание того, как система вообще должна работать. Практически ни один человек не способен удержать в голове столько деталей, сколько есть, пусть даже в маленьком проекте. ТЗ на 5 страниц текста намного лучше, чем когда его нет вообще. Касательно бремени написания ТЗ — разработчик или заказчик? Ну давайте я к вам обращусь, как к разработчику за составлением детального ТЗ и согласованием деталей со мной в процессе разработки на какую-нибудь, скажем торговую площадку. Ваши аналитики будут пол года сидеть и делать мне ТЗ, согласовывать со мной, разработчиками, консультировать меня. А когда закончим я просто возьму результат и отдам его своим собственным разработчикам — УРА, пацаны, бесплатное ТЗ завезли, ай-да разрабатывать!
UFO just landed and posted this here
А кто еще? Эти аналитики принадлежат конторе, зачем заказчику разбираться, за что я плачу тестирование, аналитику, бухгалтерию, еще что-то. Есть контракт, есть сумма контракта, есть результат.
Нет контракта — не надо и ТЗ.
UFO just landed and posted this here
Сложно говорить кто, что должен. Кто-то хочет финансировать пресэйлз, кто-то нет. Каждая контора сама выбирает бизнес-стратегию -)
Что значит не составлять подробно? а зачем тогда вообще ТЗ? у нас помню даже раньше помимо услуги «составление ТЗ» была услуга «контроль проекта со стороны заказчика».
Услуга эта работала так: приходит клиент говорит чего он хочет. Мы проводим с ним н встреч, пишем тонну писем, и продаем ТЗ. За одно говорим, сколько будет стоить выполнение этого ТЗ нами. Если заказчика не устраивает цена, то мы предлагали вести проект от его имени с теми исполнителями которых выберет заказчик.
Но в любом случае у клиента оставалось хорошее проработанное ТЗ с которым можно устраивать тендеры (не государственные, а настоящие), а у аналитика деньги на хлеб с маслом
> большие компании вообще делают pre-sales программы, которые стоят до 50К-100К и которые никак не возвращаются напрямую.

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

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

Когда маленькая компания работает с маленькими адекватными клиентами — тоже всё нормально, все всё понимают и либо составляют ТЗ, либо другим образом формализуют оплату по разработке.

Проблемы начинаются, когда маленькая компания пытается продать разработку большим дядям — самый частотный случай. Обычно директор маленькой компании говорит «ну это такие клиенты… такое портфолио будет!»; большая компания же просто пытается сэкономить. О том, что за счет экономии снижается качество (или портятся люди), никто не вспоминает.

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

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

По поводу морали не согласен, т.к. есть успешный опыт работы с клиентами уровня «крупная транснациональная компания». Да, на пресэйлз уходит 50-100 т.р., но если зацепился там и ты удобен, то это окупается. Но опять же, чтобы зацепиться нужно, чтобы все были рады. А чтобы все были рады требуется ТЗ согласованное порою с 10-ю разными менеджерами.
> По поводу морали не согласен, т.к. есть успешный опыт работы с клиентами уровня «крупная транснациональная компания»

Искренне за вас рад — рад, что у кого-то это получается и кому-то это правда интересно.

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

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

Раздел знаний называется «Эффективные коммуникации».

Часто дело не в клиентах, а в выстраивании правильной коммуникации. Конечно 1% психов от популяции никто не отменял. И 1 из 100 точно будет не способен к выстраиванию правильной коммуникации. С остальными задача взаимного удовлетворения решаема.
Ой, спасибо за совет, но конкретно ко мне он не очень применим. Я некоторое время назад начал задумываться о собственной идентичности, и понял, что я скорее программист-интроверт, нежели руководитель. И я, хоть и умею выстраивать коммуникации (директором тоже успел побыть), но на самом деле не очень это люблю. Так что у меня сейчас небольшой собственный свечной заводик интернет-проект, на котором «вкалывают роботы, а не человек» — и меня это замечательнейшим образом устраивает. И конечно, навыки руководителя в собственном бизнесе, сильно помогают, но развивать их не очень хочется.

Небольшая маленькая «месть» за совет :)) — не знаю, интроверт вы или экстраверт, но возможно, вам через некоторое время поднадоест суета большого бизнеса, но выйти из неё будет страшновато. Тогда порекомендую обратиться к юнговской теории поиска идентичности и, в частности, прочитать Дж. Холлиса «Перевал в середине пути».

Возможно, вы даже захотите присоединиться ко мне «в долине Галта» (Айн Рэнд «Атлант расправил плечи»)
Ок, приношу извинения, за советы не в тему -)

Я из другой школы: Чиксентмихайи, Зелегман и Канеман мои друзья -)))
Почему должен платить заказчик? очень просто. Он Заинтересован.
Его интерес в следующих пунктах:
1. Клиент заинтересован в четком бюджете на проект? заинтересован.
2. Клиент заинтереован в четком понимании результат? заинтересован.
Техническое задание помогает ему достичь этих целей.
Клиент может с ТЗ пойти другому исполнителю, но у него уже будут собраны и описаны не противоречивые:
1. цели проекта
2. доменная область
3. бизнес логика
4. технические нюансы (если интеграции с другими системами)
5. критерии проверки результата.

Фактически нормально ТЗ — доказательство достижимости поставленных целей в рамках бюджета.

А есть еще и юридическая точка зрения: у Клиента есть доказательсто того, что Подрядчик его не обманет при приемке:)
Это уже проблема PreSale :)
С точки зрения финансов — составление ТЗ можно провести как отдельную услугу с оплатой.
У буржуинов это нормальная практика. Часто попадались проекты, в которых нужно было только «написать код» по «бумажкам». Да и мои SRS (технические задания) часто делали пару циклов согласования, после рецензирования, у аудиторов, которых оплачивал Клиент.
А в моем текущем проекте, пришлось уделить неделю изучению юридических нюансов, и отправлять Клиенту табличку, как пункты договора и технического задания связаны с конкретными Законами.
По моему нескромному мнению, работа без ТЗ (или аналогичного ему документа) должна вестись на условиях Time&Material, а не по фиксированным ценам.
Присоединюсь к этому мнению.
Кто платит, тот и музыку заказывает :)
Если Клиент оплачивает риски подхода ХЗ без ТЗ — без проблем
А если перекладывает риски на Подрядчика, то это уже дело Подрядчика как делать и делать ли вообще.
А кто оплатит хантинг новых разрабов, которые быстро выгорает при работе без ТЗ? -)
если поставить им рейт $50 на человека, не будут выгорать))
А с чего им выгорать?

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

В чем тут может быть причина выгорания? Срок не давит, цикличность есть…

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

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

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

По своему опыту:
— если вы работаете в одиночку или в паре с одним человеком — не используйте ничего. Делайте всё, как делали раньше. Методология только увеличит издержки, не даст ничего. (Сам пробовал делать UML-диаграммы, документацию и пр.)
— если вы руководитель в команде до 5-10 человек — посмотрите в сторону Agile, какие там практики. Ваша основная задача — синхронизировать ожидания членов команды за счет минимальных ресурсов.
— если вы работаете в большом коллективе — используйте методологию, существующую там. Не лезьте со своей, не портите готовую структуру, только ресурсы потратите, не факт, что построите что-то лучше.
— если вы руководите большим коллективом от 20 человек… то вам мои советы определённо не нужны :)

ТЗ не нужно для взаимодействия с командой; ТЗ нужно для только для взаимодействия с клиентом (и субподрядчиками) за вот этим (см. пункт 6 статьи):
> В процессе разработки не помешает иногда бить креативного клиента распечатанным и подписанным ТЗ по источнику креативной струи, чтобы не улететь с орбиты в глубокий космос.
Последнее согласование ТЗ вылилось для заказчика и, опосредованно, меня, в разрешение глубинных противоречий и войны за влияние между подразделениями предприятия заказчика, поскольку требовало однозначно определить функциональные обязанности сотрудников и подразделений на местах (невозможно автоматизировать бардак). Естественно нашлись и те, кому такая активность «прищемила хвост» и эти люди оказали максимум противодействия при тестировании и внедрении продукта.

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


Поздравляю, вы ознакомились со стадией «идентификация рисков» в управлении рисками. (ISO 31010)
Очень полезная стадия

Как обычно правы все. Только все говорят о разном ТЗ.


Есть ТЗ, которое идет в договор. Оно описывает технические ограничения, например разделы на сайте, браузеры, адаптивный дизайн итд. Это ТЗ делает заказчик, а исполнитель согласовывает как прочие параметры контракта. Если заказчик может выдать подробное ТЗ (вместе с эскизами например) в на этом этапе — отлично, если нет — значит нет. Во втором случае цена будет сильно выше.


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


Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком. Будет кровь пить весь проект. Или взять адекватные деньги за такое. Сумма как раз будет равна (сумма проекта с минимальным ТЗ — сумма с максимально полным ТЗ).

Я вижу такой идеальный путь:

1. Мини-контракт на разработку ТЗ минимальной версии за символическую сумму, за которую делаем:
— 3 странички пользовательских сценариев
— 2 странички текстового описания всех экранов
— 1 страничка этапов работы с демонстрацией
2. Следующий контракт — прототипирование экранов системы на базе утвержденного мини-ТЗ
3. Следующий контракт — дизайн интерфейсов на базе утвержденного прототипа
4. Контракт на разработку первого этапа из мини-ТЗ

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

Идеальный путь это:
1) Когда вам удобно работать
2) Когда вы это продаете заказчику


Все зависит от конкретных людей с обоих сторон и проекта.

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

На сколько я помню ГОСТы (подправте если я не прав), то после ТЗ делается технический и эскизный проекты в которых, на сколько я помню как раз и осуществляется уточнение.

Эскизный и Технический проект — это этапы разработки, а не документы. В рамках этапа может быть много разных документов.


ГОСТ на ИС был сформирован на основе ГОСТа на строительство. Там четко — сначала макеты, потом чертежи, потом стройка. В разработке гораздо чаще встречается ситуация, что двигаться дальше можно только попытавшись реализовать функционал. Это похоже на НИОКР, по которым никаких гостов никогда не было.

ГОСТ РВ 15.105-2001 «Военная техника. Порядок выполнения научно-исследовательских работ и их составных частей. Основные положения».
ГОСТ РВ 15.203-2001 «Система разработки и поставки продукции на производство. Порядок выполнения ОКР по созданию изделий и его составных частей».
ГОСТ 15.110-2003 «Документация отчетная научно-техническая на научно-исследовательские, аванпроекты и опытно-конструкторские работы».
Если идти по ГОСТу 34.601-90, то стадии такие:
1. Формирование требований к АС (на выходе — тактико-техническое задание).
2. Разработка концепции АС (на выходе — отчет, содержащий согласованную концепцию).
3. ТЗ.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение.

Обычно на стадии 1 и 2 забивают совсем, 3-ю иногда удается выцыганить, 4 — получается редко. 5 и 6 часто сливают вместе — и хорошо если 7 — отдельная от них стадия.
На 8 денег нет, но если что — мозг клевать попытаются.
В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами.

Это называется НЕ техническое задание, а «техническое решение»
Фактические это архитектура системы и является результатом работы системного аналитика/архитектора.

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

По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это. Но поскольку это работа, и результат «осязаем» и валидируем (серия стандартов ISO 250xx) то нужно дововариваться о оплате.
Бесплатно делать такое — это безумие
Кстати, часто бывает, что «техническое решение» не очевидно.
В этих случаях предлагаю составить ТЗ на исследовательский этап -)
Т.е. ТЗ на НИР/НИОКР получается -)
Обычно предлают «MVP» — нарезать «на кусочки», которые достижимы и валидируемы, и понижают риски «просадить бабло».
А если Компания пытается сделать, проект по которому нету компетенций — то сами себе злые буратины.
Обещали построить термоядерный реактор из палок и платилина, но не смогли? Добро пожаловать «на костер» :)

Это называется НЕ техническое задание, а «техническое решение»

Называться может как угодно. Не в словах дело.


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

Вы как-то себе противоречите. Если договора нет, то о какой оплате речь идти может?

Если договора нет, то о какой оплате речь идти может?

Это и становится предметом договора.
— Клиент, Вы согласны выделить бюджет и оплатить работу Подрядчика, со следующим результатом ...? Да / Нет.
— Клиент, Вы можете использовать результат работы или с нашими разработчиками, или с устроить тендер для любых иных подрядчиков. Вам понятны Ваши возможности? Да / Нет

UFO just landed and posted this here
не могу, добавить, боюсь, что отвалится собранная статистика
Сам опросы не добавлял, но вроде бы народ вполне правит «на лету». В любом случае можете уточнить у администрации, они реагируют.
Продуктовая фирма.
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
Или в ТЗ по почте, аське, жире внесено 100500 правок, что никто точно не знает, что и как должно работать :)
На просьбу формализировать требования сопротивляются.
Иногда сам привожу ХЗ в ТЗ, прежде всего, чтобы самому понимать, что и как должно работать :)
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)

Об аутсорсе и говорить нечего. :)
На каждую правку в жире требуйте «ТЗ на правку», согласованную с клиентом и с разрабами. Будет счастье -)

По этой схеме я вытянул массу запутавшихся проектов -)
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.

На просьбу формализировать требования сопротивляются.

Используются технические средства типа Change Management System: Jira / TFS / EA и т.д.

Без инструментов приносящих пользу всем сторонам — так и будет развиваться :)
А если прикруть к этому систему «считать деньги и таски» — то вообще будет счастье. Можно будет получить ответ на вопрос: а зачем сделали, сколько это стоило и почему

Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)


Если учесть, что результат работы БА — прояснения и непротиворечивость результат, то ребята не выполняютс свою работу :) Уволить нафиг
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.

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

А вы сталкивались с крупными проектами? Как потом складывали эти кусочки?
А вот для этого и используется «бумажка» :)
Проектная документация и инструментальная поддержка. Система отлично собирается и поддерживается годами.
Для проекта бюджетом в пару миллионов долларов, система на пару десятков тысяч долларов — фигня.
А вот косяки предовращает — на ура.
Кусочки всегда складывались, возможно мне везло -)
Фигня это всё.

Нет ТЗ?

Отлично, работаем на почасовке.

А там хоть клоны, хоть чего пусть придумывают.

Время идёт, работа идёт — деньги идут.

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

А исполнитель (обычно) мечтает так же руками развести, и сказать — «получится не как вы сказали, а вот такого размера, и будет дыр-дыр-дыр звучать, но работать будет, и денег мне побольше».

Пока опыт их не столкнет с мыслью, что работа — это не только софт и железки, но и мысли, оформленные на бумаге, и что сдача работы — это не воды налить в пояснительную записку, а именно смысл работы и идеи в ее основе лежащие изложить так, чтобы следующий за тобой мог разобраться через N лет, ничего не будет толково делаться.
оооо я тоже когда-то работал в Hardware, даже потоковый процессор проектировал и спецвычеслители всяко-разные -)
Видел обратное: изготовитель сайта (один из ТОП-10 по версии кого-то там, не совсем чтобы студия из подворотни) решил срубить с клиента бабла, и ТЗ старался не писать, чтобы его не притянули.

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

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

P.S. И, да, ТЗ, когда разговор приходит к нему, писать-то мало кто умеет. Более того, термин расхожий, а ведь в ГОСТе есть четкие обределения, требования и прочее. Когда исполнителя тыкают носом туда, начинается рев, как в детском саду. Потому что он понимает, что игры кончились, и эту работу (чуть ли не впервые в жизни) нужно будет сделать от и до — притом не бесплатно — а он-то и не умеет. По крайней мере, не умеет с разрекламированной им про себя степенью профессинализма.
А как быстрее/качественнее научиться ТЗ писать?
в голосовалке не хватает пункта «я тот, кто специализируется только на написании ТЗ» )
по структуре самого техзадания — помимо пользовательских сценариев вместе с прототипами (экранами) должно быть описание работы программного модуля — как рубрицируются данные, как они обновляются (если предусмотрено автоматическое обновление из интегрированных систем), в каких случаях и кому улетают почтовые уведомления и т.п. Расписать состав элементов БД для каждого модуля тоже бывает полезно — экономит кучу времени и в процессе не грузит заказчика дополнительными вопросами типа «а должна ли в каталоге стоять дата последнего обновления цены»
Если заказчик хочет работать без ТЗ, но понимает все риски и готов участвовать в работе и оплачивать за нужный темп работы команды, то можно продать ему Scrum команду (ну или другую методологию Agile)
Нюанс в том, что в Scrum(Agile) все равно есть этап анализа и рассмотрения Story и критериев приемки, юнит-тесты и QA, которые все равно должны базироваться на чем-то конкретном и доказать что «Оно делает что надо». В противном случае на этапе «покера» просто не смогут договориться «что делать», не говоря уже «как делать».
Хорошим тоном считается не брать в BackLog спринта User Story, которая не сопровождается критериями приемки.
Так что миниТЗ все равно есть.
Такого опыта нет, к сожалению -(
Слышал от людей что в одной из стран ЕС они так гос проект разрабатывали.
По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя. Это уже не ТЗ а функциональная спецификация, и уже на её основе команда пишет техническую документацию или ТЗ в котором описывает что и как предполагается делать вплоть до моделей, эндпоинтов апи, архитектуры, стэка технологий. Чаще всего, функционалки достаточно что бы сделать типовый проект которые уже в компании делались не раз и имеют очень легкие отклонения в функционале. Если же проект не типовый то полному циклу.
По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя.

Это разные документы и служат разным целям и они взаимо дополняющие.
TЗ — это что надо сделать
Функциональная спецификация — как сделать то, что указано в ТЗ

Пользователь скажет: Хочу отчет по продажам.

ТЗ будет включать:
  • ТЗ-1.1 Система должна предоставлять Отчет по продажам «в штуках». Форма отчета см…
  • ТЗ-1.2 Система должна предоставлять Отчет по продажам «в деньгах». форма отчета см…
  • ТЗ-1.3 Система должна предоставлять возможность экспорта отчетов в формат PDF
  • ТЗ-1.4 Система должна предоставлять возможность экспорта отчетов в формат Excel xlsx


Функциональная спецификация будет включать:
  1. Пункт ТЗ-1.1 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
  2. Пункт ТЗ-1.2 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там

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

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

Вот вам в помощь материалы:  

1. Схема мыследеятельности для работы над проектом. http://files.pavlyut.com/mindactions_v2.2.3.png 
2. (разбор ее на видео https://www.youtube.com/watch?v=4erC7e8RyZM)

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

Ваш идеальный проект сейчас живет в ваших внутренних мирах. Чтобы он стал доступен всем нам для пользования он как-то должен перекочевать в более менее “том самом” состоянии, похожем на то что у вас в ваших внутренних мирах задумано.

Для успешного «перетекания” проекта из состояния замыслов он сначала попадает в артефакты (схемы, сценарии, интерфейсы), потом “воплощается” (слово не понравилось почему-то, но оно понятное всем потому что мы даем проекту “плоть” и он “объявляется” тут как тут в пространственно-временном измерении — это там где тыкать в него можно).

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

На схеме то что вы в состоянии извлечь из себя “внаружу” для воплощения проекта, а я в свою очередь не в состоянии это сделать самостоятельно, но в состоянии вас “помассировать” чтобы из вас это вышло  - это все находится в левой первой части схемы “Окружающая действительность”.

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

Я надеюсь что вам понятно о чем я тут написал, это письмо нужно для того чтобы уберечь нас от очередной „не своей” работы, которую вы скорее всего выполните (есть вероятность отличная от ноля) не совсем корректно, и будет переработка. 

Все это нужно, это все равно “где-то” есть или “подразумевается”, но пока это не описано — проект проинзан дичайшими рисками на перерасход, невыполнение своих задач (построили а задача-то не это, как ее, это самое — тютю), и так далее.

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

Ваш продукт (товар или услуга):
1. Что Вы продаете? Зачем и в какой ситуации это покупают?
2. Какую проблему в жизни или в бизнесе Ваш продукт решает?
3. Почему клиенты покупают именно Ваш продукт?
4. Расскажите, как устроен продукт? Из каких частей он состоит?
5. Честно укажите преимущества и недостатки.

Ваша компания:
1. Почему так называется компания? Как появилась идея?
2. Что привело Вас в этот бизнес?
3. Расскажите историю по шагам и вехам развития.
4. Представьте компанию в цифрах (год/месяц/начало существования)
5. “Разрежьте” свой бизнес по направлениям товаров и услуг, по клиентским категориям, по регионам и странам, по каналам продаж и т.д.

Ключевое лицо или лица компании (Вы или Ваши партнеры):
1. Откуда родом?
2. Семейный статус.
3. Предки и род (семейное дело)
4. Карьера (опыт в данной сфере и других сферах)
5. Кто учитель? (известный мастер)
6. Какая “профессиональная школа”? (компания-эталон)
7. Личные награды и достижения (в том числе и непрофессиональные).
8. Участвует ли каким-то образом в социальной, культурной и политической жизни.

Ваша команда:
1. Кто ключевые люди в компании?
2. Биография, опыт, знаковые проекты и клиенты каждого.
3. Как выглядит организационная структура?
4. Как выглядит схема взаимодействия с клиентом? (Кто и как работает над клиентом, кто общается с клиентом, кто участвует в проекте и на каких стадиях)
5. Как Ваша компания развивает и обучает своих сотрудников?

Клиенты, опыт и портфолио:
1. Есть ли у Вас клиенты-звезды? (люди и организации)
2. Расскажите про свои самые значимые проекты и достижения.
3. Расскажите про самые сложные проекты.
4. Какие вопросы задают Вам клиенты чаще всего?
5. Какие самые частые клиентские сомнения, страхи, стереотипы и возражения?
6. Что именно в Вашем предложении “цепляет” клиентов сильнее всего?
7. Можете ли Вы хотя бы примерно оценить, сколько денег вы сэкономили для своих клиентов или помогли дополнительно заработать?

Сервис и условия:
1. Распишите основные этапы работы с клиентом от первого обращения до получения Вами денег и выполнения работ
2. Расскажите, как Вы сопровождаете клиента после покупки.
3. Опишите самые удачные акции, которые Вы проводили.
4. Дарите ли Вы своим клиентам подарки и в каком случае?
5. Как Вы собираете обратную связь от клиентов?
6. Как Вы работаете с претензиями и рекламациями?
7. Сформулируйте 3-5 “не продуктовых” причин, почему объективно выгоднее покупать у Вас, а не у конкурентов.

Детали и мелочи:
1. Используете ли Вы уникальные материалы?
2. Владеете ли Вы уникальными технологиями и методиками?
3. Можете ли Вы разобрать продукт или услугу и описать его по элементам?
4. Раскройте секреты, ноу-хау и ньюансы, которые больше никто не использует.
5. Работают ли с Вами уникальные, единственные в своем роде специалисты?
6. Укажите те детали и мелочи в продукции или услуге, по которым можно судить о безупречном качестве.

Вот только лишь десятая часть десятая часть тех вопросов, которые уместно вставить в рамках электронного письма. Конечно же Вам не стоит ими ограничиваться. Без отрыва от работы это может занять от 10 дней до нескольких месяцев. Также важно качество упаковки и лучше, чтобы это сделал профессионал.
А такой вариант встречали: «Я вам плачу деньги за разработку, если у вас не хватает знаний как автоматизировать моё предприятие, так это ваши издержки за которые не вижу смысла платить». )))

А многие проекты могут и не начаться, поскольку: обговорили — написал, посмотрели — это забыли — обговорили… бесконечный круг. А за каждую новую редакцию платить деньги клиент не согласен.
Конечно, постоянно встречаю, и в целом они готовы платить -)
У меня был интересный случай в практике.

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

А через неделю пишет, что мол все, уже ничего не надо. Работая над функционалом он вдруг осознал, что не придумал ни целей ни задач.
Есть такое, это обратная сторона медали.
У многих после формализации осознания пыл остывает -)
То что вы описали часто происходит на сеансах у нормальных психологов, человека просят оформить конкретные цели и хлоп — проблемы то и нет, а хочет он совсем другое.
Произведение оптимизма на знание — величина постоянная
©Ландау
Я разработчик и так уж вышло, что обычно, работаем без ТЗ.
Когда мои друзья не из IT спрашивают у меня, — «как дела на работе?», то мой ответ примерно таков:
«Да как всегда… занимаюсь сексом… и мне ЭТО НЕ НРАВИТСЯ»
#есливыпонимаетеочемя :(
Была у нас история одна забавная и приятная по работе без ТЗ, заказчик нас привез в Москву (у них было много бабла, но все сроки они просрали) два дня нас возили по белокаменной, кормили в ресторанах, жили в клевном новом отеле с реальными пятью звездами, улетели и прилетели за их счет, еще денег сунули каждому в конверте, а в итоге заказали у каких-то других чуваков :)
И все равно расстраивает такое -)
Потому что — зря. Впустую выброшенное время жизни. Как секс без обязательств — приятно, но бессмысленно.
Sign up to leave a comment.

Articles