Comments 152
Но у меня кстати база всегда остается, но обрастает дополнениями.
1. Сценарии
Цели:
Задачи:
Пользовательский сценарий 1
Шаг 1
Шаг 2
…
Шаг n
Пользовательский сценарий 2
Пользовательский сценарий N
2. Описание экранов
Экран 1
Экран 2
…
Экран n
3. План демонстрации промежуточных стадий системы
Демонстрация 1
Демонстрация 2
…
Демонстрация n
Иногда к этому добавляется API в swagger и математика в XLS, если есть
Не аналитик, но добавлю еще несколько пунктов, которые облегчают жизнь:
- Диаграмма последовательности (как альтернатива пользовательскому сценарию)
- Блок-схемы демонстрирующие как должен работать, например, реализуемый API
Сильно экономит время и очень упрощает понимание некоторых разделов с требованиями.
В реальности, насколько я знаю, аналитик может потратить на составление диаграмм и блок-схем тонну времени, но оно того стоит. Исключает многие дальнейшние вопросы на корню.
Немного уйду в сторону, но блок-схемы особенно полезны при описании того, как технически работает продукт, какая-то его конкретная функциональность. Очень экономит время, потому что вопросы по работе системы возникают постоянно, ответы забываются, и времени на повторное объяснение уходит многократно больше, особенно если в проекте участвует много сторон, и всем нужно знать, как работает система.
Иногда я использую майн-карты и mindmaster для этого.
У нас все большие фаната диаграмм (и я тоже, даже на бумажках часто рисую во время обсуждений!), но вот новое руководство их не любит и заставляет переписывать в листы текста и как с этим бороться пока не придумали
А как они обосновывают свой выбор? Что за текст? В каком формате?
Требуют описывать происходящее в связанной текстовой форме.
А в каком виде то? просто для разных задач разные формы хорошо подходят. Например если мы говорим о чем-то что как-то себя по хитрому ведет, то тут как по мне всякие specification by example хорошо себя подают. А есть ситуации когда проще описывать причину и следствие (event storming). Те же текстовые стори тоже удобно группировать в какую-то карту (стори мэппинг). А есть еще всякие impact mapping-и и т.д.
Посему все же поинтересуюсь, какие именно диаграммы вы пробовали делать, и в каком виде пишите текст. Просто полотно из критериев приемки, или что-то поинтереснее...
Это часть методологии приемки, которая оговаривается юридически в контракте (лучше уточнить у юристов для соответсвующей юрисдикции).
В данном случае составляется документ «Программа и методика испытаний» в котором описано пошаговое выполнение программным обеспечением требований ТЗ, вида:
2. В окне авторизации ввести данные УЗ пользователя портала.
3. В левой части окна выбрать пункт меню «Настройки».
4. Во вкладке «Настройки интерфейса» в выпадающем списке поля «Язык» выбрать English.
5. Нажать кнопку «Сохранить настройки».
6. Убедиться в наличии англоязычного интерфейса в портале.
Далее при переводе ПО в Опытно-промышленную эксплуатацию проводят «приемо-сдаточные испытания» на которых проверяют все пункты ПМИ, выдают замечания и подписывают соответствующие акты.
После чего либо переводят систему в опытную эксплуатацию либо сначала ждут устранения замечаний.
Далее повторяют процедуру при переводе системы в промышленную эксплуатацию.
upd:
Разумеется ПМИ перед испытаниями согласовывается с заказчиком на предмет того что в нём описаны проверки всех необходимых ему функций.
У меня Закон звучит так:
1. Качество выполненной подрядчиком работы должно соответствовать условиям договора подряда, а при их отсутствии или неполноте – требованиям, обычно предъявляемым к работам соответствующего рода. Если иное не предусмотрено законодательством или договором, результат выполненной работы должен в момент передачи заказчику обладать свойствами, указанными в договоре или определенными обычно предъявляемыми требованиями, и в пределах разумного срока быть пригодным для установленного договором использования, а если такое использование договором не предусмотрено, – для обычного использования результата работы такого рода.
2. Если законодательством или в установленном им порядке предусмотрены обязательные требования к работе, выполняемой по договору подряда, подрядчик, действующий в качестве предпринимателя, обязан выполнять работу, соблюдая эти обязательные требования.
Как бы я не изворачивался, но должен следовать, иначе Клиент меня просто «на органы продаст» что бы «компенсировать убытки» или буду «пожизни баги фиксить». :)
Полагаю в РФ есть что-то весьма похожее, тем более что есть ГОСТ ИСО/МЭК 25041-2014. Не думаю что просто так его сделали
Обычно приемка по сценарию пользователя происходит и всем ок: и клиенту и разрабам.
Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.
волосы норм
кому бы делегировать? -)))
В такой трактовке верный коммент выше — «Заказчик должен (быть готовым) вложить свои внимание и усилия в достаточно полное описание задачи». Без этих усилий это просто «кнопка „сделайте хорошо“».
Действительно мало кто понимает это.
Другой пример. Финансовое руководство предприятия, недовольное вечным бардаком на складах и кипой вечно теряющихся бумаг, заказало написание и внедрение сферической ИС «Склад». Надо ли упоминать, что кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?
И таких примеров уйма. У всех свои интересы, даже внутри одного предприятия.
экспертиза (в устоявшемся в русском языке смысле, например, «проведена криминалистическая экспертиза») = inspection, expert report, evaluation
кладовщики, работающие с карточками наподобие картотечных, встретили новацию не очень радужно, вплоть до откровенного саботажа на местах?
Так ведь надо, чтобы не было проблем с внедрением, постараться понять и этих людей и инженеров и вообще всех участников процесса и учесть их интересы (найти и предложить им в системе "сладкую конфетку"), даже если формально заказчик и не заплатил за это денег — все равно потом нервы себе же сэкономите при внедрении.
А от заказчика нужно требовать, чтобы он обеспечил возможность общения со всеми типами пользователей системы — а не только с отдельными или приемщиками. Ну и всем видам пользователей системы при личном общении можно донести мысль — что разработчики им не враги а их друзья и они помогут им избавиться от жесточайших застарелых геморроев старого ПО и даже, сохранят похожий на старый алгоритм работы и интерфейсы программ (конкретно для кладовщиков — ПО будет имитировать своими формами ввода "картонные карточки", только уже на экране монитора или их переносных терминалах).
Предлагаю реализовать минимальную версию системы для начала, а дальше апгрейдить -)
У вас какой-то свой формат свои требования, а деньги хотите записать на клиента. Делайте его менее детальным или бюджетным не важно, возможно, у вас какой-то другой сегмент заказчиков, но я в него не попадаю.
P.S. большие компании вообще делают pre-sales программы, которые стоят до 50К-100К и которые никак не возвращаются напрямую.
Мне платят либо клиенты, либо разрабы.
Написали, допустим, 10 разным клиентам ТЗ, потратили по 20 рабочих часов на каждое, т.е. 200 рабочих часов в сумме.
Все они сказали спасибо, и пошли думать, а скорее всего устраивать тендер между разными разрабами, кто дешевле даст ценник.
Эти 200 часов на кого прикажете повесить? На 11-ого клиента, который дошел до контракта?
По поводу того, что уйдут к другим разрабам с вашим ТЗ. Составляя ТЗ вы себе упрощаете жизнь, вы подробно написали про это, а вешаете на клиента. Не хочу ТЗ — не составляйте или не составляйте подробно, чтобы все детали не ушли к другому. В случае студии или компании, если ваш подход не вдохновил как вы составляете ТЗ, то вы гораздо больше денег теряете, когда заказчик уходит после составления ТЗ.
Какой у вас % проектов доходит от ТЗ до оплаченного счета?
У меня встречный вопрос, сколько стоит ТЗ в процентах в среднем от оплаченного счета?
Сколько людей заказав ТЗ не делают дальше никаких работ в процентах?
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Я иду к юристу, рассказываю проблему или спрашиваю совета, как оформить контракт или могут они предоставить некоторую услугу и как. Консультация бесплатная — дальше работа. За время консультации по сути рассказывают план действий, из которого четко видно ТЗ.
P.S. я чаще выступаю как заказчик.
Сколько людей заказав ТЗ не делают дальше никаких работ в процентах?
Вся суть бизнеса сводится к уменьшению издержек, при прочих равных выбор будет делаться в пользу более дешевого варианта.
А в процентах сложно сказать, где то необходимо ТЗ, где то НИР, кто-то вообще просит спроектировать ему систему, а внедрять он будет своими силами.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Пока вы один и вы чётко представляете чего хотите это может быть и так.
Но в жизни как правило приходится иметь дело не с 1 человеком, а с организацией.
Куча людей выдвигают различные и часто взаимоисключающие требования к итоговому продукту.
Согласование занимает пол сотни раундов и пол года времени. Выполнять подобные работы бесплатно — безумие.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ, уточняют, вписывают стоимость, но заметьте с меня за это денег не берут.
Не совсем хороший пример — я менял проводку, и чётко знал, что я хочу — рабочие взяли деньги только за работу и материалы. Да смета бесплатная, но это и не ТЗ. Это предложение основанное на ТЗ. А сейчас я думаю о ремонте в ванне и понимаю, что без проекта никак, а он стоит денег.
Ну и консультация у юриста тоже не бесплатная, по крайней мере в Праге.
К примеру, я делаю ремонт, у меня есть план, приходят строители согласуют план работ,
Ключевой вопрос: откуда вы взяли ПЛАН?
Как следствие: вам сделали по ВАШЕМУ плану — постройка утонула или не выполнила ожидаемое. К кому претензии? К Вам или к строителям?
Если вы «купили» план — вы за него заплатили «тому парню», если вы сделали его сами — вы заплатили своим временем как минимум.
Заказчик платит в любом случае :)
Если Вы еще «не вынесли» мозг строителям, вам покажут пальчиком на сомнительные моменты и уточнят пару деталей — это будет бесплатно.
Но если вы «вынесли» мозг строителям — они вам сделают как «заказано», и ни одна зараза не намекнет, что марка труб у вас «тонкая и ржавеют с нашей водой» или штукатурка фиг подходит под климат или еще что…
Так и с ТЗ для клиента — адекватный, можно и соломку ему «подстелить».
Можно сказать что согласно ЗАКОНУ а можно и не говорить
Если иное не предусмотрено договором подряда, заказчик, принявший результаты работы без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)
— замена двери, если не заказываешь, то выезд сметчика платный
— замена окон — тоже
— дизайн-проект на ремонт — платный, бриф на дизайн-проект на ремонт если не заказываешь — платный
Стоимость ТЗ порядка 3-5% от оплаченного счета
Где-то 10%-25% тех, кто заплатил за ТЗ не делают ничего вообще. ТЗ они довольны, но бывает планы поменялись, начальство передумало, бюджеты урезали и т.п.
Нет контракта — не надо и ТЗ.
Услуга эта работала так: приходит клиент говорит чего он хочет. Мы проводим с ним н встреч, пишем тонну писем, и продаем ТЗ. За одно говорим, сколько будет стоить выполнение этого ТЗ нами. Если заказчика не устраивает цена, то мы предлагали вести проект от его имени с теми исполнителями которых выберет заказчик.
Но в любом случае у клиента оставалось хорошее проработанное ТЗ с которым можно устраивать тендеры (не государственные, а настоящие), а у аналитика деньги на хлеб с маслом
Есть разные компании.
Я вот работал и с клиентами напрямую, в лице своей маленькой компании, и как субподрядчик в большой компании.
У большой компании большие цены и длительный цикл продаж — они могут себе позволить содержать штат продажников, который едет выяснять детали к клиенту по каждому чиху от этого клиента. Они же управляют субподрядчиками (а вы что думали? что они сами делают весь продакшн? нет, нанимают фрилансеров/фирмы поменьше)
Когда маленькая компания работает с маленькими адекватными клиентами — тоже всё нормально, все всё понимают и либо составляют ТЗ, либо другим образом формализуют оплату по разработке.
Проблемы начинаются, когда маленькая компания пытается продать разработку большим дядям — самый частотный случай. Обычно директор маленькой компании говорит «ну это такие клиенты… такое портфолио будет!»; большая компания же просто пытается сэкономить. О том, что за счет экономии снижается качество (или портятся люди), никто не вспоминает.
Отсюда, в общем, и все проблемы с составлением ТЗ — большая компания привыкла к хорошему уровню сервиса и ожидает, что ей многое будут делать бесплатно (только тогда экономить не надо бы), маленькой же не хватает ресурсов, чтобы жить в таком цикле продаж (3 месяца продаем, потом получаем кучу денег и думаем, как всё не завалить). Собственно, проблемы с ресурсами маленькая компания обычно и перекладывает на разработчика, говоря «Запили нам ТЗ для клиента бесплатно».
Моя личная мораль: надо работать с клиентами своего уровня — проблем меньше, понимания больше.
Без ТЗ — разрабы очень быстро выгорают, когда их дрыгают туда-сюда бессмысленными правками -)
По поводу морали не согласен, т.к. есть успешный опыт работы с клиентами уровня «крупная транснациональная компания». Да, на пресэйлз уходит 50-100 т.р., но если зацепился там и ты удобен, то это окупается. Но опять же, чтобы зацепиться нужно, чтобы все были рады. А чтобы все были рады требуется ТЗ согласованное порою с 10-ю разными менеджерами.
Искренне за вас рад — рад, что у кого-то это получается и кому-то это правда интересно.
Я попробовал — надо сказать, технически успешно, заказчик уровня «известная национальная компания» даже остался доволен, проект был сдан вовремя без косяков — но морально это принесло мне мало удовлетворения и съело кучу нервов. Поэтому больше так стараюсь не работать — но, как написал, это скорее моя точка зрения.
Я некоторое время назад понял, что я буду не гнаться за моральным удовлетворением как таковым, а создавать для него условия.
Раздел знаний называется «Эффективные коммуникации».
Часто дело не в клиентах, а в выстраивании правильной коммуникации. Конечно 1% психов от популяции никто не отменял. И 1 из 100 точно будет не способен к выстраиванию правильной коммуникации. С остальными задача взаимного удовлетворения решаема.
Небольшая маленькая «месть» за совет :)) — не знаю, интроверт вы или экстраверт, но возможно, вам через некоторое время поднадоест суета большого бизнеса, но выйти из неё будет страшновато. Тогда порекомендую обратиться к юнговской теории поиска идентичности и, в частности, прочитать Дж. Холлиса «Перевал в середине пути».
Возможно, вы даже захотите присоединиться ко мне «в долине Галта» (Айн Рэнд «Атлант расправил плечи»)
Его интерес в следующих пунктах:
1. Клиент заинтересован в четком бюджете на проект? заинтересован.
2. Клиент заинтереован в четком понимании результат? заинтересован.
Техническое задание помогает ему достичь этих целей.
Клиент может с ТЗ пойти другому исполнителю, но у него уже будут собраны и описаны не противоречивые:
1. цели проекта
2. доменная область
3. бизнес логика
4. технические нюансы (если интеграции с другими системами)
5. критерии проверки результата.
Фактически нормально ТЗ — доказательство достижимости поставленных целей в рамках бюджета.
А есть еще и юридическая точка зрения: у Клиента есть доказательсто того, что Подрядчик его не обманет при приемке:)
С точки зрения финансов — составление ТЗ можно провести как отдельную услугу с оплатой.
У буржуинов это нормальная практика. Часто попадались проекты, в которых нужно было только «написать код» по «бумажкам». Да и мои SRS (технические задания) часто делали пару циклов согласования, после рецензирования, у аудиторов, которых оплачивал Клиент.
А в моем текущем проекте, пришлось уделить неделю изучению юридических нюансов, и отправлять Клиенту табличку, как пункты договора и технического задания связаны с конкретными Законами.
Кто платит, тот и музыку заказывает :)
Если Клиент оплачивает риски подхода ХЗ без ТЗ — без проблем
А если перекладывает риски на Подрядчика, то это уже дело Подрядчика как делать и делать ли вообще.
Приходит бумажка от заказчика с задачей сделать сепульку тирьямпампирующей. Разраб делает, выставляет энцать часов, оплачиваемые заказчиком.
Потом заказчик присылает задачу «нет, сепулька нужна варпирующая» — разраб реализует, выставляет эмцать часов. Заказчик оплачивает.
Заказчик присылает задачу «сепульки быть вообще не должно, должна быть луцующая гравицапа» — разраб реализует, выставляет кацать часов. Заказчик оплачивает.
В чем тут может быть причина выгорания? Срок не давит, цикличность есть…
Выгорание идет как раз тогда, когда сроки горят, бюджет-фикс горит, заказчик фонтанирует идеями, ибо за эти кунштюки денег дополнительно не платит. А когда необдуманная хотелка заказчика стоит ему реальных дополнительных денег — заказчик гораздо критичнее относится к своим идеям.
Да даже если и так, выгорание идёт от того, что «сколько уже можно, опять эти сепульки по 10-му разу, конца и края этому не видно, пол года жизни потрачено впустую».
Даже при очень хорошей оплате, если человек видит, что результаты его работы не глядя спускают в унитаз, это очень сильно демотивирует.
Для одной сети сопровождали одно решение с постоянными доработками (а теперь нам надо учитывать вот это по вот таким параметрам. А теперь нам надо перестроить вот этот процесс вот таким образом...). Каждая доработка шла как отдельная задача, оплата почасовая (точнее, там был абонемент на эн часов в месяц, но идея та же самая — каждая доработка выставлялась часами).
Исполнителей нифига не демотивировало. Поскольку заказчик вполне осознавал, что метания туда-сюда стоят ему весьма конкретных денег, и не злоупотреблял этим.
Одно дело — когда ТЗ содержит фразу «все должно быть классно» на трех листах. Другое — когда ТЗ содержит детализированное описание процессов, расположения элементов управления, исчерпывающие перечни категорий входных данных и все тому подобное — и отнимает два-три человекомесяца, а то и больше.
Поделитесь пожалуйста полезными ссылками или списками литературы (то как это должно быть).
Буду очень признателен.
По своему опыту:
— если вы работаете в одиночку или в паре с одним человеком — не используйте ничего. Делайте всё, как делали раньше. Методология только увеличит издержки, не даст ничего. (Сам пробовал делать UML-диаграммы, документацию и пр.)
— если вы руководитель в команде до 5-10 человек — посмотрите в сторону Agile, какие там практики. Ваша основная задача — синхронизировать ожидания членов команды за счет минимальных ресурсов.
— если вы работаете в большом коллективе — используйте методологию, существующую там. Не лезьте со своей, не портите готовую структуру, только ресурсы потратите, не факт, что построите что-то лучше.
— если вы руководите большим коллективом от 20 человек… то вам мои советы определённо не нужны :)
ТЗ не нужно для взаимодействия с командой; ТЗ нужно для только для взаимодействия с клиентом (и субподрядчиками) за вот этим (см. пункт 6 статьи):
> В процессе разработки не помешает иногда бить креативного клиента распечатанным и подписанным ТЗ по источнику креативной струи, чтобы не улететь с орбиты в глубокий космос.
В целом стараюсь писать ТЗ самостоятельно, в тесном взаимодействии с заказчиком и бесплатно для него. Как разработчик я вырос из инженера-проектировщика АСУ ТП, поэтому писать ТЗ умею и люблю (да, да, не смейтесь!). Считаю, что создавая ТЗ я пропускаю все нюансы проекта через себя, что позволяет на ранней стадии увидеть узкие и проблемные места.
Считаю, что создавая ТЗ я пропускаю все нюансы проекта через себя, что позволяет на ранней стадии увидеть узкие и проблемные места
Поздравляю, вы ознакомились со стадией «идентификация рисков» в управлении рисками. (ISO 31010)
Очень полезная стадия
Как обычно правы все. Только все говорят о разном ТЗ.
Есть ТЗ, которое идет в договор. Оно описывает технические ограничения, например разделы на сайте, браузеры, адаптивный дизайн итд. Это ТЗ делает заказчик, а исполнитель согласовывает как прочие параметры контракта. Если заказчик может выдать подробное ТЗ (вместе с эскизами например) в на этом этапе — отлично, если нет — значит нет. Во втором случае цена будет сильно выше.
Когда договор подписан часто возникает другое ТЗ. В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами. Как сделать такое ТЗ без полного создания системы — никто не знает. Такое ТЗ обычно требует миллион итераций согласования и все равно оказывается неточным. Выгоднее всего делать ТЗ параллельно с разработкой.
Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком. Будет кровь пить весь проект. Или взять адекватные деньги за такое. Сумма как раз будет равна (сумма проекта с минимальным ТЗ — сумма с максимально полным ТЗ).
1. Мини-контракт на разработку ТЗ минимальной версии за символическую сумму, за которую делаем:
— 3 странички пользовательских сценариев
— 2 странички текстового описания всех экранов
— 1 страничка этапов работы с демонстрацией
2. Следующий контракт — прототипирование экранов системы на базе утвержденного мини-ТЗ
3. Следующий контракт — дизайн интерфейсов на базе утвержденного прототипа
4. Контракт на разработку первого этапа из мини-ТЗ
Таки будете смеяться, но я делал так большие системы, ооочень большие системы. И все были счастливы. Т.к. договоренности были прозрачны, всеми воспринимались однозначно, первые версии начинали шевелиться быстро, соответствовали ожиданиям заказчика.
Считаю первоначальное ТЗ — «священным», а дополнительные «хотелки» и «необходимки» заказчика предпочитаю группировать и оформлять доп.соглашением с приложениями, уточняющими и дополняющими основное ТЗ. С одной стороны это дисциплинирует заказчика, сдерживая фонтанирование идей, с другой стороны упрощает взаиморасчеты и позволяет разбить работу на этапы.
Эскизный и Технический проект — это этапы разработки, а не документы. В рамках этапа может быть много разных документов.
ГОСТ на ИС был сформирован на основе ГОСТа на строительство. Там четко — сначала макеты, потом чертежи, потом стройка. В разработке гораздо чаще встречается ситуация, что двигаться дальше можно только попытавшись реализовать функционал. Это похоже на НИОКР, по которым никаких гостов никогда не было.
ГОСТ РВ 15.203-2001 «Система разработки и поставки продукции на производство. Порядок выполнения ОКР по созданию изделий и его составных частей».
ГОСТ 15.110-2003 «Документация отчетная научно-техническая на научно-исследовательские, аванпроекты и опытно-конструкторские работы».
1. Формирование требований к АС (на выходе — тактико-техническое задание).
2. Разработка концепции АС (на выходе — отчет, содержащий согласованную концепцию).
3. ТЗ.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение.
Обычно на стадии 1 и 2 забивают совсем, 3-ю иногда удается выцыганить, 4 — получается редко. 5 и 6 часто сливают вместе — и хорошо если 7 — отдельная от них стадия.
На 8 денег нет, но если что — мозг клевать попытаются.
В нем уже заказчик хочет видеть систему полностью, описанную текстом, схемами, эскизами, таблицами.
Это называется НЕ техническое задание, а «техническое решение»
Фактические это архитектура системы и является результатом работы системного аналитика/архитектора.
Если заказчик настаивает на подготовке ТЗ второго вида до подписания договора — то лучше не работать с таким заказчиком.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это. Но поскольку это работа, и результат «осязаем» и валидируем (серия стандартов ISO 250xx) то нужно дововариваться о оплате.
Бесплатно делать такое — это безумие
В этих случаях предлагаю составить ТЗ на исследовательский этап -)
Т.е. ТЗ на НИР/НИОКР получается -)
А если Компания пытается сделать, проект по которому нету компетенций — то сами себе злые буратины.
Обещали построить термоядерный реактор из палок и платилина, но не смогли? Добро пожаловать «на костер» :)
Это называется НЕ техническое задание, а «техническое решение»
Называться может как угодно. Не в словах дело.
По моему опыту, это самый классный заказчик. Одна проблема — оплата работы за это.
Вы как-то себе противоречите. Если договора нет, то о какой оплате речь идти может?
Если договора нет, то о какой оплате речь идти может?
Это и становится предметом договора.
— Клиент, Вы согласны выделить бюджет и оплатить работу Подрядчика, со следующим результатом ...? Да / Нет.
— Клиент, Вы можете использовать результат работы или с нашими разработчиками, или с устроить тендер для любых иных подрядчиков. Вам понятны Ваши возможности? Да / Нет
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
Или в ТЗ по почте, аське, жире внесено 100500 правок, что никто точно не знает, что и как должно работать :)
На просьбу формализировать требования сопротивляются.
Иногда сам привожу ХЗ в ТЗ, прежде всего, чтобы самому понимать, что и как должно работать :)
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)
Об аутсорсе и говорить нечего. :)
По этой схеме я вытянул массу запутавшихся проектов -)
Часто ТЗ не предоставляет ни заказчик, ни куча ответственных бизнес-аналитиков.
На просьбу формализировать требования сопротивляются.
Используются технические средства типа Change Management System: Jira / TFS / EA и т.д.
Без инструментов приносящих пользу всем сторонам — так и будет развиваться :)
А если прикруть к этому систему «считать деньги и таски» — то вообще будет счастье. Можно будет получить ответ на вопрос: а зачем сделали, сколько это стоило и почему
Кто-то раз услышал диалог 2-ух БА:
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
:)
Если учесть, что результат работы БА — прояснения и непротиворечивость результат, то ребята не выполняютс свою работу :) Уволить нафиг
-А ты сам понял что написал в задании?
-Нет, но это ж моя работа.
А я это пережил и в цирке больше не смеюсь. Бизнес-аналитики очень умеют писать конъюнктурные посты из лозунгов а-ля «для контактика», но порой не всекают проект, особенно, если это какой-нибудь биллинг, ERP и прочий глубоко завязанный на бизнесе софт. А ТЗ на мобильное приложение для банка или сайт для него же я сам на коленке напишу. Не хуже бизнес-аналитика.
Проектная документация и инструментальная поддержка. Система отлично собирается и поддерживается годами.
Для проекта бюджетом в пару миллионов долларов, система на пару десятков тысяч долларов — фигня.
А вот косяки предовращает — на ура.
Нет ТЗ?
Отлично, работаем на почасовке.
А там хоть клоны, хоть чего пусть придумывают.
Время идёт, работа идёт — деньги идут.
И чем больше хотелок у клиента, тем лучше.
У заказчика времени технарей, как правило, нет. Они заняты. По уши. И ненавидят, когда к ним, таким загруженным, лезут еще с какой-то новой фигней. Обругать готовое — дело другое («Соломенное чучело» из «Накачанные адреналином» ДеМарко), тут много времени не нужно, это завсегда пожалуйста.
У исполнителя времени технарей тоже нет, но исполнителю нужны деньги. Поэтому вытаскиваемый за уши директором (и упирающийся при этом враскоряку) технарь исполнителя в конце концов что-то выдает. По этому чему-то можно примерно посчитать трудозатраты, но не более того. На сколько эти трудозатраты потом умножать — личный головняк ПМа либо начальника отдела. Все равно оказывается мало, но поставить реальную цифру никто не решится. К тому же технарь огрызается со словами «Вы что, хотите, чтобы заказчик получил от нас бесплатно законченное ТЗ, которое учитывает все-все-все и устроили тендер, да?» Возразить на это обычно бывает нечего.
Потом стартует проект и вот тут-то и начинают писать ТЗ. Но уже поздно.
Тогда от BA потребуется не просто сбор и фиксация требований, а навыки методиста и консультанта по специфике предметной области заказчика, что на практике чаще всего и требуется. Соответственно и вопрос с оплатой за услуги BA решается гораздо проще.
Вообще, конечно это иллюзия, что вы можете просто так взять и впереться на любой сегмент рынка, не зная его специфики и находу, в каких-то там опросниках, на коленке в переговорке составить исчерпывающее техническое задание.
На это все есть уже отработанные «рекомендации лучших собаководов» :).
У меня был проект, когда инженеры заказчика, за дополнительное, оплачиваемое исполнителем время, писали исполнителю ТЗ :) С уровнем важности тех или иных требований. Факт этот, само собой, не афишировался. Они честно писали, чего именно хотят. А после этого сейлы считали деньги.
А исполнитель (обычно) мечтает так же руками развести, и сказать — «получится не как вы сказали, а вот такого размера, и будет дыр-дыр-дыр звучать, но работать будет, и денег мне побольше».
Пока опыт их не столкнет с мыслью, что работа — это не только софт и железки, но и мысли, оформленные на бумаге, и что сдача работы — это не воды налить в пояснительную записку, а именно смысл работы и идеи в ее основе лежащие изложить так, чтобы следующий за тобой мог разобраться через N лет, ничего не будет толково делаться.
ТЗ написали. Стали делать работу — пошли вопли от разработчиков, мол, зачем вам эта кнопка, вы же никагда такое использовать не будете. «Кнопка» при этом была прописана в ТЗ самим подрядчиком.
В общем, я к тому, что выехать на кривой козе и поиметь гешафт, не сделав ТЗ и потому надеясь уйти от вопроса «почему сделано так, а не как договорились», порой хочет не только клиент.
P.S. И, да, ТЗ, когда разговор приходит к нему, писать-то мало кто умеет. Более того, термин расхожий, а ведь в ГОСТе есть четкие обределения, требования и прочее. Когда исполнителя тыкают носом туда, начинается рев, как в детском саду. Потому что он понимает, что игры кончились, и эту работу (чуть ли не впервые в жизни) нужно будет сделать от и до — притом не бесплатно — а он-то и не умеет. По крайней мере, не умеет с разрекламированной им про себя степенью профессинализма.
по структуре самого техзадания — помимо пользовательских сценариев вместе с прототипами (экранами) должно быть описание работы программного модуля — как рубрицируются данные, как они обновляются (если предусмотрено автоматическое обновление из интегрированных систем), в каких случаях и кому улетают почтовые уведомления и т.п. Расписать состав элементов БД для каждого модуля тоже бывает полезно — экономит кучу времени и в процессе не грузит заказчика дополнительными вопросами типа «а должна ли в каталоге стоять дата последнего обновления цены»
Хорошим тоном считается не брать в BackLog спринта User Story, которая не сопровождается критериями приемки.
Так что миниТЗ все равно есть.
По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя.
Это разные документы и служат разным целям и они взаимо дополняющие.
TЗ — это что надо сделать
Функциональная спецификация — как сделать то, что указано в ТЗ
Пользователь скажет: Хочу отчет по продажам.
ТЗ будет включать:
- ТЗ-1.1 Система должна предоставлять Отчет по продажам «в штуках». Форма отчета см…
- ТЗ-1.2 Система должна предоставлять Отчет по продажам «в деньгах». форма отчета см…
- ТЗ-1.3 Система должна предоставлять возможность экспорта отчетов в формат PDF
- ТЗ-1.4 Система должна предоставлять возможность экспорта отчетов в формат Excel xlsx
Функциональная спецификация будет включать:
- Пункт ТЗ-1.1 реализуется следующим образом: попросить данные так, математика отчетета такая-то, тестовые данные брать там
- Пункт ТЗ-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 спрашивают у меня, — «как дела на работе?», то мой ответ примерно таков:
«Да как всегда… занимаюсь сексом… и мне ЭТО НЕ НРАВИТСЯ»
#есливыпонимаетеочемя :(
Без ТЗ: почему клиент не хочет его