Почему программисты срывают дедлайн

Допустим, вы делаете проект — мобильное приложение. Нашли команду: Менеджер, Тимлид, разработчики. Составили список задач, оценили, назначили первый релиз. Проходит время, а релиза нет. Давайте искать ответ, почему так.

Ниже приведён график прогресса по проекту.

По оси y — видимый прогресс. По оси x — время

Первым этапом делаются внешние компоненты приложения — верстка. На этом этапе часто кажется, что разработчики делают проект раньше срока. Это связано с тем, что верстка дает «ощущение готовности» — «всё сделано, осталось только данные подсунуть». На деле это малая часть работы.

Главное на этом этапе — не попасть в ловушку, не думать, что команда опережает график. Это важно знать всем: разработчикам, менеджерам, заказчику.

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

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

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

На этом шаге все понятно и вопросов не возникает. Работа быстро продвигается и есть что продемонстрировать

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

Если вы получаете оценку от опытного тимлида, как правило вы получаете оценку до этой точки

Приемка. Здесь работы сдаются заказчику. Ему не нравится как выглядит результат, хотя макеты согласованы до начала работ, какие-то данные ему не нужны, а что-то он хотел бы добавить, карусель которую вы сделали должна быть зациклена, ведь «это очевидно» и тд. Обычно здесь требуется активная работа менеджера

Советы по этому пункту (менеджерам):

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

- фильтруйте желания заказчика. Часть желаний заказчика может быть доп работами, которые заказчику не очень то и нужны, часть не будут входить в ТЗ, но заказчик будет считать иначе — нужно решить конфликт. Нужно поддерживать баланс между: «идеальностью» проекта, стоимостью для заказчика и выгодой для компании

- закладывайте эти риски в оценку. Редко заказчик принимает работу без комментариев

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

Авторы: Никита Сироткин, Владислав Кошечкин

0
57 комментариев
Написать комментарий...
Game Topia

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

Ответить
Развернуть ветку
Евгений

Оценивают не сложность, а объём, не?) Или сложные задачи перестали делиться на простые?) Не обижайтесь, шутка юмора.

Ответить
Развернуть ветку
Game Topia

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

Ответить
Развернуть ветку
Евгений

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

Ответить
Развернуть ветку
Game Topia

Необязательно сам что-то выбирает. Например, часто используемая на проектах библиотека rx создаёт чувство всемогущества. И так будет длится до тех пор, пока разработчик не столкнется с более сложной задачей. То есть, эта библиотека устроена так, что сделать А и Б очень просто, а АБ - невозможно. Декомпозиция покажет несколько часов, а в итоге испытаешь чувства, что собираешь кубикрубика. И так будет у каждого, кто не знает реальную историю происхождения этой библиотеки. 

Ответить
Развернуть ветку
greg chudnoff

не количество, а объем
в кубометрах

Ответить
Развернуть ветку
54 комментария
Раскрывать всегда