lahomie93

Сочувствую, сам проходил через подобное. С какими формулировками вам отказывают? Что пишут в фидбеке?

Совет с планом и графиком - вполне хороший. Вам самим будет легче понять оставшиеся реальные объемы работы, а менеджером на "своем языке" получит понятную картину с тасками/сроками/трудозатратами, по которым он сможет договориться с бизнесом и обрести хотя бы иллюзию контроля над ситуацией.
Если менеджер пытается давить какими-то метафорами или цитатами из бизнес-книг, как в вашем случае, то:
1. Расслабиться, мысленно послать его нафиг и помнить, что нового мнеджера всегда легче найти чем разраба)
2. Предложить менеджеру рассказать о своем видении решения
3. Предложить составить план-график по задачам, как я писал в начале.

Менеджер "Нервничает" не от хорошей жизни и руководство его сношает за каждую просроченную задачу. Это я как бывший манагер говорю)

Я занимаюсь документированием для POS-системы, которая остоит из железа со своим интерфейсом, драйвера оберткой и внешним апи, с которым интегрируются мобилки/веб. На каждом слое данные маппятся в новую сущность. Мне нужно описать соотношение полей в старой и новой модели и бизнес-логику по которой происходит маппинг

Был, но он уже не актуален

Станислав Тамат, тимлид или сто

Отчасти согласен.

Но если все этапы проекта закрывать только после полной готовности предыдущего, то это приведет к неоправданному растягиванию сроков. И никто не захочет выпустить приложение спустя год после заключения контракта на разработку

Обычно работы происходят в таком порядке - заказчик готовит свою часть проекта для первых 1-2 этапов работы и после них я приступаю к разработке

Владимир Чернышев, то что вы описываете - это пример плохого менеджмента. Если разработчика постоянно "разрывают", отвлекают, то он не может сосредоточиться и выдать результат по конкретной задаче. Тут уже надо не о трэкинге говорить, а о том, чтобы делать комфортную среду для разработки - минимум ненужных митингов, комфортное рабочее место, тишина и т.д.

SerzN1, причем здесь кризис? в любой момент может сложиться ситуация, когда у разработчика низкая загрузка из-за ошибок менеджмента/продаж

⚡ Kotobotov ⚡,

сколько ты потратил часов на уборку, на поход в магазин,

нет, так как мне за это не платят и я своим временем предпочитаю распоряжаться без трэкинга. Но если я бы был домработником и мой работодатель захотел понимать сколько времени я трачу на эти дела, то пришлось бы трэкать

чтение документации

по работе по таскам с трэкаю только написание ТЗ и составление прототипов. Управление я трэкаю суммарно за день без детализации. Ранее, я стажировался в компании, где менеджеров каждый день, в конце дня просили написать мааленький отчет в скрамовском формате.

Так что да, менеджеры тоже этого не могут избежать, хотя требования к нам ниже, так как время команды разработчиков стоит намного дороже времени менеджера

ned4ded, давайте рассмотрим ваш пример:
1.

Я сначала думаю, какой минимальный функционал должен быть реализован в модуле.

. На этом этапе вы сделали декомпозицию задачи. К такой декомпозиции я попрошу вас проставить часы по подазадачам, сколько вы считаете нужным на работу по каждой из них.
2.

Дальше мне надо переварить эти решения и адаптировать под текущее приложение или придумать свою реализацию. Я наливаю себе 1,5 литра чая, сажусь с художественной книжкой часа на 2-3, периодически отвлекаясь на записи мыслей по работе в блокнот.

Ок, ваша задача требует ресерч. Что вам мешает создать отдельную подзадачу под ресерч и занести туда "2-3 часа за чашкой чая", которые вы потратили на ресерч. Результатом вашей работы будет продуманная архитектура модуля
3.

Я сажусь за пк, пишу решение, нахожу определенные узкие места в реализации и процесс повторяется. Сколько я писал код, часа 3-4 за пару дней?

Допустим для написание модуля нам надо было решить 3 подзадачи. При решении каждой подзадачи вы тратили час на написание нового кода, час на его отладку, час на обдумывание кода на бумажке. Итого по каждой задаче вам нужно будет отметить по три потраченных часа
4. По итогу мы получим, что в течение двух дней вы потратили 12 часов на решение задачи. Если применить скрамовское "велосити", то вы поработали с коэффициентом 12/16 = 0,75, что считается невыдающимся, но приемлимым результатом.

Как видите я измерил результат вашей работы в часах. Я смог вас переубедить?

И какое собачье дело работодателю может быть до времени работы.

Ну не знаю. Может быть потому что он платит вам зарплату?

⚡ Kotobotov ⚡, а потом разработчик не захочет делать эту таску, потом не захочет делать конкретный проект. И что мне делать с таким - смотреть на него и платить зарплату?

jeruthadam, это уже третье сообщение, где вы перешли откровенно на личность и пытаетесь меня оскорбить. Если вы не заметили, то я уважительно отношусь ко всем участникам темы и не думаю, что заслужил такой фамильярный тон. Влепил жалобу, надеюсь. модераторы разберутся

А теперь по существу:
1. Бенч - это ненормальная ситуация. Нормальная - когда разработчик работает на проекте у него все хорошо. Естественно, вины разработчика в том, что он попал на бенч нету и это ответственность менеджмента найти проект.
2. Я не спрашивал мнения о своей компетенции или моей компании. Если в отличие от меня вы работаете в "нормальной" айти компании, то могу только порадоваться за вас.
3. С чего вы решили, что я или моя компания заставляет разработчиков "нарезать круги вокруг зданий". Я где-то в теме писал про то, как распоряжаюсь свободными разрабами?

zakirovdamir, одна из целей трэкинга - это и есть одна из форм обратной связи. Я вижу статус, вижу потраченное время, коммиты по задачам.

Я ни в коем случае не исключаю обычное общение, но когда компания растет, то возникает потребность в системе, которая упорядочит работу

PxlFxr, согласен, что штрафы для компании это зашквар. Но идея с чатом для напоминаний мне нравится, возьму ее на вооружение

zakirovdamir, да. Я бы еще добавил недоооценку задачи, недоработанные требования, технические риски (например, баг в сдк, сторонней либе, проблема с оновлениями идешки)

Но рассмотрим только ваши.

В вашем подходе, когда я отказался от контроля процесса, я по факту узнаю, что оказывается:

1 Вы не могли найти решение задачи. Или на вас спихнули другую задачу, которая отняла время
2 Задача была неинтересна и вы просто 3 дня сидели ничего не делая
3 Сработал риск, про который я узнаю постфактум и уже никак на него повлиять нельзя

Теперь посмотрим, как я поступил бы, контролируя процесс:
1 После первого дня я узнал о ваших затруднениях и выделил бы в помощь более опытного разработчика или снял бы другие, менее приоритетные задачи
2 После первого дня я узнал, что задача вам неинтересна и смог бы ее поручить другому разработчику, либо замотивировать вас на ее выполнение.
3 Исправить "что-то случилось" сразу как оно "случилось"

И если сравнить наши подходы, то в вашем менеджер может:
1. Разгрести последствия
2. Провести ретроспективу

В моем подходе:
1. Сделать пункты 1 и 2, которые вы предложили
2. Сделать пункты, которые я описал в нашем кейсе
3. Если факап неизбежен, то предупредить об этом заказчика заранее и дать ему больше времени для маневра, изменить его ожиданиями

Я смог вас убедить в том, что контроль разработки важен и не является пустым "мозголюбством"?

zakirovdamir, да, вы правы, нужно провести ретроспективу. Какие основные причины срыва сроков на ваш взгляд бывают?

zakirovdamir, хорошо, я снял оценку с разработчика и заложил риски в допчасы. Тут мы договорились)

Дальше, вы пишете

нужно принимать результат, а не контролировать процесс

Допустим, я послушал вас совет и отказался от контроля процесса. Мы договорились о дате начала, дате окончания выполнения задачи, предоставил все api, дизайны, описание

Представим ситуацию, что вы работали над задачей сроком три дня и вы с ней не справились вовремя. Какие шаги я должен предпринимать как менеджер после такого?

⚡ Kotobotov ⚡, про результат согласен. Естественно, в первую очередь интересует. Как трэкинг времени противоречит работе на результат?

zakirovdamir, вы так и не ответили на мой вопрос) должен ли или не должен менеджер привлекать разработчика к оценке?