Здравствуйте!

Все свое рабочее время я для себя условно делю на три вида: непосредственно работа, обучение, общение.
Потому что, для того, чтобы что-то сделать, выполнить свою работу, нужно:
— сначала разобраться в проблеме, получить новые знания, изучить что-то новое необходимое для выполнения работы;
— и только после этого можно выполнить действия, которые приводят к нужному результату, или созданию продукта.
Отдельно выделяю общение, коммуникации — по почте, по телефону, личное общение, — которые необходимы для решения рабочих вопросов.

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

Кто-нибудь ведет учет своих работ в таком разрезе?
Если да, то какое у вас примерно соотношение?
Или какое соотношение считаете "нормальным"?

А может быть нужно работы делить на другие виды?
По другим критериям?


Это распределение работ нужно для отчета работодателю-заказчику.
Заказчик готов платить только за фактические работы, а не за обучение.
Поэтому нам интересно знать процентное соотношение этих видов работ.
И какое соотношение является "нормальным".

И вообще, в ИТ-сфере всегда приходится изучать что-то новое.
Какой разумный баланс между "обучением" и непосредственно "работой"?
Сколько своего времени я могу уделить на изучение новых технологий, которые мне понадобятся в моей работе.
Нормально ли будет такое соотношение: 50% — изучение, 50% — работа?

Какой смысл в замерении этого распределения? Вам это для чего?

MC>Какой смысл в замерении этого распределения? Вам это для чего?

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

-- Скопирую свой ответ в шапку, чтобы это сразу было понятно.

E>Для отчета работодателю-заказчику.
E>Заказчик готов платить только за фактические работы, а не за обучение.
E>В свою очередь нам интересно знать каково "нормальное" соотношение этих видов работ.



Рассмотрим пример. Пофиксить трудноуловимый баг в древнем коде с многолетними наслоениями. Несколько дней может уйти на то, чтобы понять, а как оно вообще работает. А пофиксить потом одной строчкой.
И что, оплачивать будут 15 минут?

TMU>Рассмотрим пример. Пофиксить трудноуловимый баг в древнем коде с многолетними наслоениями. Несколько дней может уйти на то, чтобы понять, а как оно вообще работает. А пофиксить потом одной строчкой.
TMU>И что, оплачивать будут 15 минут?

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

А насчет оплаты...
Тут смотря что из себя представляет этот код.
И с чем разбирался человек.
Нужно разделить конкретный код, и библиотеки на которых он написан.
Если человек знаком со всеми библиотеками, на которых написан этот код, и он чисто искал проблему (зная особенности работы библиотек), то конечно это время должно быть оплачено.

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

Тут дело даже не в оплате, а в понимании того, на что уходит время.
Ясное дело, что в нашей ИТ-сфере обучение всему новому — занимает значительную часть времени.

Дело в том, чтобы найти разумный баланс в нашей работе.
Сколько своего времени я могу уделить на изучение новых технологий, которые мне понадобятся в моей работе.
Например, нормально ли будет такое соотношение: 50% — изучение, 50% — работа?

E>Для отчета работодателю-заказчику.
E>Заказчик готов платить только за фактические работы, а не за обучение.

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

E>В свою очередь нам интересно знать каково "нормальное" соотношение этих видов работ.

Нет никакого нормального соотношения... но есть наблюдения: когда менеджмент компании начинает вводить такого рода бесмысленные метрики — значит компания скатывается в УГ.

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

Отличный у нас заказчик!
Как раз так и есть, как вы пишите.
Его касается только дело, а сколько мы там изучали — его не интересует и не касается.


DB>Нет никакого нормального соотношения...

Да ну?
А про статистику слышали?


DB>... но есть наблюдения: когда менеджмент компании начинает вводить такого рода бесмысленные метрики — значит компания скатывается в УГ.

