русских котов.

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

Интересует, как в вашей команде руководитель эээ... ведет руководство.
Спасибо.

На задание даётся срок. Выполнишь быстрее - можешь попинать балду. Не выполнишь - сам виноват. Если не выполнишь - будешь делать пока не выполнишь. Проблема заключается в том, что задание, на которое изначально было дано две недели, может растянуться на десять лет.

>Интересует, как в вашей команде руководитель эээ... ведет руководство.

11 лет назад - "ДАВАЙ"......
....позавчера - "ДАВАЙ"
вчера - "ДАВАЙ ЕЩЕ"
сегодня  - "ДАВАЙ БОЛЬШЕ"
завтра (скорее всего) - "ДАВАЙ ЕЩЕ БОЛЬШЕ"
послезавтра (вероятнее всего) - "ДАВАЙ ЕЩЕ  БОЛЬШЕ И СРОЧНО"........

PS: вчера 1-й раз услышал "СПАСИБО"

Сейчас я работаю на одну компанию, и мы используем задачи и веб сервис -
TrackStudio. Большая задача разбиватеся на мелкие (чтобы не больше двух дней на одну задачу), и под каждой задачей после ее завершения, пишется время.
Затем задача отправляется на тест, и тестировщик ее или закрывает если все ок, или переоткрывает.
Таким образом можно посмотреть суммарное время за любой период, и детализацию.

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

По конкретным задачам говоришь сколько времени требуется. Если сделал быстрее, берешь другую задачу. Если не успел вовремя, то продолжаешь доделывать. Есть периодические жесткие ("до такого-то числа") или не очень ("после пасхи") дедлайны связанные с релизом фич или презентациями для инвесторов/зевак/начальства, к ним желательно успевать. Но никакого жесткого учета времени нет, никому это нафиг не нужно.

> Нач. отдела разработки требует вести точный учет затраченного
> времени на задачу.

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

Jira

сроки могут определяться и заказчиком...
если нет - пишем более или менее рабочий кусок (срок мягкий. например, вторая половина следующего месяца), смотрим, тестим, обсуждаем возникшие проблемы, определяем следующий срок.
начальство? "пишете? хоть что-то работает? к концу года напишете? ну, работайте"
правда, отвлекают мелкие работы и поручения (текучка, бумажная бюрократия и т.д.) от того же начальства.

Кстати, (по моему) был ГОСТ нормы работы программиста. скоко-то там отлаженных строк в месяц. смешной такой ГОСТ был.

(Н)ачальник: сколько времени тебе нужно на этот кусок?
(П)рограммист: не знаю, кусок совсем новый, раньше такого не было.
Н: ну все-таки?
П: я же говорю - не знаю, может час, а может неделю.
Н: ну все-таки?
... Далее идет сказка про белого бычка. В итоге срок берется "с потолка".

Знакомо?

IMHO, [7] - самый разумный подход. Если вообще не единственно разумный.

Была как-то задача, для решения которой потребовалось написать около 30 классов - получилось примерно 2 тыс. строк. Понятно, что это лишь косвенные показатели трудоемкости, но все же показатели.

А сначала надо было продумать архитектуру - с прицелом на возможное в будущем изменение и/или расширение функционала, а также на повторное использование кода в будущих похожих задачах (которые реально предвиделись и которые действительно вскоре появились, всего было шесть однотипных задач).

Сделал первую. И услышал - "а что ты так долго возился, там же делать нечего, вот смотри как просто и ясно все получилось".

Блин! Так потому и долго, чтобы все было просто и ясно. А то, что на следующих 5 задачах сэкономил время в 5-кратном же размере - это не в счет.

> Лодочник ©   (13.07.17 06:27) [6]
> Jira

Это всего лишь инструмент.

>>(Н)ачальник: сколько времени тебе нужно на этот кусок?

А сколько времени уйдет, чтобы этот кусок не влиял на другие куски? В этом отношении в свободное время изучаю golang. Фактически Си с подходом питона.

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

А на вопрос сколько времени на работу некую потрачу, я иногда даже сам за себя ответить не могу. Раз помню сказал что неделя нужна, а справился за полдня...

> формализовать абсолютно все сложно

Не все сложно, когда задача понятна, в целом предсказуема или примитивна и легко "впихивается" в водопадную модель, тогда конечно легко распределить работу между сотрудниками, составить сроки и следить за выполнением.
А если в проекте много неопределенности глобального характера, и, например, как я сейчас не вижу толком, что в итоге будет. Соответственно я и сроки не могу определить, если с потолка только прикинуть. А хочется доделать до конца, а иначе все будет в моем понимании - куча потерянного рабочего времени впустую...
Вот как быть с временем, которое было потрачено на работу, не принесшую положительного результата (напрасную работу)? Как его оценивать?

