среда, 30 июля 2014 г.

Об эффективности в ущерб эффективности

Эта статья подготовлена для блогов журнала PCWeek.
Еще в прошлом, двадцатом, веке крупные неконвейерные производства столкнулись с проблемой несбалансированности ресурсов. Поясню на примере. Если у нас конвейер, и каждая операция на нем занимает 15 секунд, то все хорошо. Если операция занимает 15 плюс-минус 10 секунд, то непрерывного конвейера не получается. Либо мы все настраиваем с учетом самой медленной операции, либо конвейер разваливается. В большинстве случаев замедлить конвейер до самой медленной операции неэффективно, поэтому появилось такое понятие, как рабочие центры.  В первом рабочем центре обрабатывается партия из тысячи изделий, потом они передаются на второй и т.д. Очень быстро возникла ситуация, когда перед «медленными» рабочими центрами стал образовываться вал партий. Одним из первых предприятий, которое предложило решение этой проблемы, была Тайота с методологией Lean. В Советском Союзе в 1964 году вышла книга Родова и Крутинского «План, поток, ритм». Основная идея «борьбы» достаточно проста: эффективность всего производства определяется эффективностью самого медленного рабочего центра. Э. Голдратт такой рабочий центр называет ограничением (не путать с бутылочным горлышком - bottle neck). Вводная часть, пожалуй, уже сильно затянулась, поэтому предлагаю перейти непосредственно к ИТ.


Для простоты возьмем пример процесса создания ПО, состоящего из 3-х этапов: бизнес-анализа, разработки, тестирования. Каждая задача должна пройти через все три этапа. Допустим, за неделю подразделение, отвечающее за бизнес-анализ, может решить 4 задачи, подразделение разработки – 5, а тестирование успевает только 3. Внимание, вопрос: «Есть ли смысл повышать эффективность разработки, чтобы они могли решать не 5, а 6 задач?» Я уверен, что в этом примере все скажут уверенное «нет». Но в реальной жизни, столкнувшись с такой ситуацией, все почему-то говорят «да». Не верите? Как мы определили в предыдущем примере, аналитикам и разработчикам достаточно решать три задачи в неделю. Четвертая, а тем более пятая, бессмысленны, т.к. все равно не будут протестированы. А теперь вопрос: «Вы руководитель разработчиков и видите, что они ничего не делают, какая ваша реакция?» Правильно, раз они ничего не делают, значит, им надо дать задачу, а как только мы дали им четвертую задачу, выясняется, что тестирование опять сорвало все планы релиза, и ничего к дате Х не протестировано. К сожалению, попытка набрать людей в отдел тестирования обычно приводит к тому, что ограничение переходит на другое подразделение, набираем людей туда – ограничение движется дальше, и так до бесконечности. 
Что же делать? Да, необходимо пытаться максимально расширить ограничение, но для этого не обязательно нанимать людей. Не справляется тестирование с объемом работ, простаивают разработчики? Пусть разработка займется написанием модульных тестов. Это, с одной стороны, позволит им не болтаться без дела, а с другой - снизит нагрузку на ограничение, т.к. базовые сценарии будут покрыты тестами, и в них снизится количество ошибок, приводящих к повторному регрессионному тестированию. Кстати, в этом случае в разработке появятся и другие плюсы: 
•Быстрее будет проходить Code Review 
•Разработчики будут больше помогать коллегам - улучшится планирование, за счет лучшего понимания всех задач; сломается Code Owning 
•Автоматизируется рутина 
•Появится документация 
•Быстрее будут исправляться ошибки 
Но необходимо понимать, что найдя бутылочное горлышко (подразделение с валом работы на входе, который они все время не успевают выполнять), мы не обязательно нашли ограничение. Допустим, бутылочное горлышко - тестирование. В тестировании «висит» огромное количество задач, но ограничением может быть разработка. Если задачи решаются настолько плохо, что возвращаются на доработку десятки раз, то не смотря на огромную скорость решения задач разработкой, проблема именно в ней. Или, что тоже достаточно вероятно, в бизнес-анализе, который формирует не достаточно четкие требования. 
Подводя итоги, можно сделать два вывода: 
1.Нет смысла пытаться повысить эффективность подразделения, если это подразделение не является ограничением. 

2.Даже если вы нашли бутылочное горлышко, не факт, что вы нашли ограничение.

Комментариев нет:

Отправить комментарий