Записки тестировщика. Читать все статьи »

Консалтинг в тестировании.

Сегодня я хочу подумать вслух и пригласить Вас, уважаемые читатели, к диалогу на тему консалтинга и его применимости к процессам тестирования и обеспечения качества.

Как вы помните, я уже обещал затронуть эту тему в одном из предыдущих выпусков Записок, но не так вышло, как планировалось: прошлый выпуск вышел со статьями на тему основ автоматизации функционального и нагрузочного тестирования.

Давайте попробуем разобраться, что такое консалтинг в тестировании, нужен ли он в принципе и кому. Как сделать так, чтобы его использование (если мы придём к выводу, что консалтинг всё-таки полезен) приносило выгоду, ведь любые действия, которые производит компания, даже если они не связаны с получением прямой прибыли от основной деятельности, так или иначе направлены на получение или увеличение прибыли.

Итак, что же такое консалтинг?

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

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

Что такое консалтинг в IT-индустрии.

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

Аутсорсинг решает производственные задачи, то есть задачи по выполнению работ. А что же делать, если вопросы, с которыми приходится сталкиваться, находятся в сфере методологий, в сфере «Как работать»?

Бизнес давно перестал быть статичным, а выпуск программного обеспечения, его внедрение и использование, как никакие другие отрасли, завязанные на использовании современных технологий, требуют постоянных изменений. Современный, динамичный бизнес требует внедрения технологий, инструментов и методологий буквально в «живые» системы и процессы. Сейчас часто слышится: «У нас он-лайн бизнес». Не в смысле обязательной привязки к веб технологиям и решениям, а в смысле буквально интерактивного взаимодействия с клиентами и партнёрами. Внедрение новых подходов, самих способов работы в бизнес, использующий современные информационные технологии, требует знаний и опыта не только в сфере самого бизнеса, его основных аспектов, но и технологий и решений на столь же высоком уровне. Знаний и опыта именно в IT-среде зачастую остро не хватает даже тем компаниям, чей бизнес непосредственно завязан на технологии и программное обеспечение.

Это длинное вступление, которое, надеюсь, не сильно утомило вас, необходимо, для того, чтобы мы и дальше говорили на одном языке. Проблематика очерчена, пойдём к решениям.

Реальные задачи, как нельзя более кстати, подходят для рассмотрения практических вопросов. И конечно, я подбирал задачу, которая близка и понятна мне и соответствует теме нашего издания, теме Записок тестировщика. Задача не новая, она взята из личного опыта и как я могу судить по обсуждениям и вопросам на Форуме тестировщиков, постоянно возникает вновь и вновь. Задача создания и запуска отдела (службы) тестирования в компании. Зачем нужен свой отдел, нужен ли он в принципе, здесь обсуждаться не будет. Был период, когда я был уверен, что отдавать на аутсорсинг тестирование это большущая глупость. Со временем перед глазами проходили ситуации, когда компаниям свой отдел не особо и нужен. Менялась и точка зрения на вопрос. Сейчас речь не об этом. Это просто задача.

Вам нужен отдел тестирования.

Казалось бы, в чём вопрос? Есть представление о том, какие задачи будет решать отдел. Есть возможность поиска и найма таких специалистов. Вопросы кто и что будет делать ясен. Остаётся краеугольный вопрос, который может «свести на нет» весь результат работы отдела или службы: как делать. И тут уже нужен опыт, которым зачастую не могут обладать люди, которые работали ранее в подобных подразделениях или тем более только становятся у руля такой группы. Как запустить отдел, какими процедурами руководствоваться, как взаимодействовать с другими отделами, как решать спорные вопросы, каким инструментом пользоваться. Все эти вопросы могут решать только при комплексном изменении в компании. Организуемая структура не может быть оторванной частью чего-то, это часть процессов компании. И встроить эту структуру в здание компании нужно уметь.

Что получим, если попробуем купить хорошего специалиста на постоянной основе.

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

