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

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

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

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

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


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

И вообще, в ИТ-сфере всегда приходится изучать что-то новое.
Какой разумный баланс между "обучением" и непосредственно "работой"?
Сколько своего времени я могу уделить на изучение новых технологий, которые мне понадобятся в моей работе.
Нормально ли будет такое соотношение: 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>...то на это никакой заказчик не подпишется.
Ровно как на поиск под каждую новую задачу нового исполнителя по принципу "он должен сразу уметь решить поставленную задачу/решал ее в прошлом".