Главное Свежее Вакансии   Проекты
😼
Выбор
редакции
585 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Откровения разработчика: почему айтишники срывают сроки

Директор IT-компании «Нативные технологии» Андрей Иванов рассказал, как недооценил трудозатраты на проект в 3 раза и почему в срыве дедлайнов обычно виноваты люди, а не технологии.

b_5c77a7b995a87.jpg

Треть проектов идет с задержкой

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

Дедлайны — это фиксация договоренностей, которая дисциплинирует исполнителей.

На отрезке в 1 неделю легко в оценке попасть день в день. А вот на отрезке в 4-6 месяцев и более, дать оценку день в день — абсолютно нереально.

Из нашего опыта могу привести статистику:

2/3 проектов мы сдаем в соответствии с оценкой

1/3 проектов идет с задержкой

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

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

А вот большие, инвестиционные проекты, которые реализуются по бизнес-плану, здесь "срыв" сроков может быть очень критичен. На запуск проекта может быть завязана, как минимум, рекламная активность, и отсрочка чревата прямыми финансовыми и репутационными потерями.

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

Стоит отметить, что для каждого проекта причины задержек могут быть свои, не все зависит только от разработчиков. Где-то заказчик может затянуть с согласованием, где-то внесены изменения в ТЗ, где-то была допущена ошибка на этапе оценки.

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

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

Почему сложно оценить реальные сроки в IT-сфере

На результат оценки в IT-проектах влияет много факторов.

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

Даже простой вопрос постановки бизнес-задачи (формулирование идеи/функционала) IT-продукта таит в себе много подводных камней. Заказчик, формулируя идею, скорее всего, не до конца понимает весь функционал, все сценарии и взаимосвязи, которые должны быть реализованы. К примеру, вряд ли заказчик, при формулировании идеи думает об "отрицательных" сценариях поведения пользователей. Что будет, если пользователь решил прервать оформление покупки? Не ввел нужные данные или ввел неверные данные? А что если у него пропал интернет? И таких вариаций поведения пользователей и ситуаций очень много, все они должны быть продуманы и реализованы. От таких "мелочей" зависит качество продукта, никто не хочет пользоваться непродуманным приложением.

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

Самый правильный вариант — это оценка задач командой. Разработка ПО (программного обеспечения) — это командная работа. Уровень, глубина проработки проекта влияет на точность оценки. Несколько человек оценивают одну и ту же задачу, и в случае значительного расхождения обсуждают и приходят к консенсусу. Этот метод позволяет снизить субъективизм, влияние человеческого фактора.

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

Как ни странно, но в IT-сфере главное не технологии. Главное — это коммуникации между людьми.

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

2. Технологические факторы.

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

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

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

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

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

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

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

Первый наш проект был недооценен в 3 раза

В начале нашего пути, мы неоднократно наступали на грабли неверной оценки проектов. Мы давали оценку и фиксировали ее в договоре без достаточно глубокой проработки проекта. Не закладывали время на создание документации, коммуникацию и бета-тестирование.

В общем, совершили достаточно ошибок, чтобы выработать свой подход к оценке и реализации проектов:

— Глубокая, качественная проработка проекта — это основа.

— Фиксация договоренностей в договоре только после проработки проекта.

— Честная, максимально прозрачная работа с заказчиком на всех этапах проекта.

Один из наших первых проектов, был недооценен в 3 раза. Когда мы выиграли тендер, мы устроили праздник в нашем небольшом офисе, потому что считали, что это очень крупный и денежный контракт. Проект действительно был крупным, но только в плане объема работы, а не в плане гонорара. Вместо запланированных 4-5 месяцев мы работали 7, и еще месяц ушел на бета-тестирование.

F6rgskgw3yn1qf8PqS1fBmfeyQUJurXuyk4xFED6tAQF78l_Aa5l7UFcqmY2_LHUEc_QbeivtIgMZBqB

Проект, реализованный за 7 месяцев — сервис для поиска готового бизнеса и франшиз

Конечно, не все 7 месяцев работа велась с одинаковой интенсивностью. Были перерывы на тестирование и согласования на стороне заказчика, но зачастую команда проекта работала по 12-14 часов в будние и брали задачи на выходные. Я помню, как охрана в бизнес-центре несколько раз выгоняла нас из офиса в 23:00, чтобы снова встретить в 10 часов утра.

К слову сказать, заказчик относился к просрочке тогда вполне адекватно. В том числе, потому что видел усилия, которые мы прикладываем, и осознал объем задачи. Мы максимально погружали его в проект. Рассказывали, разъясняли, делились опытом. Совместно искали варианты оптимизации сроков, работали с функционалом, подбирали эффективные решения.

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

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Популярные за неделю
mn
13
Показать следующие
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать
Прямой эфир