Допустим, вы делаете проект — мобильное приложение. Нашли команду: Менеджер, Тимлид, разработчики. Составили список задач, оценили, назначили первый релиз. Проходит время, а релиза нет. Давайте искать ответ, почему так.
Ниже приведён график прогресса по проекту.
По оси y — видимый прогресс. По оси x — время
Первым этапом делаются внешние компоненты приложения — верстка. На этом этапе часто кажется, что разработчики делают проект раньше срока. Это связано с тем, что верстка дает «ощущение готовности» — «всё сделано, осталось только данные подсунуть». На деле это малая часть работы.
Главное на этом этапе — не попасть в ловушку, не думать, что команда опережает график. Это важно знать всем: разработчикам, менеджерам, заказчику.
Иногда исполнители используют это как лайфхак для того, чтобы срочно создать вау эффект. Времени на проект не было. И чтобы предотвратить панику, разрабочики выполняют максимум задач по верстке. Гораздо правильнее — честно признаться. У исполнителя форс мажор, а вертка — это меньше половины проекта. После этого всеми участниками процесса разработать план как успеть к сроку.
Вторым этапом в готовую верстку подсовываются данные. Они получаются через интрфейс — API. Бывалые менеджеры и разработчики в курсе, что «верстка это мелочь, вот прикрутили API, значит готово».
Если вы получаете оценку разработчика, то как правило вам дают оценку до этой точки. Все что будет сделано по задаче дальше разработчик может даже не заметить. У него сложится впечатление, что работы по проекту выполнены в срок.
На этом шаге все понятно и вопросов не возникает. Работа быстро продвигается и есть что продемонстрировать
Завершение проекта. На этом шаге тимлид посмотрел на результат — тут не то скругление у кнопки, тут не сделан переход по инпуту, тут вообще не по тз и тд. Набирается список правок, который по объему может сравниться с объемом исходной задачи. В это процессе менеджер и тимлид тратят много времени.
Если вы получаете оценку от опытного тимлида, как правило вы получаете оценку до этой точки
Приемка. Здесь работы сдаются заказчику. Ему не нравится как выглядит результат, хотя макеты согласованы до начала работ, какие-то данные ему не нужны, а что-то он хотел бы добавить, карусель которую вы сделали должна быть зациклена, ведь «это очевидно» и тд. Обычно здесь требуется активная работа менеджера
Советы по этому пункту (менеджерам):
- Главное — как можно раньше демонстрируйте результат, чтобы включить работы по приемке в более ранние этапы. Общайтесь с заказчиком — проводите демо, собирайте обратную связь, давайте тестовые сборки. Это позволит постоянно понимать, насколько заказчик готов принять проект
- фильтруйте желания заказчика. Часть желаний заказчика может быть доп работами, которые заказчику не очень то и нужны, часть не будут входить в ТЗ, но заказчик будет считать иначе — нужно решить конфликт. Нужно поддерживать баланс между: «идеальностью» проекта, стоимостью для заказчика и выгодой для компании
- закладывайте эти риски в оценку. Редко заказчик принимает работу без комментариев
Подведём итог.Разработчики часто не видят весь процесс и не учитывают правки и отладку. Поэтому чтобы получить сроки проекта приходится увеличивать их оценку в 2 раза. Менеджерам важно поддерживать связь с заказчиком, честно говорить о проблемах и рушить иллюзии.
Авторы: Никита Сироткин, Владислав Кошечкин
Да нет, всё не совсем так. Набирают клиентов, одновременно ведут кучу проектов. Во-первых, времени на всех не хватает потому что от жадности набрано больше чем могут вывезти. Во-вторых, больше дорожат крупными клиентами и делают в первую очередь их проекты (обычно это не твой проект, анон, а какого-нибудь завода. Там и бюджет гораздо больше и пиздюли мощнее). Проекты ноунеймов делают по остаточному принципу. В третьих, форс-мажоры и отпуска. Где-то не рассчитали, где-то проект по ходу изменили, кто-то уволился, кто-то снова в отпуске. В результате, либо ослиная скорость, либо вообще всё встаёт, особенно потому что п.1. В чётвертых, ты в целом никуда не денешься с "подводной лодки". Уже начав проект, на другую команду не переключишься и приходится работать уже с теми кто есть. Пени всякие и штрафы не компенсируют задержку. В пятых, простите уже за такое наблюдение (это личное мнение), но большинство программистов это неорганизованные раздолбаи в состоянии постоянного полурасслабона. Для них срыв сроков это норма. Дефицит кадров, куча клиентов, постоянно растущие з/п - зачем париться? Даже если откуда-то попрут, то вакансий много.
Нет мотивации доделывать проект, ну или доделать его вовремя - это главный фактор. К нему в основном ведет неверная оценка сроков задач. Чаще всего это связано с космическим объемомо работы, оценку которого свалили на одного человека и без нее уже заваленного другой работой. Он сделал приценку-оценку, но что-то не учел, что-то не посчитал, что-то посчитал неверно. ИМХО такокое чаще всего наблюдается на проектах с большими ТЗ порядка 50 страниц или 200-250 экранов дизайна. А также подобных проектах, но с нещедрыми заказчиками, из-за чего не закладываются сверх риски в проект. Еще и для полного комбо когда нужно дать ответ по оценке за день, а бывает и до какого-нибудь условного обеда.
Как с языка сняли! Все в точку! Наберут проектов, как правило. Не успевают. Начинается перекладывание ответственности в команде. Сроки срываются
Разработчики НИКОГДА не видят весь процесс. Это дело ПМа.
Тут нужно сделать небольшую сноску, что только малоквалифицированных специалисты не умеют оценивать сложность работы.
На самом деле часто встречал, что очень квалифицированные ребята могут некорректно оценивать. Это связано с тем, что они просто могут не видеть всю картину. Как раз об этом и пишем
Оценивают не сложность, а объём, не?) Или сложные задачи перестали делиться на простые?) Не обижайтесь, шутка юмора.
Встречал ТЗ на 1/3 А4)
В большинстве нынешних проектов, само проектирование, "продумывание", детализация задач и условий встречается редко, это я стараюсь мягко выразиться тк если ТЗ на новый самолёт выглядит как, "нам нужен поезд, но только летающий и тп" или "нам нужен мост, но мы пока не решили где он будет" то мало хорошего получится в итоге.
Странно, но нынче это не хорошо и не плохо, это просто есть, обусловлено тем, что полноценное проектирование может составлять более 50% конечной работы и занимать месяцы. За это время некоторые проекты теряют смысл или потенциал, поэтому сейчас популярны подходы, методы в рамках которых "все быстро" и многие вопросы решаются по ходу дела и часто конечный результат мало соответствует изначальному документу. Поэтому со сроками (да и с деньгами) все хорошо у тех, кто в 100ый раз делает работу по одному шаблону.
Говоря проще, хотите фиксированные работы в установленные сроки, прорабатывайте задачи не менее чем на 95% и фиксируйте их в письменном виде, это снимает большинство проблем, но прилично отдаляет старт))
Формальные задачи - формальные сроки...
Эх, молодёжь...
Брукса "Мифический человеко-месяц" никто не читал.
"Составили список задач, оценили"
Так если есть список задач с оценками, откуда "ощущение готовности"? На Burndown диаграмме должно быть видно реальное положение дел.
План разработки приложения
1. Создать план разработки
2. Релиз
"Составили список задач, оценили" примерно вот так выглядит, а дальше кто что додумал
Никогда не соблюдал никакие дедлайны) каждый раз, когда старался это делать - качество стремительно протухало. Ведь всегда нужно скорей, быстрей, а ничего хорошего от такого подхода не выйдет, отсюда и баги и недоработки, тк исполнитель всегда заложник сроков и в определённый момент он всегда не успевает. Вот всегда. При этом может меняться объем, требования к проекту, или в процессе все вообще может развернуться на 360, а сроки то уже оговорены.
Как будет готово - так и будет готово, вот простейшая формула)
Зачем вообще сроки? Ни исполнитель, ни заказчик не заинтересован в том, что бы было долго. Но как только исполнитель называет срок - он становится заложником этой цифры, тоже самое касается в общем то и цены, и объёма.
Первое и самая главная цель всех этих оценок чтобы установить рамки для разработчика, чтобы в момент когда проект потребует допов можно было топоть ножкой и кричать "ну мы же договорились"
Рецепт простой и надёжный, как швейцарские часы - к оценке сроков докидывать +50% на каждом разрабе + ещё 50% на qa/uat.
Почитайте уже что-нибудь, например - Р. Мартин "Чистый Agile".
Чтобы не попадать в глупое положение с такими вот...публикациями.
Так это. Уже-ж как лет 10 решили, что задачи в IT по времени не оцениваются. Что за фантомные менеджерские боли и натягивание шара на куб?
Максимум, что можно это понять сколько стори поинтов выполняет команда за интервал времени, и то это справедливо для продолжительной работы год-два-три.
Для абстрактного ТЗ оценка по времени будет коррелировать с реальностью со значением ноль.
Заказчикам не выгодна такая позиция
Потому что это Разработка. Разработка новых систем, конструкций, формул всегда связана с риском увеличения сроков, потому что велика вероятность незапланированных работ, которые как выясняется в процессе тоже нужно сделать. И никогда, если разрабатываешь что то новое ты срок не запланируешь наверняка, если конечно ты не делаешь то же самое второй, третий или ещё какой раз. Первый аргумент просто убил, такое впечатление что автор позавчера пришёл в разработку а вчера выкатил статью. Очень поверхностная статья
Детский сад ясельная группа. К тому же в названии статьи неплохо бы указать, что речь пойдет о создании сайтов для заказчика.