Об эффективности проектов, сделанных под конкретного заказчика
Авторы: Алексей Янчук, Константин Кондратюк.
Несколько месяцев назад я участвовал в дискуссии об организации работы программного проекта соответственно требованиям PRINCE2 и SCRUM одновременно.
Главным камнем преткновения являлось следующее: на фазе инициализации согласно PRINCE2 необходимо определить финальный продукт проекта и рассчитать бюджет, что почти автоматически пересчитывается в количество командо-часов работы. По сравнению с PRINCE2, SCRUM ставит этот процесс с ног на голову: продукт «выкристаллизовывается» от спринта к спринту. Для некоторых кураторов проекта со стороны заказчика это почти равносильно культурному шоку.
Общепризнанно, что точно оценить программный проект сложно, а еще сложнее «уложить» в оценку конечный продукт. Но является ли такое положение дел причиной, следствием, или просто элементом в более сложной картине? Слушая рассуждения коллег по дискуссии, меня в который раз поразила однобокость подхода к организации разработки программных проектов. Наш диалог с коллегами из проект-офиса это наглядно раскрывает. (Я) – Слушай, Джерри, вот мы рассуждаем о том, как оценить эффективность разработчиков, как ее отслеживать, как увязать это с PRINCE2 отчетностью.
Давай представим, что я сейчас достану из кармана волшебный гаджет, который рассчитает с точностью до секунды срок окончания проекта. (Джерри) – Было бы очень кстати! А ну показывай! (Я) – Так вот, этот гаджет показывает, что проект в том виде, в котором он определен сейчас, будет закончен 14 Октября 2010 года в 11 часов 43 минуты и 12 секунд. (Джерри) – Это абсурдная дата! (Я) – Почему же? Мой гаджет показывает, что сейчас сформулировано только 10% от всех требований к проекту. (Джерри) – В октябре 2010 всем уже будет наплевать на этот проект! (Я) – Почему? (Джерри) – Да потому, что деньги на проект выделят только в том случае, если вся разработка закончится в этом году! (Я) – Да не вопрос!
Разработка заканчивается в этом году, пропишем стабилизацию в 6ть месяцев, потом еще что-нибудь, что PRINCE2 и корпоративная методика говорит. (Джерри) – В менеджменте тоже не дураки сидят, они этот ход расколет запросто. (Я) – Ну раз в менеджменте не дураки, значит они должны понимать, то делают. Раз простят не оценить, а сказать удобную цифру. (Джерри) – Ты не первый, кто до этого додумался. (Я) – Тогда поставим вопрос так: зачем мы вообще рассуждаем об эффективности работы команды, если на оценку проекта это никак не влияет? Ставь нужную дату в план – а там оформим изменения рамок проекта. И под это дело будем сдвигать сроки. ИТ-консультанты по всему миру сталкиваются с этой проблемой ежедневно: люди, которые имеют весьма далекое понятие о работе программиста, пытаются успокоить себя, что их не будут ругать (лишать премии, отказывать в очередном повышении по службе, и т.п.) за то, что они потратили деньги на неэффективную работу дорогостоящих программистов.
И при этом не думают задать себе самый главный вопрос: что же такое эффективность программного проекта? Давайте послушаем продолжение этой дискуссии. (Кевин) – Но ведь в индустрии такие оценки существуют! (Я) – Кевин, да они существуют. Возьмем такую простую метрику как количество строчек когда в день. Что она нам показывает? (Кевин) – Ну, прогресс за день показывает, да… (Я) – Кевин, ты себя обманываешь. Эта метрика будет имеет смысл только если ты можешь сказать, что проект будет закончен, как только программисты напишут Х строчек кода. Мое мнение – отдельно взятая, эта метрика реально не показывает ничего. Потому что чем больше когда – тем больше потенциальных багов. С учетом того, что мы хотим внедрить обязательный уровень покрытия юнит тестами – чем больше кода, тем больше тестов, и тем больше времени уходит на разработку! Кода должно быть меньше, а не больше… (Кевин) – Может быть пример был не самым удачным… (Я) – Ок, принято. Ты согласишся с тем, что попадание в оценку говорит о эффективной организации? (Кевин) – Да, вполне… (Я) – Тогда забыли про бюджеты в нашей ситуации. Теперь давай представим: я беру бриф проекта, иду к себе на этаж, и 14 Октября следующего года мы выкатываем релиз. Вопрос: был ли процесс эффективным? (Кевин) – Нет! (Я) – Почему? (Кевин) – В нем будут баги, будут проблемы с производительностью, будут проблемы с эргономикой, да мало ли чего! (Я) – Кевин, ты можешь допустить такое, что первый релиз может работать как надо? (Кевин) – Да если он и будет работать, он все равно будет никому не нужен потому, что к этому времени 10ть раз поменяются требования, поменяются законы, менеджмент заключит каких-нибудь контрактов, ребята из отдела ИТ-операций разродятся очередным гениальным стандартом – и можешь свой эффективный релиз выкинуть! (Я) – Кевин, т.е. в принципе ты согласишься с тем, что эффективность работы разработчиков, строго говоря, не определяет успех проекта? (Кевин) – Нет, не соглашусь, эффективность – залог успеха проекта! Один мой знакомый, работающий консультантом в крупном европейском провайдере мобильной связи, как-то озвучил, что они делают: “Development without knowledge, operation without a clue”.
Все хотят быть эффективными, и при этом не так много тех, кто понимает, что же такое быть эффективным. А ведь эффективность вполне конкретное понятие: соотношение полезного выхода к затратам. С затратами все более или менее ясно – это время и деньги. Сложнее с полезным выходом: как часто заказчик четко знает, что именно надо производить?
В проектах, которые делаются под заказ, не последним будет такой фактор, как восприятие проекта. Реплики раздраженных жизнью пользователей «миллионы потрачены, и никаких улучшений», распространяются со скоростью пожара. Ведь часто в представители пользователей выбирают либо самый молодых, либо самых ненужных, либо тех, кто уже и так мешает работать. У тех, кто распоряжается деньгами как правило есть свои приоритеты, которые часто не стыкуются с тем, что говорят представители пользователей.
Говоря о разработке программного обеспечения, много внимания уделяется оценке работы разработчиков. При этом как-то незаслуженно обходят стороной вопросы эффективности принимающей стороны: раз клиент платит, то он может менять требования тогда, когда хочет – и это обязательно должно способствовать увеличению всеобщей эффективности. (Джерри) – Как-то неуютно я чувствую себя после ревью твоего PID-а. (Я) – Ну, Джерри, ты же понимаешь: когда клиент платит за озвучивание нереальных обещаний — он услышит то, за что заплатил. Что меня беспокоит, понимает ли клиент все последствия того, что он хочет услышать? (Джерри) – Лёша, мы не первый день в этом бизнесе. Все верят, что эта авантюра как-то заработает. Либо же — если это все ляснется — голова будет болеть у кого-то другого. А что вы думаете? Можно ли каким-либо образом оценить влияние заказчика на успех проекта?