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