Комментарии 160
К примеру, если изначально мы запланировали 100 часов, но по итогу проработали 130, значит что-то пошло не так — проект нерентабельный, есть проблемы в работе или сотрудники работали неэффективно и т.д.
и заметьте, вопросов к запланировавшим 100 часов у них нет, а только к сотрудникам...
а запланировали бы 50 то и тем более сотрудники не эффективны? А проблема на самом деле в том, что планирующие часто очень мало в чем разбираются, кроме "скрам-мастерства" и тому подобного хлама
Что вы предлагаете?
? Не верить искуственно сформированным метрикам и KPI в каком то софте, а больше работатать и общаться с непосредственными исполнителями задания?
Спасибо за совет, наверное я сильно быканул в комментарии, раз столько минусов :)
Я привел сразу несколько причин в статье, и как раз «есть проблемы в работе» – это вопросы к запланировавшим, то есть менеджерам. Могли неверно организовать работы, плохо проработать бизнес логику и пр.
Планируют время на работу сотрудники, они предварительно оценивают задачи.
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
выяснить причину и скорее всего настучать по голове запланировавшему, потому что он наврал?
А запланировавший – это сотрудник, а не менеджер. Исполнители оценивают задачи. Ну не стучать же им по голове за то, что они не попали в оценки :)
Раз - не попали, два - не попали, на третий можно и постучать, точнее постараться понять почему ошибаемся с прогнозом.
Вот да, без стука только. Проводим ретро, анализируем задачи, разговариваем с сотрудником. Нет цели точно попасть в оценку. Есть цель грамотно планироваться)
Всегда, абсолютно всегда, добавлять к оценке разработчика от 15% до 150% (в зависимости от квалификации сотрудника и размера фичи которая оценивается). Исполнитель редко может предсказать технические риски в задаче (если только это не абсолютно типовая задача которую он делал уже несколько раз)
Мы всегда добавляем. Не 150%, правда. Но буфер закладываем. Разработчик может в оценку добавить буфер, когда задача для него новая. И менеджер заказчику буфер тоже добавляет.
Но бывают ситуации, когда и с этими условиями выходим за рамки. Разбираем, делаем выводы.
Мне больше всего понравился вариант эстимейта одного фрилансера..
время на разработку х2 от ожидаемого, дедлайн х4 от времени на разработку..
. Да, иногда перебор, но "в целом по больнице" довольно точно выходит ;)
Ну опытный исполнитель знает что всегда что-то может не так и не туда пойти и закладывается на такие случаи...
Все верно. Но бывают задачи с которыми впервые сталкиваются) Но опять же, это все закладывается и на такие задачи делается ресерч предварительно)
У меня лично таких задач - каждая вторая. Типовых давно уже не бывает (вот так чтобы специально, может быть какой-то типовой кусок в рамках другой задачи).
Просто сразу декомпозируешь, смотришь где какой алгоритм применить.
Хуже когда "на оптимизацию" - "этот модуль работает слишком долго, нужно чтобы работал быстрее". Там надо понять используемый алгоритм, выявить узкие места, придумать как изменить или использовать что-то другое. Но тоже оцениваемое.
Не поддаются оценке только "исследовательские задачи". Когда есть некая сущность, надо разобраться как работает, как использовать, понять преимущества и недостатки, оценить граничные условия применимости, если нужно - разработать удобное АПИ для широкого использования. Но это технические задачи, не проектные. Там нет жестких сроков как правило.
Знаете, участвовал я в планировании под руководством менеджмента.
И сроки там всегда были не реалистичные.
Либо руководитель не давил и сроки были оверпереоценены, в итоге команда не работала в полную силу.
Либо руководитель давил и под его давление сроки указывались не реалистичные и команда чтобы успеть перерабатывала и выгорала.
Ни тот ни другой подход не давали высокой эффективности. По сути задача мотивации и эффективности разработчиков не решается через контроль, она решается через мотивацию и заинтересованность. Можете разработчиков заинтересовать и мотивировать - они будут давать результат. Не можете - подсчет секундочек проведенных за компом не приведет к росту эффективности.
Если исполнитель оценил и не попал, тому могут быть вполне объективные причины.
Другое дело, если это систематически происходит... Значит просто не умеет еще - надо помогать.
Надо вам попробовать самому что-то запланировать, ошибиться и получить по голове, чтобы не возникало желания стучать другим. Но скорее всего вам по голове никто не настучит за ошибку.
Продолжайте работать так, как работаете. Вы все правильно делаете. Либо ваш подход разумен и тогда вы придёте к процветанию либо он идиотский и тогда вы сами себя похороните. В любом случае, как бы не оказалось, всем от этого будет только лучше.
У нас оценку времени принято доверять исполнителю. И, знаете, работает.
Сначала аналитику на его часть, потом разработчику на его.
Ну может быть только для совсем джунов оценку может сделать другой....
И вот почему-то не бывает ситуаций, когда задача на неделю, а исполнитель оценивает ее в месяц. Все достаточно честно (хотя разработчик немного всегда сверх закладывает на случай если какие-то сложности возникнут по ходу).
Вопрос адекватности менеджеров. Меня тоже смутил момент про неэффективность, но в целом, при нормальном использовании, понимать сколько времени было потрачено на задачу и сколько планировалось - это очень удобно. Это статистика на базе которой можно планировать и зачастую точнее, чем смогут это сделать разработчики. Я сам сталкивался с подобным, когда оценивал задачу в условные 4 часа, а менеджер говорил, что я что-то не учел, так как по статистики эта задача занимает условные 7 часов.
Но это надо, чтобы не было страха честно сообщать о затраченном времени. К этому не должны быть привязаны деньги. Тогда инструмент будет работать. В идеале, если при выходе за запланированное время, пишутся моменты о которых не подумали на планировании.
В идеале, если при выходе за запланированное время, пишутся моменты о которых не подумали на планировании.
Как учитывается психология работника которому поручили уcловное задание на планируемые 4-е часа, если он мыслит в рамках своего 8-ми часового рабочего дня? :)
(смогу/не смогу и тогда доделаю завтра/послезавтра ...)
P.S. Статистика в руках руководителя — это одно, а исполнителя, совсем другое.
Так же как и когда время никак не фиксируется. Если человек на постоянной основе на зплачи которые требуют полдня тратит по целом дню, то рано или поздно к не у появятся вопросы, ну или не появятся, но и роста зарплаты у него не будет.
Плюс задача не одна, есть очередь, так что закончив одну четырех часовую задачу, можно перейти к другой. Тут уже задача руководителя обеспечить работника работой на полный рабочий день. Тут все очень сильно зависит от руководства. К тому же всегда был вариант сегодня уйти пораньше, что не бросать на середине следующую задачу, а завтра поработать подольше. Ну и в целом, тому чтобы доделать следующую задачу способствовало то, что переработки в пределах, вроде, 15% от рабочего времени оплачивались автоматом по трекеру. И в целом всех всё устраивало.
У нас все также демократично) Можно уйти раньше, а затем задержаться.
Нам даже 100% попадание в оценки не важно. Если +- 20% попали, то все супер.
И переработать можно, это тоже оплатят)
Наверно, я слишком строго все в материале описал. Но хотелось показать конкретный пример, а все «если» в каждой компании свои.
«Люди и взаимодействие важнее процессов и инструментов»
Ему не поручили на 4 часа задачу)
Как происходит:
1. Появляется задача, ее описывает аналитик.
2. Разработчик вместе с аналитиком и менеджером обсуждают задачу, чтобы все ее правильно понимали и не изобрели велосипед.
3. Разработчик декомпозирует задачу и проставляет оценку. При этом разработчик всегда может обратиться к старшему разработчику, если есть какие-то вопросы.
4. Менеджер апрувит оценку вместе со старшим разработчиком.
Получаем, что задача декомпозирована и оценена. Если при ее выполнение идет что-то не так, то разработчик сообщает менеджеру и команда это разбирает.
У нас все по доброму)
Приятно такое читать, на самом деле. Молодцы!
4. Менеджер апрувит оценку вместе со старшим разработчиком.
Всегда и любую? Или иногда не апрувит и переубеждает? ?
Так и есть! Спасибо за ваш комментарий)
У нас нет цели наказать, а цель грамотно планироваться. Чтобы разбирать задачу, декомпозировать ее, на этапе планирования понимать, какие могут быть подводные камни.
Никто рублем не накажет, а наоборот разберут ситуацию вместе с менеджером и тимлидом)
В скрам-мастерстве планируют время те же люди, что и код пишут (сотрудники). Это одна из основных идей.
Так и у нас, разработчики оценивают задачи)
а кто иначе оценит точнее трудозатраты экспертов как не сами эксперты ) задача руководителя провести дополнительные оценки и риски, например, если для выполнения задачи нужно ждать решение соседнего отдела или вышестоящего подразделения, или вообще каких-нибудь внешних исполнителей (типа поставщиков или подрядчиков)
Использовал Trello для личных целей. Очень было досадно, когда получил "письмо счастья". Немного посмотрев, что есть на рынке из отечественного (с возможностью переезда карточек и закладок), выбрал WEEEK. Переезд и перенастройка заняли от силы час.
Пока полёт нормальный, нареканий нет.
Учётку в Atlassian снёс после этого сразу, и пусть идут лесом! =)
Да, переезжать сразу стоило. Некоторые сервисы без предупреждения со всеми данными доступ отрубили
Я тоже на WEEK перешел - пока всем очень доволен. Особенно радует интуитивно понятный интерфейс и максимально упрощенный онбординг. Бесплатный тариф закрыл все, что было нужно для личного планирования задач (подозреваю, что в командах работает так же хорошо).
Никакой слежки за сотрудниками – это принципиальная позиция. Считаем эффективность по скорости команды в целом: есть такое понятие velocity, за единицу расчёта берем story point. Это намного гибче, проще и в итоге точнее получается, чем считать часы. Разработчик участвует в оценивании задач на planning poker. Оценки даём качественные, а не количественные. Для гибкого планирования этого достаточно. И в итоге ошибок гораздо меньше.
У сервиса Аванплан есть импорт из Jira и Trello, в том числе импорт оценок задач в SP. Все проекты и задачи импортируются быстрее, чем за минуту (мы переезжали из Redmine c 2500 тыс задач). Есть веб-версия и мобильное приложение iOS, Android. Есть оценки в сторипойнтах, есть расчёт скорости команды, есть прогнозы по дате завершения на основе этой скорости, удобные дашборды не для галочки, а исходя из помощи в планировании и отслеживания прогресса.
Самое полезное для меня лично — это я смог импортнуть свои личные задачки из Trello, а рабочие из Redmine и теперь на одном дашборде мне подсказывают успею ли я до конца недели все свои задумки сделать как по работе, так и по дому. Раньше я пытался это как-то в OmniFocus сводить. Но у него не было интеграции именно с трекерами задач.
Покер проводим в Retrius — также российская разработка. Там же можно провести ретро или мозгоштурм при необходимости. Заставляет не расплываться мыслью по древу и придерживаться повестки. Собрания у нас теперь в два раза короче получаются. Народ доволен.
Кайтен неплох для тех, кто привык именно к Trello. Но пользоваться трелло именно для разработки как по мне — один из первых этапов зрелости команды. С ростом зрелости и опыта уже слишком тесно становится в трелло.
Это не слежка :)
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
Конечно, ресурсы надо отслеживать и планировать, это понятно. Я за то, чтобы по возможности не взваливать вопросы ресурсного планирования на разработчиков. Они не могут и не должны точно оценивать в часах. Но оценку вообще они должны давать, без этого никуда. Поэтому придумали эту хитрость с оценкой качественной (просто-сложно-нереально) вместо количественной. А количественная (уже в целях ресурсного планирования) появляется в отчетах, которые в хороших системах делаются автоматически. В том числе и форму Т-13 заполнить и т.д., чтобы и бухгалтерия была довольна, и заказчику можно было бы объяснить смету, если ему так привычнее. Хитрости эти придумали очень давно, называются они Agile, Scrum и иже с ними. И заказную разработку тоже можно так делать. Вопрос в целесообразности, готовности команды и бизнеса к этому. Редко кто сразу начинает именно так работать. Обычно это долгий и тернистый путь)
Вы продвинулись не мало за несколько лет. У вас есть отчетность, вы планируете — большинство даже этого не делают.
кстати, кайтен «умеет» оценивать в сторипоинтах и в «майках» и в часах (вшитое поле Размер)… в теории (для бухов и заказчиков) можно сделать конвертор сторипоинтов (или маек) в часы, у кайтена есть кастомное поле «формула» с которым оч много всего можно делать.. и покер-оценка у них есть..
пишу не для автора (уже и так знают), а кто пока ещё выбирает трекер.. )
У ваших сотрудников почасовая оплата с динамической ценой часа?
Если нет, то это подмена понятий, вы ведь просто продаете часы сотрудника компаниям, все, что вам "необходимо" в таком случае, это продавать часы в нужном соотношении. Причем тут вообще сам сотрудник?
Мы продаем разработку проектов, а заказчик оплачивает часы затраченные на проект.
Эффективность у нас – это отношение запланированного СОТРУДНИКОМ времени на затраченное им же.
Чтобы мы понимали, попадаем ли мы в оценки, а если нет, то разбираем почему.
Мы продаем разработку проектов, а заказчик оплачивает часы затраченные на проект.
Заказчик у вас оплачивает часы, а не готовый продукт? Повезло вам с заказчиком :)
Это подмена понятий.
Разработчик не может эффективно заниматься несколькими проектами сразу, покупает ваша контора часы пакетами, продает тоже пакетами, в сути вашу контору интересует только количество проданных часов и продажа часов подешевле за подороже.
Эффективность проекта это кол-во потраченных денег на кол-во полученных, то, что вася думал проект займет миллиард часов, а занял неделю никак не повлияет на затраты сторон.
Соответственно должна измеряться эффективность проекта, а не сотрудника. Тк эффективность сотрудника давно известна из его цены.
Зачем оплата часа? Оплата за результат. Который есть "функционал в срок". Сколько часов потратил - его проблемы.
Два разных сотрудника с разной квалификацией могут на одно и то же потратить разное время. Но результат один и стоимость его должна быть одинаковой.
Есть и такой формат работы, как вы описали. А если заказчик оплатил 100 часов, а сделали задачу за 10? Вернуть 90 часов?
При разработке сложных продуктов есть много подводных камней, которые сразу не учесть, поэтому мы работаем по Time & Material. То есть заказчик оплачивает фактически затраченное время на задачу.
Заказчик не оплачивает часы. Он говорит "мне нужно вот это". Мы отвечаем - "стоит будет столько, через полгода система будет развернута на объекте и на 100% работоспособна в рамках оговоренного функционала". Это контракт. Как сы его будем выполнять внутри - это наши заботы. Тянуть со сроками и давать заведомую переоценку не в наших интересах. Нам интересно выполнить один контракт и взять другой.
Недооценивать сроки и выкатывать недоработанную или недотестированную систему - тоже не в наших интересах. Это репутационный ущерб.
Так было когда в промавтоматизации работал. Сейчас банк (центральные серверы). Тут если с архитектурой накостылишь, можно очень большие проблемы с интеграцией получить, что приведет к такому ущербу, что мало не покажется никому. Так что тут еще жестче - есть ОТАР (Организационно-Техническое Архитектурное Решение), когда он согласован всеми - все. Выделяются ресурсы, бюджет, определяются сроки.
Если заказчик что-то захотел поправить - задача снимается и все с начала. При этом после пересогласования она может сдвинуться по времени, например, на конец следующего квартала. Поэтому заказчики (бизнес-подразделения) все это понимают и стараются свои хотелки сразу формулировать в максимально полном и конкретном виде.
Звучит круто)
Но мы работаем Т&М, потому что иногда все хотелки сразу и максимально не собрать. Сделали какую-то функцию, смотрим на нее, ага. Вот тут лучше было бы так сделать, а вот это вообще убрать.
Ну и бюрократии меньше)
Но мы работаем Т&М, потому что иногда все хотелки сразу и максимально не собрать. Сделали какую-то функцию, смотрим на нее, ага. Вот тут лучше было бы так сделать, а вот это вообще убрать.
К сожалению, такой подход (на мой взгляд) приводит к очень плохой архитектуре приложения и куче костылей. Потому что когда я (к примеру) думаю как что-то релаизовать, то разбиваю это на несколько взаимисвязанных подзадач, и выстраиваю наиболее эффективную архитектуру приложения исходя из того что каждая подзадача будет реализована именно так и никак иначе, а связи между ними будут именно такими и никактми иначе.
Если все начинаешь меня в процессе - все или сыплется или обрастает куче костылей превращаясь в хлипкую дендрофекальную конструкцию.
Увы, но это опыт многих лет в разработке. Когда-то, да, начинал именно так - скорее что-то сделать, детали додумаем походу. Плюс "О! Вот еще в голову пришло, сейчас добавим!". И получалась полная фигня.
Внутри карточки можно посмотреть, отработал ли конкретный сотрудник норму часов за неделю и чем именно он занимался
Норма часов? Во-во, натуральный мини-ФСБ. Если это фиксируется автоматически, то даже и тут можно обмануть при желании (самое тривиальное - смлтря блокбастер, двигать мышку каждые N минут, чтобы копм не погасил/заблокировал экран). А если время ставится вручную, что мешает всегда делать "8 часов в 30 минут" в день?
Насчёт эффективности - очень, очень часто можно сильно ошибиться а оценке трудоёмкости, особенно при багфиксах или неочевидных с точки решения задачах.
Ну почему ФСБ(
Выше уже писал, что мы занимаемся проектной разработкой, работаем с заказчиками по ТМ.
Мы предварительно оцениваем задачи с разработчиками, затем согласовываем стоимость задач с заказчиками, а если что-то пошло не по плану? Должны обосновать, почему задача заняла больше времени, чем мы планировали.
Но все это не только для отчетности, как вы могли понять из статьи)
Не очень понимаю, что такое проектная разработка. Проектом можно назвать любую задачу. И не знаю, что такое ТМ.
Проектная разработка, если сильно упростить – это когда разрабатывается конкретный функционал под задачи заказчика.
ТМ – time & material, формат оплаты, когда заказчик оплачивает фактически затраченное время на разработку.
Несколько странный подход. Никогда не сталкивался с таким.
Сколько работаю (а профессионально в разработку ушел где-то в 1991-м году), всегда было "создать оговоренный функционал в оговоренный срок за оговоренные деньги". Т.е. заказчик оплачивает конечный результат, а не количество часов за компом.
Естественно, предусматриваются штрафные санкции за срыв сроков. И естественно сроки есть продукт взаимной договоренности и опираются на нашу оценку. Если заказчику нужно быстрее чем мы можем - тут отдельный разговор.
Но когда все согласовано - тут уже наша забота чтобы в срок уложиться. Хочешь днем спи, ночью работай, хочешь наоборот. Главное - уложиться в срок.
Работал где-то над 5 проектами с оплатой time & material.
Вы пишете про "создать оговоренный функционал в оговоренный срок за оговоренные деньги", а в тех проектах нет оговоренного функционала. Точнее как — есть высокоуровневые хотелки, но никто, ни заказчик, ни исполнитель, ни интегратор не знает как именно мы будем реализовывать хотелки. То есть функционал описывается и документируется прямо по ходу разработки. Если ещё больше упрощать — мы делаем демо, показываем заказчику, а он говорит что дальше — то ли оставляем, то ли выбрасываем и делаем всё с нуля.
Точнее как — есть высокоуровневые хотелки, но никто, ни заказчик, ни исполнитель, ни интегратор не знает как именно мы будем реализовывать хотелки. То есть функционал описывается и документируется прямо по ходу разработки. Если ещё больше упрощать — мы делаем демо, показываем заказчику, а он говорит что дальше — то ли оставляем, то ли выбрасываем и делаем всё с нуля.
С таким давно уже зарекся связываться. Ничего хорошего из этого не получается. Любой мало-мальски сложный проект требует архитектурной проработки. В описываемо вами случае это нереально - вы строите одну архитектуру, в результате получается что-то совсем иное. Все это приводит к лютому костылингу.
Поэтому работаю только там, где все оговаривается заранее на берегу с составлением BRD (бизнес-требования заказчика). Дальше - архитектурное решение, FSD, разработка, тестирование, внедрение.
Тогда получается эффективный продукт без внутренних противоречий который потом можно нормально сопровождать (у меня "в портфолио" есть продукты, которые внедрены в конце 90-х и все еще сопровождаются без проблем. А уж объектов, где наша система устанавливалась в 10-15-м годах и все еще работает и поддерживается, более чем.
Правда, долгое время основная область была промавтоматизация. А там и железо и софт вместе. И если о чем-то договорились и сделали железо (контроллеры), а потом заказчик переобулся в воздухе, ему сразу предложат выкупить то железо что уже сделано (и самостоятельно отнести его на помойку), а потом еще раз оплатить разработку и изготовление нового. Желающих оплачивать каждый свой каприз по отдельному прайсу, почему-то, не нашлось ни разу.
Всё так, просто я работаю в куда более гибкой бизнес-среде — ecommerce на php ?.
И у нас для заказчика откатить всё назад и сделать с нуля — это потеря, скажем, 40-50 тысяч долларов, что ощутимо, но не прям конец всему. Полагаю, что если бы их потери считались бы в миллионах долларов — то и подход был бы другой.
А ещё с T&M бывало такое, что мы просто не доводили проект до конца. То есть сделали этап 1, заказчик посмотрел и сказал, что ему хватит, устроит как есть. И тогда получается, что они даже экономят по факту, так как время на согласование требований, архитектурное решение и т.д. не было потрачено впустую.
А это цифры по какому курсу?)) Мы тоже хотим в эту бизнес-среду))
Даже если работать по фикс, то не берет же исполнитель сразу за весь проект стоимость, а по этапно. Аналитика, дизайн, разработка, условно. Что тоже позволяет не завершать прям весь проект)
Это не по курсу, я в американской компании работаю и на американский рынок. Про нынешнюю не могу говорить, а вот прошлая контора, где работал до 2021 года брала с клиента примерно $150-180 за 1 час разработки.
Но тут нюанс — это именно что чистый 1 час, то есть часы всех других отделов не связанных с разработкой (а это всё администрирование, все внутренние проекты, и так далее) должны окупаться за счёт отдела разработки.
Ещё могу поделиться инсайдом — до продажи компании чистая прибыль с одного часа выходила примерно $10 до налогов. Трудилось около 160 человек в 4 странах. Потом компания стала дочкой WPP, и сотрудникам перестали расскрывать внутреннюю кухню бизнеса.
Аналитика, дизайн, разработка, условно. Что тоже позволяет не завершать прям весь проект)
Да, тоже верно.
Помоему это и есть ключевой аспект решаемых задач: почасовая оплата требует какого-то вразумительной фактуры для отчёта перед заказчиком.
Все верно)
Вот только оценка задачи не должна ложиться на плечи разработчика. А то получается так, что у вас вроде и аналитик есть, но почему-то разработчик в итоге получает по жопе, что как-то неправильно. Часы это прошлый век, всё можно посчитать и по agile, а грамотный менеджер может и от story поинтов рассчитать бюджет.
Насчёт эффективности - очень, очень часто можно сильно ошибиться а оценке трудоёмкости, особенно при багфиксах или неочевидных с точки решения задачах.
Вот как раз для таких случаев и хорошо иметь статистику, что на этом проекте заменить описание - это 10 минут, а вот на этом 2 часа.
Статистика, более качественное планирование. Но при условии, что менеджмент адекватный, и срыв сроков - это повод задуматься, что недоглядели, чтобы в будущем заложить на это время, а не претензии к сотрудникам, что они плохо работают.
Самое сложное построить доверительные отношения, чтобы не было и такого, что сотрудник не успевает и в тихоня что-то в ночи доделывает, а потом рапортует, что всё ОК, в срок уложился.
Касается это не только того где время меряют буквально, но и где оценки идут в сторипоинтах. Заложили 3 сторипоинта, а в итоге получилось , что делали весь спринт, при средней скорости в 5 сторипоинтов.
Хочу вашему комментарию поставить 10 плюсов, но карма и на 1 закончилась :)
Цель не наказать, а как раз разобраться, где недоглядели. И менеджеры, и разработчики.
Звучит прекрасно, но "в дикой природе встречается крайне редко". )
У топикастера задача состоит в выжимании максимального профита с ресурса компании. Прям так и сквозит всей этой эффективностью.
А если время ставится вручную
Вручную, конечно. Разработчик без сомнения может врать, но по сути эта оценка не столько времени, сколько цены задачи. И если видно, что какой-то разработчик задачи делает очень дорого (или врёт или просто медленно работает), он первый кандидат на увольнение.
Можно автоматом трекать, можно вручную. За этим не следим)
Разработчик может врать менеджеру, возможно, менеджер даже несколько таких враков не заметит. Но если старшие разработчики и тимлиды, которые затем на это укажут.
Наша система не надзирательная, а как раз наоборот. Помогает развивать эффективность)
Попробуйте Яндекс.Трекер, после JIra глоток свежего воздуха. Причем они очень сильно шагнули вперед с первых релизов (тогда им вообще не возможно было пользоваться).
Если просто менять этот стек, то Eva позиционирует себя как замена. Если же со сменой хочется еще ускорить проекты и добавить ресурсное планирование, то в BIPULSE есть интеграция с Trello и Jira , но тут в нагрузку приедет и обновление методологии управления. (Управление проектами критической цепи (Critical chain Project management) и адаптация этого для Agile проектов)
А вы что используете?
Мы, как разработчики второго (Пульса), то его и применяем %))
Я лично пробовал давно другие решения, но там как без рук. Для простых ответов на вопросы (когда освободится сотрудник, задачи по сотрудникам) нужно городить какие-то хитрые отчёты вместо одного клика.
Некоторые Клиенты ставят Пульс в интеграцию в Jira/Trello чтобы видеть всю картину, а не разбитую по пространствам/доскам. Другие ставят вместо BigPicture/Structure, чтобы нормальное календарно-сетевое планирование поверх трекера было.
на фрилансе приспособил Кайтен как замену тайм-трекера, конечно с настоящими (типа Clockify, tmetric и т.п. ) нельзя сравнить, но основные функции выполняет (без экспорта в эксель):
ведёт проекты
считает время
считает деньги (доход)
строит итоговую таблицу, чтобы счета выставлять
А можно и в эксель экспортировать, есть же выгрузка)
да, есть выгрузки в эксель, есть хорошее апи… но, если уж мы платим немаленькие деньги за продукт, то хочется получать желаемое без лишних костылей заморочек ))
эксели и апи для чего-то более эксклюзивного или когда нет другого выхода )
иначе, зачем тогда продукт и такие деньги платить, если в экселе можно вообще всё делать!? ))
с помощью скриптов из гугловского экселя можно сделать вполне достойный трекер и даже получше многих платных на рынке ))
статья про Кайтен, потому скажу про него )
юзаем Кайтен меньше года, основные претензии:
не умеет автоматически включать таймер при перемещении в нужную колонку (чтобы запустить таймер надо открыть полную форму задачи, кликнуть пуск, кликнуть ок в модалке… капец)
очень «закрытые» отчёты… собственный (кастомный) построить нельзя (эксель не в счёт).. ОЧЕНЬ слабые возможности по кастомизации готовых (встроенных) отчётов (почти ничего нельзя сделать, кроме «пары» фильтров) и свой не сохранишь…
слабенькое разведение прав (но получше, чем у очень многих)… хочется 50+ пунктов ))
что радует:
от первого раза было ощущение, что это единственные ребята в мире, которые понимают в канбане )) … ни у кого не видел такое свободное управление досками, колонками, подколонками, дорожками с кучей настроек и автоматизаций
много автоматизации, которая в формах легко настраивается
хорошая интеграция с телеграмом
очень хороший набор типов для кастомных полей
работал в нескольких конторах, где вот так же «требовали» выработку, 40ч в неделю «вынь да положь»… и что? - если не хватало до 40 (киношки смотрел), то просто накидывали в задачи - таска делается 5мин, а пишут 1ч или переносили время на следующую неделю (если переработка)… все были «в одной лодке», потому лидам было глубоко пофик на такое…
наверно только бухам от этого хорошо, но никаких вменяемых выводов из такого учёта сделать невозможно, «филькина грамота»…
Когда всем пофик, то ничего не поможет. А нам не пофик, поэтому работает) Конечно, иногда и филькины грамоты проскакивают, стараемся отслеживать
Учёт потраченного времени целесообразен только в аутстафф/аутсорс конторах. Потому, что они продают часы и по ним нужно выставлять счета. Если же проект продается по фиксе, то важно не "сколько часов туда вбухали", а "за сколько времени проект сделали" и сколько календарного времени (в рабочих днях) потрачено на задачу. Потому что операционные затраты постоянно идут, и чем раньше будет сделан проект, тем больше выгода на экономии операционных затрат.
Но даже при просрочке проектов, эти компании научились "отбивать" все увеличения сроков доп. соглашениями.
Все правильно говорите)
Но с другой стороны, когда мы реализуем проекты с оплатой за часы, то в этот момент заказчик начинает считать "за сколько времени проект сделали". И если экономика не сходится, то он уйдет к другим.
Поэтому это одна из мер, которая позволяет делать проекты в рыночные бюджеты, а не заливать дыры доп часами)
А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.
На исследовательские задачи выделяем время пощупать, чтобы понять на сколько сложно. Условно договорились, что к концу дня исполнитель сообщит менеджеру, что удалось сделать и появилась ли какая-то ясность.
Вы правы, бывают проекты, где внедрение даже небольшой функции может привести к его перелопачиваннию. Разработчик перед задачей изучает проект, если видим, что можем утонуть, то закладываем больше буфера + предупреждаем об этом заказчика.
Спасибо за интересные вопросы)
2. В процентах показывать эффективность работы исполнителей.
Судя по картинке вы определяете "эффективность" как некоторую функцию от количества времени, которое сотрудник записал в поле "план", и количества времени, которое сотрудник записал в поле "факт".
Вы где-то посмотрели такое определение эффективности или сами изобрели?
Ещё подскажите.
Дарья планировала 5 часов оценивать задачи. И она записала, что 5 часов их оценивала.
Дарья молодец или не молодец?
Не то чтобы прямо молодец. Надо было записать что оценивала их 4 часа 50 минут. И план превышен, и возможность на следующем спринте его ещё раз превысить сохранена.
Это пока самая простая аналитика, которую можно собрать. Отношение планируемого к фактическому.
Если Дарья согласовала эту оценку и уложилась в нее, и результат работ соответствует ожидаемому (то есть декомпозировала все задачи и оценила), то конечно молодец.
Почему нет?)
Будет интересно почитать про процесс согласования. Дарья сообщает кому-то "Согласуй мне, пожалуйста, 5 часов на оценку задач". Её коллега или руководитель проводит какую-то работу и сообщает "Да, ок". При этом у двух человек появляются затраты времени на задачу "Согласование времени".
Это так происходит?
3. Формировать статистику всех сотрудников.
Ещё один вопрос (отдельно от предыдущего).
Вот Сергей записал, что работал 8 часов 4 минуты. Вы с эти согласились?
Если согласились, то этот "табель" ушёл в бухгалтерию и Сергею дополнительно к зарплате насчитали "переработки"?
Или у вас переработки как-то по-другому работают? Типа вы ведёте 2 разных табеля: один для денег, другой для эффективности...
а интеграция с гитом для ci/cd имеется у него?
Я вот травмированный контрактной разработкой - в веб-студии вели в WorkSection часы, заказчиков как гостевых юзеров туда приглашали, чтоб они могли видеть факт затраченных часов, ну и если обоснованное превышение часов случалось, то большинство готово было пойти на встречу.
Но сам факт часов нужно было обязательно иметь причём внесённым по таймеру, а не вручную - там в WS это отслеживалось...
Теперь в продуктовой разработке тоже трекаю время, в Jira есть плагин для этого. Хотя это почти некому тут ненужно, но я уже без таймера не могу)))
Если понимаешь, что это не в наказательной цели вводится, то относишься к этому проще)
Я там был проджект-менеджером (ну менеджерство весьма условное - сам аналитик задачи напиши, сам тестер, сам заказчика отбрифуй), а за не затрэканные часы сверх плана - просто как-то заказчик отказался платить и с тех пор пришлось трэкать постоянно..
Трэкать надо не только для заказчика, но и для аналитики собственных задач) В любом случае это полезно)
Ну это да, чтоб потом можно было прикинуть, сколько времени понадобится на новую подобную таску
Вот) Вот же! Это в статье тоже написано, но почему то многие зацепились за то, что мы оцениваем сотрудников)
Для нас простой критерий - нету сабтасков значит борда не очень.
А так очень хорош clickUP
Детализация с точностью до одной минуты? Отчеты с детализацией 10 минут?
Почему ошибка 30% считается существенной, при том, что задачи оцениваются буквально по минутам? Кстати, вы заметили, что все 3 сотрудника на скринах потратили ровно 8 часов на задачи за день?
Едва ли вы настолько наивны, что считаете эту статистику хотя бы отдаленно близкой к правде.
ИМХО, при заказной разработке галеры почти всегда продают заказчикам часы, которые уже приобрели по цене ЗП разработчиков. Реальный показатель оценки дохода это соотношение цены покупки и продажи времени. Это значит, что оценка, в особенности сверх-гранулированная расхода времени сотрудников для конторы с точки зрения бизнес-ценности не интересна вообще никак.
Причина движух с тотальным контролем всегда, - некомпетентность менеджмента, убежденного будто автоматизированный контроль возможен.
Исполнитель может вносить с точностью до одной минуты. Либо включил таймер, как начал задачу, как закончил – выключил.
Про 8 часов так совпало, но кто-то заполняет время в конце дня и подбивает, чтобы 8 часов было. Так это длина рабочего дня)
Мы продаем не часы, а реализацию проекта от аналитики до запуска. Но заказчик оплачивает фактически затраченные часы на проект. Работаем по Time & Material.
Нам эти цифры нужны для того, чтобы:
1. Могли собирать статистику по задачам и затем давать более точную оценку похожему функционалу.
2. Могли видеть общую картину по исполнителю, какие задачи он выполняет.
3. Считать эффективность по исполнителю. В нашей ситуации это отношение запланированного СОТРУДНИКОМ времени к фактически затраченному.
Это не тотальный контроль. Это нормальная история, когда исполнители фиксируют свое время. Правда)
Если и вы, и сотрудник знает, что 8 часов это не 8 часов, то кажется наивным делать вид, что оцениваете эффективность по этой статистике.
Мы продаем не часы, а реализацию проекта от аналитики до запуска. Но
заказчик оплачивает фактически затраченные часы на проект. Работаем по
Time & Material.
Суть ведь не в том, что ваша компания пишет в рекламе. Если заказчик оплачивает часы, ваш доход складывается именно из продажи часов.
Нам эти цифры нужны для того, чтобы:
Снова, ошибка в том, что доход конторы не зависит от умения планировать время сотрудником, он зависит от кол-ва фактически проданных часов. Эффективность вашего сотрудника всегда известна из его зп и цены, по которой вы смогли его продать.
В статье не про деньги было, а про отчетность. Маржинальность мы считаем иначе, конечно)
А вот отношение времени планируемого к затраченному назвали эффективностью. Вероятно, вас нейминг смущает)
Что касается точности измерений – они не 100% точные, мы это понимаем и не строим иллюзий. Но даже приблизительная аналитика позволяет делать выводы.
Перефразируя заголовок: "Куда без боли перейти с джиры и трелло, если хочешь патриотично продолжать развивать свой продукт/бизнес в россии и не релоцироваться". Отвечаем: лучше всего нахрен
Как грубо(
Почему так?
Возможно потому, что решение о выводе продуктов с российского рынка было принято Атлассианом тоже не просто так, а в силу того, что оставаться на российском рынке и платить налоги в бюджет россии - это, выражаясь не совсем языком отрасли, зашквар. И, соответственно, зашкваром является попытка продолжать развивать бизнес в этой стране, пусть и с использованием других таск-планнеров
А вы не рассматривали Планфикс? Это тоже отечественный продукт.
Jira и Trello уходят из России. В какой таск-трекер перейти без боли, чтобы статусы и ответственные сохранились?