Для чего это надо — я уже написал — нужна просто статистика.
Эту статистику будем использовать для планирования работы на год-два вперед.
Чтобы знать сколько времени из рабочих дней в предстоящем году уйдет на учебу.

Здравствуйте, es3000, Вы писали:



E>Это распределение работ нужно для отчета работодателю-заказчику.
E>Заказчик готов платить только за фактические работы, а не за обучение.
Если изучение чего-то было связано с необходимостью решить какую-то задачу, то оно должно идти в общий рейт. Если обучение было "для себя" и заказчику в рамках текущих выполняемых работ не нужно — то только за свой счет.
Все, что по другому — личные "бзики" заказчика/исполнителя.

Здравствуйте, es3000, Вы писали:

DB>>Плохой заказчик, или отношения с ним плохие. Для заказчика должны быть только фактические работы (реализация фич, правка багов и тд.). А уж то, что для реализации какой-то фичи пришлось что-то обсудить, что-то изучить, что-то реализовать, касаться его не должно.
E>Отличный у нас заказчик!

похоже на "сам себя не похвалишь..."

E>Как раз так и есть, как вы пишите.

как раз и нет:

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

E>Для чего это надо — я уже написал — нужна просто статистика.
E>Эту статистику будем использовать для планирования работы на год-два вперед.
E>Чтобы знать сколько времени из рабочих дней в предстоящем году уйдет на учебу.

невозможно знать, сколько времени уйдёт на учёбу. это зависит от задач, изучаемой темы и навыков исполнителя.
поэтому разумный вариант — это выставить верхнюю планку по затратам на обучение. если проект выходит за этот бюджет, значит пора фиксировать убытки.
если бюджет равен нулю, то можно сразу бросать.
на общение же лучше тратить не более 20-25%% времени в месяц.

Здравствуйте, De-Bill, Вы писали:

