Оценка трудоемкости проектов разработки. Часть 1

«Привет! Добро пожаловать! Спасибо, что приняла наш оффер. Пойдем знакомиться с твоей командой. У них как раз сейчас дейли. Ты вышла под конец спринта, поэтому пока работы для тебя…

Язык айтишников

Каждый, кто работает в IT, непременно сталкивался с профессиональным жаргоном и компьютерным сленгом. Его можно любить или ненавидеть, принимать или терпеть, но непреложным остается факт — IT-жаргон существует и от него никуда не деться.

Когда приходишь в новую компанию, на тебя наваливается куча незнакомых слов. Кажется, их так много, что потребуется немало времени, чтобы понять и выучить их все. Многие слова ты уже знаешь, о смысле других догадываешься, часть из них является англицизмами, поэтому догадаться об их значении несложно Первая реакция — неприятие: «Зачем использовать английские слова в русский речи, когда есть достаточно русских альтернатив?» Потом ты пытаешься сохранить чистоту языка. В итоге, начинаешь говорить так же, как и все. Это неизбежно.

Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение IT-специалистов и наладить их взаимопонимание. Обычно слова получаются короткими и емкими. Иногда одно слово заключает в себе целую фразу. Поэтому польза в них, на мой взгляд, есть.

Я послушала, как говорят разработчики в Wrike, и составила словарик из самых распространенных слов. Слова собраны по тематическим группам.

4f3kprom3kqtlqvdeowfmqsiyt0.png

График проекта

Управление временем – это важный комплекс мер для обеспечения своевременного завершения проекта. Первым шагом в управлении временем является составление плана управления расписанием, который документирует, как вы собираетесь разрабатывать, управлять, выполнять и контролировать расписание проекта. В зависимости от потребностей вашего проекта, этот план может быть формальным и подробным, неформальным и многоуровневым, или где-то между этими двумя формами.

Вторым шагом является определение графика действий или задач. Помните структуру распределения работ, т.е. шаги, которые мы рассматривали в Scope проекта? Самые нижние уровни в структуре распределения работ называются рабочими пакетами, и они определяют конкретные результаты проекта. Здесь вы разбиваете каждый рабочий пакет на действия, в которых прописана работа, необходимая для его завершения.

График проекта

После того как вы определили график мероприятий, пришло время упорядочить их. Последовательность действий основана на взаимодействии между задачами. Каждое действие, кроме самого первого и самого последнего, должно быть связано, по крайней мере, с одним предшествующим или одним последующим. Когда вы добавили все свои взаимосвязанные действия, результатом будет логическая последовательность порядка, в котором должна выполняться работа проекта.

Затем вы должны оценить ресурсы, необходимые для выполнения каждого действия. Вы оцениваете количество и типы необходимых вам ресурсов, включая людей, оборудование и материалы. Далее, вы можете использовать свои оценки ресурсов и выяснить, сколько времени потребуется для завершения каждого действия. Есть несколько методов для составления расписания из последовательности ваших действий и оценок: метод критического пути, метод критической цепи и т.д. Все это мы рассмотрим в будущих главах.

Какой бы подход планирования вы ни использовали, конечным результатом является график, который отражает ранние и поздние даты начала и окончания каждого действия в вашем проекте. Хотя для разработки реалистичного графика обычно требуется несколько повторений, в конечном счете вы создадите базовый график для своего проекта.

Как только работа над вашим проектом начинается, вы отслеживаете ход выполнения работ, а также изменения в графике, чтобы вы могли определить любые отклонения от начального плана. Если это происходит, вы можете предпринять корректирующие действия, чтобы восстановить график.

Процесс оценки

В этой статье мы рассмотрим общий процесс оценки проекта. Какие основные шаги нужно учитывать, если вы начинаете работать с новым проектом или к вам приходит запрос на изменение существующего?

Прежде чем ответить, как оценить проект, нужно понять, что мы оцениваем.

