Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Могу сказать, что при оценке потребного времени на выполнение задач, помимо декомпозиции, надо отталкиваться от реальных фактических затрат времени на выполнение различных видов задач. Т.е. не умозрительно назначать сроки, с тенденцией ставить удобные тебе красивые числа. А иметь коллекцию замеренных фактических сроков на те или иные дела, причём с учётом особенностей их выполнения. На скорую руку там, или тщательно. Буквально как сметчики в строительстве работают.
Таким образом, жизненно важно иметь коллекцию таких замеров, создавать её, замерять время тех или иных дел.
Но это ещё не всё. Далее надо делать поправки на получившиеся оценки — на собственную усталость, сложность работы, возможность загвоздок, насколько напряженно ты готов работать. Закладывать резервы времени.
И это ещё не всё. Все получающиеся цифры, и особенно разбивку, как они получаются, надо держать строго про себя. Так как далее в дело вступает политика. Когда сообразно политической ситуации в команде, тебе надо искажать сроки в большую или меньшую сторону. Дабы, например, пообещать что всё скоро будет сделано. Или наоборот, представить задачу как очень сложную, и выбить под неё побольше ресурсов. Озвучиваются, разумеется, только отфильтрованные после политики цифры. Но при всей политике, важно осознавать во что реально всё обойдётся, на что можно рассчитывать. Иметь трезвую голову и собственные реальные оценки.
Ещё можно давать не одну конкретную цифру, а диапазон. Особенно такое уместно при высокой степени неопределённости. Если просят конкретную цифру, назови сначала диапазон 3-6 рабочих дней например, потом скажи раз просят цифру, то 6 дней. И потом добавь, что возможно управишься быстрее.
Да и вообще, сколько закладывать резервы времени для уверенности что ты действительно всё сделаешь к озвученному сроку, надо соразмерно степени твёрдости гарантий, которые надо обеспечить и цене ошибки/срыва сроков. Скажем, если надо успеть к рождеству или там дате, когда состоится конференция, на которой надо показать софтину — это одно. Ты никак подвинуть и повлиять не можешь. А с кем-то ещё можно договориться о переносе сроков и цена вопроса будет просто некоторое раздражение начальства. Это другая история.
Хочу добавить, что я вот трекаю, сколько времени нужно мне на всякие дела. Ответственно заявляю, что обыватели очень часто любят всё упрощать, и вместо реальных цифр иметь дело с воображаемыми красивыми, круглыми удобными цифрами. Вот например, не 46 минут, а 1 час. Ещё есть тенденция избегать неудобных, всё ломающих цифр. Скажем, мы будем закладывать на задачу 1 час, даже если по факту это создаст проблемы, мы окажемся в цейноте, и по-хорошему надо было закладывать все 80 минут. Но лишние 20 минут так неудобны! Они всё ломают! Неудобно считать, некрасиво выглядит и вообще неприятно даже помыслить, что фактическое время больше психологической отметки в 1 час. Ну и т.д. всё в таком духе.
Однако цифры из реальности сплошь и рядом некрасивые. Посмотрите цифры денег у себя на банковском счете, в кошельке — они очень редко круглые и красивые. Посмотрите расписание поездов на вокзале. Время прибытия/отправления также сплошь и рядом какие-то совсем не круглые числа. Границы стран — куда ни посмотри, они рваные и неправильной формы. Красивые прямые линии редко встречаются, и просто кричат своей искуственностью.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Вообще, это задача не разраба, хотя последние и привлекаются для оценки конечных подзадач, но только для задач, которые они уже решали.
Здесь на подфоруме управления проектами когда-то обсуждались похожие вопросы (отдельное спасибо Gaperton).
Рекомендую декомпозировать и давать оценки в диаппазоне: оптимистическая-пессимистическая. Учитывая когнитивное искажение "сверхоптимизм", то оптимистическую я бы умножал хотя бы на 1.5, а пессимистическую х3.
Если есть исследовательская часть (например, нужно сначала разобраться в коде/технологии), то такая блокирующая подзадача оценивается отдельно с указанием что все подзачи после нее могут изменить оценку по результатам.
Здравствуйте, so5team, Вы писали: S>Здравствуйте, sergey2b, Вы писали: S>>Теперь требуют оценить время точно S>"Бегите, глупцы!" (с) S>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме.
да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
Здравствуйте, sergey2b, Вы писали:
S>Я насколько возможно культурно это же сказал
S>Мотивируя что готов писать репорты о потраченном времени без вопросов S>Что просто check out и компиляция нужно куска занимает минут 20 а иногда и несколько часов
Это прям факап. Ты точно ошибся. Тебя такое писать никто не происил.
Теперь ты выглядишь как парень который будет классно обьяснять почему сроки сорваны. Ты точно этого хотел?
Чтобы оценить трудоемкость задачи надо просто составить план.
1 Планиную потратить на обзорное исследование кода — столько то
2 Планиную потратить на понимание проблемы — столько то
3 Планиную потратить на выработка вырианта решения проблемы — столько то
4 Обычно на ревью уходить — столько то
Здравствуйте, sergey2b, Вы писали:
S>Я это понимаю S>И не знаю что отвечать когда от меня назвать цифру немедленно
Если требуют цифру немедленно, можно говорить грубую оценку по верхней планке, с запасом. И говорить, что это крайне предварительная оценка, нуждающаяся в уточнении. Какой вопрос, такой и ответ.
И вообще, есть подход с уточняющимися оценками. Когда сначала берётся очень грубая оценка, потом делаются прикидки, оценка уточняется. Когда начинаешь делать задачу, углубляешься, оценка ещё уточняется.
К тому же умение оценивать проекты это задача менеджера проекта, оно не входит в компетенцию разработчика. Если обычный программист может оценить время, то он считай уже сам менеджер проекта и оригинального менеджера проекта можно гнать в шею, так как он не нужен. Разделение ролей в программировании придумали вовсе не для того чтобы кто-то приходил и требовал выполнить за него свою работу.
И я почитал комментарии, типа нужно точно оценить время для менеджера проекта. Оценишь не верно уволят? Ну я никогда не завидовал действующим программистам. Из своего опыта могу сказать, что когда происходят факапы с другими людьми в программировании, со всякими начальниками, общей неорганизованности и прочего, есть два пути решающие проблему.
1. Повысить свою компетентность.
2. Уволиться на хрен.
дополнительные пути
3. Работать как можешь ожидая увольнения.
4. И с начальством подружиться, и поймать перо жар птицы.
Или можешь просто ждать, когда тебя уволят за невыполнение задач в срок или намеренное затягивание задач, когда менеджер проекта почему-то спрашивает тебя сколько должна занимать задача и она должна быть сделана ещё вчера, хотя её поставили сегодня. А дальше классические 50/50, тебя или уволят, или нет. Потому что я сомневаюсь, что можно сильно повысить компетентность ещё и работая впридачу.
Есть ещё другой путь, то о чём так любят рассуждать хрюши, обретение софт скилов, то есть научиться болтологии, дружбе с начальством и прочему. Ведь главное не работать, главное уметь отбалтываться.
И мои последние пять копеек насчёт того, что некоторые говорят, что такое начальство дураки и не лечатся. Они дураки только пока не найдут рабов дураков кинув им кость. Пока есть деньги платить зарплаты можно быть дураками и бизнес не рухнет благодаря наёмным программистам, которые гробят своё физическое и психическое здоровье, лишь бы выслужится. Так кто дурак?
Тоже самое практически и в странах. У власти стоят ничтожества с точки зрения технологических умений, но многие люди их восхваляют. Достижения инженеров приписываются лидерам страны. С чего бы? А неудачи это видимо народ виноват, а не полицаи с автоматами загнобили очередного бизнесмена. Всё это рабская психология людей.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
— Сколько времени вам понадобится?
— Точно не знаю
— Можете хотя бы грубо сказать?
— Да х%& его знает бл@%&!
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Ну так а ИИ на что? Даешь ему вводные данные, он оценивает.
Следующим шагом говоришь реализовать, он реализует, в 100 раз быстрее оценки. И все довольны.
S>Для примера мне дали написать тест, оценили на 2-3 часа S>я уже 4 день разбираюсь как работает код тк комментариев и документации нет
Звучит как идеальная задача для нейросети
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, __kot2, Вы писали:
__>>С опытом у меня выработался нюх на неуспешные проекты и если я вижу, что сотрудники только делают вид, что в чемто разбираются, то просто сваливаю оттуда сильно не вникая в детали о причинах существования таких проектов вообще. Которых, по моему мнению, большинство
S>Эвристиками не поделитесь?
— текучка с проекта
— хреновая инфраструктура — устаревшее оборудование и утилиты
— нервное руководство
— очень невнятная и медленная инфраструктура тестирования. никогда не понятно, что работает, а что сломано
— отсутствие хотя бы одного эксперта в области проекта в самой группе по проекту
— тянущиеся месяцами проблемы
— руководство требует решения проблем, отказываясь вникать в детали
— невозможность пообщаться с руководством по проекту, оно все время занято своими непонятными митингами, никак не сказывающимися на продукте
Здравствуйте, jamesq, Вы писали:
J>Здравствуйте, sergey2b, Вы писали:
S>>Я это понимаю S>>И не знаю что отвечать когда от меня назвать цифру немедленно
J>Если требуют цифру немедленно, можно говорить грубую оценку по верхней планке, с запасом. И говорить, что это крайне предварительная оценка, нуждающаяся в уточнении. Какой вопрос, такой и ответ.
Стандартное развитие событий говноменеджмента «а вот Вася сказал, что это можно сделать в три раза быстрее, почему ты называешь такой срок? Ты хочешь меня обмануть или оцениваешь себя в три раза хуже Васи?»
J>И вообще, есть подход с уточняющимися оценками. Когда сначала берётся очень грубая оценка, потом делаются прикидки, оценка уточняется. Когда начинаешь делать задачу, углубляешься, оценка ещё уточняется.
Правильное айкидо заключается в том, чтобы вообще уходить нафиг с таких задач, а не кидаться на амбразуру, героически их закрывая
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Как-то так:
— Уведомляешь, что код новый, и оценка может быть неточной
— Разбиваешь на подзадачи — оцениваешь их, подчеркиваешь риски
— Если ничего не понятно, то обговариваешь некоторые блоки, которые нужно продумать. Просишь время на их исследование. После исследования называешь более точную оценку
— При озвучивании задачи учитываешь, кто просит оценку — т.к. под оценкой все понимают разное — кто-то хочет оценку в 90 персентиле, а кто-то медиану
Здравствуйте, jamesq, Вы писали:
J>Здравствуйте, __kot2, Вы писали:
J>>>Если требуют цифру немедленно, можно говорить грубую оценку по верхней планке, с запасом. И говорить, что это крайне предварительная оценка, нуждающаяся в уточнении. Какой вопрос, такой и ответ. __>>Стандартное развитие событий говноменеджмента «а вот Вася сказал, что это можно сделать в три раза быстрее, почему ты называешь такой срок? Ты хочешь меня обмануть или оцениваешь себя в три раза хуже Васи?»
J>А ты отвечаешь — сие есть очень грубая оценка, которую вы хотели получить немедленно. Я могу уточнить, если вы выделите время.
На самом деле с хорошим начальством таких разговоров вообще не бывает. Но тут менеджер руководит ситуацией, самое главное что именно он отчитывается наверх, а не ты и он всегда может выставить тебя в нужном свете, если ты ему сильно так уж прям не нужен или он видит, что тебе эта работа сильно нужна и ты готов прогибаться бесконечно
J>>>Если требуют цифру немедленно, можно говорить грубую оценку по верхней планке, с запасом. И говорить, что это крайне предварительная оценка, нуждающаяся в уточнении. Какой вопрос, такой и ответ. __>>Стандартное развитие событий говноменеджмента «а вот Вася сказал, что это можно сделать в три раза быстрее, почему ты называешь такой срок? Ты хочешь меня обмануть или оцениваешь себя в три раза хуже Васи?»
J>А ты отвечаешь — сие есть очень грубая оценка, которую вы хотели получить немедленно. Я могу уточнить, если вы выделите время. J>Но как ни крути, свои оценки надо будет защищать. Например объяснять, что вот для такого-то таска, тебе придётся делать то-то и то-то, что занимает такое-то время. И все эти другие оценки времени — нереалистичные фантазии. Ещё ты с лёгкой совестью можешь ссылаться на свою неопытность. Например говорить, что Вася имеет опыт в предметной области, работал с такими вещами. А ты нет. Вася сеньёр с соответствующей зарплатой, а ты нет. Если надо быстро сделать — пусть Вася и делает. Только вот Вася один, и всю работу он не потянет. Поэтому хочешь-нехочешь, начальству придётся отдавать работу и менее опытным сотрудникам. Оценка же не какое-то там объективное необходимое время для работы, а конкретно тебе необходимое. J>А так да, конкуренцию между исполнителями никто не отменял. Даже более того, нередко бывает что тебя, назвавшего более длительный срок увольняют, как слишком медленного. Передают таск Васе, который обещал быстрее. Тот делает задачу, и срывает все обещанные сроки. Выходит не меньше обещанного тобой, если не больше. Тут то начальство оказывается в интересном положении. Но как бы Вася в некотором выигрыше, т.к. тебя уволили ещё раньше, а он пока работает.
Никто не позволит называть большой (но разумный) срок. Потом корректировать тоже не позволят. Они хотят чтобы программист до начала работы над тикетом указал точную оценку и потом придерживался ее. О том, чтобы была точность до двух — трех дней не может быть и речи. Некоторые хотят прямо с точностью до часа. И будут портить нервы.
Здравствуйте, Олег К., Вы писали:
ОК>Никто не позволит называть большой (но разумный) срок. Потом корректировать тоже не позволят. Они хотят чтобы программист до начала работы над тикетом указал точную оценку и потом придерживался ее. О том, чтобы была точность до двух — трех дней не может быть и речи. Некоторые хотят прямо с точностью до часа. И будут портить нервы.
Тут мы видим, что программист не свободен в своих оценках. На него оказывается давление, чтобы он назвал оценку, которая устраивала бы начальство. И обязался бы её выполнять. Гнусная манипуляция, которой надо противодействовать.
Во-первых, надо сразу озвучить, чем они занимаются. Далее, пусть они сами назначают сроки, и несут ответственность за свои решения, если их не устраивает оценка исполнителя. Ещё можно им объяснить, что одно дело их хотелки, и что там их устраивает или не устраивает, а совсем другое дело неумолимая реальность, которой по-барабану, что там ты хочешь.
Но да, говноменеджмент трудно излечим, и полезно иметь возможность послать начальство куда подальше, и уволиться. Хотя это на крайний случай, и торопиться делать такое не стоит. Говноменеджер может с тобой облажаться, потом он облажается с другими, но потом до него дойдёт, какой он кретин. И может сделает выводы. Важно, что ты сам не позволишь говноменеджеру процветать и выезжать на твоём горбу, за твой счёт.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи,
вводная какая? оценить багфиксинг? я про него напишу — это реально ковырение в носу в незнакомом коде, нужно время на понимание вообще что от тебя хотят и как это ты можешь воспроизвести. Это уже +- ты можешь оценить, т.е. не "это работа тим лида", а "в течение дня я дам обратную связь тим лиду по общему скоупу понимания проблемы", оттолкнулся бы от этого. Не в позу — "это не моя работа", а давайте подумаю 8h и расскажу на следующем стендапе или что у вас там.
S>а потом сообщить реальное время выполнения задачи
в тикете отображается, там и фиксируй, тут просто не лениться и помнить про этот тикет.
Здравствуйте, sergey2b, Вы писали:
S>И не знаю что отвечать когда от меня назвать цифру немедленно
Попробуйте ответить просто "На данный момент не знаю".
Если начнут приставать, можно сказать: "Дайте мне минут 15-20 чтобы хотя бы граем глаза посмотреть на код".
Это время нужно чтобы примерно прикинуть какого объема код и насколько плохо он написан.
Дальше можно будет сказать: "Мне нужно 2/3/4/8/16/24 часа (в зависимости от объема и качества) чтобы сделать предварительную оценку".
После прошествия этого времени у вас уже будет какая-то информация о том, с чем столкнулись и какие-то следующие сроки вы готовые озвучивать. Например, "нужно не менее 2 дней на редизайн и затем еще сколько-то на реализацию". Или "ну тут не меньше недели только чтобы разобраться".
Здравствуйте, sergey2b, Вы писали:
S>я оценил задачу на один день, так как знал что есть рабочий пример запроса и отображения изображения S>в результате компиляция кода заняла день
Не собрав проект ты уже дал по времени — бред и нахрена.
Если проект не твой и большой, то всегда предполагать, что его сборка займет только неделю, а то и две (ну так нунче все пишут код).
Начальству сразу нужно было сказать, что собственно тест написать день нужно, но насколько я в курсе тот, проект не собирается вообще. Сначала нужно его собрать и запустить — это может и несколько дней занять.
А после еще разорбраться какой протокол общения с ним (по тем же пайпам). А вот после я тест напишу за пару часов.
И да, исправление багаов — это уже другие задачи и в эту не входят, не забывай.
Есть еще вариант. Пишешь тест по своим пайпам, глянув по быстрому на доку-код. Докладываешь, что тест написан и запущен и он упал. В том проекте всё криво и косо (он даже не собирается, я пробовал и не собирается).
После уже тебе ставится задача фиксить баг. Ты ее расписываешь:
1. Собрать тот кривой проект — неделя — документации нет, люди, что последний раз его собирали уволились 100 лет назад и проконсультироваться не у кого и вообще там море говнокода наколбашено за долгие года.
Здесь можно добавить подпунктов длительностью 1-2 дня.
2. Изучение проекта в части твоего таска — неделя. Люди, что последний раз его собирали уволились 100 лет назад и проконсультироваться не у кого и вообще там море говнокода наколбашено за долгие года.
Здесь можно добавить подпунктов длительностью 1-2 дня.
3. Фикс баг — 1 час.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, __kot2, Вы писали:
S>>>И не знаю что отвечать когда от меня назвать цифру немедленно __>>Правильный ответ — Пошел на х и поиск новой работы
S>Этот совет был актуален 5 лет назад. А сегодня уже изменилась ситуация — для многих работу стало найти сложнее.
Я для себя лично выработал такую стратегию: я по собеседованиям в другие конторы не хожу, только стараюсь быть в курсе всех потенциально мне интересных. Когда я вижу красные флаги в работе руководства или в работе самой конторы, начинаю ходить собеседоваться. Занимает это все равно много, в Америке полгода—год
Здравствуйте, __kot2, Вы писали:
J>>Если требуют цифру немедленно, можно говорить грубую оценку по верхней планке, с запасом. И говорить, что это крайне предварительная оценка, нуждающаяся в уточнении. Какой вопрос, такой и ответ. __>Стандартное развитие событий говноменеджмента «а вот Вася сказал, что это можно сделать в три раза быстрее, почему ты называешь такой срок? Ты хочешь меня обмануть или оцениваешь себя в три раза хуже Васи?»
А ты отвечаешь — сие есть очень грубая оценка, которую вы хотели получить немедленно. Я могу уточнить, если вы выделите время.
Но как ни крути, свои оценки надо будет защищать. Например объяснять, что вот для такого-то таска, тебе придётся делать то-то и то-то, что занимает такое-то время. И все эти другие оценки времени — нереалистичные фантазии. Ещё ты с лёгкой совестью можешь ссылаться на свою неопытность. Например говорить, что Вася имеет опыт в предметной области, работал с такими вещами. А ты нет. Вася сеньёр с соответствующей зарплатой, а ты нет. Если надо быстро сделать — пусть Вася и делает. Только вот Вася один, и всю работу он не потянет. Поэтому хочешь-нехочешь, начальству придётся отдавать работу и менее опытным сотрудникам. Оценка же не какое-то там объективное необходимое время для работы, а конкретно тебе необходимое.
А так да, конкуренцию между исполнителями никто не отменял. Даже более того, нередко бывает что тебя, назвавшего более длительный срок увольняют, как слишком медленного. Передают таск Васе, который обещал быстрее. Тот делает задачу, и срывает все обещанные сроки. Выходит не меньше обещанного тобой, если не больше. Тут то начальство оказывается в интересном положении. Но как бы Вася в некотором выигрыше, т.к. тебя уволили ещё раньше, а он пока работает.
Здравствуйте, Shmj, Вы писали:
S>>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
два гоода было норм
такой зарплаты мне больше не где не предлагают
60% процентов американского рынка дорогих приборов дураки не смогли бы освоить
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Добавлю к вышеизложенному. Без декомпозиции никак, причём при таких требованиях точности декомпозицию нужно делать до тех пор, пока самая долгая задача не уложится в день (максимум два). Требуйте такую декомпозицию или делайте сами за отдельную плату. Потом сумма оценок умножается на "менеджерский коэффициент", который вы выбираете исходя из своего уровня владения кодовой базой, опыта и прочих факторов. У меня этот коэффициент сейчас в среднем 1.4. Раньше был значительно выше =).
У вас типичная ситуация, когда не очень умный управленец хочет систему под ключ и чтобы она стабильно и без правок закрывала нужды бизнеса. Так не работает в реальном мире. Поэтому и были придуманы всякие скрамбаны с почасовой оплатой вместо фиксед прайса. А от вас по сути хотят фиксед прайс полученный по формуле точная_оценка_времени*стоимость_часа. На этом можно строить бизнес — в фикс прайс всегда можно заложить более высокую маржу (с определёнными рисками). И вот чтобы эти риски минимизировать, вы уже в первую очередь для себя делаете полную декомпозицию и умножаете на волшебные коэффициенты.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Это невозможно. Это даже сложно в известной тебе области и с известным кодом, ну только если не совсем маленькая задачка.
А так первым шагом должно быть разбиение задачи на более мелкие — у них время оценить проще и ошибка плюс-минус скорее будет не критичной.
Если же тебя реально просят точно оценить в часах — стоит усомниться в адекватности руководителей
Здравствуйте, sergey2b, Вы писали:
S>я не могу при всех сказать что это невозможно, я сказал более мягко — это работа менеджера оценивать, а я как послушный гребец буду грести S>мне ответили что нет программист должен делать планирование
Откуда менеджер знает, сколько займет реализация?
Он может принять решение о приоритетах, о срезании углов, о принятии рисков.
UPD. По-идее, должен быть тимлид/техлид — он оценит.
Здравствуйте, Hоmunculus, Вы писали:
H>Если же тебя реально просят точно оценить в часах — стоит усомниться в адекватности руководителей
Надо исходить из того, что если тебе оплатят эту работу по твоей почасовой ставке в объеме вот этого оцененного времени, а работы окажется больше, то ты всё равно её доделаешь и тебе не будет обидно, что сильно продешевил.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Очень много неизвестных. Не понятно в каком виде к тебе задачи приходят, что за задачи: баг, таска, фича и т.п., что за код какой объём проект, какой критерий завершения задачи, объём юнитов, готовность инфры под завершение, внешние условия вроде какого-то оборудования, например.
Есть набор техник которые можно использовать для оценки, но без предварительного проектирования и исследования оценка будет всё равно плавать, хотя с временем будет болеет точной даже если будет что-то новое.
Здравствуйте, Marty, Вы писали:
M>Берёшь указательный палец. Засовываешь его поглубже в нос. Выковыриваешь из него козявку пожирнее. Глядя на форму и размеры козявки — называешь сроки. Если козявка жирная и причудливой формы — срок побольше. Если маленькая и аккуратная — срок поменьше
это же америка, 2-3 месяца оказался в хвосте и сразу начнуться репресии
тем более рецесия и людей увольняют тысчами сейчас
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Для незнакомой задачи сама оценка требует время.
S>Кодовая база 7-12 милл строк S>Я знаком с небольшим куском, примерно 1/3 S>С остальным кодом я малознаком
Если считать, что там 6 миллионов строк кода, то ты имеешь представление как работают 2 миллиона строк? Это очень классный результат! На каком счету ты у начальника?
Здравствуйте, s_aa, Вы писали:
S>>И не знаю что отвечать когда от меня назвать цифру немедленно
_>У меня на работе пофигу что отвечать, главное быстро и уверенно. Цифра нужна менеджеру, чтобы у него была иллюзия контроля. Сделаешь молодец, не сделаешь — отыщешь сто причин почему не успел, уверенно сообщишь новый срок, и все будут довольны.
Да я вот сам сейчас в какой-то степени начальник. Сдал в прошлую пятницу монитор в ремонт в мастерскую. Обещали на этой неделе посмотреть. Вчера, в четверг звоню выяснить как дела — отвечают, что даже не прикасались пока. Хотя 6 дней прошло. Обещали сегодня посмотреть. Сегодня звоню — на голубом глазу мне говорят, что и сегодня не смотрели. Мол не успел. Ну и что теперь? Только из-за затягивания сроков я буду дёргаться как-то? Отменять заказ, передавать кому-то ещё? Но у меня же тоже не так всё просто. Другого исполнителя ещё найти надо, годного. Эти то хоть нормально делают, пусть и долго. И переделывают некачественную работу за собой. А про тех я вообще ничего не знаю. В общем, исполнитель имеет возможности позатягивать сроки, это точно. Если в остальном он не лажает.
Здравствуйте, __kot2, Вы писали:
S>>И не знаю что отвечать когда от меня назвать цифру немедленно __>Правильный ответ — Пошел на х и поиск новой работы
Этот совет был актуален 5 лет назад. А сегодня уже изменилась ситуация — для многих работу стало найти сложнее.
Здравствуйте, Олег К., Вы писали:
ОК>Никто не позволит называть большой (но разумный) срок. Потом корректировать тоже не позволят. Они хотят чтобы программист до начала работы над тикетом указал точную оценку и потом придерживался ее. О том, чтобы была точность до двух — трех дней не может быть и речи. Некоторые хотят прямо с точностью до часа. И будут портить нервы.
Когда требуют точность до часа, это уже откровенный микроменеджмент. Точность до 2-3 дней обычное дело, когда тебе ставят задачу не написать там какую функцию или класс, а создать целую софтину. Или там, фичу написать и прикрутить.
Здравствуйте, __kot2, Вы писали:
__>Для незнакомой задачи сама оценка требует время.
Да, и в зависимости от сложности задачи может занять от 5 мин, до 3-6 месяцев.
Здравствуйте, so5team, Вы писали:
S>>Теперь требуют оценить время точно
S>"Бегите, глупцы!" (с)
S>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме.
Я так понимаю ты исповедуешь "идею достаточности" — типа мне ХХХ достаточно чтобы удовлетворить базовые потребности и немного выше, и работать чтобы жить а не жить чтобы работать.
Отличный подход, и идея уволиться тоже отличная.
Но представь себе что есть другие людит которые хотят хорошо разабатывать — больше медианы. Что ты им посоведуешь?
Здравствуйте, jamesq, Вы писали:
J>Во-первых, надо сразу озвучить, чем они занимаются. Далее, пусть они сами назначают сроки, и несут ответственность за свои решения, если их не устраивает оценка исполнителя. Ещё можно им объяснить, что одно дело их хотелки, и что там их устраивает или не устраивает, а совсем другое дело неумолимая реальность, которой по-барабану, что там ты хочешь.
J>Но да, говноменеджмент трудно излечим, и полезно иметь возможность послать начальство куда подальше, и уволиться. Хотя это на крайний случай, и торопиться делать такое не стоит. Говноменеджер может с тобой облажаться, потом он облажается с другими, но потом до него дойдёт, какой он кретин. И может сделает выводы. Важно, что ты сам не позволишь говноменеджеру процветать и выезжать на твоём горбу, за твой счёт.
Кому-то нравиться все время искать работу, а кому-то наравиться просто работат и получать ЗП.
У всех свои предпочения.
Я это к тому, что лучше не хамить и просто уволиться и пойти искать новую хорошую работу где такого не будет.)
Здравствуйте, Олег К., Вы писали:
ОК>Я с тобой полностью согласен. Выше я сказал другими словами, что менеджеров нужно учить и нужно уметь постоять за себя. Иначе будут борзеть. На деле же в большинстве случаев происходит то что я описал.
Смотри — для менеджера это просто некая механическая проблема.
Есть чувак который вые..тся, значит его надо заменить.
Я к тому, что учить менеджеров тут, это как спорить с телевизором — можно но обычно безсмысленно.
Здравствуйте, imh0, Вы писали:
I>А если представить себе что такой же вопрос задают штукатуру — когда закончишь штукатурить эту комнату?
Для штукатура это типичная и стандартная работа, которая элементарно нормируется. А теперь попроси штукатура оценить время и стоимость штукатурки какой представительской комнаты в царском дворце (примеров в мире в море) и офигей от сроков и цены.
Причем он просрет оценочные сроки раз в пять и по времени и по цене.
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Поинтересуйся мнением постановщика задачи о требуемом времени исполнения. От этого и исходи.
Иногда у постановщиков задач в голове возникают нереальные сроки по выполнению этих задач . В этом случае твоя оценка сроков , пустая трата времени
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:
S>>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
МПИ>разработай некую модель, пусть даже самопальную, МПИ>в рамках которой ты сможешь выкатить пункты работы, которую нужно проделать МПИ>и оцени эти пункты, можно с нижней и верхней границей МПИ>если понятно, что не всё заранее понятно, то закладывай пункты типа "распознать концепцию кода такого-то модуля" МПИ>потом проссумируй эти границы пунктов и вот тебе оценка
После оценки времени по такой модели обычно получаются десятки лет
Посмотри на математеков которые сотни лет решали простые задачи и немогли найти решения.
Не четные совершенные числа, гипотеза Коллоца, великая теорема Ферма...
Так что задачи с которыми не имел дела могут выглядеть очень просто, но время на решение может превзойти любые ожидания.
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
на одной работе была такая тема.
просто прикидывал время, за которое нога за ногу сто пудов это сделаешь. умножал это время на 3. давал тимлиду. потом тимлиды обсуждали оценки от команды на своем митинге. и либо немного резали время, либо соглашались
Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела
и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
А сколько времени для оценки задачи или это тоже нужно сначала оценить?
Здравствуйте, Hоmunculus, Вы писали:
H>Если же тебя реально просят точно оценить в часах — стоит усомниться в адекватности руководителей
просят всех а не только меня
я не могу при всех сказать что это невозможно, я сказал более мягко — это работа менеджера оценивать, а я как послушный гребец буду грести
мне ответили что нет программист должен делать планирование
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
Берёшь указательный палец. Засовываешь его поглубже в нос. Выковыриваешь из него козявку пожирнее. Глядя на форму и размеры козявки — называешь сроки. Если козявка жирная и причудливой формы — срок побольше. Если маленькая и аккуратная — срок поменьше
Здравствуйте, sergey2b, Вы писали: S>Я это понимаю S>И не знаю что отвечать когда от меня назвать цифру немедленно
Правильный ответ — Пошел на х и поиск новой работы
И как другие оценивают? Похоже у вас там своя кухня
S>я не могу при всех сказать что это невозможно, я сказал более мягко — это работа менеджера оценивать, а я как послушный гребец буду грести
S>мне ответили что нет программист должен делать планирование
Тебе намекают, что с твоим опытом пора быть не просто программистом
Вообще много неизвестных.
Пример задачи
Один будешь работать али с помощниками
Знакомая область или нет
Делалось ли что-то похожее раньше, кем-то другим
и тд
Здравствуйте, __kot2, Вы писали:
S>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме. __>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
Может быть с точки зрения говноменеджера это манипуляции.
S>>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
GIV>А никак. Отбрехиваться.
Поддержу этот ответ. ТС, если ты только не работал уже над похожей задачей в этом же коде, то оценить срок никак нельзя. Поэтому остается только отбрехиваться.
Пара вопросов. Менеджер программист или нет? Он понимает работу программистов? На каком счету ты у него?
Культурно объясняй что не ты писал весь этот код. Миллионы строк кода далеко не самого лучшего качества, написанный разными людьми в разном стиле. На данный момент ты даже не знаешь куда смотреть в коде, не говоря уже о том, чтобы дать оценку срока. Чтобы дать оценку, нужно начать работать над ним. Это все занимает время. Даже если просто посмотреть на код, тебе это ничего не даст. Нужно просто начать работать над ним, и когда получится тогда получится. Ты не сидишь без дела.
Менеджеров тоже нужно учить и, в случае чего, нужно уметь постоять за себя.
S>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме. __>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
У меня двоякое мнение на этот счет. С одной стороны я согласен, что это инструмент манипуляции. С другой стороны начальник может совсем не понимать работу программиста. Поэтому могут доводить ситуацию до абсурда.
Здравствуйте, Олег К., Вы писали:
S>>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме. __>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
ОК>У меня двоякое мнение на этот счет. С одной стороны я согласен, что это инструмент манипуляции. С другой стороны начальник может совсем не понимать работу программиста. Поэтому могут доводить ситуацию до абсурда.
Если человек совсем не понимает, то какого хрена он столько денег получает? Ладно, если это команда энтузиастов собралась. Если у человека есть хотя бы пару лет работы, он все это понимает. По моему опыту это всегда манипуляция
S>>>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме. __>>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
ОК>>У меня двоякое мнение на этот счет. С одной стороны я согласен, что это инструмент манипуляции. С другой стороны начальник может совсем не понимать работу программиста. Поэтому могут доводить ситуацию до абсурда. __>Если человек совсем не понимает, то какого хрена он столько денег получает? Ладно, если это команда энтузиастов собралась. Если у человека есть хотя бы пару лет работы, он все это понимает. По моему опыту это всегда манипуляция
Ты же жил и работал в Штатах. Должен знать какие идиоты там встречаются.
Здравствуйте, Олег К., Вы писали:
S>>>>>Требовать точные сроки -- это маразм. А вы уж сами решайте, готовы ли вы тратить часть своей жизни в этом маразме. __>>>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
ОК>>>У меня двоякое мнение на этот счет. С одной стороны я согласен, что это инструмент манипуляции. С другой стороны начальник может совсем не понимать работу программиста. Поэтому могут доводить ситуацию до абсурда. __>>Если человек совсем не понимает, то какого хрена он столько денег получает? Ладно, если это команда энтузиастов собралась. Если у человека есть хотя бы пару лет работы, он все это понимает. По моему опыту это всегда манипуляция
ОК>Ты же жил и работал в Штатах. Должен знать какие идиоты там встречаются.
Надо же понимать их мотивацию.
Здравствуйте, sergey2b, Вы писали:
S>15 минут, я до этого писал время от балды S>Теперь требуют оценить время точно
Ты токарь что-ли?
1. Взять болванку: 30 сек
2. Обточить болванку: 3 мин
3. Повторять пп.1-2 до обеда
4. Перерыв на обед: 30 мин
5. Повторять пп.1-2 до конца рабочего дня
Мотивируя что готов писать репорты о потраченном времени без вопросов
Что просто check out и компиляция нужно куска занимает минут 20 а иногда и несколько часов
S>И не знаю что отвечать когда от меня назвать цифру немедленно
У меня на работе пофигу что отвечать, главное быстро и уверенно. Цифра нужна менеджеру, чтобы у него была иллюзия контроля. Сделаешь молодец, не сделаешь — отыщешь сто причин почему не успел, уверенно сообщишь новый срок, и все будут довольны.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
J>Да я вот сам сейчас в какой-то степени начальник. Сдал в прошлую пятницу монитор в ремонт в мастерскую. Обещали на этой неделе посмотреть. Вчера, в четверг звоню выяснить как дела — отвечают, что даже не прикасались пока. Хотя 6 дней прошло. Обещали сегодня посмотреть. Сегодня звоню — на голубом глазу мне говорят, что и сегодня не смотрели. Мол не успел. Ну и что теперь? Только из-за затягивания сроков я буду дёргаться как-то? Отменять заказ, передавать кому-то ещё? Но у меня же тоже не так всё просто. Другого исполнителя ещё найти надо, годного. Эти то хоть нормально делают, пусть и долго. И переделывают некачественную работу за собой. А про тех я вообще ничего не знаю. В общем, исполнитель имеет возможности позатягивать сроки, это точно. Если в остальном он не лажает.
Будет постоянно затягивать сроки, будут портить нервы. А потом и уволят. Аналогия с ремонтом в мастерской неверная.
Здравствуйте, Олег К., Вы писали:
ОК>Если считать, что там 6 миллионов строк кода, то ты имеешь представление как работают 2 миллиона строк? Это очень классный результат! На каком счету ты у начальника?
за два года все ревью положительные
но явно руководство хочет что бы мы работали быстрей
Здравствуйте, sergey2b, Вы писали:
S>Задача писать тесты S>Если тесты не проходят исправлять выявленные ошибки
Годно, тесты могут и джуны писать, ошибки исправлять — нужен опыт и понимание предметной области.
S>Кодовая база 7-12 милл строк S>Я знаком с небольшим куском, примерно 1/3 S>С остальным кодом я малознаком
Для написания тестов не надо досконально знать код, не? Есть бизнес логика, входные и выходные данные грубо. Совпадает — хорошо, нет — копаемся.
S>Для примера мне дали написать тест, оценили на 2-3 часа
Кто оценил? Тест на 1 функцию?
S>я уже 4 день разбираюсь как работает код тк комментариев и документации нет
Просто разбираешься или тест вернул ошибку?
AI агента нет? Сделать анализ кода — его стихия.
Есть у меня знакомый который убежден, что код это и есть самая лучшая документация
Здравствуйте, sergey2b, Вы писали:
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
По сути нужно признать: ты сам виноват, что устроился работать с некомпетентными людьми. Скорее всего от безвыходности, т.к. другого варианта не смог найти, верно? Значит нужно принять реальность и как бы "отбывать наказание", подыгрывая их прихотям, верно?
Такая оценка добавит стресса и приведет к тому что работа будет выполнена хуже (в попытках сделать побыстрее) и дольше (из-за стресса не будет работать голова, будешь плохо спать, над 1 простым багом будешь сидеть пол дня и в упор его не будешь видеть).
Притом тут две ловушки:
1. Назовешь слишком малое прогнозируемое время — потом тебя же будут тыкать носом — почему так медленно, ведь оценку ты сам дал.
2. Назовешь время с запасом — могут дать оценить кому-то другому и начнут тыкать носом — а вот Вася оценил во столько-то, значит он более оптимальный работник.
Здравствуйте, jamesq, Вы писали:
J>Тут мы видим, что программист не свободен в своих оценках. На него оказывается давление, чтобы он назвал оценку, которая устраивала бы начальство. И обязался бы её выполнять. Гнусная манипуляция, которой надо противодействовать.
Но он хотя бы в США, хотя бы можно терпеть приходи за американскую зарплату. А у меня было подобное за российскую зарплату Причем там люди годами работают и думают что это норм.
J>Тут мы видим, что программист не свободен в своих оценках. На него оказывается давление, чтобы он назвал оценку, которая устраивала бы начальство. И обязался бы её выполнять. Гнусная манипуляция, которой надо противодействовать. J>Во-первых, надо сразу озвучить, чем они занимаются. Далее, пусть они сами назначают сроки, и несут ответственность за свои решения, если их не устраивает оценка исполнителя. Ещё можно им объяснить, что одно дело их хотелки, и что там их устраивает или не устраивает, а совсем другое дело неумолимая реальность, которой по-барабану, что там ты хочешь. J>Но да, говноменеджмент трудно излечим, и полезно иметь возможность послать начальство куда подальше, и уволиться. Хотя это на крайний случай, и торопиться делать такое не стоит. Говноменеджер может с тобой облажаться, потом он облажается с другими, но потом до него дойдёт, какой он кретин. И может сделает выводы. Важно, что ты сам не позволишь говноменеджеру процветать и выезжать на твоём горбу, за твой счёт.
Я с тобой полностью согласен. Выше я сказал другими словами, что менеджеров нужно учить и нужно уметь постоять за себя. Иначе будут борзеть. На деле же в большинстве случаев происходит то что я описал.
ОК>>Никто не позволит называть большой (но разумный) срок. Потом корректировать тоже не позволят. Они хотят чтобы программист до начала работы над тикетом указал точную оценку и потом придерживался ее. О том, чтобы была точность до двух — трех дней не может быть и речи. Некоторые хотят прямо с точностью до часа. И будут портить нервы.
J>Когда требуют точность до часа, это уже откровенный микроменеджмент. Точность до 2-3 дней обычное дело, когда тебе ставят задачу не написать там какую функцию или класс, а создать целую софтину. Или там, фичу написать и прикрутить.
Проблемы с менеджментом и процессами. Да. И желание выжать побольше.
Здравствуйте, sergey2b, Вы писали:
S>я не могу при всех сказать что это невозможно, я сказал более мягко — это работа менеджера оценивать, а я как послушный гребец буду грести S>мне ответили что нет программист должен делать планирование
Глупость ты сказал и тебе соответсвенно ответили. Оценить сроки своей задачи должен как раз ты сам. А как — выше тебе уже Буравчик написал.
В общем "разделяешь и властвуешь". Разбиваешь задачу на части и дальше очениваешь время на каждую часть, суммируешь и умножаешь на пи.
Здравствуйте, sergey2b, Вы писали:
S>И не знаю что отвечать когда от меня назвать цифру немедленно
А вот в этом случае можно потребовать закупку хрустального шара, как инструмента для работы.
Но вообще обычно достаточно сказать, что не знаю и мне нужен день, чтобы разобраться с задачей и после дам грубую оценку этапов (в том числе и этапа оценки времени выполнения).
Здравствуйте, so5team, Вы писали:
S>Если начнут приставать, можно сказать: "Дайте мне минут 15-20 чтобы хотя бы граем глаза посмотреть на код". S>Это время нужно чтобы примерно прикинуть какого объема код и насколько плохо он написан.
Еще лучше всё это описать и ответить начальнику письменно вместе с оценками по времени.
Здравствуйте, Vzhyk2, Вы писали:
V>Глупость ты сказал и тебе соответсвенно ответили. Оценить сроки своей задачи должен как раз ты сам. А как — выше тебе уже Буравчик написал. V>В общем "разделяешь и властвуешь". Разбиваешь задачу на части и дальше очениваешь время на каждую часть, суммируешь и умножаешь на пи.
мне дали задачу, написать тест
запросить изображение по одному pipe
когда получил изображение запросить другое изображение по другому pipe
из документации только исходный код
я оценил задачу на один день, так как знал что есть рабочий пример запроса и отображения изображения
в результате компиляция кода заняла день
пример оказалась не рабочим
человек который поломал пример послал меня нах
как в таких условиях надо было оценивать время написания теста
Здравствуйте, __kot2, Вы писали:
__>Если человек совсем не понимает, то какого хрена он столько денег получает? Ладно, если это команда энтузиастов собралась. Если у человека есть хотя бы пару лет работы, он все это понимает. По моему опыту это всегда манипуляция
В целом можно воспринимать как манипуляция, но если ответ будет = 100*реальная трудоемкость. То хоть это и манипуляция то надо увольнять.
А увольнение не выгодно в первую очередь разработчику, так как портит резюме и лишает денег.
Найти нового сотрудника гораздо проще чем найти новую работу.
Менеджеру это не больно так как поиском занимается не он.
Поэтому это скорее пусть и некая манипуляция, но скорее помошь разработчику не отказаться на улице.
Здравствуйте, __kot2, Вы писали:
__>Я для себя лично выработал такую стратегию: я по собеседованиям в другие конторы не хожу, только стараюсь быть в курсе всех потенциально мне интересных. Когда я вижу красные флаги в работе руководства или в работе самой конторы, начинаю ходить собеседоваться. Занимает это все равно много, в Америке полгода—год
Это если ты не работаешь в Мета или Гугле — долго прыгать по бигтехам не получиться, а работать в жопной компашке так себе.
Здравствуйте, Vzhyk2, Вы писали:
I>>А если представить себе что такой же вопрос задают штукатуру — когда закончишь штукатурить эту комнату?
V>Для штукатура это типичная и стандартная работа, которая элементарно нормируется. А теперь попроси штукатура оценить время и стоимость штукатурки какой представительской комнаты в царском дворце (примеров в мире в море) и офигей от сроков и цены.
Ну это только так кажеться. Для программиста тоже обычная работа — написать тесты.
V>Причем он просрет оценочные сроки раз в пять и по времени и по цене.
Его не просили дать не выполнимые сроки, его просили дать +/- реалистичные и именно для него.
Можно оценивать задачи в каких-то стандартных задачах.
Например 0.5 от обычной задачи написать тест.
Или *5 от обычной задачи написать тест.
Здравствуйте, imh0, Вы писали:
I>Ну это только так кажеться. Для программиста тоже обычная работа — написать тесты.
Нет, но эффективному менеджеру не понять оное. Странно. что вы до сих пор не кончились, но осталось вам недолго. Где-то в 28 вас ликвидируют полностью.
I>Можно оценивать задачи в каких-то стандартных задачах.
Это каких?
Здравствуйте, imh0, Вы писали:
I>Скорее про НЕ гугл. I>Типа стартапа.
Вот мы и пришли ко вкусам. Для кого-то человечье говно — это вкусняшка, а для кого-то это говно и ничего более.
I>Крупная корпорация всегда не жопная компашка.
Всегда говно.
Здравствуйте, Vzhyk2, Вы писали:
I>>Ну это только так кажеться. Для программиста тоже обычная работа — написать тесты. V>Нет, но эффективному менеджеру не понять оное. Странно. что вы до сих пор не кончились, но осталось вам недолго. Где-то в 28 вас ликвидируют полностью.
Тут недано столкнулся с ситуацией, приятель рассказал — им на онбординге-обучении на менеджеров в одном из бигтехов сказали "вы должны знать, что ценность для компании IT-менеджера с девелоперским бекграундом в несколько раз выше чем любого разработчика" Причем это сказали в мотивации к анти синдрому самозванца — "Типа не бойтесь увольнять, даже если у вас получилась ошибка — вы для компании ценнее чем любой эксперт-архитектор на соответсвующих уровнях"
Так как опытных мереджеров именно с опытом разработки в 1000 раз сложнее найти чем любого разраба.
I>>Можно оценивать задачи в каких-то стандартных задачах. V>Это каких?
Ну смотри — что такое сторипоинты слышал?
Нет — ну тогда не обьяснить.)
Здравствуйте, imh0, Вы писали:
I>Ну смотри — что такое сторипоинты слышал?
Ага, отличная штука нихера не делать, а на бабки начальство и владельцев бизнеса разводить.
Здравствуйте, imh0, Вы писали:
I>Здравствуйте, __kot2, Вы писали:
__>>да не маразм это, а инструмент манипуляции. "ты сам дал обещание, что сделаешь это за столько.."
I>А если представить себе что такой же вопрос задают штукатуру — когда закончишь штукатурить эту комнату? I>Это тоже манипуляции?
Нет, конечно. Но менеджер, который считает, что искать баг в незнакомом коде это как штукатурить стену — идиот-с
Я даже больше скажу, я иногда в таких случаях находил прямо куски кода, которые вызывали баг, при этом человек явно хотел добиться работы какого-то сценария. Но про этот сценарий не в курсе ни менеджер, ни product owner. То есть, условно говоря, баг можно пофиксить, просто удалив некий код, что вызовет непредсказуемое изменение поведения, возможно. Где-то у кого-то. Кому именно так надо было
То есть тебе вместо стены надо покрасить плюмбус, но что это, зачем и как это будет использоваться не знает никто.
С опытом у меня выработался нюх на неуспешные проекты и если я вижу, что сотрудники только делают вид, что в чемто разбираются, то просто сваливаю оттуда сильно не вникая в детали о причинах существования таких проектов вообще. Которых, по моему мнению, большинство
S>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
разработай некую модель, пусть даже самопальную,
в рамках которой ты сможешь выкатить пункты работы, которую нужно проделать
и оцени эти пункты, можно с нижней и верхней границей
если понятно, что не всё заранее понятно, то закладывай пункты типа "распознать концепцию кода такого-то модуля"
потом проссумируй эти границы пунктов и вот тебе оценка
Властитель слабый и лукавый,
Плешивый щеголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
S>>>Подскажите Как оценивать сроки задач когда дают задачу с кодом с которым раньше не имел дела S>>>и просят перед началом работы оценить срок выполнения задачи, а потом сообщить реальное время выполнения задачи
МПИ>>разработай некую модель, пусть даже самопальную, МПИ>>в рамках которой ты сможешь выкатить пункты работы, которую нужно проделать МПИ>>и оцени эти пункты, можно с нижней и верхней границей МПИ>>если понятно, что не всё заранее понятно, то закладывай пункты типа "распознать концепцию кода такого-то модуля" МПИ>>потом проссумируй эти границы пунктов и вот тебе оценка
_>После оценки времени по такой модели обычно получаются десятки лет _>Посмотри на математеков которые сотни лет решали простые задачи и немогли найти решения. _>Не четные совершенные числа, гипотеза Коллоца, великая теорема Ферма... _>Так что задачи с которыми не имел дела могут выглядеть очень просто, но время на решение может превзойти любые ожидания.
да, на гипотезу Коллатца я и сам потратил месяца 2
но программистские задачи же в основном не научно-исследовательские первопроходческие
там всё в принципе алгоритмически ясно, просто бывает много сложных деталей
Властитель слабый и лукавый,
Плешивый щеголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
Здравствуйте, __kot2, Вы писали:
__>С опытом у меня выработался нюх на неуспешные проекты и если я вижу, что сотрудники только делают вид, что в чемто разбираются, то просто сваливаю оттуда сильно не вникая в детали о причинах существования таких проектов вообще. Которых, по моему мнению, большинство
Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:
МПИ>там всё в принципе алгоритмически ясно, просто бывает много сложных деталей
А дьявол обычно всегда в них скрывается.
Здравствуйте, sergey2b, Вы писали:
S>я не могу при всех сказать что это невозможно, я сказал более мягко — это работа менеджера оценивать, а я как послушный гребец буду грести S>мне ответили что нет программист должен делать планирование
Тебе уже написали- дай estimate на проделывание estimate, т.к. с этим кодом/фичей/проектом ещё не работал. Если хотят estimate сразу — ну прикинб всё-таки на основе предыдущих 30 лет опыта, и добавь буфер 20%.
Работа менеджера- планировать и раздавать задачи, учитывая очередь с приоритетом на фичи/багофиксы и т.п., а не держать в голове контекст области компетенции каждого программиста.
Причем там люди годами работают и думают что это норм.
