Разработчик программного обеспечения Atlassian, который владеет Trello и Jira, начнет отключать от сервисов учетные записи, зарегистрированные из России и Белоруссии. Об этом компания сообщила в рассылке для пользователей несколько дней назад. Что делать тем, чьи процессы завязаны на эти сервисы?
Всем привет! Меня зовут Саша Комбаров и недавно я перевел команду из 50 человек из Trello в отечественный аналог. Расскажу с какими проблемами мы столкнулись, какие были аналоги и почему идеальный трекер вы никогда не найдете. В общем, наш личный опыт. Кстати, именно поэтому мы разработали надстройку над трекером: систему подсчета эффективности исполнителей и проектов — Reporter.
Предыстория
С основания компании в 2017 году и до 2022 года работали в Trello — простом и удобном таск-трекере. В Trello можно сколько угодно создавать пространств, досок и задач, добавлять артефакты к задачам, чек-листы, отслеживать прогресс задачи. Но не было и нет учета времени по задачам. Соответственно, менеджеру приходилось вручную подсчитывать затраченные ресурсы по каждому проекту, что отнимало достаточно много ресурсов, не всегда было точным, а в моменте посмотреть отчет и эффективность проектов не представлялось возможным. С ростом количества проектов осознали, что это нужно автоматизировать :)
Собрали основные требования, что бы мы хотели от трекера:
Канбан доска;
В задачу можно добавлять материалы и чек-листы;
Исполнитель может автоматически и вручную логировать время;
Автоматический подсчет планируемых и затраченных часов за отчетный период;
Подсчет эффективности выполненных задач;
Список выполненных задач;
Отчеты исполнителей за день;
Разделение прав доступа для менеджеров и исполнителей.
Начали складывать сервисы, которые могли бы нам подойти, в Google таблицу. В разное время попробовали YouTrack, Toggl и GanttPRO. Не зашло.
Переезд в отечественный трекер
В марте 2022 в Trello пропала возможность добавлять новых пользователей, также стало невозможным платить за иностранные сервисы с российских банковских карт. Из-за всех танцев с бубном стоимость увеличилась примерно в два раза.
В том же 2022 году были первые слухи, что сервисы для российских компаний отключат, поэтому решили искать отечественные альтернативы. Выбор пал на Kaiten, так как он один из нашей таблицы наиболее нам подходил.
Сразу скажу, что мы не собрали все вещи и переехали в новый инструмент всей компанией. Сначала решили протестировать это с командой добровольцев, перенеся их работу в Kaiten. Когда убедились, что ребята могут использовать нужные функции и работают с комфортом, мы подтянули все остальные команды.
Импортировать карточки из Trello или Jira в текущие статусы, а затем привязать к ним исполнителей можно буквально в несколько шагов:
Так, переехали, идем дальше :)
Организация работ команд
Для каждого нового проекта у нас формируется отдельная проектная группа, которую ведет менеджер. Но, что важно, менеджер может вести одновременно 4-5 проектов.
Чтобы это визуализировать, мы создали отдельные пространства в Kaiten для каждого проекта. Все эти пространства создавались по одному шаблону:
Слева на пространстве есть доска «Инфо», в карточках которой лежит вся информация по проекту с ссылками на документы и другими нужными файлами.
Рядом с ней — «Задачи» — основная доска проектной команды. Согласно всем канбан-канонам задачи двигаются по этапам слева направо. Это колонки: «Очередь», «Выполняется», «На проверке», «Проверено». Для каждой итерации мы сделали отдельные дорожки — так гораздо проще отслеживать эффективность работы.
Справа расположилась доска «Архив». В Kaiten можно архивировать карточки, чтобы готовые задачи не занимали место на доске, но хранились в специальном месте пространства. Мы с командой сделали отдельную доску, которую также назвали архивом, чтобы удобнее взаимодействовать с выполненными задачами. Завершенные карточки лежат на ней какое-то время, прежде чем автоматически улететь в архив пространства.
Внутри карточек мы используем почти все доступные поля, чтобы описать задачу, визуализировать всю важную информацию и избежать лишних коммуникаций. Например, мы всегда проставляем размер задачи, ставим метки, пишем описание задачи, указываем срок, добавляем участников и назначаем ответственного сотрудника.
Отдельно отмечу чек-листы. В карточке может быть сразу несколько чек-листов. Некоторые из них могут быть шаблонными, некоторые ребята создают по личной потребности индивидуально для каждой задачи. Например, один чек-лист описывает бизнес-логику, как задача должна быть сделана, а другой — тест-кейс, который регулирует взаимодействие тестировщика с разработчиком.
Чтобы менеджеру было удобно вести все свои проекты, он может переключаться между пространствами с помощью бокового меню. Так, бросив один взгляд на доску, будет понятно, на каком этапе находятся задачи, чем занимается конкретный сотрудник и как закрываются чек-листы.
Кстати, для регулирования доступов к разным пространствам мы используем группы пользователей. К примеру, если к нам пришел новый менеджер, будет достаточно добавить его в группу админов, чтобы новый сотрудник автоматически получил доступ к нужным пространствам.
Самая важная функция — тайм-трекер
Учет времени — функция, ради которой и затевался этот переезд в новый сервис. Нам жизненно необходимо было фиксировать время работы с задачами, чтобы сделать процесс прозрачным, и позже понимать рентабельность проектов и эффективность работы сотрудников.
Внутри карточки есть специальное поле, где мы выставляем размер — указываем количество часов, которое сотрудник запланировал на решение задачи.
Как только задача берется в работу, исполнитель запускает таймер и прописывает в специальном поле, что конкретно он делал в это время.
Сразу отмечу один момент — крайне важно договориться с членами команды, чтобы они отмечали свое реальное время работы с задачами. Руководство должно объяснить, что вы не играете в агентов ФСБ или Большого Брата для тотального контроля или наказаний.
Ваша цель — выстроить прозрачный и удобный рабочий процесс, чтобы в итоге грамотно балансировать нагрузку между сотрудниками и зарабатывать больше.
Позже всё это формируется в отчет о фактически затраченном времени. Я или менеджер проекта могут в любое время посмотреть отчет и проанализировать, сколько времени было затрачено на отдельную задачу или проект в целом. К примеру, если изначально мы запланировали 100 часов, но по итогу проработали 130, значит что-то пошло не так — проект нерентабельный, есть проблемы в работе или сотрудники работали неэффективно и т.д.
Кроме того, такой детальный учет времени помогает оценить, сколько ресурсов у нас уходит на типичные задачи. Поэтому, если в следующий раз на этом или другом проекте мы будем выполнять аналогичную задачу, то сможем точно оценить ее размер.
Внутри карточки можно посмотреть, отработал ли конкретный сотрудник норму часов за неделю и чем именно он занимался.
Reporter — что ты такое
Еще год назад исполнители отправляли ежедневные отчеты менеджеру в мессенджер. Сейчас даже как-то звучит дико, но так мы были уверены, что время точно не потеряется, плюс это дисциплинировало коллег.
Kaiten немного автоматизировал это, нужно было только зайти в дашборд и скопировать задачи.
Я готовил описание задач под наш небольшой сервис, который позволял бы смотреть отчеты за каждый день на одной странице, отслеживать эффективность по проектам и исполнителям. Это бы позволило не отправлять ежедневные отчеты.
Но у нас появился промежуточный этап. Один из разработчиков интегрировался с Kaiten и сделал страницу с отчетами по каждому дню. Назвал его лаконично — Reporter. Мне понравилось :)
Решили сначала использовать «программистский дизайн» и сформировать необходимые нам отчеты как можно быстрее, а затем уже освежить и дизайн, и фронт.
Несмотря на то, что в Kaiten удобно устроен сам таймер и все данные собираются в разные типы отчетов, нам не хватало удобной визуализации. Было муторно скачивать отчеты в Excel и вручную доставать нужные данные.
И раз уж мы разработчки, которые хотели автоматизировать всё по максимуму, мы решили адаптировать систему отчетов под себя (благо у Kaiten есть открытый и довольно удобный API). Так и появился специальный плагин Reporter.
Что за зверь этот Reporter и что же он умеет?
1. Формировать отчет за день по выбранному сотруднику.
Плагин подгружает данные из Kaiten и в один клик показывает все затраченные часы сотрудника и комментарии по ним. Отчет доступен и исполнителям, и менеджерам.
2. В процентах показывать эффективность работы исполнителей.
На этой странице менеджер или я можем отследить, отношение запланированного и по факту затраченного сотрудником времени. Можно посмотреть данные по всем проектам или выбрать один конкретный. Также отчет показывает, сколько часов разработчик был активен в сервисе.
3. Формировать статистику всех сотрудников.
Например, сколько часов они отработали в конкретный день или посмотреть подробную информацию о каждом.
5. Показывать общую статистику по проекту.
Reporter достает данные по всем задачам на пространстве проекта и сравнивает план и факт по запланированному и потраченному времени на проект. Также показывает прогресс по проекту — сколько задач в очереди, в работе и готово.
Ну и как же без темной темы, многие ее оценили.
Reporter помог упросить процесс сбора данных о работе над проектами, что в свою очередь привело к повышению контроля эффективности внутри команды.
Наши промежуточные результаты
Иногда я читаю истории, как команды бунтуют, когда руководство просит их трекать время. В этих случаях мне кажется, что дело не в инструменте, а в его правильном использовании и моральной подготовке сотрудников. Лично мы подошли к вопросу переезда серьезно и подготовили почву для команды, чтобы ребятам было проще адаптироваться:
Пообщались с командой и объяснили, для чего нам нужно учитывать время и как это улучшит работу веб-студии.
Написали регламент работы в новом инструменте и рассказали об основных фишках.
Сделали небольшой собственный FAQ и провели несколько встреч с отработкой вопросов.
Конечно и у нас не обошлось без шероховатостей — привыкать к чему то новому без них невозможно. Но они же стали толчком к разработке Reporter, который облегчил и сделал рабочий процесс еще прозрачнее.
Спустя год после перехода в трекер, я уверенно могу сказать, что это было верным решением — мы выросли ~ на 30%. Качество постановки и контроля задач стало выше. Мы понимаем, куда и сколько тратится времени на проект. Эти данные помогают отследить, сколько ресурсов фактически тратится на разработку и здраво оценить свои возможности. Таким образом мы можем точнее устанавливать сроки работы над проектом и не бояться факапов.
Ну и еще один вывод — не гонитесь за двумя зайцами сразу :) Выберите, что для вас важнее, а затем подбирайте сервис. Лучше с API, чтобы вы могли через какое-то время расширить его под себя.
Переехали из Jira или Trello? Какой таск/тайм трекер используете? Считаете ли эффективность и рентабельность?
Делитесь в комментариях :)
Комментарии (153)
Serge_DSX
12.08.2023 12:21+5Использовал Trello для личных целей. Очень было досадно, когда получил "письмо счастья". Немного посмотрев, что есть на рынке из отечественного (с возможностью переезда карточек и закладок), выбрал WEEEK. Переезд и перенастройка заняли от силы час.
Пока полёт нормальный, нареканий нет.
Учётку в Atlassian снёс после этого сразу, и пусть идут лесом! =)
sashadzen Автор
12.08.2023 12:21+1Да, переезжать сразу стоило. Некоторые сервисы без предупреждения со всеми данными доступ отрубили
UprightMan
12.08.2023 12:21+1Я тоже на WEEK перешел - пока всем очень доволен. Особенно радует интуитивно понятный интерфейс и максимально упрощенный онбординг. Бесплатный тариф закрыл все, что было нужно для личного планирования задач (подозреваю, что в командах работает так же хорошо).
alexandrmoroz
12.08.2023 12:21+7Никакой слежки за сотрудниками – это принципиальная позиция. Считаем эффективность по скорости команды в целом: есть такое понятие velocity, за единицу расчёта берем story point. Это намного гибче, проще и в итоге точнее получается, чем считать часы. Разработчик участвует в оценивании задач на planning poker. Оценки даём качественные, а не количественные. Для гибкого планирования этого достаточно. И в итоге ошибок гораздо меньше.
У сервиса Аванплан есть импорт из Jira и Trello, в том числе импорт оценок задач в SP. Все проекты и задачи импортируются быстрее, чем за минуту (мы переезжали из Redmine c 2500 тыс задач). Есть веб-версия и мобильное приложение iOS, Android. Есть оценки в сторипойнтах, есть расчёт скорости команды, есть прогнозы по дате завершения на основе этой скорости, удобные дашборды не для галочки, а исходя из помощи в планировании и отслеживания прогресса.
Самое полезное для меня лично — это я смог импортнуть свои личные задачки из Trello, а рабочие из Redmine и теперь на одном дашборде мне подсказывают успею ли я до конца недели все свои задумки сделать как по работе, так и по дому. Раньше я пытался это как-то в OmniFocus сводить. Но у него не было интеграции именно с трекерами задач.
Покер проводим в Retrius — также российская разработка. Там же можно провести ретро или мозгоштурм при необходимости. Заставляет не расплываться мыслью по древу и придерживаться повестки. Собрания у нас теперь в два раза короче получаются. Народ доволен.
Кайтен неплох для тех, кто привык именно к Trello. Но пользоваться трелло именно для разработки как по мне — один из первых этапов зрелости команды. С ростом зрелости и опыта уже слишком тесно становится в трелло.
sashadzen Автор
12.08.2023 12:21+3Это не слежка :)
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.alexandrmoroz
12.08.2023 12:21+2Конечно, ресурсы надо отслеживать и планировать, это понятно. Я за то, чтобы по возможности не взваливать вопросы ресурсного планирования на разработчиков. Они не могут и не должны точно оценивать в часах. Но оценку вообще они должны давать, без этого никуда. Поэтому придумали эту хитрость с оценкой качественной (просто-сложно-нереально) вместо количественной. А количественная (уже в целях ресурсного планирования) появляется в отчетах, которые в хороших системах делаются автоматически. В том числе и форму Т-13 заполнить и т.д., чтобы и бухгалтерия была довольна, и заказчику можно было бы объяснить смету, если ему так привычнее. Хитрости эти придумали очень давно, называются они Agile, Scrum и иже с ними. И заказную разработку тоже можно так делать. Вопрос в целесообразности, готовности команды и бизнеса к этому. Редко кто сразу начинает именно так работать. Обычно это долгий и тернистый путь)
Вы продвинулись не мало за несколько лет. У вас есть отчетность, вы планируете — большинство даже этого не делают.
vahmurka
12.08.2023 12:21кстати, кайтен «умеет» оценивать в сторипоинтах и в «майках» и в часах (вшитое поле Размер)… в теории (для бухов и заказчиков) можно сделать конвертор сторипоинтов (или маек) в часы, у кайтена есть кастомное поле «формула» с которым оч много всего можно делать.. и покер-оценка у них есть..
пишу не для автора (уже и так знают), а кто пока ещё выбирает трекер.. )
Lexicon
12.08.2023 12:21У ваших сотрудников почасовая оплата с динамической ценой часа?
Если нет, то это подмена понятий, вы ведь просто продаете часы сотрудника компаниям, все, что вам "необходимо" в таком случае, это продавать часы в нужном соотношении. Причем тут вообще сам сотрудник?sashadzen Автор
12.08.2023 12:21Мы продаем разработку проектов, а заказчик оплачивает часы затраченные на проект.
Эффективность у нас – это отношение запланированного СОТРУДНИКОМ времени на затраченное им же.
Чтобы мы понимали, попадаем ли мы в оценки, а если нет, то разбираем почему.
Kanut
12.08.2023 12:21Мы продаем разработку проектов, а заказчик оплачивает часы затраченные на проект.
Заказчик у вас оплачивает часы, а не готовый продукт? Повезло вам с заказчиком :)
sashadzen Автор
12.08.2023 12:21Это, можно сказать, становится стандартом отрасли. Работа по Time & Materia
SpiderEkb
12.08.2023 12:21Совершенно нет. Может быть где-нибудь в вебразработке, но это не вся отрасль.
sashadzen Автор
12.08.2023 12:21А я про заказную веб и мобайл разработку)
SpiderEkb
12.08.2023 12:21С этим даже связываться не хочу :-)
Там сплошное "сделайте нам красиво" - сами не знают чего хотят. А без ТЗ, как известно, результат ХЗ.
sashadzen Автор
12.08.2023 12:21Ну, разные заказчики бывают) В основном все четко, рынок изменился. Но я говорю про разработку от ~3 млн рублей
Lexicon
12.08.2023 12:21Это подмена понятий.
Разработчик не может эффективно заниматься несколькими проектами сразу, покупает ваша контора часы пакетами, продает тоже пакетами, в сути вашу контору интересует только количество проданных часов и продажа часов подешевле за подороже.Эффективность проекта это кол-во потраченных денег на кол-во полученных, то, что вася думал проект займет миллиард часов, а занял неделю никак не повлияет на затраты сторон.
Соответственно должна измеряться эффективность проекта, а не сотрудника. Тк эффективность сотрудника давно известна из его цены.
sashadzen Автор
12.08.2023 12:21Как ловко вы перешли от эффективности к тому, что нас интересует)
В своей компании вы можете по другому считать, никто не запрещает, а мы вот так это делаем.
К нам не за часами приходят, а за реализацией проекта, а часы это лишь форма расчета)
SpiderEkb
12.08.2023 12:21Зачем оплата часа? Оплата за результат. Который есть "функционал в срок". Сколько часов потратил - его проблемы.
Два разных сотрудника с разной квалификацией могут на одно и то же потратить разное время. Но результат один и стоимость его должна быть одинаковой.
sashadzen Автор
12.08.2023 12:21Есть и такой формат работы, как вы описали. А если заказчик оплатил 100 часов, а сделали задачу за 10? Вернуть 90 часов?
При разработке сложных продуктов есть много подводных камней, которые сразу не учесть, поэтому мы работаем по Time & Material. То есть заказчик оплачивает фактически затраченное время на задачу.SpiderEkb
12.08.2023 12:21Заказчик не оплачивает часы. Он говорит "мне нужно вот это". Мы отвечаем - "стоит будет столько, через полгода система будет развернута на объекте и на 100% работоспособна в рамках оговоренного функционала". Это контракт. Как сы его будем выполнять внутри - это наши заботы. Тянуть со сроками и давать заведомую переоценку не в наших интересах. Нам интересно выполнить один контракт и взять другой.
Недооценивать сроки и выкатывать недоработанную или недотестированную систему - тоже не в наших интересах. Это репутационный ущерб.
Так было когда в промавтоматизации работал. Сейчас банк (центральные серверы). Тут если с архитектурой накостылишь, можно очень большие проблемы с интеграцией получить, что приведет к такому ущербу, что мало не покажется никому. Так что тут еще жестче - есть ОТАР (Организационно-Техническое Архитектурное Решение), когда он согласован всеми - все. Выделяются ресурсы, бюджет, определяются сроки.
Если заказчик что-то захотел поправить - задача снимается и все с начала. При этом после пересогласования она может сдвинуться по времени, например, на конец следующего квартала. Поэтому заказчики (бизнес-подразделения) все это понимают и стараются свои хотелки сразу формулировать в максимально полном и конкретном виде.
sashadzen Автор
12.08.2023 12:21Звучит круто)
Но мы работаем Т&М, потому что иногда все хотелки сразу и максимально не собрать. Сделали какую-то функцию, смотрим на нее, ага. Вот тут лучше было бы так сделать, а вот это вообще убрать.
Ну и бюрократии меньше)
dyadyaSerezha
12.08.2023 12:21+10Внутри карточки можно посмотреть, отработал ли конкретный сотрудник норму часов за неделю и чем именно он занимался
Норма часов? Во-во, натуральный мини-ФСБ. Если это фиксируется автоматически, то даже и тут можно обмануть при желании (самое тривиальное - смлтря блокбастер, двигать мышку каждые N минут, чтобы копм не погасил/заблокировал экран). А если время ставится вручную, что мешает всегда делать "8 часов в 30 минут" в день?
Насчёт эффективности - очень, очень часто можно сильно ошибиться а оценке трудоёмкости, особенно при багфиксах или неочевидных с точки решения задачах.
sashadzen Автор
12.08.2023 12:21+2Ну почему ФСБ(
Выше уже писал, что мы занимаемся проектной разработкой, работаем с заказчиками по ТМ.
Мы предварительно оцениваем задачи с разработчиками, затем согласовываем стоимость задач с заказчиками, а если что-то пошло не по плану? Должны обосновать, почему задача заняла больше времени, чем мы планировали.
Но все это не только для отчетности, как вы могли понять из статьи)dyadyaSerezha
12.08.2023 12:21+2Не очень понимаю, что такое проектная разработка. Проектом можно назвать любую задачу. И не знаю, что такое ТМ.
sashadzen Автор
12.08.2023 12:21Проектная разработка, если сильно упростить – это когда разрабатывается конкретный функционал под задачи заказчика.
ТМ – time & material, формат оплаты, когда заказчик оплачивает фактически затраченное время на разработку.SpiderEkb
12.08.2023 12:21Несколько странный подход. Никогда не сталкивался с таким.
Сколько работаю (а профессионально в разработку ушел где-то в 1991-м году), всегда было "создать оговоренный функционал в оговоренный срок за оговоренные деньги". Т.е. заказчик оплачивает конечный результат, а не количество часов за компом.
Естественно, предусматриваются штрафные санкции за срыв сроков. И естественно сроки есть продукт взаимной договоренности и опираются на нашу оценку. Если заказчику нужно быстрее чем мы можем - тут отдельный разговор.
Но когда все согласовано - тут уже наша забота чтобы в срок уложиться. Хочешь днем спи, ночью работай, хочешь наоборот. Главное - уложиться в срок.
tommyangelo27
12.08.2023 12:21Работал где-то над 5 проектами с оплатой time & material.
Вы пишете про "создать оговоренный функционал в оговоренный срок за оговоренные деньги", а в тех проектах нет оговоренного функционала. Точнее как — есть высокоуровневые хотелки, но никто, ни заказчик, ни исполнитель, ни интегратор не знает как именно мы будем реализовывать хотелки. То есть функционал описывается и документируется прямо по ходу разработки. Если ещё больше упрощать — мы делаем демо, показываем заказчику, а он говорит что дальше — то ли оставляем, то ли выбрасываем и делаем всё с нуля.
SpiderEkb
12.08.2023 12:21Точнее как — есть высокоуровневые хотелки, но никто, ни заказчик, ни исполнитель, ни интегратор не знает как именно мы будем реализовывать хотелки. То есть функционал описывается и документируется прямо по ходу разработки. Если ещё больше упрощать — мы делаем демо, показываем заказчику, а он говорит что дальше — то ли оставляем, то ли выбрасываем и делаем всё с нуля.
С таким давно уже зарекся связываться. Ничего хорошего из этого не получается. Любой мало-мальски сложный проект требует архитектурной проработки. В описываемо вами случае это нереально - вы строите одну архитектуру, в результате получается что-то совсем иное. Все это приводит к лютому костылингу.
Поэтому работаю только там, где все оговаривается заранее на берегу с составлением BRD (бизнес-требования заказчика). Дальше - архитектурное решение, FSD, разработка, тестирование, внедрение.
Тогда получается эффективный продукт без внутренних противоречий который потом можно нормально сопровождать (у меня "в портфолио" есть продукты, которые внедрены в конце 90-х и все еще сопровождаются без проблем. А уж объектов, где наша система устанавливалась в 10-15-м годах и все еще работает и поддерживается, более чем.
Правда, долгое время основная область была промавтоматизация. А там и железо и софт вместе. И если о чем-то договорились и сделали железо (контроллеры), а потом заказчик переобулся в воздухе, ему сразу предложат выкупить то железо что уже сделано (и самостоятельно отнести его на помойку), а потом еще раз оплатить разработку и изготовление нового. Желающих оплачивать каждый свой каприз по отдельному прайсу, почему-то, не нашлось ни разу.
tommyangelo27
12.08.2023 12:21+1Всё так, просто я работаю в куда более гибкой бизнес-среде — ecommerce на php ????.
И у нас для заказчика откатить всё назад и сделать с нуля — это потеря, скажем, 40-50 тысяч долларов, что ощутимо, но не прям конец всему. Полагаю, что если бы их потери считались бы в миллионах долларов — то и подход был бы другой.А ещё с T&M бывало такое, что мы просто не доводили проект до конца. То есть сделали этап 1, заказчик посмотрел и сказал, что ему хватит, устроит как есть. И тогда получается, что они даже экономят по факту, так как время на согласование требований, архитектурное решение и т.д. не было потрачено впустую.
sashadzen Автор
12.08.2023 12:21А это цифры по какому курсу?)) Мы тоже хотим в эту бизнес-среду))
Даже если работать по фикс, то не берет же исполнитель сразу за весь проект стоимость, а по этапно. Аналитика, дизайн, разработка, условно. Что тоже позволяет не завершать прям весь проект)tommyangelo27
12.08.2023 12:21Это не по курсу, я в американской компании работаю и на американский рынок. Про нынешнюю не могу говорить, а вот прошлая контора, где работал до 2021 года брала с клиента примерно $150-180 за 1 час разработки.
Но тут нюанс — это именно что чистый 1 час, то есть часы всех других отделов не связанных с разработкой (а это всё администрирование, все внутренние проекты, и так далее) должны окупаться за счёт отдела разработки.
Ещё могу поделиться инсайдом — до продажи компании чистая прибыль с одного часа выходила примерно $10 до налогов. Трудилось около 160 человек в 4 странах. Потом компания стала дочкой WPP, и сотрудникам перестали расскрывать внутреннюю кухню бизнеса.
Аналитика, дизайн, разработка, условно. Что тоже позволяет не завершать прям весь проект)
Да, тоже верно.
Mikhail55ru
12.08.2023 12:21+1Помоему это и есть ключевой аспект решаемых задач: почасовая оплата требует какого-то вразумительной фактуры для отчёта перед заказчиком.
sashadzen Автор
12.08.2023 12:21Все верно)
spaceatmoon
12.08.2023 12:21Вот только оценка задачи не должна ложиться на плечи разработчика. А то получается так, что у вас вроде и аналитик есть, но почему-то разработчик в итоге получает по жопе, что как-то неправильно. Часы это прошлый век, всё можно посчитать и по agile, а грамотный менеджер может и от story поинтов рассчитать бюджет.
sashadzen Автор
12.08.2023 12:21+1Задачу будет делать разработчик, почему он не должен свою задачу оценивать?
Hokum
12.08.2023 12:21+5Насчёт эффективности - очень, очень часто можно сильно ошибиться а оценке трудоёмкости, особенно при багфиксах или неочевидных с точки решения задачах.
Вот как раз для таких случаев и хорошо иметь статистику, что на этом проекте заменить описание - это 10 минут, а вот на этом 2 часа.
Статистика, более качественное планирование. Но при условии, что менеджмент адекватный, и срыв сроков - это повод задуматься, что недоглядели, чтобы в будущем заложить на это время, а не претензии к сотрудникам, что они плохо работают.
Самое сложное построить доверительные отношения, чтобы не было и такого, что сотрудник не успевает и в тихоня что-то в ночи доделывает, а потом рапортует, что всё ОК, в срок уложился.
Касается это не только того где время меряют буквально, но и где оценки идут в сторипоинтах. Заложили 3 сторипоинта, а в итоге получилось , что делали весь спринт, при средней скорости в 5 сторипоинтов.
sashadzen Автор
12.08.2023 12:21+3Хочу вашему комментарию поставить 10 плюсов, но карма и на 1 закончилась :)
Цель не наказать, а как раз разобраться, где недоглядели. И менеджеры, и разработчики.
spaceatmoon
12.08.2023 12:21У топикастера задача состоит в выжимании максимального профита с ресурса компании. Прям так и сквозит всей этой эффективностью.
sashadzen Автор
12.08.2023 12:21+1Хм, а разве нет бизнеса, который хочет получить максимальный профит?)
Hardcoin
12.08.2023 12:21А если время ставится вручную
Вручную, конечно. Разработчик без сомнения может врать, но по сути эта оценка не столько времени, сколько цены задачи. И если видно, что какой-то разработчик задачи делает очень дорого (или врёт или просто медленно работает), он первый кандидат на увольнение.
sashadzen Автор
12.08.2023 12:21+1Можно автоматом трекать, можно вручную. За этим не следим)
Разработчик может врать менеджеру, возможно, менеджер даже несколько таких враков не заметит. Но если старшие разработчики и тимлиды, которые затем на это укажут.
Наша система не надзирательная, а как раз наоборот. Помогает развивать эффективность)
Apokalepsis
12.08.2023 12:21Попробуйте Яндекс.Трекер, после JIra глоток свежего воздуха. Причем они очень сильно шагнули вперед с первых релизов (тогда им вообще не возможно было пользоваться).
sashadzen Автор
12.08.2023 12:21+3Хм, а мы вот пробовали, но были разочарованы. Но было это давненько) Если сейчас изменилось в лучшую сторону, то ради интереса потестим)
sbase
12.08.2023 12:21Если просто менять этот стек, то Eva позиционирует себя как замена. Если же со сменой хочется еще ускорить проекты и добавить ресурсное планирование, то в BIPULSE есть интеграция с Trello и Jira , но тут в нагрузку приедет и обновление методологии управления. (Управление проектами критической цепи (Critical chain Project management) и адаптация этого для Agile проектов)
sashadzen Автор
12.08.2023 12:21А вы что используете?
sbase
12.08.2023 12:21+1Мы, как разработчики второго (Пульса), то его и применяем %))
Я лично пробовал давно другие решения, но там как без рук. Для простых ответов на вопросы (когда освободится сотрудник, задачи по сотрудникам) нужно городить какие-то хитрые отчёты вместо одного клика.
Некоторые Клиенты ставят Пульс в интеграцию в Jira/Trello чтобы видеть всю картину, а не разбитую по пространствам/доскам. Другие ставят вместо BigPicture/Structure, чтобы нормальное календарно-сетевое планирование поверх трекера было.
vahmurka
12.08.2023 12:21на фрилансе приспособил Кайтен как замену тайм-трекера, конечно с настоящими (типа Clockify, tmetric и т.п. ) нельзя сравнить, но основные функции выполняет (без экспорта в эксель):
ведёт проекты
считает время
считает деньги (доход)
строит итоговую таблицу, чтобы счета выставлять
sashadzen Автор
12.08.2023 12:21А можно и в эксель экспортировать, есть же выгрузка)
vahmurka
12.08.2023 12:21да, есть выгрузки в эксель, есть хорошее апи… но, если уж мы платим немаленькие деньги за продукт, то хочется получать желаемое без лишних
костылейзаморочек ))эксели и апи для чего-то более эксклюзивного или когда нет другого выхода )
иначе, зачем тогда продукт и такие деньги платить, если в экселе можно вообще всё делать!? ))
с помощью скриптов из гугловского экселя можно сделать вполне достойный трекер и даже получше многих платных на рынке ))
sashadzen Автор
12.08.2023 12:21Согласен, за деньги хочется получать больше ништяков)
Я общался с продактом Кайтена, они сами понимают, что есть над чем работать, в частности отчеты будут допиливать)
vahmurka
12.08.2023 12:21статья про Кайтен, потому скажу про него )
юзаем Кайтен меньше года, основные претензии:
не умеет автоматически включать таймер при перемещении в нужную колонку (чтобы запустить таймер надо открыть полную форму задачи, кликнуть пуск, кликнуть ок в модалке… капец)
очень «закрытые» отчёты… собственный (кастомный) построить нельзя (эксель не в счёт).. ОЧЕНЬ слабые возможности по кастомизации готовых (встроенных) отчётов (почти ничего нельзя сделать, кроме «пары» фильтров) и свой не сохранишь…
слабенькое разведение прав (но получше, чем у очень многих)… хочется 50+ пунктов ))
что радует:
от первого раза было ощущение, что это единственные ребята в мире, которые понимают в канбане )) … ни у кого не видел такое свободное управление досками, колонками, подколонками, дорожками с кучей настроек и автоматизаций
много автоматизации, которая в формах легко настраивается
хорошая интеграция с телеграмом
очень хороший набор типов для кастомных полей
sashadzen Автор
12.08.2023 12:21Да, есть минусы. Но они развиваются, может и это прикрутят)
Мы на основе их АПИ отчеты допилили, потому что их да, слабоватые...
vahmurka
12.08.2023 12:21+2работал в нескольких конторах, где вот так же «требовали» выработку, 40ч в неделю «вынь да положь»… и что? - если не хватало до 40 (киношки смотрел), то просто накидывали в задачи - таска делается 5мин, а пишут 1ч или переносили время на следующую неделю (если переработка)… все были «в одной лодке», потому лидам было глубоко пофик на такое…
наверно только бухам от этого хорошо, но никаких вменяемых выводов из такого учёта сделать невозможно, «филькина грамота»…
sashadzen Автор
12.08.2023 12:21Когда всем пофик, то ничего не поможет. А нам не пофик, поэтому работает) Конечно, иногда и филькины грамоты проскакивают, стараемся отслеживать
sbase
12.08.2023 12:21+4Учёт потраченного времени целесообразен только в аутстафф/аутсорс конторах. Потому, что они продают часы и по ним нужно выставлять счета. Если же проект продается по фиксе, то важно не "сколько часов туда вбухали", а "за сколько времени проект сделали" и сколько календарного времени (в рабочих днях) потрачено на задачу. Потому что операционные затраты постоянно идут, и чем раньше будет сделан проект, тем больше выгода на экономии операционных затрат.
Но даже при просрочке проектов, эти компании научились "отбивать" все увеличения сроков доп. соглашениями.sashadzen Автор
12.08.2023 12:21Все правильно говорите)
Но с другой стороны, когда мы реализуем проекты с оплатой за часы, то в этот момент заказчик начинает считать "за сколько времени проект сделали". И если экономика не сходится, то он уйдет к другим.
Поэтому это одна из мер, которая позволяет делать проекты в рыночные бюджеты, а не заливать дыры доп часами)sbase
12.08.2023 12:21Тогда нужна Методика (Метод управления проектным бизнесом, ISBN 978-5-0055-3024-0), чтобы план проекта был надёжным. Чтобы дыр не было.
vooft
12.08.2023 12:21+2А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.
sashadzen Автор
12.08.2023 12:21На исследовательские задачи выделяем время пощупать, чтобы понять на сколько сложно. Условно договорились, что к концу дня исполнитель сообщит менеджеру, что удалось сделать и появилась ли какая-то ясность.
Вы правы, бывают проекты, где внедрение даже небольшой функции может привести к его перелопачиваннию. Разработчик перед задачей изучает проект, если видим, что можем утонуть, то закладываем больше буфера + предупреждаем об этом заказчика.
Спасибо за интересные вопросы)vooft
12.08.2023 12:21Т.е. время на изучение проекта вы не оцениваете и не биллите?
sashadzen Автор
12.08.2023 12:21Оцениваем и биллим. Заказчик оплачивает эти задачи. Я написал условную ситуацию, когда совсем ничего непонятно.
А так предварительно декомпозируем, но понимаем, что может потребоваться больше времени.
sbase
12.08.2023 12:21Мне нравится формулировка "закладываем буфера", а контролируете ли их расход? ;)
anitspam
12.08.2023 12:21+12. В процентах показывать эффективность работы исполнителей.
Судя по картинке вы определяете "эффективность" как некоторую функцию от количества времени, которое сотрудник записал в поле "план", и количества времени, которое сотрудник записал в поле "факт".
Вы где-то посмотрели такое определение эффективности или сами изобрели?
Ещё подскажите.
Дарья планировала 5 часов оценивать задачи. И она записала, что 5 часов их оценивала.
Дарья молодец или не молодец?
Aquahawk
12.08.2023 12:21+1Не то чтобы прямо молодец. Надо было записать что оценивала их 4 часа 50 минут. И план превышен, и возможность на следующем спринте его ещё раз превысить сохранена.
sashadzen Автор
12.08.2023 12:21-1Это пока самая простая аналитика, которую можно собрать. Отношение планируемого к фактическому.
Если Дарья согласовала эту оценку и уложилась в нее, и результат работ соответствует ожидаемому (то есть декомпозировала все задачи и оценила), то конечно молодец.
Почему нет?)anitspam
12.08.2023 12:21Будет интересно почитать про процесс согласования. Дарья сообщает кому-то "Согласуй мне, пожалуйста, 5 часов на оценку задач". Её коллега или руководитель проводит какую-то работу и сообщает "Да, ок". При этом у двух человек появляются затраты времени на задачу "Согласование времени".
Это так происходит?
sashadzen Автор
12.08.2023 12:21Если убрать момент, что мы оцениваем пулл задач, а не одну задачу, то да. Необходимо проверить, что было верно запланировано и декомпозировано
anitspam
12.08.2023 12:213. Формировать статистику всех сотрудников.
Ещё один вопрос (отдельно от предыдущего).
Вот Сергей записал, что работал 8 часов 4 минуты. Вы с эти согласились?
Если согласились, то этот "табель" ушёл в бухгалтерию и Сергею дополнительно к зарплате насчитали "переработки"?Или у вас переработки как-то по-другому работают? Типа вы ведёте 2 разных табеля: один для денег, другой для эффективности...
sashadzen Автор
12.08.2023 12:21-1Да, два разных табеля сейчас. Потому что где-то мог разработчик прокосячить и задержаться, а где-то менеджер просит задержаться. Но мы на пути к дзену, когда все будет в одной системе)
NIKEtoS1989
12.08.2023 12:21+2Я вот травмированный контрактной разработкой - в веб-студии вели в WorkSection часы, заказчиков как гостевых юзеров туда приглашали, чтоб они могли видеть факт затраченных часов, ну и если обоснованное превышение часов случалось, то большинство готово было пойти на встречу.
Но сам факт часов нужно было обязательно иметь причём внесённым по таймеру, а не вручную - там в WS это отслеживалось...
Теперь в продуктовой разработке тоже трекаю время, в Jira есть плагин для этого. Хотя это почти некому тут ненужно, но я уже без таймера не могу)))
sashadzen Автор
12.08.2023 12:21+1Если понимаешь, что это не в наказательной цели вводится, то относишься к этому проще)
NIKEtoS1989
12.08.2023 12:21+1Я там был проджект-менеджером (ну менеджерство весьма условное - сам аналитик задачи напиши, сам тестер, сам заказчика отбрифуй), а за не затрэканные часы сверх плана - просто как-то заказчик отказался платить и с тех пор пришлось трэкать постоянно..
sashadzen Автор
12.08.2023 12:21Трэкать надо не только для заказчика, но и для аналитики собственных задач) В любом случае это полезно)
NIKEtoS1989
12.08.2023 12:21Ну это да, чтоб потом можно было прикинуть, сколько времени понадобится на новую подобную таску
sashadzen Автор
12.08.2023 12:21Вот) Вот же! Это в статье тоже написано, но почему то многие зацепились за то, что мы оцениваем сотрудников)
NIKEtoS1989
12.08.2023 12:21+1Ну я то аналитик на нынешнем месте и тут даже мне нужно дать оценку бизнесу - сколько такая задача может стоить в часах, потому согласен с тем, что в каком-то виде планирование и логирование часов необходимо
sashadzen Автор
12.08.2023 12:21Спасибо, что развернули в комментариях, стало понятнее)
NIKEtoS1989
12.08.2023 12:21+1Ну да, я думаю больше с необходимостью планировать и логировать сталкиваются разработчики - они же с этого чаще бомбят)
mikegordan
12.08.2023 12:21Для нас простой критерий - нету сабтасков значит борда не очень.
А так очень хорош clickUP
Lexicon
12.08.2023 12:21+1Детализация с точностью до одной минуты? Отчеты с детализацией 10 минут?
Почему ошибка 30% считается существенной, при том, что задачи оцениваются буквально по минутам? Кстати, вы заметили, что все 3 сотрудника на скринах потратили ровно 8 часов на задачи за день?Едва ли вы настолько наивны, что считаете эту статистику хотя бы отдаленно близкой к правде.
ИМХО, при заказной разработке галеры почти всегда продают заказчикам часы, которые уже приобрели по цене ЗП разработчиков. Реальный показатель оценки дохода это соотношение цены покупки и продажи времени. Это значит, что оценка, в особенности сверх-гранулированная расхода времени сотрудников для конторы с точки зрения бизнес-ценности не интересна вообще никак.
Причина движух с тотальным контролем всегда, - некомпетентность менеджмента, убежденного будто автоматизированный контроль возможен.
sashadzen Автор
12.08.2023 12:21Исполнитель может вносить с точностью до одной минуты. Либо включил таймер, как начал задачу, как закончил – выключил.
Про 8 часов так совпало, но кто-то заполняет время в конце дня и подбивает, чтобы 8 часов было. Так это длина рабочего дня)
Мы продаем не часы, а реализацию проекта от аналитики до запуска. Но заказчик оплачивает фактически затраченные часы на проект. Работаем по Time & Material.
Нам эти цифры нужны для того, чтобы:
1. Могли собирать статистику по задачам и затем давать более точную оценку похожему функционалу.
2. Могли видеть общую картину по исполнителю, какие задачи он выполняет.
3. Считать эффективность по исполнителю. В нашей ситуации это отношение запланированного СОТРУДНИКОМ времени к фактически затраченному.
Это не тотальный контроль. Это нормальная история, когда исполнители фиксируют свое время. Правда)Lexicon
12.08.2023 12:21Если и вы, и сотрудник знает, что 8 часов это не 8 часов, то кажется наивным делать вид, что оцениваете эффективность по этой статистике.
Мы продаем не часы, а реализацию проекта от аналитики до запуска. Но
заказчик оплачивает фактически затраченные часы на проект. Работаем по
Time & Material.Суть ведь не в том, что ваша компания пишет в рекламе. Если заказчик оплачивает часы, ваш доход складывается именно из продажи часов.
Нам эти цифры нужны для того, чтобы:
Снова, ошибка в том, что доход конторы не зависит от умения планировать время сотрудником, он зависит от кол-ва фактически проданных часов. Эффективность вашего сотрудника всегда известна из его зп и цены, по которой вы смогли его продать.
sashadzen Автор
12.08.2023 12:21В статье не про деньги было, а про отчетность. Маржинальность мы считаем иначе, конечно)
А вот отношение времени планируемого к затраченному назвали эффективностью. Вероятно, вас нейминг смущает)
Что касается точности измерений – они не 100% точные, мы это понимаем и не строим иллюзий. Но даже приблизительная аналитика позволяет делать выводы.
Mavericky3
12.08.2023 12:21Перефразируя заголовок: "Куда без боли перейти с джиры и трелло, если хочешь патриотично продолжать развивать свой продукт/бизнес в россии и не релоцироваться". Отвечаем: лучше всего нахрен
MrBugHunter
12.08.2023 12:21А вы не рассматривали Планфикс? Это тоже отечественный продукт.
sashadzen Автор
12.08.2023 12:21Рассматривали, но на тот момент больше зашел Кайтен. Хотя Планфикс тоже неплох)
abcdsash
К примеру, если изначально мы запланировали 100 часов, но по итогу проработали 130, значит что-то пошло не так — проект нерентабельный, есть проблемы в работе или сотрудники работали неэффективно и т.д.
и заметьте, вопросов к запланировавшим 100 часов у них нет, а только к сотрудникам...
а запланировали бы 50 то и тем более сотрудники не эффективны? А проблема на самом деле в том, что планирующие часто очень мало в чем разбираются, кроме "скрам-мастерства" и тому подобного хлама
sashadzen Автор
Что вы предлагаете?
forthuse
? Не верить искуственно сформированным метрикам и KPI в каком то софте, а больше работатать и общаться с непосредственными исполнителями задания?
sashadzen Автор
Спасибо за совет, наверное я сильно быканул в комментарии, раз столько минусов :)
Я привел сразу несколько причин в статье, и как раз «есть проблемы в работе» – это вопросы к запланировавшим, то есть менеджерам. Могли неверно организовать работы, плохо проработать бизнес логику и пр.
Планируют время на работу сотрудники, они предварительно оценивают задачи.
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
ganqqwerty
выяснить причину и скорее всего настучать по голове запланировавшему, потому что он наврал?
sashadzen Автор
А запланировавший – это сотрудник, а не менеджер. Исполнители оценивают задачи. Ну не стучать же им по голове за то, что они не попали в оценки :)
Yak52
Раз - не попали, два - не попали, на третий можно и постучать, точнее постараться понять почему ошибаемся с прогнозом.
sashadzen Автор
Вот да, без стука только. Проводим ретро, анализируем задачи, разговариваем с сотрудником. Нет цели точно попасть в оценку. Есть цель грамотно планироваться)
FruTb
Всегда, абсолютно всегда, добавлять к оценке разработчика от 15% до 150% (в зависимости от квалификации сотрудника и размера фичи которая оценивается). Исполнитель редко может предсказать технические риски в задаче (если только это не абсолютно типовая задача которую он делал уже несколько раз)
sashadzen Автор
Мы всегда добавляем. Не 150%, правда. Но буфер закладываем. Разработчик может в оценку добавить буфер, когда задача для него новая. И менеджер заказчику буфер тоже добавляет.
Но бывают ситуации, когда и с этими условиями выходим за рамки. Разбираем, делаем выводы.
javalin
Мне больше всего понравился вариант эстимейта одного фрилансера..
время на разработку х2 от ожидаемого, дедлайн х4 от времени на разработку..
sashadzen Автор
Вероятно, у него жизнь удалась :)
drcolombo
Я все оценки всегда помножаю на
. Да, иногда перебор, но "в целом по больнице" довольно точно выходит ;)
sashadzen Автор
Известный метод, да) Но мы должны еще согласовывать предварительный бюджет с заказчиком, поэтому чуть меньше коэффициент используем)
SpiderEkb
Ну опытный исполнитель знает что всегда что-то может не так и не туда пойти и закладывается на такие случаи...
sashadzen Автор
Все верно. Но бывают задачи с которыми впервые сталкиваются) Но опять же, это все закладывается и на такие задачи делается ресерч предварительно)
SpiderEkb
У меня лично таких задач - каждая вторая. Типовых давно уже не бывает (вот так чтобы специально, может быть какой-то типовой кусок в рамках другой задачи).
Просто сразу декомпозируешь, смотришь где какой алгоритм применить.
Хуже когда "на оптимизацию" - "этот модуль работает слишком долго, нужно чтобы работал быстрее". Там надо понять используемый алгоритм, выявить узкие места, придумать как изменить или использовать что-то другое. Но тоже оцениваемое.
Не поддаются оценке только "исследовательские задачи". Когда есть некая сущность, надо разобраться как работает, как использовать, понять преимущества и недостатки, оценить граничные условия применимости, если нужно - разработать удобное АПИ для широкого использования. Но это технические задачи, не проектные. Там нет жестких сроков как правило.
sashadzen Автор
Спасибо, что делитесь опытом) Наверно, я немного неверно высказался. У нас +- также, как вы описали) Но есть над чем работать
AllexIn
Знаете, участвовал я в планировании под руководством менеджмента.
И сроки там всегда были не реалистичные.
Либо руководитель не давил и сроки были оверпереоценены, в итоге команда не работала в полную силу.
Либо руководитель давил и под его давление сроки указывались не реалистичные и команда чтобы успеть перерабатывала и выгорала.
Ни тот ни другой подход не давали высокой эффективности. По сути задача мотивации и эффективности разработчиков не решается через контроль, она решается через мотивацию и заинтересованность. Можете разработчиков заинтересовать и мотивировать - они будут давать результат. Не можете - подсчет секундочек проведенных за компом не приведет к росту эффективности.
sashadzen Автор
Мы как раз мотивируем, а не наказываем. Но подсчет часов нам необходим, так как разрабатываем проекты для заказчиков по ТМ.
SpiderEkb
Если исполнитель оценил и не попал, тому могут быть вполне объективные причины.
Другое дело, если это систематически происходит... Значит просто не умеет еще - надо помогать.
sashadzen Автор
Да, все верно. Это делается для того, чтобы это было наглядно видно)
Dynasaur
Надо вам попробовать самому что-то запланировать, ошибиться и получить по голове, чтобы не возникало желания стучать другим. Но скорее всего вам по голове никто не настучит за ошибку.
sashadzen Автор
Я планировал, так как сам был исполнителем. Но никто не стучал. Цель не настучать, а научиться декомпозировать и планировать задачи.
Dynasaur
так я не вам :-)
sashadzen Автор
Понял) Сильно напали в комментариях, френдли фаер))
GospodinKolhoznik
Продолжайте работать так, как работаете. Вы все правильно делаете. Либо ваш подход разумен и тогда вы придёте к процветанию либо он идиотский и тогда вы сами себя похороните. В любом случае, как бы не оказалось, всем от этого будет только лучше.
sashadzen Автор
Спасибо, будем процветать :)
SpiderEkb
У нас оценку времени принято доверять исполнителю. И, знаете, работает.
Сначала аналитику на его часть, потом разработчику на его.
Ну может быть только для совсем джунов оценку может сделать другой....
И вот почему-то не бывает ситуаций, когда задача на неделю, а исполнитель оценивает ее в месяц. Все достаточно честно (хотя разработчик немного всегда сверх закладывает на случай если какие-то сложности возникнут по ходу).
sashadzen Автор
А у нас также :)
Hokum
Вопрос адекватности менеджеров. Меня тоже смутил момент про неэффективность, но в целом, при нормальном использовании, понимать сколько времени было потрачено на задачу и сколько планировалось - это очень удобно. Это статистика на базе которой можно планировать и зачастую точнее, чем смогут это сделать разработчики. Я сам сталкивался с подобным, когда оценивал задачу в условные 4 часа, а менеджер говорил, что я что-то не учел, так как по статистики эта задача занимает условные 7 часов.
Но это надо, чтобы не было страха честно сообщать о затраченном времени. К этому не должны быть привязаны деньги. Тогда инструмент будет работать. В идеале, если при выходе за запланированное время, пишутся моменты о которых не подумали на планировании.
forthuse
Как учитывается психология работника которому поручили уcловное задание на планируемые 4-е часа, если он мыслит в рамках своего 8-ми часового рабочего дня? :)
(смогу/не смогу и тогда доделаю завтра/послезавтра ...)
P.S. Статистика в руках руководителя — это одно, а исполнителя, совсем другое.
Hokum
Так же как и когда время никак не фиксируется. Если человек на постоянной основе на зплачи которые требуют полдня тратит по целом дню, то рано или поздно к не у появятся вопросы, ну или не появятся, но и роста зарплаты у него не будет.
Плюс задача не одна, есть очередь, так что закончив одну четырех часовую задачу, можно перейти к другой. Тут уже задача руководителя обеспечить работника работой на полный рабочий день. Тут все очень сильно зависит от руководства. К тому же всегда был вариант сегодня уйти пораньше, что не бросать на середине следующую задачу, а завтра поработать подольше. Ну и в целом, тому чтобы доделать следующую задачу способствовало то, что переработки в пределах, вроде, 15% от рабочего времени оплачивались автоматом по трекеру. И в целом всех всё устраивало.
sashadzen Автор
У нас все также демократично) Можно уйти раньше, а затем задержаться.
Нам даже 100% попадание в оценки не важно. Если +- 20% попали, то все супер.
И переработать можно, это тоже оплатят)
Наверно, я слишком строго все в материале описал. Но хотелось показать конкретный пример, а все «если» в каждой компании свои.
«Люди и взаимодействие важнее процессов и инструментов»
sashadzen Автор
Ему не поручили на 4 часа задачу)
Как происходит:
1. Появляется задача, ее описывает аналитик.
2. Разработчик вместе с аналитиком и менеджером обсуждают задачу, чтобы все ее правильно понимали и не изобрели велосипед.
3. Разработчик декомпозирует задачу и проставляет оценку. При этом разработчик всегда может обратиться к старшему разработчику, если есть какие-то вопросы.
4. Менеджер апрувит оценку вместе со старшим разработчиком.
Получаем, что задача декомпозирована и оценена. Если при ее выполнение идет что-то не так, то разработчик сообщает менеджеру и команда это разбирает.
У нас все по доброму)
Krawler
Приятно такое читать, на самом деле. Молодцы!
sashadzen Автор
Благодарю!
Наверно, это надо было в материале развернуть, тогда бы было меньше таких вопросов в комментариях)
tommyangelo27
Всегда и любую? Или иногда не апрувит и переубеждает? ????
sashadzen Автор
Иногда не апрувит, да. Но тут переубеждает не значит, что на черное говорят белое)
Это аргументировано. И сотрудник также может аргументировать. В споре рождается истина)
javalin
А сам спор трекается и оплачивается? )
sashadzen Автор
Да, ведь планирование это часть процесса разработки)
spaceatmoon
Ага, ага. Из 4 часов 2 часа проболтали и иди крутись на оставшиеся часы, а потом объясняй почему у тебя лишние часы. Знаем, плавали.
sashadzen Автор
Как-то мы пришли только к одной задаче) Мы оцениваем пулл задач и если где-то проболтали и времени стало чуть больше – не страшно)
sashadzen Автор
Так и есть! Спасибо за ваш комментарий)
У нас нет цели наказать, а цель грамотно планироваться. Чтобы разбирать задачу, декомпозировать ее, на этапе планирования понимать, какие могут быть подводные камни.
Никто рублем не накажет, а наоборот разберут ситуацию вместе с менеджером и тимлидом)
aratsche
В скрам-мастерстве планируют время те же люди, что и код пишут (сотрудники). Это одна из основных идей.
sashadzen Автор
Так и у нас, разработчики оценивают задачи)
aaa_bbb
а кто иначе оценит точнее трудозатраты экспертов как не сами эксперты ) задача руководителя провести дополнительные оценки и риски, например, если для выполнения задачи нужно ждать решение соседнего отдела или вышестоящего подразделения, или вообще каких-нибудь внешних исполнителей (типа поставщиков или подрядчиков)
sashadzen Автор
Все так и есть) Менеджер дирижирует процесс)