Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

«Немного надо доделать». Опрос разработчиков о незапланированных задачах в проектах

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Мы в spexfy.com (сервис для разработки техзаданий) решили подсчитать средний процент потерь времени от непредвиденных и
неоговоренных ранее «хотелок» клиентов.

Очень часто клиент и разработчик(и) начинают взаимоотношения без детального техзадания проекта, но с подписанным договором.

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

При отсутствии детального ТЗ, разработчик(и) обычно (чтобы не ссориться с клиентом) берет эту часть разработки за свой счет.

Иногда такие «хотелки» клиента обходятся в 5-15% от бюджета всего проекта.

Если вы сталкивались с такой ситуацией и проводили разработку за свой счет, во сколько вы оцениваете потери своего времени по проектам из-за непредвиденных «хотелок» клиентов?

Считаем в % к общему количеству времени самого проекта (например, 5 часов потерь от 200 часов всего проекта = 2,5% потерь).

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

.

Я делаю так. Если почасовка — клиенту дается быстрый естимейт(неточный) на новую фишку и оценка влияния на проект в общем(еще менее точная). Также даю оценку времени необходимую на уточнение(только за счет клиента).
Если фиксированный — читаю начальное описание(до milstone), если хоть как-то можно натянуть, что было описано но я провтыкал и стоимость менее 30%(всех изменений) — выполняю. Если «таких слов не было» — за отдельную плату и только после release предыдущих этапов. Если есть влияние на сроки выполнения основного задания — только после завершения всех описанных этапов(или отмены не начатых).

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

Ах да. Сколько по времени. 10% где-то надо заложить в фиксед и ничего в почасовку. На почасовке все вопросы включая чат больше 5-10минут подряд включаются в почасовку. Это на экперт уровне. Чем ниже уровень, тем больше надо добавлять к estimate.

не вклався в естімейт

по деньгам или времени?

От сказав що займе n годин, а зайняло n+20%

То есть пообещал, что обойдется в 1000 долларов, а обошлось в 1200?
Это тот же фиксед-прайс фактически только с попыткой кинуть клиента на еще 200 долларов.
Почасовка это когда мы идем спринтами недельными и вроде все движется в понимании клиента нормальным темпом и он платит и не паникует. Когда проект закончится неизвестно ни клиенту ни команде.

То есть пообещал, что обойдется в 1000 долларов, а обошлось в 1200?
Это тот же фиксед-прайс фактически только с попыткой кинуть клиента на еще 200 долларов.

Странно, а в других областях это норма. Если не продается уже готовое.

Как только видите, что не влаживаетесь — обьясняете клиенту почему.
Но вообще говоря превышение естимейта в два раза клиенты переживают. Иногда и в 10 раз переживают.
10-20% я даже не уведомляю.
Если у вас часто такое — увеличивайте вилку(разброс).
Классика — когда человек говорит " у меня вот есть то-то и то-то, надо маленький фикс сделать". Начинаем, оказывается, что до этого там работали индусы и почти все запросы к базе ложат нехилый впс(индексов нет, вместо правильных джойнов выполняются O(x^3) и так далее), соответсвенно пофиксить все эти запросы до начала работ — 10х легко и вместо двух часов естимейт на пару недель.

или речь чисто о фрилансерах с почасовкой ?

Похоже даже не с почасовкой а с fixed price проектами

При отсутствии детального ТЗ, разработчик(и) обычно (чтобы не ссориться с клиентом) берет эту часть разработки за свой счет.

Мне интересно как дела обстоят на галерах. Чет кажеться что у них контракт там такой что они еще 4 шкуры с заказчега сдерут, за хотелки.

90% аутстаф — заказчик платит за человеко-часы. Кажется.

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

Мне интересно как в цивилизованном мире. Является ли нормой, если Джон Сильвер пришел в компанию по разработке софта где нибудь в штатах и заключил контракт, что получит свой сайт за 200 000 $ и ни центом больше?

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

Сталкивался с таким, что один и тот же проект на одной и той же галере переписывался с нуля разными командами три раза. Это не 4 шкуры это вообще ни в какие разумные грани не лезет.

А:
1) сколько этот проект жил?
2) насколько плавно его передавали между командами?
Некоторые советуют всегда выбрасывать пилотник, и писать реальный код с нуля.
А если проект не передают, то фиг в нем разберешься.

1) сколько этот проект жил?

Изначально планировали за год. В итоге проект кое-как вышел после 3-х команд через 6 лет.

2) насколько плавно его передавали между командами?

Из первой команды во вторую никого не попало. Из второй в третью попал 1 человек, но сомневаюсь что именно из-за этого в 3-й раз все-таки что-то получилось.

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

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

друга просрала все на юніт тести

Я сохраню этот комментарий для адептов юнит тестов.