E>>Для отчета работодателю-заказчику.
E>>Заказчик готов платить только за фактические работы, а не за обучение.
DB>Плохой заказчик, или отношения с ним плохие. Для заказчика должны быть только фактические работы (реализация фич, правка багов и
На самом деле это es3000 чувак альтернативного менеджмента. Почитай его прошлые пассажи

K>На самом деле это es3000 чувак альтернативного менеджмента

Что значит "альтернативный менеджмент"?


K>Почитай его прошлые пассажи

Ты читал все мои пассажи?? Польщен таким внимание к моей персоне.
А что в моих пассажах тебя навело на мысль об "альтернативном менеджменте"?

F>как раз и нет:
F>

F>Это распределение работ нужно для отчета работодателю-заказчику.
F>Заказчик готов платить только за фактические работы, а не за обучение.

как раз да.
вот De-Bill тоже самое писал:

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

F>невозможно знать, сколько времени уйдёт на учёбу. это зависит от задач, изучаемой темы и навыков исполнителя.

Согласен. Конечно, заранее невозможно знать.
Меня интересует статистика, то есть то, что уже точно известно из практической работы.


F>поэтому разумный вариант — это выставить верхнюю планку по затратам на обучение. если проект выходит за этот бюджет, значит пора фиксировать убытки.
F>если бюджет равен нулю, то можно сразу бросать.
F>на общение же лучше тратить не более 20-25%% времени в месяц.

Вот это дельные предложения.
Спасибо, учтем в работе.

Здравствуйте, es3000, Вы писали:

E>вот De-Bill тоже самое писал:
E>

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

обучение, обсуждение оплачивается в рамках этих работ.

A>Если изучение чего-то было связано с необходимостью решить какую-то задачу, то оно должно идти в общий рейт. Если обучение было "для себя" и заказчику в рамках текущих выполняемых работ не нужно — то только за свой счет.
A>Все, что по другому — личные "бзики" заказчика/исполнителя.

Конечно, согласен.
Так и есть на самом деле.
Я с этим нигде и не спорил.

Я просто хотел узнать статистику у участников этого форума по выполненным проектам за последнее время, например за 2-3 года.

Вы своей статистикой можете поделиться?

F>обучение, обсуждение оплачивается в рамках этих работ.

Конечно.
Обучение и общение, затраченные на решение задачи, должно оплачиваться.
Однако, всему есть предел.

Если для решения какой-то задачи нужно студента на 5 лет в ВУЗ отправить учиться,
то на это никакой заказчик не подпишется.

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

А просто хочется знать статистику.
Какое соотношение обычно на ваших проектах?
Какое соотношение "работа"-"изучение"-"общение" вы считаете разумным?
Какие еще виды работ имеет смысл выделить?

Здравствуйте, es3000, Вы писали:

E>Здравствуйте!

E>Все свое рабочее время я для себя условно делю на три вида: непосредственно работа, обучение, общение.
А как считать время, когда я за день час-два вишу на телефоне со смежниками, одновременно запуская код и смотрю логи, что, откуда и кому пришло? Вроде и общение, и разработка в рамках интеграции в одном флаконе.
Ну ладно, общение еще чисто теоретически можно выделить в отдельную область по признаку "говоришь/слушешь => общаешься"
А как выделить обучение?
Если человеку дали второй раз ту же самую задачу, он ведь быстрее ее выполнит? Значит, в процессе работы чему-то обучился. Отделить одно от другого -хз как. Вопрос субъективный.

Поэтому вердикт: Лепите отчеты, какие хотите, чтобы навешать заказчику любую лапшу, которая будет вам выгодна.

Если же вы заказчик — то будьте готовы, что отчеты будут содержать лапшу.

Здравствуйте, es3000, Вы писали:

E>Если для решения какой-то задачи нужно студента на 5 лет в ВУЗ отправить учиться,
E>то на это никакой заказчик не подпишется.

дело тут вовсе не в желаниях заказчика.
срок проекта должен быть оговорен заранее. и там уже будет ясно, можно ли отправить студента на 5 лет в ВУЗ. да ещё и кормить его за это.

E>А просто хочется знать статистику.
E>Какое соотношение обычно на ваших проектах?

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

E>Какое соотношение "работа"-"изучение"-"общение" вы считаете разумным?

90-0-10
но у меня такое было лишь однажды.
остальные случаи были с известной долей рандома.

E>Какие еще виды работ имеет смысл выделить?

формулирование задач, управление командой и тестирование.

G>А как выделить обучение?
G>Если человеку дали второй раз ту же самую задачу, он ведь быстрее ее выполнит? Значит, в процессе работы чему-то обучился. Отделить одно от другого -хз как. Вопрос субъективный.

На самом деле просто отделить одно от другого: как только информации достаточно, чтобы выработать решение — значит обучение закончилось.
Получается в первый раз твои работы можно разделить так например: обучение — 1 час, выполнение — 1 час.
Второй раз та же самая задача: выполнение — 1 час.


G>Поэтому вердикт: Лепите отчеты, какие хотите, чтобы навешать заказчику любую лапшу, которая будет вам выгодна.
G>Если же вы заказчик — то будьте готовы, что отчеты будут содержать лапшу.

Непонятно, зачем лепить лапшу.
Почему нельзя в отчет написать то, что отражает реальность?

F>на начальных этапах и тестировании в условиях приближённых к боевым изучение может достигать 50-80% в неделю. на начальных этапах обычно процент ниже, но недель с такой загрузкой больше. на последних, соответственно, наоборот.

F>90-0-10
F>но у меня такое было лишь однажды.

Противоречие какое-то.
Если обучение было "0" лишь однажды, почему тогда нормальным ты считаешь "0"?

F>остальные случаи были с известной долей рандома.
Ну это рандом имеет же какие-то границы?
От хх% до хх%

E>...то на это никакой заказчик не подпишется.
Ровно как на поиск под каждую новую задачу нового исполнителя по принципу "он должен сразу уметь решить поставленную задачу/решал ее в прошлом".

Здравствуйте, es3000, Вы писали:

K>>На самом деле это es3000 чувак альтернативного менеджмента

E>Что значит "альтернативный менеджмент"?
Это то, чем Вы занимаетесь. Отношение к вашему стилю управления было озвучено в других тредах.
K>>Почитай его прошлые пассажи
E>А что в моих пассажах тебя навело на мысль об "альтернативном менеджменте"?
Перечитайте треды. Вряд ли вы поймёте аргументацию, но всё же.

K>Это то, чем Вы занимаетесь. Отношение к вашему стилю управления было озвучено в других тредах.
K>Перечитайте треды. Вряд ли вы поймёте аргументацию, но всё же.

Намеки конечно я не пойму, как же их понять?
Начал говорить, так давай конкретную аргументацию.

Чем таким особенным я занимаюсь?
Чем отличается мой стиль управления от общепринятого?

M>Ровно как на поиск под каждую новую задачу нового исполнителя по принципу "он должен сразу уметь решить поставленную задачу/решал ее в прошлом".

Все будет зависеть от данной задачи и объема обучения.
Если на обучение имеющихся исполнителей понадобиться больше времени и средств, чем на поиск новых,
то естественно Заказчик наберет новых исполнителей.

Всему есть разумные пределы.

Здравствуйте, es3000, Вы писали:

F>>на начальных этапах и тестировании в условиях приближённых к боевым изучение может достигать 50-80% в неделю. на начальных этапах обычно процент ниже, но недель с такой загрузкой больше. на последних, соответственно, наоборот.
F>>90-0-10
F>>но у меня такое было лишь однажды.
E>Противоречие какое-то.
E>Если обучение было "0" лишь однажды, почему тогда нормальным ты считаешь "0"?

потому что ненормально лезть туда, где почти ничего не знаешь. а у меня такое постоянно.

F>>остальные случаи были с известной долей рандома.
E>Ну это рандом имеет же какие-то границы?
E>От хх% до хх%

от 40% до 60% в среднем за всё время проекта.

Здравствуйте, es3000, Вы писали:

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

Есть смысл отделить "обучение" (изучение технологий и инструментов) от исследования (поиск решения конкретной проблемы, выбор оптимального из нескольких решений).
Скорее всего, первое не должно попадать в "смету" для заказчика, а второе — должно.

E>Кто-нибудь ведет учет своих работ в таком разрезе?

Нет (смысла не вижу).

E>Или какое соотношение считаете "нормальным"?

Сильно зависит и от задач, и от коллектива, и от методов организации работ / стиля управления.
Думаю, нет смысла узнавать "среднюю температуру по больнице", но есть смысл ограничиться своей "палатой".

E>А может быть нужно работы делить на другие виды?
E>По другим критериям?

Исследования — отдельным пунктом (если есть).

E>Сколько своего времени я могу уделить на изучение новых технологий, которые мне понадобятся в моей работе.
(выделение bold-ом — моё)

100%

Другой вопрос: Сколько оплачиваемого работодателем времени я могу уделить на изучение новых технологий, которые мне понадобятся в моей работе?

Зависит от отношений с работодателем (иногда — на сколько сторгуетесь). От 0% до 100% (100% — если, допустим, заказов нет, но ожидаются, а вы на бессрочном контракте и постоянной ставке.)

E>Нормально ли будет такое соотношение: 50% — изучение, 50% — работа?

Если у бизнеса есть норма прибыли — её соблюдение и есть критерий нормы для всего остального. IMHO.

TMU>И что, оплачивать будут 15 минут?

Ага, а фотографу оплачивать только 1/1000 секунды времени работы (или сколько там экспозиция) за кадр.

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

E>По крайней мере надо понимать, что другой человек, знакомы с этими библиотеками, проблему нашел бы быстрее.

И запросил более высокую оплату за свой труд, кроме того, потребуется время на его поиск...

E>Его касается только дело, а сколько мы там изучали — его не интересует и не касается.

Классическая отмазка, чтобы меньше платить. По сути, стоимость работы на рынке определяется спросом и предложением. Если твой заказчик может найти исполнителя с приемлемым уровнем качества и меньшей ценой, то ему вообще не нужно с тобой разговаривать — ты ему не нужен. А такие приемы типа: "найти до чего докопаться и на этом основании понизить оплату," — это классическая разводка для лоха.

IMHO, идеальная схема — это повременная оплата + регулярные отчеты по проделанной работе + предоплата за неделю + возможность обеих сторон в любой момент отказаться от сотрудничества (в этом случае не отработанные до конца недели средства возвращаются). Работодатель заинтересован в том, чтобы четко и понятно ставить задачи, исполнитель — регулярно продвигать выполнение проекта, не скатываясь в фанатизм игр с новыми технологиями.

Здравствуйте, es3000, Вы писали:

G>>А как выделить обучение?
G>>Если человеку дали второй раз ту же самую задачу, он ведь быстрее ее выполнит? Значит, в процессе работы чему-то обучился. Отделить одно от другого -хз как. Вопрос субъективный.

E>На самом деле просто отделить одно от другого: как только информации достаточно, чтобы выработать решение — значит обучение закончилось.
E>Получается в первый раз твои работы можно разделить так например: обучение — 1 час, выполнение — 1 час.
E>Второй раз та же самая задача: выполнение — 1 час.
Ну мы же не говорим об академической дисциплине. Типа, сначала на лекции рассказывают как решать дифуры, а потом на практике берешь и решаешь.
Как правило, работа в той области, которую неплохо знаешь устроена по-другому.
въезжаешь в задачу, насилуешь аналитика (если такового нет — сам выступаешь в этой роли), прорабатываешь архитектуру, проводишь некоторые исследовательские работы, согласуешь рамки полученных ограничений, кодишь, периодически тестишь/показываешь/задаешь уточняющие вопросы, эпизодически переделываешь, постоянно-постоянно рефакторишь, в процессе кодинга натыкаешься на то, что где-то что-то забыл или не знал. Начиная с синтаксиса и конкретными решениями конкретныъ проблем и заканчивая best practices

Например, не помню и не хочу помнить я команду merge для сиквела (я на нем только 10% вермени работаю, могу позволить себе не знать всего). Полез, посмотрел. Потом писал. Не заработало. Исправлял. Что из этого обучение? время гугления? время исправления?
Напрмер, че-та не пишутся логи. Полез смотреть, как конфигурируется логгер. Смотреть примеры. Стырил нужный конфиг и допилил напильником. Что есть обучение? Время гугления? время пиления напильником?
И ведь это все итеративно.
Ладно, это простые примеры. Вот, скажем, сервис, который тебе достался в наследство, периодически подвисает. И ты его и так и этак крутишь, чтобы изучить и понять что там происходит. Это что, врея ковыряния в говнокоде — обучение?
Гробишь пару дней, выясняешь, что повисает отправитель в topic через SonicMQ. Лезешь изучать, как там топики устроены. Ставишь эксперименты. Общаешься с поддержкой. Еше неделя уходит. Потом выясняешь проблему, плюешься на архитектуру SonicMQ и переводишь durable topic на несколько очередей. Потому что топики — это зло. Переводишь быстро, написав и протестив все за полдня.

Как отделить, где я тут разрабатывал, а где — учил?

G>>Поэтому вердикт: Лепите отчеты, какие хотите, чтобы навешать заказчику любую лапшу, которая будет вам выгодна.
G>>Если же вы заказчик — то будьте готовы, что отчеты будут содержать лапшу.

E>Непонятно, зачем лепить лапшу.
E>Почему нельзя в отчет написать то, что отражает реальность?

Когда на основании метрик принимаются финансовые решения — обычно получается плохо.
А если в метрику лепится субъективное понятие — получится еще хуже. Даже уродская метрика в виде числа строк кода и то лучше — там хотя бы измерить проще.
Мы вот даже друг с другом не можем договориться, что считать обучением. А когда возникнет вопрос между исполнителем и заказчиком, и это будет вопрос о деньгах — разночтения гарантированы.

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

G>Когда на основании метрик принимаются финансовые решения — обычно получается плохо.
G>А если в метрику лепится субъективное понятие — получится еще хуже. Даже уродская метрика в виде числа строк кода и то лучше — там хотя бы измерить проще.
G>Мы вот даже друг с другом не можем договориться, что считать обучением. А когда возникнет вопрос между исполнителем и заказчиком, и это будет вопрос о деньгах — разночтения гарантированы.

G>Раз заказчик хочет странных отчетов, то я и предлагаю заранее лепить их в выгодном для себя виде.

Да дело даже не в заказчике.

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

Это я к тому, что между обучением и самой работой должен быть какой-то баланс.
А какой?
Как его измерить?
Я предложил в процентном соотношении.
Да, в этом есть определенные трудности, как подсчитать это соотношение.

Но это уже другой вопрос как считать.
Для начала надо определиться и поставить границы.
Например, цель такая: 50% — обучение, 50% — работа. Это норма.
Перекос — уже плохо.

Здравствуйте, es3000, Вы писали:


G>>Когда на основании метрик принимаются финансовые решения — обычно получается плохо.
G>>А если в метрику лепится субъективное понятие — получится еще хуже. Даже уродская метрика в виде числа строк кода и то лучше — там хотя бы измерить проще.
G>>Мы вот даже друг с другом не можем договориться, что считать обучением. А когда возникнет вопрос между исполнителем и заказчиком, и это будет вопрос о деньгах — разночтения гарантированы.

G>>Раз заказчик хочет странных отчетов, то я и предлагаю заранее лепить их в выгодном для себя виде.

E>Да дело даже не в заказчике.

E>Ты же согласен, что в нашей работе обязательно есть обучение.
Нет, не согласен.
Возможно, проблема в том, что ты так и не определил, что такое "обучение". И не ответил ни на один из предыдущих вопросов, является ли конкретно приведенный пример обучением.
Если так уж хочется выделить обучение, я бы разделял обучение и исследование.
Обучение — суть получение новых знаний, опосредовано связанных с задачей. Т.е. почитать книжки, посмотреть видюшки, выполнить тренировочные задания.
Исследование — получение знаний, проведение экспериментов, направленных непосредственно на решение задачи.

Так вот, если мне дают задачу в рамка моего стека (например, .NET+SQL) — время обчуения равно 0. Абсолютный ноль. Мне не надо читать книги по .NET чтобы приступить к работе. Это я делаю и так в рамках повышения квалификации в свободное время.
А время исследования — вполне ненулевое. Проблема- отделить время исследования от времени реализации.

E>А теперь представь, кто-то обучается-обучается, неделю-месяц-полгода, и ни строчки кода не написал.
E>Это же ненормально?
Нет, неделю-месяц обучатся — не нормально. Если это не стажер.
Но сколько проводить исследования — зависит от проекта. Может быть, месяц исследований — вполне нормально.

E>Это я к тому, что между обучением и самой работой должен быть какой-то баланс.
E>А какой?
E>Как его измерить?
E>Я предложил в процентном соотношении.

Ок. приведу свою статистику, насколько вспомню.
Если выкинуть обязанности тимлида, то среди оставшегося на новом проекте можно условно посчитать обучение 0-10%. исследование 20-50%. Кодинг 40-70%.
Но, повторюсь, есть ряд активностей (аналитика, проектирование архитектуры, согласование со смежниками, их постоянного пропинывания, код-ревью) которые тут не учел.