скоуп работ что это
Не говори красиво, говори правильно. или Глоссарий управления проектами
Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал — скоуп). «А что такое scope?» — осторожно поинтересовалась одна девушка. «О, scope — это. » — ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, — грустно сказала девушка. — Нам в институте так же объясняли».
Прибавьте к этому еще и то, что и на языке оригинала многие термины трактуются вовсе не однозначно. В сравнительном словаре Макса Вайдемана [MW], опирающемся на более полусотни источников, для многих терминов приводится по 5-6 различных определений. Русскоязычные глоссарии, которых тоже набирается немалое количество, во многих случаях запутывают ситуацию еще больше.
Теперь взглянем на эту проблему с точки зрения стандарта управления проектами. Стандарты — это документы, которые не должны допускать различных трактовок и которые должны быть понятны каждому сотруднику предприятия. Из этого следуют, по крайней мере, два вывода, существенные для темы нашей заметки. Во-первых, стандарт должен содержать определения основных используемых терминов, и, во-вторых, эти термины не следует применять ни на английском языке (хотя упоминание английского аналога, безусловно, полезно), ни в их транслитерации на русский язык.
Авторы стандарта вольны решать, каким путем они пойдут при формировании глоссария — подберут ли готовые определения на русском языке, сделают ли собственный перевод с английского или, может быть, предложат свои определения, адаптированные к профессиональной среде и квалификации персонала предприятия. Очевидно одно, в любом случае задача эта не будет простой.
Приводя в этой заметке небольшой глоссарий, мы ни в коей мере не претендуем ни на полноту, ни на анализ или критику включенных в него определений. Единственная его задача — дать объяснение терминам, которые мы использовали в наших заметках, и соотнести их с часто употребляемыми аналогами.
Оценка трудоемкости проектов разработки. Часть 1
Меня зовут Александр Катруша, я работаю Senior Engineering Manager в компании Innovecs. Большую часть своей карьеры я занимался разработкой и внедрением ERP-систем, а также оценкой и управлением соответствующих проектов. И хотя тема оценки проектов неисчерпаема, как атом, надеюсь, мой опыт пригодится многим коллегам. Особо ценны будут советы, что делать и чего не делать, как избежать типичных ошибок в оценке и ее коммуникации.
Благодарен ребятам из этой темы на DOU за мотивационный пинок для написания статьи. Она состоит из двух частей. В первой части даны общие соображения, рассмотрены цели и сложности оценки проектов разработки, структура оценки и единицы измерения, требования к оценщикам и исполнителям. Вторая часть описывает пошаговый метод составления и оформления оценки, а также попытку математического обоснования предложенного метода.
Надеюсь, материал будет полезен начинающим и опытным руководителям проектов, сотрудникам отделов продаж, а также всем, кто так или иначе связан с оценкой, продажей и выполнением проектов разработки программного обеспечения.
Терминология
Я постараюсь не злоупотреблять англицизмами, но в случае семантических различий между английскими терминами и их общепринятым русским переводом может встретиться калька с английского термина, например:
Под оценкой проекта я буду подразумевать только оценку трудоемкости работ (трудозатрат). Оценка затрат, таких как аренда офиса, железо, софт, лицензии, — тема для отдельной статьи. Также практически не буду касаться календарного планирования выполнения проекта, которое часто делается сразу после и на основе оценки трудоемкости.
Хочу также отметить, что в гибких практиках в последнее время принято говорить не об оценке, а о прогнозе (forecast), тем самым подчеркивая принципиальную неопределенность, связанную с выполнением проекта, и нацеленность больше на достижение бизнес-целей заказчика, чем на попадание в сроки и бюджет.
Под точностью оценки буду подразумевать ее возможность обеспечить качественное планирование и выполнение проекта. Поскольку за время жизни проекта его рамки, предположения и прочие параметры, как правило, сильно изменяются, то вычислить «математическую» точность оценки (то есть отношение плана к факту) практически невозможно.
Когда и зачем нужна оценка проектов
Неопределенность
Одна из базовых проблем оценки — противоречие между принципиальной неопределенностью будущих параметров проекта и необходимостью принятия решений здесь и сейчас. Мы живем в мире годовых бюджетных циклов, тендеров, ROI, time-to-market и прочих практик и концепций, которые вынуждают принимать инвестиционные решения как можно раньше в жизненном цикле проекта, то есть именно тогда, когда риски недооценки или переоценки самые большие.
При этом в процессе переговоров либо участия в тендере на исполнителя оказывается дополнительное давление с целью уменьшения оценки и принятия им на себя большего риска. Стоит всегда помнить об этом противоречии при продаже, оценке и выполнении проекта.
Когда нужна оценка
В каких же случаях может возникнуть необходимость оценить трудоемкость проекта? Несколько возможных ситуаций:
Если оценка нужна прямо сейчас
Если вы вынуждены оценивать проект в самом начале, на этапе сбора бизнес-требований или еще раньше, есть несколько путей снизить риск:
Ответ на вопрос «зачем оценивать?» может быть не столь очевиден. Помимо собственно подсчета трудозатрат и бюджета, в процессе оценки необходимо проделать немалую работу по обоснованию прогнозных чисел и снижению рисков. Я бы выделил следующие основные цели процесса оценки:
На первом месте в списке целей — определение рамок проекта. Сложно переоценить важность этого пункта. Никакая оценка не имеет смысла без четкого описания того, что и при каких условиях мы оцениваем. На мой взгляд, отсутствие четкого описания рамок проектов и предположений — одна из основных причин проблем при их выполнении.
Второй и четвертый пункты достаточно очевидны, а вот третий может быть сложен для понимания разработчиками и теми, кто не знаком с работой бюрократических структур. Для выделения бюджета, особенно в больших корпорациях, часто бывает необходимо взять неясные, абсурдные либо вовсе несуществующие требования и сделать красивую обоснованную оценку. И только для того, чтобы люди, распределяющие бюджет, ее утвердили. А в рамках этого бюджета команда смогла бы перейти к выяснению «настоящих» требований и их реализации. При этом все участники процесса могут отлично понимать абсурдность и нереальность требований и их изменчивость. Но чем детальнее и профессиональнее будет выглядеть ваша оценка, тем выше шансы получить бюджет и реализовать проект «как нужно».
Особенно это актуально для не ИТ-клиентов, продающих услуги и продукты с гораздо меньшей степенью неопределенности, чем разработка софта. Их менеджерам может быть сложно понять, почему цена на одну и ту же услугу может отличаться на порядок в зависимости от «незначительных» изменений в требованиях, фазы проекта или поставщика.
На более же высоком уровне, по утверждению Steve McConnell в его великолепной книге Software Estimation, основная цель оценки — определить, являются ли цели проекта достаточно реалистичными для достижения, то есть стоит ли вообще браться за проект.
Эксперимент
Во время семинаров по оценке проектов я несколько раз просил аудиторию в течение нескольких минут оценить полные трудозатраты на разработку достаточно простого бизнес-приложения — программы для торговца цветами с функциями учета заказов, их выполнения, оплаты и хранения базовой информации о клиентах.
В результате даже старшие разработчики и архитекторы, работавшие много лет вместе на одной платформе, на одних и тех же входных данных, находясь в одной аудитории и читающие один и тот же текст, давали оценки, отличающиеся в 20 и более раз! Требования при этом были не очень детальными, но достаточно реалистичными, как если бы они действительно были сформулированы владельцем бизнеса.
Очевидно, причина такого разброса не в технической компетенции разработчиков, в которой я не сомневался. А в том, что они оценивали разный скоуп. Кто-то думал только о разработке базовых функций, кто-то же — и о работе с требованиями, тестировании, потенциальных изменениях, интеграциях, рисках.
Именно в том, чтобы видеть весь объем работ и рисков, и состоит важная часть искусства оценки проектов. Другая важная часть — это коммуникация со всеми стейкхолдерами проекта.
Оценщики и исполнители
Идеальный оценщик
Идеальный оценщик — это разработчик с квалификацией не ниже сеньора, желательно с опытом неудачных оценок и провальных проектов, а также хорошо понимающий процессы продажи, оценки, планирования и выполнения проекта в целом. При этом он должен чувствовать себя психологически в безопасности, то есть не должен бояться быть наказанным за недооценку или переоценку конкретных задач. Иначе он может стремиться закладывать более пессимистичные оценки либо вообще отказываться их давать. Команда же будет рада использовать все выделенное время, и бюджет вашего проекта может вырасти в несколько раз больше необходимого.
Этот феномен хорошо сформулирован в законе Паркинсона: «Работа заполняет время, отпущенное на нее». Опытный разработчик всегда найдет способ, как потратить 40 часов на задачу. А значит, завышенная оценка также может влиять на фактические трудозатраты.
Кроме того, очевидно завышенная оценка отдельных задач может подорвать доверие клиента ко всей оценке и ее авторам.
Когнитивные искажения, влияющие на оценку
Даже самые опытные специалисты могут ошибаться. Одна из причин ошибок, на мой взгляд, когнитивные искажения — свойства нашего мозга, мешающие нам мыслить рационально. Больше о них можно прочитать в книге нобелевского лауреата по экономике Даниела Канемана либо в «Википедии». Здесь я опишу три искажения, непосредственно касающиеся, на мой взгляд, нашей темы.
Ошибка планирования и оптимизм
Нам хочется думать, что мы лучше других. Поэтому своим задачам, как правило, даем более оптимистичную оценку, чем похожим задачам других людей. Хороший оценщик должен адекватно оценить свои силы и быть готовым сопротивляться приемам психологического давления вроде вопросов «почему так долго?!», спокойно аргументируя свою позицию.
Также всем, даже опытным разработчикам, присущ оптимизм в оценке задач. По эмпирическим данным, разработчики в среднем дают оценки, заниженные по крайней мере на 30%. И этот оптимизм, к сожалению, находит поддержку у менеджеров и других стейкхолдеров проекта.
Ошибки в оценке вероятностей
Фактическое время выполнения задачи — случайная величина. Даже люди, прошедшие университетский курс теории вероятностей, далеко не всегда в состоянии правильно ими оперировать. См., например, парадокс Монти Холла. Особенно справедливо это для условных, очень больших и очень малых вероятностей, чем с успехом пользуются страховые компании и организаторы лотерей. Также может быть непросто оценщику отличить, например, математическое ожидание трудозатрат от наиболее вероятных трудозатрат на задачу.
Для уменьшения эффекта договаривайтесь с разработчиком о том, что вы подразумеваете под оптимистичной, реалистичной, пессимистичной и вообще оценкой выполнения задачи. Вопрос «сколько может занять эта задача?» предполагает совершенно другой ответ, чем такие вопросы, как: «Какое наиболее вероятное время выполнения этой задачи?», «Какое среднее время выполнения этой задачи?».
Эффект привязки (якорение)
Люди подсознательно стремятся к услышанным или подсказанным кем-то числам. Об этом отлично знают, например, маркетологи. В нашем контексте это может значить, что:
Исполнители
Еще одна сложность состоит в том, что оценку, как правило, делают старшие разработчики, а выполняют же большинство задач мидлы и джуны. Как показали исследования, проведенные еще на заре индустрии, продуктивность программистов разной квалификации может отличаться в несколько раз, а иногда и в десятки раз.
Рекомендацией здесь будет проводить оценку для среднего разработчика (мидла), особенно если исполнители неизвестны на момент оценки. То есть оценщик должен поставить себя на место мидла. Тогда при сбалансированной по квалификации команде оценка будет достаточно реалистичной. Но это может потребовать дополнительных усилий от оценщика и отдельной коммуникации с ним.
Если же вы точно знаете, что в вашей команда будет дисбаланс по квалификации, корректируйте оценки. По моим подсчетам на основе продуктивности разработчиков разной квалификации и времени, которое уходит на обучение и ревью младших коллег, продуктивность таких двух команд может отличаться примерно в полтора раза.
Единицы измерения
Трудоемкость vs длительность
Я предпочитаю все задачи и проекты оценивать по трудоемкости (в человеко-часах), а не по длительности (в днях или неделях) по следующим причинам:
Длительность при этом более интуитивна и удобна при стабильной команде на коротких отрезках времени.
Человеко-часы, на мой взгляд, более оптимальны, и вот почему:
Степени двойки
При надобности можно использовать и промежуточные числа: 6, 12, 40. Выше 40 ч оценка выглядит не совсем надежной, а задача плохо контролируемой. В таком случае желательно разбиение на подзадачи.
Рабочие часы vs эффективные часы
Не секрет, что разработчики, и не только они, непосредственно работают часов пять-шесть из восьмичасового рабочего дня. Остальное время уходит на отдых, кофе, перекуры, разговоры, Facebook и другие интересные занятия. Много дней подряд по 8 часов эффективно делать творческую работу практически невозможно.
Моя рекомендация — все же оценивать проект в рабочих, то есть астрономических, а не эффективных часах. И главная причина тут проста: сложно объяснить заказчику, почему он платит вам за восемь часов, а работаете вы только шесть. Даже если ваш заказчик — ИТ-компания и «тоже так делает», не стоит давать ему лишний козырь в потенциальных спорах, особенно судебных, которые могут возникнуть в течение жизни проекта. Кроме того, с рабочими часами проще планировать: не нужно вводить дополнительные коэффициенты.
Минус этого подхода проявляется на мелких задачах, при выполнении которых нет разницы между эффективными и рабочими часами. Три задачи по два или одна по шесть часов эффективного времени будут сделаны за один восьмичасовой рабочий день, об этом стоит помнить при оценке и планировании.
Структура оценки
Как мы выяснили в первой части статьи, цель оценки — не только найти трудозатраты, но и описать скоуп, риски, а также правильно преподнести их всем стейкхолдерам проекта. А потому документ «Оценка проекта» как минимум должен содержать:
Заметьте, что собственно оценка в виде чисел только на третьем месте, поскольку качественное определение скоупа и предположений намного важнее для успеха проекта, чем точность оценки. Числа неотделимы от того, что и при каких условиях они оценивают. Ошибка в оценке индивидуальной задачи может составить 5%, 10%, пусть даже 50%, и это может быть некритичным для проекта. В то время как неправильная оценка скоупа и рисков может увеличить трудоемкость работ в несколько раз.
Все недосказанности, потенциальные конфликты с заказчиком и другими стейкхолдерами намного дешевле разрешать в начале проекта, чем в его середине или конце. Для этого и необходимо четкое описание скоупа, предположения и рисков. Потому не бойтесь мягко, но настойчиво указывать на недостаток информации или ее противоречивость, ошибки заказчика, видимые риски.
Заключение
Итак, в первой части мы рассмотрели основные сложности в оценке проектов, цели процесса оценки, требования к оценщику (разработчику), структуру и единицы измерения оценки. В следующей части перейдем непосредственно к трудоемкому процессу ее составления.
Как управлять IT-проектом: сроки, бюджет и скоуп
Эту статью мы написали вместе с Полиной Скалуновой, marketing project manager в Skyeng.
Быть проджектом нелегко. Стоит необдуманно распределить несколько задач по этапам, и команда может не успеть сдать проект в срок или выйдет за рамки бюджета.
Прежде чем корректировать работу команды и принимать решения, проджекту нужно оценить объем работ, время до дедлайна и расходы. В этом поможет проектный треугольник — инструмент для управления IT-проектом.
Время на чтение: 15 минут
Что такое проектный треугольник
Представьте, вы начинающий проджект в компании по разработке программного обеспечения. Вы недавно на позиции, но уже подключились к первому проекту — работе над приложением, в котором можно составить и заказать капсульный гардероб.
Вашего наставника зовут Джим, он проджект уровня мидл. Джим оценил задачи с командой и запланировал работы по этапам, проект идет по плану и движется к завершению, команда укладывается в сроки. Неожиданно Джиму пришлось уйти в недельный отпуск по личным обстоятельствам, и он передал вам свои задачи на время отсутствия.
Пока наставник в отпуске, вы следите за бэклогом и сроками. Все идет хорошо, и тут заказчик просит добавить еще одну фичу — 3D-примерку. Он настаивает на важности этой фичи, так как у прямых конкурентов она уже есть.
Вы договорились созвониться с заказчиком завтра и обсудить вопрос подробнее. Это значит, что вам нужно срочно оценить статус текущих задач и подготовить предложения, как реализовать идею.
Первое, что вы сделали, — связались с разработчиком, чтобы собрать информацию для техзадания и выяснить, сколько этапов будет в работе над новой фичей.
Задание
Какой будет ваш следующий шаг?
Вы пишете Оливии — опытному проджекту, которая давно работает в компании.
Оливия прислала вам файл с информацией, вы открываете и приступаете к чтению.
Скоуп
Скоуп — это весь объем работ, который нужно выполнить для достижения цели проекта. В скоуп включены задачи всех специалистов: разработчиков, тестировщиков, дизайнеров.
Для приложения с подборкой капсульного гардероба UX/UI-дизайнеры отрисовывают экраны с коллекциями одежды и личным кабинетом пользователя. Разработчики должны реализовать фичи с возможностью добавить товар в корзину и оформить заказ, заполнив анкету.
Задачи разные по сложности, а их объем и количество могут меняться во время работы над проектом.
Задание
Вы задумались, в каких ситуациях скоуп может меняться во время проекта?
Поразмыслив над тем, когда меняется скоуп, вы переходите к следующей странице материалов Оливии и замечаете, что ответ на этот вопрос разобран ниже.
За скоупом важно следить, чтобы не сорвать сроки и успеть сдать проект к дедлайну. Для этого нужно проверять статус задач: сколько выполнено, сколько в процессе и нет ли у исполнителей проблем. В этом помогут специальные инструменты для планирования:
Нужно вносить в скоуп все задачи, иначе можно забыть про часть работ, которую выполнила команда. Так может случиться, когда заказчик попросит внести небольшое изменение. Если у вас заключен договор с оплатой по факту затраченных ресурсов, а вы не добавили задачу в скоуп — есть риск, что ни вы, ни заказчик не вспомните о ней к моменту выставления инвойса.
Скоуп может неоднократно меняться, и это нормально. Проджекту нужно сделать так, чтобы эти изменения не помешали вовремя закончить работу и сдать проект заказчику. Для этого он может переносить задачи на другие этапы проекта или даже сокращать скоуп.
Проджект может столкнуться с разными ситуациями, в которых скоуп придется менять. Вот три примера.
Рассмотрим эти примеры подробнее.
Заказчик пришел с новой идеей. Если заказчик решает усложнить проект и добавить новую фичу, это увеличит скоуп.
Вы понимаете, что столкнулись с этой ситуацией. Но теперь вы знаете, что нельзя просто так добавить в спринт работу над новой фичей — 3D-примеркой.
Команда не успевает выполнить задачи. Если объем работ был неверно оценен в начале и команда не успевает к дедлайну, можно сократить скоуп. Например, когда планировалось внедрить новую идею за месяц, но через две недели разработчики сообщают, что потребуется больше времени. Если заказчик согласен и идея не влияет на проект, от нее можно отказаться.
Команда забывает обсудить часть задач на старте. Все упущенные детали всплывают на этапе разработки. Если они влияют на функциональность продукта, то их придется включать в скоуп уже в процессе работы над проектом. Менять скоуп, когда ресурсы уже распределены, — непросто. Чтобы избежать этой ситуации, нужно подробно описать все задачи во время планирования.
Изучив краткий конспект о том, что такое скоуп и когда он меняется, вы понимаете, что не учли несколько моментов.
Задание
Вы готовитесь к созвону с заказчиком. Проверьте себя и выберите действия, которые нужно сделать до этого.
В нашем телеграм-канале вы найдете чек-лист, который поможет правильно вносить задачи в скоуп. Сохраняйте себе, чтобы ничего не забыть.
Теперь вы знаете, что скоуп помогает следить за выполнением задач, не нарушать сроки и распределять ресурсы. Далее переходим к следующей вершине проектного треугольника — бюджету.
Узнайте 5 принципов успешного проджект-менеджера
Пройдите бесплатный мини-симулятор и узнайте, какие принципы помогут вам добиться успеха в проджект-менеджменте
Бюджет
Бюджет включает в себя все траты, связанные с проектом: оплата работы исполнителей, закупка устройств, лицензий, управленческие, дополнительные и необязательные расходы.
Порядок оплаты прописывается в договоре с заказчиком. Договора бывают трех типов : Fixed price, Time and Material и Dedicated team.
При договорах Fixed price и Dedicated team бюджет зафиксирован на старте проекта. Проджекту нужно контролировать, чтобы расходы не вышли за его рамки.
В случае с Time and Material проджекту нужно выставлять инвойсы — счета на оплату потраченного времени и ресурсов. Поэтому он следит, сколько часов исполнители потратили на работу, оценивает результаты в сравнении с планами и готовит отчеты для заказчика.
Вы прервали чтение заметок Оливии и задумались. Команда работает над приложением по договору Fixed price. Проект близится к завершению, поэтому бюджет расписан. Скорее всего, работа над новой фичей потребует дополнительных затрат.
Вы решаете дочитать материалы, а потом написать Оливии, чтобы посоветоваться с ней по поводу бюджета. Следующий блок заметок посвящен третьей вершине проектного треугольника — срокам.
Время
В задачи проджекта входит следить за сроками проекта, оценивать их и при необходимости сокращать.
Отслеживать сроки можно двумя методами: burndown chart и методом критического пути.
Burndown chart подходит для отслеживания сроков. Это диаграмма, через которую можно увидеть, сколько стори поинтов команда выполняет в каждом спринте и как это число меняется от спринта к спринту. С помощью диаграммы можно прогнозировать срок завершения проекта.
Burndown chart следует обновлять после каждого спринта. Тогда будет видно, на каком этапе находится проект, сколько задач сделано и сколько времени нужно до релиза.
Метод критического пути подходит для отслеживания задач, по которым не должно быть задержек. Сначала определяется критический путь с последовательностью всех задач, которые нужны для реализации проекта. Если на критическом пути увеличивается срок выполнения какой-либо задачи, меняется и дата завершения проекта.
Для расчета критического пути сначала нужно создать сетевой график и определить последовательность задач. Потом решить, что нужно выполнять последовательно, а чем можно заниматься параллельно. Например, пока разработчики делают первую фичу, UI-дизайнер работает над второй. Когда разработчики приступают ко второй фиче, команда QA начинает тестировать первую.
Вы прочитали конспекты Оливии и узнали о вершинах проектного треугольника.
Через час у вас запланирован короткий мит с проектной командой, чтобы обсудить реализацию новой фичи. Но уже сейчас вы понимаете, какие вопросы нужно внести в план встречи с заказчиком.
Задание
Какие вершины проектного треугольника нужно обсудить с заказчиком?