Comments 31
Понравилась мысль.
Просто и со вкусом.
Стоит добавить, что очень много зависит и от самого заказчика.
Бывали случаи например, когда подготовив проект заказчику и детально всё объяснив — он «улетает на крылышках» обещая под всё это найти денег сверх бюджета. А потом начинается — «а вот у нас не хватает на это, на это, на это», «как бы нам вот это урезать». Поэтому приходится заранее очень четко узнавать у клиента сколько он реально готов потратить на проект, чтобы не делать лишней работы.
Стоит добавить, что очень много зависит и от самого заказчика.
Бывали случаи например, когда подготовив проект заказчику и детально всё объяснив — он «улетает на крылышках» обещая под всё это найти денег сверх бюджета. А потом начинается — «а вот у нас не хватает на это, на это, на это», «как бы нам вот это урезать». Поэтому приходится заранее очень четко узнавать у клиента сколько он реально готов потратить на проект, чтобы не делать лишней работы.
Спасибо!
Вы правы. Но у нас модель продаж несколько другая: мы сначала продаем фазу (как правило, первая — это анализ), а потом начинаем работать. Потому что сначала же непонятно какой объем у проекта, что нужно сделать и сколько это будет стоить. Анализ как раз дает такое представление и нам и самому клиенту, но детальные выводы можно сделать только на концепции, когда уже есть задача на проектирование функционала. Вот с этого момента и можно разговаривать про урезание объема или поиска более дешевых решений.
Вы правы. Но у нас модель продаж несколько другая: мы сначала продаем фазу (как правило, первая — это анализ), а потом начинаем работать. Потому что сначала же непонятно какой объем у проекта, что нужно сделать и сколько это будет стоить. Анализ как раз дает такое представление и нам и самому клиенту, но детальные выводы можно сделать только на концепции, когда уже есть задача на проектирование функционала. Вот с этого момента и можно разговаривать про урезание объема или поиска более дешевых решений.
мда, нужно иметь талант однозначно, — ничего нового не сказали но как красиво предподнесли.
Именно по такой схеме техникал-врайтеры обычно составляют ТЗ, именно по такой схеме адекватный фрилансер его уточняет и т.п… но вы красиво рассказали, спасибо
Именно по такой схеме техникал-врайтеры обычно составляют ТЗ, именно по такой схеме адекватный фрилансер его уточняет и т.п… но вы красиво рассказали, спасибо
аааааа… я помотрел на Ваш ник, это не Вы на днях написали статью как можно писать на абсурдеы темы тома текста? это была практика и демонстрация? :)
Вы меня раскусили! :)
На самом деле, поработав в нескольких компаниях, я часто наблюдал довольно унылую картину: приходит менеджер к клиенту, садится в кресло и включает режим диктофона, поддакивая в нужных местах. Потом уезжает в офис, пишет не менее унылое ТЗ и отдает разработчикам, которые, в свою очередь, погружаются в эротические грезы о будущем функционале.
Этот текст скорее для менеджеров компаний, которые не очень хорошо понимают, что клиент тяжело расстается с информацией. Он попросту не умеет этого делать. Главная мысль примерно такая: перед тем как поехать — подготовьтесь. Риск, что вы сделаете лажу, будет гораздо ниже, чем если просто приехать с отформатированным мозгом.
Ну а то, что я размазал мысль на несколько абзацев… Считайте демонстрацией :)
На самом деле, поработав в нескольких компаниях, я часто наблюдал довольно унылую картину: приходит менеджер к клиенту, садится в кресло и включает режим диктофона, поддакивая в нужных местах. Потом уезжает в офис, пишет не менее унылое ТЗ и отдает разработчикам, которые, в свою очередь, погружаются в эротические грезы о будущем функционале.
Этот текст скорее для менеджеров компаний, которые не очень хорошо понимают, что клиент тяжело расстается с информацией. Он попросту не умеет этого делать. Главная мысль примерно такая: перед тем как поехать — подготовьтесь. Риск, что вы сделаете лажу, будет гораздо ниже, чем если просто приехать с отформатированным мозгом.
Ну а то, что я размазал мысль на несколько абзацев… Считайте демонстрацией :)
плохие менеджеры… вообще ИМХО самая правильная практика когда на встречи ходят вдвоем (менеджер и тим-лидер который будет заниматься проектом) при условии конечно адекватности этого самого лидера, в том смысле что должен понимать кесарю-кесарево и подключаться к диалогу в необходимые моменты и не рассказывать заказчику что эту маркетинговую кнопку пыщь «мне сделать — как два пальца...»
Поддержу мысль о том, что сам менеджер на встрече ничего не сделает. У нас в агенстве на подобное мероприятие с кофе и трофейными ручками отправляется манагер и арт-дир (собственно, последний и знает, какие вопросы задавать, и что именно означают ответы на них).
P.S. Как можно уважать подрядчика, который забыл визитки?
P.S. Как можно уважать подрядчика, который забыл визитки?
Менеджер менеджеру менеджер рознь. У нас на такие встречи ездит специально обученный человек и менеджер. Роль менеджера — сугубо административная: зафиксировать договоренности и обновить план. А вот человек уже разбирается с бизнесом клиента и снимает требования.
> Как можно уважать подрядчика, который забыл визитки?
Это не продажи, так что ничего страшного. Главное — не забыть голову.
> Как можно уважать подрядчика, который забыл визитки?
Это не продажи, так что ничего страшного. Главное — не забыть голову.
Перенесите в профильный блог, вроде как кармы уже хватает…
Спасибо за статью, хочется отметить, что вы безусловно правы, «разболтать» клиента порой просто не удаётся. И всё как вы описали со скудными сведениями и унылым ТЗ менеджер едет назад. Иногда, по принципу развития того сценария который Вы описали, появляются следующие прелести жизни: манагер (новичок, не грамотный, не до конца понимающий) наобещал клиенту кучу всего, что это чуть-ли не веб-ос будет, а разработчики потом сидят сутками с выпученными глазками как у дикой собачки и пишут этот ужасный код :) Всё должно зависеть как и от менеджера студии, так и от заказчика, особенно, если он заказывает сайт не «шоп был» а для дела (продвижение бренда, продажа товаров/услуг и т.д.). Ещё раз спасибо за статью.
Хороший дополнительный продукт — помощь заказчику в составлении концепци сайта (назавем это так, например). Требует дополнительной оплаты)
Я занимался судейством футбола, и перед игрой моделировал предстоящие событя по такому же принципу. Узнать кто играет, в чем особенности, какую модель судейства применить и т.д. Очень помагало. А теперь эта наработка вошла и в остальные сферы деятельности.
Развернутый пост написать не получится, можно провалиться в конкретную область и там завязнуть. Либо не вдаваясь в подробности пройтись и получится как в этой записи.
Под ТЗ я понимаю именно Техническое задание на разработку проекта. Это как раз не бриф. Если попытаться провести аналогии, то бриф это скорее концепция проекта. А ТЗ — это его детализация. У нас под ТЗ понимается группа документов, содержащий постановку задачи на: разработку, дизайн, контент, верстку… и других.
> И клиенты все-таки не до такой степени идиоты. Бывают будь здоров разбираются, что аж бежать хочется прочь. )))
Это хороший клиент ;) Можно получить дополнительные знания, если он лучше разбирается.
Под ТЗ я понимаю именно Техническое задание на разработку проекта. Это как раз не бриф. Если попытаться провести аналогии, то бриф это скорее концепция проекта. А ТЗ — это его детализация. У нас под ТЗ понимается группа документов, содержащий постановку задачи на: разработку, дизайн, контент, верстку… и других.
> И клиенты все-таки не до такой степени идиоты. Бывают будь здоров разбираются, что аж бежать хочется прочь. )))
Это хороший клиент ;) Можно получить дополнительные знания, если он лучше разбирается.
«Нужно донести до клиента, что это всего лишь беседа и мы не проектируем систему, а вырабатываем требования к ней.»
Громкий смех в зале, местами переходящий в истерику.
Громкий смех в зале, местами переходящий в истерику.
Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Описанный выше подход верен, в том смысле что думать и готовиться необходимо.
Однако время когда заказчик смотрит на тебя влюблёнными глазами после того, как ты ему расписал во всей красе будущий проект прошло.
Сейчас он, заказчик, после всех твоих «росказней» и ТЗ добавит ещё вагон «мелких требований» и в процессе разработки будет добавлять по «маленькой тележке» требований в день.
Как грамотно тут применять итеративный подход? У меня пока получается только интуитивно — но это же не выход. Кто подскажет?
Описанный выше подход верен, в том смысле что думать и готовиться необходимо.
Однако время когда заказчик смотрит на тебя влюблёнными глазами после того, как ты ему расписал во всей красе будущий проект прошло.
Сейчас он, заказчик, после всех твоих «росказней» и ТЗ добавит ещё вагон «мелких требований» и в процессе разработки будет добавлять по «маленькой тележке» требований в день.
Как грамотно тут применять итеративный подход? У меня пока получается только интуитивно — но это же не выход. Кто подскажет?
> Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает
> продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает
> промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Не могу сказать про итеративный подход (как я понимаю, вы рассматриваете методики типа Agile, Scrum...), лично мне нравится RUP с его четкими этапами и принципом «договариваться на берегу, а потом плыть». Но это тема отдельной дискуссии и я не готов сейчас в нее вступать.
В целом, с вашей проблемой можно бороться разными способами. Для начала нужно понять обоим (и заказчику и разработчику), что техническое задание — это не только постановка задачи, а еще и договоренности между разработчиком и заказчиком о том, как она будет решаться задача. Соответственно, этот документ также должен утверждаться. Поэтому один вариантов решения проблемы — описать в договоре реакцию на изменения.
Есть другой, более мягкий вариант. Нужно объяснить заказчику, что текущий этап работы нужно доделать до конца и закрыть актом, иначе обязательства сторон не будут считаться выполненными. А для всех новых хотелок выделить отдельную очередь и работать с ней как с обычным проектом. То есть вы просто копите хотелки и как только их собралось много — оформляете в отдельную очередь.
> продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает
> промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Не могу сказать про итеративный подход (как я понимаю, вы рассматриваете методики типа Agile, Scrum...), лично мне нравится RUP с его четкими этапами и принципом «договариваться на берегу, а потом плыть». Но это тема отдельной дискуссии и я не готов сейчас в нее вступать.
В целом, с вашей проблемой можно бороться разными способами. Для начала нужно понять обоим (и заказчику и разработчику), что техническое задание — это не только постановка задачи, а еще и договоренности между разработчиком и заказчиком о том, как она будет решаться задача. Соответственно, этот документ также должен утверждаться. Поэтому один вариантов решения проблемы — описать в договоре реакцию на изменения.
Есть другой, более мягкий вариант. Нужно объяснить заказчику, что текущий этап работы нужно доделать до конца и закрыть актом, иначе обязательства сторон не будут считаться выполненными. А для всех новых хотелок выделить отдельную очередь и работать с ней как с обычным проектом. То есть вы просто копите хотелки и как только их собралось много — оформляете в отдельную очередь.
Нужно сразу договариваться след. образом:
1) вот мы зафиксировали требования к проекту, все они будут реализованы в версии 1.0
2) во время подготовки версии 1.0 набираем доп. требования, которые будут реализованы в версии 2.0, за которую Вы нам дадите энное кол-во бабла.
Если клиент не хочет так, то приводите ему след. доводы:
1) Мы договорились на какую-то сумму за определенный функционал
2) Если до начала работ, надобность в каком-либо функционале отпадает, то мы его не делаем, и соотв. не берем за него денег
3) В противоположность п.2 если возникает потребность в новом функционале, то по вашему мы должны его делать и ни чего не иметь за это?
4) Мы не отказываемся вводить доп. функционал за дополнительную плату, но делать это нужно упорядоченно, для чего нужна версионность, и Вы (заказчики) будете понимать за что платите дополнительные суммы
Как правило заказчики ни чего не могут противопоставить этому аргументу и соглашаются с ним. Если не соглашаются, то я бы не стал связываться с такими заказчиками. Ну и еще, конечно, ни в коем случае не связывайтесь с заказчиками, которые предлагают отменить п.2 и п.3 вместе, т.е. фиксируем цену проекта, и при отмене или добавлении функционала стоимость проекта не меняется. Вроде как Вы в в равных условиях, но как правило функционал будет только добавлятся. И еще на встречах не принимайте решений, т.к. на вас там давят ваши оппоненты, запишите их требования в блокнот, а потом спокойно, НА СЛЕДУЮЩИЙ ДЕНЬ все обдумайте и примите решение.
1) вот мы зафиксировали требования к проекту, все они будут реализованы в версии 1.0
2) во время подготовки версии 1.0 набираем доп. требования, которые будут реализованы в версии 2.0, за которую Вы нам дадите энное кол-во бабла.
Если клиент не хочет так, то приводите ему след. доводы:
1) Мы договорились на какую-то сумму за определенный функционал
2) Если до начала работ, надобность в каком-либо функционале отпадает, то мы его не делаем, и соотв. не берем за него денег
3) В противоположность п.2 если возникает потребность в новом функционале, то по вашему мы должны его делать и ни чего не иметь за это?
4) Мы не отказываемся вводить доп. функционал за дополнительную плату, но делать это нужно упорядоченно, для чего нужна версионность, и Вы (заказчики) будете понимать за что платите дополнительные суммы
Как правило заказчики ни чего не могут противопоставить этому аргументу и соглашаются с ним. Если не соглашаются, то я бы не стал связываться с такими заказчиками. Ну и еще, конечно, ни в коем случае не связывайтесь с заказчиками, которые предлагают отменить п.2 и п.3 вместе, т.е. фиксируем цену проекта, и при отмене или добавлении функционала стоимость проекта не меняется. Вроде как Вы в в равных условиях, но как правило функционал будет только добавлятся. И еще на встречах не принимайте решений, т.к. на вас там давят ваши оппоненты, запишите их требования в блокнот, а потом спокойно, НА СЛЕДУЮЩИЙ ДЕНЬ все обдумайте и примите решение.
Это срабатывает, если предметная область не слишком специфична и проект достаточно велик, чтобы можно было найти конкурентов, добраться до их продуктов, придумать типовое решение и не сесть с ним в лужу. :)
Сам примерно также работаю, приносит свои результаты )
ты себе противоречишь
то ты изучаешь предметную область перед встречей с клиентом, то пишешь, как получить требования без изучения предметной области
скорее, ты не исследуешь, как организована деятельность у данного конкретного заказчика (что создаёт тонну риска, как ты это сам понимаешь), а изучаешь отраслевые практики, устроойство отрасли, типовые решения, понятия, и, если удаётся — куски процессов конкурентов
поэтому «без проведения анализа» — это перегиб, его ты всё равно делаешь
то ты изучаешь предметную область перед встречей с клиентом, то пишешь, как получить требования без изучения предметной области
скорее, ты не исследуешь, как организована деятельность у данного конкретного заказчика (что создаёт тонну риска, как ты это сам понимаешь), а изучаешь отраслевые практики, устроойство отрасли, типовые решения, понятия, и, если удаётся — куски процессов конкурентов
поэтому «без проведения анализа» — это перегиб, его ты всё равно делаешь
Согласен, заголовок неудачный. Я подразумевал, что в таких случаях делаю это не структурировано, а как придется и ровно столько, сколько времени есть, поэтому адекватным анализом назвать нельзя. Фактически это меры по преодолению порога понимания бизнеса заказчика. Ну и способ разогреть представителя на общение.
Sign up to leave a comment.
«Виртуальная модель» или как нежно и аккуратно снять требования к проекту