1. Эту проблему я решаю предварительным эстимейтом задачи с декомпозицией. Если оценка превышает запланированную более на 30 процентов, то разбор полетов в привлечением тимлида с моей стороны. Таким образом я не допускаю имитацию бурной деятельности и мону ежедневно контролировать прогресс крупной задачи, смотря на то как двигаются подзаадчи
2. Почему не влияет? Допустим вы платите специалисту 150 тысяч. Этот специалист может в месяц сделать проект за миллион, может сделать за 300 тысяч, а может сделать задач на проданную сумму меньше чем его зарплата. Вам было бы неинтересно узнать сколько разработчик заработал для компании? Вы бы хотели держать спеца, который даже не может заработать себе зарплату?
3. Интересная мысль, спасибо. Подумаю как использовать.
4. Аналогично с п.3)
1. Да, и причины сопротивления которые я выявлял:
- Неудобный трэкер - это было в моей прошлой организации, где внедрялся Битрикс 24. Объективно это была неудобная система с точки зрения UX - мелкие кнопки, формы для заполнения времени.
- Невозможность декомпозировать свою работу на подзадачи. Есть типаж разработчиков, которые параллельно работают над 2-3 задачами одновременно в проекте перескакивая между ними во время кодинга
- Отказ по этическим соображениям. Некоторые разработчики смотрят на свою работу как на творчество, которое не может поддаваться исчислению. Один раз мне пришлось даже расстаться с таким разрабом. Он нашел продуктовую компанию, где в отличие от аутсорса нет такой гонки за часами.
2. Расчет маржинальности, расчеты с заказчиком на разработчика не перекладываются. Это делает менеджмент на основании данных, которые берутся из тасктрэкера
У меня встречный вопрос - каким другим способом менеджер может получить данные по часам? Мне лично единственной альтернативой видится скринкасты и их просмотр. НО как по мне это гораздо более худший вариант, чем самостоятельное ведение трэкера
Нет, ты получишь меньше, столько сколько потратил на задачу
Я понимаю куда вопрос идет) в моем подходе разработчик получает столько денег сколько потратил на задачу. Я предвижу вопрос "а зачем мне стремиться делать быстрее, если я не заработаю с этого". Я прав?
Вопросы 1 и 2 - за выполненные задачи. СТоимость выполненных задач измеряется в часах, которые были затрачены на разработку
Вопрос 3 - оценку задач осуществляют непосредственно разработчики на этапе планирования и декомпозиции перед началом спринта. Задачи бьются на подзадачи объемом до 4 часов. Соответственно ориентир идет на оценку, которая указана в подзадачах при планировании
а почему по вашему удаленка и трекинг несовместимы? Меня беспокоит не вопрос работы с "9 до 6", речь идет о сумме часов затраченных на задачу и сроках ее выполнения. Если разработчик продуктивно поработал 12 часов и принес импакт в проект, то почему бы и не заплатить за это
Sanes, почему вы так думаете. Я готов оплачивать и оплачиваю как непосредственно кодерство, так и непрофильную активность (ведение отчетов, декомпозиция задач, митинги и т.д.)
Я лично трекеры использую:
1. Подсчет времени для расчета со сдельщиками
2. Оценка маржинальности проекта
3. Накопление исторической базы для моделирования статистических методов оценки, типа Монте Карло
4. Понимание того как разработчик умеет делать оценку
По поводу оплаты по трэккеру - я так и делаю с фрилансерами или сдельщиками. Проблем намного меньше с ними, но все равно имеются кейсы, когда фрилансеры тоже забывают трэкать время
Отвечу на вопрос про организацию кодовой базы. Есть репозиторий, куда разработчики добавляют свой локальный код. В моем кейсе разработчик удалил свою локальную ветку.
У нас задачи ставятся в виде пользовательских историй, которые перед началом работы, разработчики сами декомпозируют на таски и именно таски оцениваются в часах самим разрабом. И тот разраб, про окторого я писал на форуме, закрывает эти таски на 30-40 часов, отсюда и низкие результаты, меньше выполненных задач.
Есть трудовой договор, в котором оговаривается 8-часовой рабочий день
boss_lexa, спасибо за наводящие вопросы! Отвечаю:
Паспорт у владельца - Россифйская федерация, фирму под приложение не зарегистрирована
Основная масса денег идет исполнителям, само приложение получает комиссию с каждой сделки
Речь идет о стартапе, сейчас нужно что-то попроще для старта
Прокомментируйте еще такой момент: все говорят о том, что кроссфункциональные команды зло. Я сейчас книгу читал Scrum from trenches, так там наоборот такие команды описываются. Ну и с точки зрения Scrum команда должна быть кроссфункциональная. Что это за противоречие?
Поясню по ситуации. В нашей конторе до моего прихода отсутствовала должность проджекта. До этого эта роль выполнялась одним из членов команды по совместительству - например, на моем проекте это был дизайнер. Меня поставили на проект по середине спринта, когда скоуп задач был определен самими разработчиками. Сегодня я посмотрел на доску и понял, что далеко не все таски из скоупа будут выполнены. Вот я и задался вопросом как поступать в таких случаях.
2. Почему не влияет? Допустим вы платите специалисту 150 тысяч. Этот специалист может в месяц сделать проект за миллион, может сделать за 300 тысяч, а может сделать задач на проданную сумму меньше чем его зарплата. Вам было бы неинтересно узнать сколько разработчик заработал для компании? Вы бы хотели держать спеца, который даже не может заработать себе зарплату?
3. Интересная мысль, спасибо. Подумаю как использовать.
4. Аналогично с п.3)