Уверенна, что перед каждым тестировщиком когда-либо стояла задача оценить своё время на тестирование той или иной фичи. Я даже могу на 100% сказать, что к каждому подбегал Project Manager (или QA Test Manager) с взъерошенными волосами и вопросом: "Прикинь быстренько время на тестирование вот этого функционала, который выпустят сегодня вечером разработчики". И ты сидишь, пытаясь оценить эту ерунду, не понимая, зачем всё это нужно. Тем более в эту оценку порой и не укладываешься. В этой статье я подробно опишу подход, как лучше, а может быть и даже правильно, оценивать трудозатраты на проект.
Во-первых, зачем нужна оценка. Ведь можно просто оговорить примерные сроки и уложиться в них.
Это нужно для Заказчика, а точнее для обоснования запрашиваемых денег перед Заказчиком. Потому что Заказчик:
1. Не понимает, откуда взялась такая цифра на тестирование. Почему вы делаете работу за 100 рублей, а ваши конкуренты за 50? (Тут ответ простой: скорее всего конкурент предлагает сделать далеко не все работы.)
2. Не видит всю декомпозицию работ. И в результате половину работы совсем забыли оценить: доработка тест-кейсов, создание методики, пользовательских документов и т.д.
3. Не знает, кто будет работать и какие виды работ будут выполнены.
Во-вторых, необходимо всегда и для каждого проекта:
- Определить сроки;
- Определить объем работ;
- Определить ресурсы;
- Рассчитать стоимость.
Потому что все перечисленные пункты нужны для того, чтобы понять "выгодность" проекта, готовность компании (ресурсы) этот проект выполнять.
Но обычно оценки неверные, потому что:
- нет плана работ;
- нет документации или знания о системе;
- ожидания Заказчика и исполнителя противоречивы.
Такое бывает, когда под давлением Заказчика Исполнитель не может обосновать свою оценку. Поэтому нужно уметь обосновать, каждый пункт аргументировать.
А теперь перейду непосредсвенно к оценке.
. Прежде чем оценивать проект необходимо:
- создать шаблоны - опросник для клиента, что он хочет видеть в проекте, согласовываем видение сторон; какие виды работ будет включать каждый пункт (подробно расписываем); определяем сумму, в которую должны уложиться. На выходе должен получиться документ с описанием систем и функций, процессов и взаимодействие между процессами.
- выделяем технического специалиста, ответсвенного за оценку (pre-sale consultant).
- выделяем эксперта, согласующего все оценки (опытный человек с производства).
На этом этапе следует четко определить, что нужно обязательно проходить эту процедуру. Нельзя просто подойти к какому-то специалисту и "быстренько" всё оценить. А потом выяснится, что всё уже показали и согласовали с клиентом. Нельзя взять человека, который ни разу не занимался оценками и сказать - а давай-ка ты сейчас оценишь трудозатраты.
Вот когда мы очень хорошо выполнили п1 (создание шаблонов), приступаем к черновой оценке, а точнее к определению шаблонов для оценки. Определяем единицу измерения - тест кейс, число тест кейсов для проверки функционала, виды тестирования и глубину тестового сценария. Исходя из этого считаем:
- время на написание тест кейсов и тест планов;
- длительность прохождения тест кейса. Не надо брать длительность прохождения самого большого или самого маленького тест кейса, потому что оценка выйдет очень грубой.
- длительность прохождения по одного методу тестирования;
- длительность на написание отчета (или отчетов) по тестированию;
Необходимо учесть, что время на занесение дефекта в BTS не расписывается, а включается в время прохождения тест кейса. Оно будет больше, и это необходимо заранее сообщить Заказчику, чтобы не возникало вопросов.
К черновой оценке добавляем этапы работ и состав команды. И самое главно - РИСКИ, включающие в себя основные пункты как квалификация сотрудников, которая у всех разная, налаженность коммуникаций и т.д.. Их необходимо включать в каждый пункт черновой оценки. Если в результате мы вышли за лимит проекта, то оценки следует откорректировать и переоценить, иначе все труды приведут к тому, что проект окажется не выгодным и принесет больше расходов, чем доходов.
И....СОГЛАСОВАНИЕ. После этого этапа приступаем к работе!
Каждый метод составления оценки трудозатрат имеет свои достоинства и недостатки:
+ прозрачная структура расходов;
+ снижение рисков проекта;
+ четкое обоснование выполняемых работ.
- длительный срок оценки;
- большое количество внешних коммуникаций;
- жесткое требование к знанию предметной области (минус ли это? В других методах оценки это будет подводным камнем).
Такой подход, на мой взгляд, наиболее правильный, чем оценивать трудозатраты на коленках. Даже минусы подхода так или иначе в результате приведут к плюсам.
PS: погрешность оценки всегда не должна превышать 20%.
Надеюсь, эта статья была полезной для Вас.
Во-первых, зачем нужна оценка. Ведь можно просто оговорить примерные сроки и уложиться в них.
Это нужно для Заказчика, а точнее для обоснования запрашиваемых денег перед Заказчиком. Потому что Заказчик:
1. Не понимает, откуда взялась такая цифра на тестирование. Почему вы делаете работу за 100 рублей, а ваши конкуренты за 50? (Тут ответ простой: скорее всего конкурент предлагает сделать далеко не все работы.)
2. Не видит всю декомпозицию работ. И в результате половину работы совсем забыли оценить: доработка тест-кейсов, создание методики, пользовательских документов и т.д.
3. Не знает, кто будет работать и какие виды работ будут выполнены.
Во-вторых, необходимо всегда и для каждого проекта:
- Определить сроки;
- Определить объем работ;
- Определить ресурсы;
- Рассчитать стоимость.
Потому что все перечисленные пункты нужны для того, чтобы понять "выгодность" проекта, готовность компании (ресурсы) этот проект выполнять.
Но обычно оценки неверные, потому что:
- нет плана работ;
- нет документации или знания о системе;
- ожидания Заказчика и исполнителя противоречивы.
Такое бывает, когда под давлением Заказчика Исполнитель не может обосновать свою оценку. Поэтому нужно уметь обосновать, каждый пункт аргументировать.
А теперь перейду непосредсвенно к оценке.
. Прежде чем оценивать проект необходимо:
- создать шаблоны - опросник для клиента, что он хочет видеть в проекте, согласовываем видение сторон; какие виды работ будет включать каждый пункт (подробно расписываем); определяем сумму, в которую должны уложиться. На выходе должен получиться документ с описанием систем и функций, процессов и взаимодействие между процессами.
- выделяем технического специалиста, ответсвенного за оценку (pre-sale consultant).
- выделяем эксперта, согласующего все оценки (опытный человек с производства).
На этом этапе следует четко определить, что нужно обязательно проходить эту процедуру. Нельзя просто подойти к какому-то специалисту и "быстренько" всё оценить. А потом выяснится, что всё уже показали и согласовали с клиентом. Нельзя взять человека, который ни разу не занимался оценками и сказать - а давай-ка ты сейчас оценишь трудозатраты.
Вот когда мы очень хорошо выполнили п1 (создание шаблонов), приступаем к черновой оценке, а точнее к определению шаблонов для оценки. Определяем единицу измерения - тест кейс, число тест кейсов для проверки функционала, виды тестирования и глубину тестового сценария. Исходя из этого считаем:
- время на написание тест кейсов и тест планов;
- длительность прохождения тест кейса. Не надо брать длительность прохождения самого большого или самого маленького тест кейса, потому что оценка выйдет очень грубой.
- длительность прохождения по одного методу тестирования;
- длительность на написание отчета (или отчетов) по тестированию;
Необходимо учесть, что время на занесение дефекта в BTS не расписывается, а включается в время прохождения тест кейса. Оно будет больше, и это необходимо заранее сообщить Заказчику, чтобы не возникало вопросов.
К черновой оценке добавляем этапы работ и состав команды. И самое главно - РИСКИ, включающие в себя основные пункты как квалификация сотрудников, которая у всех разная, налаженность коммуникаций и т.д.. Их необходимо включать в каждый пункт черновой оценки. Если в результате мы вышли за лимит проекта, то оценки следует откорректировать и переоценить, иначе все труды приведут к тому, что проект окажется не выгодным и принесет больше расходов, чем доходов.
И....СОГЛАСОВАНИЕ. После этого этапа приступаем к работе!
Каждый метод составления оценки трудозатрат имеет свои достоинства и недостатки:
+ прозрачная структура расходов;
+ снижение рисков проекта;
+ четкое обоснование выполняемых работ.
- длительный срок оценки;
- большое количество внешних коммуникаций;
- жесткое требование к знанию предметной области (минус ли это? В других методах оценки это будет подводным камнем).
Такой подход, на мой взгляд, наиболее правильный, чем оценивать трудозатраты на коленках. Даже минусы подхода так или иначе в результате приведут к плюсам.
PS: погрешность оценки всегда не должна превышать 20%.
Надеюсь, эта статья была полезной для Вас.