Первый шаг — определить Project & Product Scope

Для начала нужно определить скоуп выполняемых работ и ограничения. Для этого:

  1. Определяем одного или нескольких стейкхолдеров, которые могут выступать в роли владельца продукта (Product Owner).
  2. Обсуждаем с Product Owner скоуп продукта: что должно быть сделано, какой функционал ожидается, какие бизнес-потребности должен покрыть этот продукт. Таким образом мы формируем Product Scope.
  3. На основании Product Scope создаем скоуп проекта — Project Scope — то, как мы будем реализовывать требуемый функционал. На этом этапе можно предварительно оценить сроки и стоимость проекта (L0 estimates).

Разница между скоупом продукта и скоупом проекта:

Разница между скоупом продукта и скоупом проекта
  1. Если нам нужны точные оценки длительности работ, то опускаемся еще на один уровень ниже — иерархической структуры работ (Work Breakdown Structure — WBS). Разделение задач на этом уровне позволяет правильно оценить временные ресурсы и стоимость проекта.

Основываясь на своей практике, могу сказать, что на первых двух этапах очень важно писать задачи не только In Scope, но еще и Out of Scope. Если вы хотите узнать, как Out of Scope — требования могут повлиять на проект, рекомендую посмотреть ролик Portfolio.

А еще важно проработать нефункциональные требования, которые также могут сильно повлиять на окончательное время исполнения проекта.

Важно писать задачи не только In Scope, но еще и Out of Scope

Следующий этап — собрать команду для оценки

Хорошо, если проект шаблонный: тогда PM может на основании существующей базы проектов или собственного опыта оценить проект самостоятельно.

Если проект нестандартный для PM или компании, нужно собрать группу экспертов (по технологиям и/или по доменной области), которые помогут в оценке.

Команда экспертов для оценки проекта не всегда входит в проектную команду. Однако очень желательно, чтобы архитектор, техлид или системный аналитик, принимающие участие в оценке, потом могли присоединиться к команде. Это снизит риски переэстимирования проекта, когда проектная команда не согласна с оценками экспертов.

Основные челленджи при оценке экспертами:

  • Привлечение экспертов, которые не имеют опыта в оценке работ по проекту. Они могут сказать, что нужно учесть при планировании (построить WBS), но не смогут оценить затраты по времени.
  • Эксперты-оптимисты недооценивают сложность работ и дают заниженные оценки.
  • Эксперты-перестраховщики сильно переоценивают проект и дают завышенные оценки.
  • Опора на оценку сеньоров, которые оценивают «под себя» и не могут давать оценку работ с учетом того, что на проекте будут мидл- или джуниор-разработчики/тестировщики.

Поэтому PM важно подбирать сбалансированную команду.

Когда у нас уже есть скоуп работ и группа экспертов, можно перейти к вопросу, как оценить проект.

Почему происходит scope creep

Причин появления scope creep множество, вот самые частые:

  • Вы не обозначили границы проекта или сделали это очень размыто. И либо Заказчик сейчас вами манипулирует, либо он действительно не понимал, что мобильного приложения не будет.
  • У Заказчика поменялись приоритеты или бизнес-процессы, и ему теперь нужно не совсем то, что было заявлено в начале проекта.
  • Вы не выявили всех стейкхолдеров в начале проекта, а они вдруг взяли и материализовались со своими вполне законными требованиями.
  • Вы не дружите со словом «нет» либо у вас не хватает полномочий его сказать.
  • Первоначальный анализ был проведен плохо, и вы (или ваши аналитики) не поняли, что именно и зачем надо Заказчику (какую проблему он решает), и теперь удивляетесь. С вашей точки зрения – требования «из ниоткуда», с точки зрения Заказчика – «это же очевидно!».
  • Вы изначально не построили процесс управления изменениями и не сделали его прозрачным для Заказчика. Один раз согласились, второй раз включили в объем, потому что «там же немного, и для них это важно», третий раз не просчитали влияние изменения и пришлось переписывать большой кусок – и вот сроки проекта поехали на два месяца.

