Водопадная модель управления проектами (waterfall model) известна уже очень давно, став классикой в разработке программного обеспечения для многих ИТ компаний. При таком процессе поступившая задача последовательно переходит от одного узла к другому. Например: требование > дизайн > разработка > тестирование > внедрение > поддержка.

Пожалуй, для одной задачи, данную систему действительно можно было бы назвать почти «идеальной». Но что происходит в реальной жизни? Первое, что бросается в глаза руководителю проекта, назовём его - Пётр, это то, что его подчинённые простаивают, дожидаясь своей очереди обработки задачи. Логичный, казалось бы, вывод, спустить одновременно несколько задач. Да, кто-то работает быстрее, кто-то медленнее, но каждый будет при деле, никаких простоев! Платить зарплату, за то, что сотрудник ничего не делает – нонсенс?! Чем больше задач начнём, тем больше задач, пробежавшись по цепочке, завершим. Всё верно? В конце концов, если кто-то не будет справляться, наймем в помощь новых сотрудников или уволим тех, кто больше всего тормозит процесс. Знакомая ситуация?

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

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

К обеду Пётр планировал, что команда пройдёт полпути, но оказалось, что прошли всего примерно треть. Что-то идёт не так. Ведь все молодые, держать средний темп 3 км/час, как рассчитывал Пётр, ни для кого не будет проблемой. Но почему-то расстояние от ведущего до замыкающего росло каждую минуту. Группа растянулась на несколько километров, Петр прикладывал большие усилия, чтобы нагнать убежавших вперёд. Ведь на привал планировалось прийти всем вместе, это же тимбилдинг! Очень не хотелось прийти на несколько часов позже и дать всем разбрестись вдоль озера. Поэтому порою приходилось даже бежать. Прогулка превратилось в изнурительное испытание. Во главе отряда шёл системный архитектор Дмитрий. Пётр, несколько раз звонил ему, просил пойти помедленнее, но каждый раз выяснялось, что Дмитрий итак идёт слишком медленно или же даже стоит, ждёт отстающих. Несколько раз Петр останавливал всю команду, просил всех держаться друг за другом, не отставать, но история повторялась из раза в раз.

Пётр решил сравнить поход со своим стартапом. Там также не всё было гладко, все были при деле, он тщательно следил, чтобы загрузка команды была максимальной, постоянно спускал всё новые задачи. Совсем недавно даже принял на работу несколько программистов. Но почему-то на вход поступало 20 задач, а на выход 5, максимум 10, остальные же застревали где-то внутри цепочки. Кто-то также убегал вперёд, кто-то отставал, но все ведь шли, а сроки почему-то постоянно срывались.

Пётр стал рассуждать логически. Если бы скорость у всех была одинаковой, вся команда пришла бы к цели в намеченное время. Но нельзя же привязать всех к одной верёвке и тянуть вверх. Да и верёвки у Петра не было. А если в строй вставить ещё 5 программистов? Да уж, это явно не ускорит процесс, группа растянется ещё больше. Похоже, Пётр погорячился с приёмом на работу нового персонала. Кто же тормозит команду и почему? Пётр обратил внимание, что некоторые люди в строю всё время в буквальном смысле наступают на пятки впереди идущему коллеге, а некоторые с каждым шагом отстают всё дальше и дальше. А что если отсортировать команду по скорости и поставить вперёд тех, кто идёт медленно, а назад тех, кто идёт быстро?! Сказано, сделано, слава богу, смартфоны есть у всех, каждый замерил свою среднюю скорость через GPS передатчик. После очередного привала команда перестроилась. Как не парадоксально, но скорость команды увеличилась в несколько раз! Группа перестала растягиваться и все вместе пришли к озеру даже на час раньше, чем планировалось. Стоит ли говорить, что вернувшись в офис, Пётр провёл ряд реформ, и дела в его проекте значительно улучшились. Команда стала точнее попадать в сроки и даже начла двигаться с опережением.

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

В заключение хочу спросить, а какие слабые места видите вы в своем стартапе? Какова цель вашего стартапа? Что такое эффективность компании и труда ваших сотрудников?