тесты не виноваты, что их могут писать пицценосцы

«Пицценосцы» и оверинженерить будут?
Не похоже.

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

не всегда, но часто тим лид, который кагбы сам гребец (хоть и с барабаном), принимает решение о цифрах каверджа, или о апруве пул реквестов

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

мутационное тестирование пробовали? Stryker просто убил для меня остатки веры в кавередж как сколько-нибудь значимое число

если я пишу код сам, то процентов 80 покрытия мутационное проходят, с рандомной тимой рандомные результаты

Та знаем знаем. Индусы неделями покрывающие тупые бины чтобы «кавередж был» с нулем реальных тестов на реальную логику, просраными сроками, и заваленым продакшеном сразу после деплоя, потомку что кавередж есть, а тестов нет.

[100500й] раз вклинюсь, что без e2e кавередж действительно до одного места, за исключением критических алгоритмов — именно там юнит-тестами нужно покрывать чем ближе к 100%, тем лучше (других исключений пока не встречал).

Легко. Если пицценосцам дать дизайн-паттерны, то не удивлюсь, если они искусственную черную дыру с последующим апокалипсисом создадут, не то что проект. От этой религии даже у опытных иногда башку сносит. Сидит себе такое чудо, создает класс SomethingRepository c интерфейсом ISomethingRepository делает какие-то там пошлые глупости с датаконтекстом внутри, и с довольной рожей заявляет «я абстрагировался от источника данных».

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

Не мамонт не вымрет. :-)

«Немного надо доделать» хорошо лечится «Немного надо доплатить».
Будни фриланса, ничего удивительного.

По крупным проектам — это вообще норма. И лечится приоритезацией. Хотите доделать (и разумеется срочно) — вот пункт договора о приоритезации, вот план с приоритетами, давайте чего-нибудь подвинем, скажем на июль. Ваше же срочнее надо? Вот підпиздесь, чтоб потом вы же, запамятовав, «по ошибке» не требовали штраф за просрочку.

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

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

Очень часто клиент и разработчик(и) начинают взаимоотношения без детального техзадания проекта, но с подписанным договором.

В этом и есть смысл Аджайла — клиент практически никогда не знает чего хочет. Но даже если он придет с подробнейшим ТЗ или такое ТЗ ему напишут — то когда все будет готово он все равно скажет что хотел по-другому!

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

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

При отсутствии детального ТЗ, разработчик(и) обычно (чтобы не ссориться с клиентом) берет эту часть разработки за свой счет.

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

Если вы сталкивались с такой ситуацией и проводили разработку за свой счет, во сколько вы оцениваете потери своего времени по проектам из-за непредвиденных «хотелок» клиентов?

В последнее время компания старалась принципиально не брать фиксед прайс проекты. Именно потому что они всегда заканчиваются «качелями» с клиентами, которые хотели «Фейсбук за 2000 баксов».
До этого в моем опыте было 2 примера. Первый — не очень удачный. Новый проект взяли вопреки тому, что свободных девелоперов не было. Его пилила команды абсолютных новичков, которых взяли прямо из ВУЗа. В итоге, естественно, все сроки просрачили, не смогли показать ничего, кроме багов, и потом вся компания помогала доделывать этот проект в овертайм. Овертайм девелоперам оплачивали по увеличенному рейту (это было до «галер») — поэтому для компании этот проект вылился в серьезные убытки. НО — клиента удалось «зацепить» и потом этот проект поддерживали годами — что на длительном этапе вылилось в доход.
Второй пример — что бы зацепить очень жирного американского клиента выиграли тендер на фиксед-прайс проект. При этом, естественно, эстимейты занизили по максимуму. Что бы спасти ситуацию — собрали «команду мечты» из одних синьоров, выдернув их с других проектов. В итоге за полгода клиенту сделали «конфетку». Но если пересчитать разницу между зарплатой синьоров и оплатой от клиента то этот проект был не слишком прибыльным для компании.Особенно на фоне других где продают джунов но рейтам синьоров. Зато произвели впечатление на клиента и доказали что мы таки можем делать не только говнокод. Возможно это открыло нам двери в другие топ-фортун компании.
Так что для компании и для разработчиков итог таких проектов совсем разный. Вместо опроса можно было просто спросить по какому рейту компании оплачивают разработчикам овертайм.
Если работодатель предлагает девелоперу «проводить доработку за свой счет» — то нужно не подсчитывать потери, а искать другую работу!

переделки за счет бесплатных рабов!

и не только перделки, но и
— «пособеседовать»
— «тут фигня какая-то»
— «мы всё уронили»
и многое другое.

Веселее всего когда мы уронили, но вам не сказали, и кое-какие цифры правили руками — а вы сделайте чтоб правильно (на вчера, естессно, и бесплатно) — у нас отчётность не сходится.

Підписатись на коментарі