Как происходит: 1. Появляется задача, ее описывает аналитик. 2. Разработчик вместе с аналитиком и менеджером обсуждают задачу, чтобы все ее правильно понимали и не изобрели велосипед. 3. Разработчик декомпозирует задачу и проставляет оценку. При этом разработчик всегда может обратиться к старшему разработчику, если есть какие-то вопросы. 4. Менеджер апрувит оценку вместе со старшим разработчиком.
Получаем, что задача декомпозирована и оценена. Если при ее выполнение идет что-то не так, то разработчик сообщает менеджеру и команда это разбирает.
У нас нет цели наказать, а цель грамотно планироваться. Чтобы разбирать задачу, декомпозировать ее, на этапе планирования понимать, какие могут быть подводные камни.
Никто рублем не накажет, а наоборот разберут ситуацию вместе с менеджером и тимлидом)
Вот да, без стука только. Проводим ретро, анализируем задачи, разговариваем с сотрудником. Нет цели точно попасть в оценку. Есть цель грамотно планироваться)
Выше уже писал, что мы занимаемся проектной разработкой, работаем с заказчиками по ТМ.
Мы предварительно оцениваем задачи с разработчиками, затем согласовываем стоимость задач с заказчиками, а если что-то пошло не по плану? Должны обосновать, почему задача заняла больше времени, чем мы планировали.
Но все это не только для отчетности, как вы могли понять из статьи)
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
Спасибо за совет, наверное я сильно быканул в комментарии, раз столько минусов :)
Я привел сразу несколько причин в статье, и как раз «есть проблемы в работе» – это вопросы к запланировавшим, то есть менеджерам. Могли неверно организовать работы, плохо проработать бизнес логику и пр.
Планируют время на работу сотрудники, они предварительно оценивают задачи.
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
Да, говорим. Краткосрочно мы не получим прибыль, вы правы. Но заказчик расскажет об этом своим партнерам, сам придет с новым проектом и прибыли будет больше :)
В проекте свой менеджер, свой аналитик, дизайнер, команда в целом. Процессы понятны и от проекта к проекту не меняются. А на аустафф каждая метла метет по своему. Морально тяжело
Проектная разработка, если сильно упростить – это когда разрабатывается конкретный функционал под задачи заказчика.
ТМ – time & material, формат оплаты, когда заказчик оплачивает фактически затраченное время на разработку.
Благодарю!
Наверно, это надо было в материале развернуть, тогда бы было меньше таких вопросов в комментариях)
Ему не поручили на 4 часа задачу)
Как происходит:
1. Появляется задача, ее описывает аналитик.
2. Разработчик вместе с аналитиком и менеджером обсуждают задачу, чтобы все ее правильно понимали и не изобрели велосипед.
3. Разработчик декомпозирует задачу и проставляет оценку. При этом разработчик всегда может обратиться к старшему разработчику, если есть какие-то вопросы.
4. Менеджер апрувит оценку вместе со старшим разработчиком.
Получаем, что задача декомпозирована и оценена. Если при ее выполнение идет что-то не так, то разработчик сообщает менеджеру и команда это разбирает.
У нас все по доброму)
Так и есть! Спасибо за ваш комментарий)
У нас нет цели наказать, а цель грамотно планироваться. Чтобы разбирать задачу, декомпозировать ее, на этапе планирования понимать, какие могут быть подводные камни.
Никто рублем не накажет, а наоборот разберут ситуацию вместе с менеджером и тимлидом)
Вот да, без стука только. Проводим ретро, анализируем задачи, разговариваем с сотрудником. Нет цели точно попасть в оценку. Есть цель грамотно планироваться)
Ну почему ФСБ(
Выше уже писал, что мы занимаемся проектной разработкой, работаем с заказчиками по ТМ.
Мы предварительно оцениваем задачи с разработчиками, затем согласовываем стоимость задач с заказчиками, а если что-то пошло не по плану? Должны обосновать, почему задача заняла больше времени, чем мы планировали.
Но все это не только для отчетности, как вы могли понять из статьи)
Это не слежка :)
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
Спасибо, будем процветать :)
А запланировавший – это сотрудник, а не менеджер. Исполнители оценивают задачи. Ну не стучать же им по голове за то, что они не попали в оценки :)
Спасибо за совет, наверное я сильно быканул в комментарии, раз столько минусов :)
Я привел сразу несколько причин в статье, и как раз «есть проблемы в работе» – это вопросы к запланировавшим, то есть менеджерам. Могли неверно организовать работы, плохо проработать бизнес логику и пр.
Планируют время на работу сотрудники, они предварительно оценивают задачи.
Так как мы занимаемся проектной разработкой, то нам необходимо отслеживать показатели в том числе в часах. Ведь часы – это стоимость работы, которую заплатит заказчик.
Да, переезжать сразу стоило. Некоторые сервисы без предупреждения со всеми данными доступ отрубили
Что вы предлагаете?
Спасибо за обратную связь :)
А у этой карты много названий, почитайте: https://ru.wikipedia.org/wiki/Диаграмма_связей
Я бы написал – рад быть полезным, но в прошлый раз меня заминусили за такое))
К сожалению чек-лист не спасет от строгого техдира)
хммм... Можем вместе придумать))
В данном случае в тексте мы упоминаем только одну персону и такая ЦА действительно есть.
Но мы не говорим о том, что ЦА только такая, остальную мы показали на скриншоте. Конечно, многие будут у своих близких изначально спрашивать.
Но а если их нет в городе? Переехали в новый город, например
Да, говорим. Краткосрочно мы не получим прибыль, вы правы. Но заказчик расскажет об этом своим партнерам, сам придет с новым проектом и прибыли будет больше :)
Ну и карму не хочется портить))
В проекте свой менеджер, свой аналитик, дизайнер, команда в целом. Процессы понятны и от проекта к проекту не меняются. А на аустафф каждая метла метет по своему. Морально тяжело