Согласен, заголовок неудачный. Я подразумевал, что в таких случаях делаю это не структурировано, а как придется и ровно столько, сколько времени есть, поэтому адекватным анализом назвать нельзя. Фактически это меры по преодолению порога понимания бизнеса заказчика. Ну и способ разогреть представителя на общение.
> Один из интересных моментов — аппетит приходит во время еды, и после того как заказчик получает
> продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает
> промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Не могу сказать про итеративный подход (как я понимаю, вы рассматриваете методики типа Agile, Scrum...), лично мне нравится RUP с его четкими этапами и принципом «договариваться на берегу, а потом плыть». Но это тема отдельной дискуссии и я не готов сейчас в нее вступать.
В целом, с вашей проблемой можно бороться разными способами. Для начала нужно понять обоим (и заказчику и разработчику), что техническое задание — это не только постановка задачи, а еще и договоренности между разработчиком и заказчиком о том, как она будет решаться задача. Соответственно, этот документ также должен утверждаться. Поэтому один вариантов решения проблемы — описать в договоре реакцию на изменения.
Есть другой, более мягкий вариант. Нужно объяснить заказчику, что текущий этап работы нужно доделать до конца и закрыть актом, иначе обязательства сторон не будут считаться выполненными. А для всех новых хотелок выделить отдельную очередь и работать с ней как с обычным проектом. То есть вы просто копите хотелки и как только их собралось много — оформляете в отдельную очередь.
Менеджер менеджеру менеджер рознь. У нас на такие встречи ездит специально обученный человек и менеджер. Роль менеджера — сугубо административная: зафиксировать договоренности и обновить план. А вот человек уже разбирается с бизнесом клиента и снимает требования.
> Как можно уважать подрядчика, который забыл визитки?
Это не продажи, так что ничего страшного. Главное — не забыть голову.
Развернутый пост написать не получится, можно провалиться в конкретную область и там завязнуть. Либо не вдаваясь в подробности пройтись и получится как в этой записи.
Под ТЗ я понимаю именно Техническое задание на разработку проекта. Это как раз не бриф. Если попытаться провести аналогии, то бриф это скорее концепция проекта. А ТЗ — это его детализация. У нас под ТЗ понимается группа документов, содержащий постановку задачи на: разработку, дизайн, контент, верстку… и других.
> И клиенты все-таки не до такой степени идиоты. Бывают будь здоров разбираются, что аж бежать хочется прочь. )))
Это хороший клиент ;) Можно получить дополнительные знания, если он лучше разбирается.
На самом деле, поработав в нескольких компаниях, я часто наблюдал довольно унылую картину: приходит менеджер к клиенту, садится в кресло и включает режим диктофона, поддакивая в нужных местах. Потом уезжает в офис, пишет не менее унылое ТЗ и отдает разработчикам, которые, в свою очередь, погружаются в эротические грезы о будущем функционале.
Этот текст скорее для менеджеров компаний, которые не очень хорошо понимают, что клиент тяжело расстается с информацией. Он попросту не умеет этого делать. Главная мысль примерно такая: перед тем как поехать — подготовьтесь. Риск, что вы сделаете лажу, будет гораздо ниже, чем если просто приехать с отформатированным мозгом.
Ну а то, что я размазал мысль на несколько абзацев… Считайте демонстрацией :)
Вы правы. Но у нас модель продаж несколько другая: мы сначала продаем фазу (как правило, первая — это анализ), а потом начинаем работать. Потому что сначала же непонятно какой объем у проекта, что нужно сделать и сколько это будет стоить. Анализ как раз дает такое представление и нам и самому клиенту, но детальные выводы можно сделать только на концепции, когда уже есть задача на проектирование функционала. Вот с этого момента и можно разговаривать про урезание объема или поиска более дешевых решений.
> Можно разработчику описать интерфейс своими словами
Да, конечно. Но нужна точность и однозначность формулировок, чтобы разработчик не тратил время на разгадку смысла и занимался тем, что он действительно умеет лучше всех.
Что касается копирайтера. Это не выгодно компании. Подключая в цепочку копирайтера, она будет вынуждена нести дополнительные затраты для улучшения внутреннего документа. Кроме того, увеличится время проекта и клиенту будет достаточно сложно обосновать почему мы хотим иметь «причесанный» документ, когда нужно всего лишь донести знания в полном объеме.
Дело в том, что нормально (с учетом всех нюансов) описать интерфейс и логику может только тот, кто работал над ними. Если поручить это копиратерам или техническим писателям, то можно упустить важные моменты и знания. Разработчики будут долго обижаться =)
Но конкретно в этом случае ваш пример не показателен. Дело в том, что человек подсознательно упрощает задачу, чтобы она отнимала как можно меньше ресурсов: умственных, физических — не важно каких. Но при этом он готов принять изменение, если оно улучшает решение той же самой задачи — сокращает время на ее выполнение или вносит какие-то другие бенефиты, перекрывающие неудовольствие от рутины.
Поэтому и в случае с душем и в случае с валидацией пароля получается, что проще не стало. Стало наоборот чуть сложнее, но при этом эффективность не повысилась.
Давным-давно, в одной компании такие случаи называли «ползучий наворотизм» =)
Ну вот смотрите. Для разных ресурсов я использую разные пароли. Соответственно, их у меня больше трех (в зависимости от доверия к ресурсу и способу использования). Это значит, что если внедрить этот способ на большинстве сайтов, я буду должен запоминать не двойную цепочку: ресурс -> пароль, а тройную: ресурс -> пароль -> цвет.
Это не очень хорошая идея. Во-первых, цветовосприятие у всех разное, а цвета не всегда яркие и контрастные. Во-вторых, хеш подразумевает огромное количество уникальных вариантов, а сможет ли человек разглядеть столько цветов? В-третьих, сама по себе идея не несет ничего полезного, а напротив — отвлекает человека: заставляя обращать внимание еще и на меняющиеся цвета.
Лучше галочки справа от поля повторного ввода, которая появляется после правильного пароля, пока еще ничего не придумали.
Я понимаю, что вышеописанным страшно оскорбил чьи-то чувства, но эффективность, скорость и доступность в интерфейсах гораздо важнее прикольных фич.
Спасибо, мы давно так не смеялись. Это удивительная методология! Шедеврально почти все, но особенно порадовало: «Например, в SCRUM — 9 базовых правил. В XP — 13, а в классическом RUP — аж более 120. Почувствуйте разницу».
Нет добра или зла, есть только последствия, которые мы либо берем на себя, либо не берем. «группа теглайн» для себя решила, что они сделали рейтинг рунета. Артемий Лебедев считает, что дизайн спасет мир. Я считаю, что читать интереснее, чем слушать. Все что-то да считают.
Возможно, что они заблуждаются. Возможно они делают это нарочно, чтобы извлечь свой бонус. Хотите донести истину — несите, это ваше право. Но изложение в такой форме вредит только вам, а не рейтингу.
Любой имидж может пасть жертвой эмоций. А что касается рейтинга… Я имею отношение к разработчикам, но при этом не считаю рейтинг своим. На заборе тоже всякое пишут. Поэтому участвовать, а в финале радоваться или горевать — личное дело каждого. Лебедев, например, забил на рейтинг. Еще пара компаний, которых я знаю, тоже не участвовали, потому что заняты были работой. Вот как-то так.
Парни сделали себе рейтинг таким, каким они его видели, и предложили поучаствовать рунету, только и всего. Отнеситесь к этому чуть-чуть проще.
Читал еще во время дискуссии на роеме. Грусть и мрак. Ну да, рейтинг необъективный. Ну да, возможно, что создатели негодяи и все такое. Но пофиг, на самом деле, это их рейтинг. Глупо обижаться на то, что хозяин в своем доме передвинул мебель так, как ему хотелось. Зачем вам понадобилось сообщать всему миру, что вас не заметили в «Маааскве» и выливать тонну негатива?
Все и так понятно. Никто не пишет, что живые бактерии в йогуртах на самом деле не очень-то и живые. Люди сделали свои выводы и выбор. Время покажет кто прав. А имидж скандалиста еще долго будет забываться. Зря, в общем, вы написали с такими эмоциями и выражениями. Но дело, конечно, хозяйское.
> продукт он всегда хочет что-то дополнить и изменить, даже в процессе разработки, когда он наблюдает
> промежуточные результаты у него есть свои пожелания к изменениям. Как быть?
Не могу сказать про итеративный подход (как я понимаю, вы рассматриваете методики типа Agile, Scrum...), лично мне нравится RUP с его четкими этапами и принципом «договариваться на берегу, а потом плыть». Но это тема отдельной дискуссии и я не готов сейчас в нее вступать.
В целом, с вашей проблемой можно бороться разными способами. Для начала нужно понять обоим (и заказчику и разработчику), что техническое задание — это не только постановка задачи, а еще и договоренности между разработчиком и заказчиком о том, как она будет решаться задача. Соответственно, этот документ также должен утверждаться. Поэтому один вариантов решения проблемы — описать в договоре реакцию на изменения.
Есть другой, более мягкий вариант. Нужно объяснить заказчику, что текущий этап работы нужно доделать до конца и закрыть актом, иначе обязательства сторон не будут считаться выполненными. А для всех новых хотелок выделить отдельную очередь и работать с ней как с обычным проектом. То есть вы просто копите хотелки и как только их собралось много — оформляете в отдельную очередь.
> Как можно уважать подрядчика, который забыл визитки?
Это не продажи, так что ничего страшного. Главное — не забыть голову.
Под ТЗ я понимаю именно Техническое задание на разработку проекта. Это как раз не бриф. Если попытаться провести аналогии, то бриф это скорее концепция проекта. А ТЗ — это его детализация. У нас под ТЗ понимается группа документов, содержащий постановку задачи на: разработку, дизайн, контент, верстку… и других.
> И клиенты все-таки не до такой степени идиоты. Бывают будь здоров разбираются, что аж бежать хочется прочь. )))
Это хороший клиент ;) Можно получить дополнительные знания, если он лучше разбирается.
На самом деле, поработав в нескольких компаниях, я часто наблюдал довольно унылую картину: приходит менеджер к клиенту, садится в кресло и включает режим диктофона, поддакивая в нужных местах. Потом уезжает в офис, пишет не менее унылое ТЗ и отдает разработчикам, которые, в свою очередь, погружаются в эротические грезы о будущем функционале.
Этот текст скорее для менеджеров компаний, которые не очень хорошо понимают, что клиент тяжело расстается с информацией. Он попросту не умеет этого делать. Главная мысль примерно такая: перед тем как поехать — подготовьтесь. Риск, что вы сделаете лажу, будет гораздо ниже, чем если просто приехать с отформатированным мозгом.
Ну а то, что я размазал мысль на несколько абзацев… Считайте демонстрацией :)
Вы правы. Но у нас модель продаж несколько другая: мы сначала продаем фазу (как правило, первая — это анализ), а потом начинаем работать. Потому что сначала же непонятно какой объем у проекта, что нужно сделать и сколько это будет стоить. Анализ как раз дает такое представление и нам и самому клиенту, но детальные выводы можно сделать только на концепции, когда уже есть задача на проектирование функционала. Вот с этого момента и можно разговаривать про урезание объема или поиска более дешевых решений.
Да, конечно. Но нужна точность и однозначность формулировок, чтобы разработчик не тратил время на разгадку смысла и занимался тем, что он действительно умеет лучше всех.
Что касается копирайтера. Это не выгодно компании. Подключая в цепочку копирайтера, она будет вынуждена нести дополнительные затраты для улучшения внутреннего документа. Кроме того, увеличится время проекта и клиенту будет достаточно сложно обосновать почему мы хотим иметь «причесанный» документ, когда нужно всего лишь донести знания в полном объеме.
Дело в том, что нормально (с учетом всех нюансов) описать интерфейс и логику может только тот, кто работал над ними. Если поручить это копиратерам или техническим писателям, то можно упустить важные моменты и знания. Разработчики будут долго обижаться =)
Поэтому и в случае с душем и в случае с валидацией пароля получается, что проще не стало. Стало наоборот чуть сложнее, но при этом эффективность не повысилась.
Давным-давно, в одной компании такие случаи называли «ползучий наворотизм» =)
Лучше галочки справа от поля повторного ввода, которая появляется после правильного пароля, пока еще ничего не придумали.
Я понимаю, что вышеописанным страшно оскорбил чьи-то чувства, но эффективность, скорость и доступность в интерфейсах гораздо важнее прикольных фич.
Возможно, что они заблуждаются. Возможно они делают это нарочно, чтобы извлечь свой бонус. Хотите донести истину — несите, это ваше право. Но изложение в такой форме вредит только вам, а не рейтингу.
Парни сделали себе рейтинг таким, каким они его видели, и предложили поучаствовать рунету, только и всего. Отнеситесь к этому чуть-чуть проще.
Все и так понятно. Никто не пишет, что живые бактерии в йогуртах на самом деле не очень-то и живые. Люди сделали свои выводы и выбор. Время покажет кто прав. А имидж скандалиста еще долго будет забываться. Зря, в общем, вы написали с такими эмоциями и выражениями. Но дело, конечно, хозяйское.