Как запустить IT-проект в срок: опыт проектного менеджера

Определение ключевых функций продукта

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

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

Зачем это нужно?

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

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

Читайте по теме:

Запуск востребованного FinTech-продукта в кризис: что необходимо учесть?

Зачем разработчики создают сразу несколько сторонних проектов

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

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

Мы получили полностью рабочий продукт, которым уже можно было полноценно пользоваться. Остальные три парсера мы вводили в работу постепенно: за две недели реализовали и ввели второй, потом третий.

Для получения нужного функционала нам не пришлось ждать лишние один-два месяца.

Оценка сроков создания проекта

Один из самых непростых этапов создания продукта — это оценка сроков. Чтобы выполнить все работы к дедлайнам, необходимо заранее верно оценить время, нужное для их выполнения.

На своих проектах я реализую трехступенчатую систему оценки сроков:

1. вначале задачу оценивает разработчик, измеряя ее в часах работы;
2. затем ее оценивает другой программист, чтобы избежать субъективности;
3. после всего срок работы оцениваю я, добавляя к получившемуся времени еще 20-30%.

Почему необходимо добавлять дополнительное время на разработку?

Даже если программист соблюдает дедлайны и я знаю, что работа будет сдана в срок, никогда не стоит исключать возможные форс-мажорные ситуации. Это может быть что угодно: от сложностей в документации до отключения света в офисе. Дополнительное время снижает риск просрочки дедлайна.

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

Контроль команды разработки

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

На проектах с небольшим сроком разработки:

• практикую ежедневные созвоны с членами команды буквально на три-пять минут.

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

На проектах с более долгими сроками реализации:

• созвоны проводятся реже. Достаточно один-два раза в неделю. Остальное решается в переписке.

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

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

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

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

Читайте также:

Софт-скиллы разработчика: какие навыки нужны для получения оффера мечты

Избавьтесь от «организационных помех»: 4 способа работать продуктивнее с меньшими усилиями

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

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

Диаграмма Ганта

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

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

Пример применения диаграммы Ганта на одном из моих проектов

Переговоры с заказчиком

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

Почему это важно?

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

Приведу абстрактный пример. На работу дизайнера заложено 15 часов. Дизайнер выполнил работу за 13 и за четыре часа провел презентацию для заказчика. Заказчик утверждал макеты еще восемь часов.

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

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

Заключение

В заключение статьи выделю три основных тезиса, которых стоит придерживаться:

1. Отделяйте главное от второстепенного. Нет смысла реализовывать второстепенный функционал, если не готов главный. Так есть риск к концу срока не предоставить заказчику готовый проект.
2. Закладывайте дополнительное время на разработку. Это послужит своеобразной «страховкой» от непредвиденных обстоятельств.
3. Тщательно контролируйте задачи. Пробуйте различные техники и методы отслеживания ситуации, чтобы проект был сдан в срок.

Иллюстрации предоставлены автором

Фото на обложке: Shutterstock / antoniodiaz