Привет! Меня зовут Станислав Беленов, я работаю старшим специалистом по тестированию в AWG. 

Бывали ли у вас такие ситуации, когда необходимо было определить готовность продукта и его соответствие требованиям? Каждый тестировщик сталкивается с таким вопросом при начале работы с новым продуктом. В нашей команде есть больший список критериев для определения качества разрабатываемого продукта. Сейчас попробую поделиться некоторыми основными тезисами или правилами.

 Начать надо с понимания, что тестировщик необходим с начала разработки идей продукта. Его компетенция поможет определить узкие места разрабатываемого приложения, поможет определить необходимое распределение нагрузки на модули, а правильно составленный тест-план на этапе разработки концепта поможет определить сроки для проведения качественного тестирования.

Тестировщик для нашей команды - это та невидимая нить, которая пронизывает и связывает все коммуникации внутри разрабатываемого продукта. Его компетенция и коммуникация позволяет смотреть по-другому не только на подходы к определению и тестированию требований заказчика, но и влиять на процесс разработки, аналитики, да и на процесс установки требований заказчиком. 

Мы создаем цифровые продукты для решения конкретных задач реальных пользователей. Поэтому объективное представление о том, чем эти пользователи живут и с какими проблемами сталкиваются, — то, без чего невозможна разработка нового продукта или улучшение старого.

В свое время Алан Купер сформулировал «метод персон» (или персонажей) — фреймворк, в рамках которого разрабатывается усредненный портрет типичного пользователя какого-либо интерфейса. По мнению автора, только проявив эмпатию, поняв цели и задачи людей, можно придумать какое-либо решение и разработать удобный продукт, который им понравится.

Несмотря на то что с момента появления книги было написано большое количество гайдов по персонам, отрасль не стояла на месте. Появлялись новые методы проектирования и другие интересные фреймворки. И вроде бы персонажи отошли на второй план, уступив место новым механикам. Например, многие сторонники Jobs-To-Be-Done убеждены в том, что их методология значительно превосходит персоны в плане практического применения. Но так ли это?

Мы считаем, что персоны сейчас более чем актуальны и способны повысить эффективность процесса работы над цифровым продуктом. Далее в статье мы покажем, что данный метод вовсе не противоречит новым подходам, в том числе Jobs-To-Be-Done. Но, наоборот, прекрасно их дополняет, а в некоторых случаях лежит в основе. В общем, обо всем по порядку.

Когда дело доходит до расчета стоимости проекта, важно правильно выбрать форму взаимодействия между заказчиком и исполнителем. Обычно выделяют две модели оплаты: Time & Material — когда заказчик оплачивает часы по факту выполненных работ, и Fixed-Price — когда стороны заранее утверждают бюджет и точные сроки сдачи проекта.

Большинство заказчиков предпочитают вторую модель, так как она дает представление о финальной стоимости проекта — конечно, если исполнитель знает суммарные трудозатраты и составляет реалистичный и обоснованный бюджет. Но как оценить дизайн-проект сайта или приложения, ничего не зная о его будущей структуре?

Здесь высок риск ошибиться в расчетах и упустить те детали, которые редко обсуждаются на первых двух-трех встречах с клиентом. А ошибки в первоначальном расчете ведут к неизбежным убыткам со стороны исполнителя. В итоге агентство теряет деньги и вынуждено завершать проект в ущерб качеству.

Предлагаемый нами алгоритм позволяет не брать смету с потолка, а оценивать проект так, чтобы четко понимать возможные сроки и объем работ.

Боль с одним проектом привела нас к решению написать правила работы

Аннотация

Кому это нужно