Здравствуйте, 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%.
Но, повторюсь, есть ряд активностей (аналитика, проектирование архитектуры, согласование со смежниками, их постоянного пропинывания, код-ревью) которые тут не учел.