Comments 11
требования можно заказать,… я делаю это только в студии и за деньгиКак я понял — вы это делаете в своей студии за деньги заказчика.
Очень интересно: как вам удается заманить заказчика к себе в студию и как вы оцениваете свою работу по составлению требований (сколько денег и за что берете)?
Кратко — это консалтинговая услуга, и обычно таблицу с требованиями люди пишут сами.
Если кто-то хочет что-то сделать и не понимает что именно — это уже проблемный клиент. Скорее всего не будет с ним работы.
Я это указываю каждый раз как важный разделитель работы — тут я в голову никому не залезу и не вытащу то что ему нужно. Если он хочет чтобы я сидел и беседовал с ним как психоаналитик под запись — если в принципе человеку это сложно, а он по личной оценке нормальный — можно и побеседовать бесплатно.
Отдельно стоит отдельных денег проектировка требований к примеру под ключ — когда приходят и говорят кратко — нам нужно супермегамагзин (и дают ссылку) и работать не хотят, пару слов связать не могут. Тогда я просто формирую требования сам, угадывая что им может понадобиться, сам об этом предупреждаю что оплачивают они работу которую сами сделают быстрее и проще — поэтому предоплата, поэтому что напишу то у них и будет — любая корректировка это уже другой вид работ.
Важно верно выстраивать отношения и показывать что ты работать хочешь, и делать хочешь это хорошо — но не надо все в кучу валить, тут работают две стороны над проектом, и если клиент халтурит, ему надо на это указать, но не бросать проект и все же делать. Поэтому и требования, поэтому и за деньги.
Суммы сильно зависят от проекта и идут как консалтинг.
Если кто-то хочет что-то сделать и не понимает что именно — это уже проблемный клиент. Скорее всего не будет с ним работы.
Я это указываю каждый раз как важный разделитель работы — тут я в голову никому не залезу и не вытащу то что ему нужно. Если он хочет чтобы я сидел и беседовал с ним как психоаналитик под запись — если в принципе человеку это сложно, а он по личной оценке нормальный — можно и побеседовать бесплатно.
Отдельно стоит отдельных денег проектировка требований к примеру под ключ — когда приходят и говорят кратко — нам нужно супермегамагзин (и дают ссылку) и работать не хотят, пару слов связать не могут. Тогда я просто формирую требования сам, угадывая что им может понадобиться, сам об этом предупреждаю что оплачивают они работу которую сами сделают быстрее и проще — поэтому предоплата, поэтому что напишу то у них и будет — любая корректировка это уже другой вид работ.
Важно верно выстраивать отношения и показывать что ты работать хочешь, и делать хочешь это хорошо — но не надо все в кучу валить, тут работают две стороны над проектом, и если клиент халтурит, ему надо на это указать, но не бросать проект и все же делать. Поэтому и требования, поэтому и за деньги.
Суммы сильно зависят от проекта и идут как консалтинг.
Все что присылает клиент — это требования (как бы он это не называл)
Первый этап работы — пишем ТЗ, на основании требований и/или встречи с клиентом.
Все остальные этапы оцениваются на основании ТЗ.
Но вообще, опытный ПМ, тупо по тексту заявки на 85% сможет сказать какой в итоге у проекта будет бюджет, по этому, во многих случая можно назвать вилку цен сразу.
Первый этап работы — пишем ТЗ, на основании требований и/или встречи с клиентом.
Все остальные этапы оцениваются на основании ТЗ.
Но вообще, опытный ПМ, тупо по тексту заявки на 85% сможет сказать какой в итоге у проекта будет бюджет, по этому, во многих случая можно назвать вилку цен сразу.
Ну вот у вас и утечка и ввод в заблуждение клиента — что вы работаете по любому его запросу без оплаты. Много у вас времени отказные тз писать?
Как можно написать ТЗ (задание в произдство) — без проработки взаимодействий сначала (в базовом варианте воздействие-реалкция)?
Что делаете если требование «допишут» — по кругу тз переписываете? Или по принятому у многих методу «склоняете» клиента к нужному вам решениею (не переписывать сто раз) а сразу под ограниченный процесс работать?
У вас тут дичайшая потеря качества — многие клиенты готовы оплачивать и платят за грамотную проработку, а вы сразу самогонные аппарты в производство пускаете.
Супер крутой менеджер может что угодно называть — он должен это обосновать.
Клиент свои «требования» тоже должен обосновать если хочет их пускать как есть — потребность внешнего мира (не его личная), результат который он хочет этим получить, вариант решения, аргументы почему этот вариант решения, согласованность требования (связи) с другими требованиями.
Зачем так работать вообще?
Как можно написать ТЗ (задание в произдство) — без проработки взаимодействий сначала (в базовом варианте воздействие-реалкция)?
Что делаете если требование «допишут» — по кругу тз переписываете? Или по принятому у многих методу «склоняете» клиента к нужному вам решениею (не переписывать сто раз) а сразу под ограниченный процесс работать?
У вас тут дичайшая потеря качества — многие клиенты готовы оплачивать и платят за грамотную проработку, а вы сразу самогонные аппарты в производство пускаете.
Супер крутой менеджер может что угодно называть — он должен это обосновать.
Клиент свои «требования» тоже должен обосновать если хочет их пускать как есть — потребность внешнего мира (не его личная), результат который он хочет этим получить, вариант решения, аргументы почему этот вариант решения, согласованность требования (связи) с другими требованиями.
Зачем так работать вообще?
Откуда такие выводы?
Первый этап работы — очевидно уже за деньги.
Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
После принятия, дописать ТЗ естественно нельзя.
Супер круто менеджер может обосновать что угодно.
— да это все очевидно в целом, в статье эти простые вещи как то безумно усложнены. «Жизненный цикл требования» — зачем это нужен? Встречавшийся, спрашиваешь что нужно, анализируешь, предлагаешь вариант решения. Естественно вся эта работа оплачивается клиентом. Излишняя бюрократия только снижает качество и способствует потери сути.
Первый этап работы — очевидно уже за деньги.
Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
После принятия, дописать ТЗ естественно нельзя.
Супер круто менеджер может обосновать что угодно.
— да это все очевидно в целом, в статье эти простые вещи как то безумно усложнены. «Жизненный цикл требования» — зачем это нужен? Встречавшийся, спрашиваешь что нужно, анализируешь, предлагаешь вариант решения. Естественно вся эта работа оплачивается клиентом. Излишняя бюрократия только снижает качество и способствует потери сути.
> Откуда такие выводы?
На одно и то же требование можно соорудить варианты формата «жигуль», «vw», «bmw», «bentley».
Обосновать = доказать. Доказательства должны быть подшиты с пометкой почему, иначе это пустые слова и цифры «из головы».
> Первый этап работы — очевидно уже за деньги.
Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.
Под этот листок далее можно высылать кп с тремя-пятью вариантами цен и сроков — я всегда беру деньги (а точнее указываю что тут вы деньги будете платить) если клиент начинает не работать над проектом, а «скидывать» принятия решений и мышление просто на нас потому что ему лениво или он не показывает заинтересованность к проекту.
> Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
Все согласовательные части которые беспокоят клиента находятся в требованиях, и в вариантах решений (эскизы, наброски, экраны).
Остальное это ваша работа и ваша часть отвественности.
> После принятия, дописать ТЗ естественно нельзя.
Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
А про жизненный цикл отдельно потом скажу. Это важная часть.
Спасибо за вопросы по существу.
На одно и то же требование можно соорудить варианты формата «жигуль», «vw», «bmw», «bentley».
Обосновать = доказать. Доказательства должны быть подшиты с пометкой почему, иначе это пустые слова и цифры «из головы».
> Первый этап работы — очевидно уже за деньги.
Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.
Под этот листок далее можно высылать кп с тремя-пятью вариантами цен и сроков — я всегда беру деньги (а точнее указываю что тут вы деньги будете платить) если клиент начинает не работать над проектом, а «скидывать» принятия решений и мышление просто на нас потому что ему лениво или он не показывает заинтересованность к проекту.
> Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
Все согласовательные части которые беспокоят клиента находятся в требованиях, и в вариантах решений (эскизы, наброски, экраны).
Остальное это ваша работа и ваша часть отвественности.
> После принятия, дописать ТЗ естественно нельзя.
Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
А про жизненный цикл отдельно потом скажу. Это важная часть.
Спасибо за вопросы по существу.
> Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.
Да, это называется бриф )
> ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
И что? Почему он не должен за это платить? Клиент хочет проект без тз? пусть наймет фрилансера. Если он делает проект за лям+ то прекрасно понимает что за это нужно платить.
> Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
Все верно. Для этого существует отдел технической поддержки. Создание — лишь первый этап. Потом идет развратите и постоянные доработки, которые ни кончаются никогда. Продакшен сам по себе умирает, современные проекты резонней рассматривать как бесконечную и постоянную череду доработок.
Да, это называется бриф )
> ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.
И что? Почему он не должен за это платить? Клиент хочет проект без тз? пусть наймет фрилансера. Если он делает проект за лям+ то прекрасно понимает что за это нужно платить.
> Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.
Все верно. Для этого существует отдел технической поддержки. Создание — лишь первый этап. Потом идет развратите и постоянные доработки, которые ни кончаются никогда. Продакшен сам по себе умирает, современные проекты резонней рассматривать как бесконечную и постоянную череду доработок.
Я так понимаю онтолгию нашей беседы говорим про одно и то же.
Все верно излагаете, только не надо бежать вперед клинту фразой «плати за тз» — ему не нужно тз, ему нужен результат.
Тут дело в терминологии просто — у меня тз проходит через несколько этапов как тут написано, где каждый подтверждается, и на каждом этапе полно возможностей «повизуализировать» и пофантазировать не попадая в копеечку.
Самое же дорогое в тз это как раз прописать все и прорисовать уже as is с кликами и view стейтами как это и куда, закрыть юз кейсами и тд.
А для начала мы просто пишем воздейсвтия реакции — их очень достаточно для понимания как будет работать конечный продукт у клиента.
Нельзя продать часть внутреннего процесса как услугу, если это не самостоятельная услуга со всеми ее жизненными циклами — начало, производство, доставка, закрытие.
Разница только в том что клиент и так платит за работу — не мешайте же просто себе получить проект, не надо продавать тз. Нужно сообщить что «после того как мы пропишем вам взаимодействия и вы их акцептируете, мы сможем вам показать макеты и полностью восстановить картину ожидания, тут вы сможете исправить какие-либо расположения на экране, а взаимодействия менять не будем».
Каждая фаза это точка невозврата — вообще возврата разумеется, но всем сразу ясно что это заход на новый круг — и все вопросы снимаются по тому что «мы должны все сделать потому что это к этому же относится».
Бриф брифом, а на требования есть стантарты инженирии, и все же рекомендую им прислушиваться. Клиент может напсать все что хочет — но лучше это переписать и дать ему на подпись по двум причинам:
1) Пояснить где он заблуждается или уточнить детали
2) Получить взаимную синхронизацию на понятном списке, уничтожив любые отсылки к «я вам присылал письмо там с комментарием в ворде в котором ссылки на три сайта я хотел как эти сайты».
Я просто работаю с разными проектами, космолеты не строю, но это реальный экстракт опыта для внутреннего пользования, а в данном контексте еще и приятная ревизия знающих коллег, так что в любом случае благодарен.
Все верно излагаете, только не надо бежать вперед клинту фразой «плати за тз» — ему не нужно тз, ему нужен результат.
Тут дело в терминологии просто — у меня тз проходит через несколько этапов как тут написано, где каждый подтверждается, и на каждом этапе полно возможностей «повизуализировать» и пофантазировать не попадая в копеечку.
Самое же дорогое в тз это как раз прописать все и прорисовать уже as is с кликами и view стейтами как это и куда, закрыть юз кейсами и тд.
А для начала мы просто пишем воздейсвтия реакции — их очень достаточно для понимания как будет работать конечный продукт у клиента.
Нельзя продать часть внутреннего процесса как услугу, если это не самостоятельная услуга со всеми ее жизненными циклами — начало, производство, доставка, закрытие.
Разница только в том что клиент и так платит за работу — не мешайте же просто себе получить проект, не надо продавать тз. Нужно сообщить что «после того как мы пропишем вам взаимодействия и вы их акцептируете, мы сможем вам показать макеты и полностью восстановить картину ожидания, тут вы сможете исправить какие-либо расположения на экране, а взаимодействия менять не будем».
Каждая фаза это точка невозврата — вообще возврата разумеется, но всем сразу ясно что это заход на новый круг — и все вопросы снимаются по тому что «мы должны все сделать потому что это к этому же относится».
Бриф брифом, а на требования есть стантарты инженирии, и все же рекомендую им прислушиваться. Клиент может напсать все что хочет — но лучше это переписать и дать ему на подпись по двум причинам:
1) Пояснить где он заблуждается или уточнить детали
2) Получить взаимную синхронизацию на понятном списке, уничтожив любые отсылки к «я вам присылал письмо там с комментарием в ворде в котором ссылки на три сайта я хотел как эти сайты».
Я просто работаю с разными проектами, космолеты не строю, но это реальный экстракт опыта для внутреннего пользования, а в данном контексте еще и приятная ревизия знающих коллег, так что в любом случае благодарен.
Sign up to leave a comment.
У нас же есть техническое задание на систему / сайт / приложение / проект…