Если только кто сталкивался с управлением проектом, то первое на что они натыкались это знаменитый треугольник — сроков, объема и бюджету. А следующее усложнение, это вписанный круг в этот треугольник который означает качество.
Что значит этот треугольник? Тут есть два ответа:
Его можно представить, как цель для руководителя проекта, а именно сделать нужное качество с установленным бюджетом и сроком. Так сказать выполнить проекцию треугольника во-времени, и чтобы был он не подобным, а точным.
Также указывается взаимосвязь, что если у нас объем «поплыл» и начал увеличивается, то за этим самым начнет увеличиваться и например, сроки при сохранении бюджета, или бюджет при сохранении срока. И при этом что-то будет происходить с качеством — и если ассоциация с качеством, как вписанным кругом прямая, то получается, при увеличении площади треугольника, оно будет увеличиваться? И если при увеличении сроков или бюджета, такое можно представить, то можно ли представить такое при увеличение объема? Если линейную связь между сроком и бюджетом с качеством представить легко, то с объемом сложнее.
Уверен, что качество это отдельная категория, особенно в проектах ИТ, которая такая же самостоятельная и выступает и причиной и следствием с другими параметрами проект.
Получается, не треугольник, а квадрат?
И тут стоит вспомнить, что слово, которое рука об руку вспоминается с словом проект, а именно риски. Сделать быстро — рискованно, делать долго — менее рискованно. Сделать с большИм бюджетом один и тот-же объем работ, также менее рискованно. Риски можно увеличивать, можно уменьшать. Более того, из житейского опыта, ясно, что чаще всего именно риски являются следствием соотношения выше рассмотренных параметров. Получается, еще один параметр? И проектный треугольник уже даже не квадрат.
Тут еще хочется, вспомнить о том, что каждый объем несет за собой ценность. Проект мы делаем ради какой-то ценности и ведь она тоже может изменяться? И тоже вступает во взаимоотношение прежде всего с объемом и сроками….
Ключевых параметров 6 — сроки, бюджет, объем, качество, риски и ценность. И лучше рисовать не треугольник, а тетраэдр у ко которого - 6 граней!
Ниже разберу почему с различных аспектов и начну с академического, чтобы было понятно что все что выше сказано, не придумано мной «вчера».
И рассмотрим это в первую очередь для того, чтобы ваше проекта лучше попадали в срок и в бюджет.
Аспект академический
Для понимания природы параметров проекта дадим его определение. Проект — это временное предприятие (целенаправленное действие), осуществляемое для создания уникального продукта, услуги или достижения уникального результата. Проект может быть как одиночным, так и частью программы проектов или портфеля.
Тут важно подчеркнуть и временность, и направленность на создание уникального результата.
Из временности проекта получаем, что каждый проект имеет срок. Так как для достижения целей проекта необходимо выполнить какой-то объем работ и получить результат, мы понимаем, что у каждого проекта есть объем. А так как на выполнение объема работ надо потратить ресурс, у проекта есть бюджет.
Из определения проекта мы получили всем известные параметры проекта:
Объем – что будет сделано
Бюджет – сколько будет стоить
Срок – когда планируется сделать этот объем
Но это не все параметры проекта. У него есть и малоизвестные. Спросите о них двух ближайших руководителей проекта — и один из них точно не ответит.
Из определения уникальности выходит, что у каждого проекта есть риски. Нельзя что-то делать первый раз и делать это наверняка. Каждый результат (продукт, сервис) может быть оказан с разным качеством — отсюда выходит, что у проекта есть качественная составляющая. И конечно же, результат должен быть кому-то нужен — отсюда выходит ценностная составляющая проекта.
А именно, плюс еще три параметра проекта:
Риски — определяют вероятность выполнения проекта
Качество — соответствие ожиданиям
Ценность — ответ на вопрос: а зачем всё это будет (или уже было)?
Перечислим еще раз все параметры проекта, которыми каждый проект обладает, даже если какие-то из них строго не определены: срок, объем, бюджет, качество, риски и ценность.
Секрет в достижении проекта в бюджет и в срок, которым часто пользуются: не определяют и не формулируют ни качество, ни риски, ни ценность. И как только возникают проблемы с бюджетом или со сроками, формально придерживаясь объема, начинают ухудшать качество.
Качество — первая жертва нехватки бюджета или времени.
Вторая жертва — ценность. «Давайте сделаем это и назовем успехом», «нам не то чтобы стояло хорошо, нам главное, чтобы висело прилично» и тому подобные знаменитые поговорки, говорящие, что в погоне за сроком и бюджетом жертвой становится ценность.
Завышение рисков проекта — тоже обычное дело. Когда при инициации проекта особо ретивый подрядчик хочет выиграть за счет срока или за счет бюджета, он задирает риски, надеясь выиграть более удачным предложением, с пониманием, что уже находясь в проекте, он сможет объяснить, что риски — не его, а заказчика или смежника, и надо доплатить.
Профилактика. Профилактика того, чтобы не поймать себя в ловушку, когда в погоне за сроком или соблюдением бюджета в жертву будут отданы качество, ценность и завышены риски, проста: их надо формализовать.
Качественные параметры, ценность и риски проекта должны быть формализованы и согласованы.
На практике сделать это сложно, долго и очень не хочется (в силу сложности). Срезать угол здесь можно так:
Качественные параметры — можно определить матрицей согласования с главными пользователями результата.
Ценность — договоренностью по главным ожиданиям со спонсорами проекта.
Риски — тут надо потребовать от исполнителя стандартную матрицу рисков с подобного проекта и аккуратно ее адаптировать.
Аспект культурный
Большинство компаний свыклось и успешно работают с понятием сроков, бюджетов, объема и даже качества (часто менеджеры не выпячивают параметры качества, держа их как главный резерв, чтобы достичь объема и срока). Но культуры работы как с ценностью, так и с рисками встречаются крайне редко.
«Зачем нам нужен этот проект?», «Какую ценность он нам принесет?», «Ну на хрена это всё?». Те вопросы, которые не принято задавать и на которые ответ — притупленный взгляд начальника.
Возможность ставить такой вопрос и получать на него ясный ответ возможна только в культуре компании, где вообще принято задавать вопрос: «А какую ценность нам несет… например, должность Ивана Иваныча?». Если каждый (почти) сотрудник ясно понимает, какую ценность несет его деятельность, деятельность его подразделения и так далее. Если в культуре компании такой вопрос не стыдно задать никому по отношению к чему угодно, то определение, отслеживание и сохранение ценности проекта в такой компании возможно. И наоборот, очень тяжело сохранить ценность проекта, если вопрос «А зачем вот это…», особенно начальнику, запрещен. Например, как руководитель проекта, я вел множество статусов проектов по заданному формату (по названию вроде понятно, зачем обязательная встреча), но по форме и содержанию они могли быть организованы так, что очень хотелось спросить: «А зачем вот это всё?». Но в силу культуры компании такой вопрос был равносилен тому, чтобы назвать начальника идиотом.
Итак, если хотите, чтобы в погоне за сроком и бюджетом ценность проекта не стала жертвой, ее должны знать все участники. А чтобы они могли это знать, в культуре компании вопрос «А зачем?» и ясный ответ на него должны быть нормой.
Жизненный аспект
На одном из моих проектам объем разработок был для старта оценен примерно в 3000 человеко-дней и готовы они должны быть через полгода. Как часто бывает в проекте в обычной компании, главные параметры — это срок (на первом месте) и бюджет, то есть не в срок сделать нельзя, а бюджет не должен быть привешен. Посмотрели на команду, на сроки и поняли: выполняя по 500 человеко-дней в месяц, уложимся в полгода (гениально (!)). По простой арифметике для этого нужна команда из 25 человек (уникальность арифметики). А 22, и планировалось подключить еще троих. «Ничего, ускоримся!» — подумали все (ускориться — недокументированный стандартный инструмент повышения производительности, теоретическая основа которого опирается на предложения о безграничных возможностях человека). Но кто видел, чтобы команда с самого старта выходила на плановую производительность? Кто видел, чтобы команда с ходу попадала в индикативные оценки, полученные без детальной спецификации?
Первой жертвой пали риски. Если хотите попадать в срок при недостаточных в моменте ресурсах, неизбежно надо увеличивать риски. Но и план смягчения тоже был. Ресурсов недостаточно, сроки не сдвигаемы, так что самое простое — их увеличить. И тут главное помнить: чем быстрее подключаются новые люди в пожар, тем менее подходящие они оказываются. Понятный вторичный риск и понятный на него ответ — надо набирать больше, чем нужно.
«Как можно успеть протестировать, как это работает "все вместе"?». Решили: «Половину протестируем в комплексе, а вторая пусть заработает потом». Второй жертвой стало качество. Стало понятно, чтобы успеть в срок после запуска будет много «проблем», а точнее инцидентов, которые являются их следствием.
Когда начали тестировать первые модули, стало ясно, что многого не хватает из тех «удобств», которые должны приносить ценность для пользователей, то что делает работу с системой, назовем словом «приятной». Но на любые улучшения «встали грудью» — было ясно, что любое увеличение объема сделает запуск в срок невозможным. И получается третьей жертвой пала ценность.
Как это могло быть в СССР — Сталинская школа
«К октябрьским надо успеть». Когда цели ясны и задачи определены, возникает вопрос сроков, который в сталинской школе определялся строго.
Но перед сроком что было на первом месте? Сталинский подход начинался с ценности. Преимущество диктатуры в том, что есть человек, который однозначно может определить ценность и на основании этого определить приоритет, чуть позже его назовут владельцем продукта. Это значительно снижает риски выполнения неценного результата, распыления ресурсов и ограничения его траты на не нужное.
Возвращаясь к примеру выше о сделанных 3000 человеко-днях разработок: в чем состояла корневая причина того, что ради сохранения срока в жертву были принесены качество и ценность? В том, что объем работ с ресурсами не был сбалансирован.
В сталинском подходе заказчик однозначно определяет ценность и срок, а далее именно эти два параметра делегируются руководителю для расчета всех остальных параметров, чтобы обеспечить два главных. И руководитель проекта возвращается с потребностью в ресурсах, которые выделяют, так как прежде всего хотят обеспечить ценность и срок. Итог - получаются сбалансированными все шесть ключевых параметров проекта.
Подход эффективен в части результативности, а главное — обеспечения получения нужной ценности. Минусы, в том, что в нем явно заложен высокий потенциал неэффективности. Так как очевидно, что руководитель будет перезакладываться — и с формальной точки зрения (например, для обеспечения мероприятий по разрешению рисков), и для обеспечения сроков, понимая, что ему вряд ли откажут, так как ценность определена как приоритетная. Но что лучше: получать необходимую ценность вовремя и пусть чуть дороже, чем она могла бы быть, или на протяжении всего жизненного цикла проекта докидывать ресурсы и слушать о переносе сроков, а в итоге получить худшее качество, да еще и с учетом «докидывания ресурсов» с той же эффективностью?
Личный аспект
Какую жизнь хочет прожить человек: долгую, но некачественную и без ценностей, или качественную, ценную и, возможно, полную рисков? Тут большинство ответят, что второе. В личной жизни аспект качества выше срока. И если в традиционных подходах качество падает жертвой вслед за рисками и перед ценностью, то в личной жизни вряд ли кто готов жертвовать и качеством, и ценностью. Более того, в жизни ценность часто — это то, ради чего человек и соглашается участвовать в этом проекте под названием «жизнь». То есть самое главное.
Но почему же тогда в профессиональной жизни так легко предаются и качество, и ценность? Первое и главное: очень редко ценность и качество как‑то лично касаются участников проекта (тут можно сослаться на «сталинский» подход — когда диктатор заставляет и ценность, и качество принять руководителю проекта «как свои»). Второе: срок и бюджет — это главное, что контролируется. А главное — очень часто единственное. Сделать в срок и бюджет — понятная победа для всех, перешел на следующий уровень. То, что возникнут проблемы за пределами сроков, — это уже второе.
В условиях, когда ресурс всегда дефицитный (его не выделили по записке от руководителя проекта с подписью «обеспечить» от уважаемого товарища) и его выдали, чтобы бизнес‑кейс был с максимальной маржинальностью, руководителю проекта (и мне, например, в частности) очень легко поддаться на соблазн занизить качество. Начать с того, где последствия минимальны и отдалены, и далее двигаться к большему и ближнему, пока срок не станет реалистичным.
Так что вывод прост: если среда не оценивает и не планирует все шесть параметров проекта, то удовлетворительными будут только срок и бюджет, а качество и ценность — минимальными.
Как‑то при смене всей ИТ‑инфраструктуры в одной компании директор сказал: «Сделай, пожалуйста, чтобы стало не хуже. А хуже, чем сейчас, некуда». Это профессионализма в понимании: когда срок и бюджет — главное, то качество и ценность получаются минимально допустимыми сами собой. Или другими словами «В проекте любая возможность не сделать, скорее всего, будет использована».