Что получится.
Найм дорогостоящего специалиста. Определённый срок внедрения процессов, налаживания работ. Отладки или состыковки процессов смежных направлений (а это будет обязательно – мы изменяем что-то в единой структуре). Запуска подразделения или нового вида деятельности существующей группы: автоматизированного тестирования, к примеру.

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

Что получим, если попробуем привлечь консультанта или консалтинговую компанию.
Получим то, что мне нравится в любом виде деятельности — фокусировку на выполняемых задачах. Человек или группа людей (а если отдел внедряется в достаточно крупной организации, которая, к примеру, решила не отдавать тестирование на аутсорсинг, а развивать собственное направление — то потребуется не один консультант, как мы понимаем) выполняет проект по внедрению или созданию. Внедрение имеет вполне конкретный, измеряемый результат и все преимущества проектного подхода: бюджет, срок и удовлетворение потребностей заказчика. То есть создание/внедрение не становится деятельностью, а остаётся обычным проектом, направленным на развитие.

«Подводные камни»:

1. Понимание задач консалтинга

• Консалтинг не будет сам тестировать или разрабатывать.
• Консалтинг не придумает за вас список проблем, которые нужно решать (иначе стоит задаться вопрос: зачем вам вообще консалтинг?)
• Консалтинг не решает ваши проблемы за вас, он говорит вам как их решить – работать всё равно придётся вам.

2. Двусторонняя работа

• Один консультант (или группа), без поддержки тех людей, которые участвуют в процессе, который требует изменений, просто не сможет сдвинуться с места. Вы ведь не молчите на приёме у врача?

3. Управление работой консультанта.

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

Эти вопросы, зачастую становятся основой негативного опыта работы с консультантами. И во многом это проблема самих консультантов — управление ожиданиями Заказчика, наверное первое, что стоит обсуждать при заключении контракта на проведение консалтинга. Это основа «Что хочет получить Заказчик». С другой стороны и сам заказчик должен чётко видеть проблемы. Формализовать их, найти вариант решения — хлеб консультанта, но решить что-то, на что не было заказа, как мы понимаем довольно сложно.

Что касается привлечения консультантов, для проведения обучения и подобных мероприятий. Давайте чётко разграничим области: обучение и консалтинг. Зачастую на тренингах слышаться конкретные вопросы, на которые тренер, даже обладающий большим практическим опытом не может дать ответ. Он попросту не видит ситуации и проблемы.

Выводы:
Для определённых задач, я бы сказал для определённого круга специфичных, возможно даже разовых (!) задач, привлечение консультантов видится оправданным. С учётом перечисленных выше условий его нормальной работы. Для тестирования я таких задач вижу несколько и все они так или иначе связаны с управлением существующего или запуском нового процесса — тестирования или управления качеством. Заметим, я не отождествляю эти понятия, я дополняю список задач.

Задачи, выполнение которых, мне кажется, требует консалтинга:

• Задачи создания отдела тестирования или службы качества.
• Внедрение процессов и методик работы подразделения.
• Выбор инструментов для автоматизации тестирования.
• Внедрение процессов автоматизации тестирования.
• Внедрение процессов управления качеством.

Список, наверное, может быть продолжен, я только хочу подчеркнуть общее для обозначенного выше: внедрение и создание — это задачи временные, а не постоянные, в отличии от самого тестирования и управления качеством. Именно внедрение, создания нового требует опыта, а не формальных навыков.

Заключение:
У меня перестали получаться коротенькие статьи-заметки. Это минус. Но с другой стороны и вопросы, которые я стал обсуждать с вами, уважаемые подписчики, становятся всё более серьёзными. Иногда, мне хочется разбить статью на серию статей, но с этим я пока борюсь. И я снова и снова приглашаю вас принимать участие в обсуждении тех вещей, которые я предлагаю на страницах своих «Записок».

Спасибо, удачи!
--
Вячеслав Панкратов
16/12/2004 для проекта «Сервер тестировщиков».