2642
23 июн 2022
«Как понять, что разработчик не врет о потраченном на проект времени, если договорились об оплате за человеко-часы?»
ITECH, Production-директор
Прежде всего, хочу сказать, что случаи, когда разработчик намеренно завышает часы по задаче, в моей практике встречаются редко. Наверное, потому что мы внимательно относимся к подбору команды и не только к hard skills. Мы уделяем большое внимание soft skills, и главное — можем ли доверять кандидату.
Модель с оплатой за фактически отработанные часы в принципе применима только тогда, когда есть взаимное доверие. Если не доверяете исполнителю и не уверены в его порядочности, то лучше не сотрудничать с ним.
На практике большинство случаев, когда разработчики начинают юлить по поводу затраченных часов, связаны не со злым умыслом, а с нежеланием признать свои ошибки и пробелы. Например, разработчик выбрал неоптимальное решение или невнимательно изучил ТЗ, и потом ему пришлось переделывать часть работы. Но признаться в этом сложно, поэтому находятся оправдания, почему задача «очень сложная, всплыли подводные камни, и быстрее это ну никак не сделать».
В общем алгоритм следующий:
— Экспертно выявить конкретные задачи, по которым фактические затраты значительно отличаются от прогноза (желательно заранее зафиксированного и оговоренного). Важно, чтобы задачи были предварительно декомпозированы.
— Запросить у разработчика письменные разъяснения, с чем это связано.
— Если разъяснения не убедительны, то обратиться за «вторым мнением» к эксперту, которому вы доверяете. Иногда достаточно личного опыта, если он ранее решал подобные задачи, иногда необходимо применить code review.
— Если мнение эксперта совпадает с мнением руководителя проекта, и часы кажутся завышенными, то с полученным бэкграундом выходим на личную встречу с исполнителем и просим устно рассказать о том, что же пошло не так. Применяем лучшие психологические практики, как вывести «на чистоту» (разработчики тоже люди, и профессиональных врунов среди них мало).
— Выясняем истинные причины, договариваемся о компромиссе и восстанавливаем доверие, либо больше не работаем.
Goodfellazz, Генеральный директор (CEO)
Time & Material — самая справедливая форма оплаты за разработку, на мой взгляд. У нас большой опыт веб-разработки по Fixed price. Это довольно непрозрачная схема, которая подходит только для простых шаблонных проектов. Любой более-менее индивидуальный проект по веб-разработке, например, с уникальным дизайном или функционалом, всегда выходит за пределы первоначальной сметы. Причина проста: вначале практически невозможно предугадать все нюансы, которые вылезут в процессе разработки или после запуска проекта. Поэтому фирмы-исполнители начинают закладывать риски в первоначальную стоимость контракта, часто излишне перестраховываясь. В итоге последующая разработка, так или иначе, переходит к оценке задач по затраченному времени.
Чтобы понимать врет или не врет подрядчик нужны:
1. Внутренний специалист. У вас должен быть технический специалист с опытом в профильном стеке и хорошим знанием проекта. Это практически половина успеха. Мы как команда, которая любит прозрачную работу, обожаем проекты, где есть знающий человек со стороны Заказчика, с которым можно разговаривать на одном "техническом" языке. Такой человек понимает, сколько примерно времени можно потратить на ту или иную задачу, а также знает, как правильно ставить задачу разработчикам. Порой много времени тратится впустую именно из-за неправильной постановки задач.
2. Тайм-трекер. У всех должен быть тайм-трекер. Мы пользуемся Планфиксом для ведения проектов. Там есть удобная аналитика потраченного времени и тайм-трекер. Мы долго приучали каждого разработчика трекать время и давать корректные оценки по времени. Благодаря этому заказчик может на любом этапе разработки получить отчет по потраченному времени. Для этого мы даем ему гостевой доступ к задаче, где трекают время все наши разработчики.
3. Доверие. Без него никуда. Поищите отзывы, попросите дать контакты предыдущих заказчиков, которые могут дать рекомендации. Соберите побольше информации. Но даже громкий бренд и куча положительных отзывов не смогут гарантировать успеха. Поэтому формула такая: "Доверяй, но проверяй". Иногда стоит довериться подрядчику как специалисту, чтобы не мешать и не тратить время на бесконечные обсуждения. Но при этом подрядчик должен понимать, что вы держите руку на пульсе. Перед началом разработки функционала, получите оценочную вилку ("от" и "до"). Потом промежуточный результат. Тогда сможете сравнивать, насколько "попадает" в свои оценки подрядчик. В процессе поймете, можно ли доверять.
4. Аудит. Нормальная практика. Закажите технический аудит (ревью) разработанного кода у сторонней компании. Они укажут на слабые стороны и потенциальные риски, если таковые будут.
Pitch
Все наши разработчики работают с трекером времени, который отслеживает количество часов, затраченных на задачи. Для нас это принципиально важно, таким образом мы можем анализировать продуктивность команды и общее количество часов по проекту, чтобы оценивать точность наших расчётов.
Перед запуском каждого спринта должна проводиться предварительная оценка по времени для каждой задачи. Если всё же возникают сомнения по добросовестности исполнителя, и кажется, что на задачу было заложено слишком много времени, то всегда можно попросить тимлида проверить объём работ и согласовать с ним эту оценку. Таким образом мы можем сразу предупредить риск работы с человеком, который ищет личной выгоды.
Другие вопросы
27 ноя 2024
Artox Media Digital Group, Group Head
Panda Ads, Генеральный директор (CEO)
MDA-company, CEO
21 ноя 2024
Пиробайт, Генеральный директор (CEO)
Migra, Менеджер по развитию бизнеса (BDM)
2L Agency, Аккаунт-менеджер
12 ноя 2024
Panda Ads, Генеральный директор (CEO)
PHPDev.ORG, ПиЭйчПиДев.Орг
Advertalyze, Директор по развитию бизнеса (CBDO)
+2
