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