![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
R&D срач
у забиватора дошел до пары тупиков - в одном ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
bopm травит за то, что люди пишут свой новый софт, а не копаются в опен-сорсном легаси кале в попытках его улучшить.
Во втором требуют разделить софт на нормальные уровни абстракции и выделить изолированные куски которые можно будет править независимо. У меня есть подозрение, что производительность превратится при этом в тыкву, а проверить это в данных условиях малореально, т.к. на проверку нужно время, которого как бы и нет.
И все это меня наводит на мысль, что такая работа (у меня похожая ситуация) вырывает мозг и делает невозможным существование в нормальных условиях - т.е. если нету постоянного цейтнота, дедлайнов и переключения между десятками задач в день, то мозг сразу же впадает в режим пониженного энергопотребления и начинается тупизм.
Я вообще не понимаю, какие проекты, сроки и бюджеты могут быть, что на них возможно прогнозирование и соблюдение сроков и управление рисками. Какое нафиг прогнозирование, если сегодня дадут срочную задачу, а завтра дадут еще более срочную, причем все это делается на пределе физических возможностей. Или то, что решение примерно одинаковых фич может занимать день, а может - месяц, в зависимости от того, насколько грамотно реализована нижележащая архитектура и насколько эти фичи в нее вписываются.
Т.е. я представляю себе, что любые оценки ресурсов в норме нужно делать по нижней границе - если можешь сделать за день - называешь неделю, если делается за неделю - называть месяц, а больше месяца я вообще свою работу спрогнозировать не в состоянии, потому что за месяц сто раз все поменяется.
Что с этим делать, примерно понятно - выкидывать лишние проекты, существующие растягивать до нормального времени, и работать исключительно не больше 40 часов в неделю, не отвлекаясь и распланировав работу. Но тогда невыполненная работа начинает накапливаться как снежный ком, а от проектов, которые обязательно сделать вовремя вообще деться некуда.
PS: Вот еще на тему - периодически в таких обсуждениях предлагают "положить х-ръ, требовать 100 баксов в час и вообще сесть клиентам на голову и свесить ножки". В этом есть некая проблема, как минимум у меня. Ключевой аспект безумной производительности труда - внутренняя мотивация, которая позволяет делать всю эту дурь не выходя из ритма. Если же начинать думать категориями "мне не доплачивают, я слишком много ебошу, нужно работать 40 часов" - мозг резко выключается и не желает работать даже положенных 40 часов, получая моральное разрешение пинать балду.
bopm травит за то, что люди пишут свой новый софт, а не копаются в опен-сорсном легаси кале в попытках его улучшить.Во втором требуют разделить софт на нормальные уровни абстракции и выделить изолированные куски которые можно будет править независимо. У меня есть подозрение, что производительность превратится при этом в тыкву, а проверить это в данных условиях малореально, т.к. на проверку нужно время, которого как бы и нет.
И все это меня наводит на мысль, что такая работа (у меня похожая ситуация) вырывает мозг и делает невозможным существование в нормальных условиях - т.е. если нету постоянного цейтнота, дедлайнов и переключения между десятками задач в день, то мозг сразу же впадает в режим пониженного энергопотребления и начинается тупизм.
Я вообще не понимаю, какие проекты, сроки и бюджеты могут быть, что на них возможно прогнозирование и соблюдение сроков и управление рисками. Какое нафиг прогнозирование, если сегодня дадут срочную задачу, а завтра дадут еще более срочную, причем все это делается на пределе физических возможностей. Или то, что решение примерно одинаковых фич может занимать день, а может - месяц, в зависимости от того, насколько грамотно реализована нижележащая архитектура и насколько эти фичи в нее вписываются.
Т.е. я представляю себе, что любые оценки ресурсов в норме нужно делать по нижней границе - если можешь сделать за день - называешь неделю, если делается за неделю - называть месяц, а больше месяца я вообще свою работу спрогнозировать не в состоянии, потому что за месяц сто раз все поменяется.
Что с этим делать, примерно понятно - выкидывать лишние проекты, существующие растягивать до нормального времени, и работать исключительно не больше 40 часов в неделю, не отвлекаясь и распланировав работу. Но тогда невыполненная работа начинает накапливаться как снежный ком, а от проектов, которые обязательно сделать вовремя вообще деться некуда.
PS: Вот еще на тему - периодически в таких обсуждениях предлагают "положить х-ръ, требовать 100 баксов в час и вообще сесть клиентам на голову и свесить ножки". В этом есть некая проблема, как минимум у меня. Ключевой аспект безумной производительности труда - внутренняя мотивация, которая позволяет делать всю эту дурь не выходя из ритма. Если же начинать думать категориями "мне не доплачивают, я слишком много ебошу, нужно работать 40 часов" - мозг резко выключается и не желает работать даже положенных 40 часов, получая моральное разрешение пинать балду.
no subject
no subject
Во втором требуют разделить софт на нормальные уровни абстракции и выделить изолированные куски которые можно будет править независимо. У меня есть подозрение, что производительность превратится при этом в тыкву, а проверить это в данных условиях малореально, т.к. на проверку нужно время, которого как бы и нет.
Здравствуй Java EE! Правда эти игрища до 5-6 версии мягко говоря бульдозер. В 5-6 лучше, но до spring по внятности и простоте недотягивают. Но Spring это отдельная тема которая офигенно ест мозг и часто производит ощущение ебанной магии. Вроде понятно как что там работает, но ощущение магии не пропадает.
no subject
no subject
Правда как показывает практика, часто удобней написать в компонентном виде, а потом уже сливать компоненты, которые нужны
no subject
no subject
no subject
Спринг, при всей своей маркетоидной красоте, тоже не причем в общем )
no subject
no subject
no subject
no subject
no subject
модульность - это характеристика архитектуры приложения, если я все верно понимаю
конфигурация - это конфигурация собственно приложения
как конфигурация приложения отражается на его модульности?
no subject
Вон товарищ metaclass про тоже пишет ниже.
no subject
no subject
no subject
no subject
no subject
Чтобы не было обидно и никто не рвал тельник на волосатой груди, могу напомнить, что это самое танковое сражение случилось в результате одного из самых былинных отказов в истории европейской цивилизации.
no subject
no subject
no subject
no subject
Ну а все переключения контекстов, приход более приоритетных задач и общение с кастомерами думаю обсуждать не стоит. У всех свои сложности.
Достаточно в оценку сроков заложить то, что может прийти срочная задача, которой тебе придется уделить время - и все будет. А задача менеджмента - сделать так, чтобы срочными задачами занимался кто-то кроме тебя в данный момент времени. Потому тезис о недопустимости незаменимых гвоздей имеет место быть.
no subject
no subject
(Anonymous) 2010-04-10 08:48 pm (UTC)(link)Ребе, так введение управления проектами - это будет следующая стадия организационной деградации вашей конторы. У вас появится начальник отдела, который вместо того чтобы устранять описанные условия работы, будет заставлять вас давать оценки и прогнозы, а потом будет дрючить за их неисполнение :)