если не знаешь, сколько примерно времени нужно выделять разрабу на ту или иную задачу, чтобы не трястись с секундомером за его спиной — то это не его проблема, а твой косяк
.
Из вашей цитаты я понял, что оценка - это только зона ответственности менеджера и я как менеджер, не должен к ней привлекать разработчика. Я правильно вас понял или нет?
Допустим, вам повезло с менеджером, который вышел из разработчиков. И он может дать адекватную оценку в своей предметной области
А если менеджер ранее был разработчиком в другом стэке, техеологии? Вы готовы укладываться в дэдлайн, который был поставлен сверху менеджером, не разбирающимся в вашем направлении?
Robur, неудобный трекер: - значит он напрягает людей, чтобы они согласились с этим напрягом им нужна причина.
невозможность декомпозировать работу - трекер прямо влияет на рабочий процесс - и это напряг на порядок больше опять же нужна причина для того чтобы этот напряг в глазах разработчика оправдать.
Я полностью с вами согласен. Боле того, я сам откажусь работать в компании, где используются неудобные инструменты для работы, чтобы самому не работать с ними. Да и внутренние тормоза не позволяют навязывать говно другим
Как вы замотивировали людей согласиться на эти напряги и объяснили их необходимость? "нам в менеджменте очень, ну очень нужны эти данные"? Вам нужны - отлично, а зачем это им?
Если незачем то расклад простой - они напрягаются, вы что-то за это получаете. Это вы не победите никогда, даже если вам будут делать эти отчеты, они будут формальными, вы никогда не узнаете там такие цифры потому что все так и есть или просто разработчик вам их сделал как получилось потому что вам они нужны. Я это наблюдал своими глазами и не раз - и понимая зачем менеджерам эти отчеты, даже как-то было их жалко - на изначально плохих данных хороших выводов не сделаешь.
Я прислушаюсь к этой мысли, спасибо за нее
- введите скринкасты и потеряете всех более менее толковых разработчиков. Без вариантов. Согласен - это стопроцентная демотивация разработчиков и головная боль менеджменту. Фактически, ты не занимаешься управлением, а целый день смотришь картинки, в которых все равно мало что понимаешь
- есть автотрекеры типа Rescue Time - они пытаются собирать данные в фоновом режиме в формате "поставил и забыл". Естественно по задачам никакой разбивки не будет Не подходит, так как я не смогу понять по нему над какой именно задачей возникла проблема
- если у вас так супер-важна оценка выполнения задач почасам, то странно, почему для разработчика в этом нет совершенно никакой важности. Тут что-то не так. Если ваши часы-метрики не увязаны с реальным рабочим процессом (а они повидимому не увязаны), то вопрос что вы в них вообще надеетесь увидеть
вариантов "как все исправить" я вижу два:
1. изменить рабочие процессы так чтобы то, сколько часов потрачено на каждую задачу имело значение на уровне самой разработки. Тогда разработчики или будут сами это хотеть делать, или будут понимать зачем это надо и легче пойдут навстречу.
2. изменить систему оценки процессов, метри и прочее чтобы оценивать это как-то по другому, ближе к рабочему процессу.
De1mos, искренне рад за вас. Я тоже считаю, что в таком случае разработчику и компании не нужно мучать друг друга. Если разработчику некомфортно работать с таймменеджменетом, то лучше ему найти компанию без него и не ломать свои внутренние установки
Antonio Solo, да, я некорректно выразился. Разработчик непосредственно создает продукт, менеджмент управляет, распределяет, продает этот продукт, владелец бизнеса получает прибавочную стоимость. "Капиталл" Маркса нам в помощь)
Если перефразировать мой предыдущий ответ Сергею: я, как менеджер, не могу допустить ситуацию, чтобы в течение полугода разработчик в полную силу не был задействован в создании продукта(-ов). Мне необходима система, которая позволит как можно быстрее это выявить и исправить.
Оценку я делаю под конкретного разработчика. Если над проектом будет работать "медленный Вася", то соответственно оценка будет взята с этого "медленного Васи"
"- не вижу смысла, ни разу не разбирали сколько был эстимейт и сколько заняло, а больше применения найти не могу". Полностью согласен, возьму на заметку
"- достоверно это делать сложно, сложно даже достоверно статус задач поддерживать, (собственно на него и ориентируюсь, заполняя задним числом, но иногда откровенная лажа получается и тогда просто "рисуешь" правдоподобную картину)". Вообще не согласен. Что вам мешает в работе поддерживать статус задач?
"- джира неудобный инструмент для этого, удобного вообще не нашёл". Отчасти согласен. Это наименьшее зло на рынке. Для логгирования я использую плагин Tempo к джире, который имеет и планировщик и удобные таблицы для расчетов в работе.
Тогда вопросов в этом треде нет. У меня, к сожалению, неограниченных бюджетов и таких лояльных заказчиков не имеется. За вас я могу только порадоваться
Сергей Горностаев, дело может быть не только в самом разработчике. Например, для разработчика может быть нехватка задач, проектов, плохая аналитика, недостаточно полные баг репорты, большое количество митингов и т.д. И если я вижу, что разработчик закрыл например, 30 часов, то это говорит о том программист работает неэффективно или его задействуют неэффективно. А дальше, после того сигнал получен, нужно разбираться и решать проблему
Я смотрю на это с точки зрения директивного менеджмента. Я плачу деньги разработчикам и хочу чтобы организации работы соответствовала мои требованиям. Если разработчик хочет "просто писать код", то ему стоит найти другую компанию, либо работать только над опенсорс и пет-проектами.
По вашей логике я должен постоянно должен убеждать делать работу, за которую плачу деньги?
Низкая эффективность разработчика может быть связана со множеством факторов - менеджмент не загрузил задачами, нехватка проектов, плохо написанные требования и т.д.
Сергей Горностаев, вы фактически мне предлагаете платить полную зарплату 3-6 месяцев разработчику, который неэффективно работает. Я лично не могу потратить 300-900 тысяч на содержание сотрудника, который не приносит прибыли в течение полугода
Допустим я прислушался к вашему совету. Но без трэкинга спустя пол года как я буду принимать взвешенное решение? Без объективных метрик мои решения будут основаны только на эмоциях, интуиции и последнем впечатлении
Мне интересно следующее:
1. Такой подход к планированию вы используйте только на ТМ контрактах?
2. Как вы объясняете разработчикам, что вы подразумеваете под "комфортным" временем?
3. Вы всегда закладываете риски 100 процентов?
По поводу оплаты я согласен с вами: я готов платить программистам и за некодерскую активность - митинги, отчеты, созвоны и т.д. Это и мотивирует меня бережно относиться к их времени
В теме я писал о том, что у меня стоит проблема, которая заключается в том, что часть разработчиков не трекает время ВООБЩЕ либо делает это с большими лагами задним числом
Из вашей цитаты я понял, что оценка - это только зона ответственности менеджера и я как менеджер, не должен к ней привлекать разработчика. Я правильно вас понял или нет?