Comments 21
Отличный подход! Особенно меня порадовала идея внедрить корпоративный стиль — так заказчик сразу почувствует вашу работу как часть своего бизнеса… останется только заплатить деньги =)
Эх, если б все заказчики мыслили также… :)
Говорят, бывают такие заказчики, которым, например, готовые дизайн с вёрсткой (и тем более частично написанным JS) показывать вообще нельзя, потому что им кажется, что работа почти закончена (и остаётся только «немножко» доделать, чтобы всё заработало).
На этапе коммерческого предложения уж очень маловероятно, что заказчик подумает о том, что система почти готова. На этом этапе ещё исполнитель не выбран :)
А на других этапах вы можете доходчиво объяснить, а вменяеный заказчик вполне способен понять, что это лишь прототип и до готовой системы ещё далеко.
А на других этапах вы можете доходчиво объяснить, а вменяеный заказчик вполне способен понять, что это лишь прототип и до готовой системы ещё далеко.
А если не закажут у вас, каков убыток от разработки прототипа?
Стоимость нормочаса сотрудника, разработавшего прототип * количество затраченных часов
Если в компании прототип разрабатывают дизайнер+кодер+манагер, который им еще ставит задачу, убыток большой в любом случае. У нас прототипы рисуют менеджеры проектов и консультанты, т.е. непосредственно те сотрудники, которые общаются с клиентом.
Под консультантами имеете ввиду ux-дизайнеров? Свои или отдаете на аутсорс?
Под «консультантами» я подразумеваю продающих и консультирующих менеджеров и еще продакт-менеджеров. UX-дизайнеров в штате нашей компании нет, есть классический графический дизайнер, рисующий интерфейсы, кнопочки мулечки, но прототипированием она не занимается.
Мы не рисуем сайты, а продаем «тяжелые» корпоративные приложения, имеющие в том числе и веб-интерфейс. Основная масса клиентов уже имеют утрясенные и детально проработанные брэнд-буки и требуют веб-интерфейсы наших приложений привести в соответствие.
Теперь про прототипы и манагеров. Наше глубокое убеждение, что на этапе сбора требований, иногда проектирования системы, особенно если речь идет просто о кастомизации веба UX-специалисты не нужны. Их функции могут на себя взять менеджеры и консультанты, которые раскладывают проекты на UML-ные диаграммы и заодно накидывают интерфейсы, сразу утрясая их с заказчиком. Конечно для такого подхода нужны определенные навыки и соответствующий продукт, такой как GUI Machine. Схема абсолютно рабочая, мы по ней работаем уже не первый год.
Опять же повторюсь у нас специфический процесс, мы не разрабатываем сайты с нуля, вся функциональность наших систем и их интерфейсы отработаны годами на десятках клиентов.
Мы не рисуем сайты, а продаем «тяжелые» корпоративные приложения, имеющие в том числе и веб-интерфейс. Основная масса клиентов уже имеют утрясенные и детально проработанные брэнд-буки и требуют веб-интерфейсы наших приложений привести в соответствие.
Теперь про прототипы и манагеров. Наше глубокое убеждение, что на этапе сбора требований, иногда проектирования системы, особенно если речь идет просто о кастомизации веба UX-специалисты не нужны. Их функции могут на себя взять менеджеры и консультанты, которые раскладывают проекты на UML-ные диаграммы и заодно накидывают интерфейсы, сразу утрясая их с заказчиком. Конечно для такого подхода нужны определенные навыки и соответствующий продукт, такой как GUI Machine. Схема абсолютно рабочая, мы по ней работаем уже не первый год.
Опять же повторюсь у нас специфический процесс, мы не разрабатываем сайты с нуля, вся функциональность наших систем и их интерфейсы отработаны годами на десятках клиентов.
Под консультантами скорее имеются в виду любые сотрудники, непосредственно общающиеся с заказчиками, консультирующие их. К примеру, у нас это могут быть продажники или коммерческий директор. Только свои, никакого аутсорса.
На этапе коммерческого предложения важны характеристики как стоимость, обслуживание и сроки запуска. Внешний вид системы обсуждается после выбора поставщика решения. В дополнение, сотрудники отдела закупок, логистики или финансового контроллинга не знакомы с принципами проектирования и могут посчитать внешний вид системы как доступную функциональность, доработки которой могут потребовать дополнительных средств.
Сама идея визуально выделиться положительно влияет на выбор поставщика, но для этого можно сделать видео-презентацию вашей компании или вашего решения, документально описать возможности системы.
Сама идея визуально выделиться положительно влияет на выбор поставщика, но для этого можно сделать видео-презентацию вашей компании или вашего решения, документально описать возможности системы.
Николай,
ИМХО, для заказчика в коммерческом предложении важен первым делом факт, что исполнитель понимает задачу и готов с ней справиться. На втором месте — деньги и время. И когда мы говорим о внешнем виде и показываем прототип, в первую очередь речь идет о функциональной составляющей т.к. картинку мы берем уже привычную для заказчика. Т.е. показывая окно, описанное в нашем видео (см. выше) мы спрашиваем, правильно ли мы поняли требования заказчика, что в веб-интерфейсе удаленного оператора банка должны быть такие функции?
Немного не понял про «сотрудников отдела закупок, логистики или финансового контролинга» и «допустимую функциональность». Поясните пожалуйста мысль подробнее.
Видео-презентации компании и системы, и пользовательские документы никак не подскажут клиенту каким образом мы решим его проблемы.
ИМХО, для заказчика в коммерческом предложении важен первым делом факт, что исполнитель понимает задачу и готов с ней справиться. На втором месте — деньги и время. И когда мы говорим о внешнем виде и показываем прототип, в первую очередь речь идет о функциональной составляющей т.к. картинку мы берем уже привычную для заказчика. Т.е. показывая окно, описанное в нашем видео (см. выше) мы спрашиваем, правильно ли мы поняли требования заказчика, что в веб-интерфейсе удаленного оператора банка должны быть такие функции?
Немного не понял про «сотрудников отдела закупок, логистики или финансового контролинга» и «допустимую функциональность». Поясните пожалуйста мысль подробнее.
Видео-презентации компании и системы, и пользовательские документы никак не подскажут клиенту каким образом мы решим его проблемы.
Гарантией может выступить залог в размере определенной суммы.
Внешний вид определенной функциональности может не только помочь. Допустим, вы реализовали определенный момент и это является вашим решением. Представители других отделов, отличных от проектирования, могут посчитать, что именно так будет выглядеть ваше решение, либо это полный набор ваших возможностей.
Допустим, вы сделали чек-бокс, а представители ранее тестировали подобное решение и им не понравилось использовать чек-боксы. Ваше решение могут не выбрать, просто потому, что понравилось решение с выпадающим меню.
Внешний вид определенной функциональности может не только помочь. Допустим, вы реализовали определенный момент и это является вашим решением. Представители других отделов, отличных от проектирования, могут посчитать, что именно так будет выглядеть ваше решение, либо это полный набор ваших возможностей.
Допустим, вы сделали чек-бокс, а представители ранее тестировали подобное решение и им не понравилось использовать чек-боксы. Ваше решение могут не выбрать, просто потому, что понравилось решение с выпадающим меню.
Гарантией того, что исполнитель справится? В предлагаете в банковскую ячейку класть денежную гарантию от исполнителя и аванс от заказчика и по завершении этапа решать кто заберет деньги? Я понимаю как это работает на госбюджетных проектах куда лезут все в том числе и демпингующие фирмы однодневки, но будет ли такое работать при реализации сложных коммерческих проектов? Вы сами, Николай, пробовали денег давать за работу которую беретесь выполнить?
В конкретном примере с банком мы как и все остальные участники получили предварительные требования клиента в том числе о реализации интерфейса сканирования документов заявителей кредит. Был предоставлен перечень документов к сканированию. И если все наши конкуренты написали текстом что они могут это сделать, мы кроме текста выслали видео как мы можем это реализовать. Опять же на этапе коммерческого предложения ни о какой полноте реализации функций речи идти не может, это понимает и заказчик т.к. высылает не конечный а предварительный перечень требований. Детализация требования будет проводиться после подписания контракта на предпроекте результатом которого будет ТЗ. Вот там будет все написано полно и детально.
В конкретном примере с банком мы как и все остальные участники получили предварительные требования клиента в том числе о реализации интерфейса сканирования документов заявителей кредит. Был предоставлен перечень документов к сканированию. И если все наши конкуренты написали текстом что они могут это сделать, мы кроме текста выслали видео как мы можем это реализовать. Опять же на этапе коммерческого предложения ни о какой полноте реализации функций речи идти не может, это понимает и заказчик т.к. высылает не конечный а предварительный перечень требований. Детализация требования будет проводиться после подписания контракта на предпроекте результатом которого будет ТЗ. Вот там будет все написано полно и детально.
Видео-презентации компании, обзор возможностей программного продукта, документы — разве этим можно удивить и привлечь внимание? Это же есть у всех. А вот видео-презентация прототипа, выполненного в корпоративном стиле заказчика и демонстрирующего вполне конкретную функциональность планируемой заказчиком системы — это совсем другое. Тут принцип «давайте снимем фильм, а какой — неважно» — не работает.
Первостепенная цель прототипа — именно привлечь внимание. На этапе коммерческого приложения нет задачи проработать внешний вид системы. К тому же, у заказчика на этом этапе вообще достаточно мало объективной информации (все себя рекламируют и предлагают «лучшие» решения), поэтому заказчик вынужден делать выбор, основываясь не только на базовые показатели (цену, например), но и на собственное чутье и на такие мелкие с первого взгляда характеристики, как проявление активности потенциального исполнителя.
Что касается сотрудников заказчика, которые «не понимают» или «могут подумать». Эти вопросы просто решаются общением с заказчиком. Люди в конце-концов не глупые
Первостепенная цель прототипа — именно привлечь внимание. На этапе коммерческого приложения нет задачи проработать внешний вид системы. К тому же, у заказчика на этом этапе вообще достаточно мало объективной информации (все себя рекламируют и предлагают «лучшие» решения), поэтому заказчик вынужден делать выбор, основываясь не только на базовые показатели (цену, например), но и на собственное чутье и на такие мелкие с первого взгляда характеристики, как проявление активности потенциального исполнителя.
Что касается сотрудников заказчика, которые «не понимают» или «могут подумать». Эти вопросы просто решаются общением с заказчиком. Люди в конце-концов не глупые
Есть такой пример из моей практики, не относящийся к работе, наоборот я выступал заказчиком. Имеется земельный участок на котором хочется построить жилое здание. Для выбора архитектора проектировщика изучил множество предложений в интернете и присланных на почту. В конечном итоге предпочтение отдал архитектору, приславшему его видение конфигурации и посадки здания на моем участке. Этот исполнитель помимо цен сроков и др условий потратил суток своего времени на работу в графическом редакторе и этап выделил себя. Работаем с этим подрядчиком уже не первый год и он выполнил мне уже два проекта.
Эх, Рустем, Рустем!
как так!? в отделе тестирования не используется прототип?
как раз таки это второе наше оружие после технического задания!
Даже если прототип не очень детально проработан, но в нем есть последовательность перехода от окна к окну, расположение элементов, то все равно он нам очень поможет.
Как, например, в тестировании юзабилити, когда сама программа не работает, мы можем сразу у заказчика выяснить, что ему удобно, что нет… и сразу обсудить это перед началом реализации, тем самым сократив время на последующие переработки уже готового программного продукта. К сожалению, просто нарисованные скрины в фотошопе такого результата не дают.
Так и последующее функциональное тестирование, тоже осуществляется на основе прототипов.
как так!? в отделе тестирования не используется прототип?
как раз таки это второе наше оружие после технического задания!
Даже если прототип не очень детально проработан, но в нем есть последовательность перехода от окна к окну, расположение элементов, то все равно он нам очень поможет.
Как, например, в тестировании юзабилити, когда сама программа не работает, мы можем сразу у заказчика выяснить, что ему удобно, что нет… и сразу обсудить это перед началом реализации, тем самым сократив время на последующие переработки уже готового программного продукта. К сожалению, просто нарисованные скрины в фотошопе такого результата не дают.
Так и последующее функциональное тестирование, тоже осуществляется на основе прототипов.
Виноват, не уследил, теперь буду чаще заходить к QA в гости :)
Мария, не будь такой категоричной. Рустем в статье не писал, что «прототипы в отделе тестирования у нас не используются»! Он написал, что «РЕЖЕ», чем на этапах сбора требований, проектирования и разработки. «НЕ» и «РЕЖЕ» — большая разница, так что не надо передергивать. Другой вопрос, что с аргументацией причин редкого использования можно дополнительно поработать. Думаю, не в детальности проработки прототипа дело.
Sign up to leave a comment.
Практика использования интерактивного прототипа на этапе коммерческого предложения