Как вы можете заключить из этого перечня – обычно в scope creep виноват все-таки руководитель проекта, т.к. в большинстве случаев его можно предотвратить. И даже если предотвратить scope creep  было нельзя, задача РМа – увидеть его на самых ранних стадиях и предпринять корректирующие действия.

Scrum-терминология

Scrum — это методология по управлению проектами. Набор принципов, ценностей, политик, ритуалов для организации работы. В скраме полно терминов, но в ежедневный обиход попала и закрепилась только часть из них.

Бэклог

От англ.

backlog

(дословно —

очередь работ

) — еще не запланированный объем работы, который требуется выполнить команде. Каждая созданная задача вначале попадает в бэклог, а потом уже в спринт.

Как и в случае со спринтом, термин используется и в отрыве от скрама. Часто бэклогом называют отложенные задачи. Которые сделать нужно, но не сейчас.

Примеры употребления:

  • «Надо разгрести бэклог»
  • «Пусть пока задача полежит в бэклоге, не будем брать её в этот спринт»
  • «Не забудь добавить эту задачу в бэклог своей команды»

Гол, голевой

От англ.

goal

(дословно —

цель

) — цель спринта (бывает одна или несколько), которую команда берется сделать. Цель состоит из ряда задач, которые нужно выполнить, чтобы его достигнуть.

Слово употребляется и как существительное, и как прилагательное. Может быть множественного числа.

Примеры употребления:

  • «Эта задача голевая, нужно сделать ее в первую очередь»
  • «Все голы в этот раз не выполнили»
  • «Почему неголевые задачи в работе?»

Дейли

От англ.

daily

(дословно —

ежедневно

) — ежедневные короткие (от 5 до 30 минут) встречи команды с целью поделиться прогрессом по выполненным задачам за предыдущий день и озвучить план работ на текущий день. Также дейли могут называть

стендапом

(от 

daily standup

), потому что обычно такие встречи происходят стоя — для большей эффективности.

Примеры употребления:

  • «Ребята, у нас дейли, встаем»
  • «Я сегодня удаленно, подключите меня на дейли по Zoom»
  • «К сожалению, дейлик пропускаю, нужно идти на важный митинг»

Коммититься

Глагол от англ. существительного

commitment

(дословно —

ответственность

). Коммититься — значит обещать выполнить определенный объем работы в оговоренные сроки. Это не просто обещание, это сознательное обязательство перед собой и командой. Человек, который закоммитился, обязан сделать всё возможное, чтобы выполнить то, что сам и пообещал реализовать.

Примеры употребления:

  • «Мы на это не коммитились, поэтому надо вернуться к более приоритетным задачам»
  • «Вы уверены, что мы можем коммититься на такое?»
  • «В этом спринте мы выполнили все цели, на которые коммитились»

Спринт

От англ.

sprint

(дословно —

бег на короткую дистанцию

) — заданный отрезок времени, за который нужно выполнить запланированный объем работы, чтобы в конце этого отрезка был ожидаемый результат.

Термин используют не только те, кто работает по скраму, но и те, кто просто хочет организовать свою работу и сформировать ясные рамки, во время которых должны быть выполнены задачи.

Примеры употребления:

  • «Опять завалили спринт»
  • «На этот спринт выпадают праздничные дни, поэтому он будет короче»
  • «Невыполненные задачи из прошлого спринта надо перенести в следующий»

dgewgriwq9rgp4vrgwmh7mjfgpw.png

Управление качеством проекта

Успех проекта означает достижение его целей. Управление качеством включает процессы, обеспечивающие соответствие проекта его целям и требованиям. Управление качеством начинается с планирования.

