Статьи

Несколько месяцев назад я участвовал в дискуссии об организации работы программного проекта соответственно требованиям 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-а.
(Я) – Ну, Джерри, ты же понимаешь: когда клиент платит за озвучивание нереальных обещаний – он услышит то, за что заплатил. Что меня беспокоит, понимает ли клиент все последствия того, что он хочет услышать?
(Джерри) – Лёша, мы не первый день в этом бизнесе. Все верят, что эта авантюра как-то заработает. Либо же – если это все ляснется – голова будет болеть у кого-то другого.

А что вы думаете? Можно ли каким-либо образом оценить влияние заказчика на успех проекта?

Авторы:
Алексей Янчук
Константин Кондратюк