На исследовательские задачи выделяем время пощупать, чтобы понять на сколько сложно. Условно договорились, что к концу дня исполнитель сообщит менеджеру, что удалось сделать и появилась ли какая-то ясность.
Вы правы, бывают проекты, где внедрение даже небольшой функции может привести к его перелопачиваннию. Разработчик перед задачей изучает проект, если видим, что можем утонуть, то закладываем больше буфера + предупреждаем об этом заказчика.
Можно автоматом трекать, можно вручную. За этим не следим)
Разработчик может врать менеджеру, возможно, менеджер даже несколько таких враков не заметит. Но если старшие разработчики и тимлиды, которые затем на это укажут.
Наша система не надзирательная, а как раз наоборот. Помогает развивать эффективность)
Мы всегда добавляем. Не 150%, правда. Но буфер закладываем. Разработчик может в оценку добавить буфер, когда задача для него новая. И менеджер заказчику буфер тоже добавляет.
Но бывают ситуации, когда и с этими условиями выходим за рамки. Разбираем, делаем выводы.
А вы что используете?
Благодарю за совет и лестную оценку :)
Так и у нас, разработчики оценивают задачи)
Иногда не апрувит, да. Но тут переубеждает не значит, что на черное говорят белое)
Это аргументировано. И сотрудник также может аргументировать. В споре рождается истина)
Вероятно, у него жизнь удалась :)
Оцениваем и биллим. Заказчик оплачивает эти задачи. Я написал условную ситуацию, когда совсем ничего непонятно.
А так предварительно декомпозируем, но понимаем, что может потребоваться больше времени.
На исследовательские задачи выделяем время пощупать, чтобы понять на сколько сложно. Условно договорились, что к концу дня исполнитель сообщит менеджеру, что удалось сделать и появилась ли какая-то ясность.
Вы правы, бывают проекты, где внедрение даже небольшой функции может привести к его перелопачиваннию. Разработчик перед задачей изучает проект, если видим, что можем утонуть, то закладываем больше буфера + предупреждаем об этом заказчика.
Спасибо за интересные вопросы)
Когда всем пофик, то ничего не поможет. А нам не пофик, поэтому работает) Конечно, иногда и филькины грамоты проскакивают, стараемся отслеживать
Да, есть минусы. Но они развиваются, может и это прикрутят)
Мы на основе их АПИ отчеты допилили, потому что их да, слабоватые...
А можно и в эксель экспортировать, есть же выгрузка)
Видать мы из красной книги)
Спасибо за ценное уточнение) Кайтен много чего умеет, да)
Можно автоматом трекать, можно вручную. За этим не следим)
Разработчик может врать менеджеру, возможно, менеджер даже несколько таких враков не заметит. Но если старшие разработчики и тимлиды, которые затем на это укажут.
Наша система не надзирательная, а как раз наоборот. Помогает развивать эффективность)
У нас все также демократично) Можно уйти раньше, а затем задержаться.
Нам даже 100% попадание в оценки не важно. Если +- 20% попали, то все супер.
И переработать можно, это тоже оплатят)
Наверно, я слишком строго все в материале описал. Но хотелось показать конкретный пример, а все «если» в каждой компании свои.
«Люди и взаимодействие важнее процессов и инструментов»
Понял) Сильно напали в комментариях, френдли фаер))
Мы всегда добавляем. Не 150%, правда. Но буфер закладываем. Разработчик может в оценку добавить буфер, когда задача для него новая. И менеджер заказчику буфер тоже добавляет.
Но бывают ситуации, когда и с этими условиями выходим за рамки. Разбираем, делаем выводы.
Хочу вашему комментарию поставить 10 плюсов, но карма и на 1 закончилась :)
Цель не наказать, а как раз разобраться, где недоглядели. И менеджеры, и разработчики.
Я планировал, так как сам был исполнителем. Но никто не стучал. Цель не настучать, а научиться декомпозировать и планировать задачи.
Мы как раз мотивируем, а не наказываем. Но подсчет часов нам необходим, так как разрабатываем проекты для заказчиков по ТМ.
Хм, а мы вот пробовали, но были разочарованы. Но было это давненько) Если сейчас изменилось в лучшую сторону, то ради интереса потестим)