> У вас результатом процесса(о) является результат последней операции процесса(к).
Себя еще раз процитирую:
> причем тут кто-то.… Единственный кто-то это вы как наблюдатель за ситуацией — какой период выбираете так у вас и получается.
Давайте попробую сложить для вас поточнее:
" У вас, в вашем процессе результатом будет то последнее состояние, на которое вы сами показываете пальцем, называя это 'результат'"
> у нас это отнюдь не всегда.
Вы одновременно смотрите на разные процессы и / или варианты проходов по условиям где «тадам» — есть последние состояния на которые вы указываете и называете это результатом у себя.
> и результат процесса(о) вообще может не быть связан с результатами его элементов.
То есть процесс доставки пиццы состоял из этапов в что доставщик получит пиццу, доставит вам ее, вы ее принимаете, а вы хотите сказать что у вас такие процессы, где при заказе пиццы привезут свадебный торт, да еще и на другую свадьбу.
> кому и какие потребности закрывает тезис, что процесс должен быть направлен кем-то на достижение результата?
причем тут кто-то. Цепочка состояний в любой период даст вам — а) первое состояние как начало процесса б) последнее состояние как результат процесса. Единственный кто-то это вы как наблюдатель за ситуацией — какой период выбираете так у вас и получается.
Еще у вас в рассуждениях отсутсвует модальность (та что из логики) из-за чего вы со всеми сцепляетесь. Добавьте к слову «бизнес-» или «технологический-» или «рабочий» и слово процесс резко для вас становится известным, широко употребляемым и понятным.
Универсальность ваша тоже без модальности — для кого универсальность определения, для какой языковой
и специализированной подгруппы / нескольких групп (онотологии приложите для себя — чтобы diff четко видеть ними) — и все у вас сростется с внешним миром.
Я пользуюсь этим определением на практике. Состояния (набор измеряемых параметров) я могу всегда указать, составить из них последовательность (цепочку) может любой не-специалист.
1. Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Задание что должно быть изготовлено — все чертежи, схемы компонентов, измеряемые параметры которые позволят «рабочему продукту» воплощаемому в веществе «выйти за ворота цеха» через кпп.
ТО есть да — даже на гайку есть тз, на изготовление зубочистки есть тз, на внесение изменений есть тз — задание что нужно сделать в детальной проектировке.
2. Насколько техническим или бизнес-ориентированным должно быть ТЗ?
Техническое задание — это к примеру тот документ, который регламентирует как именно на итальянском станке вы выплавите себе упаковку для молока. Для китайского станка тз будет другим, потому что оно выстраивается из ТТХ возможностей производственной линии. Для многих это в жизни разработки оказывается сюрпирзом. ТЗ это внутренний уведомительный документ для производства. Клиент его может видеть может и не видеть — дело ваше.
Бизнес-ориинетированными являются другие документы — документированная концепция (то что подразумевается сделать), бизнес-область применения решения, действующие лица, цонтекст, ожидания от поведения системы — сюда я обычно пачкой складываю все макеты проротипы и эскизы от клиента, которые идут «в основание» скетчей, потом дизайна и рабочих чертежей состояний компонентов, ну и после всего этого концепта, на основании этих писюлек пишутся «трбебования к стисеме» — что дложно быть реализовано, с точки зрения «черного ящика» (мы хотим тыкнуть сюда пальцем и откуда-то отсюда вылетит птичка, мы не знаем как это делается внутри — как она там запускается, стартует и тд). Ну и на основании каждого требования пишется архитектурное решение с покзыванием клиенту. Если не учли какие-либо его потребности и пожелания (а надо было) на первом этапе и этот этпа прошел, становится возможным предложить клиенту выполнить всю работу по цепочке с самого начала когда он захочет влиять на архитектуру (те самые «подвинуть или подкрасить»).
Концепиция (инбокс и упорядочивание всего что прилетело, обсуждено на встрече, под подпись) -> на основании концепции делаются требования — > на основании требований пишется архитекутра.
Вот это все и обычно размазывает кто как умеет называя это ТЗ. Три разных документа, три разных специализации (наборы действий для выявления данных и их документирования) — от секретаря и менеджера до аналитика и инженера-архитектора.
3. Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Все участники проекта. Это некий baseline где хрантится весь проект от замысла до ввода в эксплуатацию.
4. Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Задавать вопросы и обработать все возможные входящие (ссылки на сайты, прототипы, криворукие документы ворд / экселя, какие-то мега идеи и «хорошо проработанные задания») должен менеджер и сделать из этого концепцию (опись бреда) и получить роспись, Аналитик должен бред разложить по полочкам, выявить недостающие элементы вопросаами, задокументировать требования. Подписать. Архитекор должен разложить ключевые экраны и элементы в скетчах. Подписать — дальше производство дело техники.
5. Какими компетенциями должен обладать человек, пишущий ТЗ?
Коммуникабельность, стрессоустойчивость, шлем — задавая вопросы, кажущиеся «очевидными» или повторяющимися любой собеседуемый человек начинает бесится как непонятно кто и непонятно почему — это факт, работу надо довести до конца и не пострадать — я часто работю со спорсменами высокого уровня «добился сам» и желающими войти в эти ваши технологии. Бывает очень часто интересное после третьего вглубь вопроса «зачем».
6. Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Критерии качества есть, растут из исошек по системной инженерии — качественным считается продукт или система, соответсвующая заданным качествам (в тз и этих документах критерии качества это заполненность всех важных структур — стейкхолдеры, интересы, цели, задачи, требования, сиуациии, ожидания… и связей между ними. Много их есть они все ( старый пример http://files.pavlyut.com/mindactions_v2.2.3.png)
7. Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Два вопроса тут. Первый — процесс изменения документируется и отражается от начала до конца как обычно, тз как документ это место постоянных иземенений — важная особенность что всегда есть «последняя согласованная версия» от которой идет коммуникация.
Второй это то что вы вкладываете в варианты «обилечивания» — я например ушел в итоге от часов и у меня есть конкретная смета на проект которую клиент все время подписыает. Компоненты сметы изначально увтерждаются заранее и клиент знает принцип ценообразования. (это полностью кастомная разработка всегда, хотя я могу это навесить на любые хери типа битрииксов или чего угодно, есть четкие замеры на выходе сколько человек получил «накоденного» и мереется это не по коду а по юзаджу).
Поэтому должна быть четкая привязка к ценообразованию на что и как влияют изменения — иначе жопа кеды. Система вещица динамичная и существует только в глазах смотрящего.
8. Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Бизнес аналитик «анализирует» все входящие материалы, как правило он совмещается на первой встрече с менеджером помогая сразу задать нужные вопросы, но при наличии принятой формы анкетирования на встрече бизнес аналитик как раз не нужен чтобы не открывать ящик пандоры фантазий клиента. Тут практикуется психология, расслабление клиента и уверения его в прекрасном будущем. Это аккаунтинг. Технически у меня девченка справляется уже с этим хорошо (и это лучше — клиенты любят зачем-то быть мягкими идиотами при девушках, вне зависимости от возраста/статуса/должностей).
То есть аналитики анализирует — всю входящую информаци соединяет, находит связи, выстраивает из хаоса порядок и передает дальше. Тут практики и методы анализа и категоризации, систематизации.
Архитектор проектирует — у него должны быть навыки и опыт проекирования и запуска в эксплуатацию спроектированного — у него тут свои практики и методы — ux / ui вот это все тут.
9. Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Сложно утвреждать про «чаще всего» потому как чаще всего за все время работы я вижу настолько дичайшую сложность описать систему, и ее поведение, что в итоге понял что это проблема не описания а «воображения». Я как-то злился на клиента думал что он мне выносит мозги просто, когда я ему дал рабочий прототип и раскадровку с описью, ну тут вообще не возможно представить как-то по-иному, и вот он со всей серъезностью не понимал «как это будет работать», говорит ты собери и я пойму, так ничего не понятно. Это был не первый случай и я честно делаю вывод что он «в голове собрать и повертеть» даже элементарно не может не получается у человека — и это не его проблемы а мои, и я решли этот вопрос — покликал под видео прототип.
Поэтому что туда пишут часто это такой бред сивой кобыли что да, там кто-то запишет про показатели яндекса, кто-то укажет оттенок цвета, кто-то укажет пеню оплаты за услуги, кто-то напишет что должно быть 2 человека в группе разработке (схерали не скажет конечно, не приведет раскладку и обоснование с указанием методов и аргументации зачем и как это принесет какую именно пользу, и с хера ли вообще он полез в тех часть и тд).
Но про процесс продажи это правда — как указал ранее, тз как раз «замеряет» что пошло в «цех» — это это надо обилечивать обязательно. Пишите проессы.
10. Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ?
Не может — это пост документ который тоже пишется по договоренностям, с учетом культурно-обусловленной позиции действующих в системе стейкхолдеров (персонажей).
Как я думаю мысль автора в том чтобы разделить «Что и как» через название и реализацию, а все что дальше это уже «смягчение» дискуса какая она должна быть потому и потому, то есть мысль в том что она может быть какая угодно. Нет проблемы в том что не всегда можно уместить функцию — это нормально.
Я не спорю с вами — это мое имхо что написано, с чем я собственно полностью согласен на уровне — сначала идет definition того что делается, а уже другой очередью идет реализация — как бы разные процессы мыследеятельности. Вот об этом «заборе» мне кажется он и пишет — а что за забором это уже вообще не имеет значения без точечного контекста.
http://www.pavlyut.com/contract в мелочах есть косяки но работает, построен кровью и потом. Скоро новая версия будет, думаю написать ли пошаговый разбор как это работает сюда.
Раз тут уж клуб «одиноких сердец разъясняющих зачем тз и что это клиенту» оставлю тоже это тут, вот кусок из позавчерашнего письма клиентам, надеюсь будет полезным вам:
"
Теперь о техническом вопросе.
Надеюсь вы не занимаетесь проектировкой интерфейсов, местоположением кнопок и форма, а прописываете ваши задачи в виде ожидаемых сценарием, и примерные ожидания от их решения.
Очень коротенечко — у всех у каждого из нас есть прекраснейший “внутренний мир” и у каждого он свой. На каждого человка (в вашей команде например) и вместе со мной — это четыре замечательных внутренних мира. Не буду уточнять что они “возможно” “слегка” различаются (на самом деле чуть более чем полностью).
Ваш идеальный проект сейчас живет в ваших внутренних мирах. Чтобы он стал доступен всем нам для пользования он как-то должен перекочевать в более менее “том самом” состоянии, похожем на то что у вас в ваших внутренних мирах задумано.
Для успешного «перетекания” проекта из состояния замыслов он сначала попадает в артефакты (схемы, сценарии, интерфейсы), потом “воплощается” (слово не понравилось почему-то, но оно понятное всем потому что мы даем проекту “плоть” и он “объявляется” тут как тут в пространственно-временном измерении — это там где тыкать в него можно).
Эта схема содержит в себе ту карту “говорений” про проект в нужный момент времени чтобы “мысь по древу не растекашилась” и мы всегда понимали о чем гооврим, зачем это нужно, куда это вписать и где взять информацию, и что сейчас делать.
На схеме то что вы в состоянии извлечь из себя “внаружу” для воплощения проекта, а я в свою очередь не в состоянии это сделать самостоятельно, но в состоянии вас “помассировать” чтобы из вас это вышло - это все находится в левой первой части схемы “Окружающая действительность”.
Максимум что вы можете описать или “заложить” это вот первую и возможно чуток второй части схемы, потому как уже на второй нужно делать анализ и обоснования с аргументацией, уже от которых в свою очередь будет полностью зависеть правая часть, которая строится исключительно специалистами.
Я надеюсь что вам понятно о чем я тут написал, это письмо нужно для того чтобы уберечь нас от очередной „не своей” работы, которую вы скорее всего выполните (есть вероятность отличная от ноля) не совсем корректно, и будет переработка.
Все это нужно, это все равно “где-то” есть или “подразумевается”, но пока это не описано — проект проинзан дичайшими рисками на перерасход, невыполнение своих задач (построили а задача-то не это, как ее, это самое — тютю), и так далее.
Искренне надеюсь что это вам поможет, и дайте обратную связь на когда прикидывать разговоры о дальнейших работах.
“
Верно, но по факту в практике если фулстек это некий самостоятельный боец в поле — доля несложных проектов ~90% на рынке и все они поддаются фуллстеку.
Та же песня — только отчистился. Старый ключ про который все забыли, утек в репу к мудаку какому-то на гитхаб в открытый доступ, те же спот аукционы, по всем континентам по 70 машин поднято максимальной конфигруации. Вопрос решен — деньги даже не начисляли а сами мне прислали ссылку на гитхаб где мой ключ оказался указан.
Я так понимаю онтолгию нашей беседы говорим про одно и то же.
Все верно излагаете, только не надо бежать вперед клинту фразой «плати за тз» — ему не нужно тз, ему нужен результат.
Тут дело в терминологии просто — у меня тз проходит через несколько этапов как тут написано, где каждый подтверждается, и на каждом этапе полно возможностей «повизуализировать» и пофантазировать не попадая в копеечку.
Самое же дорогое в тз это как раз прописать все и прорисовать уже as is с кликами и view стейтами как это и куда, закрыть юз кейсами и тд.
А для начала мы просто пишем воздейсвтия реакции — их очень достаточно для понимания как будет работать конечный продукт у клиента.
Нельзя продать часть внутреннего процесса как услугу, если это не самостоятельная услуга со всеми ее жизненными циклами — начало, производство, доставка, закрытие.
Разница только в том что клиент и так платит за работу — не мешайте же просто себе получить проект, не надо продавать тз. Нужно сообщить что «после того как мы пропишем вам взаимодействия и вы их акцептируете, мы сможем вам показать макеты и полностью восстановить картину ожидания, тут вы сможете исправить какие-либо расположения на экране, а взаимодействия менять не будем».
Каждая фаза это точка невозврата — вообще возврата разумеется, но всем сразу ясно что это заход на новый круг — и все вопросы снимаются по тому что «мы должны все сделать потому что это к этому же относится».
Бриф брифом, а на требования есть стантарты инженирии, и все же рекомендую им прислушиваться. Клиент может напсать все что хочет — но лучше это переписать и дать ему на подпись по двум причинам:
1) Пояснить где он заблуждается или уточнить детали
2) Получить взаимную синхронизацию на понятном списке, уничтожив любые отсылки к «я вам присылал письмо там с комментарием в ворде в котором ссылки на три сайта я хотел как эти сайты».
Я просто работаю с разными проектами, космолеты не строю, но это реальный экстракт опыта для внутреннего пользования, а в данном контексте еще и приятная ревизия знающих коллег, так что в любом случае благодарен.
На одно и то же требование можно соорудить варианты формата «жигуль», «vw», «bmw», «bentley».
Обосновать = доказать. Доказательства должны быть подшиты с пометкой почему, иначе это пустые слова и цифры «из головы».
> Первый этап работы — очевидно уже за деньги.
Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.
Под этот листок далее можно высылать кп с тремя-пятью вариантами цен и сроков — я всегда беру деньги (а точнее указываю что тут вы деньги будете платить) если клиент начинает не работать над проектом, а «скидывать» принятия решений и мышление просто на нас потому что ему лениво или он не показывает заинтересованность к проекту.
> Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
Все согласовательные части которые беспокоят клиента находятся в требованиях, и в вариантах решений (эскизы, наброски, экраны).
Остальное это ваша работа и ваша часть отвественности.
> После принятия, дописать ТЗ естественно нельзя.
Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
А про жизненный цикл отдельно потом скажу. Это важная часть.
Ну вот у вас и утечка и ввод в заблуждение клиента — что вы работаете по любому его запросу без оплаты. Много у вас времени отказные тз писать?
Как можно написать ТЗ (задание в произдство) — без проработки взаимодействий сначала (в базовом варианте воздействие-реалкция)?
Что делаете если требование «допишут» — по кругу тз переписываете? Или по принятому у многих методу «склоняете» клиента к нужному вам решениею (не переписывать сто раз) а сразу под ограниченный процесс работать?
У вас тут дичайшая потеря качества — многие клиенты готовы оплачивать и платят за грамотную проработку, а вы сразу самогонные аппарты в производство пускаете.
Супер крутой менеджер может что угодно называть — он должен это обосновать.
Клиент свои «требования» тоже должен обосновать если хочет их пускать как есть — потребность внешнего мира (не его личная), результат который он хочет этим получить, вариант решения, аргументы почему этот вариант решения, согласованность требования (связи) с другими требованиями.
Аналитка это хорошо.
Как-то раз рентген в ночи обнаружил ИКС лучи.
Очень важны те лучи - для анализа мочи.
>чтобы не забивать молотком шурупы
Забиваешь молотком шуруп для того чтобы он "встал в направление" и дальше докручиваешь отверткой.
Не благодари
Себя еще раз процитирую:
> причем тут кто-то.… Единственный кто-то это вы как наблюдатель за ситуацией — какой период выбираете так у вас и получается.
Давайте попробую сложить для вас поточнее:
" У вас, в вашем процессе результатом будет то последнее состояние, на которое вы сами показываете пальцем, называя это 'результат'"
> у нас это отнюдь не всегда.
Вы одновременно смотрите на разные процессы и / или варианты проходов по условиям где «тадам» — есть последние состояния на которые вы указываете и называете это результатом у себя.
> и результат процесса(о) вообще может не быть связан с результатами его элементов.
То есть процесс доставки пиццы состоял из этапов в что доставщик получит пиццу, доставит вам ее, вы ее принимаете, а вы хотите сказать что у вас такие процессы, где при заказе пиццы привезут свадебный торт, да еще и на другую свадьбу.
причем тут кто-то. Цепочка состояний в любой период даст вам — а) первое состояние как начало процесса б) последнее состояние как результат процесса. Единственный кто-то это вы как наблюдатель за ситуацией — какой период выбираете так у вас и получается.
Еще у вас в рассуждениях отсутсвует модальность (та что из логики) из-за чего вы со всеми сцепляетесь. Добавьте к слову «бизнес-» или «технологический-» или «рабочий» и слово процесс резко для вас становится известным, широко употребляемым и понятным.
Универсальность ваша тоже без модальности — для кого универсальность определения, для какой языковой
и специализированной подгруппы / нескольких групп (онотологии приложите для себя — чтобы diff четко видеть ними) — и все у вас сростется с внешним миром.
Можете не пользоваться.
Процесс — цепочка состояний. В любой интересный вам период.
1. Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Задание что должно быть изготовлено — все чертежи, схемы компонентов, измеряемые параметры которые позволят «рабочему продукту» воплощаемому в веществе «выйти за ворота цеха» через кпп.
ТО есть да — даже на гайку есть тз, на изготовление зубочистки есть тз, на внесение изменений есть тз — задание что нужно сделать в детальной проектировке.
2. Насколько техническим или бизнес-ориентированным должно быть ТЗ?
Техническое задание — это к примеру тот документ, который регламентирует как именно на итальянском станке вы выплавите себе упаковку для молока. Для китайского станка тз будет другим, потому что оно выстраивается из ТТХ возможностей производственной линии. Для многих это в жизни разработки оказывается сюрпирзом. ТЗ это внутренний уведомительный документ для производства. Клиент его может видеть может и не видеть — дело ваше.
Бизнес-ориинетированными являются другие документы — документированная концепция (то что подразумевается сделать), бизнес-область применения решения, действующие лица, цонтекст, ожидания от поведения системы — сюда я обычно пачкой складываю все макеты проротипы и эскизы от клиента, которые идут «в основание» скетчей, потом дизайна и рабочих чертежей состояний компонентов, ну и после всего этого концепта, на основании этих писюлек пишутся «трбебования к стисеме» — что дложно быть реализовано, с точки зрения «черного ящика» (мы хотим тыкнуть сюда пальцем и откуда-то отсюда вылетит птичка, мы не знаем как это делается внутри — как она там запускается, стартует и тд). Ну и на основании каждого требования пишется архитектурное решение с покзыванием клиенту. Если не учли какие-либо его потребности и пожелания (а надо было) на первом этапе и этот этпа прошел, становится возможным предложить клиенту выполнить всю работу по цепочке с самого начала когда он захочет влиять на архитектуру (те самые «подвинуть или подкрасить»).
Концепиция (инбокс и упорядочивание всего что прилетело, обсуждено на встрече, под подпись) -> на основании концепции делаются требования — > на основании требований пишется архитекутра.
Вот это все и обычно размазывает кто как умеет называя это ТЗ. Три разных документа, три разных специализации (наборы действий для выявления данных и их документирования) — от секретаря и менеджера до аналитика и инженера-архитектора.
3. Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Все участники проекта. Это некий baseline где хрантится весь проект от замысла до ввода в эксплуатацию.
4. Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Задавать вопросы и обработать все возможные входящие (ссылки на сайты, прототипы, криворукие документы ворд / экселя, какие-то мега идеи и «хорошо проработанные задания») должен менеджер и сделать из этого концепцию (опись бреда) и получить роспись, Аналитик должен бред разложить по полочкам, выявить недостающие элементы вопросаами, задокументировать требования. Подписать. Архитекор должен разложить ключевые экраны и элементы в скетчах. Подписать — дальше производство дело техники.
5. Какими компетенциями должен обладать человек, пишущий ТЗ?
Коммуникабельность, стрессоустойчивость, шлем — задавая вопросы, кажущиеся «очевидными» или повторяющимися любой собеседуемый человек начинает бесится как непонятно кто и непонятно почему — это факт, работу надо довести до конца и не пострадать — я часто работю со спорсменами высокого уровня «добился сам» и желающими войти в эти ваши технологии. Бывает очень часто интересное после третьего вглубь вопроса «зачем».
6. Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Критерии качества есть, растут из исошек по системной инженерии — качественным считается продукт или система, соответсвующая заданным качествам (в тз и этих документах критерии качества это заполненность всех важных структур — стейкхолдеры, интересы, цели, задачи, требования, сиуациии, ожидания… и связей между ними. Много их есть они все ( старый пример http://files.pavlyut.com/mindactions_v2.2.3.png)
7. Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Два вопроса тут. Первый — процесс изменения документируется и отражается от начала до конца как обычно, тз как документ это место постоянных иземенений — важная особенность что всегда есть «последняя согласованная версия» от которой идет коммуникация.
Второй это то что вы вкладываете в варианты «обилечивания» — я например ушел в итоге от часов и у меня есть конкретная смета на проект которую клиент все время подписыает. Компоненты сметы изначально увтерждаются заранее и клиент знает принцип ценообразования. (это полностью кастомная разработка всегда, хотя я могу это навесить на любые хери типа битрииксов или чего угодно, есть четкие замеры на выходе сколько человек получил «накоденного» и мереется это не по коду а по юзаджу).
Поэтому должна быть четкая привязка к ценообразованию на что и как влияют изменения — иначе жопа кеды. Система вещица динамичная и существует только в глазах смотрящего.
8. Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Бизнес аналитик «анализирует» все входящие материалы, как правило он совмещается на первой встрече с менеджером помогая сразу задать нужные вопросы, но при наличии принятой формы анкетирования на встрече бизнес аналитик как раз не нужен чтобы не открывать ящик пандоры фантазий клиента. Тут практикуется психология, расслабление клиента и уверения его в прекрасном будущем. Это аккаунтинг. Технически у меня девченка справляется уже с этим хорошо (и это лучше — клиенты любят зачем-то быть мягкими идиотами при девушках, вне зависимости от возраста/статуса/должностей).
То есть аналитики анализирует — всю входящую информаци соединяет, находит связи, выстраивает из хаоса порядок и передает дальше. Тут практики и методы анализа и категоризации, систематизации.
Архитектор проектирует — у него должны быть навыки и опыт проекирования и запуска в эксплуатацию спроектированного — у него тут свои практики и методы — ux / ui вот это все тут.
9. Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Сложно утвреждать про «чаще всего» потому как чаще всего за все время работы я вижу настолько дичайшую сложность описать систему, и ее поведение, что в итоге понял что это проблема не описания а «воображения». Я как-то злился на клиента думал что он мне выносит мозги просто, когда я ему дал рабочий прототип и раскадровку с описью, ну тут вообще не возможно представить как-то по-иному, и вот он со всей серъезностью не понимал «как это будет работать», говорит ты собери и я пойму, так ничего не понятно. Это был не первый случай и я честно делаю вывод что он «в голове собрать и повертеть» даже элементарно не может не получается у человека — и это не его проблемы а мои, и я решли этот вопрос — покликал под видео прототип.
Поэтому что туда пишут часто это такой бред сивой кобыли что да, там кто-то запишет про показатели яндекса, кто-то укажет оттенок цвета, кто-то укажет пеню оплаты за услуги, кто-то напишет что должно быть 2 человека в группе разработке (схерали не скажет конечно, не приведет раскладку и обоснование с указанием методов и аргументации зачем и как это принесет какую именно пользу, и с хера ли вообще он полез в тех часть и тд).
Но про процесс продажи это правда — как указал ранее, тз как раз «замеряет» что пошло в «цех» — это это надо обилечивать обязательно. Пишите проессы.
10. Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ?
Не может — это пост документ который тоже пишется по договоренностям, с учетом культурно-обусловленной позиции действующих в системе стейкхолдеров (персонажей).
Надеюсь помог чуточку раскрыть тему.
Я не спорю с вами — это мое имхо что написано, с чем я собственно полностью согласен на уровне — сначала идет definition того что делается, а уже другой очередью идет реализация — как бы разные процессы мыследеятельности. Вот об этом «заборе» мне кажется он и пишет — а что за забором это уже вообще не имеет значения без точечного контекста.
"
Теперь о техническом вопросе.
Надеюсь вы не занимаетесь проектировкой интерфейсов, местоположением кнопок и форма, а прописываете ваши задачи в виде ожидаемых сценарием, и примерные ожидания от их решения.
Вот вам в помощь материалы:
1. Схема мыследеятельности для работы над проектом. http://files.pavlyut.com/mindactions_v2.2.3.png
2. (разбор ее на видео https://www.youtube.com/watch?v=4erC7e8RyZM)
Очень коротенечко — у всех у каждого из нас есть прекраснейший “внутренний мир” и у каждого он свой. На каждого человка (в вашей команде например) и вместе со мной — это четыре замечательных внутренних мира. Не буду уточнять что они “возможно” “слегка” различаются (на самом деле чуть более чем полностью).
Ваш идеальный проект сейчас живет в ваших внутренних мирах. Чтобы он стал доступен всем нам для пользования он как-то должен перекочевать в более менее “том самом” состоянии, похожем на то что у вас в ваших внутренних мирах задумано.
Для успешного «перетекания” проекта из состояния замыслов он сначала попадает в артефакты (схемы, сценарии, интерфейсы), потом “воплощается” (слово не понравилось почему-то, но оно понятное всем потому что мы даем проекту “плоть” и он “объявляется” тут как тут в пространственно-временном измерении — это там где тыкать в него можно).
Эта схема содержит в себе ту карту “говорений” про проект в нужный момент времени чтобы “мысь по древу не растекашилась” и мы всегда понимали о чем гооврим, зачем это нужно, куда это вписать и где взять информацию, и что сейчас делать.
На схеме то что вы в состоянии извлечь из себя “внаружу” для воплощения проекта, а я в свою очередь не в состоянии это сделать самостоятельно, но в состоянии вас “помассировать” чтобы из вас это вышло - это все находится в левой первой части схемы “Окружающая действительность”.
Максимум что вы можете описать или “заложить” это вот первую и возможно чуток второй части схемы, потому как уже на второй нужно делать анализ и обоснования с аргументацией, уже от которых в свою очередь будет полностью зависеть правая часть, которая строится исключительно специалистами.
Я надеюсь что вам понятно о чем я тут написал, это письмо нужно для того чтобы уберечь нас от очередной „не своей” работы, которую вы скорее всего выполните (есть вероятность отличная от ноля) не совсем корректно, и будет переработка.
Все это нужно, это все равно “где-то” есть или “подразумевается”, но пока это не описано — проект проинзан дичайшими рисками на перерасход, невыполнение своих задач (построили а задача-то не это, как ее, это самое — тютю), и так далее.
Искренне надеюсь что это вам поможет, и дайте обратную связь на когда прикидывать разговоры о дальнейших работах.
“
Если вам практической информации не хватает — специально в конце статьи базовый чек лист что делать дальше — сесть и писать.
Все верно излагаете, только не надо бежать вперед клинту фразой «плати за тз» — ему не нужно тз, ему нужен результат.
Тут дело в терминологии просто — у меня тз проходит через несколько этапов как тут написано, где каждый подтверждается, и на каждом этапе полно возможностей «повизуализировать» и пофантазировать не попадая в копеечку.
Самое же дорогое в тз это как раз прописать все и прорисовать уже as is с кликами и view стейтами как это и куда, закрыть юз кейсами и тд.
А для начала мы просто пишем воздейсвтия реакции — их очень достаточно для понимания как будет работать конечный продукт у клиента.
Нельзя продать часть внутреннего процесса как услугу, если это не самостоятельная услуга со всеми ее жизненными циклами — начало, производство, доставка, закрытие.
Разница только в том что клиент и так платит за работу — не мешайте же просто себе получить проект, не надо продавать тз. Нужно сообщить что «после того как мы пропишем вам взаимодействия и вы их акцептируете, мы сможем вам показать макеты и полностью восстановить картину ожидания, тут вы сможете исправить какие-либо расположения на экране, а взаимодействия менять не будем».
Каждая фаза это точка невозврата — вообще возврата разумеется, но всем сразу ясно что это заход на новый круг — и все вопросы снимаются по тому что «мы должны все сделать потому что это к этому же относится».
Бриф брифом, а на требования есть стантарты инженирии, и все же рекомендую им прислушиваться. Клиент может напсать все что хочет — но лучше это переписать и дать ему на подпись по двум причинам:
1) Пояснить где он заблуждается или уточнить детали
2) Получить взаимную синхронизацию на понятном списке, уничтожив любые отсылки к «я вам присылал письмо там с комментарием в ворде в котором ссылки на три сайта я хотел как эти сайты».
Я просто работаю с разными проектами, космолеты не строю, но это реальный экстракт опыта для внутреннего пользования, а в данном контексте еще и приятная ревизия знающих коллег, так что в любом случае благодарен.
На одно и то же требование можно соорудить варианты формата «жигуль», «vw», «bmw», «bentley».
Обосновать = доказать. Доказательства должны быть подшиты с пометкой почему, иначе это пустые слова и цифры «из головы».
> Первый этап работы — очевидно уже за деньги.
Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.
Под этот листок далее можно высылать кп с тремя-пятью вариантами цен и сроков — я всегда беру деньги (а точнее указываю что тут вы деньги будете платить) если клиент начинает не работать над проектом, а «скидывать» принятия решений и мышление просто на нас потому что ему лениво или он не показывает заинтересованность к проекту.
> Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
Все согласовательные части которые беспокоят клиента находятся в требованиях, и в вариантах решений (эскизы, наброски, экраны).
Остальное это ваша работа и ваша часть отвественности.
> После принятия, дописать ТЗ естественно нельзя.
Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
А про жизненный цикл отдельно потом скажу. Это важная часть.
Спасибо за вопросы по существу.
Как можно написать ТЗ (задание в произдство) — без проработки взаимодействий сначала (в базовом варианте воздействие-реалкция)?
Что делаете если требование «допишут» — по кругу тз переписываете? Или по принятому у многих методу «склоняете» клиента к нужному вам решениею (не переписывать сто раз) а сразу под ограниченный процесс работать?
У вас тут дичайшая потеря качества — многие клиенты готовы оплачивать и платят за грамотную проработку, а вы сразу самогонные аппарты в производство пускаете.
Супер крутой менеджер может что угодно называть — он должен это обосновать.
Клиент свои «требования» тоже должен обосновать если хочет их пускать как есть — потребность внешнего мира (не его личная), результат который он хочет этим получить, вариант решения, аргументы почему этот вариант решения, согласованность требования (связи) с другими требованиями.
Зачем так работать вообще?