Допустим, вы делаете проект — мобильное приложение. Нашли команду: Менеджер, Тимлид, разработчики. Составили список задач, оценили, назначили первый релиз. Проходит время, а релиза нет. Давайте искать ответ, почему так.
Ниже приведён график прогресса по проекту.
По оси y — видимый прогресс. По оси x — время
Первым этапом делаются внешние компоненты приложения — верстка. На этом этапе часто кажется, что разработчики делают проект раньше срока. Это связано с тем, что верстка дает «ощущение готовности» — «всё сделано, осталось только данные подсунуть». На деле это малая часть работы.
Главное на этом этапе — не попасть в ловушку, не думать, что команда опережает график. Это важно знать всем: разработчикам, менеджерам, заказчику.
Иногда исполнители используют это как лайфхак для того, чтобы срочно создать вау эффект. Времени на проект не было. И чтобы предотвратить панику, разрабочики выполняют максимум задач по верстке. Гораздо правильнее — честно признаться. У исполнителя форс мажор, а вертка — это меньше половины проекта. После этого всеми участниками процесса разработать план как успеть к сроку.
Вторым этапом в готовую верстку подсовываются данные. Они получаются через интрфейс — API. Бывалые менеджеры и разработчики в курсе, что «верстка это мелочь, вот прикрутили API, значит готово».
Если вы получаете оценку разработчика, то как правило вам дают оценку до этой точки. Все что будет сделано по задаче дальше разработчик может даже не заметить. У него сложится впечатление, что работы по проекту выполнены в срок.
На этом шаге все понятно и вопросов не возникает. Работа быстро продвигается и есть что продемонстрировать
Завершение проекта. На этом шаге тимлид посмотрел на результат — тут не то скругление у кнопки, тут не сделан переход по инпуту, тут вообще не по тз и тд. Набирается список правок, который по объему может сравниться с объемом исходной задачи. В это процессе менеджер и тимлид тратят много времени.
Если вы получаете оценку от опытного тимлида, как правило вы получаете оценку до этой точки
Приемка. Здесь работы сдаются заказчику. Ему не нравится как выглядит результат, хотя макеты согласованы до начала работ, какие-то данные ему не нужны, а что-то он хотел бы добавить, карусель которую вы сделали должна быть зациклена, ведь «это очевидно» и тд. Обычно здесь требуется активная работа менеджера
Советы по этому пункту (менеджерам):
- Главное — как можно раньше демонстрируйте результат, чтобы включить работы по приемке в более ранние этапы. Общайтесь с заказчиком — проводите демо, собирайте обратную связь, давайте тестовые сборки. Это позволит постоянно понимать, насколько заказчик готов принять проект
- фильтруйте желания заказчика. Часть желаний заказчика может быть доп работами, которые заказчику не очень то и нужны, часть не будут входить в ТЗ, но заказчик будет считать иначе — нужно решить конфликт. Нужно поддерживать баланс между: «идеальностью» проекта, стоимостью для заказчика и выгодой для компании
- закладывайте эти риски в оценку. Редко заказчик принимает работу без комментариев
Подведём итог.Разработчики часто не видят весь процесс и не учитывают правки и отладку. Поэтому чтобы получить сроки проекта приходится увеличивать их оценку в 2 раза. Менеджерам важно поддерживать связь с заказчиком, честно говорить о проблемах и рушить иллюзии.
Авторы: Никита Сироткин, Владислав Кошечкин
Никогда не соблюдал никакие дедлайны) каждый раз, когда старался это делать - качество стремительно протухало. Ведь всегда нужно скорей, быстрей, а ничего хорошего от такого подхода не выйдет, отсюда и баги и недоработки, тк исполнитель всегда заложник сроков и в определённый момент он всегда не успевает. Вот всегда. При этом может меняться объем, требования к проекту, или в процессе все вообще может развернуться на 360, а сроки то уже оговорены.
Как будет готово - так и будет готово, вот простейшая формула)
Зачем вообще сроки? Ни исполнитель, ни заказчик не заинтересован в том, что бы было долго. Но как только исполнитель называет срок - он становится заложником этой цифры, тоже самое касается в общем то и цены, и объёма.
Первое и самая главная цель всех этих оценок чтобы установить рамки для разработчика, чтобы в момент когда проект потребует допов можно было топоть ножкой и кричать "ну мы же договорились"
А ты выкатываешь за все допы ценник )
Ну не всегда. Часто бывает что заказчик не хочет что-то считать допом, а по тз не понятно что должно быть. Конечно в случае фирмы разработчик не теряет ничего, просто из бюджета проекта берегутся деньги. Но в небольших конторках или для фрилансера все эти правочки вылазят боком