Статью "Why Big Software Projects Fail: The 12 Key Questions" от автора процессов PSP/TSP Уоттса Хамфри нашел пару недель назад (в процессе подготовки вот этих заметок: #1, #2). До сих пор она валялась у меня в закладках и я перечитал ее уже несколько раз.
Мне представляется, что при верно сформулированной проблеме, эта статья пытается подвести читателя к неправильному решению. Но решению, которое позволит "продать" читателю процессы PSP/TSP ;)
Проблема эта известна всем, кому приходилось нести ответственность за выполнение более-менее серьезного программного проекта. В статье она обозначена как Management Visibility (т.е. возможность для менеджмента точно увидеть на какой стадии находится проект, с какой скоростью он движется, какие у него перспективы). Чем выше находится менеджмент, чем меньше у него возможности для прямого общения с разработчиками или хотя бы тим-лидерами и начальниками подразделений, тем слабее они "держат руку на пульсе", тем больше желание внедрить какие-то механизмы обеспечения прозрачности. Причем, чем меньше руководство имело отношение к разработке ПО, тем более дурацкие меры они готовы навязывать. Как, например, еженедельные (или даже ежедневные) отчеты для каждого сотрудника. Причем отчеты, не привязанные к выполняемым компанией проектам и планам этих проектов.
В указанной статье эта проблема обозначена правильно. Как правильно обозначено одно из важных препятствий к обеспечению management visibility: бесполезно опрашивать разработчиков о текущем состоянии их работы для того, чтобы составить общую картину. С одной стороны, разработчики сами могут точно не знать где именно они находятся и сколько времени осталось для достижения их ближайшей цели. С другой стороны, оценки -- это, зачастую, выдача желаемого за действительное. По ряду причин никто не хочет выглядеть плохо, поэтому оценки и прогнозы вольно или невольно будут оптимистичными, нежели реалистичными.
Хамфри видит выход из этой ситуации в том, чтобы при управлении проектами использовались как можно более детализированные планы. Детализированные вплоть до индивидуальных планов для каждого разработчика. Т.е. каждый разработчик должен быть обучен тому, чтобы разрабатывать для себя индивидуальный план своей работы, отслеживать продвижение по плану, корректировать оценки и т.д. Агрегация состояния таких индивидуальных планов, по мнению Хамфри, должна дать адекватное представление о текущем состоянии проекта.
И вот здесь у меня складывается смутное ощущение, что что-то не так.
Во-первых, планирование -- это все-таки не есть работа программиста, тестировщика или внедренца. Кроме того, в реальной жизни эти планы неизбежно станут увязаны с какой-то системой оценки эффективности работы сотрудника (возможно, как часть KPI). Соответственно, эти планы будут составляться и актуализироваться так, чтобы защитить доход сотрудника, а вовсе не для того, чтобы повысить прозрачность процесса разработки программного продукта.
Во-вторых, планирование хорошо работает лишь если после завершения планирования сотрудник оказывается в условиях стабильности: никто не сдвигает сроки, никто не требует внедрения новой функциональности, никто не меняет приоритетов работ, никто не пересаживает разработчика с одного проекта на другой для того, чтобы за пару дней заткнуть внезапно обнаружившуюся там дыру. Но, поскольку таких идеальных условий лично я практически никогда не видел, то планирование будет представлять из себя постоянное перепланирование. Причем, если индивидуальные планы разработчиков будут на каком-то уровне агрегироваться и согласовываться между собой, то эти операции не будут быстрыми, дешевыми и безболезненными.
В-третьих, и это самое важное на моей взгляд: характер разработки ПО таков, что в произвольной точке времени T нельзя сказать, где именно находится проект. Именно так. Нельзя при внезапном вопросе председателя совета директоров "Как обстоят дела с продуктом X" заглянуть в какой-то волшебный программный пакет (будь то MS Project или GreenHopper) и ответить: "Проект выполнен на 77.98%, с вероятностью 84.5% он будет готов к дате Ч".
Если предположить, что я прав, и что в произвольный момент времени нельзя точно оценить состояние программного проекта, то тогда станет понятно, что изобретатели процессов, вроде Уоттса Хамфри, пытаются решать не ту проблему. Не нужно оценивать состояние, нужно оценивать результаты.
Если обратить внимание на начало статьи Хамфри, то на первой же странице он рассказывает о том, как им удалось поместить разработку сложного проекта под контроль. Рецепт в итерационности. Проект был разбит на серию итераций. По результатам каждой итерации цели и сроки следующих итераций могли быть скорректированными.
По моему опыту -- это единственный работающий метод. И, как не сложно заметить, сейчас есть большой интерес к гибким методологиям (в частности к SCRUM и Kanban), где во главу угла ставится именно итерационность: короткие отрезки работы, на которых есть четкие цели, достижение или не достижение которых легко оценить по результатам итерации.
Соответственно, проблему management visibility нужно решать так, чтобы программный проект был разбит на должное количество итераций (этапов, фаз) и по результатам каждой итерации можно было делать выводы о том, какая часть проекта реализована. Как следствие, оценить состояние проекта можно не в произвольный момент времени Т, а только на границе итераций. Да, вероятно, это не то, что хотят видеть менеджеры на самом высоком уровне. И, вероятно, именно поэтому нормальные процессы разработки пока еще не дошли до широкого использования, а проникают потихонечку, под разными названиями, далеко не всегда гладко и успешно. Но, на моей взгляд, в модных сейчас гибких методологиях намного больше рациональных моментов, чем в передвижении меток времени в MS Project-е.
Не совсем очевидное следствие из итерационной разработки программного продукта -- это увеличение сроков и объемов работ. Происходит это из-за эволюционного характера разработки, когда более новая, более функциональная работающая версия продукта является следствием развития старой, менее функциональной, более простой, но обязательно работающей версии. Рост сроков и объемов работ происходит именно из-за того, что на каждой стадии должен быть получен работающий вариант ПО.
Для иллюстрации этой мысли можно попробовать представить себе разработку какого-то программного продукта. Например, текстового процессора/редактора. Законченный продукт должен поддерживать: собственный формат документа, несколько сторонних открытых форматов (часть на импорт, часть на экспорт), проверку орфографии, вставку в текст документа сторонних объектов (например, изображений), иметь настраиваемый интерфейс пользователя.
Если разработка такого текстового редактора будет построена на итерациях, в результате которых появляется ограниченная по функциональности версия, но зато полностью работающая, то могут быть выделены следующие итерации (приоритизация взята с потолка):
- самый простой вариант с поддержкой только собственного формата данных, без кастомизации интерфейса, проверки орфографии, вставки изображений. На выходе версия 0.1;
- добавление в версию 0.1 кастомизации интерфейса. На выходе версия 0.2;
- добавление в версию 0.2 функциональности по экспорту документа в несколько других открытых форматов. На выходе версия 0.3;
- добавление в версию 0.3 функциональности по проверке орфографии по запросу пользователя. На выходе версия 0.4;
- добавление в версию 0.4 функциональности по внедрению в документ сторонних объектов. На выходе версия 0.5;
- добавление в версию 0.5 функциональности по импорту документа из нескольких открытых форматов. На выходе версия 0.6;
- добавление в версию 0.6 функциональности по он-лайн проверке орфографии...
Фокус здесь в том, что при переходе от версии к версии может потребоваться серьезная переделка того, что уже было сделано в предыдущей версии. Например, в версии 0.2 кастомизированный интерфейс может потребовать очень сильно изменить ту часть редактора, которая осуществляет взаимодействие с пользователем. А в версии 0.3 может потребоваться полностью переписать подсистемы чтения/записи документов. А потом еще раз переписать их в версии 0.5.
Такое переписывание -- это трата времени и, соответственно, денег. Если процесс разработки выстроить так, чтобы при проектировании UI редактора сразу учитывались требования кастомизации интерфейса, внедрения в текст графических объектов, он-лайн проверки орфографии... А при проектировании и разработке подсистемы чтения/записи документов сразу бы учитывались все поддерживаемые форматы... Т.е., теоритически, времени и ресурсов потребовалось бы меньше. Но зато риски были бы выше. Т.к. разработчики бы стояли перед задачей гораздо большего масштаба, разбить которую на части, воплотить все эти части в коде, сшить их затем в единое целое, протестировать и задокументировать было бы намного сложнее. И предсказуемость такой разработки была бы, на мой взгляд, намного хуже. Прозрачности бы не было практически никакой :)
Полагаю, именно потому, что способ, который действительно может дать результат (итерации с эволюционным развитием системы от простого к сложному), является долгим и дорогим, он и не популярен у менеджмента. Тут как с похудением: с очень большой вероятностью можно похудеть, если прикладывать к этому серьезные усилия (ограничения в еде, смена стиля жизни, физические упражнения и пр.) и потратить значительное время. Но ведь хочется всего и сразу, чего-нибудь такого съесть, чтобы похудеть :) Так и здесь: давайте внедрим в департаменте разработки какой-нибудь чудо-процесс и инструментарий для него, чтобы можно было в MS Project-е нажать волшебную кнопку "The Current State" и получить красивую картинку с диаграммами и заключением "Степень готовности 77.98%, вероятность поставки продукта в срок -- 84.5%".
Комментариев нет:
Отправить комментарий