В плане управления качеством вы определяете стандарты качества, необходимые для проекта и конечных результатов. Такие вещи, как технические характеристики продукта, допустимые уровни ошибок, допустимые размеры и т.д. В плане также указывается, как вы продемонстрируете, что проект соответствует этим стандартам.

Обеспечение качества – это то, что вы делаете, чтобы убедиться, что ваш проект соответствует стандартам качества, которые вы определяете. Например, обзоры или создание прототипов. Вы анализируете результаты тестов, чтобы увидеть, соответствуют ли они установленным вами стандартам.

Проектная команда

Другой областью обеспечения качества является оценка ваших процессов и процедур качества, чтобы увидеть, есть ли способы их улучшить. Контроль качества – это тестирование результатов и регистрация результатов этих тестов. Это те процессы, которые вы выполняете, чтобы гарантировать, что проект соответствует требуемому уровню качества.

Трудовые ресурсы проекта

Во время планирования вы определяете навыки и роли, необходимые для выполнения работ, предписанных проектом. После того как они определены, вы можете составить штатное расписание для вашего проекта. Следующим шагом является приобретение людей, которые вам необходимы. Это могут быть нанятые сотрудники или взятые внутри организации.

Все мы знаем, что командам нужно время, чтобы полностью раскрыть свой потенциал. Когда состав укомплектован, вы должны помочь людям работать вместе и стать командой. По ходу работы вы управляете командой. Вы отслеживаете работу сотрудников, предоставляете обратную связь, чтобы помочь им совершенствоваться, решаете проблемы и управляете конфликтами.

Коммуникации в проекте

Общение является ключом к успеху проекта. Как менеджер проекта, вы проводите большую часть своего времени, общаясь с людьми о проекте. Во время планирования вы разрабатываете план коммуникаций по вашему проекту. Здесь описывается информация, которую вы сообщаете, аудитория, которая получает информацию, методы, которые вы используете для ее отправки, и как часто вы должны оставаться на связи.

Когда начинается работа над проектом, вы должны следить, чтобы все получали необходимую информацию, и она вовремя доходила до нужных людей. Поскольку управление проектами в значительной степени связано с другими людьми, управление коммуникациями в проекте имеет решающее значение для его успеха.

Риски проекта

Риск представляет собой неопределенность. Управляя рисками проекта, вы не только уменьшаете вероятность и влияние негативных событий, но и пользуетесь преимуществами происходящих позитивных событий.

Первым шагом в управлении рисками проекта является составление плана. По сути, вы объясняете, как выполнять задачи по управлению рисками в вашем проекте. Планируя управление рисками, вы обеспечиваете достаточно времени и ресурсов для этих важных задач.

На втором этапе определяются риски, с которыми может столкнуться проект. Вам следует периодически повторять этот шаг, чтобы искать новые риски, которые могут возникнуть в процессе работы. Нет необходимости управлять каждым выявленным риском. Для этого есть третий шаг.

Третьим шагом является анализ вероятности возникновения каждого риска, а также его влияния на проект. Таким образом, вы можете расставить приоритеты по рискам, чтобы сосредоточиться на тех из них, которые имеют наибольшую вероятность и влияние.

Управление рисками проекта

Имеется множество способов справиться с рисками, например, избежать их, застраховаться от риска, уменьшить его влияние, разработать планы действий в чрезвычайных ситуациях и так далее. Для каждого риска, которым вы управляете, вы решаете, как вы будете реагировать на риск в случае его возникновения.

Последний шаг – мониторинг рисков. Вы анализируете ситуацию, чтобы оценить возникновение какого-либо риска в проекте и мгновенно запустить подготовленное решение. Затем вы отслеживаете результаты, чтобы убедиться, что решение работает. Управление рисками важно на протяжении всей работы над проектом. Это помогает уменьшить негативное воздействие вредных событий, поэтому мы еще остановимся более подробно на данной теме в будущих главах.

Рейтинг
( 1 оценка, среднее 5 из 5 )
Загрузка ...