Методы Макдонольдса не работают, что делать?
Введение
Жизнь сложилась так, что я уже почти сорок лет разрабатываю ПО. Как и многие, тоже мечтал о софтверном конвейере, фабрике и индустриальной разработке и даже участвовал в попытках их воплощения в жизнь. Реальность эти мечты убила и заставила признать, что программирование отличается от индустриального производства и в нем методы управления Макдонольдса не работают.
Почему методы Макдонольдса не работают?
Прежние методы управления происходят из нашего индустриального и аграрного прошлого, где один день был очень похож на другой. Эффективность зависела от согласованной работы масс. Работа не требовала большой изобретательности. «Тотальный контроль», «нормирование», «пряник и кнут», «человеческий ресурс — «винтик», который легко заменить», — вот главные принципы эффективного менеджмента предыдущих эпох. Чем больше взмахов веслами в единицу времени, тем быстрее идет галера, тем эффективнее работают гребцы! В программировании мало повторяющихся задач, нет места для репродуктивной деятельности. После третьего повторения однотипного действия программист пишет утилиту, которая это действие автоматизирует раз и навсегда. Или находит Code monkey (иногда это рентабельней).
Никто не знает, каким местом программист думает и как он этим местом это делает. Интеллектуальное творчество нельзя нормировать и контролировать. Бессмысленно сажать за спиной программиста нормировщика-контролера с секундомером. Что он увидит и измерит? Все, кто пытается примерить методы управления фаст-фудом к разработке ПО, обречены на неудачу.
Культ карго
Вследствие того, что индустриальные методы управления оказались не эффективными, разработка ПО стала кузницей инновационных подходов к управлению производством. Waterfall, PRINCE2, CMMI, Oracle CDM, RUP, MSF, SEI PSP/TSP, Agile-семейство (XP, Crystal, Scrum, ASD, FDD и проч.) — это лишь небольшой перечень из того, что было изобретено и опробовано в нашей отрасли и обогатило практику проектного управления. Если в 4-ом издании PMI PMBOK об agile- подходах не было ни слова, то в 5-ой версии — 10 упоминаний.
Вера в то, что существует единственный правильный процесс, заставило отрасль пережить «методологическое безумие». Безграничную веру руководства в методологию с большой буквы «М» — всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Все процессы должны быть регламентированы. Все должно делаться по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Тотальный контроль соблюдения регламентов. Внедрение всеобъемлющих KPI. Большая доля «сизифова труда».
Не работает.
Статистика показывает, что успех или провал проектов не коррелируют с методологиями, которые в них использовались. Одинаково успешно проваливаются проекты, которые управляются по методологии «как получится», RUP, agile или CMMI 5-го уровня.
Все определяют люди.
Что делать?
То, что не существует единственного правильного процесса разработки ПО, означает, что в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с Законом 4-х П: продукт + проект + персонал = процесс.
Рисунок Cartmendum
Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.
Более того, команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна гибко подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.
Заключение Современное предприятие обязано относится к своим работникам так же, как к своим лучшим клиентам. Главный капитал современной компании — это знания. Большая часть этих знаний неотъемлема от их носителя — человека. Те предприятия, которые этого не поняли этого, не выживут потому, что не смогут быть эффективными.Сегодня эффективное предприятие — это сервис. Предприятие, с одной стороны, предоставляет услуги и продукты своим клиентам, а с другой, — рабочие места для наемного персонала.
Принципы «Одно предприятие на всю жизнь», «Работай продуктивно, а предприятие о тебе позаботится» — быстро уходят в прошлое. Посмотрите на рынок рабочей силы в ИТ — правила устанавливают профессионалы. Мало кого интересует, в каких компаниях вы работали, зато всех интересует, в каких проектах вы участвовали и ваш вклад в их успех.
Цель предприятия, которое стремиться к эффективности, сделать счастливыми не только своих клиентов, но и своих работников. У проекта разработки ПО сегодня не три, а четыре фактора успеха:
1. Выполнен в соответствие со спецификациями.2. Выполнен в срок.3. Выполнен в пределах бюджета.4. Каждый участник команды уходил с работы в 18:00 с чувством успеха.
Этот четвертый фактор успеха должен стать воспроизводимым, если предприятие хочет быть эффективным. Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма.
Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников.
