Мы покупаем и продаём часы: подводные камни почасовой оплаты
В аутсорсе разработки почасовая оплата — это когда мы покупаем и продаём часы, а между ними должен появиться business value. Я разбираю, почему час программиста не равен другому часу: трекинг по 6 или 8 часов, онбординг, косвенные расходы, разница в эффективности до 32 раз и риск превратиться в бодишоп.
«Мы покупаем часы и продаем часы», — объяcнял я нашему проджекту. А пока эти часы продаются, нам нужно успеть сделать проект, который заказчику нанесет непоправимый business value.
Но с часами все не так просто, час же может быть эффективный, а может быть нет. Еще может быть, что мы его у сотрудника купили, а клиент не принял. Ибо это не тот час, который он заказывал.
Бывает еще час во временном отрезке есть, а задачи, куда его можно было затрекать нет. «Простой» — время прошло, зарплата заплатилась, а выгоды никому не сделали.
Что входит в час программиста
Еще в каждый час что-то заложено. Так называемые косвенные расходы. Получается мы продаем час программиста, а в нем еще немножечко HR. Да и в целом всех других расходов.
И не путайте часы со сроками. Если задачу делать 50 часов, а сегодня 1.01.2023, то когда задача будет готова? Воооот.
Но и это не все, часы трекают все по разному. Где-то норма по 8 в день, а где-то по 6. Но даже, где по 6, встречаются люди, кто и 6 почему-то не трекают. А где по 8, бывает, что по 12. Не каждый день, но все же.
Так же есть onboarding, где ничего полезного не происходит, а часы идут. А без онбординга, дак совсем ничего сделано не будет. Получается часы не констистентны. Нельзя одного миддл-битрикса заменить другим миддл-битриксом, не проведя онбординг.
Эффективность часа программиста
Еще и линейки измерителя нет. В умных книжках пишут: час программиста может отличаться до 32 раз в эффективности. Хоть AI пиши, которое замеряет полезность сотрудника, стоп, где-то уже это было.
А еще можно превратиться в бодишоп, если часы покупать, продавать и не думать о том, что происходит между ними. А между ними тот самый business value. И если задачи не приоритезировать, цели проекта не прояснять, за обратной связью не ходить, то зря старались.
Закон Брукса: почему больше программистов — не быстрее
А еще 9 программистов за 1 месяц интернет-магазин не напишут. Чем больше программистов, тем выше издержки на концептуальную целостность в голове у каждого. Проще говоря общения становится больше, чтобы быть в курсе. Но есть и обратный эффект, если хорошо поделить проект на фронт/бэк, модули / микросервисы, то все возрадуются и буду работать быстрее.
Что важно знать о почасовой оплате разработки
— Часы все трекают по разному. Чаще всего это 6 или 8 в рабочий день.
— Часы не одинаковые. Нельзя заменить человека на другого без перемен. Иногда положительных.
— Часы и время не одно и тоже. При оценке скроков просто поделить объем на количество не получится.
— В продажу часов включено что-то еще.
— Бывает, что часы потратили, но не продали. Это вообще просто, если с клиентом действия не согласовать, а сотрудник продолжит на работу ходить.
— Лучше 1 человек на 168 часов, чем 2 по 84. Меньше затрат на общение и больше эффективных часов.
Вопросы и ответы
Почему час одного программиста нельзя заменить часом другого?
Часы не консистентны: нельзя заменить одного миддла другим без онбординга, а эффективность часа может отличаться до 32 раз.
Почему 9 программистов не сделают интернет-магазин за месяц?
Чем больше программистов, тем выше издержки на концептуальную целостность — общения становится больше. Лучше 1 человек на 168 часов, чем 2 по 84.
Как оценить сроки разработки по часам?
Часы и время — не одно и то же. Просто поделить объём на количество людей не получится: если задачу делать 50 часов, она не будет готова через 50 часов.