Agile
Краткая история IT-менеджмента
В первой главе я раскрывал вызовы, которые приход цифрового мира принес менеджменту, которые обесценивают методы классического менеджмента и требуют принципиально новых подходов. Эти вызовы первыми пришли в IT-отрасль. Вернее, они были там с самого ее начала, но первые десятилетия на них пробовали ответить в рамках регулярного менеджмента. И это были сильные попытки, которые, в том числе, развили проектный подход и привели его в современное состояние, PMBOK во многом основан именно на практиках IT-проектов. Но в целом эти попытки потерпели неудачу, гарантировать успех проекта не получилось. И именно поэтому в начале нулевых появился Agile как альтернатива регулярному менеджменту, и за прошедшие годы завоевал IT-мир, став стандартом де-факто, а теперь идет в другие отрасли. Развитию Agile-менеджмента будет посвящена вторая глава, а начну я с истории культур и методов ведения IT-проектов.
Отмечу, что я, естественно, не первый, кто обращается к истории развития IT-менеджмента и показывает ее как историю развития культур. В 2008 была опубликована книга Энтони Лаудера «Культуры программных проектов». В духе времени он решил не публиковать бумажную книгу, а выложил текст в интернете. Перевод на русский был сделан Альбертом Мустафиным и выложен в блоге happy-pm по главам и целиком в pdf. А здесь рецензия Стаса Фомина, от которого я в свое время узнал про книгу.
Энтони выделяет в истории развития четыре культуры: научную, заводскую, дизайнерскую и сервисную. Для каждой из них характерен свой подход к ведению ИТ-проектов: представления об успехе, критерии качества и организации работ. Каждая культура породила своих авторитетов и свои учебники, основанные на представлениях и задачах того времени и согласованные между собой.
Мое деление культур отличается от того, что увидел Лаудер. В моей классификации тоже четыре культуры, но она доведена до нашего времени, и переход к последней около 2012 года, уже после публикации книги Энтони. Моя периодизация культур представлена на схеме.
Каждая культура изменяет не только способ реализации проекта и управление им, она также расширяет рамку проекта. Эпоха НИОКР. Это период становления IT-отрасли, программы разрабатывались в университетах и институтах так же, как ведут конструкторские работы. Они и сами были частью более масштабных проектов, обеспечивая расчеты для военной, космической, атомной и других отраслей. Дело было новое, и основная проблема добиться, чтобы программа работала, выдавала правильные результаты.
Эпоха RUP классическое управление проектами. По мере развития отрасли возрастала потребность не просто разрабатывать программы, а делать это с предсказуемыми сроками и затратами, в соответствии с планами. Это пробовали делать методами классического менеджмента, и на этом пути были многочисленные неудачи, а успех так и не был достигнут. И в принципе в 1980-х уже поняли причину: ключевым фактором успеха IT-проектов являются не процессы, а человеческий фактор. Но плохие новости редко принимают и в 1990-е годы был предпринят значительный рывок в этом направлении были собраны реальные гуру IT и создан Rational Unify Process (RUP), из которого позднее в значительной мере вырос современное проектное управление с его руководством PMBOK (Project Management Body of Knowledge). Но успеха достигнуто не было, предсказуемого результата получить не удалось, несмотря на многократно возросшую стоимость тяжелой процедуры.
И как альтернатива тяжелым методам RUP на рубеже 21 века появились легкие Agile подходы, наступило время Agile и Scrum первого из Agile-методов. который и принес ему успех. Формально зарождение Agile 2001, год подписания Agile-манифеста http://agilemanifesto.org/ (на русском). Идеи очень простые: раз человеческий фактор главное, то построим процесс на сотрудничестве людей, а не на регламентах. А раз результат все равно гарантировать нельзя будем наблюдать за продвижением к нему.
В это же время произошло принципиальное изменение в IT: появились персональные компьютеры. И дело не в том, что они появились дома компьютеры появились в небольших компаниях и сразу возникла потребность в разработке множества программ, учитывающих особенности конкретных компаний. Гибкие виндовские системы, типа современного 1С появились много позже. И возникла большая потребность в разработчиках. Отметим, что на постсоветском пространстве эта потребность была закрыта за счет развала оборонки, когда множество инженеров ушло в IT, а на западе этого не было. Так вот, оказалось, что Scrum позволяет за счет командной работы достигать результата даже при недостатке компетенций, или хотя бы наблюдать за траекторией движения.