Здравствуйте, minorlogic, Вы писали:
M>Тогда поясни, что такое "профессиональная специфика" ? то что бывает на работе раз в 5 лет ? у меня за 5 лет даже не раз понос был (извините за подробность), это "профессиональная специфика" ?
А причин, по которым работать приходится гораздо больше и/или напряженнее в программировании достаточно:
— сложность выуживания из заказчика конкретных пожеланий и спецификаций;
— излишний оптимизм менеджеров, проектировщиков, разработчиков;
— сложность перевода ментальных моделей, существующих в головах проектировщиков/разработчиков, в программный код;
— баги, допущенные как из-за недопонимания предметной области, так и из-за элементарных опечаток;
— человеческий фактор (разные уровни подготовки программистов, разные уровни производительности одного и того же программиста в зависимости от ряда факторов (семейные проблемы, увлеченность задачей, взаимоотношения в коллективе, приближение/отдаление очередного отпуска,...), отпуска, больничные, увольнения, ...);
— постоянный прогресс в инструментах (языки программирования, технологии, библиотеки и фреймворки);
— и, наверняка, что-то еще
Я согласен с AndrewVK, что ни один из этих пунктов не может гарантированно привести к авралу. Я даже готов поверить, что есть люди, которые делают минимум ошибок при постановке задачи, проектировании и кодировании. Что благодоря своим способностям и опыту они сводят риски к минимуму и избегают авралов.
Тем не менее, вероятность того, что на каждом уровне будет допущена серьезная ошибка, слишком велика, чтобы ей пренебрегать. А в совокупности все это образует очень "тонкий лед", любой неверный шаг по которому способен привести к увеличению трудозатрат и переработкам. И поводов к ошибкам на любом уровне может быть слишком много.
Мне трудно судить об управлении программными проектами, об архитектуре и проектировании крупных систем, но вот что я считаю очень характерной для программирования вещью, так это преобразование тех идей, которые находятся в голове программиста (постановщика задачи, проектировщика), в программный код.
Например, программист может прочитать в ТЗ, что нормальным условием для парового котла будет температура, не превышающая 100 градусов. И совершенно спокойно записать:
if( t < 100 )
normal_mode();
else
alarm_mode();
И только впоследствии кто-то обнаружит, что 100 градусов -- это допустимая температура. Но поздно, ошибка допущена (просто потому, что для кого-то "не превышает" эквивалентно "строго меньше") и хорошо, если она будет обнаружена быстро.
Еще хуже, что во время проектирования мы находимся на "своей волне", у нас есть ряд "умолчаний", которые мы неявно воспринимаем и не отдаем себе отчета о том, что их нужно декларировать явно в программе или технических документах. Например, мне как-то от смежников пришел документ, описывающий структуру необходимой им информации (они делали расчеты, а мы обеспечивали связь между компонентами и занимались передачей данных). Так вот в документе описывалась структура пакета вида:
и пояснение, что элементами векторов X являются комплексные числа. Соответственно, все так и было сделано. Когда же мы привезли свою часть на интеграцию оказалось, что вектор X -- это не вектор комплексных чисел, это вектор, каждый элемент которого состоял из матрицы Y и векторов X1 и X2 (!!!). Просто автор документа не задумался о том, насколько точно написанное им отражает его собственные представления. А ошибка оказалась офигенная -- объем одного пакета увеличивался сразу в 4-5 раз. Соответственно и объем расчетов на каждом из узлов увеличился соответственно, поэтому даже расчет перестал помечаться в отведенный по ТЗ интервал времени. Уж хрен знает, о чем они думали, но в результате пришлось по ходу править ТЗ и изменять заявленные в нем параметры.
Это все к тому, что программирование -- это та область, где ошибки поджидают на каждом шагу и проявляются в самое неподходящее время. Сюда же нужно добавить и внешние факторы. Менеджеры часто настаивают на сжатых сроках из-за конкуренции, программисты берут на себя повышенные обязательства из-за излишней самоуверенности, желания карьерного роста, прибавки к зарплате, неопытности и еще хрен знает чего.
Так что ошибаются все -- менеджеры, проектировщики, программисты, тестировщики, документаторы. Кто-то меньше, кто-то больше. Но все равно, рано или поздно ошибки случаются. В чем точно можно быть уверенным в программировании -- так это в том, что в вашей программе всегда есть ошибка.
А авралы и переработки -- это попытки исправления допущенных ранее ошибок. Причем чем на более ранней стадии и на более высоком уровне была допущена ошибка, тем больше усилий приходится прилагать. Ну или отказываться от чего-то (функциональности или качества, как сказал AndreiF).
Так что одним из главных факторов, обуславливающих возникновение авралов у программистов я считаю ошибки и просчеты (в широком смысле этого слова). Но это, к сожалению, не единственные факторы...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
AF>И что тут подтверждать? Многие люди принципиально не ставят новые версии программ именно из этих соображений. "Вот выйдет первый сервиспак, тогда и поставлю". В опенсорсе всё вообще в открытую, нечетные билды — "нестабильные"
Я не знаю особенностей разработки коробочного ПО, но с заказным ПО ситуация не такая однозначная. Заказчики платят за реализацию нужной им функциональности. И зачастую не откладывают переход на новые версии (более того, иногда даже не имеют возможности отложить этот переход), поскольку они не могут обходится без того, что заказали (могли бы -- не заказывали ).
А со свободным ПО ситуация вообще особенная, там жесткие сроки релизов -- это редкость, имхо. Да и отделов контроля качества нет -- пользователи как раз таким отделом и являются
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Плюс поставил, потому что авралы были. К самому спору: специфическими для нашей профессии их не считаю.
Если бы ты сказал что нибудь вроде "У программистов бывают авралы", то вряд ли кто нибудь с тобой бы спорил
Насколько я понял, именно об этом говорит твой опыт. А вот то, что "авралы это часть профессиональной специфики программирования" — это уже вывод, который ты сделал из этого опыта. Может просто вывод неверен? Приведи цепочку рассуждений
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, eao197, Вы писали:
E>>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
L>Плюс поставил, потому что авралы были.
Спасибо, это именно то, что и требовалось.
L>К самому спору: специфическими для нашей профессии их не считаю. L>Если бы ты сказал что нибудь вроде "У программистов бывают авралы", то вряд ли кто нибудь с тобой бы спорил L>Насколько я понял, именно об этом говорит твой опыт. А вот то, что "авралы это часть профессиональной специфики программирования" — это уже вывод, который ты сделал из этого опыта. Может просто вывод неверен? Приведи цепочку рассуждений
Здравствуйте, minorlogic, Вы писали:
M>при чем тут эти рассуждения ? я просто указывал что предложенное тобой голосование неадекватно, а ты рассуждаешь про что то другое.
Здравствуйте, eao197, Вы писали:
E>Я не знаю особенностей разработки коробочного ПО, но с заказным ПО ситуация не такая однозначная. Заказчики платят за реализацию нужной им функциональности. И зачастую не откладывают переход на новые версии (более того, иногда даже не имеют возможности отложить этот переход), поскольку они не могут обходится без того, что заказали (могли бы -- не заказывали ).
С заказным ПО все еще проще — можно точно узнать у заказчика, что ему нужно сделать немедленно, а какие рюшечки можно отложить на потом. И нет никакой необходимости работать больше нормы.
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
ЗЫ
А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
Аврал ни что иное как попытка сделать работу которую надо было делать несколько месяцев (а то и лет) за короткий промежуток времени (неделю, а то и ночь).
Если уж случилось, так, что вы не верно оценили свои силы или открылись новые, неведомые обстоятельства приведщие к срыву сроков, то лучше отказаться от части фунциональности или увеличить срок. Работа сделанная в полусне на коефе/чае/кофение/экстази заведомо некачественна.
Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. "Постоянные переодические овралы" (тм) были частью моей жизни где-то до 2000-го года. И только сейчас я понял, что это были проявления нашей безолаберности и неоптытности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
eao197 категоричен и потому не прав. Так же дело обстоит и с тобой, с чего ты взял, что если "авралы происходят раз в несколько лет", то отсюда очевидно, что "люди не могут без оралов сдавать свою работу"?
Здравствуйте, VladD2, Вы писали:
E>>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
VD>Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
По поводу неумения понять простую просьбу и досмысливание чего-то еще см.здесь
VD>А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
VD>Аврал ни что иное как попытка сделать работу которую надо было делать несколько месяцев (а то и лет) за короткий промежуток времени (неделю, а то и ночь).
VD>Если уж случилось, так, что вы не верно оценили свои силы или открылись новые, неведомые обстоятельства приведщие к срыву сроков, то лучше отказаться от части фунциональности или увеличить срок. Работа сделанная в полусне на коефе/чае/кофение/экстази заведомо некачественна.
VD>Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
...The Standish Group research shows a staggering 31.1% of projects will be cancelled before
they ever get completed. Further results indicate 52.7% of projects will cost 189% of their
original estimates...
...On the success side, the average is only 16.2% for software projects that are completed ontime
and on-budget. In the larger companies, the news is even worse: only 9% of their projects
come in on-time and on-budget. And, even when these projects are completed, many are no
more than a mere shadow of their original specification requirements. Projects completed by the
largest American companies have only approximately 42% of the originally-proposed features
and functions. Smaller companies do much better. A total of 78.4% of their software projects will
get deployed with at least 74.2% of their original features and functions...
“On average, companies start 38 projects annually, less than half of which (42 per cent) are completed on time and on budget, while six per cent are cancelled altogether,” says Carter. “At an average cost of $199,033 per week, projects not completed within the set timeframes are causing companies major budget blowouts.”
Меньше половины проектов заканчиваются вовремя и укладываются в бюджеты. И даже те, что укладываются, содержат далеко не все фичи, которые в них закладывали изначально.
Имхо, эти данные свидетельствует либо о тотальном непрофессионализме занятых в разработке ПО (за редким исключением в виде тех, кто на мою просьбу ответил минусом, естественно), либо о том, что в самом процессе разработки ПО есть что-то особенное. О чем я и пытаюсь сказать.
VD>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. "Постоянные переодические овралы" (тм) были частью моей жизни где-то до 2000-го года. И только сейчас я понял, что это были проявления нашей безолаберности и неоптытности.
Не подставляйся, а то у меня есть большое желание "ударить лежачего".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, lomeo, Вы писали:
L>Так же дело обстоит и с тобой, с чего ты взял, что если "авралы происходят раз в несколько лет", то отсюда очевидно, что "люди не могут без оралов сдавать свою работу"?
А я этого не утверждал. Так что и обсуждать не чего. Понятно, что форсмажор или нужда может случаться раз в 5-10 лет. Но если это начинает случаться постоянно, то проблемы надо искать в себе и своих подходах. А те кто считает, что это в норме вещей, скажем так, не совсем правы.
L>Кстати, интересная опечатка (выделено)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Меньше половины проектов заканчиваются вовремя и укладываются в бюджеты. И даже те, что укладываются, содержат далеко не все фичи, которые в них закладывали изначально.
E>Имхо, эти данные свидетельствует либо о тотальном непрофессионализме занятых в разработке ПО (за редким исключением в виде тех, кто на мою просьбу ответил минусом, естественно), либо о том, что в самом процессе разработки ПО есть что-то особенное. О чем я и пытаюсь сказать.
О первом оно свидетельствует. Вообще высококлассных спецов очень мало.
В прочем, разработка ПО тем и отличается, что дисциплина эта творческая, а значит сильно зависящая от человеческого фактора.
Но опять же, ты сам сказал, что "половины проектов заканчиваются вовремя и укладываются в бюджеты" и "содержат далеко не все фичи" — это и есть разумные выходы из ситуации. Не уложились? Значит применяем более быстрые решения и уменьшам объем фич. А штурмовщина — это плохой выход из положения.
В режиме шутрма можно работать день-два. Проекты ведутся обычно годами. Я не вижу смысла в экономии пары дней. А штурм длинной в неделю — это отличный способ добиться переутомления, что приведет к обратному эффекту.
E>Не подставляйся, а то у меня есть большое желание "ударить лежачего".
- Фиона!
— Я Шрэк!
— А мне по фигу...
(с) цирюльник из Шрэк 3.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
VD>А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
VD>Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
Даже тем, у кого как ты верно подметил мог быть всего один аврал?
Не приходила в голову такая мысль, что аврал мог быть вызван причинами, не зависящими от человека?
VD>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду.
Ещё бы, искажаешь исходные факты — о чём тут спорить.
now playing: Alexi Delano & Xpansul — Pares Y Juego
Здравствуйте, AndrewVK, Вы писали:
AVK>Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
Скорее — заказчики не той системы. Тепличный вариант, который возможен при наличии очереди заказчиков. Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено, а иначе бы не было проекта, заказчик бы отказался от самой задумки и вложился бы в другое... В то же самое время проект технически невероятно интересен (нам) и область настолько же невероятно актуальна, востребована и денежна настолько, что заказчику дешевле финансировать разработку своей системы в течении года, для "унутреннего применения" чем покупать готовые... да и нам хоть какая-то отдушина после этих идиотских "решений для бизнеса".
Здравствуйте, vdimas, Вы писали:
V>Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено
Кто отвел времени меньше чем положено? Твоим мнением при этом интересовались? Как оплачивается переработка?
V>область настолько же невероятно актуальна, востребована и денежна
Здравствуйте, EvilChild, Вы писали:
EC>Даже тем, у кого как ты верно подметил мог быть всего один аврал?
Если был всего один, то эти люди с огромной вероятностью уже задумались и сделали правильные выводы. Иначе авралы повторялись бы.
EC>Не приходила в голову такая мысль, что аврал мог быть вызван причинами, не зависящими от человека?
Так не бывает. Любой подвиг является результатом чьего-то раздолбайства или глупости.
VD>>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. EC>Ещё бы, искажаешь исходные факты — о чём тут спорить.
Я искажаю? Ну, ты фантазер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
V>>Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено
AVK>Кто отвел времени меньше чем положено? Твоим мнением при этом интересовались?
Вопрос стоял так: "можно ли сделать то-то и то-то с выходом на рынок за столько-то недель?". Ответ был — если поднапрячься, то можно.
AVK>Как оплачивается переработка?
Несколько повысилась ЗП у работников всвязи с началом этого проекта.
V>>область настолько же невероятно актуальна, востребована и денежна
AVK>Каким процентом акций предприятия ты владеешь?
Здравствуйте, vdimas, Вы писали:
V>Вопрос стоял так: "можно ли сделать то-то и то-то с выходом на рынок за столько-то недель?". Ответ был — если поднапрячься, то можно.
Ну вот и настоящая причина. А отнюдь не "специфика программирования".
AVK>>Как оплачивается переработка?
V>Несколько повысилась ЗП у работников всвязи с началом этого проекта.
Несколько это сколько? В процентах хотя бы.
AVK>>Каким процентом акций предприятия ты владеешь?
V>Акций пока не выпускал, обхожусь без них.
Ну если это твое личное предприятие, то и говорить не о чем.
