1. «У нас очень маленький и простой проект»
Когда я умру, и черти придут тащить меня в ад, они начнут именно с этой фразы. С каждым шагом они будут рассказывать мне о том, как вспомнили о каком-то новом ерундовом функционале, который изначально подразумевался и всем очевиден…
Сколько шагов нам придется пройти, не знает никто, но если я дойду, я стану святым.
Еще в народе популярен похожий подход: «Нет времени на ТЗ, нужно скорее запускаться».
Решается это просто: даже на самую маленькую задачу можно составить мини-ТЗ. Скажу больше, я просто обожаю маленькие и простые проекты за то, что их можно ясно описать. Большие проекты я стараюсь распилить на маленькие.
Если «маленький и простой проект» застрял уже на стадии согласования ТЗ, значит, вы умело распознали чертей до того, как они сварили вас в своем котле.
2. «Это коммерческая тайна, мы вам не расскажем»
Как-то я писал ТЗ на большую и сложную медицинскую систему… Но это было приложение для театров. Чтобы я не догадался, что речь про театры, клиент рассказывал мне про врачей. Когда же был наконец подписан NDA, мне торжественно объявили: «Ну это же одно и тоже! Механика похожая: актеры или врачи — какая разница? Почему вы так расстроились?».
Казалось бы, почему не подписать со мной NDA сразу? Но нет, бумага не дает 100%-ю гарантию. Надо же познакомиться и узнать меня получше! Вдруг я раскрою военную тайну?..
Был еще секретный сайт знакомств: «У нас есть такие приборы, но мы вам о них не расскажем.» Или же: «У нас тут мега-секретный проект, скажите сколько стоит?».
Как только я слышу о секретности, которую не закрывает NDA, то сразу же предлагаю взять паузу до тех пор пока клиент не созреет. К сожалению ТЗ, написанное намеками на то, что-нельзя-называть, разрабы не понимают.
3. «Сначала скажите сколько стоит!»
Клиент не уверен, будет ли у вас заказывать, но если закажет, вам же хуже. «Окей, нам подходит, стартуем работу, времени на ТЗ нет! Ой, а вы же обещали, что все будет дешево и быстро! Как же так! Ну это же очевидно, что все должно работать не так, а так! Как это мы не договаривались? Верните деньги!».
Вопрос цены проекта до составления ТЗ, наверное, самый частый. Хочется в двух словах описать проект и собрать со всех знакомых и незнакомых команд котировки. Обычно замечание, что цена может вырасти в 10-20 раз по мере детализации никак клиента не впечатляет: “Ну, вы же — хорошие ребята! Вы же так с нами не поступите!”.
В целом желание клиента получить котировки и провести мини-тендер — это нормально, но делать это надо, разослав командам полноценное ТЗ!
4. «Почему мы должны платить за то, что нужно вам?»
Клиент прикидывается золотой антилопой и искренне негодует, что вы пытаетесь заставить его заплатить за капкан, которым хотите его поймать. “Мы же компания “УХ!” Если мы будем в числе ваших клиентов, все скажут: “Ах!” Требовать с таких клиентов, как мы, деньги с порога — просто неприлично!” Однако, дорогой клиент, черепки из-под твоих копыт уже стоят поперек горла, и хочется крикнуть: “Довольно!”.
Если клиент не хочет платить за ТЗ, плохо будет всем:
Во-первых, это не позволит потратить на ТЗ необходимый объем рабочих часов, внести все правки и добиться утверждения.
Во-вторых, если клиент не хочет вам платить за ТЗ, то захочет ли он платить за разработку в полном объеме?
К бесплатным ТЗ клиенты часто относятся легкомысленно и воспринимают их скорее как коммерческое предложение, а не как что-то требующее внимания, напряжения участия. По итогам работы по бесплатному ТЗ вы можете услышать: «Нам нужно решение задачи, а не ваши бумажки!»
Почему же нужно платить за ТЗ? Например, потому, чтобы не оплачивать риски, которые обычно закладываются в разработку без него.
5. «Мы хотим увидеть варианты!»
Мое любимое. С этими товарищами каши не напишешь, т.к. вымучить 3-4 разных ТЗ на выбор — выше моих сил.
Этим клиентам я обычно предлагаю услугу проектирования идей. Работает это так: договариваемся о формате представления и количестве идей, пишем для примера первую идею, после этого креативим со всеми знакомыми и друзьями по формату.
Смех тут в том, что если вы слышите: «Мы хотим увидеть варианты!» — то все равно начинать необходимо с ТЗ. Только ТЗ нужно составить не на систему, а на идеи. Да-да, бывает мини-задание на идеи. Очень полезная вещь, рекомендую!
6. «А вдруг у нас изменится концепция»
Кажется, что-то похожее говорили поляки Сусанину… Такой клиент, как правило, считает, что ТЗ как-то ограничит его полет мысли, фантазию и творческий креатив. Обычно, все это кончается в глубоком болоте, в котором никто уже не знает, куда мы едем и о чем мы договаривались.
При этом, когда есть даже самое простенькое ТЗ, которое позволяет сдвинуть проект, креативный клиент весело впрягается в работу, и его бурное фантанирование уже не разваливает проект, а придает ему силу реактивной струи.
В процессе разработки не помешает иногда бить креативного клиента распечатанным и подписанным ТЗ по источнику креативной струи, чтобы не улететь с орбиты в глубокий космос.
7. «Нам нужен точный клон этого...»
Вот на такое я не люблю писать ТЗ. Страшно изматывает. Какие-то веселые ребята пилили какую-то систему годами, она обрастала всевозможными рюшечками и наворотами, и теперь весь этот фарш, к которому шли постепенно и эволюционно, нужно сесть и описать. Работа для настоящих следопытов!
Как жаль тех разрабов, которые ввязываются в клонирование без ТЗ. Ну это как будто вы, глядя на героев Mortal Kombat, пытаетесь научиться драться. Также смешно и жалко.
И еще из опыта: часто бывает так, что к «точному клону» потребуется «пара незначительных модификаций», которые само-собой рушат всю логику и механику донора.
Пишу, а в почте как раз очередной запрос на точный клон этого…
8. «Придумайте сами — вы же специалисты!»
«О да, мы специалисты!» — говорит обычно коммерческий директор и важно надувает лоснящиеся щеки. «Сейчас мы расскажем вам, как лучше! Мы же знаем, мы же — специалисты, у нас же — компетенции!!!» После этих слов у клиента загораются глаза и он думает: «Вот, наконец, я нашел людей, которые сразу поняли суть моего проекта, услышали меня!».
Обычно мираж окончательно рассеивается на втором десятке раундов правок готового проекта.
Недавно как-раз вытягивал завязший проект. На 32-ом раунде правок, длившихся полтора годика, решили все-таки написать ТЗ на правки, и все быстренько финализировалось.
9. «Мы сами напишем/написали ТЗ»
Однажды подключившись к одному, слегка затянувшемуся на несколько лет проекту, я наконец спросил: «Ребята, а у вас было ТЗ?» На что мне ответили: «Где-то у нас был видеоролик, на котором клиент рассказывает что хотел.»
Часто клиент присылает какой-то треш с клоунами на вертолете. Но я — не жадный, я в ответ даю примеры заданий, составленных мною, и прошу оформить все в таком же формате. После этого “самописцы” пропадают на полгодика.
Но есть клиенты, которые действительно сами написали ТЗ очень понятно. Один из самых моих любимых клиентов согласился все заполнять в моем формате и делает это регулярно на радость разрабам. И конечно некоторым клиентам ТЗ составляли специалисты, что тоже приятно.
10. «Другие программисты не примут ваше ТЗ»
Довольно часто слышу это возражение. Обычно принимают, так что смело предлагаю переписать под новых разрабов, если не примут. Был забавный случай. Сдал ТЗ, а разрабы на стороне клиента говорят, что это не ТЗ. Ну давайте ваш формат — переделаю. Формата нет. Ну скажите что не нравится? Говорят, мол, не по ГОСТу! Ну, давайте сделаю по ГОСТу, но за доп. плату. Вы ГОСТ-то видали? Похоже, что нет.
Из опыта я знаю, что очень многие разрабы не читают ТЗ. Поэтому лучший способ с этим бороться — читать его вместе с ними. Лучше всего воспринимается сценарий действий пользователя и описание экранов. Эти два документа обычно исчерпывающе описывают систему. Иногда к этому добавляется API и таблицы с математикой, если есть.
А вот есть, например, ТЗ по ГОСТу с тендерных площадок, или же гигантские API на 300 типов запросов. Тут мне приходится переводить уже для разрабов на человеческий язык.
Надеюсь ничего не забыл. Расскажите о своих кейсах, и методах работы с возражениями. Буду рад выслушать ваши мысли как в комментах, так и в ЛС.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (144)
Loxmatiymamont
14.11.2016 12:59И где-же пример вашего супер формата?
krivotester
14.11.2016 13:13+2Формат простой, всего три документа:
1. Сценарии
Цели:
Задачи:
Пользовательский сценарий 1
Шаг 1
Шаг 2
…
Шаг n
Пользовательский сценарий 2
Пользовательский сценарий N
2. Описание экранов
Экран 1
Экран 2
…
Экран n
3. План демонстрации промежуточных стадий системы
Демонстрация 1
Демонстрация 2
…
Демонстрация n
Иногда к этому добавляется API в swagger и математика в XLS, если есть
RomanYakimchuk
14.11.2016 17:04Не аналитик, но добавлю еще несколько пунктов, которые облегчают жизнь:
- Диаграмма последовательности (как альтернатива пользовательскому сценарию)
- Блок-схемы демонстрирующие как должен работать, например, реализуемый API
Сильно экономит время и очень упрощает понимание некоторых разделов с требованиями.
В реальности, насколько я знаю, аналитик может потратить на составление диаграмм и блок-схем тонну времени, но оно того стоит. Исключает многие дальнейшние вопросы на корню.
Немного уйду в сторону, но блок-схемы особенно полезны при описании того, как технически работает продукт, какая-то его конкретная функциональность. Очень экономит время, потому что вопросы по работе системы возникают постоянно, ответы забываются, и времени на повторное объяснение уходит многократно больше, особенно если в проекте участвует много сторон, и всем нужно знать, как работает система.
krivotester
14.11.2016 18:37Спасибо, добавление разумное.
Иногда я использую майн-карты и mindmaster для этого.
Fesor
15.11.2016 00:45как развитие этой идеи есть еще модная штука — стори мэппинги всякие. Позволяют организовать одномерный бэклог в двумерную карту. Очень удобно для приоритизации.
svboobnov
15.11.2016 13:40Вот тоже поддержу схемы и диаграммы. У меня самого лучше получается понять суть процесса, если я смоделировал его в диаграмме, а ещё, бонусом, я могу в два-три раза быстрее объяснить происходящее коллеге.
KonstantinSamsonov
14.11.2016 19:27Приёмочные тесты тоже не помешали бы, пусть только по базовому функционалу и просто написанные без автоматизации…
Lofer
14.11.2016 20:40В принципе, это не часть ТЗ. Хотя может быть пункт в критериях приемки, например: функционал Fx проверяется согласно следущих тестов.
Это часть методологии приемки, которая оговаривается юридически в контракте (лучше уточнить у юристов для соответсвующей юрисдикции).Gray_Wolf
14.11.2016 21:27Да зачем здесь юристы, почти все документы составляют инженеры.
В данном случае составляется документ «Программа и методика испытаний» в котором описано пошаговое выполнение программным обеспечением требований ТЗ, вида:
спойлер1. В браузере IE 8.0 открыть «Портал автоматизации всего» по адресу http://site.com
2. В окне авторизации ввести данные УЗ пользователя портала.
3. В левой части окна выбрать пункт меню «Настройки».
4. Во вкладке «Настройки интерфейса» в выпадающем списке поля «Язык» выбрать English.
5. Нажать кнопку «Сохранить настройки».
6. Убедиться в наличии англоязычного интерфейса в портале.Lofer
14.11.2016 21:39Это, к сожалению заблуждение. Перепутана причина и следствие. Просто тех работники редко задумываются и читают юридические «бумажки», как и юристы технические.
У меня Закон звучит так:
1. Качество выполненной подрядчиком работы должно соответствовать условиям договора подряда, а при их отсутствии или неполноте – требованиям, обычно предъявляемым к работам соответствующего рода. Если иное не предусмотрено законодательством или договором, результат выполненной работы должен в момент передачи заказчику обладать свойствами, указанными в договоре или определенными обычно предъявляемыми требованиями, и в пределах разумного срока быть пригодным для установленного договором использования, а если такое использование договором не предусмотрено, – для обычного использования результата работы такого рода.
2. Если законодательством или в установленном им порядке предусмотрены обязательные требования к работе, выполняемой по договору подряда, подрядчик, действующий в качестве предпринимателя, обязан выполнять работу, соблюдая эти обязательные требования.
Как бы я не изворачивался, но должен следовать, иначе Клиент меня просто «на органы продаст» что бы «компенсировать убытки» или буду «пожизни баги фиксить». :)
Полагаю в РФ есть что-то весьма похожее, тем более что есть ГОСТ ИСО/МЭК 25041-2014. Не думаю что просто так его сделали
krivotester
18.11.2016 19:31Иногда делаем. Особенно когда API на стадии ТЗ проектируется.
Обычно приемка по сценарию пользователя происходит и всем ок: и клиенту и разрабам.
Scf
14.11.2016 12:59+2Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.
krivotester
14.11.2016 13:16На практики это, казалось бы очевидное утверждение, встречает массу возражений -)
shuvaevgl
14.11.2016 13:12+6Был на стороне разработчика и заказчика. С тех пор имею седые волосы в самых неожиданных местах!
KonstantinSoloviov
14.11.2016 13:56+4Это легко исправить: повнедрять и посопровождать — раз! И вообще волос нет :)
krivotester
14.11.2016 13:57я повнедрял и посопровождал от души и много лет, и продолжаю
волосы норм
кому бы делегировать? -)))KonstantinSoloviov
14.11.2016 14:10И обратно к любимому занятию? И ж чего хотите, там своих молодых да ранних, вот таких Чапаевцев (КДПВ очень в тему кстати) с шашкой наголо хватает — без ТЗ по ночам… По четко поставленному ХЗ!
krivotester
14.11.2016 14:16+1По Чапаеву были сомнения будет ли правильно воспринят. Вы их развеяли, спасибо за фитбэк -)
EndUser
14.11.2016 13:12+1Действительно, мало кто понимает, что программный продукт есть продукт сотрудничества сторон. Денег недостаточно. Обязательно требуется компетенция заказчика, его организационные движения на его стороне.
В такой трактовке верный коммент выше — «Заказчик должен (быть готовым) вложить свои внимание и усилия в достаточно полное описание задачи». Без этих усилий это просто «кнопка „сделайте хорошо“».krivotester
14.11.2016 13:19+1Вообще, клиенты, которые не болеют за проект — отдельная болезненная тема.
Действительно мало кто понимает это.
Areso
14.11.2016 17:52Это свойственно, когда заказчик и эксплуатант системы — разные люди (подразделения). К примеру, заказали новую систему биллинга, а инженерам, сидящим на поддержке старой — это нафиг не надо, хотя операторы системы, наоборот, радостно ждут переписанную ИС (ибо старой уже больше 15 лет, а код состоит в основном из костылей). Понятно, что несмотря на свою экспертизу, инженеры от нового проекта и подрядчика отмахивались почти не глядя. Ведь новую систему нужно будет изучать с 0, учить новый ЯП, изучать новую IDE.
Другой пример. Финансовое руководство предприятия, недовольное вечным бардаком на складах и кипой вечно теряющихся бумаг, заказало написание и внедрение сферической ИС «Склад». Надо ли упоминать, что кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?
И таких примеров уйма. У всех свои интересы, даже внутри одного предприятия.krivotester
14.11.2016 18:44Понимаю вас, плавали — знаем. Если заказчик не заинтересован в проекте, наверное лучше вообще отказаться. Не понятно как его сдавать в этом случае сдавать проект.
Ivan22
15.11.2016 10:26заказчик заинтересован. Просто не надо путать тех кто будет эксплуатировать с заказчиками.
MacIn
14.11.2016 21:38+1expertise (англ.) = опыт, специальные навыки, мастерство, компетентность.
экспертиза (в устоявшемся в русском языке смысле, например, «проведена криминалистическая экспертиза») = inspection, expert report, evaluation
Vjatcheslav3345
15.11.2016 10:43+1кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?
Так ведь надо, чтобы не было проблем с внедрением, постараться понять и этих людей и инженеров и вообще всех участников процесса и учесть их интересы (найти и предложить им в системе "сладкую конфетку"), даже если формально заказчик и не заплатил за это денег — все равно потом нервы себе же сэкономите при внедрении.
А от заказчика нужно требовать, чтобы он обеспечил возможность общения со всеми типами пользователей системы — а не только с отдельными или приемщиками. Ну и всем видам пользователей системы при личном общении можно донести мысль — что разработчики им не враги а их друзья и они помогут им избавиться от жесточайших застарелых геморроев старого ПО и даже, сохранят похожий на старый алгоритм работы и интерфейсы программ (конкретно для кладовщиков — ПО будет имитировать своими формами ввода "картонные карточки", только уже на экране монитора или их переносных терминалах).
ivorobioff
14.11.2016 13:16+1Я бы сказал ТЗ нужно, но не слишком детальное. Во-первых, действительно, на слишком детальное ТЗ уходит кучу времени и сил и чем детальней ТЗ тем больше вещей будет изменено в ходе разработки, что опять же заставит клиента задуматься над идеями и концепциями и тратить на это время. Что для разработчиков, я бы советовал писать код так чтобы его можно было легко расширять или модифицировать подстраиваться под новые детали и изменения. Конечно, изменения не должны быть слишком глобальными.
Второе, когда клиент просит оценить проект без ТЗ я обычно основываюсь на интуицию и опыт, и это же говорю клиенту, чтобы он был в курсе из чего исходят мои оценки и почему.krivotester
14.11.2016 13:18Обычно сценарий у меня занимает 3 странички.
Предлагаю реализовать минимальную версию системы для начала, а дальше апгрейдить -)
hlogeon
14.11.2016 18:40Поиск минимально необходимого уровня формализации — отдельная тема. Если в случае с хипстерским стартапом ТЗ на 5 страничек А4 — вполне себе нормально, то для какой-нибудь системы учета для предприятия оборонной промышленности ТЗ должно быть максимально детальным и подробным. Все очень зависит от сферы и конкретного проекта.
Visphord
14.11.2016 13:43Если есть такая возможность — выложите, пожалуйста, один пример вашего ТЗ.
krivotester
14.11.2016 13:50Формат дал, я дал здесь: https://habrahabr.ru/post/315046/#comment_9909048
а пример в паблик вывливать не могу — все примеры только живые -)
vics001
14.11.2016 13:46Я почему-то не понял, почему за ТЗ должен платить заказчик. ТЗ как и договор требует времени с обоих сторон, каждый тратить время, то есть деньги. Понятное дело, что ничего бесплатным не бывает, но реклама и привлечение клиентов тоже стоит денег, составление ТЗ, договора, оферта должно входить в начальный бесплатный пакет.
У вас какой-то свой формат свои требования, а деньги хотите записать на клиента. Делайте его менее детальным или бюджетным не важно, возможно, у вас какой-то другой сегмент заказчиков, но я в него не попадаю.
P.S. большие компании вообще делают pre-sales программы, которые стоят до 50К-100К и которые никак не возвращаются напрямую.krivotester
14.11.2016 13:55+3Эммм, ну вот я аналитик.
Мне платят либо клиенты, либо разрабы.
Написали, допустим, 10 разным клиентам ТЗ, потратили по 20 рабочих часов на каждое, т.е. 200 рабочих часов в сумме.
Все они сказали спасибо, и пошли думать, а скорее всего устраивать тендер между разными разрабами, кто дешевле даст ценник.
Эти 200 часов на кого прикажете повесить? На 11-ого клиента, который дошел до контракта?vics001
14.11.2016 14:08-1Тогда мне это сложно ответить, по вашей статье было понятно, что у вас студия разработки, то есть у вас есть аналитики, программисты и т.д. В случае, если вы один аналитик, я затрудняюсь вообще ответить, как вас находят клиенты, если разрабатывать будете не вы.
По поводу того, что уйдут к другим разрабам с вашим ТЗ. Составляя ТЗ вы себе упрощаете жизнь, вы подробно написали про это, а вешаете на клиента. Не хочу ТЗ — не составляйте или не составляйте подробно, чтобы все детали не ушли к другому. В случае студии или компании, если ваш подход не вдохновил как вы составляете ТЗ, то вы гораздо больше денег теряете, когда заказчик уходит после составления ТЗ.
krivotester
14.11.2016 14:29+2Какой у вас % проектов доходит от разговоров до ТЗ?
Какой у вас % проектов доходит от ТЗ до оплаченного счета?vics001
15.11.2016 03:06Я либо чего-то не понимаю, либо мы опять же в разных областей пытаемся притянуть свое видение.
У меня встречный вопрос, сколько стоит ТЗ в процентах в среднем от оплаченного счета?
Сколько людей заказав ТЗ не делают дальше никаких работ в процентах?
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Я иду к юристу, рассказываю проблему или спрашиваю совета, как оформить контракт или могут они предоставить некоторую услугу и как. Консультация бесплатная — дальше работа. За время консультации по сути рассказывают план действий, из которого четко видно ТЗ.
P.S. я чаще выступаю как заказчик.Gray_Wolf
15.11.2016 09:02Сколько людей заказав ТЗ не делают дальше никаких работ в процентах?
Вся суть бизнеса сводится к уменьшению издержек, при прочих равных выбор будет делаться в пользу более дешевого варианта.
А в процентах сложно сказать, где то необходимо ТЗ, где то НИР, кто-то вообще просит спроектировать ему систему, а внедрять он будет своими силами.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Пока вы один и вы чётко представляете чего хотите это может быть и так.
Но в жизни как правило приходится иметь дело не с 1 человеком, а с организацией.
Куча людей выдвигают различные и часто взаимоисключающие требования к итоговому продукту.
Согласование занимает пол сотни раундов и пол года времени. Выполнять подобные работы бесплатно — безумие.
foal
15.11.2016 10:59К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Не совсем хороший пример — я менял проводку, и чётко знал, что я хочу — рабочие взяли деньги только за работу и материалы. Да смета бесплатная, но это и не ТЗ. Это предложение основанное на ТЗ. А сейчас я думаю о ремонте в ванне и понимаю, что без проекта никак, а он стоит денег.
Ну и консультация у юриста тоже не бесплатная, по крайней мере в Праге.
Lofer
15.11.2016 11:21К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ,
Ключевой вопрос: откуда вы взяли ПЛАН?
Как следствие: вам сделали по ВАШЕМУ плану — постройка утонула или не выполнила ожидаемое. К кому претензии? К Вам или к строителям?
Если вы «купили» план — вы за него заплатили «тому парню», если вы сделали его сами — вы заплатили своим временем как минимум.
Заказчик платит в любом случае :)
Если Вы еще «не вынесли» мозг строителям, вам покажут пальчиком на сомнительные моменты и уточнят пару деталей — это будет бесплатно.
Но если вы «вынесли» мозг строителям — они вам сделают как «заказано», и ни одна зараза не намекнет, что марка труб у вас «тонкая и ржавеют с нашей водой» или штукатурка фиг подходит под климат или еще что…
Так и с ТЗ для клиента — адекватный, можно и соломку ему «подстелить».
Можно сказать что согласно ЗАКОНУ а можно и не говоритьЕсли иное не предусмотрено договором подряда, заказчик, принявший результаты работы без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)
krivotester
18.11.2016 19:39В строительстве:
— замена двери, если не заказываешь, то выезд сметчика платный
— замена окон — тоже
— дизайн-проект на ремонт — платный, бриф на дизайн-проект на ремонт если не заказываешь — платный
Стоимость ТЗ порядка 3-5% от оплаченного счета
Где-то 10%-25% тех, кто заплатил за ТЗ не делают ничего вообще. ТЗ они довольны, но бывает планы поменялись, начальство передумало, бюджеты урезали и т.п.
hlogeon
14.11.2016 18:46Написание ТЗ нужно заказчику не меньше, чем разработчикам. Как правило, у заказчиков, которые еще не написали ТЗ у самих полностью отсутствует понимание того, как система вообще должна работать. Практически ни один человек не способен удержать в голове столько деталей, сколько есть, пусть даже в маленьком проекте. ТЗ на 5 страниц текста намного лучше, чем когда его нет вообще. Касательно бремени написания ТЗ — разработчик или заказчик? Ну давайте я к вам обращусь, как к разработчику за составлением детального ТЗ и согласованием деталей со мной в процессе разработки на какую-нибудь, скажем торговую площадку. Ваши аналитики будут пол года сидеть и делать мне ТЗ, согласовывать со мной, разработчиками, консультировать меня. А когда закончим я просто возьму результат и отдам его своим собственным разработчикам — УРА, пацаны, бесплатное ТЗ завезли, ай-да разрабатывать!
enzain
14.11.2016 18:46Так вы не ответили на вопрос.
Даже если в компании свои аналитики.
Кто им заплатить то должен? Контора?…
Логика отсутствует
vics001
15.11.2016 03:12А кто еще? Эти аналитики принадлежат конторе, зачем заказчику разбираться, за что я плачу тестирование, аналитику, бухгалтерию, еще что-то. Есть контракт, есть сумма контракта, есть результат.
Нет контракта — не надо и ТЗ.enzain
15.11.2016 08:30+1ТЗ — это такая же часть проекта, как и проектная документация, не видел никогда чтобы стоимость проектной документации не закладывали в проект.
Без ТЗ — просто не получится ничего вменяемого.
ТЗ — это отдельный законченный продукт, с ним вы можете ходить по сотне фирм и просить оценить работы. Потому все-таки ТЗ должно быть оплачено…
Я например, не буду работать с конторой которая пытается все получить на халяву.
Если с вами кто-то так работает, я за вас рад, но подрядчика мне жаль, видимо дела совсем плохи…
krivotester
18.11.2016 19:43Сложно говорить кто, что должен. Кто-то хочет финансировать пресэйлз, кто-то нет. Каждая контора сама выбирает бизнес-стратегию -)
jetexe
15.11.2016 10:59Что значит не составлять подробно? а зачем тогда вообще ТЗ? у нас помню даже раньше помимо услуги «составление ТЗ» была услуга «контроль проекта со стороны заказчика».
Услуга эта работала так: приходит клиент говорит чего он хочет. Мы проводим с ним н встреч, пишем тонну писем, и продаем ТЗ. За одно говорим, сколько будет стоить выполнение этого ТЗ нами. Если заказчика не устраивает цена, то мы предлагали вести проект от его имени с теми исполнителями которых выберет заказчик.
Но в любом случае у клиента оставалось хорошее проработанное ТЗ с которым можно устраивать тендеры (не государственные, а настоящие), а у аналитика деньги на хлеб с маслом
janvarev
14.11.2016 14:16+1> большие компании вообще делают pre-sales программы, которые стоят до 50К-100К и которые никак не возвращаются напрямую.
Есть разные компании.
Я вот работал и с клиентами напрямую, в лице своей маленькой компании, и как субподрядчик в большой компании.
У большой компании большие цены и длительный цикл продаж — они могут себе позволить содержать штат продажников, который едет выяснять детали к клиенту по каждому чиху от этого клиента. Они же управляют субподрядчиками (а вы что думали? что они сами делают весь продакшн? нет, нанимают фрилансеров/фирмы поменьше)
Когда маленькая компания работает с маленькими адекватными клиентами — тоже всё нормально, все всё понимают и либо составляют ТЗ, либо другим образом формализуют оплату по разработке.
Проблемы начинаются, когда маленькая компания пытается продать разработку большим дядям — самый частотный случай. Обычно директор маленькой компании говорит «ну это такие клиенты… такое портфолио будет!»; большая компания же просто пытается сэкономить. О том, что за счет экономии снижается качество (или портятся люди), никто не вспоминает.
Отсюда, в общем, и все проблемы с составлением ТЗ — большая компания привыкла к хорошему уровню сервиса и ожидает, что ей многое будут делать бесплатно (только тогда экономить не надо бы), маленькой же не хватает ресурсов, чтобы жить в таком цикле продаж (3 месяца продаем, потом получаем кучу денег и думаем, как всё не завалить). Собственно, проблемы с ресурсами маленькая компания обычно и перекладывает на разработчика, говоря «Запили нам ТЗ для клиента бесплатно».
Моя личная мораль: надо работать с клиентами своего уровня — проблем меньше, понимания больше.krivotester
14.11.2016 14:27+1Вот, кстати, важный момент вы затронули.
Без ТЗ — разрабы очень быстро выгорают, когда их дрыгают туда-сюда бессмысленными правками -)
По поводу морали не согласен, т.к. есть успешный опыт работы с клиентами уровня «крупная транснациональная компания». Да, на пресэйлз уходит 50-100 т.р., но если зацепился там и ты удобен, то это окупается. Но опять же, чтобы зацепиться нужно, чтобы все были рады. А чтобы все были рады требуется ТЗ согласованное порою с 10-ю разными менеджерами.janvarev
14.11.2016 14:36> По поводу морали не согласен, т.к. есть успешный опыт работы с клиентами уровня «крупная транснациональная компания»
Искренне за вас рад — рад, что у кого-то это получается и кому-то это правда интересно.
Я попробовал — надо сказать, технически успешно, заказчик уровня «известная национальная компания» даже остался доволен, проект был сдан вовремя без косяков — но морально это принесло мне мало удовлетворения и съело кучу нервов. Поэтому больше так стараюсь не работать — но, как написал, это скорее моя точка зрения.krivotester
14.11.2016 15:28Не знаю, насколько корректно будет вам чт-то советовать, но задумайтесь:
Я некоторое время назад понял, что я буду не гнаться за моральным удовлетворением как таковым, а создавать для него условия.
Раздел знаний называется «Эффективные коммуникации».
Часто дело не в клиентах, а в выстраивании правильной коммуникации. Конечно 1% психов от популяции никто не отменял. И 1 из 100 точно будет не способен к выстраиванию правильной коммуникации. С остальными задача взаимного удовлетворения решаема.janvarev
14.11.2016 16:59Ой, спасибо за совет, но конкретно ко мне он не очень применим. Я некоторое время назад начал задумываться о собственной идентичности, и понял, что я скорее программист-интроверт, нежели руководитель. И я, хоть и умею выстраивать коммуникации (директором тоже успел побыть), но на самом деле не очень это люблю. Так что у меня сейчас небольшой собственный
свечной заводикинтернет-проект, на котором «вкалывают роботы, а не человек» — и меня это замечательнейшим образом устраивает. И конечно, навыки руководителя в собственном бизнесе, сильно помогают, но развивать их не очень хочется.
Небольшая маленькая «месть» за совет :)) — не знаю, интроверт вы или экстраверт, но возможно, вам через некоторое время поднадоест суета большого бизнеса, но выйти из неё будет страшновато. Тогда порекомендую обратиться к юнговской теории поиска идентичности и, в частности, прочитать Дж. Холлиса «Перевал в середине пути».
Возможно, вы даже захотите присоединиться ко мне «в долине Галта» (Айн Рэнд «Атлант расправил плечи»)krivotester
18.11.2016 19:47+1Ок, приношу извинения, за советы не в тему -)
Я из другой школы: Чиксентмихайи, Зелегман и Канеман мои друзья -)))
Lofer
14.11.2016 14:27+2Почему должен платить заказчик? очень просто. Он Заинтересован.
Его интерес в следующих пунктах:
1. Клиент заинтересован в четком бюджете на проект? заинтересован.
2. Клиент заинтереован в четком понимании результат? заинтересован.
Техническое задание помогает ему достичь этих целей.
Клиент может с ТЗ пойти другому исполнителю, но у него уже будут собраны и описаны не противоречивые:
1. цели проекта
2. доменная область
3. бизнес логика
4. технические нюансы (если интеграции с другими системами)
5. критерии проверки результата.
Фактически нормально ТЗ — доказательство достижимости поставленных целей в рамках бюджета.
А есть еще и юридическая точка зрения: у Клиента есть доказательсто того, что Подрядчик его не обманет при приемке:)krivotester
14.11.2016 14:28Не все согласны с очевидным -)
Lofer
14.11.2016 14:50Это уже проблема PreSale :)
С точки зрения финансов — составление ТЗ можно провести как отдельную услугу с оплатой.
У буржуинов это нормальная практика. Часто попадались проекты, в которых нужно было только «написать код» по «бумажкам». Да и мои SRS (технические задания) часто делали пару циклов согласования, после рецензирования, у аудиторов, которых оплачивал Клиент.
А в моем текущем проекте, пришлось уделить неделю изучению юридических нюансов, и отправлять Клиенту табличку, как пункты договора и технического задания связаны с конкретными Законами.
chieftain_yu
14.11.2016 15:43+1По моему нескромному мнению, работа без ТЗ (или аналогичного ему документа) должна вестись на условиях Time&Material, а не по фиксированным ценам.
Lofer
14.11.2016 15:59Присоединюсь к этому мнению.
Кто платит, тот и музыку заказывает :)
Если Клиент оплачивает риски подхода ХЗ без ТЗ — без проблем
А если перекладывает риски на Подрядчика, то это уже дело Подрядчика как делать и делать ли вообще.krivotester
14.11.2016 18:47А кто оплатит хантинг новых разрабов, которые быстро выгорает при работе без ТЗ? -)
chieftain_yu
15.11.2016 09:04+1А с чего им выгорать?
Приходит бумажка от заказчика с задачей сделать сепульку тирьямпампирующей. Разраб делает, выставляет энцать часов, оплачиваемые заказчиком.
Потом заказчик присылает задачу «нет, сепулька нужна варпирующая» — разраб реализует, выставляет эмцать часов. Заказчик оплачивает.
Заказчик присылает задачу «сепульки быть вообще не должно, должна быть луцующая гравицапа» — разраб реализует, выставляет кацать часов. Заказчик оплачивает.
В чем тут может быть причина выгорания? Срок не давит, цикличность есть…
Выгорание идет как раз тогда, когда сроки горят, бюджет-фикс горит, заказчик фонтанирует идеями, ибо за эти кунштюки денег дополнительно не платит. А когда необдуманная хотелка заказчика стоит ему реальных дополнительных денег — заказчик гораздо критичнее относится к своим идеям.maxpsyhos
15.11.2016 10:17Это в случае «без ТЗ, но с почасовой оплатой». На практике такого не видел ни разу.
Да даже если и так, выгорание идёт от того, что «сколько уже можно, опять эти сепульки по 10-му разу, конца и края этому не видно, пол года жизни потрачено впустую».
Даже при очень хорошей оплате, если человек видит, что результаты его работы не глядя спускают в унитаз, это очень сильно демотивирует.chieftain_yu
15.11.2016 10:54Я встречал.
Для одной сети сопровождали одно решение с постоянными доработками (а теперь нам надо учитывать вот это по вот таким параметрам. А теперь нам надо перестроить вот этот процесс вот таким образом...). Каждая доработка шла как отдельная задача, оплата почасовая (точнее, там был абонемент на эн часов в месяц, но идея та же самая — каждая доработка выставлялась часами).
Исполнителей нифига не демотивировало. Поскольку заказчик вполне осознавал, что метания туда-сюда стоят ему весьма конкретных денег, и не злоупотреблял этим.
chieftain_yu
14.11.2016 15:40Ну, наверное, потому, что ТЗ бывает разным.
Одно дело — когда ТЗ содержит фразу «все должно быть классно» на трех листах. Другое — когда ТЗ содержит детализированное описание процессов, расположения элементов управления, исчерпывающие перечни категорий входных данных и все тому подобное — и отнимает два-три человекомесяца, а то и больше.
Greendq
14.11.2016 15:42Потому, что имея ТЗ заказчик спокойно может его отдать другой команде. Другими словами, если мы дадим одинаковое ТЗ двум разным командам — в идеальном случае получим два идентичных продукта. Поэтому создание ТЗ оплачивается.
krivotester
18.11.2016 19:49И это кстати плюс, когда все могут работать с «открытым забралом» и без обид.
Alex_Belyaev
14.11.2016 13:59Друзья, скажите а кто-нибудь из вас, использует конкретную проектную методологию при разработке проекта в целом и тех. задания в частности?
Поделитесь пожалуйста полезными ссылками или списками литературы (то как это должно быть).
Буду очень признателен.janvarev
14.11.2016 14:28+1Немного странный ответ, но надеюсь, вам пригодится:
По своему опыту:
— если вы работаете в одиночку или в паре с одним человеком — не используйте ничего. Делайте всё, как делали раньше. Методология только увеличит издержки, не даст ничего. (Сам пробовал делать UML-диаграммы, документацию и пр.)
— если вы руководитель в команде до 5-10 человек — посмотрите в сторону Agile, какие там практики. Ваша основная задача — синхронизировать ожидания членов команды за счет минимальных ресурсов.
— если вы работаете в большом коллективе — используйте методологию, существующую там. Не лезьте со своей, не портите готовую структуру, только ресурсы потратите, не факт, что построите что-то лучше.
— если вы руководите большим коллективом от 20 человек… то вам мои советы определённо не нужны :)
ТЗ не нужно для взаимодействия с командой; ТЗ нужно для только для взаимодействия с клиентом (и субподрядчиками) за вот этим (см. пункт 6 статьи):
> В процессе разработки не помешает иногда бить креативного клиента распечатанным и подписанным ТЗ по источнику креативной струи, чтобы не улететь с орбиты в глубокий космос.
Lost_Daemon
14.11.2016 14:00+2Последнее согласование ТЗ вылилось для заказчика и, опосредованно, меня, в разрешение глубинных противоречий и войны за влияние между подразделениями предприятия заказчика, поскольку требовало однозначно определить функциональные обязанности сотрудников и подразделений на местах (невозможно автоматизировать бардак). Естественно нашлись и те, кому такая активность «прищемила хвост» и эти люди оказали максимум противодействия при тестировании и внедрении продукта.
В целом стараюсь писать ТЗ самостоятельно, в тесном взаимодействии с заказчиком и бесплатно для него. Как разработчик я вырос из инженера-проектировщика АСУ ТП, поэтому писать ТЗ умею и люблю (да, да, не смейтесь!). Считаю, что создавая ТЗ я пропускаю все нюансы проекта через себя, что позволяет на ранней стадии увидеть узкие и проблемные места.krivotester
14.11.2016 14:30Вот лучше когда глубинные противоречия вскрываются до разработки, а не во время оной -)
Lofer
14.11.2016 14:54+1Считаю, что создавая ТЗ я пропускаю все нюансы проекта через себя, что позволяет на ранней стадии увидеть узкие и проблемные места
Поздравляю, вы ознакомились со стадией «идентификация рисков» в управлении рисками. (ISO 31010)
Очень полезная стадия
gandjustas
14.11.2016 14:55+1Как обычно правы все. Только все говорят о разном ТЗ.
Есть ТЗ, которое идет в договор. Оно описывает технические ограничения, например разделы на сайте, браузеры, адаптивный дизайн итд. Это ТЗ делает заказчик, а исполнитель согласовывает как прочие параметры контракта. Если заказчик может выдать подробное ТЗ (вместе с эскизами например) в на этом этапе — отлично, если нет — значит нет. Во втором случае цена будет сильно выше.
Когда договор подписан часто возникает другое ТЗ. В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами. Как сделать такое ТЗ без полного создания системы — никто не знает. Такое ТЗ обычно требует миллион итераций согласования и все равно оказывается неточным. Выгоднее всего делать ТЗ параллельно с разработкой.
Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком. Будет кровь пить весь проект. Или взять адекватные деньги за такое. Сумма как раз будет равна (сумма проекта с минимальным ТЗ — сумма с максимально полным ТЗ).
krivotester
14.11.2016 15:16Я вижу такой идеальный путь:
1. Мини-контракт на разработку ТЗ минимальной версии за символическую сумму, за которую делаем:
— 3 странички пользовательских сценариев
— 2 странички текстового описания всех экранов
— 1 страничка этапов работы с демонстрацией
2. Следующий контракт — прототипирование экранов системы на базе утвержденного мини-ТЗ
3. Следующий контракт — дизайн интерфейсов на базе утвержденного прототипа
4. Контракт на разработку первого этапа из мини-ТЗ
Таки будете смеяться, но я делал так большие системы, ооочень большие системы. И все были счастливы. Т.к. договоренности были прозрачны, всеми воспринимались однозначно, первые версии начинали шевелиться быстро, соответствовали ожиданиям заказчика.gandjustas
14.11.2016 15:46Идеальный путь это:
1) Когда вам удобно работать
2) Когда вы это продаете заказчику
Все зависит от конкретных людей с обоих сторон и проекта.
Lost_Daemon
14.11.2016 15:18+1Для такого «первоначального» ТЗ (он же «проект ТЗ») испокон веку в проектном производстве есть документ ИТТ (Исходные Технические Требования) заказчика, который, практически исчез в IT отрасли. К сожалению, в наших реалиях, Заказчику не всегда очевидна необходимость самого ТЗ, а убедить его еще и предварительно составлять ИТТ — вообще нереально.
Считаю первоначальное ТЗ — «священным», а дополнительные «хотелки» и «необходимки» заказчика предпочитаю группировать и оформлять доп.соглашением с приложениями, уточняющими и дополняющими основное ТЗ. С одной стороны это дисциплинирует заказчика, сдерживая фонтанирование идей, с другой стороны упрощает взаиморасчеты и позволяет разбить работу на этапы.
CDCrom
14.11.2016 15:43На сколько я помню ГОСТы (подправте если я не прав), то после ТЗ делается технический и эскизный проекты в которых, на сколько я помню как раз и осуществляется уточнение.
gandjustas
14.11.2016 15:50Эскизный и Технический проект — это этапы разработки, а не документы. В рамках этапа может быть много разных документов.
ГОСТ на ИС был сформирован на основе ГОСТа на строительство. Там четко — сначала макеты, потом чертежи, потом стройка. В разработке гораздо чаще встречается ситуация, что двигаться дальше можно только попытавшись реализовать функционал. Это похоже на НИОКР, по которым никаких гостов никогда не было.
ksil
14.11.2016 17:44+2ГОСТ РВ 15.105-2001 «Военная техника. Порядок выполнения научно-исследовательских работ и их составных частей. Основные положения».
ГОСТ РВ 15.203-2001 «Система разработки и поставки продукции на производство. Порядок выполнения ОКР по созданию изделий и его составных частей».
ГОСТ 15.110-2003 «Документация отчетная научно-техническая на научно-исследовательские, аванпроекты и опытно-конструкторские работы».
chieftain_yu
14.11.2016 15:51+1Если идти по ГОСТу 34.601-90, то стадии такие:
1. Формирование требований к АС (на выходе — тактико-техническое задание).
2. Разработка концепции АС (на выходе — отчет, содержащий согласованную концепцию).
3. ТЗ.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение.
Обычно на стадии 1 и 2 забивают совсем, 3-ю иногда удается выцыганить, 4 — получается редко. 5 и 6 часто сливают вместе — и хорошо если 7 — отдельная от них стадия.
На 8 денег нет, но если что — мозг клевать попытаются.
Lofer
14.11.2016 15:00В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами.
Это называется НЕ техническое задание, а «техническое решение»
Фактические это архитектура системы и является результатом работы системного аналитика/архитектора.
Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это. Но поскольку это работа, и результат «осязаем» и валидируем (серия стандартов ISO 250xx) то нужно дововариваться о оплате.
Бесплатно делать такое — это безумиеkrivotester
14.11.2016 15:23Кстати, часто бывает, что «техническое решение» не очевидно.
В этих случаях предлагаю составить ТЗ на исследовательский этап -)
Т.е. ТЗ на НИР/НИОКР получается -)Lofer
14.11.2016 15:36Обычно предлают «MVP» — нарезать «на кусочки», которые достижимы и валидируемы, и понижают риски «просадить бабло».
А если Компания пытается сделать, проект по которому нету компетенций — то сами себе злые буратины.
Обещали построить термоядерный реактор из палок и платилина, но не смогли? Добро пожаловать «на костер» :)
gandjustas
14.11.2016 15:52Это называется НЕ техническое задание, а «техническое решение»
Называться может как угодно. Не в словах дело.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это.
Вы как-то себе противоречите. Если договора нет, то о какой оплате речь идти может?
Lofer
14.11.2016 16:13Если договора нет, то о какой оплате речь идти может?
Это и становится предметом договора.
— Клиент, Вы согласны выделить бюджет и оплатить работу Подрядчика, со следующим результатом ...? Да / Нет.
— Клиент, Вы можете использовать результат работы или с нашими разработчиками, или с устроить тендер для любых иных подрядчиков. Вам понятны Ваши возможности? Да / Нет
arhangelsoft
14.11.2016 15:08Во второй опрос добавьте «Я разработчик, и я иногда работаю без ТЗ». Потому что не на всякое задание нужно ТЗ.
krivotester
14.11.2016 15:17не могу, добавить, боюсь, что отвалится собранная статистика
NightGhost
14.11.2016 23:53Сам опросы не добавлял, но вроде бы народ вполне правит «на лету». В любом случае можете уточнить у администрации, они реагируют.
M-A-XG
14.11.2016 15:13Продуктовая фирма.
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
Или в ТЗ по почте, аське, жире внесено 100500 правок, что никто точно не знает, что и как должно работать :)
На просьбу формализировать требования сопротивляются.
Иногда сам привожу ХЗ в ТЗ, прежде всего, чтобы самому понимать, что и как должно работать :)
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)
Об аутсорсе и говорить нечего. :)krivotester
14.11.2016 15:19-1На каждую правку в жире требуйте «ТЗ на правку», согласованную с клиентом и с разрабами. Будет счастье -)
По этой схеме я вытянул массу запутавшихся проектов -)
Lofer
14.11.2016 15:25+1Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
На просьбу формализировать требования сопротивляются.
Используются технические средства типа Change Management System: Jira / TFS / EA и т.д.
Без инструментов приносящих пользу всем сторонам — так и будет развиваться :)
А если прикруть к этому систему «считать деньги и таски» — то вообще будет счастье. Можно будет получить ответ на вопрос: а зачем сделали, сколько это стоило и почему
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)
Если учесть, что результат работы БА — прояснения и непротиворечивость результат, то ребята не выполняютс свою работу :) Уволить нафиг
Analitik_Telecom
14.11.2016 19:51-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
А я это пережил и в цирке больше не смеюсь. Бизнес-аналитики очень умеют писать конъюнктурные посты из лозунгов а-ля «для контактика», но порой не всекают проект, особенно, если это какой-нибудь биллинг, ERP и прочий глубоко завязанный на бизнесе софт. А ТЗ на мобильное приложение для банка или сайт для него же я сам на коленке напишу. Не хуже бизнес-аналитика.
mister_fog
14.11.2016 15:47+1Самый хороший подход, который я видел — когда создание ТЗ, сбор требований и написание проработанной концепции (в исключительных случаях — и прототипа будущей ИС) выделяется в отдельный проект со своим бюджетом. Потом с этим ТЗ можно бегать по рынку и устраивать «тендеры» на низкую цену.
krivotester
14.11.2016 15:56ППКС -)
Analitik_Telecom
14.11.2016 19:42Ещё бы не ППКС, когда это ваш хлеб. Лучше расскажите, каково оно, привлекать бизнес-аналитиков со стороны в разработку, а потом получать от них непонимание процессов за деньги компании? Не сталкивались?
krivotester
14.11.2016 20:48Постоянно сталкиваюсь. Рецепт один: «Есть слона по частям». Маленький кусочек способен ясно сформулировать даже самый тугой аналитики. А вот в большой системе легко может заблудиться несколько крутых системных архитекторов -)
Analitik_Telecom
14.11.2016 21:11А вы сталкивались с крупными проектами? Как потом складывали эти кусочки?
Lofer
14.11.2016 21:12А вот для этого и используется «бумажка» :)
Проектная документация и инструментальная поддержка. Система отлично собирается и поддерживается годами.
Для проекта бюджетом в пару миллионов долларов, система на пару десятков тысяч долларов — фигня.
А вот косяки предовращает — на ура.
Methos
14.11.2016 17:49+2Фигня это всё.
Нет ТЗ?
Отлично, работаем на почасовке.
А там хоть клоны, хоть чего пусть придумывают.
Время идёт, работа идёт — деньги идут.
И чем больше хотелок у клиента, тем лучше.
DarkTiger
14.11.2016 19:14+1С ТЗ все просто. Написание ТЗ требует больших затрат времени ведущих технарей, как заказчика, так и исполнителя. UML не пошел в широкие массы именно из-за этой мелкой детальки — на нем описать можно все, только сделать это некогда, даже если есть кому (что тоже зачастую проблема).
У заказчика времени технарей, как правило, нет. Они заняты. По уши. И ненавидят, когда к ним, таким загруженным, лезут еще с какой-то новой фигней. Обругать готовое — дело другое («Соломенное чучело» из «Накачанные адреналином» ДеМарко), тут много времени не нужно, это завсегда пожалуйста.
У исполнителя времени технарей тоже нет, но исполнителю нужны деньги. Поэтому вытаскиваемый за уши директором (и упирающийся при этом враскоряку) технарь исполнителя в конце концов что-то выдает. По этому чему-то можно примерно посчитать трудозатраты, но не более того. На сколько эти трудозатраты потом умножать — личный головняк ПМа либо начальника отдела. Все равно оказывается мало, но поставить реальную цифру никто не решится. К тому же технарь огрызается со словами «Вы что, хотите, чтобы заказчик получил от нас бесплатно законченное ТЗ, которое учитывает все-все-все и устроили тендер, да?» Возразить на это обычно бывает нечего.
Потом стартует проект и вот тут-то и начинают писать ТЗ. Но уже поздно.
ClosedSneaky
14.11.2016 20:42Главное чтобы было в принципе возможно «взять языка» в стане заказчика, а то может так оказаться, что достаточно компетентных сотрудников у заказчика просто нет и грамотно сформулировать требования к разработке просто некому.
Тогда от BA потребуется не просто сбор и фиксация требований, а навыки методиста и консультанта по специфике предметной области заказчика, что на практике чаще всего и требуется. Соответственно и вопрос с оплатой за услуги BA решается гораздо проще.
Вообще, конечно это иллюзия, что вы можете просто так взять и впереться на любой сегмент рынка, не зная его специфики и находу, в каких-то там опросниках, на коленке в переговорке составить исчерпывающее техническое задание.Lofer
14.11.2016 21:05Работа со стейкхолдерами, выявление от лиц «принимаюх решение», до просто «быть информированными»
На это все есть уже отработанные «рекомендации лучших собаководов» :).
DarkTiger
15.11.2016 00:37Это не иллюзия, а отсутствие привычки советоваться с экспертами из других областей и жадность на оплату этих экспертов.
У меня был проект, когда инженеры заказчика, за дополнительное, оплачиваемое исполнителем время, писали исполнителю ТЗ :) С уровнем важности тех или иных требований. Факт этот, само собой, не афишировался. Они честно писали, чего именно хотят. А после этого сейлы считали деньги.ClosedSneaky
15.11.2016 08:02Какие нехорошие люди, жадные. Лучше с такими не работать.
Если повезло найти экспертов из другой области, то нужно всегда стараться наладить
взаимопонимание и прислушиваться к их советам. Таких людей ценят.
progchip666
14.11.2016 23:37Не смотря на то, что я работаю больше в области hardware проблемы те же! Наступил на больную мазоль! +++
dmitry_ch
15.11.2016 00:58+1А это от области не зависит. (Почти) все хотят развести руками, и сказать «мне вот такое примерно, и чтобы вот так — тыр-тыр-тыр, и работало!»
А исполнитель (обычно) мечтает так же руками развести, и сказать — «получится не как вы сказали, а вот такого размера, и будет дыр-дыр-дыр звучать, но работать будет, и денег мне побольше».
Пока опыт их не столкнет с мыслью, что работа — это не только софт и железки, но и мысли, оформленные на бумаге, и что сдача работы — это не воды налить в пояснительную записку, а именно смысл работы и идеи в ее основе лежащие изложить так, чтобы следующий за тобой мог разобраться через N лет, ничего не будет толково делаться.
krivotester
18.11.2016 19:55оооо я тоже когда-то работал в Hardware, даже потоковый процессор проектировал и спецвычеслители всяко-разные -)
dmitry_ch
15.11.2016 00:49Видел обратное: изготовитель сайта (один из ТОП-10 по версии кого-то там, не совсем чтобы студия из подворотни) решил срубить с клиента бабла, и ТЗ старался не писать, чтобы его не притянули.
ТЗ написали. Стали делать работу — пошли вопли от разработчиков, мол, зачем вам эта кнопка, вы же никагда такое использовать не будете. «Кнопка» при этом была прописана в ТЗ самим подрядчиком.
В общем, я к тому, что выехать на кривой козе и поиметь гешафт, не сделав ТЗ и потому надеясь уйти от вопроса «почему сделано так, а не как договорились», порой хочет не только клиент.
P.S. И, да, ТЗ, когда разговор приходит к нему, писать-то мало кто умеет. Более того, термин расхожий, а ведь в ГОСТе есть четкие обределения, требования и прочее. Когда исполнителя тыкают носом туда, начинается рев, как в детском саду. Потому что он понимает, что игры кончились, и эту работу (чуть ли не впервые в жизни) нужно будет сделать от и до — притом не бесплатно — а он-то и не умеет. По крайней мере, не умеет с разрекламированной им про себя степенью профессинализма.
Sirom
15.11.2016 10:58в голосовалке не хватает пункта «я тот, кто специализируется только на написании ТЗ» )
по структуре самого техзадания — помимо пользовательских сценариев вместе с прототипами (экранами) должно быть описание работы программного модуля — как рубрицируются данные, как они обновляются (если предусмотрено автоматическое обновление из интегрированных систем), в каких случаях и кому улетают почтовые уведомления и т.п. Расписать состав элементов БД для каждого модуля тоже бывает полезно — экономит кучу времени и в процессе не грузит заказчика дополнительными вопросами типа «а должна ли в каталоге стоять дата последнего обновления цены»
igor_suhorukov
15.11.2016 11:06Если заказчик хочет работать без ТЗ, но понимает все риски и готов участвовать в работе и оплачивать за нужный темп работы команды, то можно продать ему Scrum команду (ну или другую методологию Agile)
Lofer
15.11.2016 11:32Нюанс в том, что в Scrum(Agile) все равно есть этап анализа и рассмотрения Story и критериев приемки, юнит-тесты и QA, которые все равно должны базироваться на чем-то конкретном и доказать что «Оно делает что надо». В противном случае на этапе «покера» просто не смогут договориться «что делать», не говоря уже «как делать».
Хорошим тоном считается не брать в BackLog спринта User Story, которая не сопровождается критериями приемки.
Так что миниТЗ все равно есть.
krivotester
18.11.2016 19:56Такого опыта нет, к сожалению -(
igor_suhorukov
18.11.2016 20:02Слышал от людей что в одной из стран ЕС они так гос проект разрабатывали.
uamarshall
15.11.2016 11:33По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя. Это уже не ТЗ а функциональная спецификация, и уже на её основе команда пишет техническую документацию или ТЗ в котором описывает что и как предполагается делать вплоть до моделей, эндпоинтов апи, архитектуры, стэка технологий. Чаще всего, функционалки достаточно что бы сделать типовый проект которые уже в компании делались не раз и имеют очень легкие отклонения в функционале. Если же проект не типовый то полному циклу.
Lofer
15.11.2016 11:47По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя.
Это разные документы и служат разным целям и они взаимо дополняющие.
TЗ — это что надо сделать
Функциональная спецификация — как сделать то, что указано в ТЗ
Пользователь скажет: Хочу отчет по продажам.
ТЗ будет включать:- ТЗ-1.1 Система должна предоставлять Отчет по продажам «в штуках». Форма отчета см…
- ТЗ-1.2 Система должна предоставлять Отчет по продажам «в деньгах». форма отчета см…
- ТЗ-1.3 Система должна предоставлять возможность экспорта отчетов в формат PDF
- ТЗ-1.4 Система должна предоставлять возможность экспорта отчетов в формат Excel xlsx
Функциональная спецификация будет включать:
- Пункт ТЗ-1.1 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
- Пункт ТЗ-1.2 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
deppkind
15.11.2016 19:34+2Раз тут уж клуб «одиноких сердец разъясняющих зачем тз и что это клиенту» оставлю тоже это тут, вот кусок из позавчерашнего письма клиентам, надеюсь будет полезным вам:
"
Теперь о техническом вопросе.
Надеюсь вы не занимаетесь проектировкой интерфейсов, местоположением кнопок и форма, а прописываете ваши задачи в виде ожидаемых сценарием, и примерные ожидания от их решения.
Вот вам в помощь материалы:
1. Схема мыследеятельности для работы над проектом. http://files.pavlyut.com/mindactions_v2.2.3.png
2. (разбор ее на видео https://www.youtube.com/watch?v=4erC7e8RyZM)
Очень коротенечко — у всех у каждого из нас есть прекраснейший “внутренний мир” и у каждого он свой. На каждого человка (в вашей команде например) и вместе со мной — это четыре замечательных внутренних мира. Не буду уточнять что они “возможно” “слегка” различаются (на самом деле чуть более чем полностью).
Ваш идеальный проект сейчас живет в ваших внутренних мирах. Чтобы он стал доступен всем нам для пользования он как-то должен перекочевать в более менее “том самом” состоянии, похожем на то что у вас в ваших внутренних мирах задумано.
Для успешного «перетекания” проекта из состояния замыслов он сначала попадает в артефакты (схемы, сценарии, интерфейсы), потом “воплощается” (слово не понравилось почему-то, но оно понятное всем потому что мы даем проекту “плоть” и он “объявляется” тут как тут в пространственно-временном измерении — это там где тыкать в него можно).
Эта схема содержит в себе ту карту “говорений” про проект в нужный момент времени чтобы “мысь по древу не растекашилась” и мы всегда понимали о чем гооврим, зачем это нужно, куда это вписать и где взять информацию, и что сейчас делать.
На схеме то что вы в состоянии извлечь из себя “внаружу” для воплощения проекта, а я в свою очередь не в состоянии это сделать самостоятельно, но в состоянии вас “помассировать” чтобы из вас это вышло - это все находится в левой первой части схемы “Окружающая действительность”.
Максимум что вы можете описать или “заложить” это вот первую и возможно чуток второй части схемы, потому как уже на второй нужно делать анализ и обоснования с аргументацией, уже от которых в свою очередь будет полностью зависеть правая часть, которая строится исключительно специалистами.
Я надеюсь что вам понятно о чем я тут написал, это письмо нужно для того чтобы уберечь нас от очередной „не своей” работы, которую вы скорее всего выполните (есть вероятность отличная от ноля) не совсем корректно, и будет переработка.
Все это нужно, это все равно “где-то” есть или “подразумевается”, но пока это не описано — проект проинзан дичайшими рисками на перерасход, невыполнение своих задач (построили а задача-то не это, как ее, это самое — тютю), и так далее.
Искренне надеюсь что это вам поможет, и дайте обратную связь на когда прикидывать разговоры о дальнейших работах.
“
Nadya_Khanko
18.11.2016 20:38Во втором голосовании не хватает пункта «Я заказчик, сам пишу подобие ТЗ»)))
Узнаю себя во многих пунктах при заказе сайта))
olegbukatchuk
18.11.2016 20:39+1Прежде, чем делать лендинг, упаковывать предложение в маркетинг-кит, заказывать наружную рекламу, разрабатывать скрипты и речевые модули для своих менеджеров, нужно провести огромную смысловую работу. И начать нужно с того, чтобы задать себе несколько вопросов, которые помогут вытащить ключевые смыслы, раскрывающие Вашу компанию для Ваших клиентов и для Вас.
Ваш продукт (товар или услуга):
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 дней до нескольких месяцев. Также важно качество упаковки и лучше, чтобы это сделал профессионал.
I-am-a-programmer
18.11.2016 20:39А такой вариант встречали: «Я вам плачу деньги за разработку, если у вас не хватает знаний как автоматизировать моё предприятие, так это ваши издержки за которые не вижу смысла платить». )))
А многие проекты могут и не начаться, поскольку: обговорили — написал, посмотрели — это забыли — обговорили… бесконечный круг. А за каждую новую редакцию платить деньги клиент не согласен.
Shoroh362
18.11.2016 20:40У меня был интересный случай в практике.
Начало как у всех, обращается с заказом на сайт бурлящий идеями клиент.
Осторожно предлагаю ему расписать функционал, оформить простенькое ТЗ, определится с целями, задачами. Клиент нехотя соглашается.
А через неделю пишет, что мол все, уже ничего не надо. Работая над функционалом он вдруг осознал, что не придумал ни целей ни задач.krivotester
18.11.2016 20:41Есть такое, это обратная сторона медали.
У многих после формализации осознания пыл остывает -)
engine9
21.11.2016 14:44То что вы описали часто происходит на сеансах у нормальных психологов, человека просят оформить конкретные цели и хлоп — проблемы то и нет, а хочет он совсем другое.
mrev1l
18.11.2016 20:41Я разработчик и так уж вышло, что обычно, работаем без ТЗ.
Когда мои друзья не из IT спрашивают у меня, — «как дела на работе?», то мой ответ примерно таков:
«Да как всегда… занимаюсь сексом… и мне ЭТО НЕ НРАВИТСЯ»
#есливыпонимаетеочемя :(
engine9
21.11.2016 14:41+1Была у нас история одна забавная и приятная по работе без ТЗ, заказчик нас привез в Москву (у них было много бабла, но все сроки они просрали) два дня нас возили по белокаменной, кормили в ресторанах, жили в клевном новом отеле с реальными пятью звездами, улетели и прилетели за их счет, еще денег сунули каждому в конверте, а в итоге заказали у каких-то других чуваков :)
krivotester
21.11.2016 22:43И все равно расстраивает такое -)
KonstantinSoloviov
21.11.2016 22:57Потому что — зря. Впустую выброшенное время жизни. Как секс без обязательств — приятно, но бессмысленно.
intsurfer
Не вижу пункта «я разработчик, но ТЗ предоставляет заказчик». Иногда даже с примерами интерфейсов, которые ему нужны. После обсуждения и внесения изменений согласовывается окончательный вариант. Через год-два от того первоначального ТЗ неизменным остается только титульный лист. :)
krivotester
Точно, но наверное нельзя уже править, иначе сломается?
Но у меня кстати база всегда остается, но обрастает дополнениями.
phoenixweiss
Полностью поддерживаю. По факту, кстати, это самый вменяемый тип клиентов, который чаще всего понимает что он хочет (конечно если там не полторы строчки, а реально составили хорошо). Был у нас клиент году в 2010-м который составил ТЗ на интернет-площадку продажи и обмена редких монет. Жаль мы к тому времени только дизайн для этого проекта делали, т.к. для не-специалиста он чрезвычайно подробно более чем на сорока страницах описал всю суть и большинство нюансов, при этом добавил как полагается глоссарий, оглавление и приложил скрины с примерами на которых указал отдельные важные элементы. Также отдельно несколько таблиц составил, описывающих логику работы калькуляторов и систем оценки. По сути только благодаря тому ТЗ я до сих пор помню чем отличаются XF от VF.