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

I>Скорее про НЕ гугл.
I>Типа стартапа.
Вот мы и пришли ко вкусам. Для кого-то человечье говно — это вкусняшка, а для кого-то это говно и ничего более.

I>Крупная корпорация всегда не жопная компашка.
Всегда говно.

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

I>>Ну это только так кажеться. Для программиста тоже обычная работа — написать тесты.
V>Нет, но эффективному менеджеру не понять оное. Странно. что вы до сих пор не кончились, но осталось вам недолго. Где-то в 28 вас ликвидируют полностью.

Тут недано столкнулся с ситуацией, приятель рассказал — им на онбординге-обучении на менеджеров в одном из бигтехов сказали "вы должны знать, что ценность для компании IT-менеджера с девелоперским бекграундом в несколько раз выше чем любого разработчика" Причем это сказали в мотивации к анти синдрому самозванца — "Типа не бойтесь увольнять, даже если у вас получилась ошибка — вы для компании ценнее чем любой эксперт-архитектор на соответсвующих уровнях"

Так как опытных мереджеров именно с опытом разработки в 1000 раз сложнее найти чем любого разраба.

I>>Можно оценивать задачи в каких-то стандартных задачах.
V>Это каких?

Ну смотри — что такое сторипоинты слышал?
Нет — ну тогда не обьяснить.)

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

I>>Крупная корпорация всегда не жопная компашка.
V>Всегда говно.

Смотри — ЗП в разы выше, бонусы, собственные проекты, гибрид, рабочее место

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

I>Смотри — ЗП в разы выше, бонусы, собственные проекты, гибрид, рабочее место
О, "инсайд"... — Великим Мессией запахло.

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

I>Ну смотри — что такое сторипоинты слышал?
Ага, отличная штука нихера не делать, а на бабки начальство и владельцев бизнеса разводить.

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

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

__>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."

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

Я даже больше скажу, я иногда в таких случаях находил прямо куски кода, которые вызывали баг, при этом человек явно хотел добиться работы какого-то сценария. Но про этот сценарий не в курсе ни менеджер, ни product owner. То есть, условно говоря, баг можно пофиксить, просто удалив некий код, что вызовет непредсказуемое изменение поведения, возможно. Где-то у кого-то. Кому именно так надо было

То есть тебе вместо стены надо покрасить плюмбус, но что это, зачем и как это будет использоваться не знает никто.

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

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

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

Поинтересуйся мнением постановщика задачи о требуемом времени исполнения. От этого и исходи.

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

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

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

если понятно, что не всё заранее понятно, то закладывай пункты типа "распознать концепцию кода такого-то модуля"

потом проссумируй эти границы пунктов и вот тебе оценка

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

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

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

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

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

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

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

да, на гипотезу Коллатца я и сам потратил месяца 2

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

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

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

Эвристиками не поделитесь?

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>там всё в принципе алгоритмически ясно, просто бывает много сложных деталей
А дьявол обычно всегда в них скрывается.

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

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

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

S>Эвристиками не поделитесь?
— текучка с проекта
— хреновая инфраструктура — устаревшее оборудование и утилиты
— нервное руководство
— очень невнятная и медленная инфраструктура тестирования. никогда не понятно, что работает, а что сломано
— отсутствие хотя бы одного эксперта в области проекта в самой группе по проекту
— тянущиеся месяцами проблемы
— руководство требует решения проблем, отказываясь вникать в детали
— невозможность пообщаться с руководством по проекту, оно все время занято своими непонятными митингами, никак не сказывающимися на продукте

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

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

Если так делать в сша уволят до НГ

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

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

Тебе уже написали- дай estimate на проделывание estimate, т.к. с этим кодом/фичей/проектом ещё не работал. Если хотят estimate сразу — ну прикинб всё-таки на основе предыдущих 30 лет опыта, и добавь буфер 20%.

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

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

S>Если так делать в сша уволят до НГ
Как я уже писал — тебе в любом случае может понадобится защищать свою оценку сроков. Какую бы ты её не дал,- даже самую заниженную, всё равно к ней могут прикопаться. Их она может не устроить, и они потребуют её снизить ещё больше.