> PS: вчера 1-й раз услышал "СПАСИБО"

Спасибо только от пользователей получаю. Этого хватает. :)

И учитывать ли в трудозатраты активные размышления по дороге домой и отладочные кошмары во сне?

> han_malign ©   (17.07.17 15:39) [15]
>
> И учитывать ли в трудозатраты активные размышления по дороге
> домой и отладочные кошмары во сне?
>

Лучше (полезнее для здоровья) сменить профессию. Уж я то это знаю! :)

> И учитывать ли в трудозатраты активные размышления по дороге
> домой и отладочные кошмары во сне?

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

> pavel_guzhanov ©   (18.07.17 12:11) [17]


> И никто эти часы, да еще и те, которые уходили на обдумывание
> по ночам, когда не спится, никто никак не оплачивал.

:) Ну прям как женском коллективе - а вы и во сне деньги зарабатываете :)

> TohaNik ©   (18.07.17 20:04) [18]

блин
> а вы и во сне деньги зарабатываете :)

а вы и по ночам деньги зарабатываете :)

pavel_guzhanov ©   (18.07.17 12:11) [17]


> И никто эти часы, да еще и те, которые уходили на обдумывание
> по ночам, когда не спится, никто никак не оплачивал.


Но никто тебя и не заставлял обдумывать по ночам вместо здорового сна. Сам виноват.

> Но никто тебя и не заставлял обдумывать по ночам вместо
> здорового сна. Сам виноват.

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

>Само собой. Но когда в башке крутится какая-то хрень, ........

.....
Мужик что бык: втемяшится
В башку какая блажь —
Колом ее оттудова
Не выбьешь: упираются,
Всяк на своем стоит!
.......
Н.А. Некрасов "Кому на Руси жить хорошо"

такую хрень предлагают делать не только программистам, но и другим специалистам.
сталкивался, например, в бухгалтерии, в плановом отделе, в отделе маркетинга.
а если еще заставляют писать сначала план на сегодня, а в конце - что сделал из него и сколько времени потратил, то из 8 часов рабочего времени 2 часа уходят на эти писульки.
в итоге не только никакой экономии времени (это ж все делается, чтоб меньше перекуров и чаепитий), а совсем наоборот, да еще и нервозность появляется, что сказывается отрицательно на работе.
программист может неделю думать и час кодить, а если всю неделю говнокодить бездумно, то и никакой поминутный контроль не улучшит ситуацию.

всё имхо

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

>Программирование довольно творческая профессия, а не механическая,
 Вот!!!!! Если убрать "довольно" то это будет "истина в последней инстанции",
.....  ну или почти. Нам программистам "Молоко за вредность (вы)давать надо" и бесплатные
путевки в дома творчества и вообще.......всякие блага и побольше
и зарплату платить из расчета:  1 строка отлаженного кода=1$.

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

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

тогда 1 строка отлаженного кода = 0.1$
выбирай

> выбирай

что тут выбирать? Глянь на зарплаты программистов

Если бы в программировании не было бы творчества, то его давно бы уже автоматизировали.

> Если бы в программировании не было бы творчества, то его
> давно бы уже автоматизировали.

в каком прекрасном мире мы живем! Куды ни глянь - одно творчество! Пойду знакомого дворника обрадую в свете сих открытий))

> картман ©   (20.07.17 17:28) [30]

Тетку, которая в метро внизу эскалатора в кабинке сидит, обрадуй :)

> DayGaykin ©   (20.07.17 16:06) [29]
>
> Если бы в программировании не было бы творчества, то его
> давно бы уже автоматизировали.

и вообще, что за стиль для творческого человека? Не стоит плодить сверх необходимого:

> Тетку, которая в метро внизу эскалатора в кабинке сидит,
>  обрадуй :)

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

> [30] картман ©   (20.07.17 17:28)
> Пойду знакомого дворника обрадую в свете сих открытий))

Махнул метлой - строка,
махнул ещё - поэма.

не выдержал мук творчества:

http://fishki.net/2339738-v-vashingtone-robot-ohrannik-utopilsja-v-fontane.html

))

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

Кстати, муки творчества как правило никто не учитывает и не оценивает, что обидно. Иной раз много тратится на это сил и нервов, чем на "автоматическое" кодирование, которое лучше идет